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| = "Hunchentoot

H...

" #:|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: <4877ae640704121034n23307663s9cb2d35072089af8@mail.gmail.com> <20070413105033.GI15172@bateleur.arcanes.fr.eu.org> Message-ID: On Fri, 13 Apr 2007 12:50:34 +0200, Pierre THIERRY wrote: > 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. That won't work because of MP. You'd have to use implementation-specific facilities like this one: http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-399.htm From coffeemug at gmail.com Sat Apr 14 23:47:37 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Sat, 14 Apr 2007 19:47:37 -0400 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites Message-ID: <87d526ikme.fsf@gmail.com> I'm building a web framework on top of Hunchentoot and I ran into problems while trying to unit test some of my code. Essentially I need to unit test behavior that happens accross requests. I want to do it without starting Hunchentoot by faking the necessary objects (request, session, etc.) The documentation says the usual special variables passed to handlers contain opaque objects. Hunchentoot provides no means of instantiating them manually (unless I get into internal code, which will tie me to the implementation). I see two possible solutions: 1. Abstract my code away from Hunchentoot objects. This way I can fake the necessary environment during unit testing and use Hunchentoot's environment during the real thing. 2. Create my own objects and make sure all appropriate symbols are defined for them - essentially faking Huchentoot's API. It seems like the first option is a better one, but I feel like Huchentoot should provide some support for this. I'd be happy to hack it in if I get some direction (as I'm new to Hunchentoot and CL in general). -- Regards, Slava Akhmechet. From vamlists at gmail.com Sun Apr 15 09:13:28 2007 From: vamlists at gmail.com (Vamsee Kanakala) Date: Sun, 15 Apr 2007 14:43:28 +0530 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <87d526ikme.fsf@gmail.com> References: <87d526ikme.fsf@gmail.com> Message-ID: <4621ECB8.4090307@gmail.com> Slava Akhmechet wrote: > I'm building a web framework on top of Hunchentoot and I ran into > problems while trying to unit test some of my code. Essentially I need > to unit test behavior that happens accross requests. I want to do it > without starting Hunchentoot by faking the necessary objects (request, > session, etc.) > I had a similar problem, and I guess my not very elegant solution was to create a dummy-request class, which basically has the same slots as that of hunchentoot::request, and you can set parameters like so, and set the dummy request instance to *request*: (defclass dummy-request () ((headers-in :initarg :headers-in :initform nil) (method :initarg :method) (uri :initarg :uri) (server-protocol :initarg :server-protocol) (content-stream :initarg :content-stream :reader content-stream) (cookies-in :initform nil) (get-parameters :initform nil) (post-parameters :initform nil) (script-name :initform nil) (query-string :initform nil) (session :initform nil :accessor hunchentoot::session) (aux-data :initform nil :accessor hunchentoot::aux-data) (raw-post-data :initform nil))) And then: (let ((*request* (make-instance 'dummy-request))) (setf (slot-value *request* 'method) :post) (setf (slot-value *request* 'post-parameters) '(("id" . "10") ("name" . "Chicago"))) And you can access this in the regular way: (setf some-var (get-parameter "id")) I found out that setting some vars like hunchentoot::*session-secret* properly and doing a start-session lets you use session within a test happily. For most tests that use session/request related code, I do something like this and put it in a macro: (let* ((hunchentoot::*remote-host* "localhost") (hunchentoot::*session-secret* (hunchentoot::reset-session-secret)) (hunchentoot::*reply* (make-instance 'hunchentoot::reply)) (*request* (make-instance 'dummy-request)) (*session* (start-session))) I'm not sure if this is the best way to do this, but this approach works fine for me. HTH, Vamsee. From coffeemug at gmail.com Sun Apr 15 18:54:57 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Sun, 15 Apr 2007 14:54:57 -0400 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <4621ECB8.4090307@gmail.com> (Vamsee Kanakala's message of "Sun\, 15 Apr 2007 14\:43\:28 +0530") References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> Message-ID: <87fy71bh8e.fsf@gmail.com> Vamsee Kanakala writes: > I had a similar problem, and I guess my not very elegant solution was to > create a dummy-request class, which basically has the same slots as that > of hunchentoot::request, and you can set parameters like so, and set the > dummy request instance to *request*: Thanks! This is essentially what I wanted to do but you handed it to me on a silver platter :) One question though, why do you create a dummy-request class instead of using hunchentoot's? You could also derive something like unittest-request if you need some special functionality. > I found out that setting some vars like hunchentoot::*session-secret* > properly and doing a start-session lets you use session within a test > happily. Would it make sense to add some functions to Hunchentoot that would provide a public API to do this? This way everyone can unit-test Hunchentoot apps in the same standard way. -- Regards, Slava Akhmechet. From vamlists at gmail.com Sun Apr 15 22:38:04 2007 From: vamlists at gmail.com (Vamsee Kanakala) Date: Mon, 16 Apr 2007 04:08:04 +0530 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <87fy71bh8e.fsf@gmail.com> References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> <87fy71bh8e.fsf@gmail.com> Message-ID: <4622A94C.6090700@gmail.com> Slava Akhmechet wrote: > Thanks! This is essentially what I wanted to do but you handed it to > me on a silver platter :) One question though, why do you create a > dummy-request class instead of using hunchentoot's? You could also > derive something like unittest-request if you need some special > functionality. > If I remember correctly, instantiating hunchentoot::request directly is a bit of a problem as it depends on things like headers-in to be set properly, which needs the server to be started, or at least instantiate a hunchentoot::server object. It didn't seem very efficient as I would be running hundreds of tests, and many of them use request params. So I wanted something very simple to just mock hunchentoot::request's behavior in setting and retrieving params. And I was also too lazy to see if a more generic approach could be taken to this :). So yes, unittest-request looks like a good idea. > Would it make sense to add some functions to Hunchentoot that would > provide a public API to do this? This way everyone can unit-test > Hunchentoot apps in the same standard way. > Though I can't say I had a detailed look all the unit test frameworks available out there, but I wasn't satisfied with the ones available, so basically I wrote my own on top of Peter Seibel's code in his PCL book. So a unit test framework that is more web-oriented, hunchentoot-compatible seems like a great idea. Actually there are a couple of times I thought of writing about the same issue to this list, but one thing I was very short on time, and some meddling around seemed to solve my problem. Since you're writing a web framework based on Hunchentoot, seems like we're solving the same problems (I'm adding these bits as I write my webapp) - would love to collaborate where I can. Regards, Vamsee. From victor.kryukov at gmail.com Mon Apr 16 00:03:15 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Sun, 15 Apr 2007 19:03:15 -0500 Subject: [hunchentoot-devel] Handling Lisp errors. Message-ID: Hello list, I want to accomplish the following: every time a lisp error happens, the whole backtrace and some additional information is sent to my mail account. The question is, what is the best way to do it with Hunchentoot? (I do know how to send email messages from lisp with the help of mel-base). The second question is: how do you use CLSQL thread-safely with Hunchentoot / SBCL? SBCL don't provide thread properties, so my first solution[1] was to create a hash-table and to assign each thread a connection, to check from every thread whether it already has a connection, and then to clean that hash-table periodically, closing connections for dead threads. That worked pretty well, but I was afraid of exhausting limit of database threads somehow, so I switched to the second solution. The second solution[2] is to open new connection every time I need to save something to database or read something from it, and to close it right after that. That of course solves connection limit problem (unless I have very many users simultaneously, which is not expected in the near term), however it's much slower. Anybody can share his/her strategy? Best regards, Victor. [1] http://paste.lisp.org/display/39787 (defparameter *database-mutex* (sb-thread:make-mutex :name "database lock")) (defparameter *threads-connection* (make-hash-table)) (defun setup-connection () (connect '("localhost" "lj" "victor" "victor") :database-type :postgresql :if-exists :new)) (defun db () (handler-case (sb-thread:with-mutex (*database-mutex*) (or (gethash sb-thread:*current-thread* *threads-connection*) (setf (gethash sb-thread:*current-thread* *threads-connection*) (setup-connection)))) (error () (progn (close-old-connections) (db))))) (defun close-old-connections () (maphash #'(lambda (thread connection) (unless (sb-thread:thread-alive-p thread) (clsql:disconnect :database connection) (remhash thread *threads-connection*))) *threads-connection*)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((*default-database* (db))) (apply old-select args)))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (apply old-insert-records :database (db) args))) [2] http://paste.lisp.org/display/39787#1 (defun db () (connect *connection-spec* :database-type :postgresql :if-exists :new)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((clsql:*default-database* (db))) (prog1 (apply old-select args) (disconnect :database clsql:*default-database*))))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (let ((db (db))) (prog1 (apply old-insert-records :database db args) (disconnect :database db))))) -- Yours Sincerely, Victor Kryukov From coffeemug at gmail.com Mon Apr 16 00:32:04 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Sun, 15 Apr 2007 20:32:04 -0400 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <4622A94C.6090700@gmail.com> (Vamsee Kanakala's message of "Mon\, 16 Apr 2007 04\:08\:04 +0530") References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> <87fy71bh8e.fsf@gmail.com> <4622A94C.6090700@gmail.com> Message-ID: <874pnh6tx7.fsf@gmail.com> Vamsee Kanakala writes: > If I remember correctly, instantiating hunchentoot::request directly is > a bit of a problem as it depends on things like headers-in to be set > properly, which needs the server to be started, or at least instantiate > a hunchentoot::server object. Ahh, I see. > Though I can't say I had a detailed look all the unit test frameworks > available out there, but I wasn't satisfied with the ones available, so > basically I wrote my own on top of Peter Seibel's code in his PCL book. > So a unit test framework that is more web-oriented, > hunchentoot-compatible seems like a great idea. I wasn't thinking about writing a unit test framework (there are plenty of those, I don't know how adding another one would be beneficial). I was just thinking about making it easy to unit test hunchentoot apps. It looks like you've already given all the information on how to do that, it's just a matter of making it part of hunchentoot (assuming it makes sense). > Since you're writing a web framework based on Hunchentoot, seems > like we're solving the same problems (I'm adding these bits as I > write my webapp) - would love to collaborate where I can. I'll make it Open Source when I'm ready (probably in a few months). My code is currently in a hectic state so I don't want to publish it at the moment. I'd love to discuss any and all web-related issues, though. -- Regards, Slava Akhmechet. From lispercat at gmail.com Mon Apr 16 01:21:02 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Sun, 15 Apr 2007 21:21:02 -0400 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: References: Message-ID: For error handling just supply your own function for *http-error-handler*. >From there you can send an email as well or/and show a message to the user. Something like this: (setq *http-error-handler* 'my-error-handler) (defun my-error-handler (return-code) (if (= +http-moved-temporarily+ return-code) (return-from my-error-handler)) (let ((backtrace (get-backtrace 0)) (session (start-session))) ;; retrieve stuff out of your session (send-email "Critical error" (format nil "RetCode: ~a, Backtrace: ~a" return-code backtrace)) ;; My email function (with-html (:html (:head (:title "Error Page") (:link :rel "stylesheet" :type "text/css" :href *design-css*) (:script :language "JavaScript" :src *js-main-script* :type "text/javascript" "")) (:body (:h2 "Sorry, a server-side error has occured."))) Note that you need to make the size of the html code (css, javascript + html) of the error page more than 512Bytes so that MS IE 7.0 would show your information instead of its own message. Andrew On 4/15/07, Victor Kryukov wrote: > > Hello list, > > I want to accomplish the following: every time a lisp error happens, > the whole backtrace and some additional information is sent to my mail > account. The question is, what is the best way to do it with > Hunchentoot? (I do know how to send email messages from lisp with the > help of mel-base). > > The second question is: how do you use CLSQL thread-safely with > Hunchentoot / SBCL? SBCL don't provide thread properties, so my first > solution[1] was to create a hash-table and to assign each thread a > connection, to check from every thread whether it already has a > connection, and then to clean that hash-table periodically, closing > connections for dead threads. That worked pretty well, but I was > afraid of exhausting limit of database threads somehow, so I switched > to the second solution. > > The second solution[2] is to open new connection every time I need to > save something to database or read something from it, and to close it > right after that. That of course solves connection limit problem > (unless I have very many users simultaneously, which is not expected > in the near term), however it's much slower. > > Anybody can share his/her strategy? > > Best regards, > Victor. > > [1] http://paste.lisp.org/display/39787 > (defparameter *database-mutex* (sb-thread:make-mutex :name "database > lock")) > (defparameter *threads-connection* (make-hash-table)) > > (defun setup-connection () > (connect '("localhost" "lj" "victor" "victor") > :database-type :postgresql :if-exists :new)) > > (defun db () > (handler-case > (sb-thread:with-mutex (*database-mutex*) > (or (gethash sb-thread:*current-thread* *threads-connection*) > (setf (gethash sb-thread:*current-thread* *threads-connection*) > (setup-connection)))) > (error () (progn > (close-old-connections) > (db))))) > > (defun close-old-connections () > (maphash #'(lambda (thread connection) > (unless (sb-thread:thread-alive-p thread) > (clsql:disconnect :database connection) > (remhash thread *threads-connection*))) > *threads-connection*)) > > (let ((old-select (symbol-function 'clsql:select))) > (defun select (&rest args) > (let ((*default-database* (db))) > (apply old-select args)))) > > (let ((old-insert-records (symbol-function 'insert-records))) > (defun insert-records (&rest args) > (apply old-insert-records :database (db) args))) > > > [2] http://paste.lisp.org/display/39787#1 > (defun db () > (connect *connection-spec* > :database-type :postgresql :if-exists :new)) > > (let ((old-select (symbol-function 'clsql:select))) > (defun select (&rest args) > (let ((clsql:*default-database* (db))) > (prog1 > (apply old-select args) > (disconnect :database clsql:*default-database*))))) > > (let ((old-insert-records (symbol-function 'insert-records))) > (defun insert-records (&rest args) > (let ((db (db))) > (prog1 > (apply old-insert-records :database db args) > (disconnect :database db))))) > > > > -- > Yours Sincerely, > Victor Kryukov > _______________________________________________ > 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 Mon Apr 16 02:37:05 2007 From: reddaly at gmail.com (red daly) Date: Sun, 15 Apr 2007 19:37:05 -0700 Subject: [hunchentoot-devel] I/O timeout error (SBCL) In-Reply-To: <461F49A7.80200@gmail.com> References: <461F49A7.80200@gmail.com> Message-ID: <4622E151.1090103@gmail.com> I have attached a patch that fixes the errors for me. -red red daly wrote: > 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 # {10028FCEB1}> > [Condition of type SB-SYS:IO-TIMEOUT] > > Restarts: > 0: [TERMINATE-THREAD] Terminate this thread (# "hunchentoot-worker-79" {10027721A1}>) > > 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 # {1003007811}>) > 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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: red-changes.diff Type: text/x-patch Size: 2270 bytes Desc: not available URL: From edi at agharta.de Mon Apr 16 06:18:53 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 08:18:53 +0200 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <874pnh6tx7.fsf@gmail.com> (Slava Akhmechet's message of "Sun, 15 Apr 2007 20:32:04 -0400") References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> <87fy71bh8e.fsf@gmail.com> <4622A94C.6090700@gmail.com> <874pnh6tx7.fsf@gmail.com> Message-ID: On Sun, 15 Apr 2007 20:32:04 -0400, Slava Akhmechet wrote: > It looks like you've already given all the information on how to do > that, it's just a matter of making it part of hunchentoot (assuming > it makes sense). I'm not yet convinced that that would make sense. I can certainly see the benefit of being able to easily test web applications written with Hunchentoot, but I wonder how much of its internals Hunchentoot should expose for this. If you have to add a lot of code for this, it will be hard to maintain and keep in sync with Hunchentoot, and the chance of the test facilities behaving differently from Hunchentoot itself will increase. Also, I'm not sure if the test suite for a web application shouldn't be in an image different from the web server and operate as a web client. That way it'll be much closer to a real-world scenarion you want to test. Can you point me to other web servers that provide "hooks" for unit testing them without external clients? From edi at agharta.de Mon Apr 16 06:25:10 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 08:25:10 +0200 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: (Andrei Stebakov's message of "Sun, 15 Apr 2007 21:21:02 -0400") References: Message-ID: On Sun, 15 Apr 2007 21:21:02 -0400, "Andrei Stebakov" wrote: > (let ((backtrace (get-backtrace 0)) This is not portable across all platforms supported by Hunchentoot, the argument to GET-BACKTRACE should be a condition. Besides, for catching errors and emailing them I'd rather use an approach similar to what I described here: http://common-lisp.net/pipermail/tbnl-devel/2007-April/001153.html From edi at agharta.de Mon Apr 16 06:29:19 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 08:29:19 +0200 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: (Victor Kryukov's message of "Sun, 15 Apr 2007 19:03:15 -0500") References: Message-ID: On Sun, 15 Apr 2007 19:03:15 -0500, "Victor Kryukov" wrote: > The second question is: how do you use CLSQL thread-safely with > Hunchentoot / SBCL? SBCL don't provide thread properties, so my > first solution[1] was to create a hash-table and to assign each > thread a connection, to check from every thread whether it already > has a connection, and then to clean that hash-table periodically, > closing connections for dead threads. That worked pretty well, but I > was afraid of exhausting limit of database threads somehow, so I > switched to the second solution. > > The second solution[2] is to open new connection every time I need > to save something to database or read something from it, and to > close it right after that. That of course solves connection limit > problem (unless I have very many users simultaneously, which is not > expected in the near term), however it's much slower. > > Anybody can share his/her strategy? I'd use [2] but with pooled connections. See the :POOL keyword argument to CONNECT in CLSQL. That should get rid of your performance problems. > (let ((old-select (symbol-function 'clsql:select))) That technique will break if you recompile the file the code is in. I'd propose to do this (shadow the original SELECT with your own function) with packages. From edi at agharta.de Mon Apr 16 07:54:04 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 09:54:04 +0200 Subject: [hunchentoot-devel] I/O timeout error (SBCL) In-Reply-To: <4622E151.1090103@gmail.com> (red daly's message of "Sun, 15 Apr 2007 19:37:05 -0700") References: <461F49A7.80200@gmail.com> <4622E151.1090103@gmail.com> Message-ID: On Sun, 15 Apr 2007 19:37:05 -0700, red daly wrote: > I have attached a patch that fixes the errors for me. Apart from this not being a patch against the latest release[1], it only applies to SBCL. I have a more general solution in mind which I'll release in the next days if I find some time. Thanks, Edi. [1] http://weitz.de/patches.html From coffeemug at gmail.com Mon Apr 16 14:48:26 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Mon, 16 Apr 2007 10:48:26 -0400 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: (Edi Weitz's message of "Mon\, 16 Apr 2007 08\:18\:53 +0200") References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> <87fy71bh8e.fsf@gmail.com> <4622A94C.6090700@gmail.com> <874pnh6tx7.fsf@gmail.com> Message-ID: <87zm58z879.fsf@gmail.com> Edi Weitz writes: > I'm not yet convinced that that would make sense. BTW, another bit I had to hack was the *server* parameter and class to get 'request-method' to work. Something like this: (defclass unittest-server () ((mod-lisp-p :initform nil :initarg :mod-lisp-p))) (defmethod hunchentoot::server-mod-lisp-p ((obj unittest-server)) (slot-value obj 'mod-lisp-p)) (let ((*server* (make-instance 'unittest-server))) ...) May be when I work through some more of these issues I can release a separate project, sort of a Hunchentoot addon, for unit-testing in this manner. I still think that a client library is too heavy - it would provide a different kind of test (also valueable, but different). -- Regards, Slava Akhmechet. From edi at agharta.de Mon Apr 16 15:07:04 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 17:07:04 +0200 Subject: [hunchentoot-devel] Unit testing Hunchentoot websites In-Reply-To: <87zm58z879.fsf@gmail.com> (Slava Akhmechet's message of "Mon, 16 Apr 2007 10:48:26 -0400") References: <87d526ikme.fsf@gmail.com> <4621ECB8.4090307@gmail.com> <87fy71bh8e.fsf@gmail.com> <4622A94C.6090700@gmail.com> <874pnh6tx7.fsf@gmail.com> <87zm58z879.fsf@gmail.com> Message-ID: On Mon, 16 Apr 2007 10:48:26 -0400, Slava Akhmechet wrote: > May be when I work through some more of these issues I can release a > separate project, sort of a Hunchentoot addon, for unit-testing in > this manner. Yes, I think releasing this as some kind of addon would make much more sense than it becoming part of the core of Hunchentoot. From victor.kryukov at gmail.com Mon Apr 16 17:40:04 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Mon, 16 Apr 2007 12:40:04 -0500 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: References: Message-ID: Andrei and Edi - thanks a lot for you suggestions/comments, I'll investigate this options. On 4/16/07, Edi Weitz wrote: > On Sun, 15 Apr 2007 21:21:02 -0400, "Andrei Stebakov" wrote: > > > (let ((backtrace (get-backtrace 0)) > > This is not portable across all platforms supported by Hunchentoot, > the argument to GET-BACKTRACE should be a condition. > > Besides, for catching errors and emailing them I'd rather use an > approach similar to what I described here: > > http://common-lisp.net/pipermail/tbnl-devel/2007-April/001153.html > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Yours Sincerely, Victor Kryukov From victor.kryukov at gmail.com Mon Apr 16 17:51:12 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Mon, 16 Apr 2007 12:51:12 -0500 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: References: Message-ID: Thanks Edi - using packages is indeed a better idea that just shadowing SELECT right in place. I'll try to experiment with :pool again, though I remember having some troubles using it first time I tried. BTW, it may be a good idea to have some place where people could contribute small snippets/examples of code related to your libraries rather then post them everywhere in their blogs, mailing lists etc. I myself would be happy to contribute finalized versions of thread-safe CLSQL usage / redefining error handlers; though this examples may sound obvious for more experienced Lisp programmers, they would probaly save some time for less experienced one, like myself. E.g. I could setup a separate page on cliki.net. Do you think that makes any sence? Best Regards, Victor. On 4/16/07, Edi Weitz wrote: > On Sun, 15 Apr 2007 19:03:15 -0500, "Victor Kryukov" wrote: > > > The second question is: how do you use CLSQL thread-safely with > > Hunchentoot / SBCL? SBCL don't provide thread properties, so my > > first solution[1] was to create a hash-table and to assign each > > thread a connection, to check from every thread whether it already > > has a connection, and then to clean that hash-table periodically, > > closing connections for dead threads. That worked pretty well, but I > > was afraid of exhausting limit of database threads somehow, so I > > switched to the second solution. > > > > The second solution[2] is to open new connection every time I need > > to save something to database or read something from it, and to > > close it right after that. That of course solves connection limit > > problem (unless I have very many users simultaneously, which is not > > expected in the near term), however it's much slower. > > > > Anybody can share his/her strategy? > > I'd use [2] but with pooled connections. See the :POOL keyword > argument to CONNECT in CLSQL. That should get rid of your performance > problems. > > > (let ((old-select (symbol-function 'clsql:select))) > > That technique will break if you recompile the file the code is in. > I'd propose to do this (shadow the original SELECT with your own > function) with packages. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Yours Sincerely, Victor Kryukov From edi at agharta.de Mon Apr 16 18:33:04 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 20:33:04 +0200 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: (Victor Kryukov's message of "Mon, 16 Apr 2007 12:51:12 -0500") References: Message-ID: On Mon, 16 Apr 2007 12:51:12 -0500, "Victor Kryukov" wrote: > BTW, it may be a good idea to have some place where people could > contribute small snippets/examples of code related to your libraries > rather then post them everywhere in their blogs, mailing lists > etc. I myself would be happy to contribute finalized versions of > thread-safe CLSQL usage / redefining error handlers; though this > examples may sound obvious for more experienced Lisp programmers, > they would probaly save some time for less experienced one, like > myself. E.g. I could setup a separate page on cliki.net. Do you > think that makes any sence? I'm fine with everything that doesn't eat up more of my time... :) Seriously, if you think you can contribute something worthwhile, it's OK with me if you want to use the common-lisp.net resources allocated to Hunchentoot (TBNL) for it (if that helps). You might want to coordinate this with Mac Chan who had similar plans. CLiki or other locations are also fine, of course, this one for example: http://en.wikibooks.org/wiki/Programming:Common_Lisp From yazicivo at ttnet.net.tr Mon Apr 16 18:52:31 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Mon, 16 Apr 2007 21:52:31 +0300 Subject: [hunchentoot-devel] finish-output usage in create-static-file-dispatcher-and-handler Message-ID: <877isc8840.fsf@ttnet.net.tr> Hi, Just for curiosity, in create-static-file-dispatcher-and-handler function, wouldn't it be better if we flush the buffer finally in the loop instead of calling finish-output at every step. Does it have a special objective, e.g., for debugging purposes, portability issues? And maybe, it'd even be better to use (or to support optionally) force-output instead of finish-output. (With price of not receiving any acknowledgment about the flushed buffer.) Regards. From edi at agharta.de Mon Apr 16 19:03:33 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 21:03:33 +0200 Subject: [hunchentoot-devel] finish-output usage in create-static-file-dispatcher-and-handler In-Reply-To: <877isc8840.fsf@ttnet.net.tr> (Volkan YAZICI's message of "Mon, 16 Apr 2007 21:52:31 +0300") References: <877isc8840.fsf@ttnet.net.tr> Message-ID: On Mon, 16 Apr 2007 21:52:31 +0300, Volkan YAZICI wrote: > Just for curiosity, in create-static-file-dispatcher-and-handler > function, wouldn't it be better if we flush the buffer finally in > the loop instead of calling finish-output at every step. Does it > have a special objective, e.g., for debugging purposes, portability > issues? The way it works now it'll send separate chunks if chunked encoding is used. > And maybe, it'd even be better to use (or to support optionally) > force-output instead of finish-output. (With price of not receiving > any acknowledgment about the flushed buffer.) I doubt that using FORCE-OUTPUT really buys you anything except for very rare situations. I'd rather advise the user to write his own version of C-S-F-D-A-H in this case. From grue at mail.ru Mon Apr 16 20:08:20 2007 From: grue at mail.ru (Timofei Shatrov) Date: Tue, 17 Apr 2007 00:08:20 +0400 Subject: [hunchentoot-devel] Headers eaten during HTTP POST... Message-ID: <101774069.20070417000820@mail.ru> I'm rather new to web-programming and I seem to have stumbled upon something horrible. My setup is lighttpd+mod_proxy on Windows XP which redirect to Hunchentoot running on SBCL on Ubuntu Feisty, which is running on VMWare player on the same PC. Everything works fine except HTTP POST, which behaves very weirdly. When I submit POST data, everything is screwed. After some attempts to debug, I found that beginning of headers becomes eaten for some reason, for example the first line may be: "8.1.2) Gecko/20061201 Firefox/2.0.0.2 (Ubuntu-feisty)" (which is part of User-agent: header), when it should be "POST /cl/test-form /HTTP1.1" After that Hunchentoot tries to parse this line and you can guess that nothing good comes out of it... Note that this only happens when I access the page through mod_proxy, when I point at Hunchentoot's IP, everything is fine. However I can't believe mod_proxy randomly eats headers, because that's rather huge bug and would be noticed by everyone. This is reproduceable with hutchentoot-test examples which involve POST. -- Best regards, Timofei Shatrov mailto:grue at mail.ru From diesenbacher at gmail.com Mon Apr 16 20:12:31 2007 From: diesenbacher at gmail.com (Otto Diesenbacher) Date: Mon, 16 Apr 2007 22:12:31 +0200 Subject: [hunchentoot-devel] Handling Lisp errors. References: Message-ID: <87vefwjcy8.fsf@gmail.com> "Victor Kryukov" writes: > The second question is: how do you use CLSQL thread-safely with > Hunchentoot / SBCL? SBCL don't provide thread properties, so my first > solution[1] was to create a hash-table and to assign each thread a > connection, to check from every thread whether it already has a > connection, and then to clean that hash-table periodically, closing > connections for dead threads. That worked pretty well, but I was > afraid of exhausting limit of database threads somehow, so I switched > to the second solution. i put any database-communication out of an function, called via the *dispatch-table*, into a (with-db (bla bla)) macro: (defmacro with-db (&body body) `(let ((clsql:*default-database* (clsql:connect (list "127.0.0.1" "bla" "bla" "bla") :pool t :database-type :postgresql))) (unwind-protect (progn , at body) (clsql:disconnect :database clsql:*default-database*)))) so any thread should get his own *default-database* from the clsql connection pool? -- okflo From edi at agharta.de Mon Apr 16 20:30:45 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Apr 2007 22:30:45 +0200 Subject: [hunchentoot-devel] Headers eaten during HTTP POST... In-Reply-To: <101774069.20070417000820@mail.ru> (Timofei Shatrov's message of "Tue, 17 Apr 2007 00:08:20 +0400") References: <101774069.20070417000820@mail.ru> Message-ID: On Tue, 17 Apr 2007 00:08:20 +0400, Timofei Shatrov wrote: > My setup is lighttpd+mod_proxy on Windows XP which redirect to > Hunchentoot running on SBCL on Ubuntu Feisty, which is running on > VMWare player on the same PC. Hmm, that's certainly a setup I can't reproduce here in a reasonable time frame, so you're on your own. > when it should be > "POST /cl/test-form /HTTP1.1" It should be "POST /cl/test-form HTTP/1.1" I guess. > Note that this only happens when I access the page through > mod_proxy, when I point at Hunchentoot's IP, everything is > fine. So, this doesn't really look like Hunchentoot's fault, does it? > However I can't believe mod_proxy randomly eats headers, because > that's rather huge bug and would be noticed by everyone. Maybe the lighttpd+mod_proxy+WinXP combo is not very common? I don't know. Have you tried using WireShark on Ubuntu to monitor what mod_proxy really sends to Hunchentoot? That'd be the first thing I would try in your case. HTH, Edi. From penguin at ocean.vvo.ru Tue Apr 17 00:46:48 2007 From: penguin at ocean.vvo.ru (Igor Plekhov) Date: Tue, 17 Apr 2007 11:46:48 +1100 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: <87vefwjcy8.fsf@gmail.com> References: <87vefwjcy8.fsf@gmail.com> Message-ID: <20070417004648.GS6233@ocean.vvo.ru> On Mon, 16 Apr, 2007 at 22:12:31 +0200, Otto Diesenbacher wrote: > > i put any database-communication out of an function, called via the > *dispatch-table*, into a (with-db (bla bla)) macro: CLSQL already has that kind of macros: http://clsql.b9.com/manual/with-database.html http://clsql.b9.com/manual/with-default-database.html -- Registered Linux User #124759 From nowhere.man at levallois.eu.org Tue Apr 17 10:18:14 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Tue, 17 Apr 2007 12:18:14 +0200 Subject: [hunchentoot-devel] Handling Lisp errors. In-Reply-To: References: Message-ID: <20070417101814.GD29043@bateleur.arcanes.fr.eu.org> Scribit Victor Kryukov dies 15/04/2007 hora 19:03: > SBCL don't provide thread properties, so my first solution[1] was to > create a hash-table and to assign each thread a connection, to check > from every thread whether it already has a connection, and then to > clean that hash-table periodically, closing connections for dead > threads. Now that I'm used to Lisp's first-class everything, I'd rather mimic it everywhere. For example, you could create a custom thread object whose creation not only starts a thread but takes care of creating a DB connection (or taking it out of a pool) and making it accessible in the thread, probably with a dynamic variable... 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 jboehland+tbnl at gmail.com Wed Apr 18 13:43:47 2007 From: jboehland+tbnl at gmail.com (Joel Boehland) Date: Wed, 18 Apr 2007 06:43:47 -0700 Subject: [hunchentoot-devel] hunchentoot-mp and OpenMCL problems Message-ID: Hi, I just ran into a problem starting up-to-date darcs hunchentoot on OpenMCL 1.1 (releases 070408 and 070214, linux-x86-64). I believe this problem is related to the recently added hunchentoot-mp package, as this error doesn't occur in an earlier install of darcs hunchentoot from March, right before the addition of that package. While trying to load this file: (hello-hunchentoot.lisp) (require :asdf) (asdf:oos 'asdf:load-op :hunchentoot-test) (hunchentoot:start-server :port 4242) I got this error: > Error: The function MAKE-LOCK is predefined in OpenMCL. > While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Replace the definition of MAKE-LOCK. > Type :? for other options. 1 > If anyone needs any more info, or wants me to test anything to help out, let me know. Thanks, Joel From edi at agharta.de Wed Apr 18 14:14:48 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 18 Apr 2007 16:14:48 +0200 Subject: [hunchentoot-devel] hunchentoot-mp and OpenMCL problems In-Reply-To: (Joel Boehland's message of "Wed, 18 Apr 2007 06:43:47 -0700") References: Message-ID: Hi, On Wed, 18 Apr 2007 06:43:47 -0700, "Joel Boehland" wrote: > I just ran into a problem starting up-to-date darcs hunchentoot on > OpenMCL 1.1 (releases 070408 and 070214, linux-x86-64). Just to make this clear - "up-to-date darcs" might or might not be the same as the current Hunchentoot release. It's nice that Lu?s maintains this repository, but for bug reports you should make sure you're referring to a released version. (Doesn't really matter in this case, though.) > I believe this problem is related to the recently added > hunchentoot-mp package, as this error doesn't occur in an earlier > install of darcs hunchentoot from March, right before the addition > of that package. > > While trying to load this file: (hello-hunchentoot.lisp) > (require :asdf) > (asdf:oos 'asdf:load-op :hunchentoot-test) > (hunchentoot:start-server :port 4242) > > I got this error: > >> Error: The function MAKE-LOCK is predefined in OpenMCL. >> While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). >> Type :GO to continue, :POP to abort, :R for a list of available restarts. >> If continued: Replace the definition of MAKE-LOCK. >> Type :? for other options. > 1 > > > If anyone needs any more info, or wants me to test anything to help > out, let me know. Can you provide a backtrace? Can you try the ASDF:OOS call from a listener and see what happens? Have you made sure to delete old FASL files? I can't test myself because I don't have a Mac. Cheers, Edi. From jboehland+tbnl at gmail.com Wed Apr 18 18:10:48 2007 From: jboehland+tbnl at gmail.com (Joel Boehland) Date: Wed, 18 Apr 2007 11:10:48 -0700 Subject: [hunchentoot-devel] hunchentoot-mp and OpenMCL problems In-Reply-To: References: Message-ID: Hi Edi, Just a quick clarification: I am running the linux port (x86-64) of OpenMCL. I have tried OpenMCL snapshots 070214 and 070408 and a version updated from cvs yesterday. Between each try, I delete all the .lx64fsl files. On each of these OpenMCL versions, with the most recent hunchentoot, I get this error. With hunchentoot version 0.7.2, I don't get this error. The following is a transcript captured using gnu screen, where I try your suggestions and have captured a back trace. I will also attach it, since gmail may mess up the formatting. If you think of anything else you'd like me to do to help, please let me know. Thanks, Joel ------------------------------------------------------------------------------- joel at buckaroo-home:systems$ find .. -name '*.lx64fsl' -exec rm {} \; joel at buckaroo-home:systems$ rlwrap openmcl64 Welcome to OpenMCL Version 1.1-pre-070408 (LinuxX8664)! ? (require :asdf) :ASDF ("ASDF") ? (asdf:oos 'asdf:load-op :hunchentoot-test) ; loading system definition from hunchentoot-test.asd into # ; registering # as HUNCHENTOOT-TEST ; loading system definition from cl-who.asd into # ; registering # as CL-WHO ; loading system definition from hunchentoot.asd into # ; registering # as HUNCHENTOOT ; loading system definition from url-rewrite.asd into # ; registering # as URL-REWRITE ; loading system definition from rfc2388.asd into # ; registering # as RFC2388 ; loading system definition from md5.asd into # ; registering # as MD5 ; loading system definition from cl+ssl.asd into # ; registering # as CL+SSL ; loading system definition from flexi-streams.asd into # ; registering # as FLEXI-STREAMS ; registering # as FLEXI-STREAMS-TEST ; loading system definition from trivial-gray-streams.asd into # ; registering # as TRIVIAL-GRAY-STREAMS ; loading system definition from cffi.asd into # ; registering # as CFFI ; loading system definition from cl-ppcre.asd into # ; registering # as CL-PPCRE ; loading system definition from cl-base64.asd into # ; registering # as CL-BASE64 ; registering # as CL-BASE64-TESTS ; loading system definition from chunga.asd into # ; registering # as CHUNGA ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/flexi-streams/stream.lisp" : ; Unused lexical variable STREAM, in (SET-ENCODING-TABLE (T)) inside an anonymous lambda form. ; Unused lexical variable STREAM, in (SET-ENCODING-HASH (T)) inside an anonymous lambda form. ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/chunga/input.lisp" : ; Unused lexical variable OBJECT, in (CHUNKED-INPUT-STREAM-EXTENSIONS (T)). ; Unused lexical variable OBJECT, in (CHUNKED-INPUT-STREAM-TRAILERS (T)). ; Unused lexical variable OBJECT, in (CHUNKED-STREAM-INPUT-CHUNKING-P (T)). ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/chunga/output.lisp" : ; Unused lexical variable OBJECT, in (CHUNKED-STREAM-OUTPUT-CHUNKING-P (T)). ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). > Error: The function MAKE-LOCK is predefined in OpenMCL. > While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Replace the definition of MAKE-LOCK. > Type :? for other options. 1 > :B (2AAAAACBB658) : 0 (REDEFINE-KERNEL-FUNCTION 'MAKE-LOCK) 541 (2AAAAACBB670) : 1 (FSET 'MAKE-LOCK #) 397 (2AAAAACBB698) : 2 (%DEFUN # [...]) 397 (2AAAAACBB6C0) : 3 (%FASLOAD "/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" [...]) 1629 (2AAAAACBB768) : 4 (FUNCALL #'# #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl") 101 (2AAAAACBB788) : 5 (%LOAD #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" NIL 'CCL::%FASL-READ-BYTE :ERROR :DEFAULT) 2477 (2AAAAACBB8C0) : 6 (LOAD #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" [...]) 997 (2AAAAACBB960) : 7 (FUNCALL #'#<#> # #) 261 (2AAAAACBB9B0) : 8 (%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL #<#> . 5864062285646)) 893 (2AAAAACBBA20) : 9 (%%STANDARD-COMBINED-METHOD-DCODE '(NIL # #<#>) 5864062285646) 261 (2AAAAACBBA88) : 11 (OPERATE 'ASDF:LOAD-OP :HUNCHENTOOT-TEST [...]) 1653 (2AAAAACBBB68) : 12 (CALL-CHECK-REGS 'ASDF:OOS [...]) 229 (2AAAAACBBBA0) : 13 (TOPLEVEL-EVAL '(ASDF:OOS # :HUNCHENTOOT-TEST) [...]) 429 (2AAAAACBBBF0) : 14 (READ-LOOP [...]) 1893 (2AAAAACBBDF8) : 15 (TOPLEVEL-LOOP) 133 (2AAAAACBBE28) : 16 (FUNCALL #'#) 133 (2AAAAACBBE40) : 17 (FUNCALL #'#) 773 (2AAAAACBBEC8) : 18 (RUN-PROCESS-INITIAL-FORM # '(#)) 701 (2AAAAACBBF48) : 19 (FUNCALL #'# # '(#)) 397 (2AAAAACBBF98) : 20 (FUNCALL #'#) 365 1 > ------------------------------------------------------------------------------- On 4/18/07, Edi Weitz wrote: > Hi, > > On Wed, 18 Apr 2007 06:43:47 -0700, "Joel Boehland" wrote: > > > I just ran into a problem starting up-to-date darcs hunchentoot on > > OpenMCL 1.1 (releases 070408 and 070214, linux-x86-64). > > Just to make this clear - "up-to-date darcs" might or might not be the > same as the current Hunchentoot release. It's nice that Lu?s > maintains this repository, but for bug reports you should make sure > you're referring to a released version. (Doesn't really matter in > this case, though.) > > > I believe this problem is related to the recently added > > hunchentoot-mp package, as this error doesn't occur in an earlier > > install of darcs hunchentoot from March, right before the addition > > of that package. > > > > While trying to load this file: (hello-hunchentoot.lisp) > > (require :asdf) > > (asdf:oos 'asdf:load-op :hunchentoot-test) > > (hunchentoot:start-server :port 4242) > > > > I got this error: > > > >> Error: The function MAKE-LOCK is predefined in OpenMCL. > >> While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > >> Type :GO to continue, :POP to abort, :R for a list of available restarts. > >> If continued: Replace the definition of MAKE-LOCK. > >> Type :? for other options. > > 1 > > > > > If anyone needs any more info, or wants me to test anything to help > > out, let me know. > > Can you provide a backtrace? Can you try the ASDF:OOS call from a > listener and see what happens? Have you made sure to delete old FASL > files? > > I can't test myself because I don't have a Mac. > > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- joel at buckaroo-home:systems$ find .. -name '*.lx64fsl' -exec rm {} \; joel at buckaroo-home:systems$ rlwrap openmcl64 Welcome to OpenMCL Version 1.1-pre-070408 (LinuxX8664)! ? (require :asdf) :ASDF ("ASDF") ? (asdf:oos 'asdf:load-op :hunchentoot-test) ; loading system definition from hunchentoot-test.asd into # ; registering # as HUNCHENTOOT-TEST ; loading system definition from cl-who.asd into # ; registering # as CL-WHO ; loading system definition from hunchentoot.asd into # ; registering # as HUNCHENTOOT ; loading system definition from url-rewrite.asd into # ; registering # as URL-REWRITE ; loading system definition from rfc2388.asd into # ; registering # as RFC2388 ; loading system definition from md5.asd into # ; registering # as MD5 ; loading system definition from cl+ssl.asd into # ; registering # as CL+SSL ; loading system definition from flexi-streams.asd into # ; registering # as FLEXI-STREAMS ; registering # as FLEXI-STREAMS-TEST ; loading system definition from trivial-gray-streams.asd into # ; registering # as TRIVIAL-GRAY-STREAMS ; loading system definition from cffi.asd into # ; registering # as CFFI ; loading system definition from cl-ppcre.asd into # ; registering # as CL-PPCRE ; loading system definition from cl-base64.asd into # ; registering # as CL-BASE64 ; registering # as CL-BASE64-TESTS ; loading system definition from chunga.asd into # ; registering # as CHUNGA ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/flexi-streams/stream.lisp" : ; Unused lexical variable STREAM, in (SET-ENCODING-TABLE (T)) inside an anonymous lambda form. ; Unused lexical variable STREAM, in (SET-ENCODING-HASH (T)) inside an anonymous lambda form. ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/chunga/input.lisp" : ; Unused lexical variable OBJECT, in (CHUNKED-INPUT-STREAM-EXTENSIONS (T)). ; Unused lexical variable OBJECT, in (CHUNKED-INPUT-STREAM-TRAILERS (T)). ; Unused lexical variable OBJECT, in (CHUNKED-STREAM-INPUT-CHUNKING-P (T)). ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). ;Compiler warnings for "/home/joel/work/webdev/hunchentoot/chunga/output.lisp" : ; Unused lexical variable OBJECT, in (CHUNKED-STREAM-OUTPUT-CHUNKING-P (T)). ; Warning: COMPILE-FILE warned while performing # on #. ; While executing: #, in process listener(1). > Error: The function MAKE-LOCK is predefined in OpenMCL. > While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Replace the definition of MAKE-LOCK. > Type :? for other options. 1 > :B (2AAAAACBB658) : 0 (REDEFINE-KERNEL-FUNCTION 'MAKE-LOCK) 541 (2AAAAACBB670) : 1 (FSET 'MAKE-LOCK #) 397 (2AAAAACBB698) : 2 (%DEFUN # [...]) 397 (2AAAAACBB6C0) : 3 (%FASLOAD "/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" [...]) 1629 (2AAAAACBB768) : 4 (FUNCALL #'# #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl") 101 (2AAAAACBB788) : 5 (%LOAD #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" NIL 'CCL::%FASL-READ-BYTE :ERROR :DEFAULT) 2477 (2AAAAACBB8C0) : 6 (LOAD #P"/home/joel/work/webdev/hunchentoot/hunchentoot/port-mcl.lx64fsl" [...]) 997 (2AAAAACBB960) : 7 (FUNCALL #'#<#> # #) 261 (2AAAAACBB9B0) : 8 (%%BEFORE-AND-AFTER-COMBINED-METHOD-DCODE '(NIL #<#> . 5864062285646)) 893 (2AAAAACBBA20) : 9 (%%STANDARD-COMBINED-METHOD-DCODE '(NIL # #<#>) 5864062285646) 261 (2AAAAACBBA88) : 11 (OPERATE 'ASDF:LOAD-OP :HUNCHENTOOT-TEST [...]) 1653 (2AAAAACBBB68) : 12 (CALL-CHECK-REGS 'ASDF:OOS [...]) 229 (2AAAAACBBBA0) : 13 (TOPLEVEL-EVAL '(ASDF:OOS # :HUNCHENTOOT-TEST) [...]) 429 (2AAAAACBBBF0) : 14 (READ-LOOP [...]) 1893 (2AAAAACBBDF8) : 15 (TOPLEVEL-LOOP) 133 (2AAAAACBBE28) : 16 (FUNCALL #'#) 133 (2AAAAACBBE40) : 17 (FUNCALL #'#) 773 (2AAAAACBBEC8) : 18 (RUN-PROCESS-INITIAL-FORM # '(#)) 701 (2AAAAACBBF48) : 19 (FUNCALL #'# # '(#)) 397 (2AAAAACBBF98) : 20 (FUNCALL #'#) 365 1 > From edi at agharta.de Wed Apr 18 20:13:56 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 18 Apr 2007 22:13:56 +0200 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV Message-ID: This is a WebDAV server based on Hunchentoot. More info here: http://weitz.de/cl-webdav/ Cheers, Edi. From edi at agharta.de Wed Apr 18 20:36:51 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 18 Apr 2007 22:36:51 +0200 Subject: [hunchentoot-devel] New release 0.8.6 (Was: hunchentoot-mp and OpenMCL problems) In-Reply-To: (Joel Boehland's message of "Wed, 18 Apr 2007 11:10:48 -0700") References: Message-ID: On Wed, 18 Apr 2007 11:10:48 -0700, "Joel Boehland" wrote: > The following is a transcript captured using gnu screen, where I try > your suggestions and have captured a back trace. Could you please try the new release and check if this fixes it? Thanks for the report, Edi. From jboehland+tbnl at gmail.com Wed Apr 18 21:16:28 2007 From: jboehland+tbnl at gmail.com (Joel Boehland) Date: Wed, 18 Apr 2007 14:16:28 -0700 Subject: [hunchentoot-devel] FIXED: New release 0.8.6 (Was: hunchentoot-mp and OpenMCL problems) Message-ID: Hi Edi, Hunchentoot version 0.8.6 fixed the problem. I can load up the test application without problems on OpenMCL/linux. That was very fast. Thanks! --Joel On 4/18/07, Edi Weitz wrote: > On Wed, 18 Apr 2007 11:10:48 -0700, "Joel Boehland" wrote: > > > The following is a transcript captured using gnu screen, where I try > > your suggestions and have captured a back trace. > > Could you please try the new release and check if this fixes it? > > Thanks for the report, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From gwking at metabang.com Wed Apr 18 21:53:23 2007 From: gwking at metabang.com (Gary King) Date: Wed, 18 Apr 2007 17:53:23 -0400 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: References: Message-ID: <2BE10FC7-5565-4AA8-882A-861CB31F9755@metabang.com> Awesome! I look forward to creating some time to look at this/ Thanks Edi, On Apr 18, 2007, at 4:13 PM, Edi Weitz wrote: > This is a WebDAV server based on Hunchentoot. More info here: > > http://weitz.de/cl-webdav/ > > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From emailmac at gmail.com Wed Apr 18 22:50:49 2007 From: emailmac at gmail.com (Mac Chan) Date: Wed, 18 Apr 2007 15:50:49 -0700 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: References: Message-ID: <4877ae640704181550k3bb857a8u849097e2bcc1adca@mail.gmail.com> The screenshot looks so sexy! I can feel that great piece of CL code running behind the scene which this Windows Explorer is talking to ;-) OK, I'm not sure what I'm talking about. Great job Edi! Thanks. On 4/18/07, Edi Weitz wrote: > This is a WebDAV server based on Hunchentoot. More info here: > > http://weitz.de/cl-webdav/ > > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at agharta.de Thu Apr 19 09:18:45 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Apr 2007 11:18:45 +0200 Subject: [hunchentoot-devel] New release 0.9.0 Message-ID: ChangeLog: Version 0.9.0 2007-04-19 Added socket timeouts for AllegroCL Catch IO timeout conditions for AllegroCL, SBCL and CMUCL (suggested by Red Daly and others) Added per-server dispatch tables (suggested by Robert Synnott and Andrei Stebakov) Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi. From nowhere.man at levallois.eu.org Thu Apr 19 17:21:15 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Thu, 19 Apr 2007 19:21:15 +0200 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: References: Message-ID: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> Scribit Edi Weitz dies 18/04/2007 hora 22:13: > This is a WebDAV server based on Hunchentoot. Great, I had just begun to read the WebDAV RFCs again to try and implement that! I'm willing to use that, and I'll see if I can help resolve the issues listed of the project's page. I've added CL-WEBDAV to the set of Mercurial repositories: http://arcanes.fr.eu.org/~pierre/2007/02/weitz/ 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 Thu Apr 19 17:31:59 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Thu, 19 Apr 2007 13:31:59 -0400 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> References: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> Message-ID: Quote: "Edi Weitz dies 18/04/2007 hora 22:13" This nearly gave me a heart attack :) Andrew On 4/19/07, Pierre THIERRY wrote: > > Scribit Edi Weitz dies 18/04/2007 hora 22:13: > > This is a WebDAV server based on Hunchentoot. > > Great, I had just begun to read the WebDAV RFCs again to try and > implement that! I'm willing to use that, and I'll see if I can help > resolve the issues listed of the project's page. > > I've added CL-WEBDAV to the set of Mercurial repositories: > > http://arcanes.fr.eu.org/~pierre/2007/02/weitz/ > > Quickly, > Pierre > -- > nowhere.man at levallois.eu.org > OpenPGP 0xD9D50D8A > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGJ6ULxe13INnVDYoRArf0AKDLBRzJZwfGEIe74olaqBHk0ELiEQCg8V4x > BiQiH5QeiW1wRNB/bxlURh8= > =IoVY > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 19 17:41:55 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Apr 2007 19:41:55 +0200 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: (Andrei Stebakov's message of "Thu, 19 Apr 2007 13:31:59 -0400") References: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> Message-ID: On Thu, 19 Apr 2007 13:31:59 -0400, "Andrei Stebakov" wrote: > Quote: "Edi Weitz dies 18/04/2007 hora 22:13" > > This nearly gave me a heart attack :) I'm still here... :) From edi at agharta.de Thu Apr 19 17:43:13 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Apr 2007 19:43:13 +0200 Subject: [hunchentoot-devel] Announcement: CL-WEBDAV In-Reply-To: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> (Pierre THIERRY's message of "Thu, 19 Apr 2007 19:21:15 +0200") References: <20070419172115.GL29043@bateleur.arcanes.fr.eu.org> Message-ID: On Thu, 19 Apr 2007 19:21:15 +0200, Pierre THIERRY wrote: > I'll see if I can help resolve the issues listed of the project's > page. Great. But make sure to read the page about patches first... :) > I've added CL-WEBDAV to the set of Mercurial repositories: > > http://arcanes.fr.eu.org/~pierre/2007/02/weitz/ Thanks, I'll add a link to the website. From info at jensteich.de Thu Apr 19 21:17:30 2007 From: info at jensteich.de (Jens Teich) Date: Thu, 19 Apr 2007 23:17:30 +0200 Subject: [hunchentoot-devel] wrong version of sbcl Message-ID: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> I'm trying to avoid buying LispWorks for Macintosh but want to run hunchentoot on Intel Mac OS X 10.4.9. The result is: (ERROR "This application will only run on SBCL with thread and Unicode support or on LispWorks.") I have the latest SBCL-Version (1.0.4) and can't find anything on sbcl.org about versions with or without these features. -jens From info at jensteich.de Thu Apr 19 21:28:40 2007 From: info at jensteich.de (Jens Teich) Date: Thu, 19 Apr 2007 23:28:40 +0200 Subject: [hunchentoot-devel] wrong version of sbcl References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> Message-ID: <008d01c782c9$b4b051c0$93d4bb5a@JensSony> Jens Teich wrote: > I'm trying to avoid buying LispWorks for Macintosh but want to run > hunchentoot on > Intel Mac OS X 10.4.9. > > The result is: > > (ERROR "This application will only run on SBCL with thread and > Unicode support or on LispWorks.") > > I have the latest SBCL-Version (1.0.4) and can't find anything on > sbcl.org about versions with or > without these features. sorry for bothering, found the link in the documentation http://abstractstuff.livejournal.com/26811.html -jens From ch-tbnl at bobobeach.com Thu Apr 19 21:31:14 2007 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 19 Apr 2007 14:31:14 -0700 Subject: [hunchentoot-devel] wrong version of sbcl In-Reply-To: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> Message-ID: Hi Jens, You need to build a copy of SBCL with threads. You might consider using the latest source from CVS and build with a customize-target- features.lisp file like so: (lambda (list) (flet ((enable (x) (pushnew x list)) (disable (x) (setf list (remove x list)))) #+nil (enable :sb-show) (enable :sb-after-xc-core) (enable :sb-ldb) (enable :sb-thread) (enable :mach-exception-handler) list)) good luck, Cyrus On Apr 19, 2007, at 2:17 PM, Jens Teich wrote: > I'm trying to avoid buying LispWorks for Macintosh but want to run > hunchentoot on > Intel Mac OS X 10.4.9. > > The result is: > > (ERROR "This application will only run on SBCL with thread and > Unicode support or on LispWorks.") > > I have the latest SBCL-Version (1.0.4) and can't find anything on > sbcl.org about versions with or > without these features. > > -jens > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From ch-tbnl at bobobeach.com Thu Apr 19 21:32:03 2007 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 19 Apr 2007 14:32:03 -0700 Subject: [hunchentoot-devel] wrong version of sbcl In-Reply-To: <008d01c782c9$b4b051c0$93d4bb5a@JensSony> References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> <008d01c782c9$b4b051c0$93d4bb5a@JensSony> Message-ID: <1337C09B-2059-491E-BC9B-AE1539ED00D2@bobobeach.com> Well, yes, you can do that, but you will probably have better luck with a threaded SBCL build. Cyrus On Apr 19, 2007, at 2:28 PM, Jens Teich wrote: > Jens Teich wrote: >> I'm trying to avoid buying LispWorks for Macintosh but want to run >> hunchentoot on >> Intel Mac OS X 10.4.9. >> >> The result is: >> >> (ERROR "This application will only run on SBCL with thread and >> Unicode support or on LispWorks.") >> >> I have the latest SBCL-Version (1.0.4) and can't find anything on >> sbcl.org about versions with or >> without these features. > > sorry for bothering, found the link in the documentation > http://abstractstuff.livejournal.com/26811.html > > -jens > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Thu Apr 19 21:35:59 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Apr 2007 23:35:59 +0200 Subject: [hunchentoot-devel] wrong version of sbcl In-Reply-To: <008d01c782c9$b4b051c0$93d4bb5a@JensSony> (Jens Teich's message of "Thu, 19 Apr 2007 23:28:40 +0200") References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> <008d01c782c9$b4b051c0$93d4bb5a@JensSony> Message-ID: On Thu, 19 Apr 2007 23:28:40 +0200, "Jens Teich" wrote: >> The result is: >> >> (ERROR "This application will only run on SBCL with thread and >> Unicode support or on LispWorks.") If you see that message, you're using a very old version of Hunchentoot. 0.7.0 introduced development support for non-threaded SBCL, although you shouldn't use it for production purposes. From edi at agharta.de Thu Apr 19 21:40:15 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Apr 2007 23:40:15 +0200 Subject: [hunchentoot-devel] wrong version of sbcl In-Reply-To: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> (Jens Teich's message of "Thu, 19 Apr 2007 23:17:30 +0200") References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> Message-ID: On Thu, 19 Apr 2007 23:17:30 +0200, Jens Teich wrote: > (ERROR "This application will only run on SBCL with thread and > Unicode support or on LispWorks.") Actually, I'm pretty sure the "or on LispWorks" part was never in there... From info at jensteich.de Thu Apr 19 23:42:01 2007 From: info at jensteich.de (Jens Teich) Date: Fri, 20 Apr 2007 01:42:01 +0200 Subject: [hunchentoot-devel] wrong version of sbcl References: <37748B5C-D18A-41F5-9585-5C2DEC111874@jensteich.de> Message-ID: <00ab01c782dc$57fc0a60$93d4bb5a@JensSony> Edi Weitz wrote: > On Thu, 19 Apr 2007 23:17:30 +0200, Jens Teich > wrote: > >> (ERROR "This application will only run on SBCL with thread and >> Unicode support or on LispWorks.") > > Actually, I'm pretty sure the "or on LispWorks" part was never in > there... I am using the brand new version 0.9.0 but you are right, the error is thrown in my application. #-(or (and :sb-thread :sb-unicode) :lispworks) (error "This application will only run on SBCL with thread and Unicode support or on LispWorks.") (defpackage :webcontent (:use :cl :cl-who :hunchentoot :flex) (:export :*backup-interval* :*webcontent-port* :start :stop) #+:sbcl (:shadow :defconstant)) These lines will be familiar to you :) thx jens From dking at ketralnis.com Thu Apr 19 23:48:01 2007 From: dking at ketralnis.com (David King) Date: Thu, 19 Apr 2007 16:48:01 -0700 Subject: [hunchentoot-devel] Webdav client? Message-ID: How useful would cl-webdav be as a webdav *client* as opposed to a server? -- David From edi at agharta.de Fri Apr 20 10:30:12 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Apr 2007 12:30:12 +0200 Subject: [hunchentoot-devel] Webdav client? In-Reply-To: (David King's message of "Thu, 19 Apr 2007 16:48:01 -0700") References: Message-ID: On Thu, 19 Apr 2007 16:48:01 -0700, David King wrote: > How useful would cl-webdav be as a webdav *client* as opposed to a > server? Not at all, I'd say, because it's a server and not a client. You might want to look into Drakma for client functionality: http://weitz.de/drakma/ Maybe you can re-use some of the XML stuff in CL-WEBDAV to generate and understand PROPFIND and PROPERTYUPDATE requests, but for simple WebDAV usage Drakma should suffice. Cheers, Edi. From yazicivo at ttnet.net.tr Sun Apr 22 18:15:09 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sun, 22 Apr 2007 21:15:09 +0300 Subject: [hunchentoot-devel] Accessor Function for Form Fields Message-ID: <87ejmc8edu.fsf@ttnet.net.tr> Hi, I really like the way DEFINE-EASY-HANDLER works with supplied form field parameters. But the problem with it is, IMHO, that you cannot use DEFINE-EASY-HANDLER everywhere in the code when you want to reach to a form variable. Therefore I come up with such a solution: (let ((default-parameter-type ''string) (default-request-type :both)) (defmacro with-form-fields ((&rest fields) &body body) `(let ,(loop for field in fields collect (hunchentoot::make-defun-parameter field default-parameter-type default-request-type)) , at body))) I couldn't be sure if using an unexported function is the right way to go here, therefore I'm here for your help. Is there any other function provided by hunchentoot to have the same effect as WITH-FORM-FIELDS? If there isn't any, maybe others too would be happy to see this function coming default with hunchentoot. Regards. From edi at agharta.de Tue Apr 24 08:55:28 2007 From: edi at agharta.de (Edi Weitz) Date: Tue, 24 Apr 2007 10:55:28 +0200 Subject: [hunchentoot-devel] Accessor Function for Form Fields In-Reply-To: <87ejmc8edu.fsf@ttnet.net.tr> (Volkan YAZICI's message of "Sun, 22 Apr 2007 21:15:09 +0300") References: <87ejmc8edu.fsf@ttnet.net.tr> Message-ID: Hi, On Sun, 22 Apr 2007 21:15:09 +0300, Volkan YAZICI wrote: > I really like the way DEFINE-EASY-HANDLER works with supplied form > field parameters. But the problem with it is, IMHO, that you cannot > use DEFINE-EASY-HANDLER everywhere in the code when you want to > reach to a form variable. Therefore I come up with such a solution: > > (let ((default-parameter-type ''string) > (default-request-type :both)) > (defmacro with-form-fields ((&rest fields) &body body) > `(let ,(loop for field in fields > collect (hunchentoot::make-defun-parameter > field default-parameter-type default-request-type)) > , at body))) > > I couldn't be sure if using an unexported function is the right way > to go here, therefore I'm here for your help. Is there any other > function provided by hunchentoot to have the same effect as > WITH-FORM-FIELDS? No, not really. You could of course cook up something yourself but it'd be kind of re-inventing the wheel. > If there isn't any, maybe others too would be happy to see this > function coming default with hunchentoot. Yes, I think that makes sense. I'll add something like this to the next release. Thanks, Edi. From ocorrain at gmail.com Tue Apr 24 09:57:12 2007 From: ocorrain at gmail.com (Tiarnan O'Corrain) Date: Tue, 24 Apr 2007 10:57:12 +0100 Subject: [hunchentoot-devel] Accessor Function for Form Fields In-Reply-To: References: <87ejmc8edu.fsf@ttnet.net.tr> Message-ID: Hi-- I had something like: (defmacro with-parameters (parameters &body body) `(let ,(mapcar (lambda (p) `(,p (hunchentoot:parameter ,(string-downcase (symbol-name p))))) parameters) , at body)) (macroexpand-1 '(with-parameters (id title description) (format t "Id is ~A, title ~A, desc, ~A" id title description))) (LET ((ID (HUNCHENTOOT:PARAMETER "id")) (TITLE (HUNCHENTOOT:PARAMETER "title")) (DESCRIPTION (HUNCHENTOOT:PARAMETER "description"))) (FORMAT T "Id is ~A, title ~A, desc, ~A" ID TITLE DESCRIPTION)) regards T From yazicivo at ttnet.net.tr Wed Apr 25 23:01:38 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Thu, 26 Apr 2007 02:01:38 +0300 Subject: [hunchentoot-devel] URL-DECODE Problem with MultiByte (> 255) Characters Message-ID: <87y7kgoy7h.fsf@ttnet.net.tr> Hi, While I was trying to issue some regression tests over my URI path handling routine, I met with such a problem: ; Any character that's bigger than 255 reproduces the error. KARPUZ> (code-char 305) #\LATIN_SMALL_LETTER_DOTLESS_I KARPUZ> (wiki-path-to :filename (wiki-path-from :uri "/image/foo/yok art?k daha neler///.asd/&baz")) ; Evaluation aborted KARPUZ> (hunchentoot:url-decode (make-string 1 :initial-element (code-char 305)) (flex:make-external-format :utf8 :eol-style :lf)) The value 256 is not of type (UNSIGNED-BYTE 8). [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (SB-KERNEL:HAIRY-DATA-VECTOR-SET #() 0 256) Locals: SB-DEBUG::ARG-0 = 3 SB-DEBUG::ARG-1 = #() SB-DEBUG::ARG-2 = 0 SB-DEBUG::ARG-3 = 256 1: (VECTOR-PUSH 256 #()) Locals: SB-DEBUG::ARG-0 = 2 SB-DEBUG::ARG-1 = 256 SB-DEBUG::ARG-2 = #() 2: (URL-DECODE "?" #) Locals: HUNCHENTOOT::EXTERNAL-FORMAT = # STRING = "?" Would somebody help me to fix the error please? Regards. From xach at xach.com Wed Apr 25 23:05:07 2007 From: xach at xach.com (Zach Beane) Date: Wed, 25 Apr 2007 19:05:07 -0400 Subject: [hunchentoot-devel] URL-DECODE Problem with MultiByte (> 255) Characters In-Reply-To: <87y7kgoy7h.fsf@ttnet.net.tr> References: <87y7kgoy7h.fsf@ttnet.net.tr> Message-ID: <20070425230507.GC22346@xach.com> On Thu, Apr 26, 2007 at 02:01:38AM +0300, Volkan YAZICI wrote: > Hi, > > While I was trying to issue some regression tests over my URI path > handling routine, I met with such a problem: > > ; Any character that's bigger than 255 reproduces the error. > KARPUZ> (code-char 305) > #\LATIN_SMALL_LETTER_DOTLESS_I > KARPUZ> (wiki-path-to :filename (wiki-path-from :uri "/image/foo/yok art?k daha neler///.asd/&baz")) > ; Evaluation aborted > KARPUZ> (hunchentoot:url-decode > (make-string 1 :initial-element (code-char 305)) > (flex:make-external-format :utf8 :eol-style :lf)) [snip] > > Would somebody help me to fix the error please? URLs should have only ASCII characters. For other characters (and for special ASCII characters), you must use %XX escapes. Zach From ch-tbnl at bobobeach.com Thu Apr 26 18:28:29 2007 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 26 Apr 2007 11:28:29 -0700 Subject: [hunchentoot-devel] export make-lock and with-lock? Message-ID: Should hunchentoot export make-lock and with-lock? Thanks, Cyrus From edi at agharta.de Thu Apr 26 18:43:00 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 26 Apr 2007 20:43:00 +0200 Subject: [hunchentoot-devel] export make-lock and with-lock? In-Reply-To: (Cyrus Harmon's message of "Thu, 26 Apr 2007 11:28:29 -0700") References: Message-ID: On Thu, 26 Apr 2007 11:28:29 -0700, Cyrus Harmon wrote: > Should hunchentoot export make-lock and with-lock? http://weitz.de/hunchentoot/#ht-mp Hey, we talked about that in Cambridge already, didn't we? From ch-tbnl at bobobeach.com Thu Apr 26 18:46:14 2007 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 26 Apr 2007 11:46:14 -0700 Subject: [hunchentoot-devel] export make-lock and with-lock? In-Reply-To: References: Message-ID: <07C838C9-41E5-4C2D-A5D8-D67769350D27@bobobeach.com> Ah, right. Thanks for refreshing my memory. Cyrus On Apr 26, 2007, at 11:43 AM, Edi Weitz wrote: > On Thu, 26 Apr 2007 11:28:29 -0700, Cyrus Harmon tbnl at bobobeach.com> wrote: > >> Should hunchentoot export make-lock and with-lock? > > http://weitz.de/hunchentoot/#ht-mp > > Hey, we talked about that in Cambridge already, didn't we? > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From yazicivo at ttnet.net.tr Thu Apr 26 23:22:58 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Fri, 27 Apr 2007 02:22:58 +0300 Subject: [hunchentoot-devel] Accessor Function for Form Fields In-Reply-To: (Edi Weitz's message of "Tue\, 24 Apr 2007 10\:55\:28 +0200") References: <87ejmc8edu.fsf@ttnet.net.tr> Message-ID: <87tzv2sotp.fsf@ttnet.net.tr> Edi Weitz writes: >> If there isn't any, maybe others too would be happy to see this >> function coming default with hunchentoot. > > Yes, I think that makes sense. I'll add something like this to the > next release. Also, it will be really useful if we would be able to specify default values for parameter-type and request-type inside WITH-FORM-FIELDS. Regards. From yazicivo at ttnet.net.tr Fri Apr 27 21:13:33 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 00:13:33 +0300 Subject: [hunchentoot-devel] Boolean Form Fields Message-ID: <87bqh97c76.fsf@ttnet.net.tr> Hi, How do you use boolean type variables with DEFINE-EASY-HANDLER? (Or more generally how do you gather the results of boolean form fields?) Because, DEFINE-EASY-HANDLER binds related variable to nil even it doesn't exist. Therefore, it becomes impossible to learn if the parameter is supplied and its value is nil, or the parameter doesn't supplied within the request. Regards. From edi at agharta.de Fri Apr 27 21:52:52 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 27 Apr 2007 23:52:52 +0200 Subject: [hunchentoot-devel] Boolean Form Fields In-Reply-To: <87bqh97c76.fsf@ttnet.net.tr> (Volkan YAZICI's message of "Sat, 28 Apr 2007 00:13:33 +0300") References: <87bqh97c76.fsf@ttnet.net.tr> Message-ID: On Sat, 28 Apr 2007 00:13:33 +0300, Volkan YAZICI wrote: > How do you use boolean type variables with DEFINE-EASY-HANDLER? Usually with checkboxes. There's an example in the demo that comes with Hunchentoot. From vamlists at gmail.com Fri Apr 27 21:59:56 2007 From: vamlists at gmail.com (Vamsee Kanakala) Date: Sat, 28 Apr 2007 03:29:56 +0530 Subject: [hunchentoot-devel] export remove-session? Message-ID: <4632725C.3040509@gmail.com> Hi, I think exporting remove-session is a good idea - currently there isn't a reliable way to invalidate a current session, except for setting each session variable to nil (through session-value - or am I missing something obvious?). And setting *session* to nil doesn't seem to do this. Regards, Vamsee. From yazicivo at ttnet.net.tr Fri Apr 27 22:21:58 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 01:21:58 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: (Edi Weitz's message of "Fri\, 27 Apr 2007 23\:52\:52 +0200") References: <87bqh97c76.fsf@ttnet.net.tr> Message-ID: <874pn17915.fsf_-_@ttnet.net.tr> Edi Weitz writes: >> How do you use boolean type variables with DEFINE-EASY-HANDLER? > > Usually with checkboxes. There's an example in the demo that comes > with Hunchentoot. Yep, I have read test.lisp. But wouldn't it be better if we have some kind of exists-p key (as an available key in D-E-H lambda list, or returned by GET-PARAMETER and POST-PARAMETER) instead of using a hash table just for a single boolean? Regards. From edi at agharta.de Fri Apr 27 22:42:37 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 28 Apr 2007 00:42:37 +0200 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: <874pn17915.fsf_-_@ttnet.net.tr> (Volkan YAZICI's message of "Sat, 28 Apr 2007 01:21:58 +0300") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> Message-ID: On Sat, 28 Apr 2007 01:21:58 +0300, Volkan YAZICI wrote: > Yep, I have read test.lisp. But wouldn't it be better if we have > some kind of exists-p key (as an available key in D-E-H lambda list, > or returned by GET-PARAMETER and POST-PARAMETER) instead of using a > hash table just for a single boolean? I don't understand that question. There's a hash table in the demo because there are several checkboxes grouped together. If you only have one checkbox, you can of course just use 'BOOLEAN. From edi at agharta.de Fri Apr 27 22:47:47 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 28 Apr 2007 00:47:47 +0200 Subject: [hunchentoot-devel] export remove-session? In-Reply-To: <4632725C.3040509@gmail.com> (Vamsee Kanakala's message of "Sat, 28 Apr 2007 03:29:56 +0530") References: <4632725C.3040509@gmail.com> Message-ID: On Sat, 28 Apr 2007 03:29:56 +0530, Vamsee Kanakala wrote: > I think exporting remove-session is a good idea - currently there > isn't a reliable way to invalidate a current session, except for > setting each session variable to nil (through session-value - or am > I missing something obvious?). You're not missing anything, but usually (at least that's the way I'm using it) you have /one/ specific value in the session which controls its validity, i.e. you'd only have to delete this one value. (Note that deleting it is slightly different from setting it to NIL.) But I can export REMOVE-SESSION if people think that'd be useful. > And setting *session* to nil doesn't seem to do this. Of course not. This variable is only bound to the session object while the handler is active. From yazicivo at ttnet.net.tr Fri Apr 27 23:01:30 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 02:01:30 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: (Edi Weitz's message of "Sat\, 28 Apr 2007 00\:42\:37 +0200") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> Message-ID: <87wszx5smt.fsf_-_@ttnet.net.tr> Edi Weitz writes: > On Sat, 28 Apr 2007 01:21:58 +0300, Volkan YAZICI wrote: > I don't understand that question. There's a hash table in the demo > because there are several checkboxes grouped together. If you only > have one checkbox, you can of course just use 'BOOLEAN. If I'd use 'BOOLEAN, how can I know when the value of a boolean is NIL and when a boolean isn't supplied? Consider (foo :parameter-type :boolean :request-type :get) example. Both "foo.html" and "foo.html?foo=" returns NIL for FOO variable. IMHO, for the formal case, there should be an exist-p switch. Regards. From edi at agharta.de Fri Apr 27 23:06:58 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 28 Apr 2007 01:06:58 +0200 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: <87wszx5smt.fsf_-_@ttnet.net.tr> (Volkan YAZICI's message of "Sat, 28 Apr 2007 02:01:30 +0300") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> <87wszx5smt.fsf_-_@ttnet.net.tr> Message-ID: On Sat, 28 Apr 2007 02:01:30 +0300, Volkan YAZICI wrote: > If I'd use 'BOOLEAN, how can I know when the value of a boolean is > NIL and when a boolean isn't supplied? > > Consider (foo :parameter-type :boolean :request-type :get) > example. Both "foo.html" and "foo.html?foo=" returns NIL for FOO > variable. IMHO, for the formal case, there should be an exist-p > switch. Which browser sends requests that look like "foo.html?foo="? From yazicivo at ttnet.net.tr Sat Apr 28 10:56:06 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 13:56:06 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: (Edi Weitz's message of "Sat\, 28 Apr 2007 01\:06\:58 +0200") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> <87wszx5smt.fsf_-_@ttnet.net.tr> Message-ID: <87slak6a49.fsf@ttnet.net.tr> Edi Weitz writes: > Which browser sends requests that look like "foo.html?foo="? Consider I want to redirect client to auth.html with auth-res boolean parameter turned on. What should I pass as the URI? If I use "?auth-res=NIL" or "?auth-res=0", both of them returns T, because neither "NIL", nor "0" is NIL. Hence, I prefer to use "?auth-res=" But in this case, I cannot know if the boolean parameter is supplied and it's value is NIL, or the parameter isn't even supplied. (Because, in both situations it returns NIL.) I can cope with this problem, by making an extra (assoc 'auth-res (get-parameters)) probe everytime I need that verbosity. But wouldn't it be better just to specify a ":exist-p auth-res-exist-p" option in the lambda list of D-E-H. Regards. From yazicivo at ttnet.net.tr Sat Apr 28 12:08:20 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 15:08:20 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: <87slak6a49.fsf@ttnet.net.tr> (Volkan YAZICI's message of "Sat\, 28 Apr 2007 13\:56\:06 +0300") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> <87wszx5smt.fsf_-_@ttnet.net.tr> <87slak6a49.fsf@ttnet.net.tr> Message-ID: <87odl866rv.fsf@ttnet.net.tr> Volkan YAZICI writes: > Edi Weitz writes: >> Which browser sends requests that look like "foo.html?foo="? > > Consider I want to redirect client to auth.html with auth-res boolean > parameter turned on. What should I pass as the URI? If I use > "?auth-res=NIL" or "?auth-res=0", both of them returns T, because > neither "NIL", nor "0" is NIL. Hence, I prefer to use "?auth-res=" But > in this case, I cannot know if the boolean parameter is supplied and > it's value is NIL, or the parameter isn't even supplied. (Because, in > both situations it returns NIL.) Sorry, above assertion is mistaken. Hunchentoot returns T for boolean in all cases whenever auth-res exists in the GET parameters list. Therefore, it's not possible to make a distinction between a NIL (which means false) boolean parameter that is supplied and a parameter that isn't even supplied. (Please correct me if I'm wrong.) Regards. From yazicivo at ttnet.net.tr Sat Apr 28 18:23:55 2007 From: yazicivo at ttnet.net.tr (Volkan YAZICI) Date: Sat, 28 Apr 2007 21:23:55 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields References: <87bqh97c76.fsf@ttnet.net.tr> Message-ID: <87ejm45pdw.fsf@ttnet.net.tr> Volkan YAZICI writes: > Sorry, above assertion is mistaken. Hunchentoot returns T for boolean > in all cases whenever auth-res exists in the GET parameters > list. Therefore, it's not possible to make a distinction between a NIL > (which means false) boolean parameter that is supplied and a parameter > that isn't even supplied. (Please correct me if I'm wrong.) To clarify what I try to mean, here's an example: (define-easy-handler (auth :uri "/auth") ((result :parameter-type 'boolean :request-type :get)) (with-html (if result (htm (:p "Authentication succeeded.")) (htm (:p "Authentication failed!"))) (:p "Welcome!"))) Try this handler with "/auth?result=", "/auth?result=nil" URIs. In each case, RESULT will return T. So how can I tell /auth that I tried to authenticate the client but it's failed? (You may say that, just don't pass the `result' argument to URI. But that's not same as passing a boolean type of argument with NIL/FALSE value.) Here is my suggestion for this: --- /tmp/easy-handlers.lisp 2007-04-28 20:56:57.000000000 +0300 +++ easy-handlers.lisp 2007-04-28 20:51:29.000000000 +0300 @@ -52,7 +52,8 @@ (char argument 0))) (integer (ignore-errors (parse-integer argument :junk-allowed t))) (keyword (make-keyword argument :destructivep nil)) - (boolean t) + (boolean (not (or (string= argument "") + (string= (string-upcase argument) "NIL")))) (otherwise (funcall type argument)))) (defun compute-simple-parameter (parameter-name type parameter-reader) And, after that long discussion, I solved my problem again on my own: (defmacro with-form-fields ((&key (default-parameter-type ''string) (default-request-type :both)) (&rest fields) &body body) "Process specified lambda list similar to DEFINE-EASY-HANDLER. You can also use :EXISTS-P keyword to specify an extra parameter to ensure that the value is supplied in the request URI." `(let ;; Collect appropriate LET bindings for supplied fields. ,(nconc (loop for field in fields collect (hunchentoot::make-defun-parameter (if (listp field) (cons (first field) (delf (rest field) :exists-p)) field) default-parameter-type default-request-type)) ;; Collect :exists-p keyword variables. (loop for field in fields when (and (listp field) (getf (rest field) :exists-p)) collect (getf (rest field) :exists-p))) ;; Process :exists-p keywords. ,(with-gensyms (get-params post-params both-params) `(let* ((,get-params (get-parameters)) (,post-params (post-parameters)) (,both-params (nconc ,get-params ,post-params))) (declare (ignorable ,get-params)) (declare (ignorable ,post-params)) (declare (ignorable ,both-params)) ,@(loop for field in fields when (and (listp field) (getf (rest field) :exists-p)) collect `(setq ,(getf (rest field) :exists-p) (if (rest (assoc (string-downcase (symbol-name (quote ,(first field)))) ,(ecase (or (getf (rest field) :request-type) default-request-type) (:get get-params) (:post post-params) (:both both-params)) :test #'string=)) t))))) , at body)) Try to run above same handler example with below code. (with-form-fields () ((result :parameter-type 'boolean :request-type :get :exists-p result-exists-p)) (with-html (when (and result-exists-p (not result)) (htm (:p "Authentication failed!"))) (when result (htm (:p "Authentication succeeded."))) (:p "Welcome!"))) Excuse me if I disturb you with my own problems. Looks like everyone is comfortable with undetermined boolean values. Regards. From nowhere.man at levallois.eu.org Sat Apr 28 20:42:07 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Sat, 28 Apr 2007 22:42:07 +0200 Subject: [hunchentoot-devel] Accessor Function for Form Fields In-Reply-To: <87tzv2sotp.fsf@ttnet.net.tr> References: <87ejmc8edu.fsf@ttnet.net.tr> <87tzv2sotp.fsf@ttnet.net.tr> Message-ID: <20070428204207.GM10050@bateleur.arcanes.fr.eu.org> Scribit Volkan YAZICI dies 27/04/2007 hora 02:22: > Also, it will be really useful if we would be able to specify default > values for parameter-type and request-type inside WITH-FORM-FIELDS. I really think with-parameters is a better name than with-form-fields because what you access really are parameters, and nothing says they come from form fields. Taxonomically, 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 ch-tbnl at bobobeach.com Sat Apr 28 21:47:56 2007 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sat, 28 Apr 2007 14:47:56 -0700 Subject: [hunchentoot-devel] host/port question Message-ID: <7B32045B-D6FB-4E27-A245-82A75A8E797A@bobobeach.com> I'm not sure what "the right thing" here is, but it struck me as odd that redirect didn't include a port argument, so I made the following changes to redirect: --- hunchentoot-0.9.0/misc.lisp 2007-03-30 14:01:27.000000000 -0700 +++ ../hunchentoot-0.9.0/misc.lisp 2007-04-27 22:45:00.000000000 -0700 @@ -229,6 +229,7 @@ (add-session-id (not (or host-provided-p (starts-with- scheme-p target) (cookie-in *session-cookie-name*)))) + port permanently) "Redirects the browser to TARGET which should be a string. If TARGET is a full URL starting with a scheme, HOST and PROTOCOL @@ -240,11 +241,11 @@ otherwise a 302." (let ((url (if (starts-with-scheme-p target) target - (format nil "~A://~A~A" + (format nil "~A://~A~@[:~A~]~A" (ecase protocol ((:http) "http") ((:https) "https")) - host target)))) + host port target)))) (when add-session-id (setq url (add-cookie-value-to-url url :replace-ampersands-p nil))) (setf (header-out :location) but then I realized that what we call "host" here really is host:port. Should these two notions be more "decoupled" or should I just think host:port when I see host? Thanks, Cyrus From vamlists at gmail.com Sun Apr 29 05:49:57 2007 From: vamlists at gmail.com (Vamsee Kanakala) Date: Sun, 29 Apr 2007 11:19:57 +0530 Subject: [hunchentoot-devel] export remove-session? In-Reply-To: References: <4632725C.3040509@gmail.com> Message-ID: <8d2be40704282249m23005117m6b36be42cebfb821@mail.gmail.com> On 4/28/07, Edi Weitz wrote: > > > But I can export REMOVE-SESSION if people think that'd be useful. I'm not sure about others, but I think it would be helpful when multiple session variables are being set in different parts of the web app, when you could invalidate the entire session when a user logs out, instead of deleting each session variable - it's possible that the developer forgot to delete this particular session var in the logout method (this just happened to me :D). > And setting *session* to nil doesn't seem to do this. > > Of course not. This variable is only bound to the session object > while the handler is active. > Oops, I realized that a bit late :) Thanks, Vamsee. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Sun Apr 29 14:05:45 2007 From: edi at agharta.de (Edi Weitz) Date: Sun, 29 Apr 2007 16:05:45 +0200 Subject: [hunchentoot-devel] New release 0.9.1 (Was: host/port question) In-Reply-To: <7B32045B-D6FB-4E27-A245-82A75A8E797A@bobobeach.com> (Cyrus Harmon's message of "Sat, 28 Apr 2007 14:47:56 -0700") References: <7B32045B-D6FB-4E27-A245-82A75A8E797A@bobobeach.com> Message-ID: On Sat, 28 Apr 2007 14:47:56 -0700, Cyrus Harmon wrote: > Should these two notions be more "decoupled" or should I just think > host:port when I see host? I think it makes sense to allow for a separate PORT parameter. You can still provide "foo.com:4242" as the HOST argument, if you want. It's in the new release. Thanks, Edi. From edi at agharta.de Sun Apr 29 14:06:23 2007 From: edi at agharta.de (Edi Weitz) Date: Sun, 29 Apr 2007 16:06:23 +0200 Subject: [hunchentoot-devel] export remove-session? In-Reply-To: <8d2be40704282249m23005117m6b36be42cebfb821@mail.gmail.com> (Vamsee Kanakala's message of "Sun, 29 Apr 2007 11:19:57 +0530") References: <4632725C.3040509@gmail.com> <8d2be40704282249m23005117m6b36be42cebfb821@mail.gmail.com> Message-ID: On Sun, 29 Apr 2007 11:19:57 +0530, "Vamsee Kanakala" wrote: > I'm not sure about others, but I think it would be helpful when > multiple session variables are being set in different parts of the > web app, when you could invalidate the entire session when a user > logs out, instead of deleting each session variable - it's possible > that the developer forgot to delete this particular session var in > the logout method (this just happened to me :D). OK, it's exported in 0.9.1. From ignas.mikalajunas at gmail.com Sun Apr 29 18:24:00 2007 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Sun, 29 Apr 2007 21:24:00 +0300 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: <87ejm45pdw.fsf@ttnet.net.tr> References: <87bqh97c76.fsf@ttnet.net.tr> <87ejm45pdw.fsf@ttnet.net.tr> Message-ID: > Excuse me if I disturb you with my own problems. Looks like everyone > is comfortable with undetermined boolean values. Is it just me or there is no way to tell if the "checkbox was in the form and was not checked" vs "checkbox was not present in the form", browsers give identical requests in both cases. Most of the web frameworks I have seen seem to add a hidden field for such checkboxes that indicates whether there was a checkbox in the form being submitted. Which I am afraid you can only do on your own with hunchentoot. Ignas From penguin at ocean.vvo.ru Sun Apr 29 20:03:54 2007 From: penguin at ocean.vvo.ru (Igor Plekhov) Date: Mon, 30 Apr 2007 07:03:54 +1100 Subject: [hunchentoot-devel] Re: Boolean Form Fields In-Reply-To: References: <87bqh97c76.fsf@ttnet.net.tr> <87ejm45pdw.fsf@ttnet.net.tr> Message-ID: <20070429200354.GC15416@ocean.vvo.ru> On Sun, 29 Apr, 2007 at 21:24:00 +0300, Ignas Mikalajunas wrote: > > Is it just me or there is no way to tell if the "checkbox was in > the form and was not checked" vs "checkbox was not present in the > form", browsers give identical requests in both cases. http://www.w3.org/TR/PR-html40-971107/interact/forms.html#h-17.8.2 For INPUT elements with type="radio" or type="checkbox", and SELECT elements, only the selected values should be submitted. -- Registered Linux User #124759 From info at jensteich.de Mon Apr 30 11:41:00 2007 From: info at jensteich.de (Jens Teich) Date: Mon, 30 Apr 2007 13:41:00 +0200 Subject: [hunchentoot-devel] Connection to Postgres via Postmodern with Unicode References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> <87wszx5smt.fsf_-_@ttnet.net.tr> <87slak6a49.fsf@ttnet.net.tr> <87odl866rv.fsf@ttnet.net.tr> Message-ID: <006101c78b1c$6e7c6620$6f02a8c0@JensSony> Lispworks 5.02, WinXP Everything working in the listener: | (postmodern:with-connection ("web_access" | "web_access" | "xxx" | "localhost") | (postmodern:query | "select * from merkmale limit 10")) | (("g5p7327541ptj4diy19363553jh3yx " | "de" | "5yt732754w29gt8xhve36355ormaci | ... | 70 | " . hohe Kontaktsicherheit bei niedrigen Str?men " | .......^.........................................^ | ... But the same thing in the web using an easy-handler | (define-easy-handler (test :uri (prefixed "test"))() | (with-html-output-to-string (out) | (postmodern:with-connection ("web_access" | "web_access" | "xxx" | "localhost") | (htm | (:html (:head (:title "Testpage")) | (:body (:p (fmt "~a" | (postmodern:query | "select * from merkmale limit 10"))))))))) works fine unless higher unicode characters are involved. Empty page in the browser then, no error. Simply a blank page. -jens From edi at agharta.de Mon Apr 30 14:27:38 2007 From: edi at agharta.de (Edi Weitz) Date: Mon, 30 Apr 2007 16:27:38 +0200 Subject: [hunchentoot-devel] Connection to Postgres via Postmodern with Unicode In-Reply-To: <006101c78b1c$6e7c6620$6f02a8c0@JensSony> (Jens Teich's message of "Mon, 30 Apr 2007 13:41:00 +0200") References: <87bqh97c76.fsf@ttnet.net.tr> <874pn17915.fsf_-_@ttnet.net.tr> <87wszx5smt.fsf_-_@ttnet.net.tr> <87slak6a49.fsf@ttnet.net.tr> <87odl866rv.fsf@ttnet.net.tr> <006101c78b1c$6e7c6620$6f02a8c0@JensSony> Message-ID: On Mon, 30 Apr 2007 13:41:00 +0200, "Jens Teich" wrote: > But the same thing in the web using an easy-handler > > | (define-easy-handler (test :uri (prefixed "test"))() > | (with-html-output-to-string (out) > | (postmodern:with-connection ("web_access" > | "web_access" > | "xxx" > | "localhost") > | (htm > | (:html (:head (:title "Testpage")) > | (:body (:p (fmt "~a" > | (postmodern:query > | "select * from merkmale limit 10"))))))))) Where do you set the content type header? > works fine unless higher unicode characters are involved. > > Empty page in the browser then, no error. Simply a blank page. Log file? Did you try *CATCH-ERRORS-P*?