I missed the beginning on this conversation (too much email while
I was away), but here are my relevant comments to the last message:
During my lunch break, I wrote a small program to
compare the execution of Tcl_StringMatch() (what
ns_register_filter uses to match URLs) and
My aolserver returns an error when I do e. g. a [expr 12.0 + 1].
[expr 12 + 1] works fine. The log says: syntax error in expression 12.0 +
1. It seems that it can't handle floats anymore. As soon as there is a
decimal it returns the error.
As you are somewhere in Europe, you can get
In any case, I did want to mention that since 8.2 Tcl has had stacked
channels in the core. Extensions like Trf, memchan and TLS use this
to do compression and/or encryption on channels transparent to the
user.
I create a new channel type in tclcmds.c in the nsopenssl module to
allow
...
Thinking about it I think it is reasonably secure, the only command that I
don't know how to deal with so far is info, as it is called with info
procs, info body (...) in namespace.tcl and I need the info exists
part by myself.
You can override any command you want, or have the
Is it a bad idea, maybe before use on the production system, to let
AOLserver
create the file, byte compile the procs, adding load libtbcload... and
sourcing this file instead of running through the process every time?
procomp/tbcload is designed for obfuscation, not speed. It will
not speed
The 3.5 work is a branch based on the 3.4.2 version. The idea was to
release an interim version which was essentially identical to 3.4.2,
but had all of the Tcl changes removed in favor off Tcl 8.4. It was
released to help those, like ourselves, who are interested in more
easily migrating
Just curious, 'file tail' did not work for you? I thought it worked
cross platform...
It would if the backslashes were converted to forward slashes. (It ought
to work with backslashes under Windows.)
% set tcl_platform(os)
Linux
% file tail {c:\windows\foo.bar}
c:\windows\foo.bar
%
The Tcl 8.4 version was a bit faster, but it also crashed a couple times.
I didn't investigate further as to why. The Tcl 8.4 version was using the
default generic/tclAlloc.c shipped _with Tcl_ (not the AOLserver one).
Tcl 8.4 was _not_ compiled with --enable-threads (a configure flag that
On Tuesday 23 April 2002 08:00, you wrote:
I have finally commited the improved memory allocator from the AOLServer
Tcl mods to the 8.4 branch.
...
This may also be the point to reconsider improving the
AOLserver's way of dealing with Tcl-only extensions and
copyiny command-sets
...
* If I recall, you can load it in a tcl script by doing
ns_eval [list load /path/to/file.so]
one time, and it will exist in all interpreters. Of course, you'll
probably want to wrap this up so that it doesn't get loaded every time.
FWIW, Tcl's load command actually caches
Thomas,
The Tcl sources require a minor change before you can have it work with
AOLServer. The guys at AOL developed a special allocator designed for
much better performance with threads. I do plan on putting this into
the core (now that license issues are resolved), but it needs a bit more
...
If each part of a multi-part form had a Content-Length, there would be no
reason to parse for the boundary strings. There would, in fact, be little
need for boundary strings at all. I'm not entirely clear on why it was
done with boundaries instead of lengths in the first place.
12 matches
Mail list logo
