From yarek.kowalik at gmail.com Mon May 5 18:58:50 2008 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Mon, 5 May 2008 11:58:50 -0700 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: References: Message-ID: I'm a lisp newbie, but I am very determined to quickly learn it. I'm using most recent SBCL with Weblocks. I'm connecting to my SBCL using slime. I'm intrested in examining the ession objects - what's the most effective way of examining the session object? Here is what I have tried, but obviously I am doing something wrong: ------------------- CL-USER> (weblocks:active-sessions) (#) CL-USER> (hunchentoot:session-value :remote-addr (#) ) ; in: LAMBDA NIL ; (#) ; ; caught ERROR: ; illegal function call ; ; compilation unit finished ; caught 1 ERROR condition ------------------- ... at which point I get into the debugger... What am I doing wrong? Any help would be greatly appreciated. Thanks, Yarek From xach at xach.com Mon May 5 19:03:21 2008 From: xach at xach.com (Zach Beane) Date: Mon, 5 May 2008 15:03:21 -0400 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: References: Message-ID: <20080505190321.GC30455@xach.com> On Mon, May 05, 2008 at 11:58:50AM -0700, Yarek Kowalik wrote: > I'm a lisp newbie, but I am very determined to quickly learn it. > > I'm using most recent SBCL with Weblocks. I'm connecting to my SBCL > using slime. I'm intrested in examining the ession objects - what's > the most effective way of examining the session object? > > Here is what I have tried, but obviously I am doing something wrong: > > ------------------- > CL-USER> (weblocks:active-sessions) > (#) > CL-USER> (hunchentoot:session-value :remote-addr > (#) ) > ; in: LAMBDA NIL > ; (#) > ; > ; caught ERROR: > ; illegal function call > ; > ; compilation unit finished > ; caught 1 ERROR condition > ------------------- > > ... at which point I get into the debugger... What am I doing wrong? Using too many parentheses for the second argument, and using unreadable object syntax. Here's something that might work instead: (hunchentoot:session-value :remote-addr (first (weblocks:active-sessions))) Zach From yarek.kowalik at gmail.com Mon May 5 19:20:47 2008 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Mon, 5 May 2008 12:20:47 -0700 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: References: <20080505190321.GC30455@xach.com> Message-ID: Ok, I get the part about the extra paranthesis and how repl works. I can do this now: ---- CL-USER> (second (weblocks:active-sessions)) # CL-USER> (hunchentoot:session-value :remote-ip-addr # ) NIL NIL ---- Cool! But that still leaves the question about why I'm getting 'NIL' value for an IP address (or for that matter, any session object slot -- I tried session-id, session-string, user-agent, remote-addr, session-start, session-date)? Thanks, Yarek On Mon, May 5, 2008 at 12:13 PM, Yarek Kowalik wrote: > Hi Zach, > > Thanks for your help!!! > > For the second argument I'm using what SLIME gives me for object > representation (copied object using middle mouse button). If I want > to use the REPL object representation, what would I need to do? > > For the command you recommended, I get this: > > ---- > CL-USER> > (hunchentoot:session-value :remote-addr (first > (weblocks:active-sessions))) > NIL > NIL > ---- > > Is that OK? I'm getting the same values from both the local host and > a remote Windows box -- I was expecting two different IP addresses > for each of the sessions I have now (first and second in the active > session list). > > Yarek > > > > > > On Mon, May 5, 2008 at 12:03 PM, Zach Beane wrote: > > > > On Mon, May 05, 2008 at 11:58:50AM -0700, Yarek Kowalik wrote: > > > I'm a lisp newbie, but I am very determined to quickly learn it. > > > > > > I'm using most recent SBCL with Weblocks. I'm connecting to my SBCL > > > using slime. I'm intrested in examining the ession objects - what's > > > the most effective way of examining the session object? > > > > > > Here is what I have tried, but obviously I am doing something wrong: > > > > > > ------------------- > > > CL-USER> (weblocks:active-sessions) > > > (#) > > > CL-USER> (hunchentoot:session-value :remote-addr > > > (#) ) > > > ; in: LAMBDA NIL > > > ; (#) > > > ; > > > ; caught ERROR: > > > ; illegal function call > > > ; > > > ; compilation unit finished > > > ; caught 1 ERROR condition > > > ------------------- > > > > > > ... at which point I get into the debugger... What am I doing wrong? > > > > Using too many parentheses for the second argument, and using > > unreadable object syntax. > > > > Here's something that might work instead: > > > > (hunchentoot:session-value :remote-addr (first > > (weblocks:active-sessions))) > > > > Zach > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > From yarek.kowalik at gmail.com Mon May 5 19:13:29 2008 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Mon, 5 May 2008 12:13:29 -0700 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: <20080505190321.GC30455@xach.com> References: <20080505190321.GC30455@xach.com> Message-ID: Hi Zach, Thanks for your help!!! For the second argument I'm using what SLIME gives me for object representation (copied object using middle mouse button). If I want to use the REPL object representation, what would I need to do? For the command you recommended, I get this: ---- CL-USER> (hunchentoot:session-value :remote-addr (first (weblocks:active-sessions))) NIL NIL ---- Is that OK? I'm getting the same values from both the local host and a remote Windows box -- I was expecting two different IP addresses for each of the sessions I have now (first and second in the active session list). Yarek On Mon, May 5, 2008 at 12:03 PM, Zach Beane wrote: > > On Mon, May 05, 2008 at 11:58:50AM -0700, Yarek Kowalik wrote: > > I'm a lisp newbie, but I am very determined to quickly learn it. > > > > I'm using most recent SBCL with Weblocks. I'm connecting to my SBCL > > using slime. I'm intrested in examining the ession objects - what's > > the most effective way of examining the session object? > > > > Here is what I have tried, but obviously I am doing something wrong: > > > > ------------------- > > CL-USER> (weblocks:active-sessions) > > (#) > > CL-USER> (hunchentoot:session-value :remote-addr > > (#) ) > > ; in: LAMBDA NIL > > ; (#) > > ; > > ; caught ERROR: > > ; illegal function call > > ; > > ; compilation unit finished > > ; caught 1 ERROR condition > > ------------------- > > > > ... at which point I get into the debugger... What am I doing wrong? > > Using too many parentheses for the second argument, and using > unreadable object syntax. > > Here's something that might work instead: > > (hunchentoot:session-value :remote-addr (first > (weblocks:active-sessions))) > > Zach > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From xach at xach.com Mon May 5 22:09:58 2008 From: xach at xach.com (Zach Beane) Date: Mon, 5 May 2008 18:09:58 -0400 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: References: <20080505190321.GC30455@xach.com> Message-ID: <20080505220958.GD30455@xach.com> On Mon, May 05, 2008 at 12:13:29PM -0700, Yarek Kowalik wrote: > Is that OK? I'm getting the same values from both the local host and > a remote Windows box -- I was expecting two different IP addresses > for each of the sessions I have now (first and second in the active > session list). Sorry, I have no idea about sessions. I've never used them with hunchentoot. Zach From edi at agharta.de Mon May 5 22:22:08 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 05 May 2008 18:22:08 -0400 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: (Yarek Kowalik's message of "Mon, 5 May 2008 12:13:29 -0700") References: <20080505190321.GC30455@xach.com> Message-ID: On Mon, 5 May 2008 12:13:29 -0700, "Yarek Kowalik" wrote: > ---- > CL-USER> > (hunchentoot:session-value :remote-addr (first > (weblocks:active-sessions))) > NIL > NIL > ---- > > Is that OK? I'm getting the same values from both the local host > and a remote Windows box -- I was expecting two different IP > addresses for each of the sessions I have now (first and second in > the active session list). SESSION-VALUE should return whatever (SETF SESSION-VALUE) put there. So, the question actually is whether someone wrote a session value :REMOTE-ADDR to this session. Did you do that? Did Weblocks do that? What do you get if you inspect the corresponding session objects? (The session object maintains an alist of session values in the SESSION-DATA slot.) Edi. From yarek.kowalik at gmail.com Tue May 6 16:48:02 2008 From: yarek.kowalik at gmail.com (Yarek Kowalik) Date: Tue, 6 May 2008 09:48:02 -0700 Subject: [hunchentoot-devel] Newbie question - how to examine session object? In-Reply-To: References: <20080505190321.GC30455@xach.com> Message-ID: I'm guessing that's not being set anywhere... I'm checking Weblocks now. Thanks for the feedback. Cheeers, Yarek On Mon, May 5, 2008 at 3:22 PM, Edi Weitz wrote: > On Mon, 5 May 2008 12:13:29 -0700, "Yarek Kowalik" wrote: > > > ---- > > CL-USER> > > (hunchentoot:session-value :remote-addr (first > > (weblocks:active-sessions))) > > NIL > > NIL > > ---- > > > > Is that OK? I'm getting the same values from both the local host > > and a remote Windows box -- I was expecting two different IP > > addresses for each of the sessions I have now (first and second in > > the active session list). > > SESSION-VALUE should return whatever (SETF SESSION-VALUE) put there. > So, the question actually is whether someone wrote a session value > :REMOTE-ADDR to this session. Did you do that? Did Weblocks do that? > What do you get if you inspect the corresponding session objects? > (The session object maintains an alist of session values in the > SESSION-DATA slot.) > > Edi. > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From geocar at gmail.com Thu May 8 01:39:22 2008 From: geocar at gmail.com (Geo Carncross) Date: Wed, 7 May 2008 21:39:22 -0400 Subject: [hunchentoot-devel] hunchentoot ecl support Message-ID: <527511140805071839n20137f4i79148a94ccdceedf@mail.gmail.com> Hi, I've successfully gotten hunchentoot to run under ECL. I'm attaching a port-ecl.lisp which implements the necessary machinery for hunchentoot. In case you have trouble reading the attachment, I've also uploaded it to: http://geocar.googlepages.com/port-ecl.lisp Note, this has required patches to ECL and TRIVIAL-GRAY-STREAMS. The relevent patches are already checked into ECL's CVS. The FLEXI-STREAMS patches, and other patches at: http://nasobem.i-networx.de/hunchentoot-patches/ that were brought up in the thread at: http://common-lisp.net/pipermail/tbnl-devel/2008-March/001789.html are *not* required. The gray streams infrastructure (among other things) has been reworked very recently in ECL which has made this patch very straightforward. So far, I've gotten a few test pages to show up, but would like to know how I can get support included into hunchentoot. -------------- next part -------------- A non-text attachment was scrubbed... Name: port-ecl.lisp Type: application/octet-stream Size: 7607 bytes Desc: not available URL: From hans at huebner.org Thu May 8 04:33:14 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 8 May 2008 06:33:14 +0200 Subject: [hunchentoot-devel] hunchentoot ecl support In-Reply-To: <527511140805071839n20137f4i79148a94ccdceedf@mail.gmail.com> References: <527511140805071839n20137f4i79148a94ccdceedf@mail.gmail.com> Message-ID: Geo, as announced a few weeks ago, we will be moving Hunchentoot to use bordeaux-threads and usocket in the near future. I am sorry to hear that you have invested in the old code base already. If you could send a patch against the branch I am working on (svn://common-lisp.net/project/tbnl/svn/branches/hans), I will consider incorportating them and make them part of the upcoming release (a few weeks from now). If you need to hack usocket, please use the branch svn://common-lisp.net/project/usocket/svn/usocket/branches/hans to do so and send me patches. I have made some performance enhancements in flexi-streams that are not yet in the main release, available at svn://common-lisp.net/project/flexi-streams/svn/branches/hans Sorry for the additional work. -Hans On Thu, May 8, 2008 at 3:39 AM, Geo Carncross wrote: > Hi, > > I've successfully gotten hunchentoot to run under ECL. I'm attaching a > port-ecl.lisp which implements the necessary machinery for > hunchentoot. In case you have trouble reading the attachment, I've > also uploaded it to: > > http://geocar.googlepages.com/port-ecl.lisp > > Note, this has required patches to ECL and TRIVIAL-GRAY-STREAMS. The > relevent patches are already checked into ECL's CVS. The FLEXI-STREAMS > patches, and other patches at: > > http://nasobem.i-networx.de/hunchentoot-patches/ > > that were brought up in the thread at: > > http://common-lisp.net/pipermail/tbnl-devel/2008-March/001789.html > > are *not* required. The gray streams infrastructure (among other > things) has been reworked very recently in ECL which has made this > patch very straightforward. > > So far, I've gotten a few test pages to show up, but would like to > know how I can get support included into hunchentoot. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From geocar at gmail.com Thu May 8 11:35:09 2008 From: geocar at gmail.com (Geo Carncross) Date: Thu, 8 May 2008 07:35:09 -0400 Subject: [hunchentoot-devel] hunchentoot ecl support In-Reply-To: References: <527511140805071839n20137f4i79148a94ccdceedf@mail.gmail.com> Message-ID: <527511140805080435xa10e543ya462329777482c46@mail.gmail.com> On Thu, May 8, 2008 at 12:33 AM, Hans H?bner wrote: > Geo, > > as announced a few weeks ago, we will be moving Hunchentoot to use > bordeaux-threads and usocket in the near future. I am sorry to hear > that you have invested in the old code base already. If you could > send a patch against the branch I am working on > (svn://common-lisp.net/project/tbnl/svn/branches/hans), I will > consider incorportating them and make them part of the upcoming > release (a few weeks from now). There's a bug in hunchentoot, and :hunchentoot-no-ssl doesn't work. I've attached hunch-ssl.patch that corects the problem. I've also uploaded it to: http://geocar.googlepages.com/hunch-ssl.patch I've split the backtrace into a separate patch, attached and uploaded to: http://geocar.googlepages.com/hunch-ecl-backtrace.patch > If you need to hack usocket, please use the branch > svn://common-lisp.net/project/usocket/svn/usocket/branches/hans to do > so and send me patches. ECL doesn't have some SBCL errors, and the ffi signatures are wrong. http://geocar.googlepages.com/usocket-ecl.diff > I have made some performance enhancements in flexi-streams that are > not yet in the main release, available at > svn://common-lisp.net/project/flexi-streams/svn/branches/hans They seem to work fine! > Sorry for the additional work. No problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: hunch-ssl.patch Type: application/octet-stream Size: 1141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hunch-ecl-backtrace.patch Type: application/octet-stream Size: 1631 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usocket-ecl.diff Type: application/octet-stream Size: 3343 bytes Desc: not available URL: From sergio.garcia at gmail.com Thu May 8 14:37:50 2008 From: sergio.garcia at gmail.com (Sergio Garcia) Date: Thu, 8 May 2008 16:37:50 +0200 Subject: [hunchentoot-devel] error computing the request object Message-ID: <34ec25750805080737v7180b56bx5776cad55c090983@mail.gmail.com> Hello, Im using utf-u as the default external format in my web application (yet another social news site). Some sites have started to add links to our site, passing the title of their news as a GET parameter in the link. The problem is that one of those sites is encoding the title string using iso-8859 encoding, which causes hunchentoot to return a "Your browser sent a request that this server could not understand." and a log error that looks like "Error when creating REQUEST object: Unexpected value #x20 in UTF-8 sequence.". Is there a way I can catch the error so that I can either to ignore the parameters or try to recompute the REQUEST object using iso-8859 encoding? Thanks Sergio -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu May 8 14:57:57 2008 From: edi at agharta.de (Edi Weitz) Date: Thu, 08 May 2008 10:57:57 -0400 Subject: [hunchentoot-devel] error computing the request object In-Reply-To: <34ec25750805080737v7180b56bx5776cad55c090983@mail.gmail.com> (Sergio Garcia's message of "Thu, 8 May 2008 16:37:50 +0200") References: <34ec25750805080737v7180b56bx5776cad55c090983@mail.gmail.com> Message-ID: On Thu, 8 May 2008 16:37:50 +0200, "Sergio Garcia" wrote: > Is there a way I can catch the error so that I can either to ignore > the parameters or try to recompute the REQUEST object using iso-8859 > encoding? With the current design this is a bit tricky, but you're lucky: Hans is currently re-working Hunchentoot's internal and in the next release the request parameters will be computed later when you can actually handle the error (I think). Edi. From sergio.garcia at gmail.com Fri May 9 18:25:00 2008 From: sergio.garcia at gmail.com (Sergio Garcia) Date: Fri, 9 May 2008 20:25:00 +0200 Subject: [hunchentoot-devel] error computing the request object In-Reply-To: References: <34ec25750805080737v7180b56bx5776cad55c090983@mail.gmail.com> Message-ID: <34ec25750805091125j3759f973pbca7b7fc5ed4af46@mail.gmail.com> On Thu, May 8, 2008 at 4:57 PM, Edi Weitz wrote: > > With the current design this is a bit tricky, but you're lucky: Hans > is currently re-working Hunchentoot's internal and in the next release > the request parameters will be computed later when you can actually > handle the error (I think). > > Edi. Thanks for the info, Edi (in the meantime I just brutally patched my hunchentoot to catch errors on the computation of get parameters and re-try it with an iso-8859 encoding :/ ) off-topic: I think it would be handy to have a add-get-param-to-url in hunchentoot. Like url-rewrite's one, but using hunchentoot-default-external-format for the encoding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Fri May 9 18:36:12 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 May 2008 14:36:12 -0400 Subject: [hunchentoot-devel] error computing the request object In-Reply-To: <34ec25750805091125j3759f973pbca7b7fc5ed4af46@mail.gmail.com> (Sergio Garcia's message of "Fri, 9 May 2008 20:25:00 +0200") References: <34ec25750805080737v7180b56bx5776cad55c090983@mail.gmail.com> <34ec25750805091125j3759f973pbca7b7fc5ed4af46@mail.gmail.com> Message-ID: On Fri, 9 May 2008 20:25:00 +0200, "Sergio Garcia" wrote: > off-topic: I think it would be handy to have a add-get-param-to-url > in hunchentoot. Like url-rewrite's one, but using > hunchentoot-default-external-format for the encoding. I agree. URL-REWRITE was written before the glory days of FLEXI-STREAMS, but it should simply use them now and there shouldn't be any code duplication between Hunchentoot and URL-REWRITE. Actually, as Hunchentoot seems to be the only consumer of URL-REWRITE, it's probably the cleanest solution to integrate URL-REWRITE into Hunchentoot. As part of The Big Cleanup. RSN! From tomasz.skutnik at gmail.com Sat May 10 20:53:34 2008 From: tomasz.skutnik at gmail.com (Tomasz Skutnik) Date: Sat, 10 May 2008 22:53:34 +0200 Subject: [hunchentoot-devel] Strange condition during error handling (possible double error?) Message-ID: <533c96720805101353w6586af6dlff1b03dd0d255f85@mail.gmail.com> Hi. For my development I've tried to setup hunchentoot error logging/condition handling that better suits taste. Here's my setup (code snippets to reduce word clutter): (setf hunchentoot:*catch-errors-p* nil hunchentoot::*log-lisp-backtraces-p* t hunchentoot::*log-lisp-errors-p* t hunchentoot::*log-lisp-warnings-p* t hunchentoot::*show-lisp-errors-p* t hunchentoot::*show-lisp-backtraces-p* t) (defgeneric maybe-log-condition (condition) (:documentation "This generic function is called whenever a condition CONDITION is about to be logged in an application. You might want to specialize it on specific condition classes to fine-tune error and warning logging in addition to Hunchentoot's *log-lisp-errors-p* and *log-lisp-warnings-p*.") (:method (condition) t)) (defmethod log-message :around (log-level fmt &rest args) (let ((*log-level* log-level) (*fmt* fmt) (condition (and args (car args)))) (declare (special *log-level* *fmt*)) (cond ((and condition (typep condition 'condition)) (when (maybe-log-condition condition) (call-next-method))) (t (call-next-method))))) (defmethod maybe-invoke-debugger ((condition sb-int:simple-stream-error)) ; muffle useless condition reporting (cond ((eql (search "/img/" (script-name *request*)) 0) (log-message :warn "ignored condition for ~a: ~a" (script-name *request*) condition)) (t (call-next-method)))) (defmethod maybe-log-condition ((condition sb-int:simple-stream-error)) nil) It's rather crude workaround for something that should probably be more tightly integrated into hunchentoot (customizable error/warning logging similar to maybe-invoke-debugger). Notice maybe-invoke-debugger specialized for sb-int:simple-stream-error. I've put that in my development setup because I've tried to silence Firefox related errors, which has nasty habit of dropping connection on favicon.ico retrieval (well, that's what I suspect; haven't check that theory with packet sniffer) that results in "Broken pipe" condition. So far all fine and dandy. But, for every such condition handled by my code hunchentoot logs following line: [2008-05-10 11:41:42 [ERROR]] Error while processing connection: The variable *REQUEST* is unbound. No more information available. So I've modified hunchentoot a little bit: diff -x '*.fasl' -r -u -w -B hunchentoot-0.15.6.orig/server.lisp hunchentoot-0.15.6/server.lisp --- hunchentoot-0.15.6.orig/server.lisp 2008-04-09 10:17:48.000000000 +0200 +++ hunchentoot-0.15.6/server.lisp 2008-04-21 22:25:33.000000000 +0200 @@ -282,6 +282,7 @@ (lambda (cond) (log-message *lisp-errors-log-level* "Error while processing connection: ~A" cond) + (log-message *lisp-errors-log-level* "~a" (get-backtrace cond)) (return-from process-connection))) (warning ;; log all warnings which aren't caught inside and got following: [2008-05-10 11:41:42 [ERROR]] Error while processing connection: The variable *REQUEST* is unbound. [2008-05-10 11:41:43 [ERROR]] 0: (SB-DEBUG::MAP-BACKTRACE #)[:EXTERNAL] 1: (SB-DEBUG:BACKTRACE 536870911 #) 2: (GET-BACKTRACE #) 3: ((LAMBDA (COND)) #) 4: ((LAMBDA (COND)) #)[:EXTERNAL] 5: (SIGNAL #)[:EXTERNAL] 6: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 7: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER # #.(SB-SYS:INT-SAP #XB51C1DF0) # (14)) 8: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER # #.(SB-SYS:INT-SAP #XB51C1DF0) # (14))[:EXTERNAL] 9: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB51C1A7C) #) 10: ("foreign function: call_into_lisp") 11: ("foreign function: funcall2") 12: ("foreign function: interrupt_internal_error") 13: ("foreign function: handle_trap") 14: ((SB-PCL::FAST-METHOD MAYBE-INVOKE-DEBUGGER (SB-INT:SIMPLE-STREAM-ERROR)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1)) #) 15: (SIGNAL #)[:EXTERNAL] 16: (ERROR SB-INT:SIMPLE-STREAM-ERROR)[:EXTERNAL] 17: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" # 32) 18: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" # 32)[:EXTERNAL] 19: (FORCE-OUTPUT #) 20: ((SB-PCL::FAST-METHOD SB-GRAY:STREAM-FORCE-OUTPUT (CHUNGA:CHUNKED-OUTPUT-STREAM)) # # #) 21: (FORCE-OUTPUT #) 22: (FORCE-OUTPUT #) 23: (HUNCHENTOOT::PROCESS-CONNECTION # #) 24: ((LAMBDA ())) 25: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 26: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]438)) 27: (SB-THREAD::CALL-WITH-MUTEX # #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER # :STATE 1) # T) 28: ((LAMBDA ())) 29: ("foreign function: call_into_lisp") 30: ("foreign function: funcall0") 31: ("foreign function: new_thread_trampoline") 32: ("foreign function: #xB7FD2240") Looking at the above backtrace and process-connection source code I wasn't able to figure out anything constructive. I'm stuck. It looks for me like double error (error during error handling), but what do I know? Can someone tell me what am I doing wrong? Can I avoid this "The variable *REQUEST* is unbound." error? Is this hunchentoot error or my silly mistake? Take into account that these are my first 40 or so hours with CL (not even mentioning Hunchentoot). I'm using SBCL 1.0.15 and Hunchentoot 0.15.6. Thanks Tomasz From edi at agharta.de Sat May 10 21:12:18 2008 From: edi at agharta.de (Edi Weitz) Date: Sat, 10 May 2008 23:12:18 +0200 Subject: [hunchentoot-devel] Strange condition during error handling (possible double error?) In-Reply-To: <533c96720805101353w6586af6dlff1b03dd0d255f85@mail.gmail.com> (Tomasz Skutnik's message of "Sat, 10 May 2008 22:53:34 +0200") References: <533c96720805101353w6586af6dlff1b03dd0d255f85@mail.gmail.com> Message-ID: On Sat, 10 May 2008 22:53:34 +0200, "Tomasz Skutnik" wrote: > Can someone tell me what am I doing wrong? In your method you're trying to unconditionally access the *REQUEST* variable which is only guaranteed to be bound to the current request object while a handler is executed. In fact, the errors you're trying to deal with happen before a request object is created. Edi. From tomasz.skutnik at gmail.com Sat May 10 22:01:27 2008 From: tomasz.skutnik at gmail.com (Tomasz Skutnik) Date: Sun, 11 May 2008 00:01:27 +0200 Subject: [hunchentoot-devel] Strange condition during error handling (possible double error?) In-Reply-To: References: <533c96720805101353w6586af6dlff1b03dd0d255f85@mail.gmail.com> Message-ID: <533c96720805101501y378f0eb2k14623ab365337c70@mail.gmail.com> > > In your method you're trying to unconditionally access the *REQUEST* > variable which is only guaranteed to be bound to the current request > object while a handler is executed. In fact, the errors you're trying > to deal with happen before a request object is created. > > Edi. Thanks Edi. You mean maybe-invoke-debugger? I've modified to look like this: (defmethod maybe-invoke-debugger ((condition sb-int:simple-stream-error)) ; muffle useless condition reporting (cond ((boundp '*request*) (cond ((eql (search "/img/" (script-name *request*)) 0) (log-message :warn "ignored condition for ~a: ~a" (script-name *request*) condition)) (t (call-next-method)))) (t nil))) That's probably what I meant (sorry for algolesque): - if *request* is bound (we're in handler): - if we're serving '/img/" -> ignore & log condition - otherwise -> call next method (i.e. invoke debugger) - otherwise (we're somewhere in hunchentoot internals) -> ignore condition Looks like that solves my problem - condition logged without backtrace, debugger silenced. Thanks again. Tomasz From ch at mr-co.de Mon May 12 09:48:14 2008 From: ch at mr-co.de (Christian Haselbach) Date: Mon, 12 May 2008 11:48:14 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header Message-ID: <4828125E.2090903@mr-co.de> Hello, I just stumbled upon an encoding problem with the authorization header. It cannot really handle UTF-8 encoded user names (or passwords), because base64:base64-string-to-string does not respect the used encoding. In my local instance, I fixed this by changing hunchentoot's authorization function as follows: (defun authorization (&optional (request *request*)) "Returns as two values the user and password \(if any) as encoded in the 'AUTHORIZATION' header. Returns NIL if there is no such header." (let* ((authorization (header-in :authorization request)) (start (and authorization (> (length authorization) 5) (string-equal "Basic" authorization :end2 5) (scan "\\S" authorization :start 5)))) (when start (let* ((auth-octets (base64:base64-string-to-usb8-array (subseq authorization start))) (auth (octets-to-string auth-octets :external-format *hunchentoot-default-external-format*))) (destructuring-bind (&optional user password) (split ":" auth) (values user password)))))) Or as patch: 286,288c286,293 < (destructuring-bind (&optional user password) < (split ":" (base64:base64-string-to-string (subseq authorization start))) < (values user password))))) --- > (let* ((auth-octets (base64:base64-string-to-usb8-array > (subseq authorization start))) > (auth (octets-to-string auth-octets > :external-format > *hunchentoot-default-external-format*))) > (destructuring-bind (&optional user password) > (split ":" auth) > (values user password)))))) Regards, Christian From tl at di.fc.ul.pt Mon May 12 20:53:51 2008 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Mon, 12 May 2008 21:53:51 +0100 Subject: [hunchentoot-devel] How to use Sessions ? Message-ID: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> Hello, Maybe someone can show me the light. I am trying to use hunchentoot's session feature but whenever (start-session) is called I get this error on the log: A function with declared result type NIL returned: MD5:UPDATE-MD5-BLOCK. Any ideas ? This is my first attempt to use session maybe I am missing something obvious. I am using huchentoot (0.15.6) chunga (0.3.0) cl-base64 (3.3.2) cl-fad (0.6.2) and flexi-streams (0.14.0) with sbcl 1.0.9. Thibault From ch-tbnl at bobobeach.com Mon May 12 21:00:56 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 12 May 2008 14:00:56 -0700 Subject: [hunchentoot-devel] How to use Sessions ? In-Reply-To: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> References: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> Message-ID: <5EDA9E4F-4E7F-4ED6-A552-25FCC5DEE628@bobobeach.com> You might start be inspecting the stack trace associated with this error. On May 12, 2008, at 1:53 PM, Thibault Langlois wrote: > Hello, > Maybe someone can show me the light. I am trying to use hunchentoot's > session feature but whenever (start-session) is called I get this > error on the log: > A function with declared result type NIL returned: MD5:UPDATE-MD5- > BLOCK. > > Any ideas ? > > This is my first attempt to use session maybe I am missing something > obvious. > > I am using huchentoot (0.15.6) chunga (0.3.0) cl-base64 (3.3.2) cl-fad > (0.6.2) and flexi-streams (0.14.0) with sbcl 1.0.9. > > Thibault > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Mon May 12 22:30:33 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 13 May 2008 00:30:33 +0200 Subject: [hunchentoot-devel] How to use Sessions ? In-Reply-To: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> (Thibault Langlois's message of "Mon, 12 May 2008 21:53:51 +0100") References: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> Message-ID: On Mon, 12 May 2008 21:53:51 +0100, "Thibault Langlois" wrote: > A function with declared result type NIL returned: > MD5:UPDATE-MD5-BLOCK. > > [...] > > I am using huchentoot (0.15.6) chunga (0.3.0) cl-base64 (3.3.2) > cl-fad (0.6.2) and flexi-streams (0.14.0) with sbcl 1.0.9. As MD5 is mentioned in your error message, the version of the MD5 library you're using might also be of interest. And, as Cyrus already said, a backtrace would help. From tl at di.fc.ul.pt Tue May 13 21:43:21 2008 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Tue, 13 May 2008 22:43:21 +0100 Subject: [hunchentoot-devel] How to use Sessions ? In-Reply-To: References: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> Message-ID: <45df8e510805131443nd78d851lea854776634fa3d6@mail.gmail.com> On Mon, May 12, 2008 at 11:30 PM, Edi Weitz wrote: > On Mon, 12 May 2008 21:53:51 +0100, "Thibault Langlois" wrote: > > > A function with declared result type NIL returned: > > MD5:UPDATE-MD5-BLOCK. > > > > [...] > > > > > I am using huchentoot (0.15.6) chunga (0.3.0) cl-base64 (3.3.2) > > cl-fad (0.6.2) and flexi-streams (0.14.0) with sbcl 1.0.9. > > As MD5 is mentioned in your error message, the version of the MD5 > library you're using might also be of interest. And, as Cyrus already > said, a backtrace would help. > > This was an oportunity to use hunchentoot debugging features :-) The error comes from a call to HUNCHENTOOT::MD5-HEX -> MD5:MD5SUM-SEQUENCE -> MD5:UPDATE-MD5-STATE . I am using this md5.lisp : http://www.pmsf.de/pub/download/MD5/md5.lisp I get the same error when calling (hunchentoot::md5-hex "foo") I am using sbcl 1.0.9: CL-USER> (lisp-implementation-version) "1.0.9" CL-USER> (let ((*print-length* nil)) (print *features*)) (:HUNCHENTOOT :HUNCHENTOOT-SBCL-DEBUG-PRINT-VARIABLE-ALIST :URL-REWRITE CFFI-FEATURES:X86 CFFI-FEATURES:UNIX :CFFI :CL-PPCRE :CL-FAD :FLEXI-STREAMS :SB-BSD-SOCKETS-ADDRINFO :ASDF :SB-THREAD :ANSI-CL :COMMON-LISP :SBCL :UNIX :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :ELF :LINUX :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK :COMPARE-AND-SWAP-VOP :UNWIND-TO-FRAME-AND-CALL-VOP :STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC) Googling I found someone that met a similar situation back in 2004 using sbcl 0.8.14 and tbnl :-/ Does anyone have a similar setup (versions of sbcl and hunchentoot) and get the same error [just do (hunchentoot::md5-hex "foo") for checking] ? The problem may be caused by the fact that I am using sb-unicode as indicated in http://www.cliki.net/MD5. The problem can be fixed using sb-md5 instead but I not sure it is the right thing to do. -- Thibault Langlois FCUL / DI From edi at agharta.de Tue May 13 21:57:48 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 13 May 2008 23:57:48 +0200 Subject: [hunchentoot-devel] How to use Sessions ? In-Reply-To: <45df8e510805131443nd78d851lea854776634fa3d6@mail.gmail.com> (Thibault Langlois's message of "Tue, 13 May 2008 22:43:21 +0100") References: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> <45df8e510805131443nd78d851lea854776634fa3d6@mail.gmail.com> Message-ID: On Tue, 13 May 2008 22:43:21 +0100, "Thibault Langlois" wrote: > I am using this md5.lisp : > http://www.pmsf.de/pub/download/MD5/md5.lisp What happens if you use the MD5 version from Kevin Rosenberg's website (which is the ASDF-INSTALL download from the CLiki website)? http://files.b9.com/md5/md5-1.8.5.tar.gz From tl at di.fc.ul.pt Tue May 13 22:28:42 2008 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Tue, 13 May 2008 23:28:42 +0100 Subject: [hunchentoot-devel] How to use Sessions ? In-Reply-To: References: <45df8e510805121353m5382f33el119966ddf655c765@mail.gmail.com> <45df8e510805131443nd78d851lea854776634fa3d6@mail.gmail.com> Message-ID: <45df8e510805131528g423d76fbqdf4f1712552bc8c5@mail.gmail.com> On Tue, May 13, 2008 at 10:57 PM, Edi Weitz wrote: > On Tue, 13 May 2008 22:43:21 +0100, "Thibault Langlois" wrote: > > > I am using this md5.lisp : > > http://www.pmsf.de/pub/download/MD5/md5.lisp > > What happens if you use the MD5 version from Kevin Rosenberg's website > (which is the ASDF-INSTALL download from the CLiki website)? > > http://files.b9.com/md5/md5-1.8.5.tar.gz > > Well... it works fine ! Thanks a lot. Thibault -- Thibault Langlois FCUL / DI From geocar at gmail.com Tue May 13 23:35:55 2008 From: geocar at gmail.com (Geo Carncross) Date: Tue, 13 May 2008 19:35:55 -0400 Subject: [hunchentoot-devel] usocket patch and ecl smallcons Message-ID: <527511140805131635s52fe5bfl25bd1dc30f972a87@mail.gmail.com> I haven't heard anything back about ecl and hunchentoot. Did I send it to the right place? I've started testing ECL's new smallcons support, and it needed patching usocket further; I haven't seen your svn repository accept the patch yet, so I'm submitting it again -this time with smallcons support. I've also included the relevant patches at: http://geocar.googlepages.com/usocket-ecl-2.diff I notice the hans svn of hunchentoot still doesn't build when :HUNCHENTOOT-NO-SSL is in effect. http://geocar.googlepages.com/hunch-nossl-2.patch fixes it. I also supplied a patch to support backtraces on ecl: http://geocar.googlepages.com/hunch-ecl-backtrace.patch Let me know if there's anything else I need to do. -------------- next part -------------- A non-text attachment was scrubbed... Name: usocket-ecl-2.diff Type: application/octet-stream Size: 3710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hunch-nossl-2.patch Type: application/octet-stream Size: 578 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hunch-ecl-backtrace.patch Type: application/octet-stream Size: 1631 bytes Desc: not available URL: From hans at huebner.org Wed May 14 04:45:54 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 14 May 2008 06:45:54 +0200 Subject: [hunchentoot-devel] usocket patch and ecl smallcons In-Reply-To: <527511140805131635s52fe5bfl25bd1dc30f972a87@mail.gmail.com> References: <527511140805131635s52fe5bfl25bd1dc30f972a87@mail.gmail.com> Message-ID: Hi Geo, I have been working on other stuff, but I plan to apply your patches to my branch in the coming days. -Hans On Wed, May 14, 2008 at 1:35 AM, Geo Carncross wrote: > I haven't heard anything back about ecl and hunchentoot. Did I send it > to the right place? > > I've started testing ECL's new smallcons support, and it needed > patching usocket further; I haven't seen your svn repository accept > the patch yet, so I'm submitting it again -this time with smallcons > support. > > I've also included the relevant patches at: > > http://geocar.googlepages.com/usocket-ecl-2.diff > > I notice the hans svn of hunchentoot still doesn't build when > :HUNCHENTOOT-NO-SSL is in effect. > > http://geocar.googlepages.com/hunch-nossl-2.patch > > fixes it. I also supplied a patch to support backtraces on ecl: > > http://geocar.googlepages.com/hunch-ecl-backtrace.patch > > Let me know if there's anything else I need to do. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at agharta.de Wed May 14 14:11:31 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 14 May 2008 16:11:31 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: <4828125E.2090903@mr-co.de> (Christian Haselbach's message of "Mon, 12 May 2008 11:48:14 +0200") References: <4828125E.2090903@mr-co.de> Message-ID: On Mon, 12 May 2008 11:48:14 +0200, Christian Haselbach wrote: > I just stumbled upon an encoding problem with the authorization > header. It cannot really handle UTF-8 encoded user names (or > passwords), because base64:base64-string-to-string does not respect > the used encoding. > > In my local instance, I fixed this by changing hunchentoot's > authorization function as follows: My understanding of the standard is that what you are doing is wrong. Basic authentication is described in RFC 2617 where it says that the "userid" and "password" parts must be "TEXT" and "TEXT" is defined in RFC 2616 as "any octet", /but/ "words of *TEXT may contain characters from character sets other than ISO-8859-1 only when encoded according to the rules of RFC 2047." So, you'd have to add support for proper RFC 2047 parsing to make the function deal with this correctly. (And I'd say that that would probably be worth its own library, maybe based on FLEXI-STREAMS.) > Or as patch: BTW, note that your email program rendered the patch unusable. Thanks, Edi. From ch at mr-co.de Wed May 14 19:10:26 2008 From: ch at mr-co.de (Christian Haselbach) Date: Wed, 14 May 2008 21:10:26 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: References: <4828125E.2090903@mr-co.de> Message-ID: <482B3922.5030604@mr-co.de> Edi Weitz wrote: > My understanding of the standard is that what you are doing is wrong. > I guess, you are right. > So, you'd have to add support for proper RFC 2047 parsing to make the > function deal with this correctly. (And I'd say that that would > probably be worth its own library, maybe based on FLEXI-STREAMS.) > Well, yes, looks like it. It seems to be a bit overprotective to have something base64 encoded and then again encoded inside, which might again use base64. Regards, Christian From edi at agharta.de Wed May 14 21:42:24 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 14 May 2008 23:42:24 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: <482B3922.5030604@mr-co.de> (Christian Haselbach's message of "Wed, 14 May 2008 21:10:26 +0200") References: <4828125E.2090903@mr-co.de> <482B3922.5030604@mr-co.de> Message-ID: On Wed, 14 May 2008 21:10:26 +0200, Christian Haselbach wrote: >> So, you'd have to add support for proper RFC 2047 parsing to make >> the function deal with this correctly. (And I'd say that that >> would probably be worth its own library, maybe based on >> FLEXI-STREAMS.) >> > Well, yes, looks like it. It seems to be a bit overprotective to > have something base64 encoded and then again encoded inside, which > might again use base64. And, BTW, it probably won't buy you much unless the main browsers play along. I just tried with Firefox 2.0 and if you enter characters as login or password which aren't in Latin-1, Firefox simply sends the lower octet of each character's code point. Not very helpful... From ch at mr-co.de Wed May 14 21:55:07 2008 From: ch at mr-co.de (Christian Haselbach) Date: Wed, 14 May 2008 23:55:07 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: References: <4828125E.2090903@mr-co.de> <482B3922.5030604@mr-co.de> Message-ID: <482B5FBB.6090903@mr-co.de> Edi Weitz wrote: > And, BTW, it probably won't buy you much unless the main browsers play > along. I just tried with Firefox 2.0 and if you enter characters as > login or password which aren't in Latin-1, Firefox simply sends the > lower octet of each character's code point. Not very helpful.. That's no big problem (at this point), because the header is written by the javascript client. That's also the reason it works for me with the patch I sent. But now it only works in violation of the standards, as you pointed out. So I just have to fix this in the javascript client, which I have control over. Regards, Christian From luca at pca.it Wed May 14 22:13:46 2008 From: luca at pca.it (Luca Capello) Date: Thu, 15 May 2008 00:13:46 +0200 Subject: [hunchentoot-devel] [PATCH] Hunchentoot must depends on FLEXI-STREAMS Message-ID: <87abiso7ol.fsf@gismo.pca.it> Hi there! Please Cc: me, I'm not subscribed to the list and I'm posting from Gmane. Moreover, please ignore this message if it has been already answered, but I cannot find any reference of it. Working on the Debian package for Hunchentoot, if I'm correct I found that while Hunchentoot depends on FLEXI-STREAMS, this dependency is present in the packages.lisp file but not in the ASDF one. This dependency, however, is implicitly satisfied in all CLs but LispWorks: in fact, CL+SSL (required unless on LispWorks) depends on FLEXI-STREAMS. From a quick view, I guess that if you want to use Hunchentoot without SSL support this will miss the FLEXI-STREAMS dependency as well. The following patch unconditionally adds the dependency to FLEXI-STREAMS and it's untested since I don't have LispWorks. --8<---------------cut here---------------start------------->8--- --- hunchentoot-0.15.6.ORIG/hunchentoot.asd 2008-04-09 10:17:48.000000000 +0200 +++ hunchentoot-0.15.6/hunchentoot.asd 2008-05-15 00:05:49.000000000 +0200 @@ -48,6 +48,7 @@ :cl-fad :cl-ppcre #-(or :lispworks :hunchentoot-no-ssl) :cl+ssl + :flexi-streams :md5 :rfc2388 #+:sbcl :sb-bsd-sockets --8<---------------cut here---------------end--------------->8--- Comments? Thx, bye, Gismo / Luca -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From edi at agharta.de Wed May 14 23:07:00 2008 From: edi at agharta.de (Edi Weitz) Date: Thu, 15 May 2008 01:07:00 +0200 Subject: [hunchentoot-devel] [PATCH] Hunchentoot must depends on FLEXI-STREAMS In-Reply-To: <87abiso7ol.fsf@gismo.pca.it> (Luca Capello's message of "Thu, 15 May 2008 00:13:46 +0200") References: <87abiso7ol.fsf@gismo.pca.it> Message-ID: On Thu, 15 May 2008 00:13:46 +0200, Luca Capello wrote: > Working on the Debian package for Hunchentoot, if I'm correct I > found that while Hunchentoot depends on FLEXI-STREAMS, this > dependency is present in the packages.lisp file but not in the ASDF > one. A system dependency cannot be expressed in a package declaration. http://weitz.de/packages.html > This dependency, however, is implicitly satisfied in all CLs but > LispWorks: in fact, CL+SSL (required unless on LispWorks) depends on > FLEXI-STREAMS. From a quick view, I guess that if you want to use > Hunchentoot without SSL support this will miss the FLEXI-STREAMS > dependency as well. It won't. Hunchentoot depends on Chunga which in turn depends on FLEXI-STREAMS. Thanks, Edi. From nallen05 at gmail.com Mon May 19 15:41:47 2008 From: nallen05 at gmail.com (Nick Allen) Date: Mon, 19 May 2008 17:41:47 +0200 Subject: [hunchentoot-devel] hunchentoot + nginx Message-ID: is anyone out there using hunchentoot behind nginx? if so would they be willing to post any pointers / experiences / lessons learned / reasons not to? take care Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch at mr-co.de Mon May 19 19:43:24 2008 From: ch at mr-co.de (Christian Haselbach) Date: Mon, 19 May 2008 21:43:24 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: References: <4828125E.2090903@mr-co.de> Message-ID: <4831D85C.7030804@mr-co.de> Edi Weitz wrote: > So, you'd have to add support for proper RFC 2047 parsing to make the > function deal with this correctly. (And I'd say that that would > probably be worth its own library, maybe based on FLEXI-STREAMS.) > I tried it and called it cl-rf2047 and can be found at http://mr-co.de/projects/cl-rfc2047/ Though, I guess you do not want to add such a young library from someone with limited common lisp experience to the project's dependencies. > BTW, note that your email program rendered the patch unusable. > > Thanks for the hint. This time I attached the patch. Regards, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: hunchentoot-auth-rfc2047.patch Type: text/x-diff Size: 1472 bytes Desc: not available URL: From edi at agharta.de Tue May 20 06:45:46 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 20 May 2008 08:45:46 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: <4831D85C.7030804@mr-co.de> (Christian Haselbach's message of "Mon, 19 May 2008 21:43:24 +0200") References: <4828125E.2090903@mr-co.de> <4831D85C.7030804@mr-co.de> Message-ID: On Mon, 19 May 2008 21:43:24 +0200, Christian Haselbach wrote: > I tried it and called it cl-rf2047 and can be found at > http://mr-co.de/projects/cl-rfc2047/ I haven't looked at everything in detail, but it looks good at first sight. One comment: I'd make the two regular expression variables constants and I'd replace the expression (string+ *decoded-line-regexp* "(" *crlfsp* *decoded-line-regexp* ")*") with #.(string+ +decoded-line-regexp+ "(" +crlfsp+ +decoded-line-regexp+ ")*") (You'll have to wrap the definition of STRING+ with EVAL-WHEN if you want to keep everything in one file.) > Though, I guess you do not want to add such a young library from > someone with limited common lisp experience to the project's > dependencies. As I said in a previous reply, even Mozilla (which I think is one of the more standards-compliant browsers) doesn't seem to use RFC 2047, so it probably doesn't make much sense to make this an integral part of Hunchentoot (not to mention that it's easy to add if you need it), but I'll add a link to the website (and to Drakma's as well). Thanks, Edi. From ch at mr-co.de Tue May 20 21:56:56 2008 From: ch at mr-co.de (Christian Haselbach) Date: Tue, 20 May 2008 23:56:56 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: References: <4828125E.2090903@mr-co.de> <4831D85C.7030804@mr-co.de> Message-ID: <48334928.1050706@mr-co.de> Edi Weitz wrote: > As I said in a previous reply, even Mozilla (which I think is one of > the more standards-compliant browsers) doesn't seem to use RFC 2047, > so it probably doesn't make much sense to make this an integral part > of Hunchentoot (not to mention that it's easy to add if you need it), > but I'll add a link to the website (and to Drakma's as well). > That's true. Thanks for the tips and the links. I just rechecked how twitter does it for their REST API. They seem not allow non-ASCII characters. Regards, Christian From leslie.polzer at gmx.net Wed May 21 07:21:40 2008 From: leslie.polzer at gmx.net (Leslie P. Polzer) Date: Wed, 21 May 2008 09:21:40 +0200 (CEST) Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: <48334928.1050706@mr-co.de> References: <4828125E.2090903@mr-co.de> <4831D85C.7030804@mr-co.de> <48334928.1050706@mr-co.de> Message-ID: <63622.88.73.205.24.1211354500.squirrel@mail.stardawn.org> > I just rechecked how twitter does it for their REST API. They seem not > allow non-ASCII characters. I like the approach of having a separate login name and nickname (the SimpleMachines Forum does this, for example). Leslie From edi at agharta.de Wed May 21 14:55:48 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 21 May 2008 16:55:48 +0200 Subject: [hunchentoot-devel] New release 0.15.7 (and also FLEXI-STREAMS 0.15.0) Message-ID: This is a tiny change which should improve Hunchentoot's performance. Incidentally, if you're concerned about performance, you might consider giving FLEXI-STREAMS 0.15.0 a try which was also released today. http://weitz.de/files/hunchentoot.tar.gz http://weitz.de/files/flexi-streams.tar.gz I'd also recommend to everyone interested in Hunchentoot's future directions to check out Hans' current version from here http://trac.common-lisp.net/tbnl/browser/branches/hans and to play with it. This version needs an updated Chunga (at least 0.4.2): http://weitz.de/files/chunga.tar.gz Edi. From avodonosov at yandex.ru Thu May 22 09:41:45 2008 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Thu, 22 May 2008 13:41:45 +0400 Subject: [hunchentoot-devel] hunchentoot + nginx In-Reply-To: 9110000000085923477 References: 9110000000085923477 Message-ID: <3442111211449305@webmail12.yandex.ru> Hi, Nick. I'm using hunchentoot behind nginx, but not to say I've learned any lessons. It works (why not?). Good luck, -Anton 19.05.08, 19:41, "Nick Allen" : >is anyone out there using hunchentoot behind nginx? > >if so would they be willing to post any pointers / experiences / lessons learned / reasons not to? > >take care > >Nick From nallen05 at gmail.com Thu May 22 11:49:17 2008 From: nallen05 at gmail.com (Nick Allen) Date: Thu, 22 May 2008 13:49:17 +0200 Subject: [hunchentoot-devel] hunchentoot + nginx In-Reply-To: <3442111211449305@webmail12.yandex.ru> References: <3442111211449305@webmail12.yandex.ru> Message-ID: just started using it (nginx + hunchentoot) and nginx seems to good to be true (fast, easy to set up) there's not reason why it shouldn't work that I know of, I'm just sys-admin retarded and always assume I missed something ;-) take care Nick On Thu, May 22, 2008 at 11:41 AM, Anton Vodonosov wrote: > Hi, Nick. I'm using hunchentoot behind nginx, but not to say I've learned > any lessons. It works (why not?). > > Good luck, > -Anton > > 19.05.08, 19:41, "Nick Allen" : > >is anyone out there using hunchentoot behind nginx? > > > >if so would they be willing to post any pointers / experiences / lessons > learned / reasons not to? > > > >take care > > > >Nick > _______________________________________________ > 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 ch at mr-co.de Thu May 22 18:37:09 2008 From: ch at mr-co.de (Christian Haselbach) Date: Thu, 22 May 2008 20:37:09 +0200 Subject: [hunchentoot-devel] Encoding issues in auhtorization header In-Reply-To: <63622.88.73.205.24.1211354500.squirrel@mail.stardawn.org> References: <4828125E.2090903@mr-co.de> <4831D85C.7030804@mr-co.de> <48334928.1050706@mr-co.de> <63622.88.73.205.24.1211354500.squirrel@mail.stardawn.org> Message-ID: <4835BD55.8040308@mr-co.de> Leslie P. Polzer wrote: > I like the approach of having a separate login name and nickname > (the SimpleMachines Forum does this, for example). > > We get a bit OT here. The display name + login name approach is common and ok for things like Jabber, where the client stores this information for you. But it is yet another detail the user has to remeber. A lot of applications use the e-mail address as login, which is quite sensible. But this also means that the application knows your e-mail address, which is not necessarily what you want. In short: I'd like to give the user as much choice as possible and at most as much complexity as needed. Anyway, I've now also got a patch for jQuery, to send RFC2047 compliant auth header. :) I'll publish it soon on the cl-rfc2047 page. Regards, Christian From edi at agharta.de Mon May 26 14:39:07 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 26 May 2008 16:39:07 +0200 Subject: [hunchentoot-devel] Current development Message-ID: As common-lisp.net has been pretty unreliable in the last days, we've moved development over to the bknr.net server maintained by Hans. If you're interested in trying out the soon-to-be-released Hunchentoot version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here: http://bknr.net/trac/browser/trunk/thirdparty If you're using Drakma, you'll have to grab it from bknr.net as well, as there are incompatible changes in Chunga. The previous development history can be seen at http://trac.common-lisp.net/tbnl/browser/branches whenever the server is up. Edi. From hans at huebner.org Mon May 26 19:04:45 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 26 May 2008 21:04:45 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: To make your life easier, I have create an ediware package that you can use to check out Hunchentoot, Drakma and all dependencies with one command: svn co svn://bknr.net/svn/ediware If you use this, please let me know. If it is not used, I will not bother updating the externals list in the ediware package. -Hans On Mon, May 26, 2008 at 4:39 PM, Edi Weitz wrote: > As common-lisp.net has been pretty unreliable in the last days, we've > moved development over to the bknr.net server maintained by Hans. If > you're interested in trying out the soon-to-be-released Hunchentoot > version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here: > > http://bknr.net/trac/browser/trunk/thirdparty > > If you're using Drakma, you'll have to grab it from bknr.net as well, > as there are incompatible changes in Chunga. > > The previous development history can be seen at > > http://trac.common-lisp.net/tbnl/browser/branches > > whenever the server is up. > > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Mon May 26 19:56:16 2008 From: lispercat at gmail.com (Andrei Stebakov) Date: Mon, 26 May 2008 15:56:16 -0400 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: The idea of ediware package is really great! On Mon, May 26, 2008 at 3:04 PM, Hans H?bner wrote: > To make your life easier, I have create an ediware package that you > can use to check out Hunchentoot, Drakma and all dependencies with one > command: > > svn co svn://bknr.net/svn/ediware > > If you use this, please let me know. If it is not used, I will not > bother updating the externals list in the ediware package. > > -Hans > > On Mon, May 26, 2008 at 4:39 PM, Edi Weitz wrote: > > As common-lisp.net has been pretty unreliable in the last days, we've > > moved development over to the bknr.net server maintained by Hans. If > > you're interested in trying out the soon-to-be-released Hunchentoot > > version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here: > > > > http://bknr.net/trac/browser/trunk/thirdparty > > > > If you're using Drakma, you'll have to grab it from bknr.net as well, > > as there are incompatible changes in Chunga. > > > > The previous development history can be seen at > > > > http://trac.common-lisp.net/tbnl/browser/branches > > > > whenever the server is up. > > > > Edi. > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hutch-lists at recursive.ca Mon May 26 20:09:56 2008 From: hutch-lists at recursive.ca (Bob Hutchison) Date: Mon, 26 May 2008 16:09:56 -0400 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: <8D78B25C-FADD-40C3-A6AA-7D7FE5154B7F@recursive.ca> Hi, On 26-May-08, at 3:04 PM, Hans H?bner wrote: > To make your life easier, It definitely does. > I have create an ediware package that you > can use to check out Hunchentoot, Drakma and all dependencies with one > command: > > svn co svn://bknr.net/svn/ediware > > If you use this, please let me know. I'll be using it. > If it is not used, I will not > bother updating the externals list in the ediware package. There's stuff in there that I don't think is Edi's code. Will you be keeping these up to date as well? How is this supposed to work? Thanks for doing this. Great idea! Cheers, Bob > > > -Hans From ch-tbnl at bobobeach.com Tue May 27 05:59:09 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Mon, 26 May 2008 22:59:09 -0700 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: So what's the canonical location for Hans' branch now? Thanks, Cyrus On May 26, 2008, at 12:04 PM, Hans H?bner wrote: > To make your life easier, I have create an ediware package that you > can use to check out Hunchentoot, Drakma and all dependencies with one > command: > > svn co svn://bknr.net/svn/ediware > > If you use this, please let me know. If it is not used, I will not > bother updating the externals list in the ediware package. > > -Hans > > On Mon, May 26, 2008 at 4:39 PM, Edi Weitz wrote: >> As common-lisp.net has been pretty unreliable in the last days, we've >> moved development over to the bknr.net server maintained by Hans. If >> you're interested in trying out the soon-to-be-released Hunchentoot >> version, get all of Hunchentoot, Chunga, and FLEXI-STREAMS from here: >> >> http://bknr.net/trac/browser/trunk/thirdparty >> >> If you're using Drakma, you'll have to grab it from bknr.net as well, >> as there are incompatible changes in Chunga. >> >> The previous development history can be seen at >> >> http://trac.common-lisp.net/tbnl/browser/branches >> >> whenever the server is up. >> >> Edi. >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From hans at huebner.org Tue May 27 07:30:47 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 27 May 2008 09:30:47 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: On Tue, May 27, 2008 at 7:59 AM, Cyrus Harmon wrote: > So what's the canonical location for Hans' branch now? My former branch now lives in svn://bknr.net/svn/trunk/thirdparty/hunchentoot/ - Note that you can also use http://bknr.net/svn/... if your firewall does not like outgoing svn connections. -Hans From hans at huebner.org Tue May 27 07:39:46 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 27 May 2008 09:39:46 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: <8D78B25C-FADD-40C3-A6AA-7D7FE5154B7F@recursive.ca> References: <8D78B25C-FADD-40C3-A6AA-7D7FE5154B7F@recursive.ca> Message-ID: On Mon, May 26, 2008 at 10:09 PM, Bob Hutchison wrote: > On 26-May-08, at 3:04 PM, Hans H?bner wrote: >> I have create an ediware package that you >> can use to check out Hunchentoot, Drakma and all dependencies with one >> command: >> >> svn co svn://bknr.net/svn/ediware >> >> If you use this, please let me know. > > I'll be using it. Okay, so I will be maintaining it. >> If it is not used, I will not >> bother updating the externals list in the ediware package. > > There's stuff in there that I don't think is Edi's code. Will you be keeping > these up to date as well? How is this supposed to work? The idea is that by checking out from the ediware URL, you will always get all dependencies. The URL may change slightly, and we may introduce a mechanism so that one can check out releases. I will announce changes on this list. -Hans From edi at agharta.de Tue May 27 09:04:52 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 27 May 2008 11:04:52 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: (Cyrus Harmon's message of "Mon, 26 May 2008 22:59:09 -0700") References: Message-ID: On Mon, 26 May 2008 22:59:09 -0700, Cyrus Harmon wrote: > So what's the canonical location for Hans' branch now? The bknr.net one I sent to the list yesterday (or the "ediware" package which references the same content). The folder called "hunchentoot" contains what started as Hans' branch and what both Hans and I have been working on (and are still working on) since. This will be the basis for the next release. Same goes for Chunga/Drakma. Part 1 ("hans" being renamed to "hunchentoot") is here: http://trac.common-lisp.net/tbnl/browser/branches The sequel is now here: http://bknr.net/trac/browser/trunk/thirdparty The same three folders. As I said, you are encouraged to check it out and play with it (and report bugs of course). Expect a couple of incompatible changes, though. From css at swissjabber.ch Wed May 28 22:03:20 2008 From: css at swissjabber.ch (css) Date: Thu, 29 May 2008 00:03:20 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread Message-ID: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> Hello. My problem may seem strange, but: I have a huge download to generate on my hunchentoot, and I dont want to have one thread for each of these downloads, but one thread answering multiple requests at the same time (since the generation takes time, caching takes space, and sending the generated code to multiple receivers seems the best idea to me). That is, I want to get the request-object, and then pass it to another thread, who is then handling multiple requests (i.e. sending "non-waiting", polling for input, etc.). Is this possible? From ctdean at sokitomi.com Wed May 28 22:28:30 2008 From: ctdean at sokitomi.com (Chris Dean) Date: Wed, 28 May 2008 15:28:30 -0700 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> (css@swissjabber.ch's message of "Thu, 29 May 2008 00:03:20 +0200") References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> Message-ID: > That is, I want to get the request-object, and then pass it to > another thread, who is then handling multiple requests (i.e. sending > "non-waiting", polling for input, etc.). Is this possible? I'm not sure I follow. Do you want to get the output stream (and/or the input stream) and pass that to another thread for processing? I don't know the answer, just trying to clarify. Cheers, Chris Dean From css at swissjabber.ch Wed May 28 23:15:57 2008 From: css at swissjabber.ch (css) Date: Thu, 29 May 2008 01:15:57 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> Message-ID: <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> 2008/5/29 Chris Dean : > >> That is, I want to get the request-object, and then pass it to >> another thread, who is then handling multiple requests (i.e. sending >> "non-waiting", polling for input, etc.). Is this possible? > > I'm not sure I follow. Do you want to get the output stream (and/or > the input stream) and pass that to another thread for processing? I > don't know the answer, just trying to clarify. > > Cheers, > Chris Dean Hm. I guess what I want is best explained as some "Polling-Mode" for requests. I.e. having a main loop in one thread, "polling" or waiting for new requests, an then scheduling myself the input and output inside this one thread. My problem is that the number of threads I can use is bounded at a low bound, and I do not want to "waste" threads for something, that doesnt need them - i.e. I would like to schedule the requests and their processing myself, not relying on some threaded interface. I wonder if this is possible with hunchentoot. Hm. Maybe some "pseudocode" shows, what I mean. I have a loop with the following "content" (some-infinite-loop (if (new-connection-arrived) (push request requests-to-answer)) (dolist (req requests-to-answer) (continue-processing req) ; do some small action that continues the processing of req )) That is, basically, what I want to do. Or at least something similar. Can this be done? From ctdean at sokitomi.com Wed May 28 23:38:41 2008 From: ctdean at sokitomi.com (Chris Dean) Date: Wed, 28 May 2008 16:38:41 -0700 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> (css@swissjabber.ch's message of "Thu, 29 May 2008 01:15:57 +0200") References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: css writes: > Hm. I guess what I want is best explained as some "Polling-Mode" for > requests. I.e. having a main loop in one thread, "polling" or waiting > for new requests, an then scheduling myself the input and output > inside this one thread. My problem is that the number of threads I can > use is bounded at a low bound, and I do not want to "waste" threads > for something, that doesnt need them - i.e. I would like to schedule > the requests and their processing myself, not relying on some threaded > interface. I wonder if this is possible with hunchentoot. Sure, I got it. A very reasonable desire for a high performance server. I don't believe this is possible in Hunchentoot as it stands now - the current code is very thread based. HTTP is a fairly simple protocol and you could use Hunchentoot as a starting point for implementing your system. Cheers, Chris Dean From css at swissjabber.ch Thu May 29 07:11:11 2008 From: css at swissjabber.ch (css) Date: Thu, 29 May 2008 09:11:11 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: <9e4493f70805290011y4a9e3346j6fa367035e370619@mail.gmail.com> > Sure, I got it. A very reasonable desire for a high performance > server. I don't believe this is possible in Hunchentoot as it stands > now - the current code is very thread based. > > HTTP is a fairly simple protocol and you could use Hunchentoot as a > starting point for implementing your system. Hm. HTTP is not /that/ simple. You need at least three (simple, but still) parsers, then things like Chunked encoding (ok, i can use Chunga for this), and it takes a while to make it "stable". So I thought I could use at least parts of Hunchentoot - but seems like the "critical" Parts are heavily interdependent from the other stuff. Thank you anyway. From edi at agharta.de Thu May 29 08:00:49 2008 From: edi at agharta.de (Edi Weitz) Date: Thu, 29 May 2008 10:00:49 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> (css@swissjabber.ch's message of "Thu, 29 May 2008 01:15:57 +0200") References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: On Thu, 29 May 2008 01:15:57 +0200, css wrote: > Hm. I guess what I want is best explained as some "Polling-Mode" for > requests. I.e. having a main loop in one thread, "polling" or > waiting for new requests, an then scheduling myself the input and > output inside this one thread. My problem is that the number of > threads I can use is bounded at a low bound, and I do not want to > "waste" threads for something, that doesnt need them - i.e. I would > like to schedule the requests and their processing myself, not > relying on some threaded interface. I wonder if this is possible > with hunchentoot. IIUC this could be possible with the current (unreleased) development version of Hunchentoot. Look at the "connection manager" class Hans has written and see if you can write your own connection manager to achieve what you want. http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot From hans at huebner.org Thu May 29 08:26:00 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 29 May 2008 10:26:00 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: On Thu, May 29, 2008 at 10:00 AM, Edi Weitz wrote: > IIUC this could be possible with the current (unreleased) development > version of Hunchentoot. Look at the "connection manager" class Hans > has written and see if you can write your own connection manager to > achieve what you want. It was in fact my primary motivation to make the behavior of Hunchentoot with respect to threads more configurable, and I will be continuing on that road. A connection manager class that uses one thread for I/O scheduling and one or more request executor threads is on the list of things that I want to implement. css, can you detail what you exactly want to achive? Why do you want to avoid threads? And, as a general note, if you want free support, can you at least supply us with something like a name so that it is easier to imagine a person behind your writing? Thank you. -Hans From css at swissjabber.ch Thu May 29 10:08:43 2008 From: css at swissjabber.ch (css) Date: Thu, 29 May 2008 12:08:43 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> Hello. 2008/5/29 Hans H?bner : > On Thu, May 29, 2008 at 10:00 AM, Edi Weitz wrote: >> IIUC this could be possible with the current (unreleased) development >> version of Hunchentoot. Look at the "connection manager" class Hans >> has written and see if you can write your own connection manager to >> achieve what you want. > > It was in fact my primary motivation to make the behavior of > Hunchentoot with respect to threads more configurable, and I will be > continuing on that road. A connection manager class that uses one > thread for I/O scheduling and one or more request executor threads is > on the list of things that I want to implement. > > css, can you detail what you exactly want to achive? Why do you want > to avoid threads? One reason: I am using clisp, which has no real thread support. The other lisps use too much resources. And I have a very limited amount of threads. I am not a server admin of a huge server, I have to work with one of these tiny-low-cost-virtual-servers, which have very limited resources. As far as I see at the moment, connection-listener could be useful, but since clisp has no stable thread support yet, while usocket does not have support for accepting connections on server-sockets without blocking (and clisp does), which may be the reason why you decided to use two threads instead of only one loop for accepting and processing. I would have to write stuff arount it, anyway. So it is maybe easier for me to just implement an own little HTTP-Server, though it is not trivial. > And, as a general note, if you want free support, can you at least > supply us with something like a name so that it is easier to imagine a > person behind your writing? Thank you. I dont know why you can imagine a person you may have never seen better with his name, but ok, my name is no secret. Regards, Christoph Senjak From hans at huebner.org Thu May 29 11:44:22 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 29 May 2008 13:44:22 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> Message-ID: Hi Christoph, thank you for your explanation. It would in fact be possible to use a specialized connection manager subclass that implements listen-for-connections so that it uses some form of select() to not only wait for new connections arriving, but also for data coming in on one of the current client sockets. I have not fully thought this through, but I am interested in supporting this mode of operation - Not only because the client that I work for wants persistent connections (which we can't currently support in single threaded mode), but also because the deployment problem that you describe hit me in the past as well. Having a Lisp that can run Hunchentoot on a small virtual Linux or even a shared web host would be very nice. I will be discussing this with Edi next week, and depending on the outcome you may see the functionality added soon. -Hans On Thu, May 29, 2008 at 12:08 PM, css wrote: > Hello. > > 2008/5/29 Hans H?bner : >> On Thu, May 29, 2008 at 10:00 AM, Edi Weitz wrote: >>> IIUC this could be possible with the current (unreleased) development >>> version of Hunchentoot. Look at the "connection manager" class Hans >>> has written and see if you can write your own connection manager to >>> achieve what you want. >> >> It was in fact my primary motivation to make the behavior of >> Hunchentoot with respect to threads more configurable, and I will be >> continuing on that road. A connection manager class that uses one >> thread for I/O scheduling and one or more request executor threads is >> on the list of things that I want to implement. >> >> css, can you detail what you exactly want to achive? Why do you want >> to avoid threads? > One reason: I am using clisp, which has no real thread support. The > other lisps use too much resources. And I have a very limited amount > of threads. I am not a server admin of a huge server, I have to work > with one of these tiny-low-cost-virtual-servers, which have very > limited resources. > > As far as I see at the moment, connection-listener could be useful, > but since clisp has no stable thread support yet, while usocket does > not have support for accepting connections on server-sockets without > blocking (and clisp does), which may be the reason why you decided to > use two threads instead of only one loop for accepting and processing. > I would have to write stuff arount it, anyway. So it is maybe easier > for me to just implement an own little HTTP-Server, though it is not > trivial. > >> And, as a general note, if you want free support, can you at least >> supply us with something like a name so that it is easier to imagine a >> person behind your writing? Thank you. > I dont know why you can imagine a person you may have never seen > better with his name, but ok, my name is no secret. > > Regards, > Christoph Senjak > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From vseguip at gmail.com Thu May 29 13:44:42 2008 From: vseguip at gmail.com (vseguip at gmail.com) Date: Thu, 29 May 2008 15:44:42 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> Message-ID: > One reason: I am using clisp, which has no real thread support. The > other lisps use too much resources. And I have a very limited amount > of threads. I am not a server admin of a huge server, I have to work > with one of these tiny-low-cost-virtual-servers, which have very > limited resources. > > As far as I see at the moment, connection-listener could be useful, > but since clisp has no stable thread support yet, while usocket does > not have support for accepting connections on server-sockets without > blocking (and clisp does), which may be the reason why you decided to > use two threads instead of only one loop for accepting and processing. > I would have to write stuff arount it, anyway. So it is maybe easier > for me to just implement an own little HTTP-Server, though it is not > trivial. > Hi, If you decide to go with building your own simple http server, I will recommend you to look at mongrels parser. It's written in ragel but it's really trivial to use/import in Lisp (I did it for SBCL FFI, and it was damn easy, around 60 lisp lines or so) and it's pretty fast and secure. Just my 2 cents. Cheers, V. Segu? From css at swissjabber.ch Thu May 29 16:23:20 2008 From: css at swissjabber.ch (css) Date: Thu, 29 May 2008 18:23:20 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> Message-ID: <9e4493f70805290923s56720b1cgd47dc10b7161e34c@mail.gmail.com> 2008/5/29 Hans H?bner : > It would in fact be possible to use a specialized connection manager > subclass that implements listen-for-connections so that it uses some > form of select() to not only wait for new connections arriving, but > also for data coming in on one of the current client sockets. I have > not fully thought this through, but I am interested in supporting this > mode of operation - Not only because the client that I work for wants > persistent connections (which we can't currently support in single > threaded mode), but also because the deployment problem that you > describe hit me in the past as well. Having a Lisp that can run > Hunchentoot on a small virtual Linux or even a shared web host would > be very nice. > > I will be discussing this with Edi next week, and depending on the > outcome you may see the functionality added soon. That is good. Anyway I started reading your code a little more (maybe I can write a quick-and-dirty-version for clisp in the meantime). What I actually didnt find was any place where the routines like listen-for-connections, etc., are really called, i.e. I cannot find any server-loop. However, I also cannot test your Code - seems like I am to stupid to understand this Trac-Thingy... (How) can I download/checkout/whatever the Code for hunchentoot from this server? Thank you (and sorry for that stupid question) Christoph From ctdean at sokitomi.com Thu May 29 16:37:27 2008 From: ctdean at sokitomi.com (Chris Dean) Date: Thu, 29 May 2008 09:37:27 -0700 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: (Hans =?utf-8?Q?H=C3=BCbner's?= message of "Thu, 29 May 2008 10:26:00 +0200") References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> Message-ID: "Hans H?bner" writes: > css, can you detail what you exactly want to achive? Why do you want > to avoid threads? Just as a general piece of information, having an event-based style of programming (such as using Unix select) and avoiding or limiting the use of threads is a technique sometimes used for high load servers. Dan Kegel's C10K is a good place to start if you're interested. http://www.kegel.com/c10k.html Cheers, Chris Dean From hans at huebner.org Thu May 29 16:48:53 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 29 May 2008 18:48:53 +0200 Subject: [hunchentoot-devel] Using multiple Hunchentoot-Requests in one thread In-Reply-To: <9e4493f70805290923s56720b1cgd47dc10b7161e34c@mail.gmail.com> References: <9e4493f70805281503k1dee04c0j587d93088f07ad79@mail.gmail.com> <9e4493f70805281615v4802379fha688d19c25b2a4c7@mail.gmail.com> <9e4493f70805290308m3535f03ud0de497931a5c2b7@mail.gmail.com> <9e4493f70805290923s56720b1cgd47dc10b7161e34c@mail.gmail.com> Message-ID: On Thu, May 29, 2008 at 6:23 PM, css wrote: > That is good. Anyway I started reading your code a little more (maybe > I can write a quick-and-dirty-version for clisp in the meantime). What > I actually didnt find was any place where the routines like > listen-for-connections, etc., are really called, i.e. I cannot find > any server-loop. However, I also cannot test your Code - seems like I > am to stupid to understand this Trac-Thingy... (How) can I > download/checkout/whatever the Code for hunchentoot from this server? Sure, the easiest way to get Hunchentoot and all dependencies is: svn co svn://bknr.net/svn/ediware Let me know if it does not work for you. -Hans From ch-tbnl at bobobeach.com Thu May 29 21:20:36 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 29 May 2008 14:20:36 -0700 Subject: [hunchentoot-devel] as-keyword and other utility functions Message-ID: <893AB36C-8FC3-45B2-B87B-122A4C835C56@bobobeach.com> I see that in some of my code I was relying on hunchentoot::make- keyword, which has now gone away. But there is as-keyword and there is chunga::make-keyword. And there's, of course, alexandria:make-keyword, if I want to use that. It's a trivial function, but would it make sense to take things like with-unique-names, make-keyword, etc... and put it in some sort of ediware-utilities package? It's a trivial issue in this case, but I figured I'd bring it up for handy and less-trivial things like with-rebinding, etc... thanks, Cyrus From adit_kerti at yahoo.com Thu May 29 21:55:12 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 04:55:12 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports Message-ID: <483F2640.80800@yahoo.com> Hi everbody, I'm a Lisp newbie but I need to get my system up and running fast. I'm building a system that might cause multiple Hunchentoot servers to use conflicting ports. I want to handle this with an error handler and I've setup a wrapper function to start Hunchentoot and a restart function: ;; restart function to handle conflicting ports (defun ht-port-conflict-handler (condition) (... do something here to address the conflicting ports ...) (invoke-restart 'ht-port-conflict-handler)) ;; Start Hunchentoot Server with error-handling (defun ht-start-with-error-handler () (handler-bind ((simple-error #'ht-port-conflict-handler)) (restart-case (setf *ht-handle* (hunchentoot:start-server :port *ht-port*)) (ht-port-conflict-handler () nil)))) The system should allow users to reconfigure their instance of Hunchentoot without having to invoke the debugger, but when I run this code I always end up in the debugger anyway. Can anybody tell me where I went wrong? Or maybe there's a better solution for my situation? Regards, Raditya Kertiyasa From edi at agharta.de Thu May 29 22:15:12 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 00:15:12 +0200 Subject: [hunchentoot-devel] as-keyword and other utility functions In-Reply-To: <893AB36C-8FC3-45B2-B87B-122A4C835C56@bobobeach.com> (Cyrus Harmon's message of "Thu, 29 May 2008 14:20:36 -0700") References: <893AB36C-8FC3-45B2-B87B-122A4C835C56@bobobeach.com> Message-ID: On Thu, 29 May 2008 14:20:36 -0700, Cyrus Harmon wrote: > I see that in some of my code I was relying on hunchentoot::make- > keyword, which has now gone away. Hey, it wasn't exported, so you knew what to expect... :) > But there is as-keyword and there is chunga::make-keyword. And > there's, of course, alexandria:make-keyword, if I want to use > that. It's a trivial function, but would it make sense to take > things like with-unique-names, make-keyword, etc... and put it in > some sort of ediware-utilities package? > > It's a trivial issue in this case, but I figured I'd bring it up for > handy and less-trivial things like with-rebinding, etc... This is on my long list of things to do, but it has a fairly low priority. I will probably switch some of my libs to Alexandria at some point, but certainly not before the "Initial release [...] is yet to happen" line has vanished from their website. AS-KEYWORD in Chunga/Hunchentoot/Drakma is a special case, though, as it includes special treatment for a few fixed values that'll be the arguments to this function in 99.9% of all cases. From ch-tbnl at bobobeach.com Thu May 29 23:22:44 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Thu, 29 May 2008 16:22:44 -0700 Subject: [hunchentoot-devel] as-keyword and other utility functions In-Reply-To: References: <893AB36C-8FC3-45B2-B87B-122A4C835C56@bobobeach.com> Message-ID: <8712AC3C-B6AE-4C98-8E42-D9D0D1506B46@bobobeach.com> On May 29, 2008, at 3:15 PM, Edi Weitz wrote: > On Thu, 29 May 2008 14:20:36 -0700, Cyrus Harmon > wrote: > >> I see that in some of my code I was relying on hunchentoot::make- >> keyword, which has now gone away. > > Hey, it wasn't exported, so you knew what to expect... :) Fair enough... >> But there is as-keyword and there is chunga::make-keyword. And >> there's, of course, alexandria:make-keyword, if I want to use >> that. It's a trivial function, but would it make sense to take >> things like with-unique-names, make-keyword, etc... and put it in >> some sort of ediware-utilities package? >> >> It's a trivial issue in this case, but I figured I'd bring it up for >> handy and less-trivial things like with-rebinding, etc... > > This is on my long list of things to do, but it has a fairly low > priority. I will probably switch some of my libs to Alexandria at > some point, but certainly not before the "Initial release [...] is yet > to happen" line has vanished from their website. Ok, seems like it would be a pretty low-effort thing to get started on and slowly pull things from each package as things progress. Of course that's easy for me to say as I'm not actually offering to do the "low- effort" work. > AS-KEYWORD in Chunga/Hunchentoot/Drakma is a special case, though, as > it includes special treatment for a few fixed values that'll be the > arguments to this function in 99.9% of all cases. Right. This change just brought things to my attention. On a related note, it would be nice if there were some logs for the changes for the new branch. It looks like the old one has gone away. Don't get me wrong, the svn repo is a big improvement, but now *meta- dispatcher* seems to have disappeared and I don't see any commitlogs, README/ChangeLog notes about this, etc... Would be nice to know what's going on in the branch. Hope I don't sound too whiny; I'm not trying to complain, but rather to gently make my wishes heard and I greatly appreciate the direction in which things are moving. Thanks again, Cyrus From edi at agharta.de Fri May 30 06:40:59 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 08:40:59 +0200 Subject: [hunchentoot-devel] as-keyword and other utility functions In-Reply-To: <8712AC3C-B6AE-4C98-8E42-D9D0D1506B46@bobobeach.com> (Cyrus Harmon's message of "Thu, 29 May 2008 16:22:44 -0700") References: <893AB36C-8FC3-45B2-B87B-122A4C835C56@bobobeach.com> <8712AC3C-B6AE-4C98-8E42-D9D0D1506B46@bobobeach.com> Message-ID: On Thu, 29 May 2008 16:22:44 -0700, Cyrus Harmon wrote: > On a related note, it would be nice if there were some logs for the > changes for the new branch. It looks like the old one has gone away. Nah, I just renamed it to make more clear what is what. The whole (old) change history should still be here: http://trac.common-lisp.net/tbnl/log/branches/ http://trac.common-lisp.net/flexi-streams/log/branches > Don't get me wrong, the svn repo is a big improvement, but now > *meta- dispatcher* seems to have disappeared and I don't see any > commitlogs, README/ChangeLog notes about this, etc... Sometimes the commit comments might be a bit terse and a few might have been lost through one of the c-l.net outages, but at least the two links above should give you some kind of step-by-step history. Did you actually use *META-DISPATCHER*? Not that I would really consider putting it back in, I just thought nobody used it anyway. > Would be nice to know what's going on in the branch. Hope I don't > sound too whiny; I'm not trying to complain, but rather to gently > make my wishes heard and I greatly appreciate the direction in which > things are moving. No problem. From hans at huebner.org Fri May 30 07:58:03 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 30 May 2008 09:58:03 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <483F2640.80800@yahoo.com> References: <483F2640.80800@yahoo.com> Message-ID: Hi Raditya, the problem that you see results from the fact that Hunchentoot sets up the listen socket in a new thread. The handler and restart that you set up around the START-SERVER invocation are not active in that thread. You may want to have a look at the new development version of Hunchentoot. In this version, both LISTEN-FOR-CONNECTIONS and EXECUTE-LISTENER are generic functions that you could augment with :AROUND methods to handle port conflicts. The new version is not finalized and these generic functions are not yet mentioned in the official API documentation, but if you need to get running quickly, it may be worth a try. Use "svn co svn://bknr.net/svn/ediware" to check out the development version of Hunchentoot and all required dependencies. -Hans On Thu, May 29, 2008 at 11:55 PM, Raditya Kertiyasa wrote: > Hi everbody, > > I'm a Lisp newbie but I need to get my system up and running fast. I'm > building a system that might cause multiple Hunchentoot servers to use > conflicting ports. I want to handle this with an error handler and I've > setup a wrapper function to start Hunchentoot and a restart function: > > ;; restart function to handle conflicting ports > (defun ht-port-conflict-handler (condition) > (... do something here to address the conflicting ports ...) > (invoke-restart 'ht-port-conflict-handler)) > > > ;; Start Hunchentoot Server with error-handling > (defun ht-start-with-error-handler () > (handler-bind ((simple-error #'ht-port-conflict-handler)) > (restart-case (setf *ht-handle* (hunchentoot:start-server > :port *ht-port*)) > (ht-port-conflict-handler () nil)))) > > The system should allow users to reconfigure their instance of Hunchentoot > without having to invoke the debugger, but when I run this code I always end > up in the debugger anyway. Can anybody tell me where I went wrong? Or maybe > there's a better solution for my situation? > > Regards, > Raditya Kertiyasa > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From tc at travislists.com Fri May 30 09:24:02 2008 From: tc at travislists.com (Travis Cross) Date: Fri, 30 May 2008 09:24:02 +0000 Subject: [hunchentoot-devel] Current development In-Reply-To: References: Message-ID: <483FC7B2.9060003@travislists.com> Hans H?bner wrote: > To make your life easier, I have create an ediware package that you > can use to check out Hunchentoot, Drakma and all dependencies with one > command: > > svn co svn://bknr.net/svn/ediware If we're going to start using public version control for 'Ediware' libraries, may I gently suggest that a distributed VCS might be a better fit for the project. Distributed version control better enables and encourages a broad base of contributors with one or a limited number of committers. It also allows fast offline operation. The signs all seem to be pointing to GIT as the DVCS of choice for OSS projects [1]. As git hosts the linux kernel, and has experienced an explosive community growth of useful tools, it won't be going away anytime soon. As an example, I merged the development history of previous hunchentoot releases I had tracked with the SVN histories at clnet and bknr to produce a unified history you can clone with: git clone git://repos.tcross.org/hunchentoot.git # [2] If we're interested in going this direction, I'll publish git conversions of Edi's other libraries. Finally, I do understand that you're probably more personally comfortable with SVN. I believe though that the long-term benefits of moving to a DVCS now would be worth the investment in transition, especially as the project is already undergoing major changes. Cheers, -- Travis For more on GIT, see Bill Clementson's piece at http://bc.tech.coop/blog/080118.html [1] For what it's worth, my personal VCS history over the last decade has been: CVS --> SVN --> Mercurial --> Darcs --> GIT As git is dominating the DVCS world, git may be the last stop for awhile. [2] This is just an example; I haven't done extensive checking yet to ensure that my conversion and merge here is flawless. From edi at agharta.de Fri May 30 09:35:01 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 11:35:01 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: <483FC7B2.9060003@travislists.com> (Travis Cross's message of "Fri, 30 May 2008 09:24:02 +0000") References: <483FC7B2.9060003@travislists.com> Message-ID: On Fri, 30 May 2008 09:24:02 +0000, Travis Cross wrote: > If we're going to start using public version control for 'Ediware' > libraries, may I gently suggest that a distributed VCS might be a > better fit for the project. The short answer is no. For a longer answer please search the mailing list. This has been discussed ad nauseam before. Edi. From tc at travislists.com Fri May 30 09:48:45 2008 From: tc at travislists.com (Travis Cross) Date: Fri, 30 May 2008 09:48:45 +0000 Subject: [hunchentoot-devel] Current development In-Reply-To: References: <483FC7B2.9060003@travislists.com> Message-ID: <483FCD7D.2090201@travislists.com> Edi Weitz wrote: > On Fri, 30 May 2008 09:24:02 +0000, Travis Cross wrote: > >> If we're going to start using public version control for 'Ediware' >> libraries, may I gently suggest that a distributed VCS might be a >> better fit for the project. > > The short answer is no. For a longer answer please search the mailing > list. This has been discussed ad nauseam before. Not a problem. :) I don't have to search; I was probably the one who brought it up first (only once though). At that time, the answer was that there was going to be no public version control at all. One of the reasons given was related to the need for offline operation. Another was consideration of Windows support. And finally, as I recall, was the consideration that managing version control would mean more time spent maintaining the project. So I was a bit surprised to see the introduction of a seemingly public and permanent version-controlled repository for hunchentoot that doesn't support offline operation and has a relatively high management complexity (SVN). That's why I brought up git. Things looked to have changed. I wasn't looking to kick a dead horse. :) Cheers, -- Travis From edi at agharta.de Fri May 30 10:01:13 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 12:01:13 +0200 Subject: [hunchentoot-devel] Current development In-Reply-To: <483FCD7D.2090201@travislists.com> (Travis Cross's message of "Fri, 30 May 2008 09:48:45 +0000") References: <483FC7B2.9060003@travislists.com> <483FCD7D.2090201@travislists.com> Message-ID: On Fri, 30 May 2008 09:48:45 +0000, Travis Cross wrote: > I don't have to search; I was probably the one who brought it up > first (only once though). At that time, the answer was that there > was going to be no public version control at all. One of the > reasons given was related to the need for offline operation. > Another was consideration of Windows support. And finally, as I > recall, was the consideration that managing version control would > mean more time spent maintaining the project. The reasons are still the same. Hans and I are currently joining efforts because Hans had suggested a bunch of changes (that we had talked about before) and I used his activities as an excuse to work on a redesign of Huchentoot that I had planned for some time. Some of these changes are pretty radical and they "span" several libraries at once, so it would have been tricky to release them piecemeal and we thought it might make sense to show the work in progress so people can play with it already. Once the dust has settled a bit, I'll very likely return to private version control and regular (deemed-stable) releases for the reasons you correctly enumerated above. From adit_kerti at yahoo.com Fri May 30 13:11:12 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 20:11:12 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: References: <483F2640.80800@yahoo.com> Message-ID: <483FFCF0.1040000@yahoo.com> Hans, Thanks for the explanation and suggestion. I've never used SVN before, but I'll give it a try. If there are alternative methods such as invoking START-SERVER without creating a new thread on the version I'm using (the one I got from Ubuntu repos), or maybe checking if the port in question is already bind before even invoking START-SERVER, I'm all ears. By the way, I think Hunchentoot is great! Thanks Edi and you for making my life easier. Regards, Raditya Kertiyasa Hans H?bner wrote: > Hi Raditya, > > the problem that you see results from the fact that Hunchentoot sets > up the listen socket in a new thread. The handler and restart that > you set up around the START-SERVER invocation are not active in that > thread. > > You may want to have a look at the new development version of > Hunchentoot. In this version, both LISTEN-FOR-CONNECTIONS and > EXECUTE-LISTENER are generic functions that you could augment with > :AROUND methods to handle port conflicts. The new version is not > finalized and these generic functions are not yet mentioned in the > official API documentation, but if you need to get running quickly, it > may be worth a try. > > Use "svn co svn://bknr.net/svn/ediware" to check out the development > version of Hunchentoot and all required dependencies. > > -Hans > > On Thu, May 29, 2008 at 11:55 PM, Raditya Kertiyasa > wrote: > >> Hi everbody, >> >> I'm a Lisp newbie but I need to get my system up and running fast. I'm >> building a system that might cause multiple Hunchentoot servers to use >> conflicting ports. I want to handle this with an error handler and I've >> setup a wrapper function to start Hunchentoot and a restart function: >> >> ;; restart function to handle conflicting ports >> (defun ht-port-conflict-handler (condition) >> (... do something here to address the conflicting ports ...) >> (invoke-restart 'ht-port-conflict-handler)) >> >> >> ;; Start Hunchentoot Server with error-handling >> (defun ht-start-with-error-handler () >> (handler-bind ((simple-error #'ht-port-conflict-handler)) >> (restart-case (setf *ht-handle* (hunchentoot:start-server >> :port *ht-port*)) >> (ht-port-conflict-handler () nil)))) >> >> The system should allow users to reconfigure their instance of Hunchentoot >> without having to invoke the debugger, but when I run this code I always end >> up in the debugger anyway. Can anybody tell me where I went wrong? Or maybe >> there's a better solution for my situation? >> >> Regards, >> Raditya Kertiyasa >> >> _______________________________________________ >> 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 hans at huebner.org Fri May 30 13:22:00 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 30 May 2008 15:22:00 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <483FFCF0.1040000@yahoo.com> References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> Message-ID: On Fri, May 30, 2008 at 3:11 PM, Raditya Kertiyasa wrote: > Hans, > > Thanks for the explanation and suggestion. I've never used SVN before, but > I'll give it a try. If there are alternative methods such as invoking > START-SERVER without creating a new thread on the version I'm using (the one > I got from Ubuntu repos), or maybe checking if the port in question is > already bind before even invoking START-SERVER, I'm all ears. The current release version of Hunchentoot does not give you an API to do what you want, sorry. You can hack away at the source code yourself if you really want to. In the current development version, you can use :THREADED NIL as argument to START-SERVER. This will run the listener and the connection handler in the invoking thread, and conditions will just be signalled through to the caller of START-SERVER. You can do this in a separate thread for each of your servers (and you propably want to, as the call is blocking). :THREADED NIL will also switch off persistent connections by default so that it is possible to server multiple clients, one after the other. This mode will be slower, though, because I/O and request processing will be done in a synchronous fashion (i.e. one after the other). -Hans > > By the way, I think Hunchentoot is great! Thanks Edi and you for making my > life easier. > > Regards, > Raditya Kertiyasa > > Hans H?bner wrote: >> >> Hi Raditya, >> >> the problem that you see results from the fact that Hunchentoot sets >> up the listen socket in a new thread. The handler and restart that >> you set up around the START-SERVER invocation are not active in that >> thread. >> >> You may want to have a look at the new development version of >> Hunchentoot. In this version, both LISTEN-FOR-CONNECTIONS and >> EXECUTE-LISTENER are generic functions that you could augment with >> :AROUND methods to handle port conflicts. The new version is not >> finalized and these generic functions are not yet mentioned in the >> official API documentation, but if you need to get running quickly, it >> may be worth a try. >> >> Use "svn co svn://bknr.net/svn/ediware" to check out the development >> version of Hunchentoot and all required dependencies. >> >> -Hans >> >> On Thu, May 29, 2008 at 11:55 PM, Raditya Kertiyasa >> wrote: >> >>> >>> Hi everbody, >>> >>> I'm a Lisp newbie but I need to get my system up and running fast. I'm >>> building a system that might cause multiple Hunchentoot servers to use >>> conflicting ports. I want to handle this with an error handler and I've >>> setup a wrapper function to start Hunchentoot and a restart function: >>> >>> ;; restart function to handle conflicting ports >>> (defun ht-port-conflict-handler (condition) >>> (... do something here to address the conflicting ports ...) >>> (invoke-restart 'ht-port-conflict-handler)) >>> >>> >>> ;; Start Hunchentoot Server with error-handling >>> (defun ht-start-with-error-handler () >>> (handler-bind ((simple-error #'ht-port-conflict-handler)) >>> (restart-case (setf *ht-handle* (hunchentoot:start-server >>> :port *ht-port*)) >>> (ht-port-conflict-handler () nil)))) >>> >>> The system should allow users to reconfigure their instance of >>> Hunchentoot >>> without having to invoke the debugger, but when I run this code I always >>> end >>> up in the debugger anyway. Can anybody tell me where I went wrong? Or >>> maybe >>> there's a better solution for my situation? >>> >>> Regards, >>> Raditya Kertiyasa >>> >>> _______________________________________________ >>> 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 >> >> > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From adit_kerti at yahoo.com Fri May 30 13:47:43 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 20:47:43 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> Message-ID: <4840057F.5080901@yahoo.com> Hans, I might be getting myself into stuff that I really don't understand yet. I'll rephrase my question: The bottom line is that it is possible that more than one instance of my system will be running on the same machine. With the port set to default each time the system starts, this produces the possibility that someone will start an instance of Hunchentoot and end up in a port conflict. What I really want to do is address this situation in whichever way is simpler and easier, so I tried using HANDLER-BIND and a restart function. It may not be the best solution and I might have taken a wrong turn or missed a sign, so I'd really appreciate it if you could tell me your opinion. Regards, Raditya Kertiyasa Hans H?bner wrote: > On Fri, May 30, 2008 at 3:11 PM, Raditya Kertiyasa wrote: > >> Hans, >> >> Thanks for the explanation and suggestion. I've never used SVN before, but >> I'll give it a try. If there are alternative methods such as invoking >> START-SERVER without creating a new thread on the version I'm using (the one >> I got from Ubuntu repos), or maybe checking if the port in question is >> already bind before even invoking START-SERVER, I'm all ears. >> > > The current release version of Hunchentoot does not give you an API to > do what you want, sorry. You can hack away at the source code > yourself if you really want to. > > In the current development version, you can use :THREADED NIL as > argument to START-SERVER. This will run the listener and the > connection handler in the invoking thread, and conditions will just be > signalled through to the caller of START-SERVER. You can do this in a > separate thread for each of your servers (and you propably want to, as > the call is blocking). :THREADED NIL will also switch off persistent > connections by default so that it is possible to server multiple > clients, one after the other. This mode will be slower, though, > because I/O and request processing will be done in a synchronous > fashion (i.e. one after the other). > > -Hans > > >> By the way, I think Hunchentoot is great! Thanks Edi and you for making my >> life easier. >> >> Regards, >> Raditya Kertiyasa >> >> Hans H?bner wrote: >> >>> Hi Raditya, >>> >>> the problem that you see results from the fact that Hunchentoot sets >>> up the listen socket in a new thread. The handler and restart that >>> you set up around the START-SERVER invocation are not active in that >>> thread. >>> >>> You may want to have a look at the new development version of >>> Hunchentoot. In this version, both LISTEN-FOR-CONNECTIONS and >>> EXECUTE-LISTENER are generic functions that you could augment with >>> :AROUND methods to handle port conflicts. The new version is not >>> finalized and these generic functions are not yet mentioned in the >>> official API documentation, but if you need to get running quickly, it >>> may be worth a try. >>> >>> Use "svn co svn://bknr.net/svn/ediware" to check out the development >>> version of Hunchentoot and all required dependencies. >>> >>> -Hans >>> >>> On Thu, May 29, 2008 at 11:55 PM, Raditya Kertiyasa >>> wrote: >>> >>> >>>> Hi everbody, >>>> >>>> I'm a Lisp newbie but I need to get my system up and running fast. I'm >>>> building a system that might cause multiple Hunchentoot servers to use >>>> conflicting ports. I want to handle this with an error handler and I've >>>> setup a wrapper function to start Hunchentoot and a restart function: >>>> >>>> ;; restart function to handle conflicting ports >>>> (defun ht-port-conflict-handler (condition) >>>> (... do something here to address the conflicting ports ...) >>>> (invoke-restart 'ht-port-conflict-handler)) >>>> >>>> >>>> ;; Start Hunchentoot Server with error-handling >>>> (defun ht-start-with-error-handler () >>>> (handler-bind ((simple-error #'ht-port-conflict-handler)) >>>> (restart-case (setf *ht-handle* (hunchentoot:start-server >>>> :port *ht-port*)) >>>> (ht-port-conflict-handler () nil)))) >>>> >>>> The system should allow users to reconfigure their instance of >>>> Hunchentoot >>>> without having to invoke the debugger, but when I run this code I always >>>> end >>>> up in the debugger anyway. Can anybody tell me where I went wrong? Or >>>> maybe >>>> there's a better solution for my situation? >>>> >>>> Regards, >>>> Raditya Kertiyasa >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >> _______________________________________________ >> 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 hans at huebner.org Fri May 30 14:01:13 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 30 May 2008 16:01:13 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <4840057F.5080901@yahoo.com> References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> Message-ID: On Fri, May 30, 2008 at 3:47 PM, Raditya Kertiyasa wrote: > The bottom line is that it is possible that more than one instance of my > system will be running on the same machine. With the port set to default > each time the system starts, this produces the possibility that someone will > start an instance of Hunchentoot and end up in a port conflict. What I > really want to do is address this situation in whichever way is simpler and > easier, so I tried using HANDLER-BIND and a restart function. It may not be > the best solution and I might have taken a wrong turn or missed a sign, so > I'd really appreciate it if you could tell me your opinion. Well, all the advice I can give you here is not to compile in a port number but let the user decide if they want to run an http server, and on which port. If what you work on is a shrink-wrapped application (i.e. the user should never see the debugger), consider using the appropriate startup option to your Lisp to disable the debugger. You may also want to look at *DEBUGGER-HOOK* in the CLHS. -Hans From adit_kerti at yahoo.com Fri May 30 14:15:28 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 21:15:28 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> Message-ID: <48400C00.80104@yahoo.com> Hans, I've been trying to avoid having to prompt the user for a port, since my system will be communicating to another system via HTTP on an agreed port. But I'll take your advice. Thank you for putting up with my questions. By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it downloads the latest Hunchentoot source codes along with any required dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed something? Regards, Raditya Kertiyasa Hans H?bner wrote: > On Fri, May 30, 2008 at 3:47 PM, Raditya Kertiyasa wrote: > >> The bottom line is that it is possible that more than one instance of my >> system will be running on the same machine. With the port set to default >> each time the system starts, this produces the possibility that someone will >> start an instance of Hunchentoot and end up in a port conflict. What I >> really want to do is address this situation in whichever way is simpler and >> easier, so I tried using HANDLER-BIND and a restart function. It may not be >> the best solution and I might have taken a wrong turn or missed a sign, so >> I'd really appreciate it if you could tell me your opinion. >> > > Well, all the advice I can give you here is not to compile in a port > number but let the user decide if they want to run an http server, and > on which port. If what you work on is a shrink-wrapped application > (i.e. the user should never see the debugger), consider using the > appropriate startup option to your Lisp to disable the debugger. You > may also want to look at *DEBUGGER-HOOK* in the CLHS. > > -Hans > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From hans at huebner.org Fri May 30 14:23:00 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 30 May 2008 16:23:00 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <48400C00.80104@yahoo.com> References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> <48400C00.80104@yahoo.com> Message-ID: On Fri, May 30, 2008 at 4:15 PM, Raditya Kertiyasa wrote: > By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it > downloads the latest Hunchentoot source codes along with any required > dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed > something? It should be in the ediware/hunchentoot subdirectory. -Hans From adit_kerti at yahoo.com Fri May 30 14:49:32 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 21:49:32 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> <48400C00.80104@yahoo.com> Message-ID: <484013FC.7070000@yahoo.com> I've got this message: svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' doesn't exist And then when I ls in the ediware subdirectory, this is what I get: /ediware$ ls bordeaux-threads chunga cl-fad cl+ssl drakma cffi cl-base64 cl-ppcre cl-who Regards, Raditya Kertiyasa Hans H?bner wrote: > On Fri, May 30, 2008 at 4:15 PM, Raditya Kertiyasa wrote: > >> By the way, I've done "svn co svn://bknr.net/svn/ediware". CMIIW, but it >> downloads the latest Hunchentoot source codes along with any required >> dependencies. But I can't seem to find Hunchentoot anywhere. Have I missed >> something? >> > > It should be in the ediware/hunchentoot subdirectory. > > -Hans > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From edi at agharta.de Fri May 30 14:56:06 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 16:56:06 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <484013FC.7070000@yahoo.com> (Raditya Kertiyasa's message of "Fri, 30 May 2008 21:49:32 +0700") References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> <48400C00.80104@yahoo.com> <484013FC.7070000@yahoo.com> Message-ID: On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa wrote: > I've got this message: > svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' > doesn't exist Sorry, that's my fault due to an update I did this afternoon. Will fix. From edi at agharta.de Fri May 30 15:02:01 2008 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 May 2008 17:02:01 +0200 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: <484013FC.7070000@yahoo.com> (Raditya Kertiyasa's message of "Fri, 30 May 2008 21:49:32 +0700") References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> <48400C00.80104@yahoo.com> <484013FC.7070000@yahoo.com> Message-ID: On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa wrote: > I've got this message: > svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' > doesn't exist Should work now, please try again. Sorry for the hiccup. From adit_kerti at yahoo.com Fri May 30 15:12:13 2008 From: adit_kerti at yahoo.com (Raditya Kertiyasa) Date: Fri, 30 May 2008 22:12:13 +0700 Subject: [hunchentoot-devel] Handling multiple Hunchentoot instances with potentially conflicting ports In-Reply-To: References: <483F2640.80800@yahoo.com> <483FFCF0.1040000@yahoo.com> <4840057F.5080901@yahoo.com> <48400C00.80104@yahoo.com> <484013FC.7070000@yahoo.com> Message-ID: <4840194D.8010209@yahoo.com> Sure does. Thanks Edi :) Regards, Raditya Kertiyasa Edi Weitz wrote: > On Fri, 30 May 2008 21:49:32 +0700, Raditya Kertiyasa wrote: > > >> I've got this message: >> svn: URL 'svn://bknr.net/svn/trunk/thirdparty/flexi-streams-1.0.2' >> doesn't exist >> > > Should work now, please try again. Sorry for the hiccup. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From ch-tbnl at bobobeach.com Sat May 31 01:45:29 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Fri, 30 May 2008 18:45:29 -0700 Subject: [hunchentoot-devel] conditional reader error Message-ID: <588F7E83-6386-4E7C-8D95-F4699508DC6F@bobobeach.com> In hunchentoot.asd, I think the #+(not foo bar ...) bit is wrong: Index: hunchentoot.asd =================================================================== --- hunchentoot.asd (revision 3230) +++ hunchentoot.asd (working copy) @@ -76,7 +76,7 @@ #+(and :lispworks :unix) (:file "unix-lw") #+(and :openmcl :unix) (:file "unix-mcl") #+(and :sbcl :unix (not :win32)) (:file "unix-sbcl") - #+(and (not :allegro :clisp :cmu :lispworks :openmcl :sbcl) :unix) (:file "unix-other") + #+(and (not (or :allegro :clisp :cmu :lispworks :openmcl :sbcl)) :unix) (:file "unix-other") (:file "set-timeouts") (:file "connection-manager") (:file "server") From edi at agharta.de Sat May 31 09:44:51 2008 From: edi at agharta.de (Edi Weitz) Date: Sat, 31 May 2008 11:44:51 +0200 Subject: [hunchentoot-devel] conditional reader error In-Reply-To: <588F7E83-6386-4E7C-8D95-F4699508DC6F@bobobeach.com> (Cyrus Harmon's message of "Fri, 30 May 2008 18:45:29 -0700") References: <588F7E83-6386-4E7C-8D95-F4699508DC6F@bobobeach.com> Message-ID: On Fri, 30 May 2008 18:45:29 -0700, Cyrus Harmon wrote: > In hunchentoot.asd, I think the #+(not foo bar ...) bit is wrong: Right you are. Fixed now. Thanks, Edi. From rsynnott at gmail.com Sat May 31 18:02:47 2008 From: rsynnott at gmail.com (Robert Synnott) Date: Sat, 31 May 2008 19:02:47 +0100 Subject: [hunchentoot-devel] New release 0.15.7 (and also FLEXI-STREAMS 0.15.0) In-Reply-To: References: Message-ID: <24f203480805311102j46812865l9b235aafe06010ba@mail.gmail.com> On Wed, May 21, 2008 at 3:55 PM, Edi Weitz wrote: > This is a tiny change which should improve Hunchentoot's performance. > Incidentally, if you're concerned about performance, you might > consider giving FLEXI-STREAMS 0.15.0 a try which was also released > today. > > http://weitz.de/files/hunchentoot.tar.gz > http://weitz.de/files/flexi-streams.tar.gz > > I'd also recommend to everyone interested in Hunchentoot's future > directions to check out Hans' current version from here > > http://trac.common-lisp.net/tbnl/browser/branches/hans > > and to play with it. This version needs an updated Chunga (at least > 0.4.2): > > http://weitz.de/files/chunga.tar.gz > > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Well done on this; it's enormously faster than the previous version for serving large pages (about 10 times for a 300kb page!) Rob -- Robert Synnott http://myblog.rsynnott.com MSN: rsynnott at gmail.com Jabber: rsynnott at gmail.com From ch-tbnl at bobobeach.com Sat May 31 20:18:10 2008 From: ch-tbnl at bobobeach.com (Cyrus Harmon) Date: Sat, 31 May 2008 13:18:10 -0700 Subject: [hunchentoot-devel] hunchentoot-error error Message-ID: <86763A9F-7B7F-45ED-8273-368D5D078C6A@bobobeach.com> conditions.lisp has two definitions of hunchentoot-error, and none for hunchentoot-warn. the following patch fixes this: Index: conditions.lisp =================================================================== --- conditions.lisp (revision 3232) +++ conditions.lisp (working copy) @@ -1,5 +1,5 @@ -;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: ODD-STREAMS; Base: 10 -*- -;;; $Header: /usr/local/cvsrep/odd-streams/conditions.lisp,v 1.5 2007/12/31 01:08:45 edi Exp $ +;;; -*- Mode: LISP; Syntax: COMMON-LISP; Package: HUNCHENTOOT; Base: 10 -*- +;;; $Header: /usr/local/cvsrep/hunchentoot/conditions.lisp,v 1.5 2007/12/31 01:08:45 edi Exp $ ;;; Copyright (c) 2008, Dr. Edmund Weitz. All rights reserved. @@ -56,7 +56,7 @@ () (:documentation "Like HUNCHENTOOT-WARNING but with formatting capabilities.")) -(defun hunchentoot-error (format-control &rest format-arguments) +(defun hunchentoot-warn (format-control &rest format-arguments) "Signals a warning of type HUNCHENTOOT-SIMPLE-WARNING with the provided format control and arguments." (warn 'hunchentoot-simple-warning From edi at agharta.de Sat May 31 22:30:28 2008 From: edi at agharta.de (Edi Weitz) Date: Sun, 01 Jun 2008 00:30:28 +0200 Subject: [hunchentoot-devel] hunchentoot-error error In-Reply-To: <86763A9F-7B7F-45ED-8273-368D5D078C6A@bobobeach.com> (Cyrus Harmon's message of "Sat, 31 May 2008 13:18:10 -0700") References: <86763A9F-7B7F-45ED-8273-368D5D078C6A@bobobeach.com> Message-ID: On Sat, 31 May 2008 13:18:10 -0700, Cyrus Harmon wrote: > conditions.lisp has two definitions of hunchentoot-error, and none > for hunchentoot-warn. Damn, I shouldn't hack on this without at least re-building it afterwards. Thanks again, Edi.