From nowhere.man at levallois.eu.org Sun Apr 1 14:24:11 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Sun, 1 Apr 2007 16:24:11 +0200
Subject: [hunchentoot-devel] Displaying partial output from the handler?
In-Reply-To:
References:
<20070326195125.GA24992@localhost.localdomain>
<20070327030858.GJ19256@bateleur.arcanes.fr.eu.org>
Message-ID: <20070401142411.GB19256@bateleur.arcanes.fr.eu.org>
Scribit Andrei Stebakov dies 27/03/2007 hora 10:36:
> Pierre, I am not sure I understood you. Could you give some example of
> what you described?
Sure, here is a file with a complete toy example. Just load the file and
go to the following URI:
http://localhost:8888/step1
After approximately 8 seconds, your browser should show you a second
page, located at:
http://localhost:8888/step2
In the meantime, most browsers should leave the first page visible. I'm
confident this works on most mainstream browsers because the french
national railroad company uses this trick on its online store (that's
where I learned it, by the way, I seem to remember).
I successfully tested this example under SBCL 1.0.0.0 with Linux and
both Firefox and Konqueror.
Visually,
Pierre
--
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
#|
Copyright (c) 2007 Pierre Thierry
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
|#
#| Load and use the needed packages |#
(asdf:oos 'asdf:load-op :hunchentoot)
(asdf:oos 'asdf:load-op :cl-who)
(use-package :hunchentoot)
(use-package :cl-who)
#| Define the two functions that output pages |#
(defun waiter-page (title finished-uri)
"Return a web page that immediately redirects to another URI"
(let ((refresh-content (format nil "0;URL=~a" finished-uri)))
(with-html-output-to-string (out nil :prologue t :indent t)
(:html
(:head
(:title (esc title))
(:meta :http-equiv "refresh" :content refresh-content))
(:body
(:h1 (esc title))
(:p "Wait. Loooong."))))))
(defun slow-page (message)
"Return a web page showing a message, but only after waiting some time"
(sleep 8)
(with-html-output-to-string (out nil :prologue t :indent t)
(:html
(:head
(:title "Message")
(:body
(:h1 "Message")
(:p (esc message))
(:hr)
(:p "Wow. Took time!"))))))
#| Setup the server |#
(push (create-prefix-dispatcher "/step1" (lambda () (waiter-page "Testing two-steps serving" "/step2"))) *dispatch-table*)
(push (create-prefix-dispatcher "/step2" (lambda () (slow-page "It's done"))) *dispatch-table*)
(start-server :port 8888)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From hutch at recursive.ca Tue Apr 3 13:00:32 2007
From: hutch at recursive.ca (Bob Hutchison)
Date: Tue, 3 Apr 2007 09:00:32 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
Message-ID: <437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
> I got a folder on my linux box that contains about 240 images of font
> preview generated from cl-gd (Thanks, Edi!).
> When I show them from static apache handler it takes approximately 30
> seconds. Same thing from hunchentoot static handler
> (create-folder-dispatcher-and-handler) takes about 50 seconds. I
> understand
> it's not a big deal, but still I'd like to know what might get in
> the way. I
> use hunchentoot behind mod-proxy.
Have you tried going straight at the hunchentoot server? This as made
some difference to my stuff in the past. Might give you a better idea
where the problem is.
Cheers,
Bob
> Here are links (first is static apache, second is hunchentoot):
> http://www.greenpixeldesign.com/fonts.html
> http://www.greenpixeldesign.com/cphandler/fonts.html
>
> Thank you,
> Andrew
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
----
Bob Hutchison -- tumblelog at
Recursive Design Inc. --
xampl for Ruby --
From lispercat at gmail.com Tue Apr 3 13:31:46 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 3 Apr 2007 09:31:46 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To: <437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
Message-ID:
Hi Bob,
Could you advise how would I "go straight at the hunchentoot server"?
Also I have a feeling that the more I call the images from the server the
slower it gets. I even removed (no-chache) option from the page generation
so I thought that having images in caches would speed it up. In this context
I think what Edi says about Hunchentoot switching contexts with Apache while
page generation makes sense. My server is PIII 600 MHz, maybe it's time to
upgrade it.
Thank you,
Andrew
On 4/3/07, Bob Hutchison wrote:
>
>
> On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
>
> > I got a folder on my linux box that contains about 240 images of font
> > preview generated from cl-gd (Thanks, Edi!).
> > When I show them from static apache handler it takes approximately 30
> > seconds. Same thing from hunchentoot static handler
> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
> > understand
> > it's not a big deal, but still I'd like to know what might get in
> > the way. I
> > use hunchentoot behind mod-proxy.
>
> Have you tried going straight at the hunchentoot server? This as made
> some difference to my stuff in the past. Might give you a better idea
> where the problem is.
>
> Cheers,
> Bob
>
> > Here are links (first is static apache, second is hunchentoot):
> > http://www.greenpixeldesign.com/fonts.html
> > http://www.greenpixeldesign.com/cphandler/fonts.html
> >
> > Thank you,
> > Andrew
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> ----
> Bob Hutchison -- tumblelog at www.recursive.ca/so/>
> Recursive Design Inc. --
> xampl for Ruby --
>
>
>
> _______________________________________________
> 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:
From hutch at recursive.ca Tue Apr 3 14:56:27 2007
From: hutch at recursive.ca (Bob Hutchison)
Date: Tue, 3 Apr 2007 10:56:27 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
Message-ID: <35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
> Hi Bob,
>
> Could you advise how would I "go straight at the hunchentoot server"?
You'll have something like:
ProxyPass /cphandler/ http://localhost:4321/cphandler/
ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/
in your httpd config file.
Just point your browser at whatever corresponds to http://localhost:
4321/cphandler/
If you are running on a different machine than the server you'll have
to temporarily open whatever port you are using (and based on the
description of your server below, I'm guessing you *are* running on a
different machine (if you aren't then it is definitely time for an
upgrade :-))
> Also I have a feeling that the more I call the images from the
> server the
> slower it gets.
I pretty sure I've not seen this before.
> I even removed (no-chache) option from the page generation
> so I thought that having images in caches would speed it up. In
> this context
> I think what Edi says about Hunchentoot switching contexts with
> Apache while
> page generation makes sense. My server is PIII 600 MHz, maybe it's
> time to
> upgrade it.
it should still be sufficient for a website.
Cheers,
Bob
>
> Thank you,
> Andrew
>
> On 4/3/07, Bob Hutchison wrote:
>>
>>
>> On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
>>
>> > I got a folder on my linux box that contains about 240 images of
>> font
>> > preview generated from cl-gd (Thanks, Edi!).
>> > When I show them from static apache handler it takes
>> approximately 30
>> > seconds. Same thing from hunchentoot static handler
>> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
>> > understand
>> > it's not a big deal, but still I'd like to know what might get in
>> > the way. I
>> > use hunchentoot behind mod-proxy.
>>
>> Have you tried going straight at the hunchentoot server? This as made
>> some difference to my stuff in the past. Might give you a better idea
>> where the problem is.
>>
>> Cheers,
>> Bob
>>
>> > Here are links (first is static apache, second is hunchentoot):
>> > http://www.greenpixeldesign.com/fonts.html
>> > http://www.greenpixeldesign.com/cphandler/fonts.html
>> >
>> > Thank you,
>> > Andrew
>> > _______________________________________________
>> > tbnl-devel site list
>> > tbnl-devel at common-lisp.net
>> > http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>> ----
>> Bob Hutchison -- tumblelog at > www.recursive.ca/so/>
>> Recursive Design Inc. --
>> xampl for Ruby -- > xampl/>
>>
>>
>>
>> _______________________________________________
>> 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
----
Bob Hutchison -- tumblelog at
Recursive Design Inc. --
xampl for Ruby --
From hutch at recursive.ca Tue Apr 3 15:00:28 2007
From: hutch at recursive.ca (Bob Hutchison)
Date: Tue, 3 Apr 2007 11:00:28 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To: <35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
Message-ID: <10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
>
> On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
>
>> Hi Bob,
>>
>> Could you advise how would I "go straight at the hunchentoot server"?
>
> You'll have something like:
>
> ProxyPass /cphandler/ http://localhost:4321/cphandler/
> ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/
>
> in your httpd config file.
>
> Just point your browser at whatever corresponds to http://localhost:
> 4321/cphandler/
BTW, if this does turn out to be faster, you might consider running
it without apache at all. I've been doing this for a couple of years
now (starting with TBNL) though my site is entirely dynamic. Edi has
been cautious about recommending this, which I understand, but...
Cheers,
Bob
>
> If you are running on a different machine than the server you'll
> have to temporarily open whatever port you are using (and based on
> the description of your server below, I'm guessing you *are*
> running on a different machine (if you aren't then it is definitely
> time for an upgrade :-))
>
>
>> Also I have a feeling that the more I call the images from the
>> server the
>> slower it gets.
>
> I pretty sure I've not seen this before.
>
>> I even removed (no-chache) option from the page generation
>> so I thought that having images in caches would speed it up. In
>> this context
>> I think what Edi says about Hunchentoot switching contexts with
>> Apache while
>> page generation makes sense. My server is PIII 600 MHz, maybe it's
>> time to
>> upgrade it.
>
> it should still be sufficient for a website.
>
> Cheers,
> Bob
>
>>
>> Thank you,
>> Andrew
>>
>> On 4/3/07, Bob Hutchison wrote:
>>>
>>>
>>> On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
>>>
>>> > I got a folder on my linux box that contains about 240 images
>>> of font
>>> > preview generated from cl-gd (Thanks, Edi!).
>>> > When I show them from static apache handler it takes
>>> approximately 30
>>> > seconds. Same thing from hunchentoot static handler
>>> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
>>> > understand
>>> > it's not a big deal, but still I'd like to know what might get in
>>> > the way. I
>>> > use hunchentoot behind mod-proxy.
>>>
>>> Have you tried going straight at the hunchentoot server? This as
>>> made
>>> some difference to my stuff in the past. Might give you a better
>>> idea
>>> where the problem is.
>>>
>>> Cheers,
>>> Bob
>>>
>>> > Here are links (first is static apache, second is hunchentoot):
>>> > http://www.greenpixeldesign.com/fonts.html
>>> > http://www.greenpixeldesign.com/cphandler/fonts.html
>>> >
>>> > Thank you,
>>> > Andrew
>>> > _______________________________________________
>>> > tbnl-devel site list
>>> > tbnl-devel at common-lisp.net
>>> > http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>>> ----
>>> Bob Hutchison -- tumblelog at >> www.recursive.ca/so/>
>>> Recursive Design Inc. --
>>> xampl for Ruby -- >> xampl/>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> ----
> Bob Hutchison -- tumblelog at www.recursive.ca/so/>
> Recursive Design Inc. --
> xampl for Ruby -- xampl/>
>
>
>
----
Bob Hutchison -- tumblelog at
Recursive Design Inc. --
xampl for Ruby --
From ctdean at sokitomi.com Tue Apr 3 17:16:44 2007
From: ctdean at sokitomi.com (Chris Dean)
Date: Tue, 03 Apr 2007 10:16:44 -0700
Subject: [hunchentoot-devel] hcl:mark-and-sweep on 32 bit LispWorks
Message-ID:
The HCL:MARK-AND-SWEEP function is only available on 32 bit LispWorks.
A small patch is below to allow hunchentoot to run on 64 bit versions
of LispWorks.
Cheers,
Chris Dean
diff -rN -u old-hunchentoot/util.lisp new-hunchentoot/util.lisp
--- old-contrib/hunchentoot/util.lisp 2007-04-03 10:13:17.000000000 -0700
+++ new-hunchentoot/util.lisp 2007-04-03 10:13:18.000000000 -0700
@@ -461,7 +461,7 @@
(chunked-stream-input-chunking-p (flexi-stream-stream *hunchentoot-stream*)))
(defun cleanup-function ()
- "The default for *CLEANUP-FUNCTION*. Invokes a GC on LispWorks and
+ "The default for *CLEANUP-FUNCTION*. Invokes a GC on 32 bit LispWorks and
does nothing on other Lisps."
- #+:lispworks
- (hcl:mark-and-sweep 2))
\ No newline at end of file
+ #+:lispworks-32bit
+ (hcl:mark-and-sweep 2))
From lispercat at gmail.com Tue Apr 3 21:25:31 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 3 Apr 2007 17:25:31 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To: <10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
Bob, even if I can see it from browser the way you described, how would I
benefit from it if I need to handle all my images with
create-folder-dispatcher-and-handler?
Thank you,
Andrew
On 4/3/07, Bob Hutchison wrote:
>
>
> On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
>
> >
> > On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
> >
> >> Hi Bob,
> >>
> >> Could you advise how would I "go straight at the hunchentoot server"?
> >
> > You'll have something like:
> >
> > ProxyPass /cphandler/ http://localhost:4321/cphandler/
> > ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/
> >
> > in your httpd config file.
> >
> > Just point your browser at whatever corresponds to http://localhost:
> > 4321/cphandler/
>
> BTW, if this does turn out to be faster, you might consider running
> it without apache at all. I've been doing this for a couple of years
> now (starting with TBNL) though my site is entirely dynamic. Edi has
> been cautious about recommending this, which I understand, but...
>
> Cheers,
> Bob
>
> >
> > If you are running on a different machine than the server you'll
> > have to temporarily open whatever port you are using (and based on
> > the description of your server below, I'm guessing you *are*
> > running on a different machine (if you aren't then it is definitely
> > time for an upgrade :-))
> >
> >
> >> Also I have a feeling that the more I call the images from the
> >> server the
> >> slower it gets.
> >
> > I pretty sure I've not seen this before.
> >
> >> I even removed (no-chache) option from the page generation
> >> so I thought that having images in caches would speed it up. In
> >> this context
> >> I think what Edi says about Hunchentoot switching contexts with
> >> Apache while
> >> page generation makes sense. My server is PIII 600 MHz, maybe it's
> >> time to
> >> upgrade it.
> >
> > it should still be sufficient for a website.
> >
> > Cheers,
> > Bob
> >
> >>
> >> Thank you,
> >> Andrew
> >>
> >> On 4/3/07, Bob Hutchison wrote:
> >>>
> >>>
> >>> On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
> >>>
> >>> > I got a folder on my linux box that contains about 240 images
> >>> of font
> >>> > preview generated from cl-gd (Thanks, Edi!).
> >>> > When I show them from static apache handler it takes
> >>> approximately 30
> >>> > seconds. Same thing from hunchentoot static handler
> >>> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
> >>> > understand
> >>> > it's not a big deal, but still I'd like to know what might get in
> >>> > the way. I
> >>> > use hunchentoot behind mod-proxy.
> >>>
> >>> Have you tried going straight at the hunchentoot server? This as
> >>> made
> >>> some difference to my stuff in the past. Might give you a better
> >>> idea
> >>> where the problem is.
> >>>
> >>> Cheers,
> >>> Bob
> >>>
> >>> > Here are links (first is static apache, second is hunchentoot):
> >>> > http://www.greenpixeldesign.com/fonts.html
> >>> > http://www.greenpixeldesign.com/cphandler/fonts.html
> >>> >
> >>> > Thank you,
> >>> > Andrew
> >>> > _______________________________________________
> >>> > tbnl-devel site list
> >>> > tbnl-devel at common-lisp.net
> >>> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>>
> >>> ----
> >>> Bob Hutchison -- tumblelog at >>> www.recursive.ca/so/>
> >>> Recursive Design Inc. --
> >>> xampl for Ruby -- >>> xampl/>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > ----
> > Bob Hutchison -- tumblelog at > www.recursive.ca/so/>
> > Recursive Design Inc. --
> > xampl for Ruby -- > xampl/>
> >
> >
> >
>
> ----
> Bob Hutchison -- tumblelog at www.recursive.ca/so/>
> Recursive Design Inc. --
> xampl for Ruby --
>
>
>
> _______________________________________________
> 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:
From lispercat at gmail.com Tue Apr 3 22:13:48 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 3 Apr 2007 18:13:48 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
Guys, I need your help here. The static image loading with
create-folder-dispatcher-and-handler is really slow. Here I have just 5
images and Apache loads it almost instantaneously and HT handler takes about
10 sec!
I have a page where I have to use CSS and other images and the page loads
painfully slow.
I thought the reason was that I don't have enougt memory so I started
removing packages from my Lisp process (I use CMUCL) but it doesn't help
(rebooting the system or Lisp also doesn't help). Could it be any encoding
issues I could play with?
Here are the links for Apache and Hunchentoot handlers:
http://www.greenpixeldesign.com/fonts.html
http://www.greenpixeldesign.com/cphandler/fonts.html
Any suggestions are greatly appreciated!
Andrew
On 4/3/07, Andrei Stebakov wrote:
>
> Bob, even if I can see it from browser the way you described, how would I
> benefit from it if I need to handle all my images with
> create-folder-dispatcher-and-handler?
>
> Thank you,
> Andrew
>
> On 4/3/07, Bob Hutchison wrote:
> >
> >
> > On 3-Apr-07, at 10:56 AM, Bob Hutchison wrote:
> >
> > >
> > > On 3-Apr-07, at 9:31 AM, Andrei Stebakov wrote:
> > >
> > >> Hi Bob,
> > >>
> > >> Could you advise how would I "go straight at the hunchentoot server"?
> >
> > >
> > > You'll have something like:
> > >
> > > ProxyPass /cphandler/ http://localhost:4321/cphandler/
> > > ProxyPassReverse /cphandler/ http://localhost:4321/cphandler/
> > >
> > > in your httpd config file.
> > >
> > > Just point your browser at whatever corresponds to http://localhost:
> > > 4321/cphandler/
> >
> > BTW, if this does turn out to be faster, you might consider running
> > it without apache at all. I've been doing this for a couple of years
> > now (starting with TBNL) though my site is entirely dynamic. Edi has
> > been cautious about recommending this, which I understand, but...
> >
> > Cheers,
> > Bob
> >
> > >
> > > If you are running on a different machine than the server you'll
> > > have to temporarily open whatever port you are using (and based on
> > > the description of your server below, I'm guessing you *are*
> > > running on a different machine (if you aren't then it is definitely
> > > time for an upgrade :-))
> > >
> > >
> > >> Also I have a feeling that the more I call the images from the
> > >> server the
> > >> slower it gets.
> > >
> > > I pretty sure I've not seen this before.
> > >
> > >> I even removed (no-chache) option from the page generation
> > >> so I thought that having images in caches would speed it up. In
> > >> this context
> > >> I think what Edi says about Hunchentoot switching contexts with
> > >> Apache while
> > >> page generation makes sense. My server is PIII 600 MHz, maybe it's
> > >> time to
> > >> upgrade it.
> > >
> > > it should still be sufficient for a website.
> > >
> > > Cheers,
> > > Bob
> > >
> > >>
> > >> Thank you,
> > >> Andrew
> > >>
> > >> On 4/3/07, Bob Hutchison < hutch at recursive.ca> wrote:
> > >>>
> > >>>
> > >>> On 30-Mar-07, at 4:24 PM, Andrei Stebakov wrote:
> > >>>
> > >>> > I got a folder on my linux box that contains about 240 images
> > >>> of font
> > >>> > preview generated from cl-gd (Thanks, Edi!).
> > >>> > When I show them from static apache handler it takes
> > >>> approximately 30
> > >>> > seconds. Same thing from hunchentoot static handler
> > >>> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
> > >>> > understand
> > >>> > it's not a big deal, but still I'd like to know what might get in
> > >>> > the way. I
> > >>> > use hunchentoot behind mod-proxy.
> > >>>
> > >>> Have you tried going straight at the hunchentoot server? This as
> > >>> made
> > >>> some difference to my stuff in the past. Might give you a better
> > >>> idea
> > >>> where the problem is.
> > >>>
> > >>> Cheers,
> > >>> Bob
> > >>>
> > >>> > Here are links (first is static apache, second is hunchentoot):
> > >>> > http://www.greenpixeldesign.com/fonts.html
> > >>> > http://www.greenpixeldesign.com/cphandler/fonts.html
> > >>> >
> > >>> > Thank you,
> > >>> > Andrew
> > >>> > _______________________________________________
> > >>> > tbnl-devel site list
> > >>> > tbnl-devel at common-lisp.net
> > >>> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> > >>>
> > >>> ----
> > >>> Bob Hutchison -- tumblelog at > >>> www.recursive.ca/so/>
> > >>> Recursive Design Inc. --
> > >>> xampl for Ruby -- < http://rubyforge.org/projects/
> > >>> xampl/>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> 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
> > >
> > > ----
> > > Bob Hutchison -- tumblelog at > > www.recursive.ca/so/>
> > > Recursive Design Inc. --
> > > xampl for Ruby -- > > xampl/>
> > >
> > >
> > >
> >
> > ----
> > Bob Hutchison -- tumblelog at > www.recursive.ca/so/>
> > Recursive Design Inc. -- < http://www.recursive.ca/>
> > xampl for Ruby --
> >
> >
> >
> > _______________________________________________
> > 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:
From ctdean at sokitomi.com Tue Apr 3 23:06:41 2007
From: ctdean at sokitomi.com (Chris Dean)
Date: Tue, 03 Apr 2007 16:06:41 -0700
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
(Andrei Stebakov's message of "Tue, 3 Apr 2007 18:13:48 -0400")
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
"Andrei Stebakov" writes:
> http://www.greenpixeldesign.com/fonts.html
> http://www.greenpixeldesign.com/cphandler/fonts.html
I'm late to the thread and maybe this has been answered already, but
do you have a short snippet of code that replicates the problem? Can
you send it out?
I also am unable to reach the cphandler link above.
Cheers,
Chris Dean
From edi at agharta.de Tue Apr 3 23:09:24 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 00:09:24 +0100
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
(Andrei Stebakov's message of "Tue, 3 Apr 2007 18:13:48 -0400")
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
On Tue, 3 Apr 2007 18:13:48 -0400, "Andrei Stebakov" wrote:
> Guys, I need your help here. The static image loading with
> create-folder-dispatcher-and-handler is really slow. Here I have
> just 5 images and Apache loads it almost instantaneously and HT
> handler takes about 10 sec!
That is certainly much slower than it should be. Have you tried SBCL
in the meantime? And are you using the dreaded
MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
on CMUCL? If not, that'd probably explain your problems.
> Here are the links for Apache and Hunchentoot handlers:
>
> http://www.greenpixeldesign.com/fonts.html
> http://www.greenpixeldesign.com/cphandler/fonts.html
The second link doesn't work for me.
From lispercat at gmail.com Tue Apr 3 23:19:31 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 3 Apr 2007 19:19:31 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
Sorry Edi, I am in the process of moving it to SBCL this is why it doesn't
work.
I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly, maybe some
other package uses it?
Thank you,
Andrew
On 4/3/07, Edi Weitz wrote:
>
> On Tue, 3 Apr 2007 18:13:48 -0400, "Andrei Stebakov"
> wrote:
>
> > Guys, I need your help here. The static image loading with
> > create-folder-dispatcher-and-handler is really slow. Here I have
> > just 5 images and Apache loads it almost instantaneously and HT
> > handler takes about 10 sec!
>
> That is certainly much slower than it should be. Have you tried SBCL
> in the meantime? And are you using the dreaded
>
> MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
>
> on CMUCL? If not, that'd probably explain your problems.
>
> > Here are the links for Apache and Hunchentoot handlers:
> >
> > http://www.greenpixeldesign.com/fonts.html
> > http://www.greenpixeldesign.com/cphandler/fonts.html
>
> The second link doesn't work for me.
> _______________________________________________
> 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:
From edi at agharta.de Tue Apr 3 23:29:30 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 00:29:30 +0100
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
(Andrei Stebakov's message of "Tue, 3 Apr 2007 19:19:31 -0400")
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
On Tue, 3 Apr 2007 19:19:31 -0400, "Andrei Stebakov" wrote:
> I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly
Use it. Start up a new image, execute the function above and only
afterwards start your server. Then report about your results.
That should speed up response times on CMUCL considerably. Search
Google for why it does that. And ask on the CMUCL mailing list why
it's not enabled by default - I don't know.
From lispercat at gmail.com Wed Apr 4 04:16:47 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Wed, 4 Apr 2007 00:16:47 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
Thank you, Edi. After I swiched to SBCL it became fast enough.
Regards,
Andrew
On 4/3/07, Edi Weitz wrote:
>
> On Tue, 3 Apr 2007 19:19:31 -0400, "Andrei Stebakov"
> wrote:
>
> > I don't use MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS explicitly
>
> Use it. Start up a new image, execute the function above and only
> afterwards start your server. Then report about your results.
>
> That should speed up response times on CMUCL considerably. Search
> Google for why it does that. And ask on the CMUCL mailing list why
> it's not enabled by default - I don't know.
> _______________________________________________
> 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:
From edi at agharta.de Wed Apr 4 05:55:30 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 06:55:30 +0100
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
(Andrei Stebakov's message of "Wed, 4 Apr 2007 00:16:47 -0400")
References:
<437399D5-C836-48B8-B72E-D27F3DDB038E@recursive.ca>
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
On Wed, 4 Apr 2007 00:16:47 -0400, "Andrei Stebakov" wrote:
> Thank you, Edi. After I swiched to SBCL it became fast enough.
Good.
It would be useful to know if the CMUCL version was only too slow
because you didn't know about MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS.
The mailing list is not only there to help you with your specific
problems but also as a reference other people can look at if they have
similar problems. So, if you could try with this modification and
report back to the list as I asked you to do, that'd be a welcome
feedback.
From edi at agharta.de Wed Apr 4 07:51:24 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 08:51:24 +0100
Subject: [hunchentoot-devel] hcl:mark-and-sweep on 32 bit LispWorks
In-Reply-To: (Chris Dean's message of
"Tue, 03 Apr 2007 10:16:44 -0700")
References:
Message-ID:
On Tue, 03 Apr 2007 10:16:44 -0700, Chris Dean wrote:
> The HCL:MARK-AND-SWEEP function is only available on 32 bit
> LispWorks. A small patch is below to allow hunchentoot to run on 64
> bit versions of LispWorks.
Thanks, that will be in the next release.
> + #+:lispworks-32bit
I'll change that to
#+(and :lispworks (not :lispworks-64bit))
as I think :LISPWORK-32BIT is not a feature of LW 4.x. (I hope
:LISPWORKS-64BIT exists. I don't have a 64-bit Lisp to test with.)
From edi at agharta.de Wed Apr 4 07:54:24 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 08:54:24 +0100
Subject: [hunchentoot-devel] New release 0.8.1
Message-ID:
ChangeLog:
Version 0.8.1
2007-04-04
Added HUNCHENTOOT-MP package (suggested by Cyrus Harmon)
Only invoke MARK-AND-SWEEP for 32-bit versions of LW (thanks to Chris Dean)
Exported REASON-PHRASE
Download:
http://weitz.de/files/hunchentoot.tar.gz
Have fun,
Edi.
From ctdean at sokitomi.com Wed Apr 4 09:28:06 2007
From: ctdean at sokitomi.com (Chris Dean)
Date: Wed, 04 Apr 2007 02:28:06 -0700
Subject: [hunchentoot-devel] hcl:mark-and-sweep on 32 bit LispWorks
In-Reply-To: (Edi Weitz's message of "Wed,
04 Apr 2007 08:51:24 +0100")
References:
Message-ID:
> (I hope :LISPWORKS-64BIT exists. I don't have a 64-bit Lisp to
> test with.)
The :LISPWORKS-64BIT feature does exists. My *features* contains
(among others of course):
:COMMON-LISPWORKS :LISPWORKS :LISPWORKS5 :LISPWORKS5.0 :LISPWORKS-64BIT
Cheers,
Chris Dean
From lispercat at gmail.com Wed Apr 4 16:08:57 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Wed, 4 Apr 2007 12:08:57 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
Yes, it put it in my .cmucl-init.lisp so it looks like:
(require :asdf)
(push "/home/andrew/systems/" asdf:*central-registry*)
(asdf:oos 'asdf:load-op :swank)
(setf swank:*use-dedicated-output-stream* nil)
(swank:create-server :port 4005 :dont-close t)
(mp::startup-idle-and-top-level-loops)
The only problem I had was that my detachtty command :
detachtty --dribble-file $dtty/cmulisp.dribble --log-file \
$dtty/detachtty.log --pid-file $dtty/start.lisp.pid \
$dtty/cmulisp.socket /usr/bin/cmucl -load "/LispWeb/WebHandler.lisp"
It just skipped loading the WebHandler.lisp for some reason. Never mind, I
connected to lisp, and started my hunchentoot process manually and after
that the whole thing started to work pretty fast (just like with SBCL).
Thank you,
Andrew
On 4/4/07, Edi Weitz wrote:
>
> On Wed, 4 Apr 2007 00:16:47 -0400, "Andrei Stebakov"
> wrote:
>
> > Thank you, Edi. After I swiched to SBCL it became fast enough.
>
> Good.
>
> It would be useful to know if the CMUCL version was only too slow
> because you didn't know about MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS.
> The mailing list is not only there to help you with your specific
> problems but also as a reference other people can look at if they have
> similar problems. So, if you could try with this modification and
> report back to the list as I asked you to do, that'd be a welcome
> feedback.
> _______________________________________________
> 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:
From edi at agharta.de Wed Apr 4 17:47:31 2007
From: edi at agharta.de (Edi Weitz)
Date: Wed, 04 Apr 2007 19:47:31 +0200
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
(Andrei Stebakov's message of "Wed, 4 Apr 2007 12:08:57 -0400")
References:
<35B273C2-9CBC-483C-ABCE-B6DFB66A45BF@recursive.ca>
<10FFD096-2C57-42CC-A0D8-E780CB22EFE4@recursive.ca>
Message-ID:
On Wed, 4 Apr 2007 12:08:57 -0400, "Andrei Stebakov" wrote:
> Yes, it put it in my .cmucl-init.lisp so it looks like:
> (require :asdf)
> (push "/home/andrew/systems/" asdf:*central-registry*)
> (asdf:oos 'asdf:load-op :swank)
> (setf swank:*use-dedicated-output-stream* nil)
> (swank:create-server :port 4005 :dont-close t)
> (mp::startup-idle-and-top-level-loops)
>
> The only problem I had was that my detachtty command :
> detachtty --dribble-file $dtty/cmulisp.dribble --log-file \
> $dtty/detachtty.log --pid-file $dtty/start.lisp.pid \
> $dtty/cmulisp.socket /usr/bin/cmucl -load "/LispWeb/WebHandler.lisp"
>
> It just skipped loading the WebHandler.lisp for some reason.
Yeah, that is to be expected AFAIK. Strange thing, this
STARTUP-... function because it doesn't return.
> Never mind, I connected to lisp, and started my hunchentoot process
> manually and after that the whole thing started to work pretty fast
> (just like with SBCL).
Good to know, thanks.
From edi at agharta.de Thu Apr 5 13:49:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 05 Apr 2007 15:49:50 +0200
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] 0.11.1 trouble.
In-Reply-To: <4614FBA4.2030309@gmail.com> (quasi's message of "Thu, 05 Apr
2007 19:07:40 +0530")
References: <4614FBA4.2030309@gmail.com>
Message-ID:
On Thu, 05 Apr 2007 19:07:40 +0530, quasi wrote:
> I am running Hunchentoot 8.1.
0.8.1 I hope... :)
> As soon as I upgraded to flexi-streams 0.11.1 I have encountered a
> weird problem. Hunchentoot (or anything else) threw no errors but
> the socket was getting closed unexpectedly I think, because links
> cribbed "error reading socket" or something. I am running Allegro
> 8.0 Enterprise 64bit on Redhat Linux. (problem also persisted on
> Allegro 8.0 for the Intel Mac's)
>
> As soon as I went back to 0.8.0 (my previous version) all worked as
> before.
>
> Am I doing something wrong here ?
I doubt it. There were significant changes between 0.8.0 and 0.11.1
and it is likely that you're the first one to use the new version on
AllegroCL, especially on a 64-bit version (if that matters, don't
know).
There's also a chance that some of my recent Hunchentoot changes which
I hastily submitted in the wake of my ILC preparations broke something
which results in sockets being closed although they shouldn't. That's
why I'm sending a copy of this to tbnl-devel as well.
> How can I help debug this more ?
Try to get a detailed backtrace of the error. You might want to check
what the previous page (before the socket was closed) was supposed to
send (return code, size of content, headers, transfer encoding).
Also, delete the FASL files from FLEXI-STREAMS and Hunchentoot,
recompile, and check all the warnings you might get during
compilation.
Thanks,
Edi.
From quasilists at gmail.com Thu Apr 5 15:30:03 2007
From: quasilists at gmail.com (quasi)
Date: Thu, 05 Apr 2007 21:00:03 +0530
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] 0.11.1 trouble.
In-Reply-To:
References: <4614FBA4.2030309@gmail.com>
Message-ID: <461515FB.4060800@gmail.com>
Edi Weitz wrote:
> On Thu, 05 Apr 2007 19:07:40 +0530, quasi wrote:
>
>
>> I am running Hunchentoot 8.1.
>>
>
> 0.8.1 I hope... :)
>
my bad. :) it is indeed 0.8.1
>
>> As soon as I upgraded to flexi-streams 0.11.1 I have encountered a
>> weird problem. Hunchentoot (or anything else) threw no errors but
>> the socket was getting closed unexpectedly I think, because links
>> cribbed "error reading socket" or something. I am running Allegro
>> 8.0 Enterprise 64bit on Redhat Linux. (problem also persisted on
>> Allegro 8.0 for the Intel Mac's)
>>
>> As soon as I went back to 0.8.0 (my previous version) all worked as
>> before.
>>
>> Am I doing something wrong here ?
>>
>
> I doubt it. There were significant changes between 0.8.0 and 0.11.1
> and it is likely that you're the first one to use the new version on
> AllegroCL, especially on a 64-bit version (if that matters, don't
> know).
>
I dont think it matters. Observed on 32bit ACL 8.0 on the Intel Mac and
64bit ACL 8.0 on RH Linux.
> There's also a chance that some of my recent Hunchentoot changes which
> I hastily submitted in the wake of my ILC preparations broke something
> which results in sockets being closed although they shouldn't. That's
> why I'm sending a copy of this to tbnl-devel as well.
>
>
>> How can I help debug this more ?
>>
>
> Try to get a detailed backtrace of the error. You might want to check
> what the previous page (before the socket was closed) was supposed to
> send (return code, size of content, headers, transfer encoding).
>
> Also, delete the FASL files from FLEXI-STREAMS and Hunchentoot,
> recompile, and check all the warnings you might get during
> compilation.
>
Ya I tried a complete recompile. No change. Also on another machine
which had 0.9.1 and it worked. With 0.11.1 compile gave only 2 warnings.
;;; /Users/quasi/quasiLabs/lisp-libraries/flexi-streams-0.11.1/stream.lisp
; While compiling (METHOD SET-ENCODING-TABLE (T)):
Warning: Variable STREAM is never used.
; While compiling (METHOD SET-ENCODING-HASH (T)):
Warning: Variable STREAM is never used.
Problem is there are no errors thrown at all, so what do I do?
> Thanks,
> Edi.
>
>
From edi at agharta.de Thu Apr 5 16:41:16 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 05 Apr 2007 18:41:16 +0200
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] 0.11.1 trouble.
In-Reply-To: <461515FB.4060800@gmail.com> (quasi's message of "Thu, 05 Apr
2007 21:00:03 +0530")
References: <4614FBA4.2030309@gmail.com>
<461515FB.4060800@gmail.com>
Message-ID:
On Thu, 05 Apr 2007 21:00:03 +0530, quasi wrote:
> Problem is there are no errors thrown at all, so what do I do?
Did you try with *CATCH-ERRORS-P* set to NIL?
From quasilists at gmail.com Thu Apr 5 16:58:00 2007
From: quasilists at gmail.com (quasi)
Date: Thu, 05 Apr 2007 22:28:00 +0530
Subject: [hunchentoot-devel] Re: [flexi-streams-devel] 0.11.1 trouble.
In-Reply-To:
References: <4614FBA4.2030309@gmail.com>
<461515FB.4060800@gmail.com>
Message-ID: <46152A98.7090303@gmail.com>
Edi Weitz wrote:
> On Thu, 05 Apr 2007 21:00:03 +0530, quasi wrote:
>
>
>> Problem is there are no errors thrown at all, so what do I do?
>>
>
> Did you try with *CATCH-ERRORS-P* set to NIL?
>
>
OOPS. Did'nt know about that. I was dependent on the
*show-lisp-errors-p*. :( Have to find time to RTF[M|D].
Well the backtrace is here.
`NIL' is not of the expected type `REAL'
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT] Abort entirely from this (lisp) process.
Backtrace:
0: (SWANK::DEBUG-IN-EMACS #)
...
8: (INVOKE-DEBUGGER #)
9: (SIGNAL #)
10: (ERROR TYPE-ERROR :DATUM NIL :EXPECTED-TYPE REAL :FORMAT-CONTROL
"~@<`~s' is not of the expected type `~s'~:@>" :FORMAT-ARGUMENTS (NIL REAL))
11: ((METHOD TRIVIAL-GRAY-STREAMS:STREAM-WRITE-SEQUENCE
(FLEXI-STREAMS::FLEXI-LATIN-1-OUTPUT-STREAM STRING T T))
#
"Hunchentoot..." 0
NIL)
Locals:
#:STREAM = #
#:SEQUENCE919 =
"Hunchentoot..."
#:START920 = 0
#:END921 = NIL
#:AMPERSAND-ARGS = NIL
#:AMPERSAND-ARGS = NIL
#:|g919| =
"Hunchentoot...
"
#:|g921| = NIL
#:|g920| = 0
STREAM = #
#:|g922| = #(153 156 17 17 133 6 0 16 153 156 ...)
#:|g923| = 0
#:|g926| = NIL
#:|g927| = #
#:DEST-PTR925 = -268442126
#:SRC-PTR924 = #\null
#:|g932| = ((EXCL:PIPE-STREAM . :STREAMP))
#:STREAM = #
#:|g919| =
"HunchentootH..."
#:|g961| = (8192)
#:|g928| = -2
EXCL::.NEXT-METHOD. = #
#:|g929| = #
OCTET = #
NIL = #
#:|g963| = :FLEXI-STREAM-EXTERNAL-FORMAT
CHAR = #
NIL = :STREAM
NIL = #
#:|g964| = #
EXCL::.NEXT-METHODS. = (#)
From nowhere.man at levallois.eu.org Fri Apr 6 02:07:20 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 6 Apr 2007 04:07:20 +0200
Subject: [hunchentoot-devel] Re: Mercurial repositories
In-Reply-To:
References:
<7EB05352-CA54-4431-9CE3-73AE8D913992@bobobeach.com>
<20070119003232.GC16524@bateleur.arcanes.fr.eu.org>
<20070215024100.GA7532@bateleur.arcanes.fr.eu.org>
Message-ID: <20070406020720.GW27732@bateleur.arcanes.fr.eu.org>
Scribit Edi Weitz dies 15/02/2007 hora 08:27:
> Let me know once you're done with the other libs, and I'll add links
> there as well.
As you released version 0.11.2, I took the time to mirror this
dependency of Hunchentoot also. Goes from 0.1.0 to 0.11.2:
http://arcanes.fr.eu.org/~pierre/2007/02/weitz/
The last project I have the history of is TBNL. If someone wants to see
it mirrored also, I'll do it. As far as Hunchentoot is concerned,
mirroring cl-ppcre could probably interest people, I suppose.
I'm not sure I told it earlier (and I only discovered it recently), but
the three repositories there have two RSS feeds each, one for all
changesets and the other one for the tags. As I tag every version, you
can subscribe to the tags feed in your favorite RSS agregator to see
when a new version is available.
Normally, I mirror each new version in the few minutes after I read the
announcement mail from Edi (I'd like the process to be automatic,
though).
Reflectively,
Pierre
--
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From nowhere.man at levallois.eu.org Fri Apr 6 04:55:08 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 6 Apr 2007 06:55:08 +0200
Subject: [hunchentoot-devel] Re: Mercurial repositories
In-Reply-To: <20070406020720.GW27732@bateleur.arcanes.fr.eu.org>
References:
<7EB05352-CA54-4431-9CE3-73AE8D913992@bobobeach.com>
<20070119003232.GC16524@bateleur.arcanes.fr.eu.org>
<20070215024100.GA7532@bateleur.arcanes.fr.eu.org>
<20070406020720.GW27732@bateleur.arcanes.fr.eu.org>
Message-ID: <20070406045508.GA792@bateleur.arcanes.fr.eu.org>
Scribit Pierre THIERRY dies 06/04/2007 hora 04:07:
> The last project I have the history of is TBNL. If someone wants to
> see it mirrored also, I'll do it.
In fact, now that I have automated pretty much anything in the process,
it's too easy to have an excuse not to do it. So I added TBNL also. Goes
from 0.1.0 to 0.11.4...
Quickly,
Pierre
--
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From lispercat at gmail.com Fri Apr 6 13:25:52 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 6 Apr 2007 09:25:52 -0400
Subject: [hunchentoot-devel] Intermittent proble while uploading a file
Message-ID:
Since I switched to latest SBCL sometimes I got following error:
Internal Server Error
The value NIL is not of type STRING.
0: (BACKTRACE 536870911 #)
1: (HUNCHENTOOT:GET-BACKTRACE #)
2: ((LAMBDA (COND)) #)
3: ((LAMBDA (COND)) #)
4: (SIGNAL #)
5: (ERROR TYPE-ERROR)
6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
#
#.(SB-SYS:INT-SAP #XB505254C)
#
(142 14))
7: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
#
#.(SB-SYS:INT-SAP #XB505254C)
#
(142 14))
8: (SB-KERNEL:INTERNAL-ERROR
#.(SB-SYS:INT-SAP #XB505223C)
#)
9: ("foreign function: call_into_lisp")
10: ("foreign function: funcall2")
11: ("foreign function: interrupt_internal_error")
12: ("foreign function: sigtrap_handler")
13: (MAKE-STRING-INPUT-STREAM NIL 0)
14: (NIL NIL)
15: (CP-API::UPLOAD-FILE
"10f14f8c-016c-479a-9709-ce62b2027149"
#P"/tmp/upload/6E5824411F6BBA0248441CFCDF13D765-text.png"
"Customers")
16: (CP-API::SESSION-GENERATE-DESIGN)
17: (CP-API::CP-PRODUCT)
18: (HUNCHENTOOT::PROCESS-REQUEST
((:HOST . "127.0.0.1:3001")
(:ACCEPT
. "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, */*")
(:ACCEPT-ENCODING . "gzip, deflate") (:ACCEPT-LANGUAGE . "en-us")
(:COOKIE . "sessionid=52%3A6E5824411F6BBA0248441CFCDF13D765")
(:UA-CPU . "x86")
(:USER-AGENT
. "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; Media Center PC
4.0)")
(:X-FORWARDED-FOR . "192.168.1.1")
(:X-FORWARDED-HOST . "www.greenpixeldesign.com")
(:X-FORWARDED-SERVER . "www.greenpixeldesign.com")
(:CONNECTION . "close"))
#
:GET
"/cphandler/product.html"
:HTTP/1.1)
19: (HUNCHENTOOT::PROCESS-CONNECTION
#
#)
20: ((LAMBDA ()))
21: ("foreign function: call_into_lisp")
22: ("foreign function: funcall0")
23: ("foreign function: new_thread_trampoline")
24: ("foreign function: #xB7FD5B63")
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From edi at agharta.de Fri Apr 6 13:34:21 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 06 Apr 2007 15:34:21 +0200
Subject: [hunchentoot-devel] Intermittent proble while uploading a file
In-Reply-To:
(Andrei Stebakov's message of "Fri, 6 Apr 2007 09:25:52 -0400")
References:
Message-ID:
On Fri, 6 Apr 2007 09:25:52 -0400, "Andrei Stebakov" wrote:
> Since I switched to latest SBCL sometimes I got following error:
>
> Internal Server Error
>
> The value NIL is not of type STRING.
>
> 0: (BACKTRACE 536870911 #)
> 1: (HUNCHENTOOT:GET-BACKTRACE #)
> 2: ((LAMBDA (COND)) #)
> 3: ((LAMBDA (COND)) #)
> 4: (SIGNAL #)
> 5: (ERROR TYPE-ERROR)
> 6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
> #
> #.(SB-SYS:INT-SAP #XB505254C)
> # (STRUCT
>
> SB-VM::OS-CONTEXT-T-STRUCT))>
> (142 14))
> 7: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
> #
> #.(SB-SYS:INT-SAP #XB505254C)
> # (STRUCT
>
> SB-VM::OS-CONTEXT-T-STRUCT))>
> (142 14))
> 8: (SB-KERNEL:INTERNAL-ERROR
> #.(SB-SYS:INT-SAP #XB505223C)
> #)
> 9: ("foreign function: call_into_lisp")
> 10: ("foreign function: funcall2")
> 11: ("foreign function: interrupt_internal_error")
> 12: ("foreign function: sigtrap_handler")
> 13: (MAKE-STRING-INPUT-STREAM NIL 0)
> 14: (NIL NIL)
> 15: (CP-API::UPLOAD-FILE
> "10f14f8c-016c-479a-9709-ce62b2027149"
> #P"/tmp/upload/6E5824411F6BBA0248441CFCDF13D765-text.png"
> "Customers")
> 16: (CP-API::SESSION-GENERATE-DESIGN)
> 17: (CP-API::CP-PRODUCT)
> 18: (HUNCHENTOOT::PROCESS-REQUEST
> ((:HOST . "127.0.0.1:3001")
> (:ACCEPT
> . "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/x-shockwave-flash, */*")
> (:ACCEPT-ENCODING . "gzip, deflate") (:ACCEPT-LANGUAGE . "en-us")
> (:COOKIE . "sessionid=52%3A6E5824411F6BBA0248441CFCDF13D765")
> (:UA-CPU . "x86")
> (:USER-AGENT
> . "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
> 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; Media Center PC
> 4.0)")
> (:X-FORWARDED-FOR . "192.168.1.1")
> (:X-FORWARDED-HOST . "www.greenpixeldesign.com")
> (:X-FORWARDED-SERVER . "www.greenpixeldesign.com")
> (:CONNECTION . "close"))
> #
> :GET
> "/cphandler/product.html"
> :HTTP/1.1)
> 19: (HUNCHENTOOT::PROCESS-CONNECTION
> #
> #)
> 20: ((LAMBDA ()))
> 21: ("foreign function: call_into_lisp")
> 22: ("foreign function: funcall0")
> 23: ("foreign function: new_thread_trampoline")
> 24: ("foreign function: #xB7FD5B63")
Between stack frame 15 (CP-API::UPLOAD-FILE) and the top of the stack
I don't see any Hunchentoot function involved which could have caused
the error. (MAKE-STRING-INPUT-STREAM NIL 0) is certainly wrong,
though.
Regarding the "(NIL NIL)" stack frame see the SBCL mailing list a
weeks back. You should probably employ *CATCH-ERRORS-P* to diagnose
the problem.
From rm at seid-online.de Fri Apr 6 21:12:19 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Fri, 06 Apr 2007 23:12:19 +0200
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To:
References:
Message-ID: <1175893939.5720.4.camel@localhost.localdomain>
On Fri, 2007-03-30 at 22:57 +0200, Edi Weitz wrote:
> On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" wrote:
>
> > I got a folder on my linux box that contains about 240 images of font
> > preview generated from cl-gd (Thanks, Edi!).
>
> Nice... :)
>
> > When I show them from static apache handler it takes approximately 30
> > seconds. Same thing from hunchentoot static handler
> > (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand
> > it's not a big deal, but still I'd like to know what might get in the way. I
> > use hunchentoot behind mod-proxy.
> > Here are links (first is static apache, second is hunchentoot):
> > http://www.greenpixeldesign.com/fonts.html
> > http://www.greenpixeldesign.com/cphandler/fonts.html
>
> I guess it's the thread switching that takes the additional time.
> >From tests on my Linux box (using ApacheBench and a localhost
> connection) my impression was that serving static files with
> Hunchentoot wasn't slower than with Apache.
Just as a side note: unless we talk about low traffic/low volume serving
i'd expect Apache to be significantly faster than Lisp solutions - once
Apache detects that a request serves static files it uses 'sendfile' to
shuffle the file content over the network (thus avoiding to read any
data at all into userspace only to write it back to kernel space. That
does save a lot of time (and context switches)).
That's nothing to be ashamed of as a Lisper - Lisp shines when it comes
to content generation ;-)
Cheers, Ralf Mattes
From lispercat at gmail.com Fri Apr 6 23:45:20 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Fri, 6 Apr 2007 19:45:20 -0400
Subject: [hunchentoot-devel] Different speed loading images from static
apache and hunchentoot handler
In-Reply-To: <1175893939.5720.4.camel@localhost.localdomain>
References:
<1175893939.5720.4.camel@localhost.localdomain>
Message-ID:
Ralf, it was a different issue specific to CMUCL. Performance was just
horrible, but it was fixed by calling (mp::startup-idle-and-top-level-loops).
SBCL works fine out of the box (there are other issues but not the speed).
Andrew
On 4/6/07, Ralf Mattes wrote:
>
> On Fri, 2007-03-30 at 22:57 +0200, Edi Weitz wrote:
> > On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" <
> lispercat at gmail.com> wrote:
> >
> > > I got a folder on my linux box that contains about 240 images of font
> > > preview generated from cl-gd (Thanks, Edi!).
> >
> > Nice... :)
> >
> > > When I show them from static apache handler it takes approximately 30
> > > seconds. Same thing from hunchentoot static handler
> > > (create-folder-dispatcher-and-handler) takes about 50 seconds. I
> understand
> > > it's not a big deal, but still I'd like to know what might get in the
> way. I
> > > use hunchentoot behind mod-proxy.
> > > Here are links (first is static apache, second is hunchentoot):
> > > http://www.greenpixeldesign.com/fonts.html
> > > http://www.greenpixeldesign.com/cphandler/fonts.html
> >
> > I guess it's the thread switching that takes the additional time.
> > >From tests on my Linux box (using ApacheBench and a localhost
> > connection) my impression was that serving static files with
> > Hunchentoot wasn't slower than with Apache.
>
> Just as a side note: unless we talk about low traffic/low volume serving
> i'd expect Apache to be significantly faster than Lisp solutions - once
> Apache detects that a request serves static files it uses 'sendfile' to
> shuffle the file content over the network (thus avoiding to read any
> data at all into userspace only to write it back to kernel space. That
> does save a lot of time (and context switches)).
> That's nothing to be ashamed of as a Lisper - Lisp shines when it comes
> to content generation ;-)
>
> Cheers, Ralf Mattes
>
> _______________________________________________
> 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:
From edi at agharta.de Sat Apr 7 21:19:22 2007
From: edi at agharta.de (Edi Weitz)
Date: Sat, 07 Apr 2007 23:19:22 +0200
Subject: [hunchentoot-devel] New release 0.8.2
Message-ID:
ChangeLog:
Version 0.8.2
2007-04-05
Really exported REASON-PHRASE this time (and also *CURRENT-PROCESS*)
Download:
http://weitz.de/files/hunchentoot.tar.gz
Yes, the date in the ChangeLog is correct, I couldn't upload the code
because I couldn't reach my server that day.
From edi at agharta.de Sat Apr 7 21:57:02 2007
From: edi at agharta.de (Edi Weitz)
Date: Sat, 07 Apr 2007 23:57:02 +0200
Subject: [hunchentoot-devel] New release 0.8.3
Message-ID:
Sorry...
ChangeLog:
Version 0.8.3
2007-04-07
Don't use chunked encoding for empty (NIL) bodies
Download:
http://weitz.de/files/hunchentoot.tar.gz
Cheers,
Edi.
From lispercat at gmail.com Sun Apr 8 15:13:27 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 8 Apr 2007 11:13:27 -0400
Subject: [hunchentoot-devel] Processing an error outside the Hunchentoot code
Message-ID:
What's the best to add my own error handler? I see there is some processing
based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside
process-request function, but it doesn't allow to add a user handler of the
error (or I just didn't find it). Let's say I don't want a user to see the
error (only some nice reassuring message :)) and I want to be notified by an
email with the backtrace. Should I go and modify the body of the
process-request function (which I'll need to merge with every new release of
HT) or is there a way to add my own handler outside of the Hunchentoot code?
Thank you,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yoni-r at actcom.com Sun Apr 8 16:17:53 2007
From: yoni-r at actcom.com (Yoni Rabkin Katzenell)
Date: Sun, 08 Apr 2007 19:17:53 +0300
Subject: [hunchentoot-devel] Processing an error outside the Hunchentoot
code
In-Reply-To:
(Andrei Stebakov's message of "Sun, 8 Apr 2007 11:13:27 -0400")
References:
Message-ID: <87zm5i2632.fsf@actcom.com>
"Andrei Stebakov" writes:
> What's the best to add my own error handler? I see there is some processing
> based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside
> process-request function, but it doesn't allow to add a user handler of the
> error (or I just didn't find it). Let's say I don't want a user to see the
> error (only some nice reassuring message :)) and I want to be notified by an
> email with the backtrace. Should I go and modify the body of the
> process-request function (which I'll need to merge with every new release of
> HT) or is there a way to add my own handler outside of the Hunchentoot code?
I've generally found it enough to define error handlers just like I
usually do in CL:
(defun foo ()
"Display the foo page"
(handler-case
(... faulty code which might produce some error ...)
(error () (display-a-nice-error-message))))
--
"Cut your own wood and it will warm you twice"
From lispercat at gmail.com Sun Apr 8 16:29:53 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 8 Apr 2007 12:29:53 -0400
Subject: [hunchentoot-devel] Processing an error outside the Hunchentoot
code
In-Reply-To: <87zm5i2632.fsf@actcom.com>
References:
<87zm5i2632.fsf@actcom.com>
Message-ID:
Right, but I'd like to have a handler if something wrong goes in request
processing, when the user sees the backtrace on the screen.
Andrew
On 4/8/07, Yoni Rabkin Katzenell wrote:
>
> "Andrei Stebakov" writes:
>
> > What's the best to add my own error handler? I see there is some
> processing
> > based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside
> > process-request function, but it doesn't allow to add a user handler of
> the
> > error (or I just didn't find it). Let's say I don't want a user to see
> the
> > error (only some nice reassuring message :)) and I want to be notified
> by an
> > email with the backtrace. Should I go and modify the body of the
> > process-request function (which I'll need to merge with every new
> release of
> > HT) or is there a way to add my own handler outside of the Hunchentoot
> code?
>
> I've generally found it enough to define error handlers just like I
> usually do in CL:
>
> (defun foo ()
> "Display the foo page"
> (handler-case
> (... faulty code which might produce some error ...)
> (error () (display-a-nice-error-message))))
>
> --
> "Cut your own wood and it will warm you twice"
> _______________________________________________
> 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:
From lispercat at gmail.com Sun Apr 8 16:48:59 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 8 Apr 2007 12:48:59 -0400
Subject: [hunchentoot-devel] Processing an error outside the Hunchentoot
code
In-Reply-To:
References:
<87zm5i2632.fsf@actcom.com>
Message-ID:
Oh, I got it, so every hunchentoot handler should have its own error handlng
procedure. I wonder if it's going to interfere with the internals of
process-request
function when it does the logging and other stuff? Still it would be nice to
have one hook handler for all of my request handlers so I don't have to
write the handler-case block for all of them. Also from my own code how do I
use the get-backtrace function?
Thank you,
Andrew**
On 4/8/07, Andrei Stebakov wrote:
>
> Right, but I'd like to have a handler if something wrong goes in request
> processing, when the user sees the backtrace on the screen.
>
> Andrew
>
> On 4/8/07, Yoni Rabkin Katzenell wrote:
> >
> > "Andrei Stebakov" writes:
> >
> > > What's the best to add my own error handler? I see there is some
> > processing
> > > based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside
> > > process-request function, but it doesn't allow to add a user handler
> > of the
> > > error (or I just didn't find it). Let's say I don't want a user to see
> > the
> > > error (only some nice reassuring message :)) and I want to be notified
> > by an
> > > email with the backtrace. Should I go and modify the body of the
> > > process-request function (which I'll need to merge with every new
> > release of
> > > HT) or is there a way to add my own handler outside of the Hunchentoot
> > code?
> >
> > I've generally found it enough to define error handlers just like I
> > usually do in CL:
> >
> > (defun foo ()
> > "Display the foo page"
> > (handler-case
> > (... faulty code which might produce some error ...)
> > (error () (display-a-nice-error-message))))
> >
> > --
> > "Cut your own wood and it will warm you twice"
> > _______________________________________________
> > 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:
From edi at agharta.de Sun Apr 8 19:42:17 2007
From: edi at agharta.de (Edi Weitz)
Date: Sun, 08 Apr 2007 21:42:17 +0200
Subject: [hunchentoot-devel] Processing an error outside the Hunchentoot
code
In-Reply-To:
(Andrei Stebakov's message of "Sun, 8 Apr 2007 11:13:27 -0400")
References:
Message-ID:
On Sun, 8 Apr 2007 11:13:27 -0400, "Andrei Stebakov" wrote:
> What's the best to add my own error handler? I see there is some
> processing based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P*
> inside process-request function, but it doesn't allow to add a user
> handler of the error (or I just didn't find it). Let's say I don't
> want a user to see the error (only some nice reassuring message :))
> and I want to be notified by an email with the backtrace. Should I
> go and modify the body of the process-request function (which I'll
> need to merge with every new release of HT) or is there a way to add
> my own handler outside of the Hunchentoot code?
If you just don't want to show Hunchentoot's error messages, you can
use this one
http://weitz.de/hunchentoot/#*http-error-handler*
and the related variables.
If you want complete control, write an around method for
DISPATCH-REQUEST
http://weitz.de/hunchentoot/#dispatch-request
like for example this one:
CL-USER 3 > (defun inversion-handler ()
(format nil "Result: ~A"
(/ 1 (ignore-errors
(parse-integer
(tbnl:parameter "input"))))))
INVERSION-HANDLER
CL-USER 4 > (compile *)
INVERSION-HANDLER
NIL
NIL
CL-USER 5 > (setq tbnl:*default-handler* **)
INVERSION-HANDLER
CL-USER 6 > (defmethod tbnl:dispatch-request :around (dispatch-table)
(handler-case
(call-next-method)
(arithmetic-error ()
"Oops, I can't compute that...")))
#
CL-USER 7 > (tbnl:start-server :port 4242)
#
Etc.
Cheers,
Edi.
From edi at agharta.de Mon Apr 9 00:27:47 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 09 Apr 2007 02:27:47 +0200
Subject: [hunchentoot-devel] New release 0.8.4
Message-ID:
No technical changes. This release just fixes some version numbers I
botched yesterday.
Sorry,
Edi.
From victor.kryukov at gmail.com Mon Apr 9 18:05:57 2007
From: victor.kryukov at gmail.com (Victor Kryukov)
Date: Mon, 9 Apr 2007 13:05:57 -0500
Subject: [hunchentoot-devel] New release 0.8.4
In-Reply-To:
References:
Message-ID:
Dear Edi:
What upgrade strategy do you recommend in following Hunchentoot
updates? E.g. should I update every time your announce a fix, only
when major version number changes, etc. (that also depends on my
paranoia, I know :).
The reason I'm asking that is because, to the best of my knowledge,
there is no 'update' feature in asdf-install - as an lazy Ubuntu user,
I'm too used to 'apt-get update'. My understanding is that updating
asdf packages (eps. when some dependecies have also changed) is a
complicated procedure - that's why it's better to perform it only for
'critical' things.
What is your perspective on that?
Bets regards,
Victor.
On 4/8/07, Edi Weitz wrote:
> No technical changes. This release just fixes some version numbers I
> botched yesterday.
>
> Sorry,
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
From xach at xach.com Mon Apr 9 18:15:27 2007
From: xach at xach.com (Zach Beane)
Date: Mon, 9 Apr 2007 14:15:27 -0400
Subject: [hunchentoot-devel] New release 0.8.4
In-Reply-To:
References:
Message-ID: <20070409181527.GT7908@xach.com>
On Mon, Apr 09, 2007 at 01:05:57PM -0500, Victor Kryukov wrote:
> Dear Edi:
>
> What upgrade strategy do you recommend in following Hunchentoot
> updates? E.g. should I update every time your announce a fix, only
> when major version number changes, etc. (that also depends on my
> paranoia, I know :).
>
> The reason I'm asking that is because, to the best of my knowledge,
> there is no 'update' feature in asdf-install - as an lazy Ubuntu user,
> I'm too used to 'apt-get update'. My understanding is that updating
> asdf packages (eps. when some dependecies have also changed) is a
> complicated procedure - that's why it's better to perform it only for
> 'critical' things.
>
> What is your perspective on that?
In my experience, upgrading is not a big deal. If your site works
fine, there's not really a compelling reason to upgrade. (I still have
some sites running tbnl-0.3, from early 2005). If you have problems,
upgrading to the latest version is not generally a difficult
process. The fear of upgrading can be a bigger obstacle than actually
upgrading.
Zach
From austin at pettomato.com Mon Apr 9 18:54:56 2007
From: austin at pettomato.com (Austin Haas)
Date: Mon, 9 Apr 2007 14:54:56 -0400
Subject: [hunchentoot-devel] New release 0.8.4
In-Reply-To:
References:
Message-ID: <20070409185456.GA4854@bean.chicago>
Is it really complicated? My understanding was that you can just asdf-install again, and it will install the new version of Hunchentoot and update the symlink to the .asd file. Then, you can just delete the old version. I don't know anything about dependencies, though, or if it works the same way on setups other than SBCL on Gentoo.
-austin
--
Austin Haas
Pet Tomato, Inc.
http://pettomato.com
On Mon Apr 09 13:05 , Victor Kryukov wrote:
> Dear Edi:
>
> What upgrade strategy do you recommend in following Hunchentoot
> updates? E.g. should I update every time your announce a fix, only
> when major version number changes, etc. (that also depends on my
> paranoia, I know :).
>
> The reason I'm asking that is because, to the best of my knowledge,
> there is no 'update' feature in asdf-install - as an lazy Ubuntu user,
> I'm too used to 'apt-get update'. My understanding is that updating
> asdf packages (eps. when some dependecies have also changed) is a
> complicated procedure - that's why it's better to perform it only for
> 'critical' things.
>
> What is your perspective on that?
>
> Bets regards,
> Victor.
>
> On 4/8/07, Edi Weitz wrote:
> >No technical changes. This release just fixes some version numbers I
> >botched yesterday.
> >
> >Sorry,
> >Edi.
> >_______________________________________________
> >tbnl-devel site list
> >tbnl-devel at common-lisp.net
> >http://common-lisp.net/mailman/listinfo/tbnl-devel
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
From edi at agharta.de Mon Apr 9 18:56:37 2007
From: edi at agharta.de (Edi Weitz)
Date: Mon, 09 Apr 2007 20:56:37 +0200
Subject: [hunchentoot-devel] New release 0.8.4
In-Reply-To: <20070409181527.GT7908@xach.com> (Zach Beane's message of "Mon,
9 Apr 2007 14:15:27 -0400")
References:
<20070409181527.GT7908@xach.com>
Message-ID:
On Mon, 9 Apr 2007 14:15:27 -0400, Zach Beane wrote:
> In my experience, upgrading is not a big deal. If your site works
> fine, there's not really a compelling reason to upgrade. (I still
> have some sites running tbnl-0.3, from early 2005). If you have
> problems, upgrading to the latest version is not generally a
> difficult process. The fear of upgrading can be a bigger obstacle
> than actually upgrading.
What Zach says.
FWIW, I /try/ to adhere to the following policy:
- Every functional change is mentioned in the ChangeLog file,
"cosmetic" changes and otherwise irrelevant re-organizations
sometimes aren't.
- For Bugfixes and "small" changes, only the patch version number is
released (for example from 0.8.3 to 0.8.4), for new functionality or
bigger changes the minor version is bumped (for example from 0.7.3
to 0.8.0). The major version number will only be increased once I'm
confident that the library is fairly stable - expect this to take
more time.
- I try to be backwards-compatible if possible. Incompatible changes
will be explicitly announced.
HTH,
Edi.
From nowhere.man at levallois.eu.org Mon Apr 9 19:18:36 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Mon, 9 Apr 2007 21:18:36 +0200
Subject: [hunchentoot-devel] New release 0.8.4
In-Reply-To:
References:
Message-ID: <20070409191836.GF17670@bateleur.arcanes.fr.eu.org>
Scribit Victor Kryukov dies 09/04/2007 hora 13:05:
> The reason I'm asking that is because, to the best of my knowledge,
> there is no 'update' feature in asdf-install - as an lazy Ubuntu user,
> I'm too used to 'apt-get update'.
Hunchentoot has made its way into Debian recently, I suppose it should
appear in the universe section also.
Natively,
Pierre
--
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From luismbo at gmail.com Mon Apr 9 22:21:14 2007
From: luismbo at gmail.com (Luis Oliveira)
Date: Mon, 09 Apr 2007 23:21:14 +0100
Subject: [hunchentoot-devel] New release 0.8.4
References:
Message-ID:
"Victor Kryukov" writes:
> The reason I'm asking that is because, to the best of my knowledge,
> there is no 'update' feature in asdf-install - as an lazy Ubuntu user,
> I'm too used to 'apt-get update'.
I can relate to that, and that's one of the reasons why I wrote
"ediware"[1]. I just "darcs pull" new patches in the hunchentoot tree
and ASDF picks the changes up, recompiling the necessary bits.
[1] http://common-lisp.net/~loliveira/ediware/
--
Lu?s Oliveira
http://student.dei.uc.pt/~lmoliv/
From edi at agharta.de Mon Apr 9 23:19:48 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Apr 2007 01:19:48 +0200
Subject: [hunchentoot-devel] New release 0.8.5
Message-ID:
ChangeLog:
Version 0.8.5
2007-04-10
Correct behaviour for "100 Continue" responses
Download:
http://weitz.de/files/hunchentoot.tar.gz
Cheers,
Edi.
From lispercat at gmail.com Tue Apr 10 13:54:39 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 10 Apr 2007 09:54:39 -0400
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
Message-ID:
When I use the *http-error-handler* it works fine on Firefox displaying my
message and doing some extra job. On IE it says "Can not display page" and
shows the HTTP 500 code. I guess I need to filter out the http status code
500 and replace it for status ok somewhere.
How can I replace the status code or fix the page in IE?
BTW, when I use (redirect) inside of some of my handlers call I also get to
the *http-error-handler*. I guess the proper thing to do is to add
+http-moved-temporarily+ into the *approved-return-codes*.
Thank you,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From edi at agharta.de Tue Apr 10 14:15:10 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Apr 2007 16:15:10 +0200
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
In-Reply-To:
(Andrei Stebakov's message of "Tue, 10 Apr 2007 09:54:39 -0400")
References:
Message-ID:
On Tue, 10 Apr 2007 09:54:39 -0400, "Andrei Stebakov" wrote:
> When I use the *http-error-handler* it works fine on Firefox
> displaying my message and doing some extra job. On IE it says "Can
> not display page" and shows the HTTP 500 code.
Yes, that seems to be a deliberate design decision of Microsoft.
> I guess I need to filter out the http status code 500 and replace it
> for status ok somewhere. How can I replace the status code or fix
> the page in IE?
http://weitz.de/hunchentoot/#return-code
> BTW, when I use (redirect) inside of some of my handlers call I also get to
> the *http-error-handler*. I guess the proper thing to do is to add
> +http-moved-temporarily+ into the *approved-return-codes*.
As long as you don't change the return code and the "Location" header
it shouldn't matter.
From lispercat at gmail.com Tue Apr 10 14:36:22 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Tue, 10 Apr 2007 10:36:22 -0400
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
In-Reply-To:
References:
Message-ID:
(setf (return-code) +http-ok+) doesn't have any effect on IE 7.0 when I do
it inside my *http-error-handler*.
Is it possible to extract a *session* or *reply* from the user defined
*http-error-handler*?
Andrew
On 4/10/07, Edi Weitz wrote:
>
> On Tue, 10 Apr 2007 09:54:39 -0400, "Andrei Stebakov"
> wrote:
>
> > When I use the *http-error-handler* it works fine on Firefox
> > displaying my message and doing some extra job. On IE it says "Can
> > not display page" and shows the HTTP 500 code.
>
> Yes, that seems to be a deliberate design decision of Microsoft.
>
> > I guess I need to filter out the http status code 500 and replace it
> > for status ok somewhere. How can I replace the status code or fix
> > the page in IE?
>
> http://weitz.de/hunchentoot/#return-code
>
> > BTW, when I use (redirect) inside of some of my handlers call I also get
> to
> > the *http-error-handler*. I guess the proper thing to do is to add
> > +http-moved-temporarily+ into the *approved-return-codes*.
>
> As long as you don't change the return code and the "Location" header
> it shouldn't matter.
> _______________________________________________
> 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:
From edi at agharta.de Tue Apr 10 14:57:18 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Apr 2007 16:57:18 +0200
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
In-Reply-To:
(Andrei Stebakov's message of "Tue, 10 Apr 2007 10:36:22 -0400")
References:
Message-ID:
On Tue, 10 Apr 2007 10:36:22 -0400, "Andrei Stebakov" wrote:
> (setf (return-code) +http-ok+) doesn't have any effect on IE 7.0
> when I do it inside my *http-error-handler*.
Yes, you're right, I confused myself. The code in headers.lisp
already has the return code in a local variable and doesn't update it
after the error handler returns. The original intent (code by Stefan
Scholl IIRC) obviously was that it should work a bit like Apache's
ErrorDocument directive. And I agree that it generally is a bad idea
to change the return code in an error handler (see for example Apache
documentation for "ErrorDocument").
> Is it possible to extract a *session* or *reply* from the user
> defined *http-error-handler*?
Yes.
http://weitz.de/hunchentoot/#*http-error-handler*
From edi at agharta.de Tue Apr 10 15:00:20 2007
From: edi at agharta.de (Edi Weitz)
Date: Tue, 10 Apr 2007 17:00:20 +0200
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
In-Reply-To:
(Andrei Stebakov's message of "Tue, 10 Apr 2007 09:54:39 -0400")
References:
Message-ID:
On Tue, 10 Apr 2007 09:54:39 -0400, "Andrei Stebakov" wrote:
> When I use the *http-error-handler* it works fine on Firefox
> displaying my message and doing some extra job. On IE it says "Can
> not display page" and shows the HTTP 500 code. I guess I need to
> filter out the http status code 500 and replace it for status ok
> somewhere.
There's a better way to deal with this:
Microsoft Internet Explorer (MSIE) will by default ignore
server-generated error messages when they are "too small" and
substitute its own "friendly" error messages. The size threshold
varies depending on the type of error, but in general, if you make
your error document greater than 512 bytes, then MSIE will show
the server-generated error rather than masking it.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807
http://httpd.apache.org/docs/2.2/mod/core.html#errordocument
From rm at seid-online.de Tue Apr 10 15:11:21 2007
From: rm at seid-online.de (Ralf Mattes)
Date: Tue, 10 Apr 2007 17:11:21 +0200
Subject: [hunchentoot-devel] *http-error-handler* on IE 7.0 (http code 500)
In-Reply-To:
References:
Message-ID: <1176217881.9972.22.camel@localhost.localdomain>
On Tue, 2007-04-10 at 17:00 +0200, Edi Weitz wrote:
> On Tue, 10 Apr 2007 09:54:39 -0400, "Andrei Stebakov" wrote:
>
> > When I use the *http-error-handler* it works fine on Firefox
> > displaying my message and doing some extra job. On IE it says "Can
> > not display page" and shows the HTTP 500 code. I guess I need to
> > filter out the http status code 500 and replace it for status ok
> > somewhere.
>
> There's a better way to deal with this:
>
> Microsoft Internet Explorer (MSIE) will by default ignore
> server-generated error messages when they are "too small" and
> substitute its own "friendly" error messages. The size threshold
> varies depending on the type of error, but in general, if you make
> your error document greater than 512 bytes, then MSIE will show
> the server-generated error rather than masking it.
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807
> http://httpd.apache.org/docs/2.2/mod/core.html#errordocument
Thank's Edi!
You saved my day - it's always healthy to have a good laugh :-)
The sad thing: this is real ...
Cheers RalfD
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
From lispercat at gmail.com Thu Apr 12 17:26:19 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 13:26:19 -0400
Subject: [hunchentoot-devel] Running multiple web application
Message-ID:
I just wanted to consult what's the best strategy for using multiple
hunchentoot applications. Is it better to use one *dispatch-table* and
insert multiple handlers for different application in this table or have
many servers listening on different ports? I'd like to go with multiple
hunchentoot:start-server, does it have any disadvantages?
Thank you,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From emailmac at gmail.com Thu Apr 12 17:34:55 2007
From: emailmac at gmail.com (Mac Chan)
Date: Thu, 12 Apr 2007 10:34:55 -0700
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
Message-ID: <4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
I am not sure if there are advantages with multiple hunchentoot:start-server.
However, multi-core CPUs are so common these days you might want to
start two lisp images with each running a separate web application.
Most lisps support threading but cannot take advantage of multiple
cores in one image.
Correct me if I'm wrong.
Regards,
-- Mac
On 4/12/07, Andrei Stebakov wrote:
> I just wanted to consult what's the best strategy for using multiple
> hunchentoot applications. Is it better to use one *dispatch-table* and
> insert multiple handlers for different application in this table or have
> many servers listening on different ports? I'd like to go with multiple
> hunchentoot:start-server, does it have any disadvantages?
>
> Thank you,
> Andrew
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
From lispercat at gmail.com Thu Apr 12 17:47:17 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 13:47:17 -0400
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To: <4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
My Web PC is really modest, PIII 600 MHz so it probably won't benefit from
running multiple images. Basically, my question is if starting multiple
hunchentoot server is a good idea here. I need some logical separations for
different web applications so I am wondering what's the best way to achieve
it.
Andrew
On 4/12/07, Mac Chan wrote:
>
> I am not sure if there are advantages with multiple
> hunchentoot:start-server.
> However, multi-core CPUs are so common these days you might want to
> start two lisp images with each running a separate web application.
>
> Most lisps support threading but cannot take advantage of multiple
> cores in one image.
>
> Correct me if I'm wrong.
>
> Regards,
> -- Mac
>
> On 4/12/07, Andrei Stebakov wrote:
> > I just wanted to consult what's the best strategy for using multiple
> > hunchentoot applications. Is it better to use one *dispatch-table* and
> > insert multiple handlers for different application in this table or have
> > many servers listening on different ports? I'd like to go with multiple
> > hunchentoot:start-server, does it have any disadvantages?
> >
> > Thank you,
> > Andrew
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From edi at agharta.de Thu Apr 12 18:17:10 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 12 Apr 2007 20:17:10 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
(Andrei Stebakov's message of "Thu, 12 Apr 2007 13:47:17 -0400")
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
On Thu, 12 Apr 2007 13:47:17 -0400, "Andrei Stebakov" wrote:
> Basically, my question is if starting multiple hunchentoot server is
> a good idea here. I need some logical separations for different web
> applications so I am wondering what's the best way to achieve it.
If the two servers are doing more or less different things, I'd say
it's better to have them in different Lisp images. That's certainly
easier to maintain. I would only be tempted to run mutiple servers in
one image if they shared a lot of code and/or data.
From edi at agharta.de Thu Apr 12 18:19:20 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 12 Apr 2007 20:19:20 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To: <4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com> (Mac
Chan's message of "Thu, 12 Apr 2007 10:34:55 -0700")
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
On Thu, 12 Apr 2007 10:34:55 -0700, "Mac Chan" wrote:
> Most lisps support threading but cannot take advantage of multiple
> cores in one image.
>
> Correct me if I'm wrong.
I think you're right. AFAIK the current exceptions are Scieneer,
Corman, OpenMCL, and (on some platforms) SBCL.
From lispercat at gmail.com Thu Apr 12 19:45:39 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 15:45:39 -0400
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
In my case if I run multiple images it would be harder to maintain it
because each image would use the swank, almost the same set of libraries and
I'd have to think how to connect to each image via slime using different
port. To me it's a bit complicated.
On the other hand, if running multiple hunchentoot servers is OK in one
image I would keep separate *dispatch-table* per each server and it would
make a perfect logical separation for different apps. Do you think it's a
reasonable approach?
Andrew
On 4/12/07, Edi Weitz wrote:
>
> On Thu, 12 Apr 2007 10:34:55 -0700, "Mac Chan" wrote:
>
> > Most lisps support threading but cannot take advantage of multiple
> > cores in one image.
> >
> > Correct me if I'm wrong.
>
> I think you're right. AFAIK the current exceptions are Scieneer,
> Corman, OpenMCL, and (on some platforms) SBCL.
> _______________________________________________
> 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:
From edi at agharta.de Thu Apr 12 19:55:19 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 12 Apr 2007 21:55:19 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
(Andrei Stebakov's message of "Thu, 12 Apr 2007 15:45:39 -0400")
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
On Thu, 12 Apr 2007 15:45:39 -0400, "Andrei Stebakov" wrote:
> On the other hand, if running multiple hunchentoot servers is OK in
> one image I would keep separate *dispatch-table* per each server and
> it would make a perfect logical separation for different apps. Do
> you think it's a reasonable approach?
Yes, you'd use *META-DISPATCHER* then. Note that there are some parts
of Hunchentoot (for example logging and error handling) that are
currently controlled by global variables which should actually be
per-server switches. You'll find some discussions related to this in
the mailing list archive. This is a remnant of Hunchentoot's heritage
from a single-server library (TBNL). Several users have announced to
send patches to fix this but haven't sent anything yet. I'll probably
clean this up one day, but it's not a big issue for me as I virtually
never use multiple servers in one image.
From lispercat at gmail.com Thu Apr 12 20:13:20 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 16:13:20 -0400
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
So I need to keep track of all servers that I start and for each one return
it's dispatch-table something like this?:
(defvar *server1* (start-server :port 3001....)
(defvar *server2* (start-server :port 3002....)
(setq *meta-dispatcher* (lambda (server)
(declare (ignore server))
(if (eql server *server1*) *dispatch-table1*
*dispatch-table2*)))
Why can't start-server take a dispatch-table as a parameter?
Andrew
On 4/12/07, Edi Weitz wrote:
>
> On Thu, 12 Apr 2007 15:45:39 -0400, "Andrei Stebakov"
> wrote:
>
> > On the other hand, if running multiple hunchentoot servers is OK in
> > one image I would keep separate *dispatch-table* per each server and
> > it would make a perfect logical separation for different apps. Do
> > you think it's a reasonable approach?
>
> Yes, you'd use *META-DISPATCHER* then. Note that there are some parts
> of Hunchentoot (for example logging and error handling) that are
> currently controlled by global variables which should actually be
> per-server switches. You'll find some discussions related to this in
> the mailing list archive. This is a remnant of Hunchentoot's heritage
> from a single-server library (TBNL). Several users have announced to
> send patches to fix this but haven't sent anything yet. I'll probably
> clean this up one day, but it's not a big issue for me as I virtually
> never use multiple servers in one image.
> _______________________________________________
> 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:
From yoni-r at actcom.com Thu Apr 12 20:33:12 2007
From: yoni-r at actcom.com (Yoni Rabkin Katzenell)
Date: Thu, 12 Apr 2007 23:33:12 +0300
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
(Andrei Stebakov's message of "Thu, 12 Apr 2007 13:26:19 -0400")
References:
Message-ID: <87hcrl9vuf.fsf@actcom.com>
I've been using up to several separate Hunchentoot images per server
with no problems. I usually run them with a script (without swank) and
gnu screen.
The only thing I have ever had issues with is being careless with RAM,
but that was my application's fault entirely.
--
"Cut your own wood and it will warm you twice"
From edi at agharta.de Thu Apr 12 21:59:16 2007
From: edi at agharta.de (Edi Weitz)
Date: Thu, 12 Apr 2007 23:59:16 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
(Andrei Stebakov's message of "Thu, 12 Apr 2007 16:13:20 -0400")
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
On Thu, 12 Apr 2007 16:13:20 -0400, "Andrei Stebakov" wrote:
> So I need to keep track of all servers that I start and for each one
> return it's dispatch-table something like this?:
> (defvar *server1* (start-server :port 3001....)
> (defvar *server2* (start-server :port 3002....)
> (setq *meta-dispatcher* (lambda (server)
> (declare (ignore server))
> (if (eql server *server1*) *dispatch-table1* *dispatch-table2*)))
No, you don't have to do it like this. There are certainly more
intelligent ways to do it. I'd use something like
(lambda (server)
(case (server-local-port server)
(3001 *dispatch-table1*)
(3002 *dispatch-table2*)))
> Why can't start-server take a dispatch-table as a parameter?
Did you read my last reply?
If there's a feature in an open source project you want to have that's
not provided, you can hack it yourself and send a patch, or you can
pay someone else to do it, or you can complain about it on the mailing
list. You can try to figure out yourself which of these alternatives
is the most promising.
From lispercat at gmail.com Thu Apr 12 22:17:42 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 18:17:42 -0400
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID:
I am sorry I gave an impression that I was complaining. I just thought it
was logical to do so if every server has its own dispatch-table. There is
probably a reason why it's done differently so I wanted to understand why.
I am sure, if I come up with something useful I'll make a patch and send it
to the list. Currently I am just a beginner trying to learn lisp and you
guys are awesome in what you do for the community and for me personally.
Thank you,
Andrew
On 4/12/07, Edi Weitz wrote:
>
> On Thu, 12 Apr 2007 16:13:20 -0400, "Andrei Stebakov"
> wrote:
>
> > So I need to keep track of all servers that I start and for each one
> > return it's dispatch-table something like this?:
> > (defvar *server1* (start-server :port 3001....)
> > (defvar *server2* (start-server :port 3002....)
> > (setq *meta-dispatcher* (lambda (server)
> > (declare (ignore server))
> > (if (eql server *server1*) *dispatch-table1*
> *dispatch-table2*)))
>
> No, you don't have to do it like this. There are certainly more
> intelligent ways to do it. I'd use something like
>
> (lambda (server)
> (case (server-local-port server)
> (3001 *dispatch-table1*)
> (3002 *dispatch-table2*)))
>
> > Why can't start-server take a dispatch-table as a parameter?
>
> Did you read my last reply?
>
> If there's a feature in an open source project you want to have that's
> not provided, you can hack it yourself and send a patch, or you can
> pay someone else to do it, or you can complain about it on the mailing
> list. You can try to figure out yourself which of these alternatives
> is the most promising.
> _______________________________________________
> 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:
From rsynnott at gmail.com Fri Apr 13 01:47:24 2007
From: rsynnott at gmail.com (Robert Synnott)
Date: Fri, 13 Apr 2007 02:47:24 +0100
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID: <24f203480704121847j16a3a1d3m8e70c45df064c516@mail.gmail.com>
On 4/12/07, Andrei Stebakov wrote:
> So I need to keep track of all servers that I start and for each one return
> it's dispatch-table something like this?:
> (defvar *server1* (start-server :port 3001....)
> (defvar *server2* (start-server :port 3002....)
> (setq *meta-dispatcher* (lambda (server)
> (declare (ignore server))
> (if (eql server *server1*) *dispatch-table1*
> *dispatch-table2*)))
>
This is more or less exactly the approach I've been taking. The
advantage, of course, is largely in memory usage, the disadvantage is
in the trouble involved in keeping track of it all. You can, if you
like, put different sites in different packages, then just do
site1:*dispatch-table*, site2:*dispatch-table* etc. in the above, the
advantage being that you can then easily develop and test each site in
its own package.
Rob
From lispercat at gmail.com Fri Apr 13 02:20:34 2007
From: lispercat at gmail.com (Andrei Stebakov)
Date: Thu, 12 Apr 2007 22:20:34 -0400
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To: <24f203480704121847j16a3a1d3m8e70c45df064c516@mail.gmail.com>
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
<24f203480704121847j16a3a1d3m8e70c45df064c516@mail.gmail.com>
Message-ID:
Yes, Robert, this is exactly the way I am going now. So far looks good and
doesn't seem to promise any maintenance problems.
Thank you,
Andrew
On 4/12/07, Robert Synnott wrote:
>
> On 4/12/07, Andrei Stebakov wrote:
> > So I need to keep track of all servers that I start and for each one
> return
> > it's dispatch-table something like this?:
> > (defvar *server1* (start-server :port 3001....)
> > (defvar *server2* (start-server :port 3002....)
> > (setq *meta-dispatcher* (lambda (server)
> > (declare (ignore server))
> > (if (eql server *server1*) *dispatch-table1*
> > *dispatch-table2*)))
> >
>
> This is more or less exactly the approach I've been taking. The
> advantage, of course, is largely in memory usage, the disadvantage is
> in the trouble involved in keeping track of it all. You can, if you
> like, put different sites in different packages, then just do
> site1:*dispatch-table*, site2:*dispatch-table* etc. in the above, the
> advantage being that you can then easily develop and test each site in
> its own package.
> Rob
> _______________________________________________
> 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:
From reddaly at gmail.com Fri Apr 13 09:13:11 2007
From: reddaly at gmail.com (red daly)
Date: Fri, 13 Apr 2007 02:13:11 -0700
Subject: [hunchentoot-devel] I/O timeout error (SBCL)
Message-ID: <461F49A7.80200@gmail.com>
This is a repeat of an earlier problem one user had, as documented in
this thread:
http://common-lisp.net/pipermail/tbnl-devel/2006-December/000876.html
>Basically, mx explanation in the other email was right except for the
>logging part. There should /probably/ be some cleanup that prevents
>errors like this one (that aren't really errors) to pop up the
>debugger.
Maybe an intrigued soul will contribute a patch. The bug is more of an
annoyance than anything.
The original email before I noticed it was a repeat report:
I have been noticing this IO error since several months ago. When
catch-signals is nil, hunchentoot occasionally throws me into the
debugger. It signals at seemingly random points during a server's lifetime.
I have a backtrace, but I do not know the source of the error.
I am running a 64 bit version of SBCL, though I have noticed this on 32
bit SBCL, too.
I/O timeout reading #
[Condition of type SB-SYS:IO-TIMEOUT]
Restarts:
0: [TERMINATE-THREAD] Terminate this thread (#)
Backtrace:
0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN))
#)
1: (SWANK::DEBUG-IN-EMACS #)
2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
#
#)
3: (SWANK::CALL-WITH-REDIRECTED-IO
#
#)
4: (SWANK::CALL-WITH-CONNECTION
#
#)
5: (INVOKE-DEBUGGER #)
6: (INVOKE-DEBUGGER #)
7: (HUNCHENTOOT::MAYBE-INVOKE-DEBUGGER #)
8: (SIGNAL #)
9: (ERROR SB-SYS:IO-TIMEOUT)
10: (SB-IMPL::REFILL-BUFFER/FD
#)
11: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE
#
NIL
:EOF)
12: ((SB-PCL::FAST-METHOD STREAM-READ-BYTE (CHUNGA:CHUNKED-INPUT-STREAM))
(#(8 9) . #())
#
#)
13: ((SB-PCL::FAST-METHOD FLEXI-STREAMS::READ-BYTE*
(FLEXI-STREAMS:FLEXI-INPUT-STREAM))
#
#
#)
14: ((SB-PCL::FAST-METHOD STREAM-READ-CHAR
(FLEXI-STREAMS::FLEXI-LATIN-1-INPUT-STREAM))
#
#
#)
15: (READ-CHAR
#
T
NIL
#)
16: (CHUNGA:READ-LINE*
#
NIL)
17: (HUNCHENTOOT::GET-REQUEST-DATA)
18: (HUNCHENTOOT::PROCESS-CONNECTION
#
#)
19: ((LAMBDA ()))
20: ("foreign function: #x41EE32")
21: ("foreign function: #x416EF1")
-red
From nowhere.man at levallois.eu.org Fri Apr 13 10:50:34 2007
From: nowhere.man at levallois.eu.org (Pierre THIERRY)
Date: Fri, 13 Apr 2007 12:50:34 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To:
References:
<4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com>
Message-ID: <20070413105033.GI15172@bateleur.arcanes.fr.eu.org>
Scribit Andrei Stebakov dies 12/04/2007 hora 16:13:
> So I need to keep track of all servers that I start and for each one return
> it's dispatch-table something like this?:
I suppose you could take advantage of the fact the global variables are
dynamic ones:
(defvar *dispatch-table1* ...)
(defvar *dispatch-table2* ...)
(let ((*dispatch-table* *dispatch-table1*))
(start-server :port 8001))
(let ((*dispatch-table* *dispatch-table2*))
(start-server :port 8002))
I didn't try this code, though, it's just what seemed natural to me for
this use.
Quickly,
Pierre
--
nowhere.man at levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From edi at agharta.de Fri Apr 13 11:21:50 2007
From: edi at agharta.de (Edi Weitz)
Date: Fri, 13 Apr 2007 13:21:50 +0200
Subject: [hunchentoot-devel] Running multiple web application
In-Reply-To: <20070413105033.GI15172@bateleur.arcanes.fr.eu.org> (Pierre
THIERRY's message of "Fri, 13 Apr 2007 12:50:34 +0200")
References: