I can't get TBNL to stay responsive reliably on SBCL/ppc (which is a no-threads platform). Among other things, it will block in read-line (get-apache-command) when the connection from apache has gone away. Hitting Control-C interrupts the read and pushes the process back to the place where it's accepting the new connection from apache.
(Using mod_lisp2).
Does anyone have experience with this platform? Is it expected to work?
Thanks,
--Chris
Hi!
On 2005-02-05 17:24:00, chris@austin-lane.net wrote:
I can't get TBNL to stay responsive reliably on SBCL/ppc (which is a no-threads platform). Among other things, it will block in read-line
I don't think this could work without a threading SBCL. TBNL uses KMRCL for starting a listener. Which itself just calls a function when there's no threading SBCL or another Common Lisp with multi-processing:
#-(or allegro cmu lispworks sb-thread) (funcall func)
Regards, Stefan
On 2005-02-06 02:52:34, Stefan Scholl wrote:
#-(or allegro cmu lispworks sb-thread) (funcall func)
This was with KMRCL 1.77. Current version is 1.78, which seems to support openmcl:
processes.lisp: (defun make-process (name func) #+allegro (mp:process-run-function name func) #+cmu (mp:make-process func :name name) #+lispworks (mp:process-run-function name nil func) #+sb-thread (sb-thread:make-thread func) #+openmcl (ccl:process-run-function name func) #-(or allegro cmu lispworks sb-thread openmcl) (funcall func) )
"Stefan" == Stefan Scholl stesch@no-spoon.de writes:
Stefan> I don't think this could work without a threading Stefan> SBCL. TBNL uses KMRCL for starting a listener. Which Stefan> itself just calls a function when there's no threading Stefan> SBCL or another Common Lisp with multi-processing:
Stefan> #-(or allegro cmu lispworks sb-thread) (funcall Stefan> func)
Stefan,
Thanks for the answer. Any opinion on whether it would be easier to hack tbnl to use the serve-event non-threads loop or switch a TBNL script to run under Araneida (which I understand but do not know does not require threads).
I have an additional question, I am currently getting an encoding error because the input stream is :EXTERNAL-FORMAT :ASCII and the POST'ed matter is in UTF8 or Latin-1 or whatever. Anyone else see this?
--Chris
On Sun, 6 Feb 2005 09:31:47 -0500 (EST), chris@austin-lane.net wrote:
Thanks for the answer. Any opinion on whether it would be easier to hack tbnl to use the serve-event non-threads loop or switch a TBNL script to run under Araneida (which I understand but do not know does not require threads).
Hmm, no idea. You should search for an example of proper SERVE-EVENT usage (I seem to remember that Thomas Burdick posted something like that to the small-cl-sources list some time ago) and try to apply it to mod_lisp. I don't know enough of Araneida to answer the other half of the question.
I'd be happy to accept clean patches to enable TBNL to use SERVE-EVENT.
I have an additional question, I am currently getting an encoding error because the input stream is :EXTERNAL-FORMAT :ASCII and the POST'ed matter is in UTF8 or Latin-1 or whatever. Anyone else see this?
You're talking about the data coming from the browser? That's strange. Do you have a simple example to reproduce that behaviour?
Cheers, Edi.
"Edi" == Edi Weitz edi@agharta.de writes:
Edi> I'd be happy to accept clean patches to enable TBNL to use Edi> SERVE-EVENT.
So clean patches are my current goal :)
>> I have an additional question, I am currently getting an >> encoding error because the input stream is :EXTERNAL-FORMAT >> :ASCII and the POST'ed matter is in UTF8 or Latin-1 or >> whatever. Anyone else see this?
Edi> You're talking about the data coming from the browser? Edi> That's strange. Do you have a simple example to reproduce Edi> that behaviour?
I stopped this by setting the LC_ALL locale to en_US.UTF-8 before starting lisp, and adding an explicit chartset=UTF-8 to the webpages. My previous locale, Posix, caused lisp to use ASCII as the default :EXTERNAL-FORMAT (which caused it to reject chars > 127).
thanks,
--Chris
On Tue, 8 Feb 2005 06:03:11 -0500 (EST), chris@austin-lane.net wrote:
So clean patches are my current goal :)
Good... :)
I stopped this by setting the LC_ALL locale to en_US.UTF-8 before starting lisp, and adding an explicit chartset=UTF-8 to the webpages. My previous locale, Posix, caused lisp to use ASCII as the default :EXTERNAL-FORMAT (which caused it to reject chars > 127).
OK. This is the SBCL Unicode branch, right? Can it change the external format of a stream on the fly like CLISP and (I think) AllegroCL?
Cheers, Edi.
"Edi" == Edi Weitz edi@agharta.de writes:
Edi> OK. This is the SBCL Unicode branch, right? Can it change Edi> the external format of a stream on the fly like CLISP and (I Edi> think) AllegroCL?
According to #lisp, no (and that is recognized as a limitation).
--Chris
-
chris＠austin-lane.net -
Edi Weitz -
Stefan Scholl