Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=7751


acedit AT armory.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Additional Comments From acedit AT armory.com  2005-03-30 08:23 -------
Beware: long thought experiment dump below

First off, is this feature request limited to on_cast triggers? In other 
words,
do we care about making on_dispel, on_pre_cast or on_pre_dispel triggers run 
in
'dependency sorted ways'? Within that, what actions do we care about? Theres a
total of 16 combinations.

For now Im limiting my thought experiments to on_cast triggers.

In this particular bug, you basically seem to want the triggers to execute at
some point between the time they are currently triggered and when cast is
totally done, some intermediate casting is in other words acceptable. Delayed
triggering. The opposite philosophy is "Immediate Triggering", in which case 
you
run the trigger as soon as possible, this is what we do now. Both have
advantages, but for now lets just take this as a request for delayed 
triggering
for the on_cast trigger.

My basic architecture so far is to do a no-op in the triggering spell if the
spell is going to be cast later due to dependency ordering, and after all
casting is done, if a trigger wasnt run at the appropriate time, run it then.

In your case, we have 'straw', which has an indirect depends on python 
(through
other spells), and it also has an on_cast python cast_self trigger. To express
the trigger in the dependency tree, it is just 'straw depends on python' which
is technically already the case. As such, when the depends tree is built, this
dependency rule can be added and make will do its best to sort things based on
dependency order. So in fact, our trigger is just to do nothing. The potential
problem with this is someone makes a circular depends, at that point make 
seems
to pick an arbitrary order, so straw (for example) could cast before python. 
We
could note during the straw cast that it was built before its triggering spell
was and it would need to be cast yet again.

check_self triggers are a little different. One approach is to skip the check 
if
the spell is in our depends tree and hasnt cast yet. On the other hand, 
someone
might complain that we'd potentially be leaving the spells broken for an
extended period of time, this directly conflicts with the delayed triggering
philosophy.

dispel_self is even more different, say straw has a on_cast python 
dispel_self.
What if some other part of the depends tree needs straw? The end result is
either cast failures or a dispel_self not holding. This isnt a problem with
delayed/immediate triggers, although it can change the results, which seem to 
be
basically undefined. However I find no usage of on_cast dispel_self triggers 
in
the grimoire that are for spells /other/ than the spell using the trigger, all
of which appear to be for spell depreciation. Im going to otherwise leave the
behavior of on_cast dispel_self as is, and open-ended. If someone wants to 
think
about this, great, I'm not right now.

Im going to ignore run_script for now, except I will point out that one can
re-implement 'immediate triggering' with it in the same way it exists 
currently.

The next phase of questions I have to ask myself have to do with recursive
triggering, which i believe may lead to a greater incidence of cyclic 
depends. I
suppose after that theres cyclic triggering...then theres the other trigger
types. Note that I find no examples of on_pre_cast, that tells me either its 
too
backwards for people to think about, the same thing can be done other ways, or
both, should we just get rid of it?

It would be good to get some other  unique examples of on_cast triggers; the
only one i have is basically perl-module -> perl, or python-module -> python.
Both of which are basically shadows of the dependency tree.

Are there usage cases where we have
foo depends bar
bar on_cast foo cast_self
In other words, we have to cast bar before we cast foo, and when foo is cast,
bar must be recast. In my above solution depending on what make does we'd 
either
get:
break bar -> foo depends, cast bar, cast foo, all casting finishes, cast 
notices
bar cast before foo, so recasts bar.
OR
break foo -> bar depends, cast foo, cast bar
foo can however fail since it needs bar cast first, at which point, well, who 
knows.

A possibly more realistic example is a bigger cycle.

My example of recursive depends is
nvidia_driver:xfree86:on_cast:cast_self
xfree86:zlib:on_cast:cast_self

So if I cast zlib, xfree86 must be cast after it, and likewise nvidia_driver 
is
also in the tree, conveniently after xfree86. This all comes out rather
elegantly with delayed triggers, again seeing the triggers shadow 
dependencies.
The case I worry about is where theres not such a clean shadow, or some cycles
show up.

Perhaps the ultimate solution for cycles and trigger ordering is to do our own
tree traversal instead of using make. Then we can apply weights to the edges,
depends would get heavy edges, triggers would get light edges so cycles would
always break the lightest edge (a trigger). For now I think we can only
concievably handle the pretty cases elegantly.

-- 


------- Additional Comments From acedit AT armory.com  2005-03-30 08:23 -------
Beware: long thought experiment dump below

