Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [RFC] Compressed filetype detection (Bug #16011)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jaka Kranjc <smgl AT lynxlynx.info>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [RFC] Compressed filetype detection (Bug #16011)
  • Date: Sun, 15 May 2016 23:37:52 +0200

On Sunday 15 of May 2016 17:37:25 Ismael Luceno wrote:
> On 15/May/2016 21:31, Jaka Kranjc wrote:
> > On Sunday 15 of May 2016 16:04:39 Ismael Luceno wrote:
> > > I am thinking about having the uncompression, checksumming, signature
> > > verification, etc. all reworked and split into a separate unit, so
> > > that we can make it more flexible and streamline all tasks related
> > > to the inspection, packing and unpacking of spell sources, which I
> > > hope makes it easier to build better tools, specially to automate
> > > spell creation and inspection, and which could remove the need to
> > > specify information like BUILD_DIRECTORY into the spells.
> >
> > They're already in separate "units" — libraries. How could they be any
> > easier to reuse? If you're missing some more high-level interfaces, that
> > is trivial to add.
>
> It is only simpler to reuse within sorcery. Doing complex changes,
> experiments, with sorcery is nowadays not simple.
Eh? Nowadays? What did you try to do and what stopped you? Maybe as a counter-
example, when I wrote the update mode for quill, sorcery hardly changed to
make that possible.

If you for some (odd) reason don't want to load all sorcery, you can still
only load what you need. Quill does that for faster startup and then loads
the
rest.

> The problem I see with sorcery is that it is too tightly coupled,
> it's exactly the opposite of what unix is meant to be, and for no
> good reason.
Examples, proof? I'm sure some functions could be split further and libmisc
cleaned up, but that's bordering on nitpicking. Code is reused when a need is
shown. Most of it is in thematic library functions, there's plenty of
modularity and layering, so it's pretty bizzare that you accuse it of tight
coupling. Especially since it is written in bash where it is trivial to
redefine functions at runtime.

>
> In this area in particular, there is no benefit whatsoever.
>
> And if we kept things separate and generic, perhaps someone else
> would find it useful too.
>
> > The only reason I can think of for a separate BUILD_DIRECTORY var is that
> > some archives don't extract to expected locations. In case they create
> > more than one top-level directory, the correct one can't be
> > deterministically guessed, so I doubt the var can go away. I guess it's
> > also partly a verification mechanism.
>
> For the few spells that are not tarbombs or similar, we can add an
> extra line in BUILD, the rest can be automatically fixed.
>
> This could also be a step forward to allow easier incompatible parallel
> builds, sharing the rest of the system, which could in turn be unified
> with the cross-building support for a more uniform approach.
Parallel builds of the same spell sounds like a bad idea. Perhaps ok for the
individual level, but imagine it being part of a queue. And an automatically
different build dir wouldn't solve much, since you still need a different
install and potentially track root. There's no way to guess that, so what's
an
extra var to specify when invoking cast?

> Also, testing of different steps of the build, with changes in the
> middle, could be easier.
What do you miss in delve? AFAIK it was created for exactly this reason.

LP
--
To err is humour
www.gemrb.org




Archive powered by MHonArc 2.6.24.

Top of Page