Public SourceMage Discussion List

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

Thanks to those who tested this. I'll be integrating to devel shortly
unless some major malfunction comes up.

As for the enhancements proposed below, since there has been little
response, I'll leave the TRIGGER_CHECK file as it is. If/when people want
to talk about it, its there to try out, and as I said, Im more than happy
to work out something different if whats there is not acceptable. For
now I'll assume its either not wanted, not important, or is acceptable
as implemented. As for improving the interface to triggers (also outlined
below), I'll simply punt, and "do nothing" for now. If the conversation
comes up on the topic in the future I'll reference this thread with
my suggestions.

-Andrew

On Thu, Aug 25, 2005 at 08:40:36PM -0700, Andrew Stitt wrote:
> The sorcery team has been working on improving on_cast triggers. The
> work is mostly complete, and I think its ready for broader testing and
> feedback from the development/user-base.
> 
> The main improvement was to integrate (on_cast) triggers with dependency
> sorting. In the old implementation, an on_cast trigger was effectively a
> cast -c after the triggering spell completed. This leads to many spells
> being cast multiple times. For example, if zlib casts, it will trigger
> a number of casts. During a rebuild, those spells are already going to
> be cast.
> 
> The new implementation puts triggers into the same dependency tree and
> works hard to only cast a trigger once (if there arent any dependency
> loops, its guaranteed). As a consequence, triggered spells are inspected
> at the same time as other spells, as opposed to being a seperate cast
> entirely.
> 
> I've got this code working and have made a temporary sorcery tarball
> availible as sorcery-trigger.tar.bz2 on the mirror. To use it, set your
> sorcery branch to 'triggers', then do sorcery update. Try casting zlib :-)
> 
> I'll probably integrate things to devel for a wider audience soon,
> I'd like to get some preliminary testing first though.
> 
> ******
> 
> All the above is effectively taking the existing triggers and making
> them work better, but not really enhancing them in anyway. So I want to
> start a discussion on how to fix the other problems with (on_cast) triggers.
> 
> Aside from the problems with dependency/trigger sorting, the main issues
> with triggers (that ive heard of) are:
>  * no such thing as an on_update/on_api_change trigger, leading to
>    un-necessary triggers
>  * triggers are difficult/annoying/infeasable to add en-masse
> 
> The first problem could be fixed by adding extra decision making code
> to the on_cast trigger. Theres a piece of code where cast looks at a
> trigger, and asks the user if they want to run that trigger or not. It would
> be possible to override that default functionality with something that
> could compare the VERSION/UPDATED field or something even more
> exotic. The exact mechanism is up in the air.
> 
> I've proof-of-concepted a new spell file (for lack of a better name)
> TRIGGER_CHECK. It lives in the triggerer's script directory. It gets
> called for each trigger with $TARGET and $ACTION set to the spell
> being triggered and the trigger action (cast_self or check_self). If
> the file returns true, the trigger should be run, if it returns false,
> the trigger is not necessary.
> 
> Let me stress that this is just one way this could work, nothing here is
> set in stone. The above is just the simplest way possible to demonstrate
> the functionality Im describing. Id like for the final solution to be
> simple, extensible, flexible and easy for spell writers to work with.
> 
> Thoughts? Ideas?
> 
> The other problem with triggers, is you have to add one for each spell
> that needs one. That can get tedious, so I think we could use a better
> interface. I dont know what that interface would look like, but here
> are some options to maybe get people thinking.
> 
> * Allow calling on_cast() from DEPENDS, most on_cast triggers shadow
> dependencies, so one could put all that information into one file. In
> theory it might be more manageable.
> 
> Commentary: this doesnt really make things any more powerful, but might
> make it less tedious by having one file to work on instead of two.
> 
> * Make depends/optional_depends have a flag to indicate there should
> also be an on_cast trigger (assuming the optional depend is on). Or make
> more depends functions which combine regular depends and triggers.
> 
> Commentary: slightly less tedious than first option, adds more complexity to
> depends parameters. Might be less flexible in the long run.
> 
> * Do nothing, triggers are fine as they are.
> 
> Commentary: update could be more seamless with more triggers.
> cleanse --fix may not get everything in one pass, a number of spells
> (perl modules) arent obviously broken from cleanse --fix, but still
> need recasting. There are other ways around the cleanse --fix/perl
> module issue. By far, the easiest :-)
> 
> * Add a new spell file on the triggerer's side. The file would let the
> spell generate triggers. For example, zlib could dynamically trigger
> cast_self on all the spells that depend on it. Other spells with similarly
> shaky api's could do the same. Perl could trigger a recast on all the 
> installed perl modules. 
> 
> Commentary: Much more powerful interface. However it involves making
> (possibly bad) assumptions about spells. Leads to further decentralization
> of information, for example, the triggerer would have to know what spells
> may be effected by an api change. Overall spell management could become
> more difficult.
> 
> * Auto-detect breakage and trigger rebuilds.
> 
> Commentary: The problem here is that cast wants to ask the user all
> the questions it can before starting compilation. Thus, if we decide
> midway through to cast something, we'd need to ask the user questions,
> breaking our model. A solution to that is to cast the broken spell from
> the tablet where all the questions have already been answered. This
> is a fair amount of work, has the most unknowns but could be do-able,
> but not over-night. The other ideas can be. There would also need to be
> an optional spell defined api for checking itself. Perl modules would
> make sure that perl didnt upgrade out from under them. This is by far
> the most work and error prone.
> 
> 
> -Andrew
> 
> --
> __________________________________________________________________________
> |Andrew D. Stitt                           | astitt at sourcemage.org    |
> |irc: afrayedknot                          | afrayedknot at t.armory.com |
> |aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
> |Sorcery Team Lead                         | ftp://t.armory.com/         |
> --------------------------------------------------------------------------



> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


-- 
__________________________________________________________________________
|Andrew D. Stitt                           | astitt at sourcemage.org    |
|irc: afrayedknot                          | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus    | acedit at armory.com        |
|Sorcery Team Lead                         | ftp://t.armory.com/         |
--------------------------------------------------------------------------