I just started having the same problems that Patrick was having.
The only change was recently running redhat's up2date. Any time
a host name is resolved, the server segfaults. In my case, it
was incoming connections to the nsftp module that would kill it.
Doubling the stack size seems to have
Is there a way to write the generated image directly to the
AOLServer connection without having to write it to a file first?
nsgd has this feature and it's very useful for dynamically generated
images...
Regards,
-Oscar
On Sunday, October 13, 2002, at 07:37 PM, Vlad Seryakov wrote:
Hello,
To answer my own question: this happens because
aolserver/modules/tcl/nsperm/init.tcl is being called twice during startup.
Followup question:
1. Can anyone suggest how this might happen? Point me to a description of
how the startup procedure works so I can figure out how this got in the
queue
And what's the license for such library? I couldn't find it on their
website.
It is free for Linux
In fact their website seemed comflicting to me, for in one page
it said download free version (but didn't say what it meant by free)
and in another it had a developer license ($99 for 1-4
CharDirector supports this,
i did not implement it yet in my module but i will in the next couple of days.
On Tue, Oct 15, 2002 at 08:39:16PM +, Oscar Bonilla wrote:
Is there a way to write the generated image directly to the
AOLServer connection without having to write it to a file first?
Extended ASCII characters in Tcl variables (e.g. headings and labels), for
example é (eacute, \xE9) are rendered in HTML pages and in server.log as
é, \xC3 \xA9, è as è \xC3 \xA8, etc. Same leadin A-tilde for all the
seven or so accented characters in the \xC0 - \xFF range in the page. The
same
Extended ASCII characters in Tcl variables (e.g. headings and labels), for
example é (eacute, \xE9) are rendered in HTML pages and in server.log as
é, \xC3 \xA9, è as è \xC3 \xA8, etc. Same leadin A-tilde for all the
They are being output directly as utf-8 chars, which is what Tcl
uses
+-- On Oct 15, Jeff Hobbs said:
My guess is that whatever finally outputs (to stdout?) isn't doing
the conversion correctly. Perhaps 'fconfigure stdout' will show
something not correct?
The output doesn't go to stdout. Indeed, the output doesn't go through
the Tcl channel mechanism