From info at jensteich.de  Mon Mar  3 17:11:49 2008
From: info at jensteich.de (Jens Teich)
Date: Mon, 3 Mar 2008 18:11:49 +0100
Subject: [hunchentoot-devel] ProxyPass with IIS
Message-ID: <000301c87d51$ad7184a0$c60dbb5a@LENOVOJENS>

Does anybody know how to achieve this Apache - mod_proxy feature ...
| ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot
| ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentooton Win 
using IIS?ThanksJens



From edi at agharta.de  Mon Mar  3 21:22:42 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 03 Mar 2008 22:22:42 +0100
Subject: [hunchentoot-devel] ProxyPass with IIS
In-Reply-To: <000301c87d51$ad7184a0$c60dbb5a@LENOVOJENS> (Jens Teich's
	message of "Mon, 3 Mar 2008 18:11:49 +0100")
References: <000301c87d51$ad7184a0$c60dbb5a@LENOVOJENS>
Message-ID: <ur6ermrj1.fsf@agharta.de>

On Mon, 3 Mar 2008 18:11:49 +0100, "Jens Teich" <info at jensteich.de> wrote:

> Does anybody know how to achieve this Apache - mod_proxy feature ...
> | ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot
> | ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentooton
>   Win using IIS?ThanksJens

Just checking: Does the IIS actually do something?  If not, then you
could use Hunchentoot directly, without a proxy in front.  For the
actual question I don't have an answer, sorry.


From info at jensteich.de  Tue Mar  4 06:51:02 2008
From: info at jensteich.de (Jens Teich)
Date: Tue, 4 Mar 2008 07:51:02 +0100
Subject: [hunchentoot-devel] ProxyPass with IIS
References: <000301c87d51$ad7184a0$c60dbb5a@LENOVOJENS>
	<ur6ermrj1.fsf@agharta.de>
Message-ID: <037c01c87dc4$aae92fd0$c60dbb5a@LENOVOJENS>

Edi Weitz wrote:
> On Mon, 3 Mar 2008 18:11:49 +0100, "Jens Teich" <info at jensteich.de>
> wrote: 
> 
>> Does anybody know how to achieve this Apache - mod_proxy feature ...
>>> ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot
>>> ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentooton
>>   Win using IIS?ThanksJens
> 
> Just checking: Does the IIS actually do something?  If not, then you
> could use Hunchentoot directly, without a proxy in front.  For the
> actual question I don't have an answer, sorry.

Yes I know this but unfortunately we need the IIS because another system
(CMS) uses it.

Jens


From bhyde at pobox.com  Thu Mar  6 02:22:25 2008
From: bhyde at pobox.com (Ben Hyde)
Date: Wed, 5 Mar 2008 21:22:25 -0500
Subject: [hunchentoot-devel] format to age in test.lisp?
Message-ID: <ED2C3626-2F8A-4A9B-88B3-8F3B3B84C650@pobox.com>

I'm a new subscriber and I haven't done any of the usual things.  For  
example lurked for while or read the archives.

I did the following _mindlessly_ to get clbuild to build hunchentoot:

Hope this helps.  - ben

$ ./clbuild diff hunchentoot
...
diff -rN -u old-hunchentoot/test/test.lisp new-hunchentoot/test/ 
test.lisp
--- old-hunchentoot/test/test.lisp      2008-03-05 21:16:06.000000000  
-0500
+++ new-hunchentoot/test/test.lisp      2008-03-05 21:16:06.000000000  
-0500
@@ -444,7 +444,7 @@
                                          "Yellow snow")
                          do (htm
                              (:input :type "checkbox"
-                             :name (format age nil "meal{~A}" choice)
+                             :name (format nil "meal{~A}" choice)
                               :checked (gethash choice meal)
                               (esc choice))
                              (:br)))))


From edi at agharta.de  Thu Mar  6 07:49:12 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 06 Mar 2008 08:49:12 +0100
Subject: [hunchentoot-devel] New release 0.15.2 (Was: format to age in
	test.lisp?)
In-Reply-To: <ED2C3626-2F8A-4A9B-88B3-8F3B3B84C650@pobox.com> (Ben Hyde's
	message of "Wed, 5 Mar 2008 21:22:25 -0500")
References: <ED2C3626-2F8A-4A9B-88B3-8F3B3B84C650@pobox.com>
Message-ID: <u4pbk1edj.fsf@agharta.de>

On Wed, 5 Mar 2008 21:22:25 -0500, Ben Hyde <bhyde at pobox.com> wrote:

> -                             :name (format age nil "meal{~A}" choice)
> +                             :name (format nil "meal{~A}" choice)

Woops, how did that one get into there?

Thanks, fixed in the new release.

Edi.


From michaelw+tbnl at foldr.org  Tue Mar 11 11:15:23 2008
From: michaelw+tbnl at foldr.org (Michael Weber)
Date: Tue, 11 Mar 2008 12:15:23 +0100
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
Message-ID: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>

Hi,

attached is a patch which adds and exports a new function REDIRECT*  
(including changes to documentation).  It is like REDIRECT, except  
that it has a keyword argument CODE instead of PERMANENTLY.  This is  
to allow returning 303 (See Other) while staying backwards compatible.

The alternative would be to add the CODE keyword argument to  
REDIRECT, and figure out the semantics when both :code  
and :permanently are given.  I can prepare a patch for that, too, if  
this is preferred (and somebody states the proposed behavior as  
docstring ;)).


Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hunchentoot-redirect.patch
Type: application/octet-stream
Size: 7498 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080311/715a9c94/attachment.obj>
-------------- next part --------------



From edi at agharta.de  Tue Mar 11 11:32:37 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 11 Mar 2008 12:32:37 +0100
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org> (Michael
	Weber's message of "Tue, 11 Mar 2008 12:15:23 +0100")
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
Message-ID: <umyp55wdm.fsf@agharta.de>

On Tue, 11 Mar 2008 12:15:23 +0100, Michael Weber <michaelw+tbnl at foldr.org> wrote:

> attached is a patch which adds and exports a new function REDIRECT*
> (including changes to documentation).  It is like REDIRECT, except
> that it has a keyword argument CODE instead of PERMANENTLY.  This is
> to allow returning 303 (See Other) while staying backwards
> compatible.
>
> The alternative would be to add the CODE keyword argument to
> REDIRECT, and figure out the semantics when both :code and
> :permanently are given.  I can prepare a patch for that, too, if
> this is preferred (and somebody states the proposed behavior as
> docstring ;)).

Thanks for the patch.  I would personally prefer to have only one
function for this task at the risk of not being backwards compatible,
i.e. I'd simply remove :PERMANENTLY.  Maybe we can have a quick poll:

If anybody with lots of production Hunchentoot applications is
absolutely relying on the :PERMANENTLY keyword, please speak up
now... :)

Cheers,
Edi.


From michaelw+tbnl at foldr.org  Tue Mar 11 12:12:20 2008
From: michaelw+tbnl at foldr.org (Michael Weber)
Date: Tue, 11 Mar 2008 13:12:20 +0100
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <umyp55wdm.fsf@agharta.de>
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de>
Message-ID: <8CF9E661-5B2F-4ECA-9CAF-20438B584D43@foldr.org>


On Mar 11, 2008, at 12:32 , Edi Weitz wrote:

> Thanks for the patch.  I would personally prefer to have only one
> function for this task at the risk of not being backwards compatible,
> i.e. I'd simply remove :PERMANENTLY.  Maybe we can have a quick poll:

Be my guest :)   New patch attached.

> If anybody with lots of production Hunchentoot applications is
> absolutely relying on the :PERMANENTLY keyword, please speak up
> now... :)


For those applications it's anyway easy enough to have a local  
version of REDIRECT which wraps HUNCHENTOOT:REDIRECT.


Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hunchentoot-redirect.patch
Type: application/octet-stream
Size: 3345 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080311/79dbc7b8/attachment.obj>
-------------- next part --------------



From xach at xach.com  Tue Mar 11 12:44:34 2008
From: xach at xach.com (Zach Beane)
Date: Tue, 11 Mar 2008 08:44:34 -0400
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <umyp55wdm.fsf@agharta.de>
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de>
Message-ID: <20080311124434.GR19732@xach.com>

On Tue, Mar 11, 2008 at 12:32:37PM +0100, Edi Weitz wrote:
 
> Thanks for the patch.  I would personally prefer to have only one
> function for this task at the risk of not being backwards compatible,
> i.e. I'd simply remove :PERMANENTLY.  Maybe we can have a quick poll:
> 
> If anybody with lots of production Hunchentoot applications is
> absolutely relying on the :PERMANENTLY keyword, please speak up
> now... :)

I use :permanently in a lot of places and would be a little annoyed if
it disappeared.

Zach


From edi at agharta.de  Tue Mar 11 13:02:07 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 11 Mar 2008 14:02:07 +0100
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <20080311124434.GR19732@xach.com> (Zach Beane's message of
	"Tue, 11 Mar 2008 08:44:34 -0400")
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de> <20080311124434.GR19732@xach.com>
Message-ID: <uod9l4do0.fsf@agharta.de>

On Tue, 11 Mar 2008 08:44:34 -0400, Zach Beane <xach at xach.com> wrote:

> I use :permanently in a lot of places and would be a little annoyed
> if it disappeared.

I thought you were still using TBNL...


From xach at xach.com  Tue Mar 11 13:05:25 2008
From: xach at xach.com (Zach Beane)
Date: Tue, 11 Mar 2008 09:05:25 -0400
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <uod9l4do0.fsf@agharta.de>
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de> <20080311124434.GR19732@xach.com>
	<uod9l4do0.fsf@agharta.de>
Message-ID: <20080311130524.GT19732@xach.com>

On Tue, Mar 11, 2008 at 02:02:07PM +0100, Edi Weitz wrote:
> On Tue, 11 Mar 2008 08:44:34 -0400, Zach Beane <xach at xach.com> wrote:
> 
> > I use :permanently in a lot of places and would be a little annoyed
> > if it disappeared.
> 
> I thought you were still using TBNL...

I upgraded one of my two sites using TBNL to hunchentoot, and I was
very pleasantly surprised by how little I had to change. When I
(eventually) upgrade the second site, this change would make me less
pleasantly surprised. :)

Zach