First off, is this feature request limited to on_cast triggers? In other 
words,
do we care about making on_dispel, on_pre_cast or on_pre_dispel triggers run 
in
'dependency sorted ways'? Within that, what actions do we care about? Theres a
total of 16 combinations.

For now Im limiting my thought experiments to on_cast triggers.

In this particular bug, you basically seem to want the triggers to execute at
some point between the time they are currently triggered and when cast is
totally done, some intermediate casting is in other words acceptable. Delayed
triggering. The opposite philosophy is "Immediate Triggering", in which case 
you
run the trigger as soon as possible, this is what we do now. Both have
advantages, but for now lets just take this as a request for delayed 
triggering
for the on_cast trigger.

My basic architecture so far is to do a no-op in the triggering spell if the
spell is going to be cast later due to dependency ordering, and after all
casting is done, if a trigger wasnt run at the appropriate time, run it then.

In your case, we have 'straw', which has an indirect depends on python 
(through
other spells), and it also has an on_cast python cast_self trigger. To express
the trigger in the dependency tree, it is just 'straw depends on python' which
is technically already the case. As such, when the depends tree is built, this
dependency rule can be added and make will do its best to sort things based on
dependency order. So in fact, our trigger is just to do nothing. The potential
problem with this is someone makes a circular depends, at that point make 
seems
to pick an arbitrary order, so straw (for example) could cast before python. 
We
could note during the straw cast that it was built before its triggering spell
was and it would need to be cast yet again.

check_self triggers are a little different. One approach is to skip the check 
if
the spell is in our depends tree and hasnt cast yet. On the other hand, 
someone
might complain that we'd potentially be leaving the spells broken for an
extended period of time, this directly conflicts with the delayed triggering
philosophy.

dispel_self is even more different, say straw has a on_cast python 
dispel_self.
What if some other part of the depends tree needs straw? The end result is
either cast failures or a dispel_self not holding. This isnt a problem with
delayed/immediate triggers, although it can change the results, which seem to 
be
basically undefined. However I find no usage of on_cast dispel_self triggers 
in
the grimoire that are for spells /other/ than the spell using the trigger, all
of which appear to be for spell depreciation. Im going to otherwise leave the
behavior of on_cast dispel_self as is, and open-ended. If someone wants to 
think
about this, great, I'm not right now.

Im going to ignore run_script for now, except I will point out that one can
re-implement 'immediate triggering' with it in the same way it exists 
currently.

The next phase of questions I have to ask myself have to do with recursive
triggering, which i believe may lead to a greater incidence of cyclic 
depends. I
suppose after that theres cyclic triggering...then theres the other trigger
types. Note that I find no examples of on_pre_cast, that tells me either its 
too
backwards for people to think about, the same thing can be done other ways, or
both, should we just get rid of it?

It would be good to get some other  unique examples of on_cast triggers; the
only one i have is basically perl-module -> perl, or python-module -> python.
Both of which are basically shadows of the dependency tree.

Are there usage cases where we have
foo depends bar
bar on_cast foo cast_self
In other words, we have to cast bar before we cast foo, and when foo is cast,
bar must be recast. In my above solution depending on what make does we'd 
either
get:
break bar -> foo depends, cast bar, cast foo, all casting finishes, cast 
notices
bar cast before foo, so recasts bar.
OR
break foo -> bar depends, cast foo, cast bar
foo can however fail since it needs bar cast first, at which point, well, who 
knows.

A possibly more realistic example is a bigger cycle.

My example of recursive depends is
nvidia_driver:xfree86:on_cast:cast_self
xfree86:zlib:on_cast:cast_self

So if I cast zlib, xfree86 must be cast after it, and likewise nvidia_driver 
is
also in the tree, conveniently after xfree86. This all comes out rather
elegantly with delayed triggers, again seeing the triggers shadow 
dependencies.
The case I worry about is where theres not such a clean shadow, or some cycles
show up.

Perhaps the ultimate solution for cycles and trigger ordering is to do our own
tree traversal instead of using make. Then we can apply weights to the edges,
depends would get heavy edges, triggers would get light edges so cycles would
always break the lightest edge (a trigger). For now I think we can only
concievably handle the pretty cases elegantly.

--


------- Additional Comments From acedit AT armory.com  2005-09-01 02:43 -------
This should be fixed in the trigger push into devel at change 65010

-- 


------- Additional Comments From acedit AT armory.com  2005-09-01 02:43 -------
This should be fixed in the trigger push into devel at change 65010

--


------- Additional Comments From acedit AT armory.com  2005-10-21 13:06 -------
re-marking as fixed

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.