Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

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.