From hans at huebner.org  Tue Mar 11 13:07:59 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 11 Mar 2008 09:07:59 -0400
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <20080311130524.GT19732@xach.com>
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de> <20080311124434.GR19732@xach.com>
	<uod9l4do0.fsf@agharta.de> <20080311130524.GT19732@xach.com>
Message-ID: <fd2982320803110607r7612ec80x9f8e6d23458dba0e@mail.gmail.com>

Why not support both STATUS-CODE and PERMANENTLY and make it an error
to specify both?

-Hans

2008/3/11, Zach Beane <xach at xach.com>:
> On Tue, Mar 11, 2008 at 02:02:07PM +0100, Edi Weitz wrote:
>  > On Tue, 11 Mar 2008 08:44:34 -0400, Zach Beane <xach at xach.com> wrote:
>  >
>  > > I use :permanently in a lot of places and would be a little annoyed
>  > > if it disappeared.
>  >
>  > I thought you were still using TBNL...
>
>
> I upgraded one of my two sites using TBNL to hunchentoot, and I was
>  very pleasantly surprised by how little I had to change. When I
>  (eventually) upgrade the second site, this change would make me less
>  pleasantly surprised. :)
>
>
>  Zach
>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Tue Mar 11 13:19:02 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 11 Mar 2008 14:19:02 +0100
Subject: [hunchentoot-devel] [patch] redirect* (allows to set status code)
In-Reply-To: <fd2982320803110607r7612ec80x9f8e6d23458dba0e@mail.gmail.com>
	(Hans =?iso-8859-1?q?H=FCbner's?= message of "Tue,
	11 Mar 2008 09:07:59 -0400")
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de> <20080311124434.GR19732@xach.com>
	<uod9l4do0.fsf@agharta.de> <20080311130524.GT19732@xach.com>
	<fd2982320803110607r7612ec80x9f8e6d23458dba0e@mail.gmail.com>
Message-ID: <uk5k94cvt.fsf@agharta.de>

On Tue, 11 Mar 2008 09:07:59 -0400, "Hans H?bner" <hans at huebner.org> wrote:

> Why not support both STATUS-CODE and PERMANENTLY and make it an
> error to specify both?

That's of course possible, but it's a bit ugly, isn't it?  Reminds of
the story how they didn't change the crufty syntax of Make back then
because they already had half a dozen active users.  At least,
discussions like this one explain why Common Lisp isn't as lean and
elegant as some people would like it to be.

If Zach is the only one complaining, I still think it is better to
burn our bridges behind us.  (Sorry, Zach...)


From neuss at math.uni-karlsruhe.de  Thu Mar 13 20:06:36 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Thu, 13 Mar 2008 21:06:36 +0100
Subject: [hunchentoot-devel] Two questions
Message-ID: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Hello,

I have two questions.  The first is probably a stupid one: is it possible
to serve both http and https on the same port?  With one Hunchentoot
instance?

The second one should probably be asked at the mod_lisp mailing list: is it
possible to put several Hunchentoot servers behind mod_lisp?

Thank you very much,
Nicolas


From edi at agharta.de  Thu Mar 13 20:31:21 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 13 Mar 2008 21:31:21 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de> (Nicolas
	Neuss's message of "Thu, 13 Mar 2008 21:06:36 +0100")
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <uzlt2cqna.fsf@agharta.de>

On Thu, 13 Mar 2008 21:06:36 +0100, Nicolas Neuss <neuss at math.uni-karlsruhe.de> wrote:

> I have two questions.  The first is probably a stupid one: is it
> possible to serve both http and https on the same port?  With one
> Hunchentoot instance?

No, that's generally not possible.  It's not a Hunchentoot limitation.
How is the client supposed to know which protocol they should use?

> The second one should probably be asked at the mod_lisp mailing
> list: is it possible to put several Hunchentoot servers behind
> mod_lisp?

It is possible, the mod_lisp directives can be per virtual server or
even per location (see Apache documentation).  IIRC you'll find
examples for this in the mailing list archive if you dig deep enough.

HTH,
Edi.


From maciekp at japhy.fnord.org  Fri Mar 14 12:26:04 2008
From: maciekp at japhy.fnord.org (Maciej Pasternacki)
Date: Fri, 14 Mar 2008 13:26:04 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <uzlt2cqna.fsf@agharta.de>
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
Message-ID: <1205497564.5646.3.camel@localhost>

On Thu, 2008-03-13 at 21:31 +0100, Edi Weitz wrote:
> On Thu, 13 Mar 2008 21:06:36 +0100, Nicolas Neuss <neuss at math.uni-karlsruhe.de> wrote:
> 
> > I have two questions.  The first is probably a stupid one: is it
> > possible to serve both http and https on the same port?  With one
> > Hunchentoot instance?
> 
> No, that's generally not possible.  It's not a Hunchentoot limitation.
> How is the client supposed to know which protocol they should use?

Nitpick: theoretically, it may be possible.  Client is supposed to know
this by URL anyway (http://example.com:42/ vs https://example.com:42/),
and server should be able to recognise whether start of client's request
is encrypted or not.

OTOH I never heard of such functionality, and can't imagine any scenario
(maybe except some case of guerilla deployment or firewall piercing)
where this could be actually useful.

-- 
-><- Maciej 'japhy' Pasternacki -><- http://www.pasternacki.net/ -><-




From neuss at math.uni-karlsruhe.de  Fri Mar 14 17:23:09 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Fri, 14 Mar 2008 18:23:09 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <uzlt2cqna.fsf@agharta.de> (Edi Weitz's message of "Thu\,
	13 Mar 2008 21\:31\:21 +0100")
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
Message-ID: <873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Edi Weitz <edi at agharta.de> writes:

> On Thu, 13 Mar 2008 21:06:36 +0100, Nicolas Neuss <neuss at math.uni-karlsruhe.de> wrote:
>
>> I have two questions.  The first is probably a stupid one: is it
>> possible to serve both http and https on the same port?  With one
>> Hunchentoot instance?
>
> No, that's generally not possible.  It's not a Hunchentoot limitation.
> How is the client supposed to know which protocol they should use?

OK, I had suspected that.  Thank you for the information.

>> The second one should probably be asked at the mod_lisp mailing
>> list: is it possible to put several Hunchentoot servers behind
>> mod_lisp?
>
> It is possible, the mod_lisp directives can be per virtual server or
> even per location (see Apache documentation).  IIRC you'll find
> examples for this in the mailing list archive if you dig deep enough.

I searched, but did not succeed in making it run.  However, methinks that I
may be better off anyhow using mod_proxy instead of mod_lisp.  In any case,
I was able to get Apache2/mod_proxy/Hunchentoot running nicely using the
httpd.conf-lines

ProxyPass /hunchentoot/ http://127.0.0.1:8005/
ProxyPassReverse /hunchentoot/ http://127.0.0.1:8005/

However, again two questions arise:

1. Omitting the trailing / makes the whole thing fail (which is in
contradiction to the Hunchentoot docs).  Why?

2. Is it possible to change the above setup such that it forwards secure
connections?

Thank you very much,
Nicolas



From kiuma72 at gmail.com  Fri Mar 14 17:33:42 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Fri, 14 Mar 2008 17:33:42 +0000
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <4d3bc9370803141033i4c46a517hbe8c05b0b6b67347@mail.gmail.com>

On Thu, Mar 13, 2008 at 8:06 PM, Nicolas Neuss <neuss at math.uni-karlsruhe.de>
wrote:

> Hello,
>
> I have two questions.  The first is probably a stupid one: is it possible
> to serve both http and https on the same port?  With one Hunchentoot
> instance?

More or less yes, take a look here http://common-lisp.net/project/claw/
it's not finished, but I'm near.
 kiuma

>
>
> The second one should probably be asked at the mod_lisp mailing list: is
> it
> possible to put several Hunchentoot servers behind mod_lisp?
>
> Thank you very much,
> Nicolas
> _______________________________________________
> 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/20080314/7b864447/attachment.html>

From rsynnott at gmail.com  Fri Mar 14 17:36:26 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Fri, 14 Mar 2008 17:36:26 +0000
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
	<873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <24f203480803141036r567a35c8h1a6d9ef8f3e865a2@mail.gmail.com>

On Fri, Mar 14, 2008 at 5:23 PM, Nicolas Neuss
<neuss at math.uni-karlsruhe.de> wrote:

>  I searched, but did not succeed in making it run.

You should probably be able to do it by setting *meta-dispatcher* to a
custom function which looks at the incoming port.

However, as you say, mod_proxy may be a better option.
Rob


From edi at agharta.de  Fri Mar 14 18:15:55 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 14 Mar 2008 19:15:55 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de> (Nicolas
	Neuss's message of "Fri, 14 Mar 2008 18:23:09 +0100")
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
	<873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <uhcf9b290.fsf@agharta.de>

On Fri, 14 Mar 2008 18:23:09 +0100, Nicolas Neuss <neuss at math.uni-karlsruhe.de> wrote:

> ProxyPass /hunchentoot/ http://127.0.0.1:8005/
> ProxyPassReverse /hunchentoot/ http://127.0.0.1:8005/
>
> However, again two questions arise:
>
> 1. Omitting the trailing / makes the whole thing fail (which is in
> contradiction to the Hunchentoot docs).  Why?

Hmm, not sure.  I guess you'll have to look at the Apache docs.

  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass

> 2. Is it possible to change the above setup such that it forwards
> secure connections?

Sure.  Put the directives into a virtual server which serves https
connections.  IIUC that should be all you need.


From kiuma72 at gmail.com  Fri Mar 14 18:29:56 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Fri, 14 Mar 2008 18:29:56 +0000
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <uhcf9b290.fsf@agharta.de>
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
	<873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uhcf9b290.fsf@agharta.de>
Message-ID: <4d3bc9370803141129ub556e47v2303a89f3819bdf1@mail.gmail.com>

On Fri, Mar 14, 2008 at 6:15 PM, Edi Weitz <edi at agharta.de> wrote:

> On Fri, 14 Mar 2008 18:23:09 +0100, Nicolas Neuss <
> neuss at math.uni-karlsruhe.de> wrote:
>
> > ProxyPass /hunchentoot/ http://127.0.0.1:8005/
> > ProxyPassReverse /hunchentoot/ http://127.0.0.1:8005/
>
have you tried something like
ProxyPass /hunchentoot/ggg http://127.0.0.1:8005/ggg<http://127.0.0.1:8005/>
ProxyPassReverse /hunchentoot/ggg
http://127.0.0.1:8005/ggg<http://127.0.0.1:8005/>
?

>  >
> > However, again two questions arise:
> >
> > 1. Omitting the trailing / makes the whole thing fail (which is in
> > contradiction to the Hunchentoot docs).  Why?
>
> Hmm, not sure.  I guess you'll have to look at the Apache docs.
>
>  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass
>
> > 2. Is it possible to change the above setup such that it forwards
> > secure connections?
>
> Sure.  Put the directives into a virtual server which serves https
> connections.  IIUC that should be all you need.
> _______________________________________________
> 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/20080314/cf71305e/attachment.html>

From neuss at math.uni-karlsruhe.de  Sat Mar 15 18:37:32 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Sat, 15 Mar 2008 19:37:32 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <4d3bc9370803141129ub556e47v2303a89f3819bdf1@mail.gmail.com>
	(Andrea Chiumenti's message of "Fri\,
	14 Mar 2008 18\:29\:56 +0000")
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
	<873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uhcf9b290.fsf@agharta.de>
	<4d3bc9370803141129ub556e47v2303a89f3819bdf1@mail.gmail.com>
Message-ID: <87wso396kz.fsf@ma-patru.mathematik.uni-karlsruhe.de>

"Andrea Chiumenti" <kiuma72 at gmail.com> writes:

>     > ProxyPass /hunchentoot/ http://127.0.0.1:8005/
>     > ProxyPassReverse /hunchentoot/ http://127.0.0.1:8005/
>
> have you tried something like
> ProxyPass /hunchentoot/ggg http://127.0.0.1:8005/ggg
> ProxyPassReverse /hunchentoot/ggg http://127.0.0.1:8005/ggg

No, because at the moment, I do not have subdirectories. 

> On Fri, Mar 14, 2008 at 6:15 PM, Edi Weitz wrote:
>
>     > 2. Is it possible to change the above setup such that it forwards
>     > secure connections?
>    
>     Sure.  Put the directives into a virtual server which serves https
>     connections.  IIUC that should be all you need.

I have tried now in httpd.conf the following:

<VirtualHost localhost:443>
ServerName localhost
SSLEngine on
SSLCertificateFile /home/neuss/CL-HOME/courses/server.cert
SSLCertificateKeyFile /home/neuss/CL-HOME/courses/server.key
ProxyPass /hunchentoot/ https://127.0.0.1:8005/
ProxyPassReverse /hunchentoot/ https://127.0.0.1:8005/
</VirtualHost>

However, although https://127.0.0.1:8005/ works, when I access it with
https://localhost/hunchentoot/, I see the following error in the log file:

[2008-03-15 19:23:16 [ERROR]] Error while processing connection: The
TLS/SSL connection on handle #.(SB-SYS:INT-SAP #X080FFD68) has been
closed. (return code:  5)SSL error queue: 

Does anyone see what I'm doing wrong here?

Thank you,
Nicolas

P.S.: Here is the longer backtrace:

  0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN))
      #<FUNCTION (LAMBDA #) {A8D0DDD}>)
  1: (SWANK::DEBUG-IN-EMACS #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
  2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<CLOSURE (LAMBDA #) {B0E3905}>)
  3: (SWANK::CALL-WITH-REDIRECTED-IO
      #<SWANK::CONNECTION {ADC8DC9}>
      #<CLOSURE (LAMBDA #) {B0E3915}>)
  4: (SWANK::CALL-WITH-CONNECTION
      #<SWANK::CONNECTION {ADC8DC9}>
      #<CLOSURE (LAMBDA #) {B0E3905}>)
  5: (INVOKE-DEBUGGER #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
  6: (INVOKE-DEBUGGER #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
  7: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
      #<unavailable argument>
      #<unavailable argument>
      #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
  8: ((LAMBDA
          (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.))
      #<unavailable argument>
      #<unavailable argument>
      #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
  9: (SIGNAL #<CL+SSL::SSL-ERROR-ZERO-RETURN {B0E36D1}>)
 10: (ERROR CL+SSL::SSL-ERROR-ZERO-RETURN)
 11: (CL+SSL::SSL-SIGNAL-ERROR
      #.(SB-SYS:INT-SAP #X0810FC90)
      #<FUNCTION CL+SSL::SSL-ACCEPT>
      5
      0)
 12: (CL+SSL::SSL-SIGNAL-ERROR
      #.(SB-SYS:INT-SAP #X0810FC90)
      #<FUNCTION CL+SSL::SSL-ACCEPT>
      5
      0)
 13: (CL+SSL:MAKE-SSL-SERVER-STREAM #<unavailable lambda list>)
 14: (HUNCHENTOOT::PROCESS-CONNECTION
      #<HUNCHENTOOT::SERVER {B74C2F1}>
      #<SB-BSD-SOCKETS:INET-SOCKET descriptor 11 {AE8D8A9}>)
 15: ((LAMBDA ()))


From neuss at math.uni-karlsruhe.de  Sun Mar 16 15:18:19 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Sun, 16 Mar 2008 16:18:19 +0100
Subject: [hunchentoot-devel] Two questions
In-Reply-To: <87wso396kz.fsf@ma-patru.mathematik.uni-karlsruhe.de> (Nicolas
	Neuss's message of "Sat\, 15 Mar 2008 19\:37\:32 +0100")
References: <8763vqtmlv.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uzlt2cqna.fsf@agharta.de>
	<873aqtxls2.fsf@ma-patru.mathematik.uni-karlsruhe.de>
	<uhcf9b290.fsf@agharta.de>
	<4d3bc9370803141129ub556e47v2303a89f3819bdf1@mail.gmail.com>
	<87wso396kz.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <87hcf6itok.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Nicolas Neuss <neuss at math.uni-karlsruhe.de> writes:

> <VirtualHost localhost:443>
> ServerName localhost
> SSLEngine on
> SSLCertificateFile /home/neuss/CL-HOME/courses/server.cert
> SSLCertificateKeyFile /home/neuss/CL-HOME/courses/server.key
> ProxyPass /hunchentoot/ https://127.0.0.1:8005/
> ProxyPassReverse /hunchentoot/ https://127.0.0.1:8005/
> </VirtualHost>

Success.  Reading the apache2 error log I found out that I was missing the
activation of SSLProxyEngine.  The following works for me as much as I see:

<VirtualHost localhost:443>
ServerName localhost
SSLEngine on
SSLCertificateFile /home/neuss/CL-HOME/courses/server.cert
SSLCertificateKeyFile /home/neuss/CL-HOME/courses/server.key
SSLProxyEngine    On
SSLProxyCACertificateFile /home/neuss/CL-HOME/courses/server.cert
ProxyPreserveHost On
ProxyPass /hunchentoot/ https://127.0.0.1:8005/
ProxyPassReverse /hunchentoot/ https://127.0.0.1:8005/
</VirtualHost>

Yours, Nicolas


From jeffrey at cunningham.net  Mon Mar 17 02:34:54 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Sun, 16 Mar 2008 19:34:54 -0700
Subject: [hunchentoot-devel] Yahoo using Hunchentoot?
Message-ID: <47DDD8CE.3000700@cunningham.net>

For a second there it had me wondering:

http://jandmworks.com/download/screenshot.png

I'll leave it to someone else to explain how the fact that I have a 
hunchentoot server running on my desktop on port 4000 can interact with 
my normal browsing activities.   ;-)

--Jeff


From edi at agharta.de  Mon Mar 17 11:42:35 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 17 Mar 2008 12:42:35 +0100
Subject: [hunchentoot-devel] New release 0.15.3 (Was: [patch] redirect*
 (allows to set status code))
In-Reply-To: <8CF9E661-5B2F-4ECA-9CAF-20438B584D43@foldr.org> (Michael
	Weber's message of "Tue, 11 Mar 2008 13:12:20 +0100")
References: <85735535-B7DD-495B-8615-51027C6D5F7F@foldr.org>
	<umyp55wdm.fsf@agharta.de>
	<8CF9E661-5B2F-4ECA-9CAF-20438B584D43@foldr.org>
Message-ID: <u8x0h7f10.fsf_-_@agharta.de>

On Tue, 11 Mar 2008 13:12:20 +0100, Michael Weber <michaelw+tbnl at foldr.org> wrote:

> Be my guest :)   New patch attached.

Thanks.  It's in the new release.

Edi.


From nablaone at gmail.com  Tue Mar 18 17:36:24 2008
From: nablaone at gmail.com (=?UTF-8?Q?Rafa=C5=82_Strzali=C5=84ski?=)
Date: Tue, 18 Mar 2008 18:36:24 +0100
Subject: [hunchentoot-devel] Yahoo using Hunchentoot?
In-Reply-To: <47DDD8CE.3000700@cunningham.net>
References: <47DDD8CE.3000700@cunningham.net>
Message-ID: <f1384930803181036w189fc4ael8b51f207bac307d6@mail.gmail.com>

On Mon, Mar 17, 2008 at 3:34 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
> For a second there it had me wondering:
>
>  http://jandmworks.com/download/screenshot.png
>
>  I'll leave it to someone else to explain how the fact that I have a
>  hunchentoot server running on my desktop on port 4000 can interact with
>  my normal browsing activities.   ;-)

127.0.0.1 ad.yahoo.com

in your /etc/hosts ?


-- 
Pozdrawiam,
Rafal Strzalinski (nabla)
http://nablaone.net


From jeffrey.k.cunningham at boeing.com  Tue Mar 18 17:41:05 2008
From: jeffrey.k.cunningham at boeing.com (Jeffrey Cunningham)
Date: Tue, 18 Mar 2008 10:41:05 -0700
Subject: [hunchentoot-devel] Yahoo using Hunchentoot?
In-Reply-To: <F014AD23EEB9B9469410D7F0334C93D30711D30F@XCH-NW-4V2.nw.nos.boeing.com>
References: <47DDD8CE.3000700@cunningham.net>
	<F014AD23EEB9B9469410D7F0334C93D30711D30F@XCH-NW-4V2.nw.nos.boeing.com>
Message-ID: <47DFFEB1.3000800@boeing.com>

Rafa? Strzali?ski wrote:
> On Mon, Mar 17, 2008 at 3:34 AM, Jeff Cunningham <jeffrey at cunningham.net> wrote:
>> For a second there it had me wondering:
>>
>>  http://jandmworks.com/download/screenshot.png
>>
>>  I'll leave it to someone else to explain how the fact that I have a
>>  hunchentoot server running on my desktop on port 4000 can interact with
>>  my normal browsing activities.   ;-)
> 
> 127.0.0.1 ad.yahoo.com
> 
> in your /etc/hosts ?
> 
> 

Exactly. An amusing side effect.


From helmut at cybernetic-systems.de  Tue Mar 18 17:50:52 2008
From: helmut at cybernetic-systems.de (Dr. Helmut G. Enders)
Date: Tue, 18 Mar 2008 18:50:52 +0100
Subject: [hunchentoot-devel] unix setuid
Message-ID: <47E000FC.6070709@cybernetic-systems.de>

I'm using ht with debian sbcl / clc.

Currently the s-bit is set to start sbcl as root,
for using port 80.
But when i set uid back to <user> I got
problems with clc as the fasl files had
a different (root) owner. Even a
brute force chmod 0777 of the fasls has
no success. The clc stops with
"security... more than one user has write
access".

Now I start hunchentoot with 8080 and use
iptables to map port 80 to 8080.

How do you solve this problem.
A nice thing would be to setuid to root,
access the port 80 and setuid back, but here
I failed :-(.

Helmut

PS:
 <off topic but perhaps useful>
 Currently sbcl is broken unter
 debian sid amd64, you have to downgrade
 the libc6 (libc6-i368 libc6-dev libc6-dev-i386)
 back to version 2.7-8  (snapshot.debian.org)




From kiuma72 at gmail.com  Tue Mar 18 18:45:25 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Tue, 18 Mar 2008 18:45:25 +0000
Subject: [hunchentoot-devel] unix setuid
In-Reply-To: <47E000FC.6070709@cybernetic-systems.de>
References: <47E000FC.6070709@cybernetic-systems.de>
Message-ID: <4d3bc9370803181145i2e5e714t4757e7036fffb804@mail.gmail.com>

If I remember there are problems with IP ports < 1024 and a user different
from root.

kiuma

On Tue, Mar 18, 2008 at 5:50 PM, Dr. Helmut G. Enders <
helmut at cybernetic-systems.de> wrote:

> I'm using ht with debian sbcl / clc.
>
> Currently the s-bit is set to start sbcl as root,
> for using port 80.
> But when i set uid back to <user> I got
> problems with clc as the fasl files had
> a different (root) owner. Even a
> brute force chmod 0777 of the fasls has
> no success. The clc stops with
> "security... more than one user has write
> access".
>
> Now I start hunchentoot with 8080 and use
> iptables to map port 80 to 8080.
>
> How do you solve this problem.
> A nice thing would be to setuid to root,
> access the port 80 and setuid back, but here
> I failed :-(.
>
> Helmut
>
> PS:
>  <off topic but perhaps useful>
>  Currently sbcl is broken unter
>  debian sid amd64, you have to downgrade
>  the libc6 (libc6-i368 libc6-dev libc6-dev-i386)
>  back to version 2.7-8  (snapshot.debian.org)
>
>
> _______________________________________________
> 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/20080318/ca544e8b/attachment.html>

From bhyde at pobox.com  Tue Mar 18 19:38:03 2008
From: bhyde at pobox.com (Ben Hyde)
Date: Tue, 18 Mar 2008 15:38:03 -0400
Subject: [hunchentoot-devel] unix setuid
In-Reply-To: <47E000FC.6070709@cybernetic-systems.de>
References: <47E000FC.6070709@cybernetic-systems.de>
Message-ID: <5AC406DE-8A7C-4C23-89AF-E436737500ED@pobox.com>

On Mar 18, 2008, at 1:50 PM, Dr. Helmut G. Enders wrote:
> I'm using ht with debian sbcl / clc.
>
> Currently the s-bit is set to start sbcl as root,
> for using port 80.

One approach to this problem is write a very small C program that.

  1. listens on the port
  2. records listener's file description into an environment variable(s)
  3. execs a command given it's remaining arguments.

Combined with other tools found in daemontools you can then drop  
rights, switch users, etc. and finally invoke the actual Lisp  
process.  This plays well with jails etc.

The C program is easier to write, at least easier than the bit that  
converts the file handle into something useful for your Lisp process.

  - ben


From helmut at cybernetic-systems.de  Tue Mar 18 21:03:13 2008
From: helmut at cybernetic-systems.de (Dr. Helmut G. Enders)
Date: Tue, 18 Mar 2008 22:03:13 +0100
Subject: [hunchentoot-devel] unix setuid
In-Reply-To: <5AC406DE-8A7C-4C23-89AF-E436737500ED@pobox.com>
References: <47E000FC.6070709@cybernetic-systems.de>
	<5AC406DE-8A7C-4C23-89AF-E436737500ED@pobox.com>
Message-ID: <47E02E11.7080206@cybernetic-systems.de>

Ben Hyde wrote:

> One approach to this problem is write a very small C program that.
> 
>  1. listens on the port
>  2. records listener's file description into an environment variable(s)
>  3. execs a command given it's remaining arguments.
> 
> Combined with other tools found in daemontools you can then drop rights, 
> switch users, etc. and finally invoke the actual Lisp process.  This 
> plays well with jails etc.
> 
> The C program is easier to write, at least easier than the bit that 
> converts the file handle into something useful for your Lisp process.
> 
>  - ben
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel


Thanks, but in the meantime (google..google) I found privbind.

I chmod u+s /usr/bin/privbind
and add

(setq inferior-lisp-program
    "/usr/bin/privbind -u helmut -g helmut /usr/bin/sbcl")

to my .emacs

and add
   screen -t Hunchentoot emacs -f slime
to my .screenrc

and add
  (require 'hunchentoot)
  (hunchentoot:start-server :port 80  :address <ip of eth0:1>)
to my .sbclrc

:-) and add
   sudo -H -u helmut  screen -d -m
to my /etc/init.d/screens

....
even after an reboot I login (or ssh to the server),
do a screen -r  .... and be happy.

(Now  my server has many eth0:x's with many
  hunchentoolies, listening all on port 80 :-)


Helmut





From bhyde at pobox.com  Tue Mar 18 22:27:01 2008
From: bhyde at pobox.com (Ben Hyde)
Date: Tue, 18 Mar 2008 18:27:01 -0400
Subject: [hunchentoot-devel] unix setuid
In-Reply-To: <47E02E11.7080206@cybernetic-systems.de>
References: <47E000FC.6070709@cybernetic-systems.de>
	<5AC406DE-8A7C-4C23-89AF-E436737500ED@pobox.com>
	<47E02E11.7080206@cybernetic-systems.de>
Message-ID: <480D9292-1E19-4C7E-975B-3AA7AC106895@pobox.com>


On Mar 18, 2008, at 5:03 PM, Dr. Helmut G. Enders wrote:

> privbind

fascinating.  very useful.  appears to route around the priv  
restriction using a socket SOCK_SEQPACKET what ever that is.  linux  
only it seems

i got the impression you don't even need that +s


From css at swissjabber.ch  Thu Mar 20 23:25:40 2008
From: css at swissjabber.ch (css)
Date: Fri, 21 Mar 2008 00:25:40 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
Message-ID: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>

As I noticed, Hunchentoot is not yet ported to ECL, even though the
ECL-documentation says that it has Gray-Streams-, Thread- and
Socket-Support as far as I read.

Was there simply no interest to port it to ECL so far, or is there any
reason why it is not possible or very hard to port it to ECL, or why
one should not use ECL?

Another thing I am interested in is, why doesnt Hunchentoot use
"external" Libraries, or store the whole Stuff in the port-*-Files in
seperate "Libraries" - the functions defined there may be useful to
other Projects, too, and they would also benefit from bugfixes and
extensions (and would maybe add such, too).


From edi at agharta.de  Fri Mar 21 22:33:59 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 21 Mar 2008 23:33:59 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	(css@swissjabber.ch's
	message of "Fri, 21 Mar 2008 00:25:40 +0100")
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
Message-ID: <u3aqjso4o.fsf@agharta.de>

On Fri, 21 Mar 2008 00:25:40 +0100, css <css at swissjabber.ch> wrote:

> As I noticed, Hunchentoot is not yet ported to ECL, even though the
> ECL-documentation says that it has Gray-Streams-, Thread- and
> Socket-Support as far as I read.
>
> Was there simply no interest to port it to ECL so far, or is there
> any reason why it is not possible or very hard to port it to ECL, or
> why one should not use ECL?

I suppose there was simply no interest so far.  You're welcome to
provide patches for ECL.

  http://weitz.de/patches.html

> Another thing I am interested in is, why doesnt Hunchentoot use
> "external" Libraries, or store the whole Stuff in the port-*-Files
> in seperate "Libraries" - the functions defined there may be useful
> to other Projects, too, and they would also benefit from bugfixes
> and extensions (and would maybe add such, too).

There already exist compatibility libraries for things like MP and
sockets which I think provide more functionality than what is in the
port-xxx.lisp files.  However, they're pretty big and using them would
add another layer of complexity to Hunchentoot which already depends
on a dozen other libs.

Right now there are only a few lines per implementation which cover a
small subset of four implementation-specific areas, namely MP,
sockets, debugging, and OS integration.  Loading four external
libraries to cover this seems overdone to me.

Having said that, a lot of the "design decisions" of Hunchentoot might
actually be accidents or workarounds owed to its history - see the
website.  If I would start from scratch today, I would probably do a
lot of things differently.  But that's not going to happen anytime
soon... :)


From avodonosov at yandex.ru  Fri Mar 21 22:49:25 2008
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Sat, 22 Mar 2008 00:49:25 +0200
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <u3aqjso4o.fsf@agharta.de>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de>
Message-ID: <152701829.20080322004925@yandex.ru>

>> As I noticed, Hunchentoot is not yet ported to ECL, even though the
>> ECL-documentation says that it has Gray-Streams-, Thread- and
>> Socket-Support as far as I read.
>>
>> Was there simply no interest to port it to ECL so far, or is there
>> any reason why it is not possible or very hard to port it to ECL, or
>> why one should not use ECL?

> I suppose there was simply no interest so far.  You're welcome to
> provide patches for ECL.

>   http://weitz.de/patches.html

Not to say there was no interest at all, I'm quite interested in that,
but there is not enough free time, as usually...

Regards,
-- Anton



From info at jensteich.de  Mon Mar 24 03:25:35 2008
From: info at jensteich.de (Jens Teich)
Date: Mon, 24 Mar 2008 04:25:35 +0100
Subject: [hunchentoot-devel] Problems with SBCL on MacOS
Message-ID: <29E74AA7-3EFB-4A29-9DE7-142722D8E785@jensteich.de>

MacOS X 10.5.2
Aquamacs (latest) with GNU Emacs 22.1.91.2
SBCL  1.0.12

When loading :hunchentoot-test, the following happens. I'm puzzled  
because ASDF says compile failed,
but a fasl file is written.

When I start the webserver with this fasl-file, strange things happen.  
The test-site works after
(start.server :port 4242), but the REPL prompt doesn't appear again.  
Looks like an infinite loop.

Jens


CL-USER> (asdf :hunchentoot-test)
; compiling file "/Users/jensteich/Lisp/hunchentoot-0.15.3/port- 
sbcl.lisp" (written 13 FEB 2008 05:02:18 PM):
; compiling (IN-PACKAGE :HUNCHENTOOT)
; compiling (WARN "Without thread support, this library is only useful  
for development.")
;
; caught WARNING:
;   Without thread support, this library is only useful for development.

; compiling (DEFMACRO DEFCONSTANT ...)
; compiling (DEFUN MAKE-LOCK ...)
; compiling (DEFMACRO WITH-LOCK ...)
; compiling (DEFVAR *INCF-MUTEX* ...)
; compiling (DEFMACRO ATOMIC-INCF ...)
; compiling (DEFUN ENSURED-SLEEP-MILLIS ...)
;
; caught STYLE-WARNING:
;   redefining ENSURED-SLEEP-MILLIS in DEFUN

; compiling (COMMON-LISP:HANDLER-CASE (SB-EXT:WITH-TIMEOUT  
1.e-7 ...) ...); in: LAMBDA NIL
;     (SB-KERNEL:FLOAT-WAIT)
;
; note: deleting unreachable code

;     (HUNCHENTOOT::ENSURED-SLEEP-MILLIS 5)
;
; note: deleting unreachable code

; file: /Users/jensteich/Lisp/hunchentoot-0.15.3/port-sbcl.lisp
; in: EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
;     (HUNCHENTOOT::ENSURED-SLEEP-MILLIS 5)
;
; note: deleting unreachable code

; compiling (DEFMACRO WITH-TIMEOUT ...)
; compiling (DEFUN PROCESS-RUN-FUNCTION ...)
; compiling (DEFUN PROCESS-KILL ...)
; compiling (DEFINE-SYMBOL-MACRO *CURRENT-PROCESS* ...)
; compiling (DEFUN PROCESS-ALLOW-SCHEDULING ...)
; compiling (DEFUN RESOLVE-HOSTNAME ...)
; compiling (DEFUN START-UP-SERVER ...)
; compiling (DEFUN FORMAT-ADDRESS ...)
; compiling (DEFUN MAKE-SOCKET-STREAM ...)
; compiling (WHEN (FIND-SYMBOL "*DEBUG-PRINT-VARIABLE-ALIST*" ...) ...)
; compiling (DEFUN GET-BACKTRACE ...)

; /Users/jensteich/Lisp/hunchentoot-0.15.3/port-sbcl.fasl written
; compilation finished in 0:00:00
WARNING:
    COMPILE-FILE warned while performing #<COMPILE-OP NIL {13F28EE1}> on
    #<CL-SOURCE-FILE "port-sbcl" {12106F59}>.


erred while invoking #<COMPILE-OP NIL {13F28EE1}> on
#<CL-SOURCE-FILE "port-sbcl" {12106F59}>
    [Condition of type ASDF:COMPILE-FAILED]

Restarts:
   0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {13F28EE1}> on  
#<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>.
   1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {13F28EE1}> on  
#<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}> as having been successful.
   2: [ABORT-REQUEST] Abort handling SLIME request.
   3: [ABORT] Exit debugger, returning to top level.

Backtrace:
   0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL- 
SOURCE-FILE)) #<unavailable argument> #<unavailable argument>  
#<ASDF:COMPILE-OP NIL {13F28EE1}> #<ASDF:CL-SOURCE-FILE "port- 
sbcl" {12106F59}>)
       Locals:
         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
         SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {13F28EE1}>
         SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>
   1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.  
SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument>  
#<ASDF:COMPILE-OP NIL {13F28EE1}> #<ASDF:CL-SOURCE-FILE "port- 
sbcl" {12106F59}>)
       Locals:
         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
         SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {13F28EE1}>
         SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>
   2: ((LAMBDA NIL))
       Locals:
   3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
       Locals:
   4: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {1175099D}>)
       Locals:
         SB-DEBUG::ARG-0 = 1
         SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {1175099D}>
   5: (ASDF:OPERATE ASDF:LOAD-OP :HUNCHENTOOT-TEST)
       Locals:
         SB-DEBUG::ARG-0 = 2
         SB-DEBUG::ARG-1 = ASDF:LOAD-OP
         SB-DEBUG::ARG-2 = :HUNCHENTOOT-TEST
   6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF :HUNCHENTOOT-TEST) #<NULL- 
LEXENV>)
       Locals:
         SB-DEBUG::ARG-0 = (ASDF :HUNCHENTOOT-TEST)
         SB-DEBUG::ARG-1 = #<NULL-LEXENV>
   7: (SWANK::EVAL-REGION "(asdf :hunchentoot-test)
" T)
       Locals:
         SWANK::PACKAGE-UPDATE-P = T
         STRING = "(asdf :hunchentoot-test)
"
   8: ((LAMBDA NIL))
       Locals:
   9: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T))  
#<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL)  
{13F10B5D}>)
       Locals:
         SWANK-BACKEND::FN = #<CLOSURE (LAMBDA NIL) {13F10B5D}>
  10: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL)  
{13F10B5D}>)
       Locals:
         SB-DEBUG::ARG-0 = #<CLOSURE (LAMBDA NIL) {13F10B5D}>
  11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL  
"(asdf :hunchentoot-test)
") #<NULL-LEXENV>)
       Locals:
         SB-DEBUG::ARG-0 = (SWANK:LISTENER-EVAL "(asdf :hunchentoot- 
test)
")
         SB-DEBUG::ARG-1 = #<NULL-LEXENV>
  12: ((LAMBDA NIL))
       Locals:
  13: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T  
T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK- 
DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {13F1004D}>)
       Locals:
         SWANK-BACKEND::FUN = #<CLOSURE (LAMBDA NIL) {13F1004D}>
         SWANK-BACKEND::HOOK = #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
  14: ((LAMBDA NIL))
       Locals:
  15: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T  
T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK- 
DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {11A2F69D}>)
       Locals:
         SWANK-BACKEND::FUN = #<FUNCTION (LAMBDA NIL) {11A2F69D}>
         SWANK-BACKEND::HOOK = #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
  16: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {11EDB211}>  
#<CLOSURE (LAMBDA NIL) {13F0DC7D}>)
       Locals:
         SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
         SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {13F0DC7D}>
  17: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {11EDB211}>  
#<FUNCTION (LAMBDA NIL) {11A2F69D}>)
       Locals:
         SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
         SB-DEBUG::ARG-1 = #<FUNCTION (LAMBDA NIL) {11A2F69D}>
  18: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {11EDB211}>)
       Locals:
         SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
  19: (SWANK::PROCESS-AVAILABLE-INPUT #<SB-SYS:FD-STREAM for "a  
socket" {11ED0B81}> #<CLOSURE (LAMBDA NIL) {13F0DC3D}>)
       Locals:
         SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "a socket" {11ED0B81}>
         SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {13F0DC3D}>
  20: ((FLET SWANK::HANDLER))
       Locals:
  21: ((LAMBDA (SWANK-BACKEND::_)) #<unused argument>)
       Locals:
         SWANK-BACKEND::FN = #<CLOSURE (FLET SWANK::HANDLER) {1205871D}>
  22: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL)
       Locals:
         SB-DEBUG::ARG-0 = NIL
         SB-DEBUG::ARG-1 = NIL
         SB-DEBUG::ARG-2 = NIL
  23: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)
       Locals:
         SB-IMPL::DIRECTION = :INPUT
         SB-IMPL::FD = 0
         TIMEOUT = NIL
  24: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard  
input" {122792D1}>)
       Locals:
         SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "standard  
input" {122792D1}>
  25: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard  
input" {122792D1}> NIL #:EOF-OBJECT)
       Locals:
         SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "standard  
input" {122792D1}>
         SB-DEBUG::ARG-1 = NIL
         SB-DEBUG::ARG-2 = #:EOF-OBJECT
       Catch-tags:
         SB-IMPL::EOF-INPUT-CATCHER
  26: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {122792D1}>  
NIL #:EOF-OBJECT #<unused argument>)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = #:EOF-OBJECT
         STREAM = #<SB-SYS:FD-STREAM for "standard input" {122792D1}>
  27: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100BCC61}>  
NIL #:EOF-OBJECT #<unused argument>)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = #:EOF-OBJECT
         STREAM = #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100BCC61}>
  28: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
INPUT* {11A5D7E1}> NIL #:EOF-OBJECT #<unused argument>)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = #:EOF-OBJECT
         STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
INPUT* {11A5D7E1}>
  29: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL  
SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> NIL (NIL) T)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = (NIL)
         SB-IMPL::RECURSIVEP = T
         STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
INPUT* {11A5D7E1}>
  30: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL  
SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> NIL (NIL) NIL)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = (NIL)
         SB-IMPL::RECURSIVEP = NIL
         STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
INPUT* {11A5D7E1}>
  31: (READ #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD-INPUT*  
{11A5D7E1}> NIL (NIL) NIL)
       Locals:
         SB-IMPL::EOF-ERROR-P = NIL
         SB-IMPL::EOF-VALUE = (NIL)
         SB-IMPL::RECURSIVEP = NIL
         STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
INPUT* {11A5D7E1}>
  32: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL  
SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> #<unavailable argument>)
       Locals:
         SB-DEBUG::ARG-0 = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT- 
STANDARD-INPUT* {11A5D7E1}>
         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
  33: (SB-IMPL::REPL-FUN NIL)
       Locals:
         SB-DEBUG::ARG-0 = NIL
  34: (SB-IMPL::REPL-FUN NIL)
       Locals:
         SB-DEBUG::ARG-0 = 1
         SB-DEBUG::ARG-1 = NIL
  35: ((LAMBDA NIL))
       Locals:
       Catch-tags:
         SB-INT:TOPLEVEL-CATCHER
  36: ((LAMBDA NIL))
       Locals:
         SB-DEBUG::ARG-0 = 0
  37: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA NIL)  
{11BF7F0D}>)
       Locals:
         SB-DEBUG::ARG-0 = #<CLOSURE (LAMBDA NIL) {11BF7F0D}>
  38: (SB-IMPL::TOPLEVEL-REPL NIL)
       Locals:
         SB-DEBUG::ARG-0 = NIL
  39: (SB-IMPL::TOPLEVEL-INIT)
       Locals:
  40: ((LABELS SB-IMPL::RESTART-LISP))
       Locals:
       Catch-tags:
         SB-IMPL::%END-OF-THE-WORLD






