Public SourceMage Discussion List

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

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

Attachment: pgpWnmH_cooFn.pgp
Description: PGP signature