You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@tcl.apache.org by Michael Link <ml...@apache.org> on 2001/03/09 19:46:47 UTC
development release 4
I have checked in 1.0d4 of mod_tcl which includes several new
features. The majority of the API has been exported, this includes Apache
functions as well as the ability to read and write variables/structures
from the request_rec structure. Some more hooks have been exported as
well, see the BUGS section of the README for which ones work and which
ones don't. Documentation is now included in the README as well, which
defines what the configuration directives are, the hooks that can be used
as well as the apache functions.
Kind of a general road map I have planned is:
1. Deal with the BUGS
2. Research on exporting non-standard hooks
3. Research on exporting filter definitions...
4. Add list of variables that can be read/written via r/r_set in
documentation
checkout via
cvs -d:pserver:anoncvs@www.apache.org:/home/cvspublic checkout tcl-modtcl
--
Mike
Re: development release 4
Posted by Michael Link <ml...@apache.org>.
I'll build something for shared objects. Getting around using autoconf
etc in Apache 2.0 would be difficult since the entire package uses it for
configuration...... The auto* utils are actually really easy to use, its
libtool that is a bit wonkey.
--
mike
On 13 Mar 2001, David N. Welton wrote:
>
> Another thing:
>
> % tar -zxf mod_tcl.tar.gz
> % mv mod_tcl apache_2.0a9/modules/.
> % cd apache_2.0a9
> % autoconf
> % autoheader
> % ./configure
> % make
>
> I am not very knowledgable about auto* (I despise them, actually), but
> one thing that would be really useful would be a way to build mod_tcl
> as a .so outside of the Apache source tree.
>
mod_tcl 1.0d7 released...
Posted by Michael Link <ml...@apache.org>.
Changes in 1.0d7
--------------------------------------------------------------------------------
- Migration to Apache 2.0.16
- I now know how to implement problem hooks
Changes in 1.0d7pre
--------------------------------------------------------------------------------
- Fixed <Tcl>...</Tcl>, these should be placed outside of
<Directory>/<Location> directives. Everything in <Tcl>...</Tcl> is added
to a global variable and then made local to the namespace of the file,
this is due to several problems with handling configuration, mainly that
exection would either result in a "this directive doesn't belong here" or
a problem with the configuration not being built yet as in an
EXEC_ON_READ.
- Fixed a bug in ap_create_environment.
- Fixed a bug with writing <Tcl>...</Tcl> logic to the local namespace
[2001032300]
Changes in 1.0d6
--------------------------------------------------------------------------------
- ap_send_http_header no longer does anything so the command just returns
TCL_OK which essentially makes it null, I'll probably get rid of it later.
- made changes in league with Apache 2.0.14. Handlers were moved around
etc.
Changes in 1.0d5
--------------------------------------------------------------------------------
- Configuration checks for mmap() and will use malloc(),read(),free() in
that order to replace mmap() procedures.
- Constants and commands are now placed in the ::apache namespace, so you
must import that namespace into your scripts.
- A test script is included with the distribution for testing and example
purposes. test_script.tm
TODO
--------------------------------------------------------------------------------
1. Add configuration documentation to README, add documentation regarding
`r' and `r_set' commands.
DONE 2. Possible addition of option to build shared object
(.so) library. (It appears Apache 2.0 has a configuration directive for
this --enable-shared, but it appears to be not implemented yet...).
3. A couple of hooks are broken (Apache bug?) the DECLINE causes the
server to exit on signal 11 (SEGV).
4. Add non-standard hooks?
5. Add filters?
6. libapreq (doesn't appear to be ported to 2.0 completley yet...)
7. Decide what goals need to be acheived for release 1.0
8. Make necessary changes along with Apache 2.0 revisions.
9. Look into TCL threads. A preliminary investigation to enabling TCL
threads caused SEGVs randomly...?
Map
--------------------------------------------------------------------------------
- 1.0d0 -| Inital port from mod_tcl* 0.26, single file split into 4
| (Apache 2.0a9)
|
- 1.0d1 -| removal of nasties, update of configuration
|
- 1.0d2 -| addition of some API commands
|
- 1.0d3 -| more of API exposed, new config option, inital checkin to CVS
|
- 1.0d4 -| Documentation, 90% of API exposed
|
- 1.0d5 -| constants commands in ::apache namespace, mmap checking, test
| script
|
- 1.0d6 -| ap_send_http_header deprecated, updated to be peachy with
| Apache 2.0.14
|
% 1.0d7 %| migration to Apache 2.0.16, fixed bugs
|
- 1.0d8 -|
|
- 1.0d9 -|
|
- 1.0.0 -|
Re: development release 4
Posted by "David N. Welton" <da...@apache.org>.
Another thing:
% tar -zxf mod_tcl.tar.gz
% mv mod_tcl apache_2.0a9/modules/.
% cd apache_2.0a9
% autoconf
% autoheader
% ./configure
% make
I am not very knowledgable about auto* (I despise them, actually), but
one thing that would be really useful would be a way to build mod_tcl
as a .so outside of the Apache source tree.
--
David N. Welton
Personal: http://www.efn.org/~davidw/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org
Re: development release 4
Posted by "David N. Welton" <da...@innominate.it>.
Michael Link <ml...@apache.org> writes:
> I do this all the time, as long as you clean it up everything is
> fine. Otherwise apache can bloat to a large footprint size. I'm
> getting a segfault in ap_cfg_getline(), not sure why yet.
Because the config_file is NULL. EXEC_ON_READ seems to fix it for me.
--
David N. Welton
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Work: http://www.innominate.com/
Re: development release 4
Posted by Michael Link <ml...@apache.org>.
On 18 Mar 2001, David N. Welton wrote:
> davidw@apache.org (David N. Welton) writes:
>
> > I haven't looked at it in detail yet, and haven't tried running
> > things, either, but could you explain a bit about your thoughts
> > behind the execution model? It runs a file in a namespace using the
> > filename itself for the namespace name?
>
> I've been looking over the "<Tcl> ... </Tcl>" code, and it isn't
> entirely clear.
>
> I think mixing malloc + apache memory stuff is probably not a good
> idea. It's segfaulting on me...
I do this all the time, as long as you clean it up everything is
fine. Otherwise apache can bloat to a large footprint size. I'm getting
a segfault in ap_cfg_getline(), not sure why yet.
>
> static const char *tcl_raw_args(cmd_parms *parms, void *mconfig, char *arg)
> {
> tcl_config_rec *tclr = (tcl_config_rec*) mconfig;
> char l[MAX_STRING_LEN];
> char *script = NULL, **xx;
>
> tclr->raw_list = apr_array_make(parms->pool, 0, sizeof(char *));
>
> while (!(ap_cfg_getline(l, MAX_STRING_LEN, parms->config_file))) {
> if (!strncasecmp(l, "</Tcl>", 6)) {
> goto cleanup;
> }
> script = apr_pstrcat(parms->pool, script, "\n", l, NULL);
> }
>
> cleanup:
>
> xx = (char **)apr_array_push(tclr->raw_list);
> *xx = script;
> return NULL;
> }
>
> Would something like this be simpler? The first array_make shouldn't
> be there, but without it, I seem to be getting the raw_list
> uninitialized, probably because I also switched the command to:
>
> AP_INIT_RAW_ARGS("<Tcl>", (fz_t) tcl_raw_args, NULL, RSRC_CONF|EXEC_ON_READ, "add raw tcl to the interpreter." ),
> AP_INIT_NO_ARGS("</Tcl>", (fz_t) tcl_no_args, NULL, RSRC_CONF, "end of tcl section." ),
>
> But I'm out of time for now to track this down...
>
> --
> David N. Welton
> Free Software: http://people.debian.org/~davidw/
> Apache Tcl: http://tcl.apache.org/
> Personal: http://www.efn.org/~davidw/
> Work: http://www.innominate.com/
>
Re: development release 4
Posted by "David N. Welton" <da...@apache.org>.
davidw@apache.org (David N. Welton) writes:
> I haven't looked at it in detail yet, and haven't tried running
> things, either, but could you explain a bit about your thoughts
> behind the execution model? It runs a file in a namespace using the
> filename itself for the namespace name?
I've been looking over the "<Tcl> ... </Tcl>" code, and it isn't
entirely clear.
I think mixing malloc + apache memory stuff is probably not a good
idea. It's segfaulting on me...
static const char *tcl_raw_args(cmd_parms *parms, void *mconfig, char *arg)
{
tcl_config_rec *tclr = (tcl_config_rec*) mconfig;
char l[MAX_STRING_LEN];
char *script = NULL, **xx;
tclr->raw_list = apr_array_make(parms->pool, 0, sizeof(char *));
while (!(ap_cfg_getline(l, MAX_STRING_LEN, parms->config_file))) {
if (!strncasecmp(l, "</Tcl>", 6)) {
goto cleanup;
}
script = apr_pstrcat(parms->pool, script, "\n", l, NULL);
}
cleanup:
xx = (char **)apr_array_push(tclr->raw_list);
*xx = script;
return NULL;
}
Would something like this be simpler? The first array_make shouldn't
be there, but without it, I seem to be getting the raw_list
uninitialized, probably because I also switched the command to:
AP_INIT_RAW_ARGS("<Tcl>", (fz_t) tcl_raw_args, NULL, RSRC_CONF|EXEC_ON_READ, "add raw tcl to the interpreter." ),
AP_INIT_NO_ARGS("</Tcl>", (fz_t) tcl_no_args, NULL, RSRC_CONF, "end of tcl section." ),
But I'm out of time for now to track this down...
--
David N. Welton
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Work: http://www.innominate.com/
Re: development release 4
Posted by Michael Link <ml...@apache.org>.
On 17 Mar 2001, David N. Welton wrote:
> Michael Link <ml...@apache.org> writes:
>
> > > Tcl_CreateObjCommand(interp, "r", cmd_r, NULL, NULL);
>
> > > 'request_rec' might be more descriptive. Is there a problem with
> > > putting all these commands in a namespace of their own, like
> > > 'Apache::' (to borrow something from the perl folks)?
>
> > hmm, I suppose I could do this, I thought mod_perl also used a
> > convention like `r'?
>
> Leggibility isn't always that important for the perl folks, either;-)
>
> If it were used with the namespace, ::apache::r, it would be easy to
> pick out, but I worry about grepping through code trying to find an
> 'r' somewhere (if it has been imported, for instance, into the current
> namespace).
it is in ::apache::r but your right, the first thing I did was import
::apache
>
> > The reason I used r is because it is customary for the request_rec
> > variable passed to handlers to be called r. So if your writing
> > modules you always see statements like this `r->server_name'. I
> > thought it would be an easier transfer of knowledge if someone knew
> > how to deal with C modules.
>
> This makes sense... but more so for the command names, I think.
hmm, how about I offer the option to use request_rec or r?
>
> > This is the same thought applied to the command names for the
> > functions, they are all synonomous with the apache function name
> > ap_*. Let me know what you think. As far as putting them in a
> > namespace, I don't see why this can't be done.
>
> Another thing...
>
> I haven't looked at it in detail yet, and haven't tried running
> things, either, but could you explain a bit about your thoughts behind
> the execution model? It runs a file in a namespace using the filename
> itself for the namespace name?
Here is what happens.
0. The server starts up, the interp is initialized etc.
1. A request for file /index.tm is requested. The file is looked up to
see if it is already in the interp. If the file is not there (or the
modification date has changed) the file is loaded into the interp as a
script (since everything should be a proc). The file is loaded into a
namespace with the name of the file. This is done because someone usually
has a general config directive like this
Tcl_ContentHandler content_handler
which tells us that the proc we want to call for a content handler is
named content_handler. If you have more than 1 file then you will need to
use the name content_handler for all the files in that directory. Loading
all these files into the global namespace will overwrite each others
content_handler procedure with the last one read in. It could also
rewrite other use defined functions... To avoid this every file is loaded
into its own namespace.
2. The handler/hook is called, DECLINEd if not defined...
Also pre Apache 2.0 I was defining variables like env and pram (form read
data) into the global namespace. In 2.0 I have changed this so that env
and pram are read into the namespace of the current file being requested
because its possible that 2 simultaneous requests are made and if we were
reading and writing global data that would be a problem, global should be
protected with threads. Now I have no idea if its possible for Apache 2.0
to exec 2 handlers at the same time, I haven't checked into this yet, and
I was assuming that it syncronized them itself, but thats a poor
assumption on my part, and its on my list to check. Also I'm not sure
what the concurrency of Apache 2.0 is set to either, its possible that
they have it set so only 1 thread is active at 1 time, but this would be
ineffecient, so I doubt it.
--
>
> Any thoughts about generalizing this out even further?
>
> Thanks,
> --
> David N. Welton
> Free Software: http://people.debian.org/~davidw/
> Apache Tcl: http://tcl.apache.org/
> Personal: http://www.efn.org/~davidw/
> Work: http://www.innominate.com/
>
Re: development release 4
Posted by "David N. Welton" <da...@apache.org>.
Michael Link <ml...@apache.org> writes:
> > Tcl_CreateObjCommand(interp, "r", cmd_r, NULL, NULL);
> > 'request_rec' might be more descriptive. Is there a problem with
> > putting all these commands in a namespace of their own, like
> > 'Apache::' (to borrow something from the perl folks)?
> hmm, I suppose I could do this, I thought mod_perl also used a
> convention like `r'?
Leggibility isn't always that important for the perl folks, either;-)
If it were used with the namespace, ::apache::r, it would be easy to
pick out, but I worry about grepping through code trying to find an
'r' somewhere (if it has been imported, for instance, into the current
namespace).
> The reason I used r is because it is customary for the request_rec
> variable passed to handlers to be called r. So if your writing
> modules you always see statements like this `r->server_name'. I
> thought it would be an easier transfer of knowledge if someone knew
> how to deal with C modules.
This makes sense... but more so for the command names, I think.
> This is the same thought applied to the command names for the
> functions, they are all synonomous with the apache function name
> ap_*. Let me know what you think. As far as putting them in a
> namespace, I don't see why this can't be done.
Another thing...
I haven't looked at it in detail yet, and haven't tried running
things, either, but could you explain a bit about your thoughts behind
the execution model? It runs a file in a namespace using the filename
itself for the namespace name?
Any thoughts about generalizing this out even further?
Thanks,
--
David N. Welton
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
Work: http://www.innominate.com/
Re: development release 4
Posted by Michael Link <ml...@apache.org>.
On 13 Mar 2001, David N. Welton wrote:
> Looks good!
>
> A couple of things I have noticed, after a (quick) look at the code:
>
> mmap
>
> How portable is it? Does it work on Windows? I don't know, as I
> don't use Windows myself, but there are a fair amount of people who
> seem to be interested in Apache+Tcl+Windows.
I have heard that mmap is portable to Windows. It would be trivial to
write an #ifdef for it though so that a malloc(),read(),free() could be
used instead if mmap does not exist on a system... (actually I've already
done this).
>
> blocks like
>
> {
> ....
> }
>
> I'm not sure this is ok with all compilers. A friend says the best
> way to do that, portably and efficiently, is
>
> do {
> .......
> } while (0);
well the do while is how I see preprocessor macros defined so that people
can use a ; as a statement. The { } is really just a complex statement
not at all different from a complex statement following an
if,else,while,for etc... If this convention doesn't work on a compiler
I'd be really interested in seeing it.
>
> I see
>
> if ((fd = open(r->filename, O_RDONLY, 0)) == -1) {
> ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r->server, "open(%s, ...): %s", r->filename, strerror(errno));
>
> return HTTP_NOT_FOUND;
> }
>
> mptr = mmap((caddr_t) 0, r->finfo.size, PROT_READ, MAP_SHARED, fd, 0);
> bptr = (char*) malloc(r->finfo.size + flen + 21);
>
> memcpy(bptr, "namespace eval ", 15); pos += 15;
> memcpy(bptr + pos, r->filename, flen); pos += flen;
> memcpy(bptr + pos, " {\n", 3); pos += 3;
> memcpy(bptr + pos, mptr, r->finfo.size); pos += r->finfo.size;
> memcpy(bptr + pos, "\n}\0", 3);
>
> munmap((char*) mptr, r->finfo.size);
> close(fd);
>
> in several places. Is it worth making a function out of it?
naw, it can just remain inline. It is only 3 segments, 1 for loading, 1
for reloading if the file was updated, and 1 for the raw TCL that can be
input in the config file.
>
> Tcl_CreateObjCommand(interp, "r", cmd_r, NULL, NULL);
>
> 'request_rec' might be more descriptive. Is there a problem with
> putting all these commands in a namespace of their own, like
> 'Apache::' (to borrow something from the perl folks)?
>
hmm, I suppose I could do this, I thought mod_perl also used a convention
like `r'? The reason I used r is because it is customary for the
request_rec variable passed to handlers to be called r. So if your
writing modules you always see statements like this `r->server_name'. I
thought it would be an easier transfer of knowledge if someone knew how to
deal with C modules. This is the same thought applied to the command
names for the functions, they are all synonomous with the apache function
name ap_*. Let me know what you think. As far as putting them in a
namespace, I don't see why this can't be done.
> Thanks for all the work! Soon I'll try 'porting' dtcl to it to see how
> it runs, and how fast it runs.
>
> BTW, you don't have access to tcl.apache.org yet, do you? Let me know
> when you are ready to post some stuff to the web, and I can set you up
> with that, to
Ok, cool beans :)
--
Mike
Re: development release 4
Posted by "David N. Welton" <da...@apache.org>.
Michael Link <ml...@apache.org> writes:
> Kind of a general road map I have planned is:
> 1. Deal with the BUGS
> 2. Research on exporting non-standard hooks
> 3. Research on exporting filter definitions...
> 4. Add list of variables that can be read/written via r/r_set in
> documentation
>
> checkout via
>
> cvs -d:pserver:anoncvs@www.apache.org:/home/cvspublic checkout tcl-modtcl
Looks good!
A couple of things I have noticed, after a (quick) look at the code:
mmap
How portable is it? Does it work on Windows? I don't know, as I
don't use Windows myself, but there are a fair amount of people who
seem to be interested in Apache+Tcl+Windows.
blocks like
{
....
}
I'm not sure this is ok with all compilers. A friend says the best
way to do that, portably and efficiently, is
do {
.......
} while (0);
I see
if ((fd = open(r->filename, O_RDONLY, 0)) == -1) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r->server, "open(%s, ...): %s", r->filename, strerror(errno));
return HTTP_NOT_FOUND;
}
mptr = mmap((caddr_t) 0, r->finfo.size, PROT_READ, MAP_SHARED, fd, 0);
bptr = (char*) malloc(r->finfo.size + flen + 21);
memcpy(bptr, "namespace eval ", 15); pos += 15;
memcpy(bptr + pos, r->filename, flen); pos += flen;
memcpy(bptr + pos, " {\n", 3); pos += 3;
memcpy(bptr + pos, mptr, r->finfo.size); pos += r->finfo.size;
memcpy(bptr + pos, "\n}\0", 3);
munmap((char*) mptr, r->finfo.size);
close(fd);
in several places. Is it worth making a function out of it?
Tcl_CreateObjCommand(interp, "r", cmd_r, NULL, NULL);
'request_rec' might be more descriptive. Is there a problem with
putting all these commands in a namespace of their own, like
'Apache::' (to borrow something from the perl folks)?
Thanks for all the work! Soon I'll try 'porting' dtcl to it to see how
it runs, and how fast it runs.
BTW, you don't have access to tcl.apache.org yet, do you? Let me know
when you are ready to post some stuff to the web, and I can set you up
with that, too.
--
David N. Welton
Personal: http://www.efn.org/~davidw/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org