Sorry for answering so late
I agree the code driving info script has to be removed and I will ASAP
integrating the functionality for which it had been devised into
inspect. It takes some extra line of code to track the internal state of
mod_rivet as r->filename is defined only when request is being
processed, but it shouldn't be hard at all. We might suggest the
remapping of the ensemble method as a way to provide compatibility and
put an example in contrib.
I'd like to know from Karl and Jeff if they do extensive usage of 'info
script' in their code and if shifting to inspect could impact their
application.
-- Massimo
On 01/23/2014 06:25 PM, Damon Courtney wrote:
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
do you mean you want to keep that ugly hack in Rivet_SendContent?
If you want to remove it, I’m fine with that. Just know that it
creates an incompatibility. Now, what are the chances someone is
using [info script] in Rivet to determine the .rvt file path?
Probably slim to none seeing as [env SCRIPT_FILENAME] would be the
more common method. All that said, it’s probably easier to just
remove the hack and then stop trying to hack [info script] at all.
If you want info about your Rivet request, use ::rivet::inspect. And
then push people toward that in the docs.
we have ::rivet::inspect now (whose manual page needs further
elaboration). It's easy to place those variables in a new
dictionary returned by it.
I chose the name 'inspect' to avoid conflict with 'info'. I new
core commands were in the namespace ::tcl but I didn't know they
were an ensemble and, as a matter of fact, I didn't know of the
-map option of namespace configure either
I forgot about inspect. We should continue to enhance that command
and remove any hacks like [info script]. A whole doc page on
introspection would be nice as it would lay out exactly what you can
query from Rivet.
OK, but I don't see it as the mine field it could look like at
first. The only problem I can think of is implementing a simple and
safe way for keeping the state of of a request processing and
depending on it calling either our implementation of 'info script'
or Tcl's. The crux of the problem is that we need to run our info
script only during the execution of any script/template referenced
by the URL and call the default implementation from any other
script (ChildInitScript, BeforeScript, AfterScript, ErrorScript
etc).
The method of remapping a Tcl command would make possible to
simply extend both 'info' and 'source' provided also this one is an
ensemble method. A URL referenced file name should be stored in
the rivet_interp_globals structure and a method of ::rivet::inspect
could be used to read it. I think everything could be done within
Rivet_ExecuteAndCheck but the transition between those 3
procedures (where the state has to change in order to drive our
wrappers of 'info' and 'source') isn't marked by anything, as
scripts are simply concatenated and then executed.
I think the problem is leaning more on mod_rivet rather than Tcl.
I love that Tcl lets you override commands, including core commands.
Other language purists can argue it’s a bad thing, whatever, I’m not
interested in a debate. The problem is when you do it in a framework
like Rivet where other people are expected to build on top of your
work. Everything you rename and install your own proc over the top
of creates another level of indirection and the added performance
cost of a proc call. Which is bad, mmm’kay. ESPECIALLY if you do it
to a command like [info] that gets called thousands of times per
request.
Currently, we don’t “override” anything. We just use Tcl’s
already-provided mechanism (info script ?filename?) to set the script
name within the Rivet request. Any call to [info script] still maps
directly to the C function and costs nothing except setting the
script once when setting up the request.
I guess what I’m trying to figure out is what the hell all this is
for. Remove the hack to [info script], that’s great. Note it in the
CHANGES that we no longer do that and point them at ::rivet::inspect.
But let’s not “fix it” by adding another hack somewhere else. If we
want to extend ::rivet::inspect (which should also be an ensemble, by
the way), then extend it to have an [inspect script] command or
whatever. But let’s not fix one “hack” by hacking something else.
Trying to override the source command and/or ::tcl::info::script just
sounds like an all-around bad idea.
What do we gain for the performance loss? What’s the point? And…
who’s asking for it? Did someone get confused using [info script]
and report a bug or ask for support that I missed? If you just want
to remove the (arguable) hack, then remove the hack.
D
---------------------------------------------------------------------
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