From ch-tbnl at bobobeach.com  Mon Mar 24 04:25:00 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sun, 23 Mar 2008 21:25:00 -0700
Subject: [hunchentoot-devel] Problems with SBCL on MacOS
In-Reply-To: <29E74AA7-3EFB-4A29-9DE7-142722D8E785@jensteich.de>
References: <29E74AA7-3EFB-4A29-9DE7-142722D8E785@jensteich.de>
Message-ID: <61845833-60E6-42C3-A001-3A9521391B62@bobobeach.com>


comments below...

On Mar 23, 2008, at 8:25 PM, Jens Teich wrote:

> MacOS X 10.5.2
> Aquamacs (latest) with GNU Emacs 22.1.91.2
> SBCL  1.0.12
>
> When loading :hunchentoot-test, the following happens. I'm puzzled  
> because ASDF says compile failed,
> but a fasl file is written.
>
> When I start the webserver with this fasl-file, strange things  
> happen. The test-site works after
> (start.server :port 4242), but the REPL prompt doesn't appear again.  
> Looks like an infinite loop.
>
> Jens

I'd start with the WARNING here:

> CL-USER> (asdf :hunchentoot-test)
> ; compiling file "/Users/jensteich/Lisp/hunchentoot-0.15.3/port- 
> sbcl.lisp" (written 13 FEB 2008 05:02:18 PM):
> ; compiling (IN-PACKAGE :HUNCHENTOOT)
> ; compiling (WARN "Without thread support, this library is only  
> useful for development.")
> ;
> ; caught WARNING:
> ;   Without thread support, this library is only useful for  
> development.

and suggest that you build and install a threaded version of SBCL for  
running hunchentoot.

What happens down below is that the debugger gets entered because ASDF  
(correctly or not; I guess this point is arguable) treats this WARNING  
as an error and enters the debugger to let you know that you're  
compilation didn't succeed without a warning.

I'd suggest getting the SBCL source, enabling threads, building a  
threaded SBCL and using that for your hunchentoot development.

Good luck,

Cyrus

> ; compiling (DEFMACRO DEFCONSTANT ...)
> ; compiling (DEFUN MAKE-LOCK ...)
> ; compiling (DEFMACRO WITH-LOCK ...)
> ; compiling (DEFVAR *INCF-MUTEX* ...)
> ; compiling (DEFMACRO ATOMIC-INCF ...)
> ; compiling (DEFUN ENSURED-SLEEP-MILLIS ...)
> ;
> ; caught STYLE-WARNING:
> ;   redefining ENSURED-SLEEP-MILLIS in DEFUN
>
> ; compiling (COMMON-LISP:HANDLER-CASE (SB-EXT:WITH-TIMEOUT  
> 1.e-7 ...) ...); in: LAMBDA NIL
> ;     (SB-KERNEL:FLOAT-WAIT)
> ;
> ; note: deleting unreachable code
>
> ;     (HUNCHENTOOT::ENSURED-SLEEP-MILLIS 5)
> ;
> ; note: deleting unreachable code
>
> ; file: /Users/jensteich/Lisp/hunchentoot-0.15.3/port-sbcl.lisp
> ; in: EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
> ;     (HUNCHENTOOT::ENSURED-SLEEP-MILLIS 5)
> ;
> ; note: deleting unreachable code
>
> ; compiling (DEFMACRO WITH-TIMEOUT ...)
> ; compiling (DEFUN PROCESS-RUN-FUNCTION ...)
> ; compiling (DEFUN PROCESS-KILL ...)
> ; compiling (DEFINE-SYMBOL-MACRO *CURRENT-PROCESS* ...)
> ; compiling (DEFUN PROCESS-ALLOW-SCHEDULING ...)
> ; compiling (DEFUN RESOLVE-HOSTNAME ...)
> ; compiling (DEFUN START-UP-SERVER ...)
> ; compiling (DEFUN FORMAT-ADDRESS ...)
> ; compiling (DEFUN MAKE-SOCKET-STREAM ...)
> ; compiling (WHEN (FIND-SYMBOL "*DEBUG-PRINT-VARIABLE- 
> ALIST*" ...) ...)
> ; compiling (DEFUN GET-BACKTRACE ...)
>
> ; /Users/jensteich/Lisp/hunchentoot-0.15.3/port-sbcl.fasl written
> ; compilation finished in 0:00:00
> WARNING:
>   COMPILE-FILE warned while performing #<COMPILE-OP NIL {13F28EE1}> on
>   #<CL-SOURCE-FILE "port-sbcl" {12106F59}>.
>
>
> erred while invoking #<COMPILE-OP NIL {13F28EE1}> on
> #<CL-SOURCE-FILE "port-sbcl" {12106F59}>
>   [Condition of type ASDF:COMPILE-FAILED]
>
> Restarts:
>  0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {13F28EE1}> on  
> #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>.
>  1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {13F28EE1}> on  
> #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}> as having been  
> successful.
>  2: [ABORT-REQUEST] Abort handling SLIME request.
>  3: [ABORT] Exit debugger, returning to top level.
>
> Backtrace:
>  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL- 
> SOURCE-FILE)) #<unavailable argument> #<unavailable argument>  
> #<ASDF:COMPILE-OP NIL {13F28EE1}> #<ASDF:CL-SOURCE-FILE "port- 
> sbcl" {12106F59}>)
>      Locals:
>        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {13F28EE1}>
>        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>
>  1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.  
> SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument>  
> #<ASDF:COMPILE-OP NIL {13F28EE1}> #<ASDF:CL-SOURCE-FILE "port- 
> sbcl" {12106F59}>)
>      Locals:
>        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {13F28EE1}>
>        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "port-sbcl" {12106F59}>
>  2: ((LAMBDA NIL))
>      Locals:
>  3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
>      Locals:
>  4: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {1175099D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = 1
>        SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {1175099D}>
>  5: (ASDF:OPERATE ASDF:LOAD-OP :HUNCHENTOOT-TEST)
>      Locals:
>        SB-DEBUG::ARG-0 = 2
>        SB-DEBUG::ARG-1 = ASDF:LOAD-OP
>        SB-DEBUG::ARG-2 = :HUNCHENTOOT-TEST
>  6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF :HUNCHENTOOT-TEST) #<NULL- 
> LEXENV>)
>      Locals:
>        SB-DEBUG::ARG-0 = (ASDF :HUNCHENTOOT-TEST)
>        SB-DEBUG::ARG-1 = #<NULL-LEXENV>
>  7: (SWANK::EVAL-REGION "(asdf :hunchentoot-test)
> " T)
>      Locals:
>        SWANK::PACKAGE-UPDATE-P = T
>        STRING = "(asdf :hunchentoot-test)
> "
>  8: ((LAMBDA NIL))
>      Locals:
>  9: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T))  
> #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL)  
> {13F10B5D}>)
>      Locals:
>        SWANK-BACKEND::FN = #<CLOSURE (LAMBDA NIL) {13F10B5D}>
> 10: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL)  
> {13F10B5D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<CLOSURE (LAMBDA NIL) {13F10B5D}>
> 11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL  
> "(asdf :hunchentoot-test)
> ") #<NULL-LEXENV>)
>      Locals:
>        SB-DEBUG::ARG-0 = (SWANK:LISTENER-EVAL "(asdf :hunchentoot- 
> test)
> ")
>        SB-DEBUG::ARG-1 = #<NULL-LEXENV>
> 12: ((LAMBDA NIL))
>      Locals:
> 13: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T  
> T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK- 
> DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {13F1004D}>)
>      Locals:
>        SWANK-BACKEND::FUN = #<CLOSURE (LAMBDA NIL) {13F1004D}>
>        SWANK-BACKEND::HOOK = #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
> 14: ((LAMBDA NIL))
>      Locals:
> 15: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T  
> T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK- 
> DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {11A2F69D}>)
>      Locals:
>        SWANK-BACKEND::FUN = #<FUNCTION (LAMBDA NIL) {11A2F69D}>
>        SWANK-BACKEND::HOOK = #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
> 16: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {11EDB211}>  
> #<CLOSURE (LAMBDA NIL) {13F0DC7D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
>        SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {13F0DC7D}>
> 17: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {11EDB211}>  
> #<FUNCTION (LAMBDA NIL) {11A2F69D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
>        SB-DEBUG::ARG-1 = #<FUNCTION (LAMBDA NIL) {11A2F69D}>
> 18: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {11EDB211}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SWANK::CONNECTION {11EDB211}>
> 19: (SWANK::PROCESS-AVAILABLE-INPUT #<SB-SYS:FD-STREAM for "a  
> socket" {11ED0B81}> #<CLOSURE (LAMBDA NIL) {13F0DC3D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "a socket" {11ED0B81}>
>        SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA NIL) {13F0DC3D}>
> 20: ((FLET SWANK::HANDLER))
>      Locals:
> 21: ((LAMBDA (SWANK-BACKEND::_)) #<unused argument>)
>      Locals:
>        SWANK-BACKEND::FN = #<CLOSURE (FLET SWANK::HANDLER) {1205871D}>
> 22: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL)
>      Locals:
>        SB-DEBUG::ARG-0 = NIL
>        SB-DEBUG::ARG-1 = NIL
>        SB-DEBUG::ARG-2 = NIL
> 23: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)
>      Locals:
>        SB-IMPL::DIRECTION = :INPUT
>        SB-IMPL::FD = 0
>        TIMEOUT = NIL
> 24: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard  
> input" {122792D1}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "standard  
> input" {122792D1}>
> 25: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard  
> input" {122792D1}> NIL #:EOF-OBJECT)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SB-SYS:FD-STREAM for "standard  
> input" {122792D1}>
>        SB-DEBUG::ARG-1 = NIL
>        SB-DEBUG::ARG-2 = #:EOF-OBJECT
>      Catch-tags:
>        SB-IMPL::EOF-INPUT-CATCHER
> 26: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {122792D1}>  
> NIL #:EOF-OBJECT #<unused argument>)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = #:EOF-OBJECT
>        STREAM = #<SB-SYS:FD-STREAM for "standard input" {122792D1}>
> 27: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100BCC61}>  
> NIL #:EOF-OBJECT #<unused argument>)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = #:EOF-OBJECT
>        STREAM = #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {100BCC61}>
> 28: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
> INPUT* {11A5D7E1}> NIL #:EOF-OBJECT #<unused argument>)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = #:EOF-OBJECT
>        STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
> INPUT* {11A5D7E1}>
> 29: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL  
> SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> NIL (NIL) T)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = (NIL)
>        SB-IMPL::RECURSIVEP = T
>        STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
> INPUT* {11A5D7E1}>
> 30: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL  
> SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> NIL (NIL) NIL)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = (NIL)
>        SB-IMPL::RECURSIVEP = NIL
>        STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
> INPUT* {11A5D7E1}>
> 31: (READ #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD-INPUT*  
> {11A5D7E1}> NIL (NIL) NIL)
>      Locals:
>        SB-IMPL::EOF-ERROR-P = NIL
>        SB-IMPL::EOF-VALUE = (NIL)
>        SB-IMPL::RECURSIVEP = NIL
>        STREAM = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT-STANDARD- 
> INPUT* {11A5D7E1}>
> 32: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL  
> SWANK::*CURRENT-STANDARD-INPUT* {11A5D7E1}> #<unavailable argument>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<SYNONYM-STREAM :SYMBOL SWANK::*CURRENT- 
> STANDARD-INPUT* {11A5D7E1}>
>        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
> 33: (SB-IMPL::REPL-FUN NIL)
>      Locals:
>        SB-DEBUG::ARG-0 = NIL
> 34: (SB-IMPL::REPL-FUN NIL)
>      Locals:
>        SB-DEBUG::ARG-0 = 1
>        SB-DEBUG::ARG-1 = NIL
> 35: ((LAMBDA NIL))
>      Locals:
>      Catch-tags:
>        SB-INT:TOPLEVEL-CATCHER
> 36: ((LAMBDA NIL))
>      Locals:
>        SB-DEBUG::ARG-0 = 0
> 37: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA NIL)  
> {11BF7F0D}>)
>      Locals:
>        SB-DEBUG::ARG-0 = #<CLOSURE (LAMBDA NIL) {11BF7F0D}>
> 38: (SB-IMPL::TOPLEVEL-REPL NIL)
>      Locals:
>        SB-DEBUG::ARG-0 = NIL
> 39: (SB-IMPL::TOPLEVEL-INIT)
>      Locals:
> 40: ((LABELS SB-IMPL::RESTART-LISP))
>      Locals:
>      Catch-tags:
>        SB-IMPL::%END-OF-THE-WORLD
>
>
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From info at jensteich.de  Mon Mar 24 05:58:53 2008
From: info at jensteich.de (Jens Teich)
Date: Mon, 24 Mar 2008 06:58:53 +0100
Subject: [hunchentoot-devel] Problems with SBCL on MacOS
In-Reply-To: <61845833-60E6-42C3-A001-3A9521391B62@bobobeach.com>
References: <29E74AA7-3EFB-4A29-9DE7-142722D8E785@jensteich.de>
	<61845833-60E6-42C3-A001-3A9521391B62@bobobeach.com>
