From alemmens at xs4all.nl  Fri Aug  7 13:09:50 2009
From: alemmens at xs4all.nl (Arthur Lemmens)
Date: Fri, 07 Aug 2009 15:09:50 +0200
Subject: [hunchentoot-devel] European Common Lisp Meeting
Message-ID: <op.uyamuoznwpmq96@smtp.xs4all.nl>

Hi,
 
We just want to remind you that the registration deadline for this year's
ECLM (European Common Lisp Meeting) is August 15.  You can still register
at
 
  http://weitz.de/eclm2009
 
We hope to see you in Hamburg,
 
Edi Weitz & Arthur Lemmens






From girzel at gmail.com  Mon Aug 10 04:26:19 2009
From: girzel at gmail.com (Eric Abrahamsen)
Date: Mon, 10 Aug 2009 12:26:19 +0800
Subject: [hunchentoot-devel] create-groups-bind-regex-dispatcher
Message-ID: <913E106E-74E1-4592-A691-6741F49422FF@gmail.com>

I see that several years ago there was once a macro that created a  
regex dispatcher and passed its group matches to the handler as  
arguments. It seems to have disappeared, but I found a copy here:
http://cl-debian.alioth.debian.org/repository/moved-to-pkg-common-lisp/tbnl-upstream/contrib/create-groups-bind-regex-dispatcher/create-groups-bind-regex-dispatcher.lisp

Does anyone know if this work with Hunchentoot 1.0? Was it judged not  
useful enough to include in the official release? I know it's not  
strictly necessary since you've still got access to the url path in  
the handler, but it does seem like a tidy convenience...

Thanks
Eric



From sky at viridian-project.de  Mon Aug 10 07:36:44 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Mon, 10 Aug 2009 09:36:44 +0200 (CEST)
Subject: [hunchentoot-devel] create-groups-bind-regex-dispatcher
In-Reply-To: <913E106E-74E1-4592-A691-6741F49422FF@gmail.com>
References: <913E106E-74E1-4592-A691-6741F49422FF@gmail.com>
Message-ID: <b8ceb9012c0a6465a8d31b98b541326c.squirrel@mail.stardawn.org>


Eric Abrahamsen wrote:
> I see that several years ago there was once a macro that created a
> regex dispatcher and passed its group matches to the handler as
> arguments. It seems to have disappeared, but I found a copy here:
> http://cl-debian.alioth.debian.org/repository/moved-to-pkg-common-lisp/tbnl-upstream/contrib/create-groups-bind-regex-dispatcher/create-groups-bind-regex-dispatcher.lisp
>
> Does anyone know if this work with Hunchentoot 1.0?

It looks like it would.


> Was it judged not
> useful enough to include in the official release? I know it's not
> strictly necessary since you've still got access to the url path in
> the handler, but it does seem like a tidy convenience...

I don't know what the policies for including convenience stuff are,
but it's neat indeed.

  Leslie

-- 
http://www.linkedin.com/in/polzer




From edi at agharta.de  Mon Aug 10 09:54:01 2009
From: edi at agharta.de (Edi Weitz)
Date: Mon, 10 Aug 2009 11:54:01 +0200
Subject: [hunchentoot-devel] create-groups-bind-regex-dispatcher
In-Reply-To: <b8ceb9012c0a6465a8d31b98b541326c.squirrel@mail.stardawn.org>
References: <913E106E-74E1-4592-A691-6741F49422FF@gmail.com>
	<b8ceb9012c0a6465a8d31b98b541326c.squirrel@mail.stardawn.org>
Message-ID: <b56421a00908100254m5d70f585vc2d18a2f1ce70e58@mail.gmail.com>

On Mon, Aug 10, 2009 at 9:36 AM, Leslie P.
Polzer<sky at viridian-project.de> wrote:

> I don't know what the policies for including convenience stuff are

I removed the "contrib" directory a while ago already because I didn't
want to maintain it.  If someone wants to host additions like this in
a separate repository, I'd be happy to add a link to it from the
Hunchentoot website, though.

Cheers,
Edi.



From girzel at gmail.com  Mon Aug 10 11:57:23 2009
From: girzel at gmail.com (Eric Abrahamsen)
Date: Mon, 10 Aug 2009 19:57:23 +0800
Subject: [hunchentoot-devel] create-groups-bind-regex-dispatcher
In-Reply-To: <b56421a00908100254m5d70f585vc2d18a2f1ce70e58@mail.gmail.com>
References: <913E106E-74E1-4592-A691-6741F49422FF@gmail.com>
	<b8ceb9012c0a6465a8d31b98b541326c.squirrel@mail.stardawn.org>
	<b56421a00908100254m5d70f585vc2d18a2f1ce70e58@mail.gmail.com>
Message-ID: <AB7C5B10-216B-41D7-AD39-C40F6F49454F@gmail.com>


On Aug 10, 2009, at 5:54 PM, Edi Weitz wrote:

> On Mon, Aug 10, 2009 at 9:36 AM, Leslie P.
> Polzer<sky at viridian-project.de> wrote:
>
>> I don't know what the policies for including convenience stuff are
>
> I removed the "contrib" directory a while ago already because I didn't
> want to maintain it.  If someone wants to host additions like this in
> a separate repository, I'd be happy to add a link to it from the
> Hunchentoot website, though.

