From edi at agharta.de  Fri Feb  1 18:01:35 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 01 Feb 2008 19:01:35 +0100
Subject: [hunchentoot-devel] hunchentoot CGI?
In-Reply-To: <68F0856D-F98F-4588-AA28-227398295248@bobobeach.com> (Cyrus
	Harmon's message of "Thu, 31 Jan 2008 14:08:02 -0800")
References: <68F0856D-F98F-4588-AA28-227398295248@bobobeach.com>
Message-ID: <uprvgtv28.fsf@agharta.de>

On Thu, 31 Jan 2008 14:08:02 -0800, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> This may seem counterproductive but has anyone used Hunchentoot for
> running CGI scripts?

Not me.  Are you trying to win some strange bet or is this a first
attempt at integrating Arc with Hunchentoot?

:)

> It seems like this should be pretty straightforward, but I could be
> missing something.

I only thought about it for a few seconds, but I also think it
shouldn't be hard.


From ch-tbnl at bobobeach.com  Fri Feb  1 18:31:33 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Fri, 1 Feb 2008 10:31:33 -0800
Subject: [hunchentoot-devel] hunchentoot CGI?
In-Reply-To: <uprvgtv28.fsf@agharta.de>
References: <68F0856D-F98F-4588-AA28-227398295248@bobobeach.com>
	<uprvgtv28.fsf@agharta.de>
Message-ID: <73EF0CA3-B4BF-47EA-A95F-0B337021CDDA@bobobeach.com>


Heh. No, I think I've got it to work, at least on some simple CGI  
scripts. I'd like to be able to have things like mailman, gitweb,  
etc... running off of my hunchentoot server rather than requiring me  
to set up apache just for same damn CGIs. I'll post it once I've done  
some more testing if anyone's interested.

Cyrus

On Feb 1, 2008, at 10:01 AM, Edi Weitz wrote:

> On Thu, 31 Jan 2008 14:08:02 -0800, Cyrus Harmon <ch-tbnl at bobobeach.com 
> > wrote:
>
>> This may seem counterproductive but has anyone used Hunchentoot for
>> running CGI scripts?
>
> Not me.  Are you trying to win some strange bet or is this a first
> attempt at integrating Arc with Hunchentoot?
>
> :)
>
>> It seems like this should be pretty straightforward, but I could be
>> missing something.
>
> I only thought about it for a few seconds, but I also think it
> shouldn't be hard.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From hom.sepanta at gmail.com  Mon Feb  4 20:14:48 2008
From: hom.sepanta at gmail.com (Mostafa Razavi)
Date: Mon, 04 Feb 2008 23:44:48 +0330
Subject: [hunchentoot-devel] Hunchentoot Thread Safety
Message-ID: <47A77238.7020100@gmail.com>

Hi. I've been thinking about Hunchentoot's thread safety, lately. I see 
that for each request Hunchentoot spawns a new thread (if possible, of 
course) and binds the special variable *request* for it. Initially I 
thought this could cause problems, but when I did a few tests I found 
out everything actually seems to work correctly.

Now, I'm not complaining why things are not going wrong, only I'm 
curious how is it that using a dynamic variable, which is one of those 
dreaded global variables after all, does not cause problems here.

You might point out I can find it out all by myself by reading the 
source code, but unfortunately I couldn't. Maybe I'm missing something. 
Can anyone here, please, point me to the answer? Thanks.

Hom


From xach at xach.com  Mon Feb  4 20:21:09 2008
From: xach at xach.com (Zach Beane)
Date: Mon, 4 Feb 2008 15:21:09 -0500
Subject: [hunchentoot-devel] Hunchentoot Thread Safety
In-Reply-To: <47A77238.7020100@gmail.com>
References: <47A77238.7020100@gmail.com>
Message-ID: <20080204202109.GV19732@xach.com>

On Mon, Feb 04, 2008 at 11:44:48PM +0330, Mostafa Razavi wrote:
> Hi. I've been thinking about Hunchentoot's thread safety, lately. I see 
> that for each request Hunchentoot spawns a new thread (if possible, of 
> course) and binds the special variable *request* for it. Initially I 
> thought this could cause problems, but when I did a few tests I found 
> out everything actually seems to work correctly.
> 
> Now, I'm not complaining why things are not going wrong, only I'm 
> curious how is it that using a dynamic variable, which is one of those 
> dreaded global variables after all, does not cause problems here.

Special variables are global variables done right, and aren't to be
dreaded in Common Lisp.

In threaded Lisps, binding a special will typically make it
thread-local. For example, in SBCL:

  http://www.sbcl.org/manual/Special-Variables.html

Zach


From hom.sepanta at gmail.com  Mon Feb  4 20:44:55 2008
From: hom.sepanta at gmail.com (Mostafa Razavi)
Date: Tue, 05 Feb 2008 00:14:55 +0330
Subject: [hunchentoot-devel] Hunchentoot Thread Safety
In-Reply-To: <20080204202109.GV19732@xach.com>
References: <47A77238.7020100@gmail.com> <20080204202109.GV19732@xach.com>
Message-ID: <47A77947.7060507@gmail.com>

Oh! So basically definitions are global, bindings thread-local. That 
makes sense. Thanks, Zach.

Hom

Zach Beane wrote:
> On Mon, Feb 04, 2008 at 11:44:48PM +0330, Mostafa Razavi wrote:
>   
>> Hi. I've been thinking about Hunchentoot's thread safety, lately. I see 
>> that for each request Hunchentoot spawns a new thread (if possible, of 
>> course) and binds the special variable *request* for it. Initially I 
>> thought this could cause problems, but when I did a few tests I found 
>> out everything actually seems to work correctly.
>>
>> Now, I'm not complaining why things are not going wrong, only I'm 
>> curious how is it that using a dynamic variable, which is one of those 
>> dreaded global variables after all, does not cause problems here.
>>     
>
> Special variables are global variables done right, and aren't to be
> dreaded in Common Lisp.
>
> In threaded Lisps, binding a special will typically make it
> thread-local. For example, in SBCL:
>
>   http://www.sbcl.org/manual/Special-Variables.html
>
> Zach
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>   



From ndj at hivsa.com  Tue Feb  5 08:21:13 2008
From: ndj at hivsa.com (Nico de Jager)
Date: Tue, 05 Feb 2008 10:21:13 +0200
Subject: [hunchentoot-devel] Hunchentoot Thread Safety
In-Reply-To: <47A77238.7020100@gmail.com> (Mostafa Razavi's message of "Mon,
	04 Feb 2008 23:44:48 +0330")
References: <47A77238.7020100@gmail.com>
Message-ID: <87k5ljddae.fsf@davinci.hivsa.com>

Hi

Mostafa Razavi <hom.sepanta at gmail.com> writes:

> Hi. I've been thinking about Hunchentoot's thread safety, lately. I
> see that for each request Hunchentoot spawns a new thread (if
> possible, of course) and binds the special variable *request* for
> it. Initially I thought this could cause problems, but when I did a
> few tests I found out everything actually seems to work correctly.
>
> Now, I'm not complaining why things are not going wrong, only I'm
> curious how is it that using a dynamic variable, which is one of those
> dreaded global variables after all, does not cause problems here.
Also see http://www.gigamonkeys.com/book/variables.html, footnote 11 and the applicable text.

Nico

>
> You might point out I can find it out all by myself by reading the
> source code, but unfortunately I couldn't. Maybe I'm missing
> something. Can anyone here, please, point me to the answer? Thanks.
>
> Hom
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel


From hom.sepanta at gmail.com  Tue Feb  5 10:56:01 2008
From: hom.sepanta at gmail.com (Mostafa Razavi)
Date: Tue, 05 Feb 2008 14:26:01 +0330
Subject: [hunchentoot-devel] Hunchentoot Thread Safety
In-Reply-To: <87k5ljddae.fsf@davinci.hivsa.com>
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
Message-ID: <47A840C1.2040304@gmail.com>

Thanks, Nico. It's good to read books carefully. I had already read PCL 
but I hadn't noticed that.

Hom
> Nico de Jager wrote:
> Also see http://www.gigamonkeys.com/book/variables.html, footnote 11 and the applicable text.
>
> Nico
>   


From victor.kryukov at gmail.com  Wed Feb  6 06:20:36 2008
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Wed, 06 Feb 2008 00:20:36 -0600
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
Message-ID: <87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>

Hello group,

when I'm trying to asdf-load hunchentoot 0.15 in clisp 2.41[2], I'm
receiving the following error message[1].

The problem is that Lu?s Oliveira's name in two files, port-clisp.lisp
and unix-clisp.lisp, is encoded with latin-1, while clisp expects
utf-8, as explained here[3].

BTW, his name spelling is inconsistent in these two files, and
according to [4], Lu?s Oliveira is the right one.

My patch to fix that behaviour is below[5] (it fixes the issue for clisp
and hunchentoot still compiles on SBCL) - I basically saved both files
in utf-8 and changes Lu?s' name spelling in port-clisp.lisp - although
I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.

Regards,
Victor.

[1] Error message:

;; Compiling file /home/victor/src/clbuild/source/hunchentoot/port-clisp.lisp ...
*** - invalid byte sequence #xED #x76 #x65 in CHARSET:UTF-8 conversion
The following restarts are available:
RETRY          :R1      
Retry performing #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE
  "port-clisp" #x000333DCB850>.
ACCEPT         :R2      
Continue, treating #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE
  "port-clisp" #x000333DCB850> as having been successful.
ABORT          :R3      ABORT
Break 1 [2]> 

[2] clisp --version

victor at esculap:~/src/clbuild/source/hunchentoot$ clisp --version
GNU CLISP 2.41 (2006-10-13) (built on victor-desktop [127.0.1.1])
Software: GNU C 4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2) 
/usr/bin/gcc-4.1 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -x none libcharset.a libavcall.a libcallback.a /usr/lib/libreadline.so -lncurses -ldl   -L/usr/lib -lsigsegv 
SAFETY=0 TYPECODES WIDE GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.4
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER CLX-ANSI-COMMON-LISP CLX READLINE
 REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT
 UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx)
Installation directory: /usr/lib/clisp/
User language: ENGLISH
Machine: X86_64 (X86_64) esculap.gateway.2wire.net [192.168.1.73]

[3] http://objectmix.com/lisp/339187-unicode-file-clisp.html

[4] http://www.cl-user.net/asp/l1-A5/sdataQ0So-oWAO7WqDQ3XMHpX8yBX8yBXnMq=/sdataQu3F$sSHnB==

[5]

diff -rN -u old-hunchentoot/port-clisp.lisp new-hunchentoot/port-clisp.lisp
--- old-hunchentoot/port-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
+++ new-hunchentoot/port-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
@@ -1,7 +1,7 @@
 ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*-
 ;;; $Header: /usr/local/cvsrep/hunchentoot/port-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
 
-;;; Copyright (c) 2006, Luis Ol?veira <loliveira at common-lisp.net>.
+;;; Copyright (c) 2006, Lu??s Oliveira <loliveira at common-lisp.net>.
 ;;; Copyright (c) 2007, Anton Vodonosov <avodonosov at yandex.ru>.
 ;;; Copyright (c) 2007, Dr. Edmund Weitz.
 ;;; All rights reserved.
diff -rN -u old-hunchentoot/unix-clisp.lisp new-hunchentoot/unix-clisp.lisp
--- old-hunchentoot/unix-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
+++ new-hunchentoot/unix-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
@@ -1,7 +1,7 @@
 ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*-
 ;;; $Header: /usr/local/cvsrep/hunchentoot/unix-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
 
-;;; Copyright (c) 2006, Lu?s Oliveira <loliveira at common-lisp.net>.
+;;; Copyright (c) 2006, Lu??s Oliveira <loliveira at common-lisp.net>.
 ;;; Copyright (c) 2007, Anton Vodonosov <avodonosov at yandex.ru>.
 ;;; Copyright (c) 2007, Dr. Edmund Weitz.
 ;;; All rights reserved.




From avodonosov at yandex.ru  Wed Feb  6 21:59:40 2008
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Wed, 06 Feb 2008 23:59:40 +0200
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
In-Reply-To: <87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net> (Victor Kryukov's
	message of "Wed\, 06 Feb 2008 00\:20\:36 -0600")
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
Message-ID: <uejbpoier.fsf@yandex.ru>


Transliteration to latin characters may make sense here,
as it was originally done by Lu?s:
http://common-lisp.net/~loliveira/patches/serve-event.diff.

BTW, clisp default encoding depends on your locale, 
it is not necessary utf-8: 
http://clisp.cons.org/clisp.html#opt-enc.

Best regards,
-Anton

Victor Kryukov <victor.kryukov at gmail.com> writes:

