[hunchentoot-devel] Hunchentoot on CLISP

[Edi Weitz]

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 at 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 at weitz.de> wrote:
>>
>> On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker
>> <andrew.pennebaker at 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.
>
>