Then back away slowly and come up with a new plan. I would suggest that for now we leave the [info script] behavior alone. It doesn’t hurt anyone that I can see, and it would break compatibility right now. As near as I can tell from the docs, it’s never even mentioned that we do that, and we certainly don’t define its behavior for including or sourcing files.
My other suggestion would be to add our own info command or something like it to dig into the internals of Rivet when necessary. We currently have the ::server() array that we populate with some configuration variables. Those could be moved to a new introspection command as well. Tcl is known for its introspection. There’s no reason we shouldn’t also provide some hooks to give insight on what Rivet is doing. We’ve faked around it for years now, let’s just make it official. And stop messing with Tcl internals. :) D On Jan 22, 2014, at 4:08 PM, Massimo Manghi <[email protected]> wrote: > 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 <[email protected]> >> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