If there are many of these ex-Contrib additions floating around the  
web, that seems like a good idea. Otherwise this particular macro  
wasn't hard to google...

Eric

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




From rklinda at gmail.com  Wed Aug 12 12:09:41 2009
From: rklinda at gmail.com (Richard KLINDA)
Date: Wed, 12 Aug 2009 14:09:41 +0200
Subject: [hunchentoot-devel] maybe bug + patch
Message-ID: <87r5vhfd2y.fsf@gmail.com>

Hello, I may have found a bug.

After stopping an acceptor with STOP, one can't start it again with
START, because the START method doesn't reset the value of
acceptor-shutdown-p to NIL, so the listener returns/quits instantly.  See the
attached trivial patch, that fixes the issue for me, but maybe I'm just
missing something here.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hunch.patch
Type: text/x-diff
Size: 385 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090812/587d4b6a/attachment.patch>
-------------- next part --------------

-- 
Richard

From jmckitrick at gmail.com  Wed Aug 12 13:45:41 2009
From: jmckitrick at gmail.com (Jonathon McKitrick)
Date: Wed, 12 Aug 2009 09:45:41 -0400
Subject: [hunchentoot-devel] CLOS versus closures
Message-ID: <c93a90e60908120645h62a988b5u1e9210595f81df94@mail.gmail.com>

quick question... Hunchentoot recently (?) moved to a more OO model,
correct?  I'm just curious... since lambda expressions, closures, macros,
and other lisp constructs are often considered 'better' than CLOS (less
verbose, less overhead), what made Edi decide to move to the more OO design?
 Surely it wasn't just popular demand.  ;-)

-- 

Jonathon McKitrick
http://moltencopper.com



From peter at gigamonkeys.com  Wed Aug 12 13:50:23 2009
From: peter at gigamonkeys.com (Peter Seibel)
Date: Wed, 12 Aug 2009 06:50:23 -0700
Subject: [hunchentoot-devel] CLOS versus closures
In-Reply-To: <c93a90e60908120645h62a988b5u1e9210595f81df94@mail.gmail.com>
References: <c93a90e60908120645h62a988b5u1e9210595f81df94@mail.gmail.com>
Message-ID: <40e4e7e50908120650w450a05f7i8d42968107e7a3a@mail.gmail.com>

Hmmm. I'm not sure those things are "often considered 'better'" except
perhaps by Paul Graham. Anyway, the current architecture, as I
understand it, is designed to be extensible in various ways. To build
that level of extensibility using closures, etc. you would end up
implementing something like CLOS.

-Peter

On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrick<jmckitrick at gmail.com> wrote:
> quick question... Hunchentoot recently (?) moved to a more OO model,
> correct? ?I'm just curious... since lambda expressions, closures, macros,
> and other lisp constructs are often considered 'better' than CLOS (less
> verbose, less overhead), what made Edi decide to move to the more OO design?
> ?Surely it wasn't just popular demand. ?;-)
>
> --
>
> Jonathon McKitrick
> http://moltencopper.com
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
Peter Seibel
http://www.codersatwork.com/
http://www.gigamonkeys.com/blog/



From edi at agharta.de  Wed Aug 12 15:27:31 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 12 Aug 2009 17:27:31 +0200
Subject: [hunchentoot-devel] CLOS versus closures
In-Reply-To: <40e4e7e50908120650w450a05f7i8d42968107e7a3a@mail.gmail.com>
References: <c93a90e60908120645h62a988b5u1e9210595f81df94@mail.gmail.com>
	<40e4e7e50908120650w450a05f7i8d42968107e7a3a@mail.gmail.com>
Message-ID: <b56421a00908120827u3f5ca86yf1a4a80f1d63ef5a@mail.gmail.com>

Thanks Peter, that's basically the same answer I would have given... :)

On Wed, Aug 12, 2009 at 3:50 PM, Peter Seibel<peter at gigamonkeys.com> wrote:
> Hmmm. I'm not sure those things are "often considered 'better'" except
> perhaps by Paul Graham. Anyway, the current architecture, as I
> understand it, is designed to be extensible in various ways. To build
> that level of extensibility using closures, etc. you would end up
> implementing something like CLOS.
>
> -Peter
>
> On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrick<jmckitrick at gmail.com> wrote:
>> quick question... Hunchentoot recently (?) moved to a more OO model,
>> correct? ?I'm just curious... since lambda expressions, closures, macros,
>> and other lisp constructs are often considered 'better' than CLOS (less
>> verbose, less overhead), what made Edi decide to move to the more OO design?
>> ?Surely it wasn't just popular demand. ?;-)
>>
>> --
>>
>> Jonathon McKitrick
>> http://moltencopper.com
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
>
>
> --
> Peter Seibel
> http://www.codersatwork.com/
> http://www.gigamonkeys.com/blog/
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>



From edi at agharta.de  Wed Aug 12 15:25:55 2009
From: edi at agharta.de (Edi Weitz)
Date: Wed, 12 Aug 2009 17:25:55 +0200
Subject: [hunchentoot-devel] maybe bug + patch
In-Reply-To: <87r5vhfd2y.fsf@gmail.com>
References: <87r5vhfd2y.fsf@gmail.com>
Message-ID: <b56421a00908120825s20ac70dj8f4b68a66a7426ad@mail.gmail.com>

