Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 13938] Hooks support in sorcery...

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 13938] Hooks support in sorcery...
  • Date: 28 Sep 2009 10:07:04 -0000

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





--- Comment #19 from Andraž 'ruskie' Levstik <ruskie+bugs AT codemages.net>
2009-09-28 05:07:02 ---
(In reply to comment #18)
> 1. Sure they do, they're switches for functionality even in your code.
>

Well technically not my code but existing code. And I would like to get rid of
those two functions as well.

> 2. And it would be good to add _hook suffixes to all of them, so they can't
> get
> mixed up (in the functional approach).
>

Agreed

> 3. But having the calls inlined will not change variable availability,
> except
> for any clashing local vars of the deepest scope.
>

Hmmm actually a local var wouldn't be available even in the current
implementation? or am I wrong?

> 4. Spell files have no success/failure hook separation, just pre/post. What
> the
> hook does can depend on the success/failure of the previous code, so
> perhaps it
> would be good to pass the return status to it too.
>

Hmm yes makes sense. Though isn't the return code handled outside of the
run_spell_file?

> 8. I meant libhook, I didn't say hooks.
>

Ahh I see what you meant. I think that was a bad copy paste or a distraction
when I was writting it. Or maybe I was thinking of something else. Anyway most
of the doc will need to be a manpage anyway.

> 9.1. The file doesn't have to create any feature creep. Think of it as the
> default hook constructor. The sorcery one would for example call the
> $SORCERY_HOOKS/ counterpart to do any real work. That is if it is needed at
> all.
> With the function approach it would have only a hook container role, since
> the
> sorcery one would just define the 2 or 3 default sorcery hooks then source
> $SORCERY_HOOKS, which can replace, use or disable them.
> (the two functions you moved there would remain where they were before)
>

I'd remove all built-in stuff such as sound and email reports and xterm title
and make them separate spells.

> 10. First an unrelated comment: . */success won't source all the files, just
> the first that expands and the others would be treated as positional
> arguments.
> It would have to be done through a loop.
>

Hmm my mistake.

> No, it would work as well. Let me explain it in greater detail. On sorcery
> startup the sorcery libhook would be read, defining a few default real
> fallback
> hooks (like with default_sorcery_build) and the rest as noops. Then all the
> hooks under $SORCERY_HOOKS would be read. To make this nice and simple (no
> contention), each hook function would have a prefix of the filename (eg.
> dzen_post_SUCCESS_hook).
>

This could work.

> One way would be to check and use the functions per function and per bundle,
> something like:
> hlist="dzen"
> [[ -z $hlist ]] && return
> for fname in $flist; do
> f="function $fname () {"
> for i in $hlist; do
> if declare -F ${i}_$fname &>/dev/null; then
> f="$f ${i}_$fname;"
> fi
> done
> if [[ $f != "function $fname () {" ]]; then
> f="$f }"
> else
> f="$f sorcery_$fname; }" # or just include it in the hlist
> fi
> $f
> done

Still needs a check if it's +x or not and has the proper perms.

> It is pretty much more of the same that we already do.
>
> And like I said, this would be done on init, not each time. So after the
> sourcing is done, the real hook functions would be already completely
> defined
> and ready for use.
>

I actually like this idea.

> For kicks, the default sorcery post_SUCCESS_hook could reinit the hooks if a
> new one was installed, so they would work immediately in the middle of
> multispell casts. Not sure if that's a good idea though, it depends on what
> kind of hooks there'll be.
>

Erm. So basically check if there's anything new there?

> 10.1 Of course it is in the eye of the eye tyrant, but this is no excuse for
> avoiding debate and possible improvements.

I didn't see any possible improvments until you clearly defined it. I don't
take "hints" well.

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



Archive powered by MHonArc 2.6.24.

Top of Page