[hunchentoot-devel] Hunchentoot on CLISP
The "New York version" (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) creates a stalling web server, never loading, never error'ing. When I remove the code :ready-only t from line 377: (when (usocket:wait-for-input listener :timeout +new-connection-wait-time+) The New York version works fine. Specs: - Hunchentoot 1.1.1 - Quicklisp - CLISP - Mac OS X
On Mon, Feb 28, 2011 at 4:19 AM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
The "New York version" (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) creates a stalling web server, never loading, never error'ing. When I remove the code :ready-only t from line 377: (when (usocket:wait-for-input listener :timeout +new-connection-wait-time+) The New York version works fine. Specs:
Hunchentoot 1.1.1 Quicklisp CLISP Mac OS X
This sounds like a bug in CLISP or usocket. Usocket guys, do you know something about READY-ONLY on CLISP? -Hans
That's interesting. We ran into a problem here which I had to fix by changing the default value of the read-only keyword parameter of wait-for-input from nil to t. I got some explanation of wait-for-input from Erik Huelsmann, who designed this stuff. I sent him back some suggestions and questions, but I don't think I got an answer. The real question is whether Hunchentoot is interacting properly with usocket. I haven't checked to see whether we are currently using the very latest usocket library here. Andrew Pennebaker wrote:
The "New York version" (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
creates a stalling web server, never loading, never error'ing.
When I remove the code :ready-only t from line 377:
(when (usocket:wait-for-input listener :timeout +new-connection-wait-time+)
The New York version works fine.
Specs:
* Hunchentoot 1.1.1 * Quicklisp * CLISP * Mac OS X
------------------------------------------------------------------------
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I finally got the New York version to work, but only with Lispbox CCL<http://common-lisp.net/project/lispbox/>. Any other flavor of Common Lisp gives me trouble. On Mon, Feb 28, 2011 at 2:11 PM, Daniel Weinreb <dlw@itasoftware.com> wrote:
That's interesting. We ran into a problem here which I had to fix by changing the default value of the read-only keyword parameter of wait-for-input from nil to t.
I got some explanation of wait-for-input from Erik Huelsmann, who designed this stuff. I sent him back some suggestions and questions, but I don't think I got an answer. The real question is whether Hunchentoot is interacting properly with usocket.
I haven't checked to see whether we are currently using the very latest usocket library here.
Andrew Pennebaker wrote:
The "New York version" (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
creates a stalling web server, never loading, never error'ing.
When I remove the code :ready-only t from line 377:
(when (usocket:wait-for-input listener :timeout +new-connection-wait-time+)
The New York version works fine.
Specs:
- Hunchentoot 1.1.1 - Quicklisp - CLISP - Mac OS X
------------------------------
_______________________________________________ tbnl-devel site listtbnl-devel@common-lisp.nethttp://common-lisp.net/mailman/listinfo/tbnl-devel
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I finally got the New York version to work, but only with Lispbox CCL. Any other flavor of Common Lisp gives me trouble.
What exactly does "any other flavor" mean? Which ones did you try on which platforms?
Folks, please note that the API change which caused the problem reported here is not yet in the released version of Hunchentoot, but only in the trunk version. The released version of Hunchentoot does work as expected, including the simple example that is in the documentation. -Hans On Mon, Feb 28, 2011 at 10:16 PM, Edi Weitz <edi@weitz.de> wrote:
On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I finally got the New York version to work, but only with Lispbox CCL. Any other flavor of Common Lisp gives me trouble.
What exactly does "any other flavor" mean? Which ones did you try on which platforms?
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support. On Mon, Feb 28, 2011 at 4:16 PM, Edi Weitz <edi@weitz.de> wrote:
On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I finally got the New York version to work, but only with Lispbox CCL. Any other flavor of Common Lisp gives me trouble.
What exactly does "any other flavor" mean? Which ones did you try on which platforms?
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support.
That should not happen. Can you check the values of bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they correct? If so, the default taskmaster should be one-thread-per-connection-manager which doesn't need threads.
I've checked a bunch of implementations now. bt:*supports-threads-p* and tbnl::*supports-threads-p* are T for the implementations that work well with Hunchentoot. Typically both variables are NIL due to the underlying implementation lacking thread support: Success - Lispbox CCL on Ubuntu/Xen - Lispbox CCL on Mac OS X - MacPorts CCL on Mac OS X - Aptitude SBCL on Ubuntu/VMware - MacPorts SBCL on Mac OS X Partial Failure - Aptitude CLISP on Ubuntu/Xen (no threads; Hunchentoot server and command hang) - Fink CLISP on Mac OS X (no threads; Hunchentoot works with slight modification) Failure - Aptitude SBCL on Ubuntu/Xen (SBCL compilation fails) - MacPorts CLISP on Mac OS X (CFFI and threads missing) - Aptitude CCL on Ubuntu (no package named CCL) - ECL on Ubuntu/Xen (ECL compilation failure) - MacPorts ECL on Mac OS X (flexi-streams compilation failure) - ABCL on Ubuntu/Xen (Bordeaux Threads compilation failure) - MacPorts ABCL on Mac OS X (Quicklisp compilation failure) - GCL on Ubuntu/Xen (Quicklisp compilation failure) Cheers, Andrew Pennebaker www.yellosoft.us On Tue, Mar 1, 2011 at 9:08 AM, Edi Weitz <edi@weitz.de> wrote:
On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support.
That should not happen. Can you check the values of bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they correct? If so, the default taskmaster should be one-thread-per-connection-manager which doesn't need threads.
Thanks for the detailed survey. Most of these combinations I don't have access to, though. If you think there are errors or missing features in Hunchentoot which are the cause for some of these failures, please send patches. http://weitz.de/patches.html Cheers, Edi. On Thu, Mar 3, 2011 at 3:02 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I've checked a bunch of implementations now. bt:*supports-threads-p* and tbnl::*supports-threads-p* are T for the implementations that work well with Hunchentoot. Typically both variables are NIL due to the underlying implementation lacking thread support: Success
Lispbox CCL on Ubuntu/Xen Lispbox CCL on Mac OS X MacPorts CCL on Mac OS X Aptitude SBCL on Ubuntu/VMware MacPorts SBCL on Mac OS X
Partial Failure
Aptitude CLISP on Ubuntu/Xen (no threads; Hunchentoot server and command hang) Fink CLISP on Mac OS X (no threads; Hunchentoot works with slight modification)
Failure
Aptitude SBCL on Ubuntu/Xen (SBCL compilation fails) MacPorts CLISP on Mac OS X (CFFI and threads missing) Aptitude CCL on Ubuntu (no package named CCL) ECL on Ubuntu/Xen (ECL compilation failure) MacPorts ECL on Mac OS X (flexi-streams compilation failure) ABCL on Ubuntu/Xen (Bordeaux Threads compilation failure) MacPorts ABCL on Mac OS X (Quicklisp compilation failure) GCL on Ubuntu/Xen (Quicklisp compilation failure)
Cheers, Andrew Pennebaker www.yellosoft.us
On Tue, Mar 1, 2011 at 9:08 AM, Edi Weitz <edi@weitz.de> wrote:
On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support.
That should not happen. Can you check the values of bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they correct? If so, the default taskmaster should be one-thread-per-connection-manager which doesn't need threads.
In particular, Hunchentoot fails to compile in MacPorts ECL. (ql:quickload "hunchentoot") ... ;;; Note: ;;; Invoking external command: ;;; /usr/bin/gcc-4.2 -o /Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.fas -L/opt/local/lib/ /private/var/folders/N-/N-IxaaKuFae5ik1WKxV6wE+++TI/-Tmp-/eclinits0Tu3w.o /Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.o -bundle -L/opt/local/lib -arch x86_64 -L/opt/local/lib -arch x86_64 -lecl -lgmp -lm In function COERCE, the value of variable is 65533 which is not of expected type (INTEGER -128 127) On Mon, Feb 28, 2011 at 4:16 PM, Edi Weitz <edi@weitz.de> wrote:
On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
I finally got the New York version to work, but only with Lispbox CCL. Any other flavor of Common Lisp gives me trouble.
What exactly does "any other flavor" mean? Which ones did you try on which platforms?
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (4)
-
Andrew Pennebaker -
Daniel Weinreb -
Edi Weitz -
Hans Hübner