Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] feature creep. WAS: splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Tue, 10 Oct 2006 00:40:59 +0300

> > This would make casting somewhat slower, but personally I'd happily pay
> > the price for not having to do so many full-house cleanses and hunting
> > for missing check_self triggers.
>
> Theres an issue with this, which is that cast needs to know everything
> its going to build ahead of time because figuring it out later implies
> user interaction.
>
> - foo rebuilds
> - check_self on bar (dependee of foo)
> - check_self fails, have to rebuild bar
> - to rebuild bar sorcery has to do depends resolution on it
> - to do dependency resolution cast has to run PREPARE/CONFIGURE/DEPENDS
> on the spell
> - but its too late, we're in the middle of compilation and can't do
> something that might prompt the user :-(

I don't see how this would differ from what we have now with check_self.
Correct me if I'm wrong, but isn't this how check_self works:

1) 'cast foo' is run, spell bar is installed and has in TRIGGERS: 'on_cast
foo
check_self
2) do depends resolution for foo, and also for bar because of the check_self
3) foo is cast
4) bar is checked
5) check_self bar fails
6) bar is cast, no need for interruption as depends resolution is already done

So my suggestion would work like this:

1) 'cast foo' is run. spells bar and qux depend on foo.
2) depends resolution for foo, and also for bar and qux because they are
dependees
3) cast foo
4) check_self bar
5) if failed, cast bar <-- depends resolution already done
6) same for qux, etc.

This would of course result in more queries, but on the other hand most
queries for bar and qux should have default answers because they've already
been installed earlier.

Based on this example, I don't see why a check-em-all option like this
couldn't exist. It would basically be the same as if all dependees of foo had
the trigger "on_cast foo check_self" in them. Please shoot more holes if you
have ammo. :)

> It might be possible to use the tablet'd spell, where all the answers
> are known. But then we have to support building from the tablet (which
> is an eventual goal if enough things need it).
>
> A counterpoint to using the tablet might be "but the old version of
> bar in the tablet might not work with the latest foo" in which case a
> cast_self up_trigger should exist anyway.

I've nothing to say about the tablet stuff, I haven't enough knowledge to
contribute.

> Of course doesnt this seem kind of silly talking about a new feature
> request immediatly after someone mentions feature creep. Just a little?

You got me there. :) On the other hand, I think you understand that I'm
aiming
at reducing the amount of work needed for spell maintenance, and thus for
less feature stress. I do agree that this kind of a suggestion is
controversial, but I have a fairly reasonable argument in my back pocket if
you care to read onward.

> One has to wonder how often this sort of thing actually happens on a
> properly updated box.

I run into evasive lib breakage every now and then, and I do believe I keep
this box well updated. What an option like this would enable is instantly
catching stuff that needs check_self triggers. Some seldom-used app residing
on the hard disk may suffer from lib breakage (that results from an updated
dependency) for a while before it's actually run. And it's not after every
cast that I (or probably many others) run a full cleanse.

Let's suppose we don't enforce this kind of check-em-all feature on all
users - and I very much doubt we will - but we add it as an option. So we'll
still need check_self triggers for every case where lib breakage is a
possibility. Now, suppose then that I have the check-em-all option enabled,
and I cast an updated spell. It will show me right away which dependees got
broken because of the update, and I can go and add check_self triggers
instantly in the grimoire, or do other fixes if necessary. If one of those
broken and fixed dependees would have happened to be
spell_i_never_use_but_have_installed, the breakage would not have been
revealed until the next cleanse --fix.

> Personally I favor automation at "build-time" (working on the code
> before distribution to users machines) to extra work at "run-time"
> on the user's box.
>
> Also, I think theres far too many other unresolved issues discovered by
> prometheus that need attention. Our grimoire QA process could stand to
> be *much* more active. We can work on that without effecting feature
> creep at all, and deliver a better product to the end users.

I can't but agree with you about the bugs. But that's another topic, and I
promise I'll do my best with the kde sections which I'm now maintainer of.

But I'd like to wrap this up. While writing this very mail I've come to
realize two things:

1) My original suggestion probably isn't viable. Enforcing a general
check-em-all feature is a bit much, to say the least.
2) On the other hand, the very same feature I originally suggested would be
an
efficient tool for locating missing check_self triggers, if it's implemented
as an optional feature aimed at grimoire developers.

So, if you favor working on the code before distributing it to users, it
should make sense to implement something like this.

--
Juuso Alasuutari
[[ Source Mage GNU/Linux ]]

Attachment: pgpyao6G1Cuh1.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page