Message-ID: <38FEF8AD-A043-4105-B11C-C2AABA746CC2@jensteich.de>

>> and suggest that you build and install a threaded version of SBCL  
>> for running hunchentoot.
>>

This solves the problem, thanks.

Jens



From css at swissjabber.ch  Wed Mar 26 01:23:04 2008
From: css at swissjabber.ch (css)
Date: Wed, 26 Mar 2008 02:23:04 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <152701829.20080322004925@yandex.ru>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
Message-ID: <9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>

2008/3/21, Anton Vodonosov <avodonosov at yandex.ru>:
> >> As I noticed, Hunchentoot is not yet ported to ECL, even though the
>  >> ECL-documentation says that it has Gray-Streams-, Thread- and
>  >> Socket-Support as far as I read.
>  >>
>  >> Was there simply no interest to port it to ECL so far, or is there
>  >> any reason why it is not possible or very hard to port it to ECL, or
>  >> why one should not use ECL?
>
>  > I suppose there was simply no interest so far.  You're welcome to
>  > provide patches for ECL.
>
>  >   http://weitz.de/patches.html
>
>
> Not to say there was no interest at all, I'm quite interested in that,
>  but there is not enough free time, as usually...

I am trying to do this at the moment, but I have some problems. I have
"ported" trivial-gray-streams, chunga and flexi-streams (and cl+ssl
should also work, but I have a problem with the ssl-library at the
moment). Any package required by Hunchentoot compiles successfully.
Does anybody of you happen to know a Maintainer of these Packages, or
where I can submit the changes I have made?

