April 2007 - tbnl-devel@common-lisp.net - mailman3.common-lisp.net

[hunchentoot-devel] New release 0.8.4
by Edi Weitz 09 Apr '07

09 Apr '07

No technical changes. This release just fixes some version numbers I botched yesterday. Sorry, Edi.

6 6

[hunchentoot-devel] Processing an error outside the Hunchentoot code
by Andrei Stebakov 08 Apr '07

08 Apr '07

What's the best to add my own error handler? I see there is some processing based on *SHOW-LISP-ERRORS-P* *SHOW-LISP-BACKTRACES-P* inside process-request function, but it doesn't allow to add a user handler of the error (or I just didn't find it). Let's say I don't want a user to see the error (only some nice reassuring message :)) and I want to be notified by an email with the backtrace. Should I go and modify the body of the process-request function (which I'll need to merge with every new release of HT) or is there a way to add my own handler outside of the Hunchentoot code? Thank you, Andrew

3 4

[hunchentoot-devel] New release 0.8.3
by Edi Weitz 07 Apr '07

07 Apr '07

Sorry... ChangeLog: Version 0.8.3 2007-04-07 Don't use chunked encoding for empty (NIL) bodies Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] New release 0.8.2
by Edi Weitz 07 Apr '07

07 Apr '07

ChangeLog: Version 0.8.2 2007-04-05 Really exported REASON-PHRASE this time (and also *CURRENT-PROCESS*) Download: http://weitz.de/files/hunchentoot.tar.gz Yes, the date in the ChangeLog is correct, I couldn't upload the code because I couldn't reach my server that day.

1 0

[hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler
by Andrei Stebakov 06 Apr '07

06 Apr '07

I got a folder on my linux box that contains about 240 images of font preview generated from cl-gd (Thanks, Edi!). When I show them from static apache handler it takes approximately 30 seconds. Same thing from hunchentoot static handler (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand it's not a big deal, but still I'd like to know what might get in the way. I use hunchentoot behind mod-proxy. Here are links (first is static apache, second is hunchentoot): http://www.greenpixeldesign.com/fonts.html http://www.greenpixeldesign.com/cphandler/fonts.html Thank you, Andrew

5 19

[hunchentoot-devel] Intermittent proble while uploading a file
by Andrei Stebakov 06 Apr '07

06 Apr '07

Since I switched to latest SBCL sometimes I got following error: Internal Server Error The value NIL is not of type STRING. 0: (BACKTRACE 536870911 #<SB-IMPL::STRING-OUTPUT-STREAM {CD0F3C9}>) 1: (HUNCHENTOOT:GET-BACKTRACE #<unavailable argument>) 2: ((LAMBDA (COND)) #<TYPE-ERROR {CD0F2A9}>) 3: ((LAMBDA (COND)) #<TYPE-ERROR {CD0F2A9}>) 4: (SIGNAL #<TYPE-ERROR {CD0F2A9}>) 5: (ERROR TYPE-ERROR) 6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB505254C) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB505223C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (142 14)) 7: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER #<unavailable argument> #.(SB-SYS:INT-SAP #XB505254C) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB505223C :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (142 14)) 8: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB505223C) #<unavailable argument>) 9: ("foreign function: call_into_lisp") 10: ("foreign function: funcall2") 11: ("foreign function: interrupt_internal_error") 12: ("foreign function: sigtrap_handler") 13: (MAKE-STRING-INPUT-STREAM NIL 0) 14: (NIL NIL) 15: (CP-API::UPLOAD-FILE "10f14f8c-016c-479a-9709-ce62b2027149" #P"/tmp/upload/6E5824411F6BBA0248441CFCDF13D765-text.png" "Customers") 16: (CP-API::SESSION-GENERATE-DESIGN) 17: (CP-API::CP-PRODUCT) 18: (HUNCHENTOOT::PROCESS-REQUEST ((:HOST . "127.0.0.1:3001") (:ACCEPT . "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*") (:ACCEPT-ENCODING . "gzip, deflate") (:ACCEPT-LANGUAGE . "en-us") (:COOKIE . "sessionid=52%3A6E5824411F6BBA0248441CFCDF13D765") (:UA-CPU . "x86") (:USER-AGENT . "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; Media Center PC 4.0)") (:X-FORWARDED-FOR . "192.168.1.1") (:X-FORWARDED-HOST . "www.greenpixeldesign.com") (:X-FORWARDED-SERVER . "www.greenpixeldesign.com") (:CONNECTION . "close")) #<FLEXI-STREAMS::FLEXI-LATIN-1-IO-STREAM {CBCADE9}> :GET "/cphandler/product.html" :HTTP/1.1) 19: (HUNCHENTOOT::PROCESS-CONNECTION #<HUNCHENTOOT::SERVER {A96A0C9}> #<SB-BSD-SOCKETS:INET-SOCKET descriptor 14 {CBC2559}>) 20: ((LAMBDA ())) 21: ("foreign function: call_into_lisp") 22: ("foreign function: funcall0") 23: ("foreign function: new_thread_trampoline") 24: ("foreign function: #xB7FD5B63")

2 1

[hunchentoot-devel] New release 0.5.1
by Edi Weitz 06 Apr '07

06 Apr '07

ChangeLog: Version 0.5.1 2007-01-18 Even more flexible behaviour of RAW-POST-DATA Download: http://weitz.de/files/hunchentoot.tar.gz Sorry for the noise, Edi.

5 15

[hunchentoot-devel] Re: [flexi-streams-devel] 0.11.1 trouble.
by Edi Weitz 05 Apr '07

05 Apr '07

On Thu, 05 Apr 2007 19:07:40 +0530, quasi <quasilists(a)gmail.com> wrote: > I am running Hunchentoot 8.1. 0.8.1 I hope... :) > As soon as I upgraded to flexi-streams 0.11.1 I have encountered a > weird problem. Hunchentoot (or anything else) threw no errors but > the socket was getting closed unexpectedly I think, because links > cribbed "error reading socket" or something. I am running Allegro > 8.0 Enterprise 64bit on Redhat Linux. (problem also persisted on > Allegro 8.0 for the Intel Mac's) > > As soon as I went back to 0.8.0 (my previous version) all worked as > before. > > Am I doing something wrong here ? I doubt it. There were significant changes between 0.8.0 and 0.11.1 and it is likely that you're the first one to use the new version on AllegroCL, especially on a 64-bit version (if that matters, don't know). There's also a chance that some of my recent Hunchentoot changes which I hastily submitted in the wake of my ILC preparations broke something which results in sockets being closed although they shouldn't. That's why I'm sending a copy of this to tbnl-devel as well. > How can I help debug this more ? Try to get a detailed backtrace of the error. You might want to check what the previous page (before the socket was closed) was supposed to send (return code, size of content, headers, transfer encoding). Also, delete the FASL files from FLEXI-STREAMS and Hunchentoot, recompile, and check all the warnings you might get during compilation. Thanks, Edi.

2 3

[hunchentoot-devel] hcl:mark-and-sweep on 32 bit LispWorks
by Chris Dean 04 Apr '07

04 Apr '07

The HCL:MARK-AND-SWEEP function is only available on 32 bit LispWorks. A small patch is below to allow hunchentoot to run on 64 bit versions of LispWorks. Cheers, Chris Dean diff -rN -u old-hunchentoot/util.lisp new-hunchentoot/util.lisp --- old-contrib/hunchentoot/util.lisp 2007-04-03 10:13:17.000000000 -0700 +++ new-hunchentoot/util.lisp 2007-04-03 10:13:18.000000000 -0700 @@ -461,7 +461,7 @@ (chunked-stream-input-chunking-p (flexi-stream-stream *hunchentoot-stream*))) (defun cleanup-function () - "The default for *CLEANUP-FUNCTION*. Invokes a GC on LispWorks and + "The default for *CLEANUP-FUNCTION*. Invokes a GC on 32 bit LispWorks and does nothing on other Lisps." - #+:lispworks - (hcl:mark-and-sweep 2)) \ No newline at end of file + #+:lispworks-32bit + (hcl:mark-and-sweep 2))

2 2

[hunchentoot-devel] New release 0.8.1
by Edi Weitz 04 Apr '07

04 Apr '07

ChangeLog: Version 0.8.1 2007-04-04 Added HUNCHENTOOT-MP package (suggested by Cyrus Harmon) Only invoke MARK-AND-SWEEP for 32-bit versions of LW (thanks to Chris Dean) Exported REASON-PHRASE Download: http://weitz.de/files/hunchentoot.tar.gz Have fun, Edi.

1 0