Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

On Tue, Oct 10, 2006 at 12:40:59AM +0300, Juuso Alasuutari wrote:
> 
> 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

And thus for every spell that depends on those spells. Because the
check_self has to run for them as well. I dont think users (or developers)
will want cast to waste time doing depends resolution for potentially
every spell they have installed. Thats a lot of spells and extra work
to do just in case something *might* go wrong. I think its better to
just use cleanse afterwards to see whats broken and simply fix it. Giving
this to users is a bad excuse for not doing QA.

> 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. :)

Im up for it, although, I have more ammo than you... :-)

Before we begin, Im going to note that you concede below that this is
more for grimoire developers, and not end users (If you arent actually
conceding the user side of things we can still talk about it).

So Im going to frame my responses within the context that this is a
developers only feature. And not something users should be doing on a
regular basis.


> > 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.

Define "every now and then" in more concrete terms.

Its not instant, it requires a big payment up-front all the time for
the possibility that something might break. This isnt really a very
modular or unix-like solution. This is a big monolithic-app solution.

Im not seeing the advantage of embedding the check in cast where in
order to use it you have to jump through hoops (dependency resolution
for all parent spells) regardless of whether or not they're cast.

Instead of jumping through those hoops all the time, why not just update
within a test environment, then run cleanse, note whats broken and fix
the spell. Build, test, fix. With this feature instead you'll just miss
things that were broken because they'll be automatically fixed. You'll
never guess what happens next! We'll miss something, then as a "workaround"
tell users to use the feature anyway (and we're agreeing that they shouldn't).

We already have a tool to check for broken stuff (cleanse). We already
have a tool to test spells (prometheus). Why dont we use those, rather
than overcomplicating sorcery with a feature we'd largely use only in
prometheus anyway.


> 
> 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.

It wont show you "right away" (triggers dont run until all the triggerers
have been processed (assuming at least one succeeds). Nor do I think
you'll add the triggers "instantly" but that'd be a neat trick if
you could.

Lets refrain from exageration please, it detracts from your argument.

In anycase, you can just run cleanse after the fact and know whats broken,
and fix things that way. Or prometheus could do an update, run cleanse
--fix and figure out whats broken and based on missing lib tests derive
what things broke it and figure out what spells (yes plural) need
check_self/cast_self triggers.

> 
> > 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.

Actually, it'd be more efficient and useful done externally through
prometheus than internally in sorcery.


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

I dont think that conclusion follows from the premise unless we take a
really broad definition of "something like this".

If I favor "working on the code before distributing it" (Im assuming
you mean an alternative to "release early release often release
broken"). Then I would favor proper QA. How does proper package QA imply
feature creep in the package manager?

-Andrew

-- 
_________________________________________________________________________
| Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
| irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
| 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
-------------------------------------------------------------------------