From krz at cis.rit.edu Fri Nov 6 03:33:59 2009 From: krz at cis.rit.edu (Bob Krzaczek) Date: Thu, 05 Nov 2009 22:33:59 -0500 Subject: [hunchentoot-devel] Scieneer Common Lisp Message-ID: <4AF39927.4030108@cis.rit.edu> Hi, I'm happy to say that I've managed to get most of Hunchentoot up and running on Scieneer Common Lisp (Solaris 10, SPARC, 64 bit) today, with fairly minimal tweaks to its dependencies' sources. Still, I've run into some problems. A handful of the hunchentoot-test pages are coming back with HTTP's Bad Request. So, although it's very promising, it isn't all quite there yet. Anyway, the main reason I'm writing to the list is to ask if anyone else is working on SCL, before I attack this in earnest tomorrow? I just didn't want to step on toes, or duplicate someone else's effort. Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz at cis.rit.edu, icbm 43.0848N 77.6789W From quasilists at gmail.com Fri Nov 6 17:43:15 2009 From: quasilists at gmail.com (quasi) Date: Fri, 6 Nov 2009 23:13:15 +0530 Subject: [hunchentoot-devel] No REPL after hunchentoot:start Message-ID: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> Hey, I do not get the Slime REPL back after I start the webserver (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with snow leopard. It works with Allegro 8.1. Am I missing something trivial here? thanks for the help, regards quasi From xach at xach.com Fri Nov 6 18:31:43 2009 From: xach at xach.com (Zach Beane) Date: Fri, 6 Nov 2009 13:31:43 -0500 Subject: [hunchentoot-devel] No REPL after hunchentoot:start In-Reply-To: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> References: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> Message-ID: <20091106183143.GU16138@xach.com> On Fri, Nov 06, 2009 at 11:13:15PM +0530, quasi wrote: > Hey, > > I do not get the Slime REPL back after I start the webserver > > (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) > > I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with > snow leopard. > > It works with Allegro 8.1. > > Am I missing something trivial here? Did you compile SBCL with thread support? Zach From andy.arvid at gmail.com Fri Nov 6 18:24:45 2009 From: andy.arvid at gmail.com (Andrew Peterson) Date: Fri, 6 Nov 2009 15:24:45 -0300 Subject: [hunchentoot-devel] No REPL after hunchentoot:start In-Reply-To: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> References: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> Message-ID: <30b9bbc50911061024u4dba177v70d86cdc07b05ef0@mail.gmail.com> Check global variable *features* It should have :sb-thread in the list of features. If not, you will need to compile sbcl from the source with threads enabled. andy On Fri, Nov 6, 2009 at 2:43 PM, quasi wrote: > Hey, > > I do not get the Slime REPL back after I start the webserver > > (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) > > I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with > snow leopard. > > It works with Allegro 8.1. > > Am I missing something trivial here? > > thanks for the help, > > regards > quasi > > _______________________________________________ > 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 quasilists at gmail.com Fri Nov 6 21:16:23 2009 From: quasilists at gmail.com (quasi) Date: Sat, 7 Nov 2009 02:46:23 +0530 Subject: [hunchentoot-devel] No REPL after hunchentoot:start In-Reply-To: <20091106183143.GU16138@xach.com> References: <438e11130911060943j706ed73ai4feeb1e48b952c2@mail.gmail.com> <20091106183143.GU16138@xach.com> Message-ID: <438e11130911061316x69ffc032s97419a503bdeec6c@mail.gmail.com> On Sat, Nov 7, 2009 at 12:01 AM, Zach Beane wrote: >> Am I missing something trivial here? > > Did you compile SBCL with thread support? > eeek. I was using the 1.0.29 binaries without thread support. :( my bad. sorry. thanks! quasi From frode at netfonds.no Mon Nov 9 14:48:06 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Mon, 09 Nov 2009 15:48:06 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type Message-ID: <821vk7oiu1.fsf@netfonds.no> Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me. It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory. TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2" Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned. -- Frode V. Fjeld From edi at agharta.de Mon Nov 9 21:11:46 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 9 Nov 2009 22:11:46 +0100 Subject: [hunchentoot-devel] Scieneer Common Lisp In-Reply-To: <4AF39927.4030108@cis.rit.edu> References: <4AF39927.4030108@cis.rit.edu> Message-ID: Seems nobody is working on this, so if you can provide patches which are necessary to make Hunchentoot run on SCL, that'll be fine. Please read this first, though: http://weitz.de/patches.html Thanks, Edi. On Fri, Nov 6, 2009 at 4:33 AM, Bob Krzaczek wrote: > Hi, > > I'm happy to say that I've managed to get most of Hunchentoot up and > running on Scieneer Common Lisp (Solaris 10, SPARC, 64 bit) today, with > fairly minimal tweaks to its dependencies' sources. > > Still, I've run into some problems. ?A handful of the hunchentoot-test > pages are coming back with HTTP's Bad Request. ?So, although it's very > promising, it isn't all quite there yet. > > Anyway, the main reason I'm writing to the list is to ask if anyone else > is working on SCL, before I attack this in earnest tomorrow? ?I just > didn't want to step on toes, or duplicate someone else's effort. > > Cheers, > Bob > > > -- > Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT > phone +1-585-4757196, email krz at cis.rit.edu, icbm 43.0848N 77.6789W > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Mon Nov 9 21:21:36 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 9 Nov 2009 22:21:36 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: <821vk7oiu1.fsf@netfonds.no> References: <821vk7oiu1.fsf@netfonds.no> Message-ID: What OS are you on? I just checked and this seems to work as expected on my machine with LWW and LWL. Also, how exactly did you specify/generate the value for base-path? Cheers, Edi. On Mon, Nov 9, 2009 at 3:48 PM, Frode V. Fjeld wrote: > Hi, I'm rather new to both hunchentoot and lispworks, so please bear > with me. > > It seems to me that the function create-folder-dispatcher-and-handler > uses the test (or (pathname-name base-path) (pathname-type base-path)) > to see if base-path is indeed a directory. This fails on my system > because both pathname accessors return :UNSPECIFIC, where base-path > indeed names a directory. > > TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) > "LispWorks" > "5.1.2" > > Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, > NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get > from hunchentoot. I had to modify the hunchentoot code to print the > results from pathname-name to see that :UNSPECIFIC was returned. > > -- > Frode V. Fjeld > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From frode at netfonds.no Tue Nov 10 08:18:13 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Tue, 10 Nov 2009 09:18:13 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> Message-ID: <82ws1yn67u.fsf@netfonds.no> Hi Edi, I'm on Linux/Ubuntu 9.10 i386-64. The problem occurred while trying to get weblocks-demo up and running. That is, this specific problem seems to occur (most consistently) when I purposely request a non-existing URL after having loaded and started weblocks-demo. After haveing tweaked hunchentoot slightly to expose the problem more, I'm seeing the call-stack below. #P"/home/frode/cvs/lib/asdf/weblocks/pub/" is indeed an existing directory. And, funnily enough: TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") (pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) NIL NIL ..whereas they both return :UNSPECIFIC for the actual base-path, as you can gather from the stack below. Could it be that weblocks somehow creates the pathname object the wrong way? #P"/home/frode/cvs/lib/asdf/weblocks/pub/" is supposed to denote a directory. :UNSPECIFIC :UNSPECIFIC [Condition of type HUNCHENTOOT:PARAMETER-ERROR] Restarts: 0: [ABORT] Quit process. Backtrace: 0: (SUBFUNCTION 2 (METHOD HUNCHENTOOT:PROCESS-REQUEST (T))) (#) 1: SIGNAL (# &REST NIL) 2: CONDITIONS::CONDITIONS-ERROR (:INVISIBLEP ..) 3: ERROR (HUNCHENTOOT:PARAMETER-ERROR &REST (:FORMAT-CONTROL "~S is supposed to denote a directory. ~S ~S" :FORMAT-ARGUMENTS (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC))) 4: HUNCHENTOOT:PARAMETER-ERROR ("~S is supposed to denote a directory. ~S ~S" &REST (#P"/home/frode/cvs/lib/asdf/weblocks/pub/" :UNSPECIFIC :UNSPECIFIC)) 5: HUNCHENTOOT:CREATE-FOLDER-DISPATCHER-AND-HANDLER ("/weblocks-common/pub/" #P"/home/frode/cvs/lib/asdf/weblocks/pub/" &OPTIONAL NIL) 6: WEBLOCKS::WEBLOCKS-DISPATCHER (#) 7: HUNCHENTOOT::LIST-REQUEST-DISPATCHER (#) 8: (METHOD HUNCHENTOOT:PROCESS-REQUEST (T)) (#) 9: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (HUNCHENTOOT:ACCEPTOR T)) (# 8) 10: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) ..) 11: (METHOD HUNCHENTOOT:PROCESS-CONNECTION (WEBLOCKS:WEBLOCKS-ACCEPTOR T)) (# 8) 12: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 13: CLOS::NEXT-METHOD-CALL-2 ((METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) ..) 14: (METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND (HUNCHENTOOT:ACCEPTOR T)) (# 8) 15: CLOS::METHOD-COMBINATION-TEMPLATE (:INVISIBLEP T) 16: (SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) (:DONT-KNOW) 17: SYSTEM::%%FIRST-CALL-TO-STACK NIL Thanks, Frode Edi Weitz writes: > What OS are you on? I just checked and this seems to work as expected > on my machine with LWW and LWL. > > Also, how exactly did you specify/generate the value for base-path? > > Cheers, > Edi. > > On Mon, Nov 9, 2009 at 3:48 PM, Frode V. Fjeld wrote: >> Hi, I'm rather new to both hunchentoot and lispworks, so please bear >> with me. >> >> It seems to me that the function create-folder-dispatcher-and-handler >> uses the test (or (pathname-name base-path) (pathname-type base-path)) >> to see if base-path is indeed a directory. This fails on my system >> because both pathname accessors return :UNSPECIFIC, where base-path >> indeed names a directory. >> >> TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) >> "LispWorks" >> "5.1.2" >> >> Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, >> NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get >> from hunchentoot. I had to modify the hunchentoot code to print the >> results from pathname-name to see that :UNSPECIFIC was returned. >> >> -- >> Frode V. Fjeld >> >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> >> > From edi at agharta.de Tue Nov 10 08:37:44 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Nov 2009 09:37:44 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: <82ws1yn67u.fsf@netfonds.no> References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> Message-ID: On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld wrote: > TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") > ? ? ? ? ? ? ?(pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) > NIL > NIL Yes, that is what I would expect. > ..whereas they both return :UNSPECIFIC for the actual base-path, as you > can gather from the stack below. Could it be that weblocks somehow > creates the pathname object the wrong way? That would be my guess. I'm not familiar with weblocks, though. Cheers, Edi. From sky at viridian-project.de Tue Nov 10 09:04:37 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 10 Nov 2009 10:04:37 +0100 (CET) Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> Message-ID: Edi Weitz wrote: > On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld wrote: > >> TBNL> (values (pathname-name #P"/home/frode/cvs/lib/asdf/weblocks/pub/") >> ? ? ? ? ? ? ?(pathname-type #P"/home/frode/cvs/lib/asdf/weblocks/pub/")) >> NIL >> NIL > > Yes, that is what I would expect. > >> ..whereas they both return :UNSPECIFIC for the actual base-path, as you >> can gather from the stack below. Could it be that weblocks somehow >> creates the pathname object the wrong way? > > That would be my guess. I'm not familiar with weblocks, though. I've missed that the OP was using Weblocks. We've had pathname issues with Lispworks in the past, and they might still be in the stable branch. I suggest to try weblocks-dev to see if this has been resolved and write to the Weblocks list if it hasn't. Leslie -- http://www.linkedin.com/in/polzer From frode at netfonds.no Tue Nov 10 09:09:42 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Tue, 10 Nov 2009 10:09:42 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> Message-ID: <82skcmn3u1.fsf@netfonds.no> On Tue, Nov 10, 2009 at 9:18 AM, Frode V. Fjeld wrote: >> ..whereas they both return :UNSPECIFIC for the actual base-path, as you >> can gather from the stack below. Could it be that weblocks somehow >> creates the pathname object the wrong way? Edi Weitz writes: > That would be my guess. I'm not familiar with weblocks, though. It appears that the root cause is this effect: TBNL> (values (pathname-type #p"/tmp") (pathname-type (probe-file #p"/tmp"))) NIL :UNSPECIFIC (Btw. sbcl will return NIL for both.) It's unclear to me what the semantics of NIL vs. :UNSPECIFIC is supposed to be, and so whether it's weblocks or hunchentoot (or both?) that needs to be tweaked. -- Frode V. Fjeld From frode at netfonds.no Tue Nov 10 10:06:45 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Tue, 10 Nov 2009 11:06:45 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> Message-ID: <82fx8mn16y.fsf@netfonds.no> "Leslie P. Polzer" writes: > I've missed that the OP was using Weblocks. We've had pathname issues > with Lispworks in the past, and they might still be in the stable > branch. I didn't suspect it was a weblocks issue at first. > I suggest to try weblocks-dev to see if this has been resolved and > write to the Weblocks list if it hasn't. I tried weblocks-dev, and the problem appears to remain. I also made a post to the Weblocks list about this. However, I think I finally found the relevant section of the CLHS: > 19.2.2.2.3 :UNSPECIFIC as a Component Value > If :unspecific is the value of a pathname component, the component is > considered to be ``absent'' or to ``have no meaning'' in the filename > being represented by the pathname. > [...] > When reading[1] the value of any pathname component, conforming > programs should be prepared for the value to be :unspecific. The last paragraph indicates to me that the correct resolution would be for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..? -- Frode V. Fjeld From edi at agharta.de Tue Nov 10 12:07:15 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Nov 2009 13:07:15 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: <82fx8mn16y.fsf@netfonds.no> References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> Message-ID: On Tue, Nov 10, 2009 at 11:06 AM, Frode V. Fjeld wrote: > The last paragraph indicates to me that the correct resolution would be > for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..? Yes, that sounds reasonable. I'll change that in the BKNR repository. Thanks, Edi. From frode at netfonds.no Tue Nov 10 13:32:09 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Tue, 10 Nov 2009 14:32:09 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> Message-ID: <82ws1yld46.fsf@netfonds.no> On Tue, Nov 10, 2009 at 11:06 AM, Frode V. Fjeld wrote: >> The last paragraph indicates to me that the correct resolution would be >> for hunchentoot to be prepared to see either NIL or :UNSPECIFIC ..? Edi Weitz writes: > Yes, that sounds reasonable. I'll change that in the BKNR repository. That's excellent. Thank you. -- Frode V. Fjeld From sebyte at smolny.plus.com Tue Nov 10 13:52:02 2009 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 10 Nov 2009 13:52:02 +0000 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> Message-ID: <1vk6a3nh.fsf@vps203.linuxvps.org> Quoth Edi Weitz : > I'll change that in the BKNR repository. Is the bknr repository the canonical location for hunchentoot development work and if so, is there any reason why it isn't used by clbuild? Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From edi at agharta.de Tue Nov 10 14:24:50 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Nov 2009 15:24:50 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: <1vk6a3nh.fsf@vps203.linuxvps.org> References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> <1vk6a3nh.fsf@vps203.linuxvps.org> Message-ID: On Tue, Nov 10, 2009 at 2:52 PM, Sebastian Tennant wrote: > Is the bknr repository the canonical location for hunchentoot development work > and if so, is there any reason why it isn't used by clbuild? It currently is and has been so for almost a year, I think. And as long as Hans doesn't want to get rid of me, I don't expect this to change any time soon. I can't answer the question about clbuild. From sebyte at smolny.plus.com Tue Nov 10 16:08:09 2009 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 10 Nov 2009 16:08:09 +0000 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> <1vk6a3nh.fsf@vps203.linuxvps.org> Message-ID: Quoth Edi Weitz : > I can't answer the question about clbuild. How about this question then.. do you want clbuild users to use the development version of hunchentoot or static timed releases (as is the case at the moment)? A simple email to the clbuild mailing list and they will change the download location. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From edi at agharta.de Tue Nov 10 16:29:31 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Nov 2009 17:29:31 +0100 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type In-Reply-To: References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> <1vk6a3nh.fsf@vps203.linuxvps.org> Message-ID: On Tue, Nov 10, 2009 at 5:08 PM, Sebastian Tennant wrote: > How about this question then.. do you want clbuild users to use the development > version of hunchentoot or static timed releases (as is the case at the > moment)? I think I'd prefer them to use released versions. Those who want to live on the bleeding edge, should decide for themselves and be prepared to read the mailing list. From sebyte at smolny.plus.com Tue Nov 10 17:03:31 2009 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Tue, 10 Nov 2009 17:03:31 +0000 Subject: [hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type References: <821vk7oiu1.fsf@netfonds.no> <82ws1yn67u.fsf@netfonds.no> <82fx8mn16y.fsf@netfonds.no> <1vk6a3nh.fsf@vps203.linuxvps.org> Message-ID: Quoth Edi Weitz : > I think I'd prefer them to use released versions. Those who want to > live on the bleeding edge, should decide for themselves and be > prepared to read the mailing list. As I suspected. Thanks for the confirmation. Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From j.k.cunningham at comcast.net Fri Nov 13 03:33:12 2009 From: j.k.cunningham at comcast.net (Jeff Cunningham) Date: Thu, 12 Nov 2009 19:33:12 -0800 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? Message-ID: <4AFCD378.9060007@comcast.net> I'm looking into setting up a Hunchentoot server on an OpenBSD system and right away noticed problems in the notes about building threads into SBCL (it sounds experimental). Lack of thread support would be a problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If so, were you able to use SBCL? If not, what did you use? Thanks. --Jeff From hans.huebner at gmail.com Fri Nov 13 06:29:47 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 13 Nov 2009 07:29:47 +0100 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? In-Reply-To: <4AFCD378.9060007@comcast.net> References: <4AFCD378.9060007@comcast.net> Message-ID: On Fri, Nov 13, 2009 at 04:33, Jeff Cunningham wrote: > I'm looking into setting up a Hunchentoot server on an OpenBSD system > and right away noticed problems in the notes about building threads into > SBCL (it sounds experimental). Lack of thread support would be a > problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If > so, were you able to use SBCL? If not, what did you use? I have not run Lisp on OpenBSD, but here is some advice anyway: Running Hunchentoot in a single threaded Lisp is not generally a problem for low-volume sites. I would decouple the Lisp server from clients using a HTTP proxy so that slow clients can't easily stall the server. I generally use squid (http://www.squid-cache.org/) for that purpose, but there are a host of other options. When evaluating http proxies last time, I have not been able to find one that supports single threaded backend servers well: In such a configuration, it would generally be preferable to queue requests in the front end process and perform precise scheduling of backend requests. None of the http proxies I looked at (squid, nginix, varnish) supported that.at the time. From j.k.cunningham at comcast.net Fri Nov 13 15:52:56 2009 From: j.k.cunningham at comcast.net (Jeff Cunningham) Date: Fri, 13 Nov 2009 07:52:56 -0800 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? In-Reply-To: References: <4AFCD378.9060007@comcast.net> Message-ID: <4AFD80D8.7080403@comcast.net> Thank you, Hans. I will take a look at that. I wouldn't have thought of that problem. Fortunately, it will be a low-volume site. --Jeff Hans H?bner wrote: > On Fri, Nov 13, 2009 at 04:33, Jeff Cunningham > wrote: > >> I'm looking into setting up a Hunchentoot server on an OpenBSD system >> and right away noticed problems in the notes about building threads into >> SBCL (it sounds experimental). Lack of thread support would be a >> problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If >> so, were you able to use SBCL? If not, what did you use? >> > > I have not run Lisp on OpenBSD, but here is some advice anyway: > Running Hunchentoot in a single threaded Lisp is not generally a > problem for low-volume sites. I would decouple the Lisp server from > clients using a HTTP proxy so that slow clients can't easily stall the > server. > > I generally use squid (http://www.squid-cache.org/) for that purpose, > but there are a host of other options. When evaluating http proxies > last time, I have not been able to find one that supports single > threaded backend servers well: In such a configuration, it would > generally be preferable to queue requests in the front end process and > perform precise scheduling of backend requests. None of the http > proxies I looked at (squid, nginix, varnish) supported that.at the > time. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From mjcurry at gmail.com Fri Nov 13 15:41:39 2009 From: mjcurry at gmail.com (Matthew Curry) Date: Fri, 13 Nov 2009 10:41:39 -0500 Subject: [hunchentoot-devel] PATCH: cl-webdav using the newer condition from the flexi-streams package Message-ID: <75b4567b0911130741m5ef0cf81tfca6775c23be258a@mail.gmail.com> flexi-streams package changed the name of the condition: flexi-stream-encoding-error to external-format-encoding-error Patch to cl-webdav attached. -Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: use-new-condition.patch Type: application/octet-stream Size: 402 bytes Desc: not available URL: From frode at netfonds.no Fri Nov 13 16:37:48 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Fri, 13 Nov 2009 17:37:48 +0100 Subject: [hunchentoot-devel] Invoke-debugger Message-ID: <823a4ibctf.fsf@yax.netfonds.no> There are numerous options for what to do when an error occurs while processing a hunchentoot request. But unless I'm missing something, there's no option to (effectively) call invoke-debugger? While developing and debugging, I find this to seeing a log message etc. It's rather easy to modify the standard process-request to call invoke-debugger, but wouldn't it make sense to have something like hunchentoot:*invoke-debugger-on-error-p* ? -- Frode V. Fjeld From hans.huebner at gmail.com Fri Nov 13 16:45:41 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 13 Nov 2009 17:45:41 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: <823a4ibctf.fsf@yax.netfonds.no> References: <823a4ibctf.fsf@yax.netfonds.no> Message-ID: On Fri, Nov 13, 2009 at 17:37, Frode V. Fjeld wrote: > It's rather easy to modify the standard process-request to call > invoke-debugger, but wouldn't it make sense to have something like > hunchentoot:*invoke-debugger-on-error-p* ? This is a common question which has been discussed a number of times. We've meant to put some debugging hints into the documentation, yet we've failed to do so, sorry about that. The answer is: Use *break-on-signals* to have your Lisp enter the debugger when a certain condition type is signalled. See http://l1sp.org/cl/*break-on-signals* for details. Hunchentoot used to have a special variable like you suggested, but we felt that it is better to use the language facilities rather than to invent special purpose mechanisms. Learning how to use *break-on-signals* is something that is useful anyway, so please try it out to see if it fits your needs. From peter at gigamonkeys.com Fri Nov 13 17:10:21 2009 From: peter at gigamonkeys.com (Peter Seibel) Date: Fri, 13 Nov 2009 09:10:21 -0800 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: References: <823a4ibctf.fsf@yax.netfonds.no> Message-ID: <40e4e7e50911130910u77e68e68t8a85df0c10cc74af@mail.gmail.com> On Fri, Nov 13, 2009 at 8:45 AM, Hans H?bner wrote: > On Fri, Nov 13, 2009 at 17:37, Frode V. Fjeld wrote: >> It's rather easy to modify the standard process-request to call >> invoke-debugger, but wouldn't it make sense to have something like >> hunchentoot:*invoke-debugger-on-error-p* ? > > This is a common question which has been discussed a number of times. > We've meant to put some debugging hints into the documentation, yet > we've failed to do so, sorry about that. > > The answer is: ?Use *break-on-signals* to have your Lisp enter the > debugger when a certain condition type is signalled. ?See > http://l1sp.org/cl/*break-on-signals* for details. > > Hunchentoot used to have a special variable like you suggested, but we > felt that it is better to use the language facilities rather than to > invent special purpose mechanisms. ?Learning how to use > *break-on-signals* is something that is useful anyway, so please try > it out to see if it fits your needs. In case *break-on-signals* doesn't meet your needs (for instance, if there are a lot of errors that get signaled and handled that can't be distinguished by type from the errors you want to go into the debugger on, you can also use something like this code which I got from someone on #lisp (antifuch's maybe?) ;;; An acceptor that invokes the debugger on errors: (defclass debuggable-acceptor (hunchentoot:acceptor) ()) (defvar *debug-connections* nil) (defmethod process-connection ((*acceptor* debuggable-acceptor) (socket t)) (declare (ignore socket)) (if *debug-connections* (handler-bind ((error #'invoke-debugger)) (call-next-method)) (call-next-method))) (defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) (let ((dispatcher (call-next-method))) (lambda (request) (handler-bind ((error #'invoke-debugger)) (funcall dispatcher request))))) Then start your Hunchentoot instance with something like: (start (make-instance 'debuggable-acceptor :port whatever)) -Peter > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/ From frode at netfonds.no Fri Nov 13 17:41:44 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Fri, 13 Nov 2009 18:41:44 +0100 Subject: [hunchentoot-devel] Invoke-debugger References: <823a4ibctf.fsf@yax.netfonds.no> Message-ID: <82y6ma9vaf.fsf@yax.netfonds.no> > On Fri, Nov 13, 2009 at 17:37, Frode V. Fjeld wrote: >> It's rather easy to modify the standard process-request to call >> invoke-debugger, but wouldn't it make sense to have something like >> hunchentoot:*invoke-debugger-on-error-p* ? Hans H?bner writes: > The answer is: Use *break-on-signals* [..] Right, I did have the feeling that "I must be missing something here" :-) I actually knew of *break-on-signals* (having implemented it, even), I just didn't think of it. Thanks, -- Frode V. Fjeld From sky at viridian-project.de Fri Nov 13 18:08:16 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Fri, 13 Nov 2009 19:08:16 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: <82y6ma9vaf.fsf@yax.netfonds.no> References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> Message-ID: <20091113180816.GA10352@viridian-project.de> > Hans H?bner writes: > > > The answer is: Use *break-on-signals* [..] > > Right, I did have the feeling that "I must be missing something here" > :-) I actually knew of *break-on-signals* (having implemented it, > even), I just didn't think of it. I thought by now everyone would've realized that *break-on-signals* isn't the right tool here. Not every signal is an error, and not every error bubbles up to the toplevel. Leslie From frode at netfonds.no Fri Nov 13 18:36:47 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Fri, 13 Nov 2009 19:36:47 +0100 Subject: [hunchentoot-devel] Invoke-debugger References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> Message-ID: <82tywy9sqo.fsf@yax.netfonds.no> "Leslie P. Polzer" writes: > Not every signal is an error, and not every error bubbles up to the > toplevel. Hm.. that is a valid point (or two). The switch should control whether hunchentoot's handler-bind should "decline" to handle the condition or not (i.e. whether to execute the THROW form). Not that I see many (signal 'error) in practice.. Also, looking at the relevant snippet of process-request, it strikes me as slightly odd that CATCH/THROW is used rather than BLOCK/RETURN-FROM. I think the latter is correct because it seems to me a lexical control transfer is intended. I'm unsure if the difference is anything but academic, though :-) -- Frode V. Fjeld From edi at agharta.de Fri Nov 13 19:49:13 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 13 Nov 2009 20:49:13 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: <20091113180816.GA10352@viridian-project.de> References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> Message-ID: On Fri, Nov 13, 2009 at 7:08 PM, Leslie P. Polzer wrote: > Not every signal is an error *break-on-signals* doesn't force you to break on every signal. From peter at gigamonkeys.com Fri Nov 13 23:02:12 2009 From: peter at gigamonkeys.com (Peter Seibel) Date: Fri, 13 Nov 2009 15:02:12 -0800 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> Message-ID: <40e4e7e50911131502m4cdfbf12x3a04639044328c9a@mail.gmail.com> On Fri, Nov 13, 2009 at 11:49 AM, Edi Weitz wrote: > On Fri, Nov 13, 2009 at 7:08 PM, Leslie P. Polzer > wrote: > >> Not every signal is an error > > *break-on-signals* doesn't force you to break on every signal. But it does force you, unless I'm deeply misunderstanding something, to break on every signal matching the type spec your specify, regardless of whether the error would have been handled by some higher level handler. E.g. CL-USER> (define-condition my-condition () ()) MY-CONDITION CL-USER> (defun foo () (signal 'my-condition)) FOO CL-USER> (foo) NIL CL-USER> (defun bar () (handler-case (foo) (my-condition () (format t "Handling my condition.")))) BAR CL-USER> (bar) Handling my condition. NIL CL-USER> (setq *break-on-signals* 'my-condition) MY-CONDITION CL-USER> (bar) ===> goes to debugger ; Evaluation aborted. CL-USER> -Peter -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/ From frode at netfonds.no Sat Nov 14 08:22:07 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Sat, 14 Nov 2009 09:22:07 +0100 Subject: [hunchentoot-devel] Invoke-debugger References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> Message-ID: <82ocn5a53k.fsf@yax.netfonds.no> Edi Weitz writes: > *break-on-signals* doesn't force you to break on every signal. One simple use-case I believe where the *break-on-signals* approach is inappropriate is if some response is computed by means of e.g. (if (ignore-errors (try-or-fail ...)) "It worked!" "Something went wrong.") I would typically not want the debugger on every error signaled by try-or-fail, but I believe *break-on-signals* set to e.g. "error" would force that to happen. Try-or-fail might be deep inside some library whose implementation I don't care about, or even inside of the lisp implementation itself. -- Frode V. Fjeld From hans.huebner at gmail.com Sat Nov 14 08:37:06 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 14 Nov 2009 09:37:06 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: <82ocn5a53k.fsf@yax.netfonds.no> References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> <82ocn5a53k.fsf@yax.netfonds.no> Message-ID: On Sat, Nov 14, 2009 at 09:22, Frode V. Fjeld wrote: > Edi Weitz writes: > >> *break-on-signals* doesn't force you to break on every signal. > > One simple use-case I believe where the *break-on-signals* approach is > inappropriate is if some response is computed by means of e.g. > > ?(if (ignore-errors (try-or-fail ...)) > ? ? ?"It worked!" > ? ? ?"Something went wrong.") We faced this problem a few times in the past and had the luxury to fix the underlying libraries. Normally, removing the use of ignore-errors is not hard to do, and quality code does not use it anyway. Face it, using (ignore-errors (parse-integer ...)) is nothing but stupid, but that was where I had to repair stuff in the past to make it debuggable. I am not meaning to say that I would be strictly opposed to re-establishing a Hunchentoot-private way to control error handling. It is just that I have not felt restricted by using *break-on-signals* and that I consider code which uses errors to handle errors to be preferable in any case, Hunchentoot or not. From edi at agharta.de Sat Nov 14 10:46:03 2009 From: edi at agharta.de (Edi Weitz) Date: Sat, 14 Nov 2009 11:46:03 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> <82ocn5a53k.fsf@yax.netfonds.no> Message-ID: On Sat, Nov 14, 2009 at 9:37 AM, Hans H?bner wrote: > I am not meaning to say that I would be strictly opposed to > re-establishing a Hunchentoot-private way to control error handling. > It is just that I have not felt restricted by using *break-on-signals* > and that I consider code which uses errors to handle errors to be > preferable in any case, Hunchentoot or not. Let me just say that I agree. The hows and whens of /maybe/ re-establishing Hunchentoot-specific error handling are still open due to lack of time (and that's one of the main reasons holding back a new release). But generally I think that CL has maybe the best condition system of all programming languages I know and we all don't use it enough. In an ideal world, *break-on-signals* would be the right solution to this problem. (And, yes, I've also used ignore-errors in places we I shouldn't have.) Edi. From sky at viridian-project.de Sat Nov 14 15:29:44 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sat, 14 Nov 2009 16:29:44 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> <82ocn5a53k.fsf@yax.netfonds.no> Message-ID: <20091114152944.GA17138@viridian-project.de> On Sat, Nov 14, 2009 at 09:37:06AM +0100, Hans H?bner wrote: > We faced this problem a few times in the past and had the luxury to > fix the underlying libraries. Normally, removing the use of > ignore-errors is not hard to do, and quality code does not use it > anyway. Face it, using (ignore-errors (parse-integer ...)) is nothing > but stupid, but that was where I had to repair stuff in the past to > make it debuggable. A perfectly sane pattern however is catching a specific error, e.g. (handler-case (parse-integer ...) (parse-error () nil)) This also triggers a break, of course. Leslie From peter at gigamonkeys.com Sat Nov 14 16:56:58 2009 From: peter at gigamonkeys.com (Peter Seibel) Date: Sat, 14 Nov 2009 08:56:58 -0800 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> <82ocn5a53k.fsf@yax.netfonds.no> Message-ID: <40e4e7e50911140856j72abd108y69ed3181856a1cad@mail.gmail.com> On Sat, Nov 14, 2009 at 2:46 AM, Edi Weitz wrote: > But generally I think that CL has maybe the best condition > system of all programming languages I know and we all don't use it > enough. ?In an ideal world, *break-on-signals* would be the right > solution to this problem. ?(And, yes, I've also used ignore-errors in > places we I shouldn't have.) I agree with the first two bits (best in the world, not used enough) but I think I disagree with the latter (*break-on-signals* ought to be the right solution). The thing that makes the condition system great is that it separates the handling of conditions into not just two but three parts. (signaling, handling, and restarting). It seems to me a perfectly reasonable use of the condition system to signal a condition somewhere down low, handle it up high (but still in code that was called from Hunchentoot) and then restart in some application specific way. However if the condition signaled matches the type spec in *break-on-signals* that logic will be completely short circuited, landing you in the debugger for a condition that was actually going to be handled within the application code and would never have bothered Hunchentoot at all. *break-on-signals* could possibly be made to work if you could come up with a type specifier that excluded all conditions of the sort I just described but included all unhandled conditions. But even if you could, that seems like a kludge to me--whether I want to end up in the debugger is not a function of the condition's type--it's a function of whether it's going to be handled before it percolates up to Hunchentoot code to deal with. -Peter -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/ From _deepfire at feelingofgreen.ru Sun Nov 15 03:13:40 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Sun, 15 Nov 2009 06:13:40 +0300 (MSK) Subject: [hunchentoot-devel] Customising PROCESS-REQUEST for continuous output Message-ID: <20091115.061340.1018291353080983388._deepfire@feelingofgreen.ru> Good day folks, I would like to employ a handler which continuously writes to the socket stream, so that the appended output becomes immediately available to the page viewer. Basically, I'm building a buildbot for CL libraries, and the build process can be long, so I want the feedback to be available as immediately as possible. So, I look at PROCESS-REQUEST and I see that the handler returns before any output is written to the stream. My understanding is that I need to customize PROCESS-REQUEST, unless I want to take over header generation and can tolerate headers re-appended after my output. The easiest way would appear to be subclassing REQUEST and providing a modified method for PROCESS-REQUEST. But it appears that this is impossible to do without affecting all handlers using the same acceptor, as the class of the request employed is the property of the acceptor -- as is mandated by PROCESS-CONNECTION -- which, again, dispatches on the acceptor. So, there appears to be no way to customise hunchentoot in this regard, without changing its request processing workings. Or am I just missing something? regards, Samium Gromoff -- P.S. In case this sounds negative -- it wasn't so intended. Hunchentoot is a really great server! _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From hans.huebner at gmail.com Sun Nov 15 08:42:54 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 15 Nov 2009 09:42:54 +0100 Subject: [hunchentoot-devel] Customising PROCESS-REQUEST for continuous output In-Reply-To: <20091115.061340.1018291353080983388._deepfire@feelingofgreen.ru> References: <20091115.061340.1018291353080983388._deepfire@feelingofgreen.ru> Message-ID: On Sun, Nov 15, 2009 at 04:13, Samium Gromoff <_deepfire at feelingofgreen.ru> wrote: > I would like to employ a handler which continuously writes to the socket > stream, so that the appended output becomes immediately available to the > page viewer. The canonical way to accomplish this is to use SEND-HEADERS to get a stream to the client and then send the data to the client as it becomes available. Did you try that? How does it not fulfill your needs? From _deepfire at feelingofgreen.ru Sun Nov 15 11:34:19 2009 From: _deepfire at feelingofgreen.ru (Samium Gromoff) Date: Sun, 15 Nov 2009 14:34:19 +0300 (MSK) Subject: [hunchentoot-devel] Customising PROCESS-REQUEST for continuous output In-Reply-To: References: <20091115.061340.1018291353080983388._deepfire@feelingofgreen.ru> Message-ID: <20091115.143419.237540044474598940._deepfire@feelingofgreen.ru> From: Hans H?bner > On Sun, Nov 15, 2009 at 04:13, Samium Gromoff > <_deepfire at feelingofgreen.ru> wrote: >> I would like to employ a handler which continuously writes to the socket >> stream, so that the appended output becomes immediately available to the >> page viewer. > > The canonical way to accomplish this is to use SEND-HEADERS to get a > stream to the client and then send the data to the client as it > becomes available. Did you try that? How does it not fulfill your > needs? Aha, so I failed with -ERTFM. Thanks, and sorry for disturbance! regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From edi at agharta.de Sun Nov 15 11:58:32 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 15 Nov 2009 12:58:32 +0100 Subject: [hunchentoot-devel] Invoke-debugger In-Reply-To: <40e4e7e50911140856j72abd108y69ed3181856a1cad@mail.gmail.com> References: <823a4ibctf.fsf@yax.netfonds.no> <82y6ma9vaf.fsf@yax.netfonds.no> <20091113180816.GA10352@viridian-project.de> <82ocn5a53k.fsf@yax.netfonds.no> <40e4e7e50911140856j72abd108y69ed3181856a1cad@mail.gmail.com> Message-ID: On Sat, Nov 14, 2009 at 5:56 PM, Peter Seibel wrote: > I agree with the first two bits (best in the world, not used enough) > but I think I disagree with the latter (*break-on-signals* ought to be > the right solution). The thing that makes the condition system great > is that it separates the handling of conditions into not just two but > three parts. (signaling, handling, and restarting). It seems to me a > perfectly reasonable use of the condition system to signal a condition > somewhere down low, handle it up high (but still in code that was > called from Hunchentoot) and then restart in some application specific > way. However if the condition signaled matches the type spec in > *break-on-signals* that logic will be completely short circuited, > landing you in the debugger for a condition that was actually going to > be handled within the application code and would never have bothered > Hunchentoot at all. > > *break-on-signals* could possibly be made to work if you could come up > with a type specifier that excluded all conditions of the sort I just > described but included all unhandled conditions. But even if you > could, that seems like a kludge to me--whether I want to end up in the > debugger is not a function of the condition's type--it's a function of > whether it's going to be handled before it percolates up to > Hunchentoot code to deal with. Yes, I agree. I was probably a bit too over-enthusiastic with the third bit... :) Still, I only have a finite amount of time. The Hunchentoot-specific error handling was thrown out with the 1.0.0 release and if we add something similar back in, I want it to be a reasonable, working, flexible, and well-documented solution. That takes time, and I'll do it when I have that time, this being not a priority for me right now. Thanks, Edi. From edi at agharta.de Sun Nov 15 15:17:58 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 15 Nov 2009 16:17:58 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: Hi Andreas, I took a quick look and this seems like a good start to me. I'm doing something else today, but I was going to commit the patch to the BKNR repository so that people could try it out and comment, but the patch doesn't apply. Did you work against the development version? Thanks, Edi. patching file acceptor.lisp Hunk #1 succeeded at 174 (offset 1 line). Hunk #2 succeeded at 247 (offset 1 line). Hunk #3 FAILED at 293. Hunk #4 succeeded at 464 (offset 8 lines). 1 out of 4 hunks FAILED -- saving rejects to file acceptor.lisp.rej patching file doc/index.xml Hunk #1 succeeded at 351 (offset 3 lines). Hunk #2 succeeded at 662 (offset 3 lines). patching file packages.lisp Hunk #1 succeeded at 133 (offset 1 line). patching file request.lisp Hunk #1 FAILED at 219. 1 out of 1 hunk FAILED -- saving rejects to file request.lisp.rej On Sun, Nov 15, 2009 at 3:07 PM, Andreas Fuchs wrote: > On Sun, Nov 15, 2009 at 12:58, Edi Weitz wrote: >> Yes, I agree. ?I was probably a bit too over-enthusiastic with the >> third bit... :) >> >> Still, I only have a finite amount of time. ?The Hunchentoot-specific >> error handling was thrown out with the 1.0.0 release and if we add >> something similar back in, I want it to be a reasonable, working, >> flexible, and well-documented solution. ?That takes time, and I'll do >> it when I have that time, this being not a priority for me right now. > > I have spent the last day working on a patch (incl. documentation) to > include an error-handling mechanism in Hunchentoot, similar to the > solution Peter posted some way up the thread (which was indeed a quick > hack by me). > > This patch introduces an error handling protocol for connections and > request handling. It introduces a new class and two new generic > functions (all three exported and documented): > > * defclass debugging-acceptor: An acceptor that doesn't catch errors, > instead relies on the implementation's debugger hook to catch the > error and report it synchronously. > > * defgeneric invoke-process-connection-with-error-handling: An error > handling mechanism for connection processing: Behavior for the regular > hunchentoot:acceptor is the current default behavior. > debuggable-acceptors only give you the debugger if their > debug-connection-errors-p slot is non-NIL (NIL is the default) > > * defgeneric invoke-process-request-with-error-handling: An error > handling mechanism for request handling: As before, the default > behavior is in place for all subclasses of hunchentoot:acceptor except > for debugging-acceptor. There, it invokes the debugger for signals > raised with CL:ERROR. > > I hope very much that you find this worth including in the hunchentoot > distribution. Of course, feedback is welcome. (-: > > Cheers, > -- > Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs > From asf at boinkor.net Sun Nov 15 15:22:15 2009 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 15 Nov 2009 16:22:15 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: On Sun, Nov 15, 2009 at 16:17, Edi Weitz wrote: > Hi Andreas, > > I took a quick look and this seems like a good start to me. ?I'm doing > something else today, but I was going to commit the patch to the BKNR > repository so that people could try it out and comment, but the patch > doesn't apply. ?Did you work against the development version? Oh, no - that's a diff against 1.0.0; 1.0.0 was on which I based the patch (from clbuild's http://common-lisp.net/~loliveira/ediware/hunchentoot darcs repo), as well. Should I bring it forward to what's in the BKNR repository? Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From asf at boinkor.net Sun Nov 15 14:07:14 2009 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 15 Nov 2009 15:07:14 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) Message-ID: On Sun, Nov 15, 2009 at 12:58, Edi Weitz wrote: > Yes, I agree. ?I was probably a bit too over-enthusiastic with the > third bit... :) > > Still, I only have a finite amount of time. ?The Hunchentoot-specific > error handling was thrown out with the 1.0.0 release and if we add > something similar back in, I want it to be a reasonable, working, > flexible, and well-documented solution. ?That takes time, and I'll do > it when I have that time, this being not a priority for me right now. I have spent the last day working on a patch (incl. documentation) to include an error-handling mechanism in Hunchentoot, similar to the solution Peter posted some way up the thread (which was indeed a quick hack by me). This patch introduces an error handling protocol for connections and request handling. It introduces a new class and two new generic functions (all three exported and documented): * defclass debugging-acceptor: An acceptor that doesn't catch errors, instead relies on the implementation's debugger hook to catch the error and report it synchronously. * defgeneric invoke-process-connection-with-error-handling: An error handling mechanism for connection processing: Behavior for the regular hunchentoot:acceptor is the current default behavior. debuggable-acceptors only give you the debugger if their debug-connection-errors-p slot is non-NIL (NIL is the default) * defgeneric invoke-process-request-with-error-handling: An error handling mechanism for request handling: As before, the default behavior is in place for all subclasses of hunchentoot:acceptor except for debugging-acceptor. There, it invokes the debugger for signals raised with CL:ERROR. I hope very much that you find this worth including in the hunchentoot distribution. Of course, feedback is welcome. (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot--debugging-acceptor-v1.patch Type: application/octet-stream Size: 11039 bytes Desc: not available URL: From edi at agharta.de Sun Nov 15 16:53:15 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 15 Nov 2009 17:53:15 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: On Sun, Nov 15, 2009 at 4:22 PM, Andreas Fuchs wrote: > On Sun, Nov 15, 2009 at 16:17, Edi Weitz wrote: >> Hi Andreas, >> >> I took a quick look and this seems like a good start to me. ?I'm doing >> something else today, but I was going to commit the patch to the BKNR >> repository so that people could try it out and comment, but the patch >> doesn't apply. ?Did you work against the development version? > > Oh, no - that's a diff against 1.0.0; 1.0.0 was on which I based the > patch (from clbuild's > http://common-lisp.net/~loliveira/ediware/hunchentoot darcs repo), as > well. > > Should I bring it forward to what's in the BKNR repository? That would be very nice, yes. I think we should have this change linger around in the dev version a bit before we make a new release. From j.k.cunningham at comcast.net Sun Nov 15 18:00:34 2009 From: j.k.cunningham at comcast.net (Jeff Cunningham) Date: Sun, 15 Nov 2009 10:00:34 -0800 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: References: <4AFCD378.9060007@comcast.net> Message-ID: <4B0041C2.6020408@comcast.net> Hans H?bner wrote: > On Fri, Nov 13, 2009 at 04:33, Jeff Cunningham > wrote: > >> I'm looking into setting up a Hunchentoot server on an OpenBSD system >> and right away noticed problems in the notes about building threads into >> SBCL (it sounds experimental). Lack of thread support would be a >> problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If >> so, were you able to use SBCL? If not, what did you use? >> > > I have not run Lisp on OpenBSD, but here is some advice anyway: > Running Hunchentoot in a single threaded Lisp is not generally a > problem for low-volume sites. I would decouple the Lisp server from > clients using a HTTP proxy so that slow clients can't easily stall the > server. > > > For what it's worth, I was able to build Hunchentoot single-threaded on OpenBSD, but found it nearly impossible to work with that way. I couldn't find a way to save an executable core, for example. I couldn't get swank to work, couldn't talk to a running instance so it ends up pretty much brain-dead. Once I'd launch the server I'd lose the repl ane the only way to make changes was to kill the process externally, edit and restart Lisp. There may be ways to solve all these problems, but I'm thinking I'd be better off spending my time (and money) finding a Linux server instead. Thanks for the help, --Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From asf at boinkor.net Sun Nov 15 18:28:44 2009 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 15 Nov 2009 19:28:44 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: On Sun, Nov 15, 2009 at 17:53, Edi Weitz wrote: >> Should I bring it forward to what's in the BKNR repository? > > That would be very nice, yes. ?I think we should have this change > linger around in the dev version a bit before we make a new release. Sounds sensible. I've tested the attached patch to r4467 on the latest SBCL from CVS, and it seemed to work, so I think I should have ported it correctly. One more reason to let it stew in the dev version a bit longer, I guess (-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot--debugging-acceptor-v2.patch Type: application/octet-stream Size: 17359 bytes Desc: not available URL: From edi at agharta.de Sun Nov 15 19:33:38 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 15 Nov 2009 20:33:38 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: On Sun, Nov 15, 2009 at 7:28 PM, Andreas Fuchs wrote: > Sounds sensible. I've tested the attached patch to r4467 on the latest > SBCL from CVS, and it seemed to work, so I think I ?should have ported > it correctly. One more reason to let it stew in the dev version a bit > longer, I guess (-: Thanks, it's online now. http://bknr.net/trac/log/trunk/thirdparty/hunchentoot/ Edi. From edi at agharta.de Sun Nov 15 20:05:56 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 15 Nov 2009 21:05:56 +0100 Subject: [hunchentoot-devel] PATCH: cl-webdav using the newer condition from the flexi-streams package In-Reply-To: <75b4567b0911130741m5ef0cf81tfca6775c23be258a@mail.gmail.com> References: <75b4567b0911130741m5ef0cf81tfca6775c23be258a@mail.gmail.com> Message-ID: Hi Matt, Sorry for the delay. What I had forgotten (it's more than one year ago...) is that there's a version of CL-WEBDAV in the BKNR repository that already contains this change and some changes from Cyrus Harmon to make it compatible with the then current Hunchentoot. If you're actually using CL-WEBDAV would you be so inclined to test the BKNR version against the current Hunchentoot release (1.0.0)? Maybe we can release it as is and remove the warning that you have to use an old version of the web server? http://bknr.net/trac/browser/trunk/thirdparty/cl-webdav Thanks, Edi. On Fri, Nov 13, 2009 at 4:41 PM, Matthew Curry wrote: > flexi-streams package changed the name of the condition: > flexi-stream-encoding-error to external-format-encoding-error > > Patch to cl-webdav attached. > > -Matt > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From billstclair at gmail.com Sun Nov 15 20:34:00 2009 From: billstclair at gmail.com (Bill St. Clair) Date: Sun, 15 Nov 2009 15:34:00 -0500 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: <4B0041C2.6020408@comcast.net> References: <4AFCD378.9060007@comcast.net> <4B0041C2.6020408@comcast.net> Message-ID: <8fbe874a0911151234l4baf4f46qa2217652de4f96b9@mail.gmail.com> On Sun, Nov 15, 2009 at 1:00 PM, Jeff Cunningham wrote: > Hans H?bner wrote: > > On Fri, Nov 13, 2009 at 04:33, Jeff Cunningham > wrote: > > > I'm looking into setting up a Hunchentoot server on an OpenBSD system > and right away noticed problems in the notes about building threads into > SBCL (it sounds experimental). Lack of thread support would be a > problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If > so, were you able to use SBCL? If not, what did you use? > > > I have not run Lisp on OpenBSD, but here is some advice anyway: > Running Hunchentoot in a single threaded Lisp is not generally a > problem for low-volume sites. I would decouple the Lisp server from > clients using a HTTP proxy so that slow clients can't easily stall the > server. > > > > > For what it's worth, I was able to build Hunchentoot single-threaded on > OpenBSD, but found it nearly impossible to work with that way. I couldn't > find a way to save an executable core, for example. I couldn't get swank to > work, couldn't talk to a running instance so it ends up pretty much > brain-dead. Once I'd launch the server I'd lose the repl ane the only way to > make changes was to kill the process externally, edit and restart Lisp. > There may be ways to solve all these problems, but I'm thinking I'd be > better off spending my time (and money) finding a Linux server instead. Or you could try Clozure Common Lisp (CCL) on OpenBSD. CCL and multi-threaded Hunchentoot are known to work on FreeBSD, but none of us at Clozure has an OpenBSD machine to try it on. -Bill From krz at cis.rit.edu Sun Nov 15 22:06:39 2009 From: krz at cis.rit.edu (Bob Krzaczek) Date: Sun, 15 Nov 2009 17:06:39 -0500 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: <4B0041C2.6020408@comcast.net> References: <4AFCD378.9060007@comcast.net> <4B0041C2.6020408@comcast.net> Message-ID: <4B007B6F.1020404@cis.rit.edu> Jeff Cunningham wrote: > I'm > thinking I'd be better off spending my time (and money) finding a Linux > server instead. Another option you might consider: You can build a multithreaded SBCL under FreeBSD and run Hunchentoot there. I've deployed exactly such a server for a long time without a problem. Just a suggestion, as I suspect migrating from OpenBSD to FreeBSD might be a little easier than migrating to Linux. Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz at cis.rit.edu, icbm 43.0848N 77.6789W From j.k.cunningham at comcast.net Mon Nov 16 00:22:40 2009 From: j.k.cunningham at comcast.net (Jeff Cunningham) Date: Sun, 15 Nov 2009 16:22:40 -0800 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: <8fbe874a0911151234l4baf4f46qa2217652de4f96b9@mail.gmail.com> References: <4AFCD378.9060007@comcast.net> <4B0041C2.6020408@comcast.net> <8fbe874a0911151234l4baf4f46qa2217652de4f96b9@mail.gmail.com> Message-ID: <4B009B50.8040503@comcast.net> Bill St. Clair wrote: > Or you could try Clozure Common Lisp (CCL) on OpenBSD. CCL and > multi-threaded Hunchentoot are known to work on FreeBSD, but none of > us at Clozure has an OpenBSD machine to try it on. > > -Bill > > > Can CCL generate executable images? --Jeff From billstclair at gmail.com Mon Nov 16 00:35:55 2009 From: billstclair at gmail.com (Bill St. Clair) Date: Sun, 15 Nov 2009 19:35:55 -0500 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: <4B009B50.8040503@comcast.net> References: <4AFCD378.9060007@comcast.net> <4B0041C2.6020408@comcast.net> <8fbe874a0911151234l4baf4f46qa2217652de4f96b9@mail.gmail.com> <4B009B50.8040503@comcast.net> Message-ID: <8fbe874a0911151635q526671e1y5141d0e02630faa8@mail.gmail.com> On Sun, Nov 15, 2009 at 7:22 PM, Jeff Cunningham wrote: > > > Bill St. Clair wrote: >> Or you could try Clozure Common Lisp (CCL) on OpenBSD. CCL and >> multi-threaded Hunchentoot are known to work on FreeBSD, but none of >> us at Clozure has an OpenBSD machine to try it on. >> >> -Bill >> >> >> > Can CCL generate executable images? Yes, with (save-application filename ... :prepend-kernel t) -Bill From mjcurry at gmail.com Mon Nov 16 00:41:19 2009 From: mjcurry at gmail.com (Matthew Curry) Date: Sun, 15 Nov 2009 19:41:19 -0500 Subject: [hunchentoot-devel] PATCH: cl-webdav using the newer condition from the flexi-streams package In-Reply-To: References: <75b4567b0911130741m5ef0cf81tfca6775c23be258a@mail.gmail.com> Message-ID: <75b4567b0911151641j6285df0dg47518e8e31edd19@mail.gmail.com> Edi, oh, I didn't know there was another repository for it. No, I wasn't actually using cl-webdav - just trying to compile a bunch of projects that might be useful and package them up in RPM-form for work, trying to lay the groundwork for using common lisp at work, and we're basically a RHEL 4 shop. But I'll have some time off over the Thanksgiving holiday next week, so maybe I can test it anyway if you need someone to look at it. -Matt On Sun, Nov 15, 2009 at 3:05 PM, Edi Weitz wrote: > Hi Matt, > > Sorry for the delay. ?What I had forgotten (it's more than one year > ago...) is that there's a version of CL-WEBDAV in the BKNR repository > that already contains this change and some changes from Cyrus Harmon > to make it compatible with the then current Hunchentoot. > > If you're actually using CL-WEBDAV would you be so inclined to test > the BKNR version against the current Hunchentoot release (1.0.0)? > Maybe we can release it as is and remove the warning that you have to > use an old version of the web server? > > ?http://bknr.net/trac/browser/trunk/thirdparty/cl-webdav > > Thanks, > Edi. > > On Fri, Nov 13, 2009 at 4:41 PM, Matthew Curry wrote: >> flexi-streams package changed the name of the condition: >> flexi-stream-encoding-error to external-format-encoding-error >> >> Patch to cl-webdav attached. >> >> -Matt >> >> _______________________________________________ >> 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 j.k.cunningham at comcast.net Mon Nov 16 00:55:59 2009 From: j.k.cunningham at comcast.net (Jeff Cunningham) Date: Sun, 15 Nov 2009 16:55:59 -0800 Subject: [hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server? - final report In-Reply-To: <8fbe874a0911151635q526671e1y5141d0e02630faa8@mail.gmail.com> References: <4AFCD378.9060007@comcast.net> <4B0041C2.6020408@comcast.net> <8fbe874a0911151234l4baf4f46qa2217652de4f96b9@mail.gmail.com> <4B009B50.8040503@comcast.net> <8fbe874a0911151635q526671e1y5141d0e02630faa8@mail.gmail.com> Message-ID: <4B00A31F.1060508@comcast.net> Bill St. Clair wrote: > On Sun, Nov 15, 2009 at 7:22 PM, Jeff Cunningham > wrote: > >> Bill St. Clair wrote: >> >>> Or you could try Clozure Common Lisp (CCL) on OpenBSD. CCL and >>> multi-threaded Hunchentoot are known to work on FreeBSD, but none of >>> us at Clozure has an OpenBSD machine to try it on. >>> >>> -Bill >>> >>> >>> >>> >> Can CCL generate executable images? >> > > I just grabbed latest snapshot through subversion and tried the binary and it failed, so apparently it isn't compatible with OpenBSD. I tried both the lx86cl64 and lx86cl versions (can't tell if this remote machine is 64-bit or not, it doesn't have /proc/cpu-info mounted and that's the only way I know to find out). I don't have root priviledges so there's not much else I can try that I know of. Is there a way to build it from scratch? Or do you have to start with the binary? We should probably take this off list - its getting off topic. --Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjcurry at gmail.com Mon Nov 16 02:29:06 2009 From: mjcurry at gmail.com (Matthew Curry) Date: Sun, 15 Nov 2009 21:29:06 -0500 Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0 Message-ID: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> Edi, I took a look at it tonight anyway, and there where some obvious minor fixes I spotted right away, attached is a patch that gets (using cadaver) an initial connection, a put, and a get to work. Just functions that were renamed in the new hunchentoot. Delete doesn't work, complains about a handler-done tag being unknown (but thrown). Here's the message log entry: [2009-11-15 20:55:06 [ERROR]] attempt to THROW to a tag that does not exist: HANDLER-DONE I'm not too familiar with older versions of hunchentoot, does that ring a bell for you? I'll keep looking. -Matt -------------- next part -------------- Index: resources.lisp =================================================================== --- resources.lisp (revision 4468) +++ resources.lisp (working copy) @@ -204,9 +204,9 @@ method if you're sitting behind a proxy.") (:method (resource) (format nil "http~:[~;s~]://~A~@[:~A~]/" - (ssl-p) - (ppcre:regex-replace ":\\d+$" (host) "") - (server-port)))) + (acceptor-ssl-p *acceptor*) + (ppcre:regex-replace ":\\d+$" (acceptor-address *acceptor*) "") + (acceptor-port *acceptor*)))) (defgeneric get-dead-properties (resource) (:documentation "This function must return all dead properties @@ -399,9 +399,9 @@ "Utility function which sets up Hunchentoot's *REPLY* object for a +HTTP-CREATED+ response corresponding to the newly-created resource RESOURCE." - (setf (content-type) (get-content-type resource) + (setf (content-type*) (get-content-type resource) (header-out :location) (resource-script-name resource) - (return-code) +http-created+) + (return-code*) +http-created+) (let ((etag (resource-etag resource)) (content-language (resource-content-language resource))) (when etag Index: handlers.lisp =================================================================== --- handlers.lisp (revision 4468) +++ handlers.lisp (working copy) @@ -102,8 +102,8 @@ (not-found)) (multiple-value-bind (properties propname) (parse-propfind (raw-post-data :force-binary t)) - (setf (content-type) "text/xml; charset=utf-8" - (return-code) +http-multi-status+) + (setf (content-type*) "text/xml; charset=utf-8" + (return-code*) +http-multi-status+) (let ((result ;; loop through the resource and its descendants until ;; depth limit is reached @@ -145,8 +145,8 @@ (push (cons +http-conflict+ property) results)) (t (funcall property-handler resource property) (push (cons +http-ok+ property) results)))))) - (setf (content-type) "text/xml; charset=utf-8" - (return-code) +http-multi-status+) + (setf (content-type*) "text/xml; charset=utf-8" + (return-code*) +http-multi-status+) (serialize-xmls-node (dav-node "multistatus" (apply #'dav-node "response" @@ -169,7 +169,7 @@ (let ((etag (resource-etag resource)) (write-date (resource-write-date resource)) (content-language (resource-content-language resource))) - (setf (content-type) (resource-content-type resource)) + (setf (content-type*) (resource-content-type resource)) (when etag (setf (header-out :etag) etag)) (when content-language @@ -177,11 +177,11 @@ (catch 'handler-done (handle-if-modified-since write-date) (when (equal etag (header-in* :if-none-match)) - (setf (return-code) +http-not-modified+))) - (when (eql (return-code) +http-not-modified+) + (setf (return-code*) +http-not-modified+))) + (when (eql (return-code*) +http-not-modified+) (throw 'handler-done nil)) (setf (header-out :last-modified) (rfc-1123-date write-date) - (content-length) (resource-length resource)) + (content-length*) (resource-length resource)) (unless head-request-p (send-content resource (send-headers)))))) @@ -198,10 +198,10 @@ response will be generated and DEFAULT-RETURN-CODE will be used instead." (unless results - (setf (return-code) default-return-code) + (setf (return-code*) default-return-code) (throw 'handler-done nil)) - (setf (content-type) "text/xml; charset=utf-8" - (return-code) +http-multi-status+) + (setf (content-type*) "text/xml; charset=utf-8" + (return-code*) +http-multi-status+) ;; use a hash table to group by status code (let ((status-hash (make-hash-table))) (loop for (status . resource) in results @@ -297,8 +297,8 @@ (failed-dependency))) (let ((results (copy-or-move-resource* source destination movep depth-value))) (cond (results (multi-status results)) - (destination-exists (setf (return-code) +http-no-content+ - (content-type) nil) + (destination-exists (setf (return-code*) +http-no-content+ + (content-type*) nil) nil) (t (resource-created destination)))))))) @@ -324,7 +324,7 @@ (error (condition) (warn "While trying to create collection ~S: ~A" (resource-script-name resource) condition) - (setf (return-code) +http-internal-server-error+)) + (setf (return-code*) +http-internal-server-error+)) (:no-error (&rest args) (declare (ignore args)) - (resource-created resource))))) \ No newline at end of file + (resource-created resource))))) From edi at agharta.de Mon Nov 16 07:06:44 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Nov 2009 08:06:44 +0100 Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0 In-Reply-To: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 3:29 AM, Matthew Curry wrote: > I took a look at it tonight anyway, and there where some obvious minor > fixes I spotted right away, attached is a patch that gets (using > cadaver) an initial connection, a put, and a get to work. ?Just > functions that were renamed in the new hunchentoot. Thanks a lot, it's in the repository now. > Delete doesn't work, complains about a handler-done tag being unknown > (but thrown). ?Here's the message log entry: > [2009-11-15 20:55:06 [ERROR]] attempt to THROW to a tag that does not > exist: HANDLER-DONE > I'm not too familiar with older versions of hunchentoot, does that > ring a bell for you? I think I've fixed that now (untested): http://bknr.net/trac/changeset/4471/trunk/thirdparty/cl-webdav > I'll keep looking. Maybe we should just release it now and see if someone complains? I doubt that anybody really uses cl-webdav for serious work. Thanks again, Edi. From edi at agharta.de Mon Nov 16 14:58:01 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Nov 2009 15:58:01 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: Hans mentioned this today and I now that I found some time to think about it, I tend to agree with him: The problem with the new approach is that if you want to debug your web app, you need to change the acceptor class. That's a bit inconvenient compared to the good old days of setting/binding a special variable, isn't it? Shouldn't the standard acceptor class provide the ability to switch debugging on and off at runtime? Maybe with a (class) slot or something instead of a special variable? The protocol that you added is I think still useful and should be kept nevertheless. Thought? Thanks, Edi. From edi at agharta.de Mon Nov 16 15:17:54 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Nov 2009 16:17:54 +0100 Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0 In-Reply-To: <75b4567b0911160701o37b844c8xd44fa96c5be456ef@mail.gmail.com> References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> <75b4567b0911160701o37b844c8xd44fa96c5be456ef@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 4:01 PM, Matthew Curry wrote: > I don't mind, but I was going to basically test it by going down the > list of cadaver commands that do stuff remotely, I think 'copy' didn't > work either, but I'll try again later with your updates. I'll be out of town for a week anyway. I'll decide next week whether I'll make a new release. Thanks for your help, Edi. From mjcurry at gmail.com Mon Nov 16 15:01:32 2009 From: mjcurry at gmail.com (Matthew Curry) Date: Mon, 16 Nov 2009 10:01:32 -0500 Subject: [hunchentoot-devel] PATCH: Some minor fixes for cl-webdav under hunchentoot 1.0 In-Reply-To: References: <75b4567b0911151829u4fd9358bufff4bd7c482cd849@mail.gmail.com> Message-ID: <75b4567b0911160701o37b844c8xd44fa96c5be456ef@mail.gmail.com> >> I'll keep looking. > > Maybe we should just release it now and see if someone complains? ?I > doubt that anybody really uses cl-webdav for serious work. > I don't mind, but I was going to basically test it by going down the list of cadaver commands that do stuff remotely, I think 'copy' didn't work either, but I'll try again later with your updates. -Matt From edi at agharta.de Mon Nov 16 16:35:22 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Nov 2009 17:35:22 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 5:24 PM, Peter Seibel wrote: > Hey, you're the guy who took out the special variable. ;-) I blame it on Hans... :) > I agree with your new position--it's more useful to be able to change > the behavior of a running server to choose between logging, ignoring, > or debugging errors just by setting a variable. Whether it's in a slot > or special variable doesn't matter a ton. Though I could imagine cases > where a special variable would be handy--you could change the policy > in one piece of application code without affecting others. At the handler level it wouldn't be possible. Right now, I don't think a special variable would buy you more flexibility given the Hunchentoot architecture. But I've been wrong before... :) From hans.huebner at gmail.com Mon Nov 16 16:41:33 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 16 Nov 2009 17:41:33 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 17:35, Edi Weitz wrote: > On Mon, Nov 16, 2009 at 5:24 PM, Peter Seibel wrote: > >> Hey, you're the guy who took out the special variable. ;-) > > I blame it on Hans... :) I happily take a lot of blame, but this I need to decline! You were the one who convinced me that *break-on-signals* is all you need, and who am I to dissent? :P From peter at gigamonkeys.com Mon Nov 16 16:24:23 2009 From: peter at gigamonkeys.com (Peter Seibel) Date: Mon, 16 Nov 2009 08:24:23 -0800 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: Message-ID: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> On Mon, Nov 16, 2009 at 6:58 AM, Edi Weitz wrote: > Hans mentioned this today and I now that I found some time to think > about it, I tend to agree with him: > > The problem with the new approach is that if you want to debug your > web app, you need to change the acceptor class. ?That's a bit > inconvenient compared to the good old days of setting/binding a > special variable, isn't it? Hey, you're the guy who took out the special variable. ;-) > Shouldn't the standard acceptor class provide the ability to switch > debugging on and off at runtime? ?Maybe with a (class) slot or > something instead of a special variable? ?The protocol that you added > is I think still useful and should be kept nevertheless. > > Thought? I agree with your new position--it's more useful to be able to change the behavior of a running server to choose between logging, ignoring, or debugging errors just by setting a variable. Whether it's in a slot or special variable doesn't matter a ton. Though I could imagine cases where a special variable would be handy--you could change the policy in one piece of application code without affecting others. -Peter -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/ From edi at agharta.de Mon Nov 16 18:07:10 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 16 Nov 2009 19:07:10 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> Message-ID: On Mon, Nov 16, 2009 at 5:41 PM, Hans H?bner wrote: > I happily take a lot of blame, but this I need to decline! ?You were > the one who convinced me that *break-on-signals* is all you need, and > who am I to dissent? :P Really? I'm getting old... From sky at viridian-project.de Mon Nov 16 18:25:34 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Mon, 16 Nov 2009 19:25:34 +0100 (CET) Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot (was: Invoke-debugger) In-Reply-To: References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> Message-ID: <7227347b7607341966db7caa9f1261d3.squirrel@mail.stardawn.org> Edi Weitz wrote: > At the handler level it wouldn't be possible. Right now, I don't > think a special variable would buy you more flexibility given the > Hunchentoot architecture. But I've been wrong before... :) FWIW in Weblocks we have settled down to a scheme that's similar to the one that used to be in Hunchentoot 0. Our API lets the developer decide whether he wants to have the debugger invoked or rather have the error handled by an error page. In another application (a command-line tool) we have three choices: invoke debugger, exit with error, exit after printing backtrace. Leslie From frode at netfonds.no Thu Nov 19 08:45:05 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Thu, 19 Nov 2009 09:45:05 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> Message-ID: <82zl6irjhq.fsf@netfonds.no> Hans H?bner -> Edi Weitz > You were the one who convinced me that *break-on-signals* is all you > need, and who am I to dissent? :P Just as an apropos to the discussion: I just had the cunning idea to use an around method on process-request to set up some dynamic variables that were initially unbound, and with a handler-bind that would compute the init-forms upon first use of the variable, thus only computing the bindings' init-forms when they are actually required. The *break-on-signals* approach would not mix well with this technique. -- Frode V. Fjeld From hans.huebner at gmail.com Thu Nov 19 09:31:57 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 19 Nov 2009 10:31:57 +0100 Subject: [hunchentoot-devel] [patch] Invoking the debugger in Hunchentoot In-Reply-To: <82zl6irjhq.fsf@netfonds.no> References: <40e4e7e50911160824p67c25012rc4116ea8611f01be@mail.gmail.com> <82zl6irjhq.fsf@netfonds.no> Message-ID: On Thu, Nov 19, 2009 at 09:45, Frode V. Fjeld wrote: > Hans H?bner ?-> ? Edi Weitz > >> You were the one who convinced me that *break-on-signals* is all you >> need, and who am I to dissent? :P > > Just as an apropos to the discussion: I just had the cunning idea to use > an around method on process-request to set up some dynamic variables > that were initially unbound, and with a handler-bind that would compute > the init-forms upon first use of the variable, thus only computing the > bindings' init-forms when they are actually required. The > *break-on-signals* approach would not mix well with this technique. To continue flogging a dead horse: I consented with the removal of the hunchentoot specific debugging mechanism because I still have something of a C++ mindset, part of which is considering exception handling as being exclusively for error handling. In C++, exception handling has undefined performance characteristics, which is why it is considered bad style to use it in non-error circumstances. In Lisp, performance is generally not that well-defined, and it is generally more open to multiple styles and paradigms, so restricting the use of signals to genuine error handling is much less sensible. So: Apologies :) From slawek.zak at gmail.com Sun Nov 22 15:01:02 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Sun, 22 Nov 2009 16:01:02 +0100 Subject: [hunchentoot-devel] Recursive lock when logging Message-ID: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> Hi, On svn-latest Hunchentoot I get this error when running on Allegro CL: #1=# seizing # recursively [Condition of type SIMPLE-ERROR] Following knobs have been turned: (setq *log-lisp-errors-p* t) (setq *log-lisp-warnings-p* t) (setq *message-log-pathname* "log/message.log") (setq *access-log-pathname* "log/access.log") Thanks, /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From slawek.zak at gmail.com Sun Nov 22 14:35:07 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Sun, 22 Nov 2009 15:35:07 +0100 Subject: [hunchentoot-devel] Debugging acceptor issue Message-ID: <787bbe1c0911220635ta7bd7dcx1842ac6248f01274@mail.gmail.com> Hey, I just started playing with the all-new debugging-acceptor. I run it using: (start (make-instance 'debugging-acceptor :port 8080 :debug-connection-errors-p t)) After setting up global stream redirection in swank I get segmentation fault on ACL 8.1/Linux. First time ever got a lisp process segfault on me :) So - what gives? Any special sugar I ought to add to make it sing? /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Sun Nov 22 20:32:32 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 22 Nov 2009 21:32:32 +0100 Subject: [hunchentoot-devel] Recursive lock when logging In-Reply-To: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> References: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> Message-ID: Slawek, I think that noone currently supports or tests Hunchentoot on Allegro CL. Its primary platforms are Lispworks, SBCL and Clozure CL. There are ports to other free CL implementations (ECL, CLISP), but I don't know how well they work. If you are looking for a CL web server and want to use Allegro CL, consider using Allegroserve. It is included with Allegro CL and fully supported by Franz Inc. If you still want to use Hunchentoot, you'll have to do some debugging work yourself. The locking problem that you described should be relatively simple to solve (but looking at the stack backtrace would be illuminating, use :zoom to see the backtrace). The segmentation fault that you've seen will be harder to debug. One you got it running, please send patches after having read http://weitz.de/patches.html Cheers, Hans From peter at gigamonkeys.com Sun Nov 22 20:41:32 2009 From: peter at gigamonkeys.com (Peter Seibel) Date: Sun, 22 Nov 2009 12:41:32 -0800 Subject: [hunchentoot-devel] Recursive lock when logging In-Reply-To: References: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> Message-ID: <40e4e7e50911221241y7243f679q1c60db885774c7c7@mail.gmail.com> I used to use it on Allegro; I don't think it should be too hard to get going. As to the segfaults, Allegro does that from time to time but it almost always turns out to be the result of some fairly stupid error involving passing an object of the wrong type into some thing that somehow dodges the normal type checks. (I realize that's pretty vague but I've had segfaults and then eventually realized I was doing something stupid and they went away.) You should certainly be able to bug Franz support about the segfault. My guess, in this case, is it has something to do with the streams, what SLIME is doing vs. what Allegro is expecting. -Peter On Sun, Nov 22, 2009 at 12:32 PM, Hans H?bner wrote: > Slawek, > > I think that noone currently supports or tests Hunchentoot on Allegro > CL. ?Its primary platforms are Lispworks, SBCL and Clozure CL. ?There > are ports to other free CL implementations (ECL, CLISP), but I don't > know how well they work. > > If you are looking for a CL web server and want to use Allegro CL, > consider using Allegroserve. ?It is included with Allegro CL and fully > supported by Franz Inc. > > If you still want to use Hunchentoot, you'll have to do some debugging > work yourself. ?The locking problem that you described should be > relatively simple to solve (but looking at the stack backtrace would > be illuminating, use :zoom to see the backtrace). ?The segmentation > fault that you've seen will be harder to debug. ?One you got it > running, please send patches after having read > http://weitz.de/patches.html > > Cheers, > Hans > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Peter Seibel http://www.codersatwork.com/ http://www.gigamonkeys.com/blog/ From edi at agharta.de Mon Nov 23 16:53:09 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 23 Nov 2009 17:53:09 +0100 Subject: [hunchentoot-devel] Debugging acceptor issue In-Reply-To: <787bbe1c0911220635ta7bd7dcx1842ac6248f01274@mail.gmail.com> References: <787bbe1c0911220635ta7bd7dcx1842ac6248f01274@mail.gmail.com> Message-ID: Hi Slawek, I think the same answer that Hans gave to your other question applies here as well. It seems nobody on this list actively uses Hunchentoot with AllegroCL... :( Edi. From slawek.zak at gmail.com Mon Nov 23 18:43:56 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Mon, 23 Nov 2009 19:43:56 +0100 Subject: [hunchentoot-devel] Recursive lock when logging In-Reply-To: <40e4e7e50911221241y7243f679q1c60db885774c7c7@mail.gmail.com> References: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> <40e4e7e50911221241y7243f679q1c60db885774c7c7@mail.gmail.com> Message-ID: <787bbe1c0911231043i708efca9we147e1979d92825e@mail.gmail.com> Hey Peter, On Sun, Nov 22, 2009 at 9:41 PM, Peter Seibel wrote: > I used to use it on Allegro; I don't think it should be too hard to > get going. As to the segfaults, Allegro does that from time to time > but it almost always turns out to be the result of some fairly stupid > error involving passing an object of the wrong type into some thing > that somehow dodges the normal type checks. (I realize that's pretty > vague but I've had segfaults and then eventually realized I was doing > something stupid and they went away.) You should certainly be able to > bug Franz support about the segfault. My guess, in this case, is it > has something to do with the streams, what SLIME is doing vs. what > Allegro is expecting. I think you've nailed it. I've been toying for some time w/ stream redirection in swank. After removing the hooks ACL doesn't segfault anymore. Will look into it further. Thanks!. /S From slawek.zak at gmail.com Mon Nov 23 18:48:13 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Mon, 23 Nov 2009 19:48:13 +0100 Subject: [hunchentoot-devel] Recursive lock when logging In-Reply-To: References: <787bbe1c0911220701j37e83e7xd3af287a8df93fac@mail.gmail.com> Message-ID: <787bbe1c0911231048n73967efax8c8acf97eb43fdee@mail.gmail.com> On Sun, Nov 22, 2009 at 9:32 PM, Hans H?bner wrote: > Slawek, > > I think that noone currently supports or tests Hunchentoot on Allegro > CL. ?Its primary platforms are Lispworks, SBCL and Clozure CL. ?There > are ports to other free CL implementations (ECL, CLISP), but I don't > know how well they work. Yeah, but I use ACL for AllegroCache goodness too, so can't switch my lisp that easily. As a second thought - isn't Lisp beautiful? Noone tests on ACL but for the most part Hunchentoot works just fine on it despite large code base and all the dependencies :) > If you are looking for a CL web server and want to use Allegro CL, > consider using Allegroserve. ?It is included with Allegro CL and fully > supported by Franz Inc. I've been a long-time user of Allegroserve, but still find Hunchentoot code clearer and more compelling. > If you still want to use Hunchentoot, you'll have to do some debugging > work yourself. ?The locking problem that you described should be > relatively simple to solve (but looking at the stack backtrace would > be illuminating, use :zoom to see the backtrace). ?The segmentation > fault that you've seen will be harder to debug. ?One you got it > running, please send patches after having read > http://weitz.de/patches.html I sure will do that. There is another issue w/ handle-static-file that I've found today. Will tackle it as well. Thanks Hans!, /S From frode at netfonds.no Wed Nov 25 08:42:06 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Wed, 25 Nov 2009 09:42:06 +0100 Subject: [hunchentoot-devel] Specializing process-request Message-ID: <82vdgzvvvl.fsf@netfonds.no> Hi all, The Hunchentoot documentation at http://weitz.de/hunchentoot/ mentions that an around-method on process-request "might be a good place to introduce around methods which bind special variables or do other interesting things." In my eyes there's a problem with this, because the standard process-request sets up crucial parts of the dynamic environment for request processing, and around methods can only modify the scope outside of that. In particluar, error and warning conditions are handled before the around method gets a chance to intervene. I would suggest adding a new generic function that does just the dispatching, i.e. something like this: (defmethod dispatch-request ((*request* t)) (funcall (acceptor-request-dispatcher *acceptor*) *request*)) ..and have the kernel of the standard process-request method just call dispatch-request in the obvious way. I think this is a more appropriate configuration point for the request processing protocol than the current process-request is. (I can/could of course specialize process-request for my acceptor class using an unqualified method, and thus set up the dynamic environment just how I want it. However I would then just have to copy the full body of the standard process-request to insert a line or two inside the body of the handler-bind. I believe it's the purpose of a processing protocol to avoid having to do such things.) -- Frode V. Fjeld Netfonds Bank ASA From tc at travislists.com Wed Nov 25 09:08:46 2009 From: tc at travislists.com (Travis Cross) Date: Wed, 25 Nov 2009 09:08:46 +0000 Subject: [hunchentoot-devel] [PATCH] debugging-acceptor breaks REDIRECT (among other things) Message-ID: <4B0CF41E.1060700@travislists.com> Greetings, The invoke-process-request-with-error-handling method on the debugging-acceptor gets a bit overzealous with catching unwinds. Because we throw to 'handler-done in various places, there are many unwinds that are not errors. In particular, REDIRECT throws, as does anything that calls ABORT-REQUEST-HANDLER (e.g. authorization-required replies, http-forbidden, http-not-found, etc.). The cleanest solution is to save a continuation before dropping into the debugger, then check to see whether we have a continuation to call during unwind. Patch is attached. (Thanks for providing a partial replacement for the old *catch-errors-p*, by the way.) Cheers, -- Travis Cross -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: debugging-acceptor-throw-fix.diff URL: From frode at netfonds.no Wed Nov 25 10:23:25 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Wed, 25 Nov 2009 11:23:25 +0100 Subject: [hunchentoot-devel] Specializing process-request References: <82vdgzvvvl.fsf@netfonds.no> Message-ID: <82k4xex5r6.fsf@netfonds.no> frode at netfonds.no (Frode V. Fjeld) writes: > (I can/could of course specialize process-request for my acceptor class > using an unqualified method, and thus set up the dynamic environment > just how I want it. However I would then just have to copy the full body > of the standard process-request to insert a line or two inside the body > of the handler-bind. I believe it's the purpose of a processing protocol > to avoid having to do such things.) This didn't really work out in practice: cut'n'pasting the body of process-request into a different package made it clear that process-request can't really be replaced without breaking lots of stuff. Also, modifying my dispatchers or handlers proved to be impractical. So here's a diff detailing my suggestion in my previous posting. It's simple, and seems to work well. Index: packages.lisp =================================================================== --- packages.lisp (revision 4474) +++ packages.lisp (working copy) @@ -168,6 +168,7 @@ "DELETE-AUX-REQUEST-VALUE" "DELETE-SESSION-VALUE" "DISPATCH-EASY-HANDLERS" + "DISPATCH-REQUEST" "ESCAPE-FOR-HTML" "EXECUTE-ACCEPTOR" "GET-PARAMETER" Index: request.lisp =================================================================== --- request.lisp (revision 4474) +++ request.lisp (working copy) @@ -210,6 +210,10 @@ ;; we assume it's not our fault... (setf (return-code*) +http-bad-request+))))) +(defmethod dispatch-request (request) + (funcall (acceptor-request-dispatcher *acceptor*) + request)) + (defmethod process-request (request) "Standard implementation for processing a request. You should not change or replace this functionality unless you know what you're @@ -227,7 +231,7 @@ ;; skip dispatch if bad request (when (eql (return-code *reply*) +http-ok+) ;; now do the work - (funcall (acceptor-request-dispatcher *acceptor*) *request*))))) + (dispatch-request request))))) (when error (setf (return-code *reply*) +http-internal-server-error+)) -- Frode V. Fjeld Netfonds Bank ASA From hans.huebner at gmail.com Wed Nov 25 11:05:35 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 25 Nov 2009 12:05:35 +0100 Subject: [hunchentoot-devel] Specializing process-request In-Reply-To: <82k4xex5r6.fsf@netfonds.no> References: <82vdgzvvvl.fsf@netfonds.no> <82k4xex5r6.fsf@netfonds.no> Message-ID: Frode, the patch looks good. Can you please provide a patch with a docstring and a documentation update? Thanks, Hans On Wed, Nov 25, 2009 at 11:23, Frode V. Fjeld wrote: > frode at netfonds.no (Frode V. Fjeld) writes: > >> (I can/could of course specialize process-request for my acceptor class >> using an unqualified method, and thus set up the dynamic environment >> just how I want it. However I would then just have to copy the full body >> of the standard process-request to insert a line or two inside the body >> of the handler-bind. I believe it's the purpose of a processing protocol >> to avoid having to do such things.) > > This didn't really work out in practice: cut'n'pasting the body of > process-request into a different package made it clear that > process-request can't really be replaced without breaking lots of > stuff. Also, modifying my dispatchers or handlers proved to be > impractical. So here's a diff detailing my suggestion in my previous > posting. It's simple, and seems to work well. > > Index: packages.lisp > =================================================================== > --- packages.lisp ? ? ? (revision 4474) > +++ packages.lisp ? ? ? (working copy) > @@ -168,6 +168,7 @@ > ? ? ? ? ? ?"DELETE-AUX-REQUEST-VALUE" > ? ? ? ? ? ?"DELETE-SESSION-VALUE" > ? ? ? ? ? ?"DISPATCH-EASY-HANDLERS" > + ? ? ? ? ?"DISPATCH-REQUEST" > ? ? ? ? ? ?"ESCAPE-FOR-HTML" > ? ? ? ? ? ?"EXECUTE-ACCEPTOR" > ? ? ? ? ? ?"GET-PARAMETER" > Index: request.lisp > =================================================================== > --- request.lisp ? ? ? ?(revision 4474) > +++ request.lisp ? ? ? ?(working copy) > @@ -210,6 +210,10 @@ > ? ? ? ? ;; we assume it's not our fault... > ? ? ? ? (setf (return-code*) +http-bad-request+))))) > > +(defmethod dispatch-request (request) > + ?(funcall (acceptor-request-dispatcher *acceptor*) > + ? ? ? ? ?request)) > + > ?(defmethod process-request (request) > ? "Standard implementation for processing a request. ?You should not > ?change or replace this functionality unless you know what you're > @@ -227,7 +231,7 @@ > ? ? ? ? ? ? ? ? ? ? ?;; skip dispatch if bad request > ? ? ? ? ? ? ? ? ? ? ?(when (eql (return-code *reply*) +http-ok+) > ? ? ? ? ? ? ? ? ? ? ? ?;; now do the work > - ? ? ? ? ? ? ? ? ? ? ? (funcall (acceptor-request-dispatcher *acceptor*) *request*))))) > + ? ? ? ? ? ? ? ? ? ? ? (dispatch-request request))))) > ? ? ? ? ? ? ? (when error > ? ? ? ? ? ? ? ? (setf (return-code *reply*) > ? ? ? ? ? ? ? ? ? ? ? +http-internal-server-error+)) > > > > -- > Frode V. Fjeld > Netfonds Bank ASA > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From frode at netfonds.no Wed Nov 25 12:14:40 2009 From: frode at netfonds.no (Frode V. Fjeld) Date: Wed, 25 Nov 2009 13:14:40 +0100 Subject: [hunchentoot-devel] Specializing process-request References: <82vdgzvvvl.fsf@netfonds.no> <82k4xex5r6.fsf@netfonds.no> Message-ID: <82fx82x0lr.fsf@netfonds.no> Hans H?bner writes: > the patch looks good. Can you please provide a patch with a docstring > and a documentation update? Sure, I'm attaching a patch. I tweaked the docstring for process-request also. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: -------------- next part -------------- This patch is simple in the sense that it provides an extra configuration point without otherwise interfering with the API. BTW, having now looked into using process-request as a "configuration point", I would suggest that there should be some refactoring: Move the pieces of it that are intrinsic to hunchentoot, such as bindings etc. for *tmp-files*, *headers-sent*, *request*, handler-done, and *within-request-p* [why not just (not (null *request*))?] into process-connection (or some internal defun), and keep just the stuff that implements the default condition handling. The point would be to have two well-defined configuration points: process-request that does condition handinling, and dispatch-request that is within the scope of said condition handling. -- Frode V. Fjeld Netfonds Bank ASA From mackram at gmail.com Wed Nov 25 18:02:26 2009 From: mackram at gmail.com (Mackram Raydan) Date: Wed, 25 Nov 2009 20:02:26 +0200 Subject: [hunchentoot-devel] Check regarding SSL with hunchentoot Message-ID: <37654d130911251002t5e10ef3fwb8ddc7c3b9bac4ff@mail.gmail.com> Hey Everyone, I wanted to check regarding the use of SSL with hunchentoot behind a nginx proxy. Specifically when it comes to encryption key length is there anything specific that we should take care of and is hunchentoot SSL ready for a production system. Thanks for any help you can provide. Mackram Raydan Company: www.imagimate.com Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: From vseloved at gmail.com Wed Nov 25 20:39:28 2009 From: vseloved at gmail.com (Vsevolod Dyomkin) Date: Wed, 25 Nov 2009 22:39:28 +0200 Subject: [hunchentoot-devel] Check regarding SSL with hunchentoot In-Reply-To: <37654d130911251002t5e10ef3fwb8ddc7c3b9bac4ff@mail.gmail.com> References: <37654d130911251002t5e10ef3fwb8ddc7c3b9bac4ff@mail.gmail.com> Message-ID: <89dc7c5b0911251239x78baa49vd6199f2c0bfd63@mail.gmail.com> Hi Mackram, I'm using it behind nginx, but I terminate SSL on nginx (because they are running on the same server and I don't see any reason to create excess load on Hunchentoot). If you have any specific questions, don't hesitate to ask (maybe, directly), Best regards, Vsevolod On Wed, Nov 25, 2009 at 8:02 PM, Mackram Raydan wrote: > Hey Everyone, > > I wanted to check regarding the use of SSL with hunchentoot behind a nginx > proxy. Specifically when it comes to encryption key length is there anything > specific that we should take care of and is hunchentoot SSL ready for a > production system. > > Thanks for any help you can provide. > > Mackram Raydan > > Company: www.imagimate.com > Website: www.trailoflight.net > > "An invasion of armies can be resisted, but not an idea whose time has > come." Victor Hugo > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Mon Nov 30 13:16:10 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 30 Nov 2009 14:16:10 +0100 Subject: [hunchentoot-devel] Specializing process-request In-Reply-To: <82fx82x0lr.fsf@netfonds.no> References: <82vdgzvvvl.fsf@netfonds.no> <82k4xex5r6.fsf@netfonds.no> <82fx82x0lr.fsf@netfonds.no> Message-ID: Frode, On Wed, Nov 25, 2009 at 13:14, Frode V. Fjeld wrote: > Hans H?bner writes: > >> the patch looks good. ?Can you please provide a patch with a docstring >> and a documentation update? > > Sure, I'm attaching a patch. I tweaked the docstring for process-request > also. I have committed that patch to the Subversion repository. > BTW, having now looked into using process-request as a "configuration > point", I would suggest that there should be some refactoring: Move the > pieces of it that are intrinsic to hunchentoot, such as bindings > etc. for *tmp-files*, *headers-sent*, *request*, handler-done, and > *within-request-p* [why not just (not (null *request*))?] into > process-connection (or some internal defun), and keep just the stuff > that implements the default condition handling. > > The point would be to have two well-defined configuration points: > process-request that does condition handinling, and dispatch-request > that is within the scope of said condition handling. I'd be fine with such a refactoring and cleanup! I have not reviewed the code myself, but replacing *within-request-p* with an access to *request* sounds like a worthwhile simplification. -Hans