sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells
- From: Jose Bernardo Silva <josebernardo1 AT yahoo.com>
- To: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
- Cc: sm-sorcery AT lists.ibiblio.org
- Subject: Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells
- Date: Tue, 6 Aug 2002 10:05:12 +0100 (BST)
Dufflebunk,
When you mentioned alsa-driver, I remembered which
action I thought was missing - a "rebuild me after
reboot after spell B was cast" trigger. Alsa-driver,
and other kernel module spells should really only be
rebuilt after one has booted into the new kernel. I
have no ideas on how to go to implement this, but
possibly someone has... :-)
--- Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
wrote: > Ah poopy. Here's a bunch of diffs that should
work
> better.
>
> On Tue, 2002-08-06 at 01:52, Dufflebunk wrote:
> > Actualy, I did commit it. And now I'm sure I did
> that wrong because I
> > think I commited it to branch-0_1. (/me prepares
> for flamage from CVS
> > keeper) In any case, Here are the diffs. Do unpack
> it in a temp
> > directory though as I think there's a bunch of
> extra path stuff in the
> > tar.
> >
> > By a spell's triggers I mean the triggers that are
> "owned" by the
> > spell... the spell that the self refers to in
> cast_self.
> > Perhaps an example?
> >
> > On the wiki, there are two sample spells, test1
> and test2. test2 has a
> > TRIGGERS file, it owns the triggers in there and
> the resulting triggers
> > that get added to /var/state/sorcery/triggers (ie
> registered). Those
> > triggers in the test2 spell do not get added to
> > /var/state/sorcery/triggers until after test2 is
> cast. Unless one of
> > those triggers is for test2, it's not a problem.
> If one of them is, it
> > should be put in BUILD or another script.
> >
> > It is important to remember that the triggers are
> saying, "I belong to
> > spell A. When event E happens to spell B, tell A
> perform an action." And
> > the possible actions (hopefuly) will always be an
> action on the spell
> > that owns the trigger (A, or test2). So linux-*
> doesn't need to know
> > that NVIDIA_kernel, and alsa-driver, and... need
> to be recast when it
> > is. NVIDIA_kernel needs to know it needs to be
> recast when linux-* is,
> > dito for alsa-driver, ...
> > I chose this way because linux-* should have to
> know anythign about the
> > spells that depend on it (think OO principals).
> >
> >
> >
> > On Tue, 2002-08-06 at 01:30, Nicholas K. Jennings
> wrote:
> > >Sorry to keep responding to the same message but
> I have one more
> > >question.
> > >
> > >In the description in Wiki, you mention that "a
> spells triggers are
> > >registered at the end of it's cast". What if the
> spell had a
> > >on_pre_cast
> > >trigger? Also, what excatly does "register" mean
> then?
> > >
> > >Later on you mention that "triggers are
> registered in the post_install
> > >stage". Which to me makes more sense, that is, I
> am assuming by
> > >registering you mean being entered into:
> > >
> > >/var/state/sorcery/triggers
> > >
> > >Right?
> > >
> > >- nick
> >
> > And also wrote:
> > > This sounds really good Dufflebunk. Actually I
> remember talking
> > > about this the Ryan on IRC several weeks ago and
> that what I
> > > wanted to see as well.
> > >
> > > Now if only you could commit it so I can take a
> look at it :)
> > >
> > > - Nick
> > >
> > > On Mon, Aug 05, 2002 at 11:21:38PM -0400,
> Dufflebunk wrote:
> > > > This thread is from SM-Discuss, but should be
> here.
> > > > Done.
>
http://wiki.sourcemage.org/index.php?page=spell_triggers
> has a bit
> > > > more info on what I did... adding new triggers
> or actions is easy to do.
> > > > I made the first four actions that came to
> mind: cast_self (really
> > > > recast_self), dispel_self, check_self, and
> run_script. The four triggers
> > > > that I put in are on_cast, on_pre_cast,
> on_dispel, and on_pre_dispel.
> > > > I'm pretty sure I didn't commit it properly to
> the CVS... so... yeah...
> > > >
> > > >
> > > > On Mon, 2002-08-05 at 18:29, Eric Sandall
> wrote:
> > > > >
> > > > > Sergey A. Lipnevich said:
> > > > > > It's not just a kernel spell problem. E.g.
> PHP module
> > > > > > will not work if Apache2 version changes,
> or openssh
> > > > > > has to be recompiled after openssl has
> been, or Galeon
> > > > > > and Mozilla (usually), there are probably
> other
> > > > > > "coupled" relationships. At the same time,
> simply
> > > > > > recompiling everything in the 'gaze
> depends x' list is
> > > > > > overkill, because most of such
> dependencies do not
> > > > > > depend on include files, instead they just
> link to the
> > > > > > libraries dynamically. That's what dynamic
> linking is
> > > > > > for, after all. I think we can add certain
> method,
> > > > > > 'affects' for example, to the DEPENDS
> file, listing
> > > > > > each spell that has to be recompiled after
> the one in
> > > > > > question.
> > > > > >
> > > > > > --Sergey.
> > > > >
> > > > > I like this idea. Anyone have the
> time/skill to send a patch for this to
> > > > > the sorcery team? Or should we discuss this
> more, first?
> > > > >
> > > > > -One of Three
> > > > >
> > > > > --
> > > > > Eric Sandall |
> Source Mage GNU/Linux Developer
> > > > > sandalle AT hellhound.homeip.net |
> http://www.sourcemage.org
> > > > > http://hellhound.homeip.net/~sandalle |
> SystAdmin @ Inst. Shock Physics @ WSU
> > > > > ICQ: 667348 |
> http://www.shock.wsu.edu/
> > > > >
> > > > >
> > > > >
> _______________________________________________
> > > > > SM-Grimoire mailing list
> > > > > SM-Grimoire AT lists.ibiblio.org
> > > > >
>
http://lists.ibiblio.org/mailman/listinfo/sm-grimoire
> > > > >
> > > > --
> > > >
> > > >
> > > > Quidquid latine dictum sit, altum sonatur.
> > > > -----------------
> > > > PGP public key at
> > > >
>
http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=get&search=0x92B5D3F1
> > > >
> > >
> > >
> > > _______________________________________________
> > > SM-Sorcery mailing list
> > > SM-Sorcery AT lists.ibiblio.org
> > >
> http://lists.ibiblio.org/mailman/listinfo/sm-sorcery
> > >
> > --
> >
> >
> > Quidquid latine dictum sit, altum sonatur.
> > -----------------
> > PGP public key at
> >
>
http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=get&search=0x92B5D3F1
> >
> --
>
>
> Quidquid latine dictum sit, altum sonatur.
> -----------------
> PGP public key at
>
http://wwwkeys.ch.pgp.net:11371/pks/lookup?op=get&search=0x92B5D3F1
>
>
=== message truncated ===
> ATTACHMENT part 1.2 application/x-bzip
name=triggers.tar.bz2
> ATTACHMENT part 2 application/pgp-signature
name=signature.asc
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
-
[SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Dufflebunk, 08/05/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Nicholas K. Jennings, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Dufflebunk, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Dufflebunk, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Jose Bernardo Silva, 08/06/2002
- Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells, Jon Svendsen, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Jose Bernardo Silva, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Dufflebunk, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Dufflebunk, 08/06/2002
- Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells, Nicholas K. Jennings, 08/06/2002
- Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells, Nicholas K. Jennings, 08/06/2002
- <Possible follow-up(s)>
- Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells, Chris Brien, 08/06/2002
-
Re: [SM-Sorcery]Re: [SM-Grimoire]Auto rebuilding dependent spells,
Nicholas K. Jennings, 08/06/2002
Archive powered by MHonArc 2.6.24.