May 2008 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

None
by None 15 May '08

15 May '08

1 0

[hunchentoot-devel] [PATCH] Hunchentoot must depends on FLEXI-STREAMS
by Luca Capello 14 May '08

14 May '08

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

2 1

[hunchentoot-devel] usocket patch and ecl smallcons
by Geo Carncross 14 May '08

14 May '08

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.

2 1

[hunchentoot-devel] How to use Sessions ?
by Thibault Langlois 13 May '08

13 May '08

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

3 5

[hunchentoot-devel] Strange condition during error handling (possible double error?)
by Tomasz Skutnik 10 May '08

10 May '08

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 #<CLOSURE (LAMBDA #) {AF6C86D}>)[:EXTERNAL] 1: (SB-DEBUG:BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {AF6C809}>) 2: (GET-BACKTRACE #<unused argument>) 3: ((LAMBDA (COND)) #<UNBOUND-VARIABLE *REQUEST* {A793961}>) 4: ((LAMBDA (COND)) #<UNBOUND-VARIABLE *REQUEST* {A793961}>)[:EXTERNAL] 5: (SIGNAL #<UNBOUND-VARIABLE *REQUEST* {A793961}>)[:EXTERNAL] 6: (ERROR UNBOUND-VARIABLE)[:EXTERNAL] 7: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB51C1DF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB51C1A7C :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14)) 8: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB51C1DF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB51C1A7C :TYPE (* (SB-ALIEN:STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EXTERNAL] 9: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB51C1A7C) #<unavailable argument>) 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)) #<unused argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1)) #<SB-INT:SIMPLE-STREAM-ERROR {A78E219}>) 15: (SIGNAL #<SB-INT:SIMPLE-STREAM-ERROR {A78E219}>)[:EXTERNAL] 16: (ERROR SB-INT:SIMPLE-STREAM-ERROR)[:EXTERNAL] 17: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "a socket" {B123609}> 32) 18: (SB-IMPL::SIMPLE-STREAM-PERROR "Couldn't write to ~s" #<SB-SYS:FD-STREAM for "a socket" {B123609}> 32)[:EXTERNAL] 19: (FORCE-OUTPUT #<SB-SYS:FD-STREAM for "a socket" {B123609}>) 20: ((SB-PCL::FAST-METHOD SB-GRAY:STREAM-FORCE-OUTPUT (CHUNGA:CHUNKED-OUTPUT-STREAM)) #<unused argument> #<unused argument> #<CHUNGA:CHUNKED-IO-STREAM {B127C49}>) 21: (FORCE-OUTPUT #<CHUNGA:CHUNKED-IO-STREAM {B127C49}>) 22: (FORCE-OUTPUT #<FLEXI-STREAMS::FLEXI-UTF-8-IO-STREAM {B12A4E9}>) 23: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {B3C6FB1}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 11 {B121819}>) 24: ((LAMBDA ())) 25: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) 26: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]438)) 27: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B51C2295}> #S(SB-THREAD:MUTEX :NAME "thread result lock" :%OWNER #<SB-THREAD:THREAD "hunchentoot-worker-2" {B1225D9}> :STATE 1) #<SB-THREAD:THREAD "hunchentoot-worker-2" {B1225D9}> 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

2 2

[hunchentoot-devel] error computing the request object
by Sergio Garcia 09 May '08

09 May '08

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

2 3

[hunchentoot-devel] hunchentoot ecl support
by Geo Carncross 08 May '08

08 May '08

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.

2 2

[hunchentoot-devel] Newbie question - how to examine session object?
by Yarek Kowalik 06 May '08

06 May '08

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) (#<HUNCHENTOOT::SESSION {100245E011}>) CL-USER> (hunchentoot:session-value :remote-addr (#<HUNCHENTOOT::SESSION {100245E011}>) ) ; in: LAMBDA NIL ; (#<HUNCHENTOOT::SESSION {100245E011}>) ; ; 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

3 6