> Hello group,
>
> when I'm trying to asdf-load hunchentoot 0.15 in clisp 2.41[2], I'm
> receiving the following error message[1].
>
> The problem is that Lu?s Oliveira's name in two files, port-clisp.lisp
> and unix-clisp.lisp, is encoded with latin-1, while clisp expects
> utf-8, as explained here[3].
>
> BTW, his name spelling is inconsistent in these two files, and
> according to [4], Lu?s Oliveira is the right one.
>
> My patch to fix that behaviour is below[5] (it fixes the issue for clisp
> and hunchentoot still compiles on SBCL) - I basically saved both files
> in utf-8 and changes Lu?s' name spelling in port-clisp.lisp - although
> I'm not sure if "darcs diff -u" will handle all the charcodes intelligently.
>
> Regards,
> Victor.
>
> [1] Error message:
>
> ;; Compiling file /home/victor/src/clbuild/source/hunchentoot/port-clisp.lisp ...
> *** - invalid byte sequence #xED #x76 #x65 in CHARSET:UTF-8 conversion
> The following restarts are available:
> RETRY          :R1      
> Retry performing #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE
>   "port-clisp" #x000333DCB850>.
> ACCEPT         :R2      
> Continue, treating #<ASDF:COMPILE-OP NIL #x000333DCD9A0> on #<ASDF:CL-SOURCE-FILE
>   "port-clisp" #x000333DCB850> as having been successful.
> ABORT          :R3      ABORT
> Break 1 [2]> 
>
> [2] clisp --version
>
> victor at esculap:~/src/clbuild/source/hunchentoot$ clisp --version
> GNU CLISP 2.41 (2006-10-13) (built on victor-desktop [127.0.1.1])
> Software: GNU C 4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2) 
> /usr/bin/gcc-4.1 -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -x none libcharset.a libavcall.a libcallback.a /usr/lib/libreadline.so -lncurses -ldl   -L/usr/lib -lsigsegv 
> SAFETY=0 TYPECODES WIDE GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
> libsigsegv 2.4
> libreadline 5.2
> Features: 
> (ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER CLX-ANSI-COMMON-LISP CLX READLINE
>  REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
>  INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT
>  UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
> C Modules: (clisp i18n syscalls regexp readline linux clx)
> Installation directory: /usr/lib/clisp/
> User language: ENGLISH
> Machine: X86_64 (X86_64) esculap.gateway.2wire.net [192.168.1.73]
>
> [3] http://objectmix.com/lisp/339187-unicode-file-clisp.html
>
> [4] http://www.cl-user.net/asp/l1-A5/sdataQ0So-oWAO7WqDQ3XMHpX8yBX8yBXnMq=/sdataQu3F$sSHnB==
>
> [5]
>
> diff -rN -u old-hunchentoot/port-clisp.lisp new-hunchentoot/port-clisp.lisp
> --- old-hunchentoot/port-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
> +++ new-hunchentoot/port-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
> @@ -1,7 +1,7 @@
>  ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*-
>  ;;; $Header: /usr/local/cvsrep/hunchentoot/port-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
>  
> -;;; Copyright (c) 2006, Luis Ol?veira <loliveira at common-lisp.net>.
> +;;; Copyright (c) 2006, Lu??s Oliveira <loliveira at common-lisp.net>.
>  ;;; Copyright (c) 2007, Anton Vodonosov <avodonosov at yandex.ru>.
>  ;;; Copyright (c) 2007, Dr. Edmund Weitz.
>  ;;; All rights reserved.
> diff -rN -u old-hunchentoot/unix-clisp.lisp new-hunchentoot/unix-clisp.lisp
> --- old-hunchentoot/unix-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
> +++ new-hunchentoot/unix-clisp.lisp	2008-02-06 00:07:40.000000000 -0600
> @@ -1,7 +1,7 @@
>  ;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10; -*-
>  ;;; $Header: /usr/local/cvsrep/hunchentoot/unix-clisp.lisp,v 1.1 2007/12/29 17:35:01 edi Exp $
>  
> -;;; Copyright (c) 2006, Lu?s Oliveira <loliveira at common-lisp.net>.
> +;;; Copyright (c) 2006, Lu??s Oliveira <loliveira at common-lisp.net>.
>  ;;; Copyright (c) 2007, Anton Vodonosov <avodonosov at yandex.ru>.
>  ;;; Copyright (c) 2007, Dr. Edmund Weitz.
>  ;;; All rights reserved.
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel


From edi at agharta.de  Wed Feb  6 23:38:15 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 07 Feb 2008 00:38:15 +0100
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
In-Reply-To: <uejbpoier.fsf@yandex.ru> (Anton Vodonosov's message of "Wed,
	06 Feb 2008 23:59:40 +0200")
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
	<uejbpoier.fsf@yandex.ru>
Message-ID: <uhcglr6zc.fsf@agharta.de>

On Wed, 06 Feb 2008 23:59:40 +0200, Anton Vodonosov <avodonosov at yandex.ru> wrote:

> Transliteration to latin characters may make sense here, as it was
> originally done by Lu?s:
> http://common-lisp.net/~loliveira/patches/serve-event.diff.

But the accented "i" in his name /is/ a Latin character... :)


From edi at agharta.de  Wed Feb  6 23:45:41 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 07 Feb 2008 00:45:41 +0100
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
In-Reply-To: <87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net> (Victor Kryukov's
	message of "Wed, 06 Feb 2008 00:20:36 -0600")
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
Message-ID: <ud4r9r6my.fsf@agharta.de>

On Wed, 06 Feb 2008 00:20:36 -0600, Victor Kryukov <victor.kryukov at gmail.com> wrote:

> BTW, his name spelling is inconsistent in these two files, and
> according to [4], Lu?s Oliveira is the right one.

Thanks, I'll fix that.

> My patch to fix that behaviour is below[5] (it fixes the issue for
> clisp and hunchentoot still compiles on SBCL) - I basically saved
> both files in utf-8 and changes Lu?s' name spelling in
> port-clisp.lisp - although I'm not sure if "darcs diff -u" will
> handle all the charcodes intelligently.

Thanks for the patch, but I won't change the file format to UTF-8 as
it'll make editing the files harder for me and I see no particular
reason why text files should be assumed to be encoded in UTF-8 by
default.  (Not to mention that CLISP isn't even fully supported.)

What we can do to fix this is:

1. Change the name to simply "Luis Oliveira" if that's OK with Lu?s.

2. Add an encoding declaration (an Emacs file local variable) for
   ISO-8859-1 in the first line of the file.  LispWorks, for example,
   will observe that.  Don't know about CLISP.

Cheers,
Edi.


From avodonosov at yandex.ru  Thu Feb  7 00:11:05 2008
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Thu, 07 Feb 2008 02:11:05 +0200
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
In-Reply-To: <uhcglr6zc.fsf@agharta.de> (Edi Weitz's message of "Thu\,
	07 Feb 2008 00\:38\:15 +0100")
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
	<uejbpoier.fsf@yandex.ru> <uhcglr6zc.fsf@agharta.de>
Message-ID: <uabmdocbq.fsf@yandex.ru>

Edi Weitz <edi at agharta.de> writes:

> On Wed, 06 Feb 2008 23:59:40 +0200, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>
>> Transliteration to latin characters may make sense here, as it was
>> originally done by Lu?s:
>> http://common-lisp.net/~loliveira/patches/serve-event.diff.
>
> But the accented "i" in his name /is/ a Latin character... :)

I thought latins didn't use characters above 7f...


From victor.kryukov at gmail.com  Thu Feb  7 00:16:17 2008
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Wed, 06 Feb 2008 18:16:17 -0600
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
	<ud4r9r6my.fsf@agharta.de>
Message-ID: <m2odat8vu6.fsf@vicbook.gateway.2wire.net>

Edi Weitz <edi at agharta.de> writes:

> On Wed, 06 Feb 2008 00:20:36 -0600, Victor Kryukov <victor.kryukov at gmail.com> wrote:
>> My patch to fix that behaviour is below[5] (it fixes the issue for
>> clisp and hunchentoot still compiles on SBCL) - I basically saved
>> both files in utf-8 and changes Lu?s' name spelling in
>> port-clisp.lisp - although I'm not sure if "darcs diff -u" will
>> handle all the charcodes intelligently.
>
> Thanks for the patch, but I won't change the file format to UTF-8 as
> it'll make editing the files harder for me and I see no particular
> reason why text files should be assumed to be encoded in UTF-8 by
> default.  (Not to mention that CLISP isn't even fully supported.)

Sure, I'm not telling this is the best solution - it worked for me,
but may not work for everybody.

BTW, why is editing UTF-8 files hard? Emacs is handling that pretty
easily, and I'm sure LispWorks/Allegro IDEs should respect encodings
as well.

> What we can do to fix this is:
>
> 1. Change the name to simply "Luis Oliveira" if that's OK with Lu?s.
>
> 2. Add an encoding declaration (an Emacs file local variable) for
>    ISO-8859-1 in the first line of the file.  LispWorks, for example,
>    will observe that.  Don't know about CLISP.

It seems that CLISP doesn't support the 2 - otherwise Pascal wouldn't
create his own library, I guess.[1]

Regards,
Victor.

[1] http://groups.google.com/group/comp.lang.lisp/msg/815295c8ae5ab187



From edi at agharta.de  Thu Feb  7 00:29:04 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 07 Feb 2008 01:29:04 +0100
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
In-Reply-To: <m2odat8vu6.fsf@vicbook.gateway.2wire.net> (Victor Kryukov's
	message of "Wed, 06 Feb 2008 18:16:17 -0600")
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
	<ud4r9r6my.fsf@agharta.de> <m2odat8vu6.fsf@vicbook.gateway.2wire.net>
Message-ID: <uzludpq27.fsf@agharta.de>

On Wed, 06 Feb 2008 18:16:17 -0600, Victor Kryukov <victor.kryukov at gmail.com> wrote:

> BTW, why is editing UTF-8 files hard? Emacs is handling that pretty
> easily, and I'm sure LispWorks/Allegro IDEs should respect encodings
> as well.

They do, but they have to open otherwise unknown text files with some
default encoding which in my case is Latin 1.  (And that makes sense
as almost all text files I'm dealing with are Latin 1.)  But it seems
CLISP doesn't:

> It seems that CLISP doesn't support the 2

> otherwise Pascal wouldn't create his own library, I guess.

I wouldn't be so sure about that.  My impression from c.l.l is that
Pascal B. often starts to hack already when he should still think
about the problem... :)


From luismbo at gmail.com  Thu Feb  7 04:08:47 2008
From: luismbo at gmail.com (Luis Oliveira)
Date: Thu, 07 Feb 2008 04:08:47 +0000
Subject: [hunchentoot-devel] [PATCH] invalid byte sequence failure in clisp
References: <47A77238.7020100@gmail.com> <87k5ljddae.fsf@davinci.hivsa.com>
	<87lk5ya9mz.fsf_-_@esculap.gateway.2wire.net>
	<ud4r9r6my.fsf@agharta.de>
Message-ID: <m1d4r94ddc.fsf@deadspam.com>

Edi Weitz <edi at agharta.de> writes:
> 1. Change the name to simply "Luis Oliveira" if that's OK with Lu?s.

That's what I do in most of my source code to avoid encoding issues.

-- 
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/



From ch-tbnl at bobobeach.com  Fri Feb  8 01:36:40 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Thu, 7 Feb 2008 17:36:40 -0800
Subject: [hunchentoot-devel] handle-static-file patch
Message-ID: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>


Currently, if you use create-folder-dispatcher-and-handler to create a  
handler, it will call handle-static-file on a URL like http://bogushost.tld/this/is/a/directory 
  and will give the contents of the directory as returned by fopen'ing  
the directory, which probably isn't what we want. The following patch  
to handle-static-file makes sure that the truename of the file has  
either a pathname-name or a pathname-type.

Not sure if this is desired behavior or not, but I'd rather see a 500  
error here. There's another error where if one sets up a folder- 
dispatcher-and-handler to catch "/www/foo/" and you request "/www/ 
foo/" you git an internal server error instead of a 500 error, but I  
haven't worked out the patch for that one yet.

Thanks,

Cyrus


--- misc.lisp	Thu Feb  7 18:46:24 2008
+++ misc-patched.lisp	Thu Feb  7 18:46:01 2008
@@ -137,11 +137,12 @@
  denoted by PATH.  Send a content type header corresponding to
  CONTENT-TYPE or \(if that is NIL) tries to determine the content
  type via the file's suffix."
-  (unless (or (pathname-name path)
-              (pathname-type path))
-    ;; not a file
-    (setf (return-code) +http-bad-request+)
-    (throw 'handler-done nil))
+  (let ((true-path (truename path)))
+    (unless (or (pathname-name true-path)
+                (pathname-type true-path))
+      ;; not a file
+      (setf (return-code) +http-bad-request+)
+      (throw 'handler-done nil)))
    (unless (probe-file path)
      ;; does not exist
      (setf (return-code) +http-not-found+)



From edi at agharta.de  Fri Feb  8 14:19:38 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 08 Feb 2008 15:19:38 +0100
Subject: [hunchentoot-devel] handle-static-file patch
In-Reply-To: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com> (Cyrus
	Harmon's message of "Thu, 7 Feb 2008 17:36:40 -0800")
References: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>
Message-ID: <u4pcjh6o5.fsf@agharta.de>

On Thu, 7 Feb 2008 17:36:40 -0800, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> Currently, if you use create-folder-dispatcher-and-handler to create
> a handler, it will call handle-static-file on a URL like
> http://bogushost.tld/this/is/a/directory and will give the contents
> of the directory as returned by fopen'ing the directory, which
> probably isn't what we want. The following patch to
> handle-static-file makes sure that the truename of the file has
> either a pathname-name or a pathname-type.

On which Lisp does that solve the problem?

CLISP on Windows:

  CL-USER> (pathname-name (truename "c:\\WINDOWS"))
  "WINDOWS"

AllegroCL on Linux:

  CL-USER(1): (pathname-name (truename "/tmp"))
  "tmp"

(Yes, these are both directories.)

I fear we're in unknown territory and need to resort to something like
CL-FAD for a real solution... :(

> Not sure if this is desired behavior or not, but I'd rather see a
> 500 error here. There's another error where if one sets up a folder-
> dispatcher-and-handler to catch "/www/foo/" and you request "/www/
> foo/" you git an internal server error instead of a 500 error, but I
> haven't worked out the patch for that one yet.

Hmm, sounds vaguely familiar.  Didn't we have something like this
already?

Thanks,
Edi.


From ch-tbnl at bobobeach.com  Fri Feb  8 16:34:41 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Fri, 8 Feb 2008 08:34:41 -0800
Subject: [hunchentoot-devel] handle-static-file patch
In-Reply-To: <u4pcjh6o5.fsf@agharta.de>
References: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>
	<u4pcjh6o5.fsf@agharta.de>
Message-ID: <70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com>


On Feb 8, 2008, at 6:19 AM, Edi Weitz wrote:

> On which Lisp does that solve the problem?
>
> CLISP on Windows:
>
>  CL-USER> (pathname-name (truename "c:\\WINDOWS"))
>  "WINDOWS"
>
> AllegroCL on Linux:
>
>  CL-USER(1): (pathname-name (truename "/tmp"))
>  "tmp"
>
> (Yes, these are both directories.)
>
> I fear we're in unknown territory and need to resort to something like
> CL-FAD for a real solution... :(

Darn. On SBCL on Mac OS (and presumably linux, etc...) I get:

CL-USER> (pathname-name (truename "/tmp"))
NIL

The joy of CL pathnames... Yes, cl-fad seems like a reasonable  
approach to me.

>> Not sure if this is desired behavior or not, but I'd rather see a
>> 500 error here. There's another error where if one sets up a folder-
>> dispatcher-and-handler to catch "/www/foo/" and you request "/www/
>> foo/" you git an internal server error instead of a 500 error, but I
>> haven't worked out the patch for that one yet.
>
> Hmm, sounds vaguely familiar.  Didn't we have something like this
> already?

If we did it doesn't seem to be in 0.15.0.

Thanks,

Cyrus



From victor.kryukov at gmail.com  Sat Feb  9 18:31:21 2008
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Sat, 09 Feb 2008 12:31:21 -0600
Subject: [hunchentoot-devel] handle-static-file patch
References: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>
	<u4pcjh6o5.fsf@agharta.de>
	<70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com>
Message-ID: <87wspe2d8m.fsf@esculap.gateway.2wire.net>

Cyrus Harmon <ch-tbnl at bobobeach.com> writes:

> On Feb 8, 2008, at 6:19 AM, Edi Weitz wrote:
>
>> On which Lisp does that solve the problem?
>>
>> CLISP on Windows:
>>
>>  CL-USER> (pathname-name (truename "c:\\WINDOWS"))
>>  "WINDOWS"
>>
>> AllegroCL on Linux:
>>
>>  CL-USER(1): (pathname-name (truename "/tmp"))
>>  "tmp"
>>
>> (Yes, these are both directories.)
>>
>> I fear we're in unknown territory and need to resort to something like
>> CL-FAD for a real solution... :(
>
> Darn. On SBCL on Mac OS (and presumably linux, etc...) I get:
>
> CL-USER> (pathname-name (truename "/tmp"))
> NIL

Just for the record:

SBCL 1.0.14.10 on x86-64 linux:

CL-USER> (pathname-name (truename "/tmp"))
NIL

CLISP 2.41 on x86-64 linux:

[1]> (truename "/tmp")

*** - TRUENAME: "/tmp" names a directory, not a file
The following restarts are available:
ABORT          :R1      ABORT
Break 1 [2]> 

[16]> (truename "/tmp/")
#P"/tmp/"
[18]> (pathname-name (truename "/tmp/"))
NIL



From ebzzry at gmail.com  Tue Feb 12 06:16:43 2008
From: ebzzry at gmail.com (Rommel Martinez)
Date: Tue, 12 Feb 2008 14:16:43 +0800
Subject: [hunchentoot-devel] parameters
Message-ID: <391934950802112216x285c081ag6a825027dba65904@mail.gmail.com>

Hi! How do I make an HREF link "call" a dispatch function (and "pass"
parameters without having to write long strings like this:

"/?foo=1&amp;bar=2&amp;baz=3"

I am able to do it with forms, using POST, but not with HREFs. :-(

Sorry, I'm new to Hunchentoot. Please bear with me. Thanks. :-)

-- 
Rommel M. Martinez <ebzzry at gmail.com>


From victor.kryukov at gmail.com  Tue Feb 12 06:37:57 2008
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Tue, 12 Feb 2008 00:37:57 -0600
Subject: [hunchentoot-devel] parameters
References: <391934950802112216x285c081ag6a825027dba65904@mail.gmail.com>
Message-ID: <877ihallx6.fsf@esculap.gateway.2wire.net>

"Rommel Martinez" <ebzzry at gmail.com> writes:

> Hi! How do I make an HREF link "call" a dispatch function (and "pass"
> parameters without having to write long strings like this:
>
> "/?foo=1&amp;bar=2&amp;baz=3"
>
> I am able to do it with forms, using POST, but not with HREFs. :-(

Hey Rommel,

one way to do that is to check Dr. Weitz's very own url-rewrite[1], a
Hunchentoot dependency, in particular ADD-GET-PARAM-TO-URL:

* (add-get-param-to-url "http://common-lisp.net/" "foo" "bar")
"http://common-lisp.net/?foo=bar"

* (add-get-param-to-url "http://common-lisp.net/index.html?frob=42" "foo" "bar")
"http://common-lisp.net/index.html?frob=42&amp;foo=bar"

* (add-get-param-to-url "http://common-lisp.net/" "foo" "+")
"http://common-lisp.net/?foo=%2B"

Regards,
Victor.

[1] http://www.weitz.de/url-rewrite/#add-get-param-to-url



From ebzzry at gmail.com  Tue Feb 12 06:49:26 2008
From: ebzzry at gmail.com (Rommel Martinez)
Date: Tue, 12 Feb 2008 14:49:26 +0800
Subject: [hunchentoot-devel] parameters
In-Reply-To: <877ihallx6.fsf@esculap.gateway.2wire.net>
References: <391934950802112216x285c081ag6a825027dba65904@mail.gmail.com>
	<877ihallx6.fsf@esculap.gateway.2wire.net>
Message-ID: <391934950802112249i92c99f0oc517b0116874236d@mail.gmail.com>

On Feb 12, 2008 2:37 PM, Victor Kryukov <victor.kryukov at gmail.com> wrote:
> "Rommel Martinez" <ebzzry at gmail.com> writes:
>
> > Hi! How do I make an HREF link "call" a dispatch function (and "pass"
> > parameters without having to write long strings like this:
> >
> > "/?foo=1&amp;bar=2&amp;baz=3"
> >
> > I am able to do it with forms, using POST, but not with HREFs. :-(
>
> Hey Rommel,
>
> one way to do that is to check Dr. Weitz's very own url-rewrite[1], a
> Hunchentoot dependency, in particular ADD-GET-PARAM-TO-URL:
>
> * (add-get-param-to-url "http://common-lisp.net/" "foo" "bar")
> "http://common-lisp.net/?foo=bar"
>
> * (add-get-param-to-url "http://common-lisp.net/index.html?frob=42" "foo" "bar")
> "http://common-lisp.net/index.html?frob=42&amp;foo=bar"
>
> * (add-get-param-to-url "http://common-lisp.net/" "foo" "+")
> "http://common-lisp.net/?foo=%2B"
>
> Regards,
> Victor.
>
> [1] http://www.weitz.de/url-rewrite/#add-get-param-to-url
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

Sweet! Thanks! :-)

-- 
Rommel M. Martinez <ebzzry at gmail.com>


From edi at agharta.de  Wed Feb 13 15:43:48 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 13 Feb 2008 16:43:48 +0100
Subject: [hunchentoot-devel] handle-static-file patch
In-Reply-To: <70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com> (Cyrus
	Harmon's message of "Fri, 8 Feb 2008 08:34:41 -0800")
References: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>
	<u4pcjh6o5.fsf@agharta.de>
	<70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com>
Message-ID: <u63wssvyj.fsf@agharta.de>

On Fri, 8 Feb 2008 08:34:41 -0800, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

>> Hmm, sounds vaguely familiar.  Didn't we have something like this
>> already?
>
> If we did it doesn't seem to be in 0.15.0.

No, I meant we had this problem before.  See the December 2007
archives of the mailing list.

Yes, that should be fixed as well.


From edi at agharta.de  Wed Feb 13 16:09:05 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 13 Feb 2008 17:09:05 +0100
Subject: [hunchentoot-devel] New release 0.15.1 (Was: handle-static-file
	patch)
In-Reply-To: <70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com> (Cyrus
	Harmon's message of "Fri, 8 Feb 2008 08:34:41 -0800")
References: <D3102E7C-E85B-491B-913C-0088A3B1E24A@bobobeach.com>
	<u4pcjh6o5.fsf@agharta.de>
	<70E8254A-D03A-4C72-948C-B80C57A205B2@bobobeach.com>
Message-ID: <uwsp8rg7y.fsf_-_@agharta.de>

On Fri, 8 Feb 2008 08:34:41 -0800, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> Yes, cl-fad seems like a reasonable approach to me.

See the latest release.  Should also hopefully fix the other problem
you reported.

I've chosen to always reply "Not Found" now as I think we don't have
to give the bad guys hints about our directory structure by sometimes
(in the case of folders) saying "Bad Request".

Edi.


From coffeemug at gmail.com  Fri Feb 15 20:37:53 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Fri, 15 Feb 2008 15:37:53 -0500
Subject: [hunchentoot-devel] Finding out if we're multithreaded
Message-ID: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>

Hello,

Is there an easy way to find out of Hunchentoot is using threads to
handle requests? I'd like to issue a warning on single threaded
systems, and I'm wondering if there is a unified way to get this
information.

Thanks,
Slava Akhmechet


From edi at agharta.de  Fri Feb 15 21:12:53 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 15 Feb 2008 22:12:53 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	(Vyacheslav
	Akhmechet's message of "Fri, 15 Feb 2008 15:37:53 -0500")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
Message-ID: <ur6fdzzxm.fsf@agharta.de>

On Fri, 15 Feb 2008 15:37:53 -0500, "Vyacheslav Akhmechet" <coffeemug at gmail.com> wrote:

> Is there an easy way to find out of Hunchentoot is using threads to
> handle requests? I'd like to issue a warning on single threaded
> systems, and I'm wondering if there is a unified way to get this
> information.

As a general rule, Hunchentoot should only be used in a multi-threaded
Lisp... :)

Some users convinced me to support Lisps without MP, but this is only
for testing purposes and is frowned upon.  The two possibilities I'm
aware of are:

- SBCL on some platforms; in this case Hunchentoot will issue a
  warning anyway.  (See top of port-sbcl.lisp.)

- CLISP; this Lisp doesn't have MP at all.

Edi.


From coffeemug at gmail.com  Sat Feb 16 07:06:04 2008
From: coffeemug at gmail.com (Vyacheslav Akhmechet)
Date: Sat, 16 Feb 2008 02:06:04 -0500
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <ur6fdzzxm.fsf@agharta.de>
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
Message-ID: <b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>

On 2/15/08, Edi Weitz <edi at agharta.de> wrote:
> - SBCL on some platforms; in this case Hunchentoot will issue a
>   warning anyway.  (See top of port-sbcl.lisp.)
>
> - CLISP; this Lisp doesn't have MP at all.
There's also OpenMCL running on intel chips. It might have support for
threads now (I am not sure), but at some point quite recently it
didn't.

I'll just look for SB-THREADS and whatever alternative OpenMCL offers.


From edi at agharta.de  Sat Feb 16 09:55:33 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 16 Feb 2008 10:55:33 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	(Vyacheslav
	Akhmechet's message of "Sat, 16 Feb 2008 02:06:04 -0500")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
Message-ID: <uir0pz0mi.fsf@agharta.de>

On Sat, 16 Feb 2008 02:06:04 -0500, "Vyacheslav Akhmechet" <coffeemug at gmail.com> wrote:

> There's also OpenMCL running on intel chips. It might have support
> for threads now (I am not sure), but at some point quite recently it
> didn't.

There's also CMUCL on some architectures.  But your question was about
Hunchentoot.  I'm pretty sure Hunchentoot won't even compile on
OpenMCL/CMUCL without threads.


From hans at huebner.org  Sat Feb 16 10:30:54 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 16 Feb 2008 11:30:54 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <uir0pz0mi.fsf@agharta.de>
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de>
Message-ID: <fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>

CMUCL does not have threads.  It does have multiprocessing based on
SERVE-EVENT which is implemented in the Lisp runtime, as opposed to
Lisp with threads that uses platform (often POSIX, but sometimes also
Win32) threads to implement Lisp multiprocessing.  The distinction is
important because in a threaded Lisp, the scheduler is typically
implemented in C as part of the system threads library, whereas in
CMUCL, the scheduler is implemented in Lisp.  Both approaches have
advantages and disadvantages.  The major advantage of Lisp processes
implemented as native threads is that scheduling can occur while a
Lisp process is executing foreign code, whereas with a Lisp scheduler,
entering a foreign function will prevent scheduling.  Also, Lisp
multiprocessing with native threads (theoretically) allows for
symmetric multiprocessing within one Lisp process, although many
implementations do not support that.  Contrasted to that, Lisp based
multiprocessing on CMUCL is cooperative (processes are not
interrupted, but they may yield to allow scheduling of other
processes) which simplifies some applications.  Also, as the scheduler
runs in Lisp, it is possible to call Lisp functions from the
scheduler, which makes it easy to implement queues and other
multiprocessing synchronization mechanisms that, with native
threading, require the use of system-defined primitives.

For many applications, cooperative multiprocessing is easier to work
with as there are fewer hazards.  Processing is synchronous, and
processes do not need to worry about being rescheduled unless they
voluntary give up control (either by sleeping, waiting for I/O or
explicit yield).  I had great success with running web and general
event processing servers on CMUCL with portableaserve as HTTP server.
I would like to see Hunchentoot support CMUCL in the future and will
put some effort into testing it with the upcoming cmucl-19e release.

-Hans

On Feb 16, 2008 10:55 AM, Edi Weitz <edi at agharta.de> wrote:
> On Sat, 16 Feb 2008 02:06:04 -0500, "Vyacheslav Akhmechet" <coffeemug at gmail.com> wrote:
>
> > There's also OpenMCL running on intel chips. It might have support
> > for threads now (I am not sure), but at some point quite recently it
> > didn't.
>
> There's also CMUCL on some architectures.  But your question was about
> Hunchentoot.  I'm pretty sure Hunchentoot won't even compile on
> OpenMCL/CMUCL without threads.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Sat Feb 16 11:03:57 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 16 Feb 2008 12:03:57 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>
	(Hans =?iso-8859-1?q?H=FCbner's?= message of "Sat,
	16 Feb 2008 11:30:54 +0100")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de>
	<fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>
Message-ID: <uejbdyxgi.fsf@agharta.de>

On Sat, 16 Feb 2008 11:30:54 +0100, "Hans H?bner" <hans at huebner.org> wrote:

> CMUCL does not have threads.  It does have multiprocessing based on
> SERVE-EVENT which is implemented in the Lisp runtime, as opposed to
> Lisp with threads that uses platform (often POSIX, but sometimes
> also Win32) threads to implement Lisp multiprocessing.

Yes, the same (in a similar way) is true for LispWorks pre-5.

> For many applications, cooperative multiprocessing is easier to work
> with as there are fewer hazards.

Not to mention that "native" MP on Linux often has a recent kernel as
a requirement whereas for example CMUCL or LW 4.x will also run on old
kernels.

> I would like to see Hunchentoot support CMUCL in the future

What about now?  There's port-cmu.lisp and friends...

Edi.


From hans at huebner.org  Sat Feb 16 11:11:04 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 16 Feb 2008 12:11:04 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <uejbdyxgi.fsf@agharta.de>
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de>
	<fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>
	<uejbdyxgi.fsf@agharta.de>
Message-ID: <fd2982320802160311x4a4d0bb6k9811782dac1ee29e@mail.gmail.com>

On Feb 16, 2008 12:03 PM, Edi Weitz <edi at agharta.de> wrote:
> What about now?  There's port-cmu.lisp and friends...

I must admit that I am waiting for cmucl-19e before looking at it
again as I have some hope that it will support Unicode.  Once it is
out, I will be reporting possible problems.

-Hans


From coffeemug at gmail.com  Sat Feb 16 19:50:47 2008
From: coffeemug at gmail.com (Slava Akhmechet)
Date: Sat, 16 Feb 2008 14:50:47 -0500
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <uir0pz0mi.fsf@agharta.de> (Edi Weitz's message of "Sat, 16 Feb
	2008 10:55:33 +0100")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de>
Message-ID: <873arsvfxk.fsf@gmail.com>

Edi Weitz <edi at agharta.de> writes:

> I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL
> without threads.
I don't know about CMUCL, but I did get reports of runtime issues on
non-threaded OpenMCL. There were no compilation issues. (Perhaps it was
an older version of Hunchentoot).

Anyway, there aren't that many cases to look for. I was just wondering
if function exposes a THREADED-P function before I rolled my own.

-- 
Regards,
Slava Akhmechet.


From coffeemug at gmail.com  Sat Feb 16 19:54:54 2008
From: coffeemug at gmail.com (Slava Akhmechet)
Date: Sat, 16 Feb 2008 14:54:54 -0500
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>
	("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Sat,
	16 Feb 2008 11:30:54 +0100")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de>
	<fd2982320802160230v68f12de6g8d114e4d5e0d4aff@mail.gmail.com>
Message-ID: <87y79ku169.fsf@gmail.com>

"Hans H?bner" <hans at huebner.org> writes:

> The major advantage of Lisp processes implemented as native threads is
> that scheduling can occur while a Lisp process is executing foreign
> code, whereas with a Lisp scheduler, entering a foreign function will
> prevent scheduling.
You may want to read the "tackling the awkward squad" paper by Simon
Peyton Jones. It's done in Haskell, but it would be awesome to see in
Lisp. Basically, there is a native thread per CPU for computation,
coroutines-based threads (like Erlang or CMUCL) on top of those for
abstraction, asynchronious IO to avoid blocking, and thread pool for
native calls (again, to avoid blocking). The way of the future, IMO.

-- 
Regards,
Slava Akhmechet.


From hans at huebner.org  Sat Feb 16 19:55:41 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 16 Feb 2008 20:55:41 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <873arsvfxk.fsf@gmail.com>
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de> <873arsvfxk.fsf@gmail.com>
Message-ID: <fd2982320802161155r211f6c78nd888f56aa0a8c9dc@mail.gmail.com>

I think I missed to point out that "threaded" is not the right word to
use.  What you want to know seems to be whether the current Lisp
supports multiprocessing, or am I wrong?

-Hans

On Feb 16, 2008 8:50 PM, Slava Akhmechet <coffeemug at gmail.com> wrote:
> Edi Weitz <edi at agharta.de> writes:
>
> > I'm pretty sure Hunchentoot won't even compile on OpenMCL/CMUCL
> > without threads.
> I don't know about CMUCL, but I did get reports of runtime issues on
> non-threaded OpenMCL. There were no compilation issues. (Perhaps it was
> an older version of Hunchentoot).
>
> Anyway, there aren't that many cases to look for. I was just wondering
> if function exposes a THREADED-P function before I rolled my own.
>
> --
> Regards,
> Slava Akhmechet.
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Sat Feb 16 20:44:57 2008
From: edi at agharta.de (Edi Weitz)
Date: Sat, 16 Feb 2008 21:44:57 +0100
Subject: [hunchentoot-devel] Finding out if we're multithreaded
In-Reply-To: <873arsvfxk.fsf@gmail.com> (Slava Akhmechet's message of "Sat,
	16 Feb 2008 14:50:47 -0500")
References: <b381ea40802151237m4cd3c6f2u70748fedbd0a01ee@mail.gmail.com>
	<ur6fdzzxm.fsf@agharta.de>
	<b381ea40802152306lca8ca64i9935fed573e35aa4@mail.gmail.com>
	<uir0pz0mi.fsf@agharta.de> <873arsvfxk.fsf@gmail.com>
Message-ID: <uodagwrzq.fsf@agharta.de>

On Sat, 16 Feb 2008 14:50:47 -0500, Slava Akhmechet <coffeemug at gmail.com> wrote:

> I don't know about CMUCL, but I did get reports of runtime issues on
> non-threaded OpenMCL. There were no compilation issues. (Perhaps it
> was an older version of Hunchentoot).

I haven't used Hunchentoot with OpenMCL for quite some time, but it
looks to me as if Hunchentoot will call CCL:PROCESS-RUN-FUNCTION if a
request comes in.  What does that function do in OpenMCL if there's no
MP?  Does it even exist?


From wout.perquin at skynet.be  Sun Feb 17 09:28:52 2008
From: wout.perquin at skynet.be (Wout Perquin)
Date: Sun, 17 Feb 2008 10:28:52 +0100
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
Message-ID: <KKEMLPLMIPKOHMILKBJJIEFICCAA.wout.perquin@skynet.be>

Hi,
I am struggling to get SSL working on cmucl.
I looked at
http://common-lisp.net/pipermail/tbnl-devel/2008-January/001616.html and did
what was explained there :
a) with openssl I generated private key and certificate
b) I started the server with :
(defvar *hportal443*
  (hunchentoot:start-server :port 443
   :ssl-certificate-file #P"/data/lispdata/ssl/cacert.pem"
   :ssl-privatekey-file #P"/data/lispdata/ssl/pkey.pem"))
When I browse to https://localhost then the browser notifies about the
certificate.
After I have accepted it, it takes about 25secs before the browser is done,
however it renders an empty page.
I expected to see the default page.  Also any page I publish isnt rendered
either.  The log doesnt give any hints.  It gives :
[2008-02-17 11:28:39 [INFO]] Default handler called for script /favicon.ico
[2008-02-17 11:28:39] 127.0.0.1 - "GET /favicon.ico HTTP/1.1" 200 641 "-"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524
Fedora/1.0.4-4 Firefox/1.0.4"
Is there anybody who had similar experiences and managed to get it sorted ?
Thanks, Wout Perquin



From hans at huebner.org  Sun Feb 17 10:25:26 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 17 Feb 2008 11:25:26 +0100
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
In-Reply-To: <KKEMLPLMIPKOHMILKBJJIEFICCAA.wout.perquin@skynet.be>
References: <KKEMLPLMIPKOHMILKBJJIEFICCAA.wout.perquin@skynet.be>
Message-ID: <fd2982320802170225u58fe49acx3ff7f005aaa08a82@mail.gmail.com>

Did you try (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL) to see any errors
in the debugger?  Did you start the cmucl multiprocessing loop with
(mp::startup-idle-and-top-level-loops))?  Forgetting the latter often
results in very long response times.

-Hans

On Feb 17, 2008 10:28 AM, Wout Perquin <wout.perquin at skynet.be> wrote:
> Hi,
> I am struggling to get SSL working on cmucl.
> I looked at
> http://common-lisp.net/pipermail/tbnl-devel/2008-January/001616.html and did
> what was explained there :
> a) with openssl I generated private key and certificate
> b) I started the server with :
> (defvar *hportal443*
>   (hunchentoot:start-server :port 443
>    :ssl-certificate-file #P"/data/lispdata/ssl/cacert.pem"
>    :ssl-privatekey-file #P"/data/lispdata/ssl/pkey.pem"))
> When I browse to https://localhost then the browser notifies about the
> certificate.
> After I have accepted it, it takes about 25secs before the browser is done,
> however it renders an empty page.
> I expected to see the default page.  Also any page I publish isnt rendered
> either.  The log doesnt give any hints.  It gives :
> [2008-02-17 11:28:39 [INFO]] Default handler called for script /favicon.ico
> [2008-02-17 11:28:39] 127.0.0.1 - "GET /favicon.ico HTTP/1.1" 200 641 "-"
> "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524
> Fedora/1.0.4-4 Firefox/1.0.4"
> Is there anybody who had similar experiences and managed to get it sorted ?
> Thanks, Wout Perquin
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From wout.perquin at skynet.be  Sun Feb 17 11:18:39 2008
From: wout.perquin at skynet.be (Wout Perquin)
Date: Sun, 17 Feb 2008 12:18:39 +0100
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
In-Reply-To: <fd2982320802170225u58fe49acx3ff7f005aaa08a82@mail.gmail.com>
Message-ID: <KKEMLPLMIPKOHMILKBJJEEFJCCAA.wout.perquin@skynet.be>

> (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL)
The debugger says : the value of CL+SSL::thing is #([...]), which is not of
type (SIMPLE-ARRAY (UNSIGNED-BYTE 8)(*))
[condition of SIMPLE-TYPE-ERROR]
I did a google on "CL+SSL::thing SIMPLE-TYPE-ERROR" but no match
-Wout

-----Original Message-----
From: tbnl-devel-bounces at common-lisp.net
[mailto:tbnl-devel-bounces at common-lisp.net]On Behalf Of Hans H?bner
Sent: zondag 17 februari 2008 11:25
To: General interest list for Hunchentoot and CL-WEBDAV
Subject: Re: [hunchentoot-devel] Hunchentoot and SSL on cmucl


Did you try (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL) to see any errors
in the debugger?  Did you start the cmucl multiprocessing loop with
(mp::startup-idle-and-top-level-loops))?  Forgetting the latter often
results in very long response times.

-Hans

On Feb 17, 2008 10:28 AM, Wout Perquin <wout.perquin at skynet.be> wrote:
> Hi,
> I am struggling to get SSL working on cmucl.
> I looked at
> http://common-lisp.net/pipermail/tbnl-devel/2008-January/001616.html and
did
> what was explained there :
> a) with openssl I generated private key and certificate
> b) I started the server with :
> (defvar *hportal443*
>   (hunchentoot:start-server :port 443
>    :ssl-certificate-file #P"/data/lispdata/ssl/cacert.pem"
>    :ssl-privatekey-file #P"/data/lispdata/ssl/pkey.pem"))
> When I browse to https://localhost then the browser notifies about the
> certificate.
> After I have accepted it, it takes about 25secs before the browser is
done,
> however it renders an empty page.
> I expected to see the default page.  Also any page I publish isnt rendered
> either.  The log doesnt give any hints.  It gives :
> [2008-02-17 11:28:39 [INFO]] Default handler called for script
/favicon.ico
> [2008-02-17 11:28:39] 127.0.0.1 - "GET /favicon.ico HTTP/1.1" 200 641 "-"
> "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524
> Fedora/1.0.4-4 Firefox/1.0.4"
> Is there anybody who had similar experiences and managed to get it sorted
?
> Thanks, Wout Perquin
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel



From edi at agharta.de  Sun Feb 17 11:50:10 2008
From: edi at agharta.de (Edi Weitz)
Date: Sun, 17 Feb 2008 12:50:10 +0100
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
In-Reply-To: <KKEMLPLMIPKOHMILKBJJEEFJCCAA.wout.perquin@skynet.be> (Wout
	Perquin's message of "Sun, 17 Feb 2008 12:18:39 +0100")
References: <KKEMLPLMIPKOHMILKBJJEEFJCCAA.wout.perquin@skynet.be>
Message-ID: <ulk5jvm31.fsf@agharta.de>

On Sun, 17 Feb 2008 12:18:39 +0100, "Wout Perquin" <wout.perquin at skynet.be> wrote:

>> (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL)
> The debugger says : the value of CL+SSL::thing is #([...]), which is not of
> type (SIMPLE-ARRAY (UNSIGNED-BYTE 8)(*))
> [condition of SIMPLE-TYPE-ERROR]
> I did a google on "CL+SSL::thing SIMPLE-TYPE-ERROR" but no match

Seems like something you should report to the CL+SSL mailing list.

Cheers,
Edi.


From ch-tbnl at bobobeach.com  Sun Feb 17 15:43:20 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sun, 17 Feb 2008 07:43:20 -0800
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
In-Reply-To: <ulk5jvm31.fsf@agharta.de>
References: <KKEMLPLMIPKOHMILKBJJEEFJCCAA.wout.perquin@skynet.be>
	<ulk5jvm31.fsf@agharta.de>
Message-ID: <F16BE71D-505C-411B-88BB-2A6D86CBA50D@bobobeach.com>


I ran into this as well and I think the solution was to upgrade to a  
newer version of CFFI. I think it was the cffi+lotsstuff branch that  
fixed the problem for me. You might check on the CFFI-devel mailing  
list (and complain about the lack of a sane versioning numbering/ 
naming system there).

Cyrus

On Feb 17, 2008, at 3:50 AM, Edi Weitz wrote:

> On Sun, 17 Feb 2008 12:18:39 +0100, "Wout Perquin" <wout.perquin at skynet.be 
> > wrote:
>
>>> (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL)
>> The debugger says : the value of CL+SSL::thing is #([...]), which  
>> is not of
>> type (SIMPLE-ARRAY (UNSIGNED-BYTE 8)(*))
>> [condition of SIMPLE-TYPE-ERROR]
>> I did a google on "CL+SSL::thing SIMPLE-TYPE-ERROR" but no match
>
> Seems like something you should report to the CL+SSL mailing list.
>
> Cheers,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From wout.perquin at skynet.be  Sun Feb 17 16:44:42 2008
From: wout.perquin at skynet.be (Wout Perquin)
Date: Sun, 17 Feb 2008 17:44:42 +0100
Subject: [hunchentoot-devel] Hunchentoot and SSL on cmucl
In-Reply-To: <F16BE71D-505C-411B-88BB-2A6D86CBA50D@bobobeach.com>
Message-ID: <KKEMLPLMIPKOHMILKBJJKEFLCCAA.wout.perquin@skynet.be>

It was tested on the latest CFFI version (0.9.2), but given your remark
about the versioning I reinstalled 0.9.2. but the bug remains.
Wout

-----Original Message-----
From: tbnl-devel-bounces at common-lisp.net
[mailto:tbnl-devel-bounces at common-lisp.net]On Behalf Of Cyrus Harmon
Sent: zondag 17 februari 2008 16:43
To: General interest list for Hunchentoot and CL-WEBDAV
Subject: Re: [hunchentoot-devel] Hunchentoot and SSL on cmucl



I ran into this as well and I think the solution was to upgrade to a
newer version of CFFI. I think it was the cffi+lotsstuff branch that
fixed the problem for me. You might check on the CFFI-devel mailing
list (and complain about the lack of a sane versioning numbering/
naming system there).

Cyrus

On Feb 17, 2008, at 3:50 AM, Edi Weitz wrote:

> On Sun, 17 Feb 2008 12:18:39 +0100, "Wout Perquin" <wout.perquin at skynet.be
> > wrote:
>
>>> (SETF HUNCHENTOOT:*CATCH-ERRORS-P* NIL)
>> The debugger says : the value of CL+SSL::thing is #([...]), which
>> is not of
>> type (SIMPLE-ARRAY (UNSIGNED-BYTE 8)(*))
>> [condition of SIMPLE-TYPE-ERROR]
>> I did a google on "CL+SSL::thing SIMPLE-TYPE-ERROR" but no match
>
> Seems like something you should report to the CL+SSL mailing list.
>
> Cheers,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel



From hans at huebner.org  Mon Feb 18 09:39:40 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 18 Feb 2008 10:39:40 +0100
Subject: [hunchentoot-devel] CCL/OpenMCL and WITH-TIMEOUT
Message-ID: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>

With the upcoming 1.2 release of CCL (formerly called OpenMCL), the
old implementation of TIMER-REQUEST is no longer available.
Hunchentoot relies on this in its WITH-TIMEOUT implementation which is
(only) called from FORCE-OUTPUT*.  As asynchronous timeouts are
generally unsafe, I would like to get rid of WITH-TIMEOUT altogether.
Instead, I think it would be better to only use the underlying
streams' mechanisms for timeouts, if available.  CCL 1.2 will have
stream timeouts, LW already has them and the other Lisp
implementations will propably support some form of timeouts in I/O
sooner or later.

Does anyone here have sentiments regarding WITH-TIMEOUT?  If not, I'd
propose that WITH-TIMEOUT be totally removed from Hunchentoot.

-Hans


From hans at huebner.org  Mon Feb 18 11:31:27 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 18 Feb 2008 12:31:27 +0100
Subject: [hunchentoot-devel] Re: CCL/OpenMCL and WITH-TIMEOUT
In-Reply-To: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>
References: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>
Message-ID: <fd2982320802180331t6cf85c0p264d738e6207811d@mail.gmail.com>

On Feb 18, 2008 10:39 AM, Hans H?bner <hans at huebner.org> wrote:
> With the upcoming 1.2 release of CCL (formerly called OpenMCL), the
> old implementation of TIMER-REQUEST is no longer available.

I got actually fooled by the fact that TIMER-REQUEST and friends lives
in the CCL package, but is defined in the ACL-COMPAT system.  I'd
still want to get rid of it, so if anyone has comments, please make
them.

Thanks,
Hans

> Hunchentoot relies on this in its WITH-TIMEOUT implementation which is
> (only) called from FORCE-OUTPUT*.  As asynchronous timeouts are
> generally unsafe, I would like to get rid of WITH-TIMEOUT altogether.
> Instead, I think it would be better to only use the underlying
> streams' mechanisms for timeouts, if available.  CCL 1.2 will have
> stream timeouts, LW already has them and the other Lisp
> implementations will propably support some form of timeouts in I/O
> sooner or later.
>
> Does anyone here have sentiments regarding WITH-TIMEOUT?  If not, I'd
> propose that WITH-TIMEOUT be totally removed from Hunchentoot.
>
> -Hans
>


From edi at agharta.de  Mon Feb 18 16:15:39 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 18 Feb 2008 17:15:39 +0100
Subject: [hunchentoot-devel] CCL/OpenMCL and WITH-TIMEOUT
In-Reply-To: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>
	(Hans =?iso-8859-1?q?H=FCbner's?= message of "Mon,
	18 Feb 2008 10:39:40 +0100")
References: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>
Message-ID: <ulk5i1bro.fsf@agharta.de>

On Mon, 18 Feb 2008 10:39:40 +0100, "Hans H?bner" <hans at huebner.org> wrote:

> Does anyone here have sentiments regarding WITH-TIMEOUT?  If not,
> I'd propose that WITH-TIMEOUT be totally removed from Hunchentoot.

Not that I'm totally against it, but what's the reason?  Right now,
I'm seeing it as a kind of stopgap solution for Lisps without stream
timeouts.  If you don't have /any/ timeouts, you're pretty prone to
DoS attacks, aren't you?

Can't WITH-TIMEOUT be implemented in OpenMCL 1.2?


From edi at agharta.de  Mon Feb 18 16:28:13 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 18 Feb 2008 17:28:13 +0100
Subject: [hunchentoot-devel] CCL/OpenMCL and WITH-TIMEOUT
In-Reply-To: <ulk5i1bro.fsf@agharta.de> (Edi Weitz's message of "Mon, 18 Feb
	2008 17:15:39 +0100")
References: <fd2982320802180139q24825436r74ded345138a6bc2@mail.gmail.com>
	<ulk5i1bro.fsf@agharta.de>
Message-ID: <u8x1i1b6q.fsf@agharta.de>

On Mon, 18 Feb 2008 17:15:39 +0100, Edi Weitz <edi at agharta.de> wrote:

> On Mon, 18 Feb 2008 10:39:40 +0100, "Hans H?bner" <hans at huebner.org> wrote:
>
>> Does anyone here have sentiments regarding WITH-TIMEOUT?  If not,
>> I'd propose that WITH-TIMEOUT be totally removed from Hunchentoot.
>
> Not that I'm totally against it, but what's the reason?  Right now,
> I'm seeing it as a kind of stopgap solution for Lisps without stream
> timeouts.  If you don't have /any/ timeouts, you're pretty prone to
> DoS attacks, aren't you?

Although, having thought about this for the duration of another
cigarette, I tend to think that it's probably not so elegant and clear
to mix stream timeout mechanisms and "other" timeouts.  Yeah, maybe we
should get rid of this and rely on the streams to take care of that.
Might also increase pressure on the implementations which don't have
it yet.


From jeffrey at cunningham.net  Wed Feb 20 16:09:18 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 20 Feb 2008 08:09:18 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
Message-ID: <47BC50AE.6090309@cunningham.net>

I am having a problem that I can't replicate on demand but has been 
happening with increasing frequency. I am hoping some of you might 
suggest ways to troubleshoot it. I don't know that it is a Hunchentoot 
problem, per se, but it may be an interaction problem between 
Hunchentoot and Apache2 via mod_lisp2.

The symptom is the server is hung first thing in the morning when I 
check it. The cpu is at 99% activity on the server image (sbcl). When I 
look in the error_log I see dozens of these:

[Wed Feb 20 05:10:10 2008] [error] (70007)The timeout specified has 
expired: error reading from Lisp
[Wed Feb 20 05:12:23 2008] [error] (70007)The timeout specified has 
expired: error reading from Lisp
[Wed Feb 20 05:15:14 2008] [error] (70007)The timeout specified has 
expired: error reading from Lisp
[Wed Feb 20 05:18:57 2008] [error] (70007)The timeout specified has 
expired: error reading from Lisp

These generally correspond to googlebot activity:

66.249.73.165 - - [20/Feb/2008:05:09:10 -0800] "GET 
/intrepid-obstacle-map.html?hunchentoot-session=18%3A15F2776FDB3BD7CA852EBF74A3B40B2B 
HTTP/1.1" 500 673 "-" "Mozilla/5.0 (c
ompatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.73.165 - - [20/Feb/2008:05:11:23 -0800] "GET 
/index.html?hunchentoot-session=17%3A549FDE65186DCCFD1D2552AA79A49871 
HTTP/1.1" 500 673 "-" "Mozilla/5.0 (compatible; Googl
ebot/2.1; +http://www.google.com/bot.html)"
66.249.73.165 - - [20/Feb/2008:05:14:14 -0800] "GET 
/intrepid-obstacle-map.html?hunchentoot-session=17%3A549FDE65186DCCFD1D2552AA79A49871 
HTTP/1.1" 500 673 "-" "Mozilla/5.0 (c
ompatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.73.165 - - [20/Feb/2008:05:17:57 -0800] "GET 
/intrepid-robothon-2007.html?hunchentoot-session=15%3A3C06276A2A5CD0567B6A332AE52B3940 
HTTP/1.1" 500 673 "-" "Mozilla/5.0 (
compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

And finally, netstat shows a whole bunch of 4242 ports open (these are 
just a small subset:)

tcp      680      0 127.0.0.1:4242          127.0.0.1:38121         
CLOSE_WAIT
tcp      517      0 127.0.0.1:4242          127.0.0.1:44273         
CLOSE_WAIT
tcp        0      0 127.0.0.1:42641         127.0.0.1:4242          
ESTABLISHED
tcp        0      0 127.0.0.1:4242          127.0.0.1:51379         
ESTABLISHED
tcp      509      0 127.0.0.1:4242          127.0.0.1:33727         
CLOSE_WAIT
tcp      515      0 127.0.0.1:4242          127.0.0.1:44279         
CLOSE_WAIT
tcp        0      0 127.0.0.1:4242          127.0.0.1:48386         
ESTABLISHED
tcp      561      0 127.0.0.1:4242          127.0.0.1:44283         
CLOSE_WAIT
tcp        0      0 127.0.0.1:4242          127.0.0.1:42646         
ESTABLISHED
tcp      557      0 127.0.0.1:4242          127.0.0.1:43923         
CLOSE_WAIT
tcp        0      0 192.168.1.102:39210     192.168.1.2:993         
ESTABLISHED
tcp        0      0 127.0.0.1:42651         127.0.0.1:4242          
ESTABLISHED
tcp        0      0 127.0.0.1:4242          127.0.0.1:51382         
ESTABLISHED
tcp      589      0 127.0.0.1:4242          127.0.0.1:48377         
CLOSE_WAIT
tcp      589      0 127.0.0.1:4242          127.0.0.1:56928         
CLOSE_WAIT
tcp      589      0 127.0.0.1:4242          127.0.0.1:54195         
CLOSE_WAIT

The only way I can restart the server is to kill the process, restart 
it, and restart apache.

Any ideas?

Thanks.
--Jeff


From xach at xach.com  Wed Feb 20 16:17:25 2008
From: xach at xach.com (Zach Beane)
Date: Wed, 20 Feb 2008 11:17:25 -0500
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC50AE.6090309@cunningham.net>
References: <47BC50AE.6090309@cunningham.net>
Message-ID: <20080220161725.GG19732@xach.com>

On Wed, Feb 20, 2008 at 08:09:18AM -0800, Jeff Cunningham wrote:
> I am having a problem that I can't replicate on demand but has been 
> happening with increasing frequency. I am hoping some of you might 
> suggest ways to troubleshoot it. I don't know that it is a Hunchentoot 
> problem, per se, but it may be an interaction problem between 
> Hunchentoot and Apache2 via mod_lisp2.
> 
> The symptom is the server is hung first thing in the morning when I 
> check it. The cpu is at 99% activity on the server image (sbcl). When I 
> look in the error_log I see dozens of these:
[snip]

I had trouble like this in the past, and so far in every case it was
due to me making a mistake in the handler and going into an infinite
loop. I don't know if that's the case for you, but I had good luck
debugging it by adding extra info to thread names so I could identify
handlers that might be stuck.

http://xach.livejournal.com/132391.html has a writeup.

You can also troubleshoot by interrupting all threads and requesting
their backtrace (best to write it to a file or save them to a table or
something like that). That can also help identify problems.

Zach


From jeffrey at cunningham.net  Wed Feb 20 16:46:24 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 20 Feb 2008 08:46:24 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <20080220161725.GG19732@xach.com>
References: <47BC50AE.6090309@cunningham.net> <20080220161725.GG19732@xach.com>
Message-ID: <47BC5960.8050009@cunningham.net>

Zach Beane wrote:
> On Wed, Feb 20, 2008 at 08:09:18AM -0800, Jeff Cunningham wrote:
>   
>> I am having a problem that I can't replicate on demand but has been 
>> happening with increasing frequency. I am hoping some of you might 
>> suggest ways to troubleshoot it. I don't know that it is a Hunchentoot 
>> problem, per se, but it may be an interaction problem between 
>> Hunchentoot and Apache2 via mod_lisp2.
>>
>> The symptom is the server is hung first thing in the morning when I 
>> check it. The cpu is at 99% activity on the server image (sbcl). When I 
>> look in the error_log I see dozens of these:
>>     
> [snip]
>
> I had trouble like this in the past, and so far in every case it was
> due to me making a mistake in the handler and going into an infinite
> loop. I don't know if that's the case for you, but I had good luck
> debugging it by adding extra info to thread names so I could identify
> handlers that might be stuck.
>
> http://xach.livejournal.com/132391.html has a writeup.
>
> You can also troubleshoot by interrupting all threads and requesting
> their backtrace (best to write it to a file or save them to a table or
> something like that). That can also help identify problems.
>
> Zach
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
>   
Thanks, Zach. I just tried the following:

(mapcar (lambda (thread)
        (sb-thread:interrupt-thread thread
                            (lambda ()
                            (throw 'hunchentoot::handler-done
                              ""))))
        (sb-thread:list-all-threads))

And it says it can't find the tag 'hunchentoot::handler-done (I assume). 
Yet, it shows up in the list of package symbols, exported even:

attempt to THROW to a tag that does not exist: HANDLER-DONE
   [Condition of type SB-INT:SIMPLE-CONTROL-ERROR]

Restarts:
 0: [ABORT] Abort SLIME compilation.
 1: [ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker" {D813B61}>)

Backtrace:
  0: ("no debug information for frame")
  1: ((LAMBDA NIL))
  2: (SB-THREAD:INTERRUPT-THREAD #<SB-THREAD:THREAD "worker" {D813B61}> 
#<FUNCTION (LAMBDA NIL) {D84CC55}>)
  3: (SB-IMPL::MAP1 #<FUNCTION (LAMBDA (THREAD)) {D84CF95}> 
((#<SB-THREAD:THREAD "worker" {D813B61}> #<SB-THREAD:THREAD 
"hunchentoot-worker-34" {D7CB2D1}> #<SB-THREAD:THREAD 
"hunchentoot-worker-33" {D7D92B9}> #<SB-THREAD:THREAD 
"hunchentoot-worker-32" {D777351}> #<SB-THREAD:THREAD 
"hunchentoot-worker-31" {DA38F11}> #<SB-THREAD:THREAD 
"hunchentoot-worker-30" {DC5A989}> ...)) :LIST T)
  4: (MAPCAR #<FUNCTION (LAMBDA (THREAD)) {D84CF95}> (#<SB-THREAD:THREAD 
"worker" {D813B61}> #<SB-THREAD:THREAD "hunchentoot-worker-34" 
{D7CB2D1}> #<SB-THREAD:THREAD "hunchentoot-worker-33" {D7D92B9}> 
#<SB-THREAD:THREAD "hunchentoot-worker-32" {D777351}> #<SB-THREAD:THREAD 
"hunchentoot-worker-31" {DA38F11}> #<SB-THREAD:THREAD 
"hunchentoot-worker-30" {DC5A989}> ...))

--Jeff
 


From rsynnott at gmail.com  Wed Feb 20 16:53:23 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Wed, 20 Feb 2008 16:53:23 +0000
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC5960.8050009@cunningham.net>
References: <47BC50AE.6090309@cunningham.net> <20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net>
Message-ID: <24f203480802200853h4ea7a344hb8a20f822cd489c5@mail.gmail.com>

Google will also let you rate limit the naughty GoogleBot using their
Webmaster Tools thing.

Do individual requests do anything particularly computationally
intensive? Is Hunchentoot just hanging doing nothing, or is it using
the CPU? If SBCL, have you a moderately recent version? (Old ones had
fun interesting nasty threading issues.)
Rob


From xach at xach.com  Wed Feb 20 16:53:44 2008
From: xach at xach.com (Zach Beane)
Date: Wed, 20 Feb 2008 11:53:44 -0500
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC5960.8050009@cunningham.net>
References: <47BC50AE.6090309@cunningham.net> <20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net>
Message-ID: <20080220165344.GH19732@xach.com>

On Wed, Feb 20, 2008 at 08:46:24AM -0800, Jeff Cunningham wrote:
 
> And it says it can't find the tag 'hunchentoot::handler-done (I assume). 
> Yet, it shows up in the list of package symbols, exported even:
> 
> attempt to THROW to a tag that does not exist: HANDLER-DONE
>   [Condition of type SB-INT:SIMPLE-CONTROL-ERROR]

Right. That's because not all threads are handlers, so the non-handler
threads will signal an error. That code snippet is not very precise,
and I just ignored the errors I got.

Zach


From edi at agharta.de  Wed Feb 20 16:57:03 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 20 Feb 2008 17:57:03 +0100
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC5960.8050009@cunningham.net> (Jeff Cunningham's message of
	"Wed, 20 Feb 2008 08:46:24 -0800")
References: <47BC50AE.6090309@cunningham.net>
	<20080220161725.GG19732@xach.com> <47BC5960.8050009@cunningham.net>
Message-ID: <uhcg38t28.fsf@agharta.de>

On Wed, 20 Feb 2008 08:46:24 -0800, Jeff Cunningham <jeffrey at cunningham.net> wrote:

> And it says it can't find the tag 'hunchentoot::handler-done (I
> assume). Yet, it shows up in the list of package symbols, exported
> even:
>
> attempt to THROW to a tag that does not exist: HANDLER-DONE
>    [Condition of type SB-INT:SIMPLE-CONTROL-ERROR]

The fact that the symbol is there doesn't mean that the catch tag has
been established.  It looks like you're using THROW (or a function
which uses it like REDIRECT) from a place where you shouldn't.


From jeffrey at cunningham.net  Wed Feb 20 17:13:01 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 20 Feb 2008 09:13:01 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <24f203480802200853h4ea7a344hb8a20f822cd489c5@mail.gmail.com>
References: <47BC50AE.6090309@cunningham.net>
	<20080220161725.GG19732@xach.com>	<47BC5960.8050009@cunningham.net>
	<24f203480802200853h4ea7a344hb8a20f822cd489c5@mail.gmail.com>
Message-ID: <47BC5F9D.8000507@cunningham.net>

Robert Synnott wrote:
> Google will also let you rate limit the naughty GoogleBot using their
> Webmaster Tools thing.
>
> Do individual requests do anything particularly computationally
> intensive? Is Hunchentoot just hanging doing nothing, or is it using
> the CPU? If SBCL, have you a moderately recent version? (Old ones had
> fun interesting nasty threading issues.)
> Rob
> __________________
Yes, I know about the webmaster tools thing - it looks like they're hit 
rate is a page every twenty seconds or so when they are going through 
the site. It ought to be able to handle that.

Hunchentoot is hanging with the cpu hammered at 99-100%, like its in an 
infinite loop. And, no, nothing in the page generation should cause it 
to do more than blink. These pages are very simple text with a few 
embedded images.

My sbcl is pretty late model: 1.0.14 from sources. But I've noticed this 
same problem on a commercial site a couple times where I'm running 1.0.12.

--Jeff



From jeffrey at cunningham.net  Wed Feb 20 17:16:58 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 20 Feb 2008 09:16:58 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <uhcg38t28.fsf@agharta.de>
References: <47BC50AE.6090309@cunningham.net>	<20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net> <uhcg38t28.fsf@agharta.de>
Message-ID: <47BC608A.3080908@cunningham.net>

Edi Weitz wrote:
> On Wed, 20 Feb 2008 08:46:24 -0800, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>
>   
>> And it says it can't find the tag 'hunchentoot::handler-done (I
>> assume). Yet, it shows up in the list of package symbols, exported
>> even:
>>
>> attempt to THROW to a tag that does not exist: HANDLER-DONE
>>    [Condition of type SB-INT:SIMPLE-CONTROL-ERROR]
>>     
>
> The fact that the symbol is there doesn't mean that the catch tag has
> been established.  It looks like you're using THROW (or a function
> which uses it like REDIRECT) from a place where you shouldn't.
>
>   
That one went over my head. Does it mean that if I put a function like this:

(defun cancel-all-threads ()
  (mapcar (lambda (thread)
        (sb-thread:interrupt-thread thread
                            (lambda ()
                            (throw 'hunchentoot::handler-done
                              ""))))
        (sb-thread:list-all-threads)))

into, say, request.lisp (in hunchentoot), that it would find the tag?




From rsynnott at gmail.com  Wed Feb 20 17:18:08 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Wed, 20 Feb 2008 17:18:08 +0000
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC5F9D.8000507@cunningham.net>
References: <47BC50AE.6090309@cunningham.net> <20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net>
	<24f203480802200853h4ea7a344hb8a20f822cd489c5@mail.gmail.com>
	<47BC5F9D.8000507@cunningham.net>
Message-ID: <24f203480802200918v531df5b8q591558d4d2f55a2f@mail.gmail.com>

Have you slime running in it? You could possibly attach and poke
around a bit; not sure how useful it would be, though.
Rob


From edi at agharta.de  Wed Feb 20 22:42:18 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 20 Feb 2008 23:42:18 +0100
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47BC608A.3080908@cunningham.net> (Jeff Cunningham's message of
	"Wed, 20 Feb 2008 09:16:58 -0800")
References: <47BC50AE.6090309@cunningham.net>
	<20080220161725.GG19732@xach.com> <47BC5960.8050009@cunningham.net>
	<uhcg38t28.fsf@agharta.de> <47BC608A.3080908@cunningham.net>
Message-ID: <uir0j6yid.fsf@agharta.de>

On Wed, 20 Feb 2008 09:16:58 -0800, Jeff Cunningham <jeffrey at cunningham.net> wrote:

> That one went over my head. Does it mean that if I put a function
> like this:
>
> (defun cancel-all-threads ()
>   (mapcar (lambda (thread)
>         (sb-thread:interrupt-thread thread
>                             (lambda ()
>                             (throw 'hunchentoot::handler-done
>                               ""))))
>         (sb-thread:list-all-threads)))
>
> into, say, request.lisp (in hunchentoot), that it would find the
> tag?

Why don't you try it out yourself?

  CL-USER> (defun endless ()
             (format #.*standard-output*
                     "Interrupted by someone throwing ~S.~%"
                     (catch 'foo
                       (loop (sleep 1)))))
  ENDLESS
  CL-USER> (defun stop ()
             (throw 'foo 42))
  STOP
  CL-USER> (sb-thread:make-thread 'endless)
  #<SB-THREAD:THREAD {AEB0E11}>
  CL-USER> (sb-thread:interrupt-thread * 'stop)
  Interrupted by someone throwing 42.

But as I already said the catch tag has to be established for this to
work.  Look at the code, specifically at server.lisp, and you'll see
that you can't simply throw HANDLER-DONE at any time during the
lifetime of a Hunchentoot thread.  Or simply read the docs where it
says that you can throw this tag "during the lifetime of a handler."


From jeffrey at cunningham.net  Thu Feb 21 04:01:47 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 20 Feb 2008 20:01:47 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <uir0j6yid.fsf@agharta.de>
References: <47BC50AE.6090309@cunningham.net>	<20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net>	<uhcg38t28.fsf@agharta.de>
	<47BC608A.3080908@cunningham.net> <uir0j6yid.fsf@agharta.de>
Message-ID: <47BCF7AB.3070503@cunningham.net>

Edi Weitz wrote:
>> That one went over my head. Does it mean that if I put a function
>> like this:
>>
>> (defun cancel-all-threads ()
>>   (mapcar (lambda (thread)
>>         (sb-thread:interrupt-thread thread
>>                             (lambda ()
>>                             (throw 'hunchentoot::handler-done
>>                               ""))))
>>         (sb-thread:list-all-threads)))
>>
>> into, say, request.lisp (in hunchentoot), that it would find the
>> tag?
>>     
>
> Why don't you try it out yourself?
>
>   CL-USER> (defun endless ()
>              (format #.*standard-output*
>                      "Interrupted by someone throwing ~S.~%"
>                      (catch 'foo
>                        (loop (sleep 1)))))
>   ENDLESS
>   CL-USER> (defun stop ()
>              (throw 'foo 42))
>   STOP
>   CL-USER> (sb-thread:make-thread 'endless)
>   #<SB-THREAD:THREAD {AEB0E11}>
>   CL-USER> (sb-thread:interrupt-thread * 'stop)
>   Interrupted by someone throwing 42.
>
> But as I already said the catch tag has to be established for this to
> work.  Look at the code, specifically at server.lisp, and you'll see
> that you can't simply throw HANDLER-DONE at any time during the
> lifetime of a Hunchentoot thread.  Or simply read the docs where it
> says that you can throw this tag "during the lifetime of a handler."
>   
I didn't try it out at that point because I didn't understand it well 
enough to formulate an intelligent test case. Thank you for providing one.

I have in place some machinery now that should enable me to identify all 
the threads in play and their state the next time it hangs as per Zach's 
suggestions, so I'll have to wait and see. Can't troubleshoot it until 
it breaks unfortunately.

Thanks for the ideas.
--Jeff



From lispnewb at gmail.com  Sat Feb 23 04:02:55 2008
From: lispnewb at gmail.com (Lisp Newb)
Date: Fri, 22 Feb 2008 20:02:55 -0800
Subject: [hunchentoot-devel] Using javascript
Message-ID: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>

Apologies for an even newbier question, but here (
http://osdir.com/ml/lisp.lib.tbnl.general/2006-10/msg00063.html) I'm told I
should put a js file in the root directory of my website and then use code
like:

(:html
  (:head
    (:link :href "myfile.css" :rel "stylesheet" :type "text/css")
    (:script :src "myfile.js" :type "text/javascript" nil)

to access it.

I installed hunchentoot via asdf.  What's the root directory of my
website?  The directory containing  the lisp file that calls
start-server doesn't appear to be it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080222/c4de09a0/attachment.html>

From ctdean at sokitomi.com  Sat Feb 23 07:00:39 2008
From: ctdean at sokitomi.com (Chris Dean)
Date: Fri, 22 Feb 2008 23:00:39 -0800
Subject: [hunchentoot-devel] Using javascript
In-Reply-To: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>
	(Lisp Newb's message of "Fri, 22 Feb 2008 20:02:55 -0800")
References: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>
Message-ID: <m2r6f4jgx4.fsf@jacaranda.local>


"Lisp Newb" <lispnewb at gmail.com> writes:
> (:html
>   (:head
>     (:link :href "myfile.css" :rel "stylesheet" :type "text/css")
>     (:script :src "myfile.js" :type "text/javascript" nil)
>
> I installed hunchentoot via asdf.  What's the root directory of my
> website?  The directory containing the lisp file that calls
> start-server doesn't appear to be it.

I don't believe that hunchentoot does anything special with setting up
a root directory of your website.  So, it's just whatever the
directory of the Lisp process is.  You can either change-directory to
whatver you want the server root to be, or use fully qualified file
names.

Cheers,
Chris Dean



From leslie.polzer at gmx.net  Sat Feb 23 08:43:47 2008
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Sat, 23 Feb 2008 09:43:47 +0100 (CET)
Subject: [hunchentoot-devel] Using javascript
In-Reply-To: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>
References: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>
Message-ID: <63290.88.73.235.79.1203756227.squirrel@mail.stardawn.org>


Hello nameless Lisp newb,

> should put a js file in the root directory of my website and then use code

> I installed hunchentoot via asdf.  What's the root directory of my
> website?  The directory containing  the lisp file that calls
> start-server doesn't appear to be it.

Yeah, you'll have to define a handler first.

Read The Fine Tutorials:

  http://myblog.rsynnott.com/2007/09/getting-started-with-hunchento.html

  Leslie

-- 
My personal blog: http://blog.viridian-project.de/



From lispnewb at gmail.com  Sat Feb 23 10:58:33 2008
From: lispnewb at gmail.com (Lisp Newb)
Date: Sat, 23 Feb 2008 02:58:33 -0800
Subject: [hunchentoot-devel] Using javascript
In-Reply-To: <63290.88.73.235.79.1203756227.squirrel@mail.stardawn.org>
References: <1b11c94d0802222002o685746a0p5d5fbbdbfddf190a@mail.gmail.com>
	<63290.88.73.235.79.1203756227.squirrel@mail.stardawn.org>
Message-ID: <1b11c94d0802230258r150b7e4dx5cc9be405073418b@mail.gmail.com>

Alas!  I was indeed missing the javascript handler.  It's working now.
Thanks for the patience guys!

Nameless Lisp newb

2008/2/23, Leslie P. Polzer <leslie.polzer at gmx.net>:
>
>
> Hello nameless Lisp newb,
>
>
> > should put a js file in the root directory of my website and then use
> code
>
>
> > I installed hunchentoot via asdf.  What's the root directory of my
> > website?  The directory containing  the lisp file that calls
> > start-server doesn't appear to be it.
>
>
> Yeah, you'll have to define a handler first.
>
> Read The Fine Tutorials:
>
>   http://myblog.rsynnott.com/2007/09/getting-started-with-hunchento.html
>
>   Leslie
>
>
> --
> My personal blog: http://blog.viridian-project.de/
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080223/43181f8a/attachment.html>

From berlin.brown at gmail.com  Sat Feb 23 15:25:02 2008
From: berlin.brown at gmail.com (Berlin Brown)
Date: Sat, 23 Feb 2008 10:25:02 -0500
Subject: [hunchentoot-devel] Setting up hunchentoot,
	WARNING about thread support
Message-ID: <df27a55b0802230725t565ae560wa8cf3019cadb8db7@mail.gmail.com>

I am getting this message with hunchentoot, (most recent version as of today).

WARNING: Without thread support, this library is only useful for development.

My question, is this the normal mode of operation? Or do I really need
thread support to do anything useful?  Or were their flags I needed to
setup on install.  I am using SBCL 0.14 and I did the default install
with that clisp.  During the hunchentoot asdf-install, maybe there
were options that I skipped over.

This is ubuntu linux 7.10; (not using apt install for sbcl or hunchentoot)

-- 
Berlin Brown
http://botspiritcompany.com/botlist/spring/help/about.html


From xach at xach.com  Sat Feb 23 15:35:42 2008
From: xach at xach.com (Zach Beane)
Date: Sat, 23 Feb 2008 10:35:42 -0500
Subject: [hunchentoot-devel] Setting up hunchentoot,
	WARNING about thread support
In-Reply-To: <df27a55b0802230725t565ae560wa8cf3019cadb8db7@mail.gmail.com>
References: <df27a55b0802230725t565ae560wa8cf3019cadb8db7@mail.gmail.com>
Message-ID: <20080223153542.GW19732@xach.com>

On Sat, Feb 23, 2008 at 10:25:02AM -0500, Berlin Brown wrote:
> I am getting this message with hunchentoot, (most recent version as of today).
> 
> WARNING: Without thread support, this library is only useful for development.
> 
> My question, is this the normal mode of operation? Or do I really need
> thread support to do anything useful?  Or were their flags I needed to
> setup on install.  I am using SBCL 0.14 and I did the default install
> with that clisp.  During the hunchentoot asdf-install, maybe there
> were options that I skipped over.
> 
> This is ubuntu linux 7.10; (not using apt install for sbcl or hunchentoot)

You must use a SBCL with thread support enabled. I do this by adding a
file called customize-target-features.lisp in my SBCL source directory
that has this in it:

  (lambda (list) (pushnew :sb-thread list))

The SBCL built with that file present will have thread support, and I
use that for a few different Hunchentoot sites with no problems.

Zach


From wout.perquin at skynet.be  Sat Feb 23 15:46:05 2008
From: wout.perquin at skynet.be (Wout Perquin)
Date: Sat, 23 Feb 2008 16:46:05 +0100
Subject: [hunchentoot-devel] Setting up hunchentoot,
	WARNING about thread support
In-Reply-To: <df27a55b0802230725t565ae560wa8cf3019cadb8db7@mail.gmail.com>
Message-ID: <KKEMLPLMIPKOHMILKBJJOEGFCCAA.wout.perquin@skynet.be>

I copy from http://weitz.de/hunchentoot/
Hunchentoot talks with its front-end or with the client over TCP/IP sockets
and uses multiprocessing to handle several requests at the same time.
Therefore, it cannot be implemented completely in portable Common Lisp. It
currently works with LispWorks (which is the main development and testing
platform), CMUCL (with MP support), SBCL (with Unicode and thread support),
OpenMCL, and Allegro Common Lisp.

My understanding of the above is that you have to install threads to run a
web server.  I run CMUCL (with MP support) which works fine apart from SSL
:(

Cheers
-Wout
-----Original Message-----
From: tbnl-devel-bounces at common-lisp.net
[mailto:tbnl-devel-bounces at common-lisp.net]On Behalf Of Berlin Brown
Sent: zaterdag 23 februari 2008 16:25
To: tbnl-devel at common-lisp.net
Subject: [hunchentoot-devel] Setting up hunchentoot,WARNING about thread
support


I am getting this message with hunchentoot, (most recent version as of
today).

WARNING: Without thread support, this library is only useful for
development.

My question, is this the normal mode of operation? Or do I really need
thread support to do anything useful?  Or were their flags I needed to
setup on install.  I am using SBCL 0.14 and I did the default install
with that clisp.  During the hunchentoot asdf-install, maybe there
were options that I skipped over.

This is ubuntu linux 7.10; (not using apt install for sbcl or hunchentoot)

--
Berlin Brown
http://botspiritcompany.com/botlist/spring/help/about.html
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel



From jeffrey at cunningham.net  Sun Feb 24 02:12:26 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sat, 23 Feb 2008 18:12:26 -0800
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <20080220165344.GH19732@xach.com>
References: <47BC50AE.6090309@cunningham.net>
	<20080220161725.GG19732@xach.com>	<47BC5960.8050009@cunningham.net>
	<20080220165344.GH19732@xach.com>
Message-ID: <47C0D28A.70503@cunningham.net>

Zach Beane wrote:
> Right. That's because not all threads are handlers, so the non-handler
> threads will signal an error. That code snippet is not very precise,
> and I just ignored the errors I got.
>
> Zach
>   

Okay - it's doing it right now. 99-100% cpu showing up as sbcl on my 
webserver user (the only sbcl running under that user).
When I list out the notated threads I see the following. I'm not sure 
what I was expecting to see, but nothing stands out to me as a problem. 
All of them say "[finished & idle]". Can you interpret?

--Jeff

(#<SB-THREAD:THREAD "repl-thread" {F030409}>
 #<SB-THREAD:THREAD "reader-thread" {F030339}>
 #<SB-THREAD:THREAD "control-thread" {F030259}>
 #<SB-THREAD:THREAD "auto-flush-thread" {F030099}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1136%3A6A13236755E6BFCCC3994C86FF75CE20\" 
[finished & idle]" {DCD92A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1188%3A25D0F65BA3F9CB5F8848D24A394B5A87\" 
[finished & idle]" {DB552D1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1143%3AE13A4EFDF0FA675CCF10FCD34B0C19EB\" 
[finished & idle]" {DCF22A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-philosophy.html?hunchentoot-session=1188%3A25D0F65BA3F9CB5F8848D24A394B5A87\" 
[finished & idle]" {DC4A4E1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1157%3A20E10CFFC8FE2FEDB91EAC6C7C554F8C\" 
[finished & idle]" {DC632A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1148%3A306D0561E30ECFD4918E2DDABE1BBA8D\" 
[finished & idle]" {DAD52A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1167%3A982468B6F34710B4AA6ACF16FE1B05DB\" 
[finished & idle]" {DBD72A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1152%3A5DC6202211E106618E5EEF58F9D1AC91\" 
[finished & idle]" {DAE62A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1151%3AAAAC22F60C7EAB687EA5C6F04355688B\" 
[finished & idle]" {DC242A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1151%3AAAAC22F60C7EAB687EA5C6F04355688B\" 
[finished & idle]" {DB1A2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1196%3A212178577168731D2454185B7D8F0554\" 
[finished & idle]" {DAB52A1}>
 #<SB-THREAD:THREAD "Handler for \"/slime.html\" [finished & idle]" 
{DB2B2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1220%3AAF17981047A17996DFBD8F72406747EB\" 
[finished & idle]" {DA2C2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1219%3ACDBC9E26292EDF35F26E792A23038D5D\" 
[finished & idle]" {EFD02A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1184%3A7808D8B675B055C7CF210957A6037CE5\" 
[finished & idle]" {DA3A2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1217%3ACEF20AE79B65C45111EEEA664ADAADD9\" 
[finished & idle]" {E2E3681}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1189%3ABF3BCA4D06D4C89DD371E187D92D30B6\" 
[finished & idle]" {D9032A1}>
 #<SB-THREAD:THREAD "Handler for \"/ts7200.html\" [finished & idle]" 
{D91E2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1188%3A25D0F65BA3F9CB5F8848D24A394B5A87\" 
[finished & idle]" {D9322A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1117%3A135850BDF1BBA2BAEA4A1EAF54580B72\" 
[finished & idle]" {DA0F2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1182%3AD6355AA121CEDE6E24B3A4586ABCFE50\" 
[finished & idle]" {D8502A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1145%3A6950D17A5213E6C054F90C5F607631D5\" 
[finished & idle]" {D8852A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1155%3A7B38C20E78E979DECDB64E500EC22FA2\" 
[finished & idle]" {D8B32A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1143%3AE13A4EFDF0FA675CCF10FCD34B0C19EB\" 
[finished & idle]" {D7652A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1149%3AF3A5B129D307ED34BF1ECD3EEDE8CE5B\" 
[finished & idle]" {D9792D1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1156%3A6ECDBBD829964A74DB970C7FA9EA9697\" 
[finished & idle]" {D7BB2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-philosophy.html?hunchentoot-session=1166%3A45D7F9FAB0B8C917904F0F553EB246F8\" 
[finished & idle]" {D9582A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1141%3AD26E286D709B5826A51E461D94813B68\" 
[finished & idle]" {D97B2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1128%3A1233C2ACD90A914E382DAD2557276432\" 
[finished & idle]" {D7C02A1}>
 #<SB-THREAD:THREAD "Handler for \"/\" [finished & idle]" {D7882A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1153%3A5B822B1CFBCC621168187D094E3E2014\" 
[finished & idle]" {D6DA2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1167%3A982468B6F34710B4AA6ACF16FE1B05DB\" 
[finished & idle]" {D8C42A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid/Intrepid_001_th.jpg?hunchentoot-session=1209%3AD5CE6247382306CAF9115845A594C128\" 
[finished & idle]" {D8EA2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1154%3A32344CE5830E371C7B0F192C597257DD\" 
[finished & idle]" {D8102D1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1153%3A5B822B1CFBCC621168187D094E3E2014\" 
[finished & idle]" {D8122A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1154%3A32344CE5830E371C7B0F192C597257DD\" 
[finished & idle]" {D6192D1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1183%3AC7780577DC441B2BB56915A75313BFB3\" 
[finished & idle]" {D56D2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1140%3AF6B64C2D8CCA9783DE0E190057497AE4\" 
[finished & idle]" {D59C2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1194%3A163A0D0028182806A9CDD029D8C07601\" 
[finished & idle]" {D5542A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1214%3AE9E6EEEF287C09954F0C55A2305FBA1E\" 
[finished & idle]" {D6402A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1194%3A163A0D0028182806A9CDD029D8C07601\" 
[finished & idle]" {D5F4719}>
 #<SB-THREAD:THREAD "Handler for \"/ts7200.html\" [finished & idle]" 
{D5F62A1}>
 #<SB-THREAD:THREAD "Handler for \"/ts7200.html\" [finished & idle]" 
{D61B2A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1218%3A339FB8475FBBCAC25B012C5E363635FB\" 
[finished & idle]" {D5762A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1192%3A65574B358B655C0E7E3A0EA43680AED6\" 
[finished & idle]" {D7342A1}>
 #<SB-THREAD:THREAD "Handler for \"/ts7200.html\" [finished & idle]" 
{D6B02A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1219%3ACDBC9E26292EDF35F26E792A23038D5D\" 
[finished & idle]" {D6F32A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1220%3AAF17981047A17996DFBD8F72406747EB\" 
[finished & idle]" {D5D62A1}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-obstacle-map.html?hunchentoot-session=1202%3AC12DEAF5F5AAD8ECB6FBF9F1D31C1B8F\" 
[finished & idle]" {F17B579}>
 #<SB-THREAD:THREAD "Handler for 
\"/intrepid-robogames-2007.html?hunchentoot-session=1182%3AD6355AA121CEDE6E24B3A4586ABCFE50\" 
[finished & idle]" {D699F11}>
 #<SB-THREAD:THREAD "Swank 4005" {D6936D1}>
 #<SB-THREAD:THREAD "hunchentoot-listener-1" {D5C3F61}>
 #<SB-THREAD:THREAD "initial thread" {D4C2089}>)



From xach at xach.com  Sun Feb 24 23:21:21 2008
From: xach at xach.com (Zach Beane)
Date: Sun, 24 Feb 2008 18:21:21 -0500
Subject: [hunchentoot-devel] Server sporadically hanging
In-Reply-To: <47C0D28A.70503@cunningham.net>
References: <47BC50AE.6090309@cunningham.net> <20080220161725.GG19732@xach.com>
	<47BC5960.8050009@cunningham.net> <20080220165344.GH19732@xach.com>
	<47C0D28A.70503@cunningham.net>
Message-ID: <20080224232121.GX19732@xach.com>

On Sat, Feb 23, 2008 at 06:12:26PM -0800, Jeff Cunningham wrote:
> Zach Beane wrote:
> >Right. That's because not all threads are handlers, so the non-handler
> >threads will signal an error. That code snippet is not very precise,
> >and I just ignored the errors I got.
> >
> >Zach
> >  
> 
> Okay - it's doing it right now. 99-100% cpu showing up as sbcl on my 
> webserver user (the only sbcl running under that user).
> When I list out the notated threads I see the following. I'm not sure 
> what I was expecting to see, but nothing stands out to me as a problem. 
> All of them say "[finished & idle]". Can you interpret?

Nope, I got nothin'. The next thing I'd try, if I were you, is
profiling all threads with sb-sprof to see where time is being spent.

Zach


From abadichi at bezeqint.net  Mon Feb 25 00:59:32 2008
From: abadichi at bezeqint.net (Ariel Badichi)
Date: Mon, 25 Feb 2008 02:59:32 +0200
Subject: [hunchentoot-devel] EQ used when comparing numbers [patch]
Message-ID: <87skzhkg0b.fsf@sneeze.site>


I found two places where EQ was used when comparing numbers.  The
following patch replaces each occurrence with EQL.

Ariel

--- headers.lisp~	2008-02-13 18:02:17.000000000 +0200
+++ headers.lisp	2008-02-25 02:31:03.000000000 +0200
@@ -105,7 +105,7 @@
                 ;; is no content)
                 (or chunkedp
                     head-request-p
-                    (eq (return-code) +http-not-modified+)
+                    (eql (return-code) +http-not-modified+)
                     (content-length)
                     content)))
         ;; now set headers for keep-alive and chunking

--- server.lisp~	2008-02-13 18:02:18.000000000 +0200
+++ server.lisp	2008-02-25 02:31:16.000000000 +0200
@@ -420,7 +420,7 @@
                                                    backtrace)))))
                     (with-debugger 
                       ;; skip dispatch if bad request
-                      (when (eq (return-code) +http-ok+)
+                      (when (eql (return-code) +http-ok+)
                         ;; now do the work
                         (dispatch-request *dispatch-table*)))))
               (when error



From edi at agharta.de  Thu Feb 28 23:08:35 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 29 Feb 2008 00:08:35 +0100
Subject: [hunchentoot-devel] EQ used when comparing numbers [patch]
In-Reply-To: <87skzhkg0b.fsf@sneeze.site> (Ariel Badichi's message of "Mon,
	25 Feb 2008 02:59:32 +0200")
References: <87skzhkg0b.fsf@sneeze.site>
Message-ID: <uk5ko3ci4.fsf@agharta.de>

On Mon, 25 Feb 2008 02:59:32 +0200, Ariel Badichi <abadichi at bezeqint.net> wrote:

> I found two places where EQ was used when comparing numbers.  The
> following patch replaces each occurrence with EQL.

Thanks.  Will be in the next release.

Edi.