In think there is more to fix about the way 'info script' is handled in
Rivet.
1) when called from a template parsed by another template I maintain the
usual Tcl way to respond is expected and the sub-template name be
returned. Currently the toplevel template name is returned. This
requires also Rivet_Parse and Rivet_ParseExec to handle the current file
name and store it coherently somewhere in the local scope and in
rivet_interp_globals.
2) to be consistent with the standard behaviour a file name should not
be always returned as full path. The mechanism at point 1 should be OK
as the file name passed as argument by the caller will in case be returned.
3) mod_rivet.c chdirs to a (toplevel) template directory at every
request. For the same reason explained at point 2 the simple file name
should be returned, but I can't exactly quantify the impact on existing
software and therefore I'm not very sure about is to be done.
4) As the code in mod_rivet changes globally the way [info script]
works, also the 'source' command should be remapped to a rivet's new
source command that should work like described above
it's getting trickier than expected...
-- Massimo
On 01/20/2014 06:29 PM, Damon Courtney wrote:
Ugh. Don’t do that at all. Overriding Tcl’s [info] command (or any
core commands) by renaming and replacing is a path to doom.
The good news is that we no longer have to. As of 8.5.something,
[info] is a namespace ensemble command. I do think it’s worthwhile
to make [info script] do the right thing, so you have two ways of
doing it.
Option 1
proc ::tcl::info::script {{filename “”}} { return [::rivet::env
SCRIPT_FILENAME] }
This replaces Tcl’s call for the [info script] command with a proc of
our own making that just returns our script no matter what while
maintaining the same call structure for compatibility. But it
overwrites a Tcl core function, even if it is buried behind an
ensemble.
Option 2
proc ::rivet::InfoScript {{filename “”}} { return [::rivet::env
SCRIPT_FILENAME] }
set map [namespace ensemble configure ::info -map] dict set map
script ::rivet::InfoScript namespace ensemble configure ::info -map
$map
Option 2 obviously has a few more steps, but is probably more
correct. Anyone looking at the ensemble can immediately tell we’ve
overridden the script command. They can also still reach the
original [info script] command by calling ::tcl::info::script if they
want. It actually does more than just tell you the startup script.
:)
Damon
On Jan 20, 2014, at 3:39 AM, Massimo Manghi <massimo.man...@unipr.it>
wrote:
Hi
I'm wondering if actually is worth keeping these lines of code in
Rivet_SendContent
Tcl_Obj *infoscript = Tcl_NewStringObj("info script ", -1);
Tcl_IncrRefCount(infoscript); Tcl_AppendToObj(infoscript,
r->filename, -1); Tcl_EvalObjEx(interp, infoscript,
TCL_EVAL_DIRECT); Tcl_DecrRefCount(infoscript);
the purpose of running this Tcl fragment is to coax 'info script'
to return the full path to the current script. Notice that this
code is unconditionally run on every request handled by
mod_rivet.c. Not a big deal in terms of performance, but we could
save some time at every request if we approach the problem in a
different way (and in any case it's not a good design to have code
computing something that could never be used when this same
information can be obtained by other means and only on demand)
My proposal is to rename Tcl's info command in Rivet:init (to a
different namespace?) and provide our own 'info' command which will
fall back to the default in every case except when the command call
reads exactly 'info script'. In this case the string returned by
[::rivet::env SCRIPT_FILENAME]
would be returned or the same information could be fetched from
request_rec by a new specific command (the presence of a specific
environment variable is configuration dependent, I still have to
understand whether SCRIPT_FILENAME is guaranteed to exist)
-- -- Massimo Manghi
Dipartimento di Neuroscienze Unità di Biofisica e Fisica Medica via
Volturno 39 43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