Hi Richard,

Thanks for the patch.  I'm currently on vacation, so I won't be able
to look into this until the end of the month, but can you confirm that
with this change you can stop and start the same acceptor several
times without problems?  Which Lisp implementation did you test this
on?  (I'm asking because Hans and I briefly looked at this a couple of
weeks ago and we thought it wasn't totally trivial.)

Thanks,
Edi.


On Wed, Aug 12, 2009 at 2:09 PM, Richard KLINDA<rklinda at gmail.com> wrote:
> Hello, I may have found a bug.
>
> After stopping an acceptor with STOP, one can't start it again with
> START, because the START method doesn't reset the value of
> acceptor-shutdown-p to NIL, so the listener returns/quits instantly. ?See the
> attached trivial patch, that fixes the issue for me, but maybe I'm just
> missing something here.
>
>
>
> --
> Richard
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



From jmckitrick at gmail.com  Wed Aug 12 16:53:06 2009
From: jmckitrick at gmail.com (Jonathon McKitrick)
Date: Wed, 12 Aug 2009 12:53:06 -0400
Subject: [hunchentoot-devel] CLOS versus closures
In-Reply-To: <b56421a00908120827u3f5ca86yf1a4a80f1d63ef5a@mail.gmail.com>
References: <c93a90e60908120645h62a988b5u1e9210595f81df94@mail.gmail.com>
	<40e4e7e50908120650w450a05f7i8d42968107e7a3a@mail.gmail.com>
	<b56421a00908120827u3f5ca86yf1a4a80f1d63ef5a@mail.gmail.com>
Message-ID: <c93a90e60908120953i5666c20aga63d03a9757ed915@mail.gmail.com>

I admit, I've been caught up in the On Lisp mentality lately.  It
seems intriguing, especially because CLOS can be so verbose, and
macros seem to work more naturally with closures, from what I have
learned.

So the best answer here is CLOS is the best way to add extensibility
to Hunchentoot, correct?

On Wed, Aug 12, 2009 at 11:27 AM, Edi Weitz<edi at agharta.de> wrote:
> Thanks Peter, that's basically the same answer I would have given... :)
>
> On Wed, Aug 12, 2009 at 3:50 PM, Peter Seibel<peter at gigamonkeys.com> wrote:
>> Hmmm. I'm not sure those things are "often considered 'better'" except
>> perhaps by Paul Graham. Anyway, the current architecture, as I
>> understand it, is designed to be extensible in various ways. To build
>> that level of extensibility using closures, etc. you would end up
>> implementing something like CLOS.
>>
>> -Peter
>>
>> On Wed, Aug 12, 2009 at 6:45 AM, Jonathon McKitrick<jmckitrick at gmail.com> wrote:
>>> quick question... Hunchentoot recently (?) moved to a more OO model,
>>> correct? ?I'm just curious... since lambda expressions, closures, macros,
>>> and other lisp constructs are often considered 'better' than CLOS (less
>>> verbose, less overhead), what made Edi decide to move to the more OO design?
>>> ?Surely it wasn't just popular demand. ?;-)
>>>
>>> --
>>>
>>> Jonathon McKitrick
>>> http://moltencopper.com
>>>
>>> _______________________________________________
>>> tbnl-devel site list
>>> tbnl-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>
>>
>>
>> --
>> Peter Seibel
>> http://www.codersatwork.com/
>> http://www.gigamonkeys.com/blog/
>>
>> _______________________________________________
>> 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
>



-- 

Jonathon McKitrick
http://moltencopper.com



From patrick.may at mac.com  Sat Aug 15 20:44:06 2009
From: patrick.may at mac.com (Patrick May)
Date: Sat, 15 Aug 2009 16:44:06 -0400
Subject: [hunchentoot-devel] Error in long running Hunchentoot process
Message-ID: <A8EFA9D4-E329-4434-8714-786FEBFE9846@mac.com>

	I have a site that uses Clozure and Hunchentoot.  At the moment it's  
primarily serving static content.  After being up for a few days, I  
got the following error message in the log file for the ccl process:

Welcome to Clozure Common Lisp Version 1.3-r11936  (LinuxX8664)!
?
 > Error: #<STRING-OUTPUT-STREAM  :CLOSED #x300041C1B52D> is closed
 > While executing: CCL::STREAM-IS-CLOSED, in process Hunchentoot  
listener (*:808
0)(3).


;;;
;;; #<PROCESS Hunchentoot listener (*:8080)(3) [Reset] #x300041B94CFD>  
requires
access to Shared Terminal Input
;;; Type (:y 3) to yield control to this thread.
;;;
;Compiler warnings :
;   In SAVE-PRESENTED-OBJECT: Undeclared free variable OBJECT (3  
references)
;   In SAVE-PRESENTED-OBJECT: Unused lexical variable #|symbol not  
found in home
  package!!|#SWANK::OBJECT

The Hunchentoot message log file contains a number of lines like this:

[2009-08-10 16:54:46 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041BF867D>
[2009-08-10 16:54:46 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041BF730D>
[2009-08-10 16:56:09 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/11) #x300041BF5BBD>
[2009-08-10 21:18:46 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041BBE12D>
[2009-08-10 22:38:23 [INFO]] Default handler called for script / 
robots.txt
[2009-08-11 00:39:55 [INFO]] Default handler called for script / 
w00tw00t.at.ISC.
SANS.DFind:)
[2009-08-11 00:39:55 [ERROR]] Error while processing connection: on  
#<BASIC-TCP-
STREAM ISO-8859-1 (SOCKET/8) #x300041C1D33D> :
Connection reset by peer (error #104) during read
[2009-08-11 02:08:49 [INFO]] Default handler called for script / 
favicon.ico
[2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C1993D>
[2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/11) #x300041C181CD>
[2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C1AC9D>
[2009-08-11 02:17:19 [INFO]] Default handler called for script /fastenv
[2009-08-11 02:17:20 [ERROR]] Error while processing connection: on  
#<BASIC-TCP-
STREAM ISO-8859-1 (SOCKET/12) #x300041C16A7D> :
Connection reset by peer (error #104) during read
[2009-08-11 02:18:25 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C143ED>
[2009-08-11 02:23:19 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C130AD>
[2009-08-11 02:55:18 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C11D6D>
[2009-08-11 03:24:51 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C0F6ED>
[2009-08-11 03:35:35 [INFO]] Default handler called for script /fastenv
[2009-08-11 03:35:36 [ERROR]] Error while processing connection: on  
#<BASIC-TCP-
STREAM ISO-8859-1 (SOCKET/9) #x300041BC41CD> :
Connection reset by peer (error #104) during read
[2009-08-11 03:42:48 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C1E39D>
[2009-08-11 03:42:48 [ERROR]] Error while processing connection: Input  
timeout o
n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C1D03D>

Do I have something misconfigured?

Thanks,

Patrick




From hans.huebner at gmail.com  Sun Aug 16 13:17:52 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sun, 16 Aug 2009 09:17:52 -0400
Subject: [hunchentoot-devel] Error in long running Hunchentoot process
In-Reply-To: <A8EFA9D4-E329-4434-8714-786FEBFE9846@mac.com>
References: <A8EFA9D4-E329-4434-8714-786FEBFE9846@mac.com>
Message-ID: <fd2982320908160617p1dc25acck616e67fd952fe642@mail.gmail.com>

Hi Patrick,

On Sat, Aug 15, 2009 at 16:44, Patrick May<patrick.may at mac.com> wrote:
> ? ? ? ?I have a site that uses Clozure and Hunchentoot. ?At the moment it's
> primarily serving static content. ?After being up for a few days, I
> got the following error message in the log file for the ccl process:

This:

> ?> Error: #<STRING-OUTPUT-STREAM ?:CLOSED #x300041C1B52D> is closed
> ?> While executing: CCL::STREAM-IS-CLOSED, in process Hunchentoot
> listener (*:808
> 0)(3).

looks like some real bug or problem, but it is not really possible to
diagnose it further without seeing a strack trace.  Can you

> ;;; #<PROCESS Hunchentoot listener (*:8080)(3) [Reset] #x300041B94CFD>
> requires
> access to Shared Terminal Input
> ;;; Type (:y 3) to yield control to this thread.

and then type :b to see a backtrace of the process that has crashed?

I don't know what these:

> ;Compiler warnings :
> ; ? In SAVE-PRESENTED-OBJECT: Undeclared free variable OBJECT (3
> references)
> ; ? In SAVE-PRESENTED-OBJECT: Unused lexical variable #|symbol not
> found in home
> ?package!!|#SWANK::OBJECT

are about, but I suspect that they are from junk typed into the repl
or bugs in your program.

> The Hunchentoot message log file contains a number of lines like this:

The messages below are harmless, and many of them do not occur with
the development version of Hunchentoot and usocket.

> [2009-08-10 16:54:46 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041BF867D>
> [2009-08-10 16:54:46 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041BF730D>
> [2009-08-10 16:56:09 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/11) #x300041BF5BBD>
> [2009-08-10 21:18:46 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041BBE12D>
> [2009-08-10 22:38:23 [INFO]] Default handler called for script /
> robots.txt
> [2009-08-11 00:39:55 [INFO]] Default handler called for script /
> w00tw00t.at.ISC.
> SANS.DFind:)
> [2009-08-11 00:39:55 [ERROR]] Error while processing connection: on
> #<BASIC-TCP-
> STREAM ISO-8859-1 (SOCKET/8) #x300041C1D33D> :
> Connection reset by peer (error #104) during read
> [2009-08-11 02:08:49 [INFO]] Default handler called for script /
> favicon.ico
> [2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C1993D>
> [2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/11) #x300041C181CD>
> [2009-08-11 02:09:09 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C1AC9D>
> [2009-08-11 02:17:19 [INFO]] Default handler called for script /fastenv
> [2009-08-11 02:17:20 [ERROR]] Error while processing connection: on
> #<BASIC-TCP-
> STREAM ISO-8859-1 (SOCKET/12) #x300041C16A7D> :
> Connection reset by peer (error #104) during read
> [2009-08-11 02:18:25 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C143ED>
> [2009-08-11 02:23:19 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C130AD>
> [2009-08-11 02:55:18 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C11D6D>
> [2009-08-11 03:24:51 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C0F6ED>
> [2009-08-11 03:35:35 [INFO]] Default handler called for script /fastenv
> [2009-08-11 03:35:36 [ERROR]] Error while processing connection: on
> #<BASIC-TCP-
> STREAM ISO-8859-1 (SOCKET/9) #x300041BC41CD> :
> Connection reset by peer (error #104) during read
> [2009-08-11 03:42:48 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/8) #x300041C1E39D>
> [2009-08-11 03:42:48 [ERROR]] Error while processing connection: Input
> timeout o
> n #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/9) #x300041C1D03D>
>
> Do I have something misconfigured?

I do not think that you have a configuration problem, but I'd
recommend that you upgrade to a recent version of Hunchentoot and its
dependencies from Subversion (http://bknr.net/svn/ediware) before
investigating the problem further.

-Hans



From s11 at member.fsf.org  Fri Aug 21 03:28:55 2009
From: s11 at member.fsf.org (Stephen Compall)
Date: Thu, 20 Aug 2009 22:28:55 -0500
Subject: [hunchentoot-devel] Problem with POST-PARAMETERS in multipart POSTs
	after r4438
In-Reply-To: <fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com>
	("Hans =?utf-8?Q?H=C3=BCbner=22's?= message of "Wed,
	22 Jul 2009 18:25:59 +0200")
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com>
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com>
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org>
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com>
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org>
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com>
	<46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org>
	<fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com>
Message-ID: <m2bpm9zvyg.fsf_-_@nocandy.dyndns.org>

Hans H?bner <hans.huebner at gmail.com> writes:
> Peter, I have committed your fix to the development version of
> Hunchentoot.  Leslie, thank you for reviewing it!

As of r4438 (Peter's patch), I believe this wipes out post-parameters of
multipart/form-data POST requests and causes the relevant requests to
time out.

Specifically, on a multipart/form-data request, the first call to
`post-parameters` yields a sensible result, whereas future calls yield
NIL after timing out.

The solution proper is in the first hunk of the patch below, which
removes the ability to FORCE maybe-read-post-parameters to reread a
multipart/form-data request, because it can't do that, having emptied
the stream of the necessary data.

The second hunk, which incidentally fixes the problem as well (only by
avoiding the confusing behavior of maybe-read-post-parameters in the
common case of POSTing a non-empty set of parameters, rather than
solving it), is a specific followup to r4438, which in combination with
the first hunk merely prevents post-parameters from recalculating the
alist from the raw data on every call.

Were the first hunk to be changed to warn in the specific case it
avoids, the second hunk would also serve to eliminate spurious warnings
about being unable to reread multipart posts.  So I believe including
both would be ideal.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hunchentoot-multipart-parms-4438.diff
Type: text/x-diff
Size: 1219 bytes
Desc: the patch
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090820/77da559a/attachment.diff>
-------------- next part --------------

-- 
Sorry but you say Nibiru is a Hoax?  Doesnt Exist?  So maybe The
Sumerian people doesnt exist also! --Anonymous by way of SkI

From hans.huebner at gmail.com  Fri Aug 21 12:36:11 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 21 Aug 2009 08:36:11 -0400
Subject: [hunchentoot-devel] Problem with POST-PARAMETERS in multipart
	POSTs after r4438
In-Reply-To: <m2bpm9zvyg.fsf_-_@nocandy.dyndns.org>
References: <40e4e7e50906011421s48444931g20c3e17a5b819647@mail.gmail.com> 
	<40e4e7e50907211609m5ef068acye7a0fed0346acaff@mail.gmail.com> 
	<67684cbacb09f0720be9b60fd55094ad.squirrel@mail.stardawn.org> 
	<40e4e7e50907220730v1c64a7bcgcdd2d5c4b63fad67@mail.gmail.com> 
	<7369446bd8bdebdc46b87803cad1326c.squirrel@mail.stardawn.org> 
	<40e4e7e50907220744o1cb61f2l5cfd355daef886c2@mail.gmail.com> 
	<46f6bcfd9617d7d5a61880e8ced87874.squirrel@mail.stardawn.org> 
	<fd2982320907220925y7a6fc8f7q454596ae0964eaf6@mail.gmail.com> 
	<m2bpm9zvyg.fsf_-_@nocandy.dyndns.org>
Message-ID: <fd2982320908210536q2bdcd077l3c6f0347ec7acb48@mail.gmail.com>

The patch looks good, I have committed it to the development version.
We really need more and better test cases, to state the obvious.

Thanks!
Hans

On Thu, Aug 20, 2009 at 23:28, Stephen Compall<s11 at member.fsf.org> wrote:
> As of r4438 (Peter's patch), I believe this wipes out post-parameters of
> multipart/form-data POST requests and causes the relevant requests to
> time out.
>
> Specifically, on a multipart/form-data request, the first call to
> `post-parameters` yields a sensible result, whereas future calls yield
> NIL after timing out.
>
> The solution proper is in the first hunk of the patch below, which
> removes the ability to FORCE maybe-read-post-parameters to reread a
> multipart/form-data request, because it can't do that, having emptied
> the stream of the necessary data.
>
> The second hunk, which incidentally fixes the problem as well (only by
> avoiding the confusing behavior of maybe-read-post-parameters in the
> common case of POSTing a non-empty set of parameters, rather than
> solving it), is a specific followup to r4438, which in combination with
> the first hunk merely prevents post-parameters from recalculating the
> alist from the raw data on every call.
>
> Were the first hunk to be changed to warn in the specific case it
> avoids, the second hunk would also serve to eliminate spurious warnings
> about being unable to reread multipart posts.



From girzel at gmail.com  Thu Aug 27 08:26:13 2009
From: girzel at gmail.com (Eric Abrahamsen)
Date: Thu, 27 Aug 2009 16:26:13 +0800
Subject: [hunchentoot-devel] form validation
Message-ID: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>

define-easy-handler has some pretty extensive features for accepting  
GET/POST parameters, but when it comes to validating those parameters,  
and possibly returning errors to the client, it seems like the only  
viable thing to do is write a standard handler function and work with  
get-parameters* and post-parameters* directly.

Does anyone have any experience to share in this direction? How is  
everyone handling more complex form validation and error reporting?  
Has there ever been any talk of a small external library for doing  
validation?

Eric



From sky at viridian-project.de  Thu Aug 27 10:23:02 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Thu, 27 Aug 2009 12:23:02 +0200 (CEST)
Subject: [hunchentoot-devel] form validation
In-Reply-To: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>
References: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>
Message-ID: <d20804555528753e5459c95ca1124963.squirrel@mail.stardawn.org>


Eric Abrahamsen wrote:

> Does anyone have any experience to share in this direction? How is
> everyone handling more complex form validation and error reporting?

I use Weblocks.


> Has there ever been any talk of a small external library for doing
> validation?

No, but you could try to build one from the current Weblocks
serialization and validation code. This would be a really
cool endeavour.

  Leslie

-- 
http://www.linkedin.com/in/polzer




From amalawi at gmail.com  Thu Aug 27 10:30:15 2009
From: amalawi at gmail.com (Ala'a (cmo-0))
Date: Thu, 27 Aug 2009 14:30:15 +0400
Subject: [hunchentoot-devel] form validation
In-Reply-To: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>
References: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>
Message-ID: <af6a3d2d0908270330h189a94b4yc6ac96df3968e14@mail.gmail.com>

One possible way is to define your own protocol:

(add-validation validation-forms "error message")

(valid-p object) returning two values, Boolean representing validity
after applying all validation rules. otherwise returning nil and the
second
value holding errors if they exists. then you can use it with
multiple-value-bind

(multiple-value-bind (valid-p errors) (validate object)
  (if valid-p
     (save object) ; persist it
     (otherwise report back the errors to the user))


this is only a sketch, you may use any thing else that suits your requirements.

regards,

Ala'a (cmo-0)



On Thu, Aug 27, 2009 at 12:26 PM, Eric Abrahamsen<girzel at gmail.com> wrote:
> define-easy-handler has some pretty extensive features for accepting
> GET/POST parameters, but when it comes to validating those parameters,
> and possibly returning errors to the client, it seems like the only
> viable thing to do is write a standard handler function and work with
> get-parameters* and post-parameters* directly.
>
> Does anyone have any experience to share in this direction? How is
> everyone handling more complex form validation and error reporting?
> Has there ever been any talk of a small external library for doing
> validation?
>
> Eric
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>



-- 
It does not matter how fast your code is, if it does not work!



From girzel at gmail.com  Fri Aug 28 01:04:13 2009
From: girzel at gmail.com (Eric Abrahamsen)
Date: Fri, 28 Aug 2009 09:04:13 +0800
Subject: [hunchentoot-devel] form validation
In-Reply-To: <af6a3d2d0908270330h189a94b4yc6ac96df3968e14@mail.gmail.com>
References: <66AB5772-0125-4B8F-84DE-5E99B6EDC4BF@gmail.com>
	<af6a3d2d0908270330h189a94b4yc6ac96df3968e14@mail.gmail.com>
Message-ID: <56E5CCB6-3B88-484B-8714-26A3A8DF6018@gmail.com>

Thanks to both of you. I've got weblocks and am poking through the  
code to see what's possible. Ala'a, what you sketched there is pretty  
close to what I had in mind, though I'm thinking one could define a  
suite of validators, for a set of form inputs, and get the validated  
and possible converted values out as a single structure. I'll go putter.

Thanks,
Eric

On Aug 27, 2009, at 6:30 PM, Ala'a (cmo-0) wrote:

> One possible way is to define your own protocol:
>
> (add-validation validation-forms "error message")
>
> (valid-p object) returning two values, Boolean representing validity
> after applying all validation rules. otherwise returning nil and the
> second
> value holding errors if they exists. then you can use it with
> multiple-value-bind
>
> (multiple-value-bind (valid-p errors) (validate object)
>  (if valid-p
>     (save object) ; persist it
>     (otherwise report back the errors to the user))
>
>
> this is only a sketch, you may use any thing else that suits your  
> requirements.
>
> regards,
>
> Ala'a (cmo-0)
>
>
>
> On Thu, Aug 27, 2009 at 12:26 PM, Eric Abrahamsen<girzel at gmail.com>  
> wrote:
>> define-easy-handler has some pretty extensive features for accepting
>> GET/POST parameters, but when it comes to validating those  
>> parameters,
>> and possibly returning errors to the client, it seems like the only
>> viable thing to do is write a standard handler function and work with
>> get-parameters* and post-parameters* directly.
>>
>> Does anyone have any experience to share in this direction? How is
>> everyone handling more complex form validation and error reporting?
>> Has there ever been any talk of a small external library for doing
>> validation?
>>
>> Eric
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
>
>
> -- 
> It does not matter how fast your code is, if it does not work!
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel




From mackram at gmail.com  Sat Aug 29 08:12:27 2009
From: mackram at gmail.com (Mackram Raydan)
Date: Sat, 29 Aug 2009 11:12:27 +0300
Subject: [hunchentoot-devel] question about the dispatcher
Message-ID: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>

Hey everyone,

so i was going through the hunchentoot documenation and I noticed that Edi
said "Unless you are in a Lisp without MP capabilities, you can have several
active instances of ACCEPTOR
<http://weitz.de/hunchentoot/#acceptor>(listening on different ports)
at the same time."

Now this is great but I can not seem to understand how do you link a
dispatcher to an acceptor (any kind of dispatcher) should the uri we put
include a port or something. Can anyone point out this? Thanks in advance.

Regards,
Mackram Raydan

Website: www.trailoflight.net
"An invasion of armies can be resisted, but not an idea whose time has
come." Victor Hugo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090829/efa3d77a/attachment.html>

From sky at viridian-project.de  Sat Aug 29 10:31:32 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Sat, 29 Aug 2009 12:31:32 +0200 (CEST)
Subject: [hunchentoot-devel] question about the dispatcher
In-Reply-To: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>
References: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>
Message-ID: <e51dd4062c323d40ecc4c05754646196.squirrel@mail.stardawn.org>


Mackram Raydan wrote:

> so i was going through the hunchentoot documenation and I noticed that Edi
> said "Unless you are in a Lisp without MP capabilities, you can have several
> active instances of ACCEPTOR
> <http://weitz.de/hunchentoot/#acceptor>(listening on different ports)
> at the same time."
>
> Now this is great but I can not seem to understand how do you link a
> dispatcher to an acceptor (any kind of dispatcher) should the uri we put
> include a port or something. Can anyone point out this? Thanks in advance.

The default acceptor refers to *dispatch-table* to find a dispatcher
that is willing to return a handler.

To modify this behavior (e.g. have a separate table per acceptor) you need
to subclass ACCEPTOR and set the REQUEST-DISPATCHER slot to an appropriate
function:

   (request-dispatcher :initarg :request-dispatcher
                       :accessor acceptor-request-dispatcher
                       :documentation "A designator for the request
dispatcher function used by this acceptor.  A function which accepts a
REQUEST object and calls a request handler of its choice \(and returns
its return value).  The default is the unexported symbol
LIST-REQUEST-DISPATCHER which works through the list
*DISPATCH-TABLE*.")

  HTH,

    Leslie

-- 
http://www.linkedin.com/in/polzer




From hans.huebner at gmail.com  Sat Aug 29 10:58:36 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 29 Aug 2009 12:58:36 +0200
Subject: [hunchentoot-devel] question about the dispatcher
In-Reply-To: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>
References: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>
Message-ID: <fd2982320908290358u5b075f0cnd2a332a16a0e79fa@mail.gmail.com>

On Sat, Aug 29, 2009 at 10:12, Mackram Raydan<mackram at gmail.com> wrote:
> so i was going through the hunchentoot documenation and I noticed that Edi
> said "Unless you are in a Lisp without MP capabilities, you can have several
> active instances of ACCEPTOR (listening on different ports) at the same
> time."
>
> Now this is great but I can not seem to understand how do you link a
> dispatcher to an acceptor (any kind of dispatcher) should the uri we put
> include a port or something. Can anyone point out this? Thanks in advance.

Do you want something like

(let ((server-1 (hunchentoot:start (make-instance
'hunchentoot:acceptor :port 1111 :request-dispatcher
'my-dispatcher))))
       (server-2 (hunchentoot:start (make-instance
'hunchentoot:acceptor :port 2222 :request-dispatcher
'my-dispatcher)))))
 ...)

or am I missing your question?

In a non-MP lisp, hunchentoot:start would block, which is what the
sentence cited from the documentation explains.

I can't see any need for subclassing as Leslie has suggested.

-Hans



From sky at viridian-project.de  Sat Aug 29 11:17:43 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Sat, 29 Aug 2009 13:17:43 +0200 (CEST)
Subject: [hunchentoot-devel] question about the dispatcher
In-Reply-To: <fd2982320908290358u5b075f0cnd2a332a16a0e79fa@mail.gmail.com>
References: <37654d130908290112o3a8ec146rfbf853cb13410c93@mail.gmail.com>
	<fd2982320908290358u5b075f0cnd2a332a16a0e79fa@mail.gmail.com>
Message-ID: <d7b6bef3a73c9fac40a3a89156f0e6cf.squirrel@mail.stardawn.org>


Hans H?bner wrote:

> I can't see any need for subclassing as Leslie has suggested.

That's right, the :request-dispatcher initarg is enough.

  Leslie

-- 
http://www.linkedin.com/in/polzer




From mackram at gmail.com  Mon Aug 31 18:14:34 2009
From: mackram at gmail.com (Mackram Raydan)
Date: Mon, 31 Aug 2009 21:14:34 +0300
Subject: [hunchentoot-devel] Issue with setting a dispatcher
Message-ID: <37654d130908311114j4fd62c87u3942d5d49e604572@mail.gmail.com>

Hey everyone,

I have been trying to get a dispatcher to work with hunchentoot but I have
been unable to do it at all. Specifically running the following line on the
REPL *(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4555
:request-dispatcher (apply 'hunchentoot:create-prefix-dispatcher '("/"
make-home-page))))* would result in an error appearing when i try to access
the localhost:4555. The error I get is *[2009-08-31 21:04:16 [ERROR]] Error
while processing connection: The value MAKE-HOME-PAGE is not of type
SEQUENCE.*

Note also that I tried to pass a list as an argument to :request-dispatcher
but I got a very weird error as well *[2009-08-31 20:17:37 [ERROR]] The
value (#<CLOSURE (LAMBDA #) {B229325}>) is not of type (OR FUNCTION
SYMBOL).  *I though that i should pass a list as a variable.

Can you please tell me what I am doing wrong? Thanks in advance.

Mackram Raydan

Website: www.trailoflight.net
"An invasion of armies can be resisted, but not an idea whose time has
come." Victor Hugo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20090831/125f4b7e/attachment.html>

From hans.huebner at gmail.com  Mon Aug 31 18:58:18 2009
From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Mon, 31 Aug 2009 20:58:18 +0200
Subject: [hunchentoot-devel] Issue with setting a dispatcher
In-Reply-To: <37654d130908311114j4fd62c87u3942d5d49e604572@mail.gmail.com>
References: <37654d130908311114j4fd62c87u3942d5d49e604572@mail.gmail.com>
Message-ID: <fd2982320908311158r313d292an67760d0d3fc3c15e@mail.gmail.com>

On Mon, Aug 31, 2009 at 20:14, Mackram Raydan<mackram at gmail.com> wrote:
> I have been trying to get a dispatcher to work with hunchentoot but I have
> been unable to do it at all. Specifically running the following line on the
> REPL (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4555
> :request-dispatcher (apply 'hunchentoot:create-prefix-dispatcher '("/"
> make-home-page)))) would result in an error appearing when i try to access
> the localhost:4555. The error I get is [2009-08-31 21:04:16 [ERROR]] Error
> while processing connection: The value MAKE-HOME-PAGE is not of type
> SEQUENCE.

Confusingly, the argument to :request-dispatcher is something
completely different from what create-prefix-dispatcher creates.  The
:request-dispatcher argument is only used when you do not want to use
the dispatcher/handler architecture of hunchentoot.  It is a function
designator for a function that is called for each request to be
handled.  This function needs to parse the request and call an
appropriate handler, in whatever fashion your architecture requires.
Contrasted to that, create-prefix-dispatcher is part of hunchentoot's
own dispatcher and handler architecture.  If you want to use that,
you'll not supply a :request-dispatcher argument when you create the
acceptor, as the default will do the right thing.

-Hans



From mackram at gmail.com  Mon Aug 31 19:05:42 2009
From: mackram at gmail.com (Mackram Raydan)
Date: Mon, 31 Aug 2009 22:05:42 +0300
Subject: [hunchentoot-devel] Issue with setting a dispatcher
In-Reply-To: <fd2982320908311158r313d292an67760d0d3fc3c15e@mail.gmail.com>
References: <37654d130908311114j4fd62c87u3942d5d49e604572@mail.gmail.com>
	<fd2982320908311158r313d292an67760d0d3fc3c15e@mail.gmail.com>
Message-ID: <37654d130908311205w27f73ce4o8f9fe6f4d4afccee@mail.gmail.com>

Thank you so much Hans for your quick reply, that makes so much sense now
:).


Mackram Raydan

Website: www.trailoflight.net
"An invasion of armies can be resisted, but not an idea whose time has
come." Victor Hugo


On Mon, Aug 31, 2009 at 9:58 PM, Hans H?bner <hans.huebner at gmail.com> wrote:

> On Mon, Aug 31, 2009 at 20:14, Mackram Raydan<mackram at gmail.com> wrote:
> > I have been trying to get a dispatcher to work with hunchentoot but I
> have
> > been unable to do it at all. Specifically running the following line on
> the
> > REPL (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4555
> > :request-dispatcher (apply 'hunchentoot:create-prefix-dispatcher '("/"
> > make-home-page)))) would result in an error appearing when i try to
> access
> > the localhost:4555. The error I get is [2009-08-31 21:04:16 [ERROR]]
> Error
> > while processing connection: The value MAKE-HOME-PAGE is not of type
> > SEQUENCE.
>
> Confusingly, the argument to :request-dispatcher is something
> completely different from what create-prefix-dispatcher creates.  The
> :request-dispatcher argument is only used when you do not want to use
> the dispatcher/handler architecture of hunchentoot.  It is a function
> designator for a function that is called for each request to be
> handled.  This function needs to parse the request and call an
> appropriate handler, in whatever fashion your architecture requires.
> Contrasted to that, create-prefix-dispatcher is part of hunchentoot's
> own dispatcher and handler architecture.  If you want to use that,
> you'll not supply a :request-dispatcher argument when you create the
> acceptor, as the default will do the right thing.
>
> -Hans
>
> _______________________________________________
> 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/20090831/25a84a1e/attachment.html>