Porting the Socket-Stuff was not hard, since it is compatible with
sb-bsd-sockets. Porting the Thread-Stuff was so far not hard except
for "with-timeout", and I use bordeaux-threads to implement this macro
for the moment (I was too lazy to really implement it correctly -
maybe I will do this soon, it shouldnt be too hard to replace it).

I had to replace the form

(loop for key = (read-line *hunchentoot-stream* nil nil)
                             while (and key (string-not-equal key "end"))
                             for value = (read-line *hunchentoot-stream* t)
                             collect (cons (make-keyword key) value)
                             do (maybe-write-to-header-stream key value)))

by some tagbody-go-form, because ECL doesnt support it.

I now have got a Version of Hunchentoot which compiles under ECL and
starts listening to a port if told. But it doesnt answer requests for
some reason. It doesnt throw errors (though *catch-errors-p*=nil) but
it seems not to answer the requests.
Maybe there is some Deadlock or endless loop (in my tagbody form for
instance), I dont know. I will try to figure it out as soon as I have
some free time again. If somebody is interested in this so far, just
ask, I will give the patches I have made.

C S S


From edi at agharta.de  Wed Mar 26 06:49:41 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 26 Mar 2008 07:49:41 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	(css@swissjabber.ch's
	message of "Wed, 26 Mar 2008 02:23:04 +0100")
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
Message-ID: <ulk463rp6.fsf@agharta.de>

On Wed, 26 Mar 2008 02:23:04 +0100, css <css at swissjabber.ch> wrote:

> Does anybody of you happen to know a Maintainer of these Packages,
> or where I can submit the changes I have made?

That shouldn't be too hard to find out, should it?

> I had to replace the form
>
> (loop for key = (read-line *hunchentoot-stream* nil nil)
>                              while (and key (string-not-equal key "end"))
>                              for value = (read-line *hunchentoot-stream* t)
>                              collect (cons (make-keyword key) value)
>                              do (maybe-write-to-header-stream key value)))
>
> by some tagbody-go-form, because ECL doesnt support it.

ECL doesn't support LOOP?!?

Maybe you can put your patches on some server somewhere or send them
to the list so others interested in the port can check them.

Cheers,
Edi.


From neuss at math.uni-karlsruhe.de  Wed Mar 26 08:40:00 2008
From: neuss at math.uni-karlsruhe.de (Nicolas Neuss)
Date: Wed, 26 Mar 2008 09:40:00 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <ulk463rp6.fsf@agharta.de> (Edi Weitz's message of "Wed\,
	26 Mar 2008 07\:49\:41 +0100")
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	<ulk463rp6.fsf@agharta.de>
Message-ID: <87d4phg9pb.fsf@ma-patru.mathematik.uni-karlsruhe.de>

Edi Weitz <edi at agharta.de> writes:

>> I had to replace the form
>>
>> (loop for key = (read-line *hunchentoot-stream* nil nil)
>>                              while (and key (string-not-equal key "end"))
>>                              for value = (read-line *hunchentoot-stream* t)
>>                              collect (cons (make-keyword key) value)
>>                              do (maybe-write-to-header-stream key value)))
>>
>> by some tagbody-go-form, because ECL doesnt support it.
>
> ECL doesn't support LOOP?!?

The use of the FOR clause after WHILE is (unfortunately, IMO) not allowed
by the standard.

Nicolas


From marc.battyani at fractalconcept.com  Wed Mar 26 08:52:37 2008
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Wed, 26 Mar 2008 09:52:37 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <ulk463rp6.fsf@agharta.de>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>	<u3aqjso4o.fsf@agharta.de>
	<152701829.20080322004925@yandex.ru>	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	<ulk463rp6.fsf@agharta.de>
Message-ID: <47EA0ED5.7070304@fractalconcept.com>


Edi Weitz wrote:
> On Wed, 26 Mar 2008 02:23:04 +0100, css <css at swissjabber.ch> wrote:
>   
>> I had to replace the form
>>
>> (loop for key = (read-line *hunchentoot-stream* nil nil)
>>                              while (and key (string-not-equal key "end"))
>>                              for value = (read-line *hunchentoot-stream* t)
>>                              collect (cons (make-keyword key) value)
>>                              do (maybe-write-to-header-stream key value)))
>>
>> by some tagbody-go-form, because ECL doesnt support it.
>>     
> ECL doesn't support LOOP?!?
>   
Unfortunately though handy, LOOP has a lot of quirks as well as under 
specified areas.
So here your usage of loop is not fully compliant because you use a FOR 
clause after a WHILE clause:

 From CLHS 6.1.2.1 Iteration Control:

The iteration control clauses for, as, and repeat must precede any other 
loop clauses, except initially, with, and named, since they establish 
variable bindings. When iteration control clauses are used in a loop, 
the corresponding termination tests in the loop body are evaluated 
before any other loop body code is executed.

This is why I switched to ITERATE in cl-pdf/cl-typesetting for complex 
loops. I still use LOOP a lot for all the simple loops though.

Marc




From xach at xach.com  Wed Mar 26 12:45:23 2008
From: xach at xach.com (Zach Beane)
Date: Wed, 26 Mar 2008 08:45:23 -0400
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <47EA0ED5.7070304@fractalconcept.com>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	<ulk463rp6.fsf@agharta.de> <47EA0ED5.7070304@fractalconcept.com>
Message-ID: <20080326124523.GV19732@xach.com>

On Wed, Mar 26, 2008 at 09:52:37AM +0100, Marc Battyani wrote:
> 
> Edi Weitz wrote:
> >On Wed, 26 Mar 2008 02:23:04 +0100, css <css at swissjabber.ch> wrote:
> >  
> >>I had to replace the form
> >>
> >>(loop for key = (read-line *hunchentoot-stream* nil nil)
> >>                             while (and key (string-not-equal key "end"))
> >>                             for value = (read-line *hunchentoot-stream* 
> >>                             t)
> >>                             collect (cons (make-keyword key) value)
> >>                             do (maybe-write-to-header-stream key value)))
> >>
> >>by some tagbody-go-form, because ECL doesnt support it.
> >>    
> >ECL doesn't support LOOP?!?
> >  
> Unfortunately though handy, LOOP has a lot of quirks as well as under 
> specified areas.

[dangerously offtopic, but...]

Are they really underspecified? My impression is that LOOP is strictly
specified, but loosely (i.e. incorrectly) implemented in many Common
Lisps.

Zach


From css at swissjabber.ch  Wed Mar 26 17:15:53 2008
From: css at swissjabber.ch (css)
Date: Wed, 26 Mar 2008 18:15:53 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <ulk463rp6.fsf@agharta.de>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	<ulk463rp6.fsf@agharta.de>
Message-ID: <9e4493f70803261015x296f4785r1ec6448afc8a751f@mail.gmail.com>

> ECL doesn't support LOOP?!?

It does support loop, but this LOOP seems not do be compliant with the
Standard, and ECL sais:

Iteration in LOOP follows body code.
Current LOOP context: FOR VALUE = (READ-LINE *HUNCHENTOOT-STREAM* T) COLLECT.

Clisp also warns: "WARNING: LOOP: FOR clauses should occur before the
loop's main body" but expands the loop-macro.


>  Maybe you can put your patches on some server somewhere or send them
>  to the list so others interested in the port can check them.

It is not very hard to port it. I had to shadow some Functions in
trivial-gray-streams, and replace defmethods on these symbols
(stream-element-type for instance) to the same symbols in the
gray:-Package (gray:stream-element-type). I have put the patches on
http://nasobem.i-networx.de/hunchentoot-patches/ (I used the Versions
from cliki.net), however: They are compiling (for me at least, with a
current checkout of ECL), but as I said, hunchentoot doesnt work yet
(and port-ecl.lisp is not written in a "good" format, no
documentation, etc., yet, and I have not written unix-ecl.lisp yet).

C S S


From marc.battyani at fractalconcept.com  Wed Mar 26 21:06:32 2008
From: marc.battyani at fractalconcept.com (Marc Battyani)
Date: Wed, 26 Mar 2008 22:06:32 +0100
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <20080326124523.GV19732@xach.com>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>	<u3aqjso4o.fsf@agharta.de>
	<152701829.20080322004925@yandex.ru>	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>	<ulk463rp6.fsf@agharta.de>
	<47EA0ED5.7070304@fractalconcept.com>
	<20080326124523.GV19732@xach.com>
Message-ID: <47EABAD8.2060109@fractalconcept.com>

Zach Beane wrote:
> On Wed, Mar 26, 2008 at 09:52:37AM +0100, Marc Battyani wrote:
>   
>> Unfortunately though handy, LOOP has a lot of quirks as well as under 
>> specified areas.
>>     
> [dangerously offtopic, but...]
>
> Are they really underspecified? My impression is that LOOP is strictly
> specified, but loosely (i.e. incorrectly) implemented in many Common
> Lisps.
>   
I had problems with some loops in cl-pdf which didn't work on CLISP. 
There have been several emails on the subject and the only conclusion 
was that the standard was ambiguous:
 >6.1.1.6., by saying that stepping and termination tests are "between"
 >and "just before" the loop body executions, contradicts 6.1.1.4. and
 >6.1.2.1., which say that these are _part_ of the loop body.

This is this problem that decided me to switch to ITERATE for complex 
loops in cl-pdf/typesetting (and my own projects).

BTW this is becoming off-topic and I don't want to start the debate 
again. I just wanted to say that complex loops with LOOP will not be 
portable.
(anyway the first loop of this discussion is not compliant at all)

Marc




From edi at agharta.de  Thu Mar 27 08:44:55 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 27 Mar 2008 09:44:55 +0100
Subject: [hunchentoot-devel] New release 0.15.4 (Was: Hunchentoot with ECL)
In-Reply-To: <87d4phg9pb.fsf@ma-patru.mathematik.uni-karlsruhe.de> (Nicolas
	Neuss's message of "Wed, 26 Mar 2008 09:40:00 +0100")
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de> <152701829.20080322004925@yandex.ru>
	<9e4493f70803251823q59c470eh8f5eba4bed22f025@mail.gmail.com>
	<ulk463rp6.fsf@agharta.de>
	<87d4phg9pb.fsf@ma-patru.mathematik.uni-karlsruhe.de>
Message-ID: <umyok4ku0.fsf_-_@agharta.de>

On Wed, 26 Mar 2008 09:40:00 +0100, Nicolas Neuss <neuss at math.uni-karlsruhe.de> wrote:

> The use of the FOR clause after WHILE is (unfortunately, IMO) not
> allowed by the standard.

And I thought that if SBCL's compiler allows it, it must be
ANSI-compliant... :)

Anyway, I've changed the offending LOOP slightly to appease ECL.


From larsnostdal at gmail.com  Sat Mar 29 23:55:53 2008
From: larsnostdal at gmail.com (Lars Rune =?utf-8?b?TsO4c3RkYWw=?=)
Date: Sat, 29 Mar 2008 23:55:53 +0000 (UTC)
Subject: [hunchentoot-devel] using SESSION-VALUE without START-SESSION will
	never call HT::COUNT-SESSION-USAGE
Message-ID: <loom.20080329T234055-295@post.gmane.org>

hi,
seems using HT:SESSION-VALUE without ever calling HT:START-SESSION never calls
HT::COUNT-SESSION-USAGE

CL-USER> (sb-introspect:who-calls 'ht::count-session-usage)
((HUNCHENTOOT:START-SESSION
  . #S(SB-INTROSPECT:DEFINITION-SOURCE
       :PATHNAME #P"/home/lars/programming/lisp/hunchentoot/session.lisp"
       :FORM-PATH (12 4)
       :CHARACTER-OFFSET 7759
       :FILE-WRITE-DATE 3415636264
       :PLIST NIL
       :DESCRIPTION NIL)))
CL-USER> (sb-introspect:who-calls 'ht:start-session)
NIL

so the only thing that calls HT::COUNT-SESSION-USAGE is HT:SESSION-START, and
nothing calls HT:SESSION-START .. (hope i got this right; i'm tired)

from the documentation (which is great btw.) I assumed "(counting only requests
which use sessions)" included cases where I used SESSION-VALUE since, well, i
"use" sessions then ... :)

http://www.weitz.de/hunchentoot/#*session-gc-frequency*

-- 
Lars Rune N?stdal
http://nostdal.org/



From larsnostdal at gmail.com  Sun Mar 30 00:59:33 2008
From: larsnostdal at gmail.com (Lars Rune =?utf-8?b?TsO4c3RkYWw=?=)
Date: Sun, 30 Mar 2008 00:59:33 +0000 (UTC)
Subject: [hunchentoot-devel] using SESSION-VALUE without START-SESSION
	=?utf-8?b?d2lsbAluZXZlcg==?= call HT::COUNT-SESSION-USAGE
References: <loom.20080329T234055-295@post.gmane.org>
Message-ID: <loom.20080330T004834-946@post.gmane.org>

Lars Rune N?stdal <larsnostdal <at> gmail.com> writes:

>
> so the only thing that calls HT::COUNT-SESSION-USAGE is HT:SESSION-START, and
> nothing calls HT:SESSION-START .. (hope i got this right; i'm tired)
> 

actually .. it seems (SETF SESSION-VALUE) does call HT:SESSION-START

..but i still expected different behavior based on:

"A session garbage collection (see SESSION-GC) will happen every
*SESSION-GC-FREQUENCY* requests (counting only requests which use sessions) if
the value of this variable is not NIL. It's default value is 50. "

..which led me to think this also included cases where SESSION-VALUE where
called ("requests which use sessions")

..i'm working on a chat toy (ajax and comet-polling will lead to 50 requests
pretty fast).. and i needed to have sessions timeout when users leave the
"chat-page" or get disconnected so i can update the nick-list close to real time

-- 
Lars Rune N?stdal
http://nostdal.org/



From larsnostdal at gmail.com  Sun Mar 30 01:21:18 2008
From: larsnostdal at gmail.com (Lars Rune =?utf-8?b?TsO4c3RkYWw=?=)
Date: Sun, 30 Mar 2008 01:21:18 +0000 (UTC)
Subject: [hunchentoot-devel] using SESSION-VALUE without
	=?utf-8?b?U1RBUlQtU0VTU0lPTgl3aWxsCW5ldmVy?= call
	HT::COUNT-SESSION-USAGE
References: <loom.20080329T234055-295@post.gmane.org>
	<loom.20080330T004834-946@post.gmane.org>
Message-ID: <loom.20080330T012007-963@post.gmane.org>

Lars Rune N?stdal <larsnostdal <at> gmail.com> writes:
>
> "A session garbage collection (see SESSION-GC) will happen every
> *SESSION-GC-FREQUENCY* requests (counting only requests which use sessions) if
> the value of this variable is not NIL. It's default value is 50. "

maybe it should be "counting only requests which start a new session"?

-- 
Lars Rune N?stdal
http://nostdal.org/