From info at jensteich.de Sat Mar 3 19:54:39 2007 From: info at jensteich.de (Jens Teich) Date: Sat, 3 Mar 2007 20:54:39 +0100 Subject: [hunchentoot-devel] static files Message-ID: <00ce01c75dcd$c9736410$0e84ba5a@JensSony> what's wrong with this? (push (create-static-file-dispatcher-and-handler "test.css" #P"test.css") *dispatch-table*) ==> (# DISPATCH-EASY-HANDLERS DEFAULT-DISPATCHER) Jens From edi at agharta.de Sat Mar 3 23:03:43 2007 From: edi at agharta.de (Edi Weitz) Date: Sun, 04 Mar 2007 00:03:43 +0100 Subject: [hunchentoot-devel] static files In-Reply-To: <00ce01c75dcd$c9736410$0e84ba5a@JensSony> (Jens Teich's message of "Sat, 3 Mar 2007 20:54:39 +0100") References: <00ce01c75dcd$c9736410$0e84ba5a@JensSony> Message-ID: On Sat, 3 Mar 2007 20:54:39 +0100, "Jens Teich" wrote: > what's wrong with this? > > (push (create-static-file-dispatcher-and-handler > "test.css" #P"test.css") *dispatch-table*) > ==> > (# > DISPATCH-EASY-HANDLERS > DEFAULT-DISPATCHER) "test.css" doesn't look like a URI that will ever be matched. How about "/test.css" or "/some/path/test.css"? From info at jensteich.de Sun Mar 4 10:53:02 2007 From: info at jensteich.de (Jens Teich) Date: Sun, 4 Mar 2007 11:53:02 +0100 Subject: [hunchentoot-devel] static files References: <00ce01c75dcd$c9736410$0e84ba5a@JensSony> Message-ID: <010101c75e4b$4f30b9e0$0e84ba5a@JensSony> Edi Weitz wrote: > On Sat, 3 Mar 2007 20:54:39 +0100, "Jens Teich" > wrote: > >> what's wrong with this? >> >> (push (create-static-file-dispatcher-and-handler >> "test.css" #P"test.css") *dispatch-table*) >> ==> >> (# >> DISPATCH-EASY-HANDLERS >> DEFAULT-DISPATCHER) > > "test.css" doesn't look like a URI that will ever be matched. How > about "/test.css" or "/some/path/test.css"? "/test.css" does the trick, thanks Edi! Jens From edi at agharta.de Tue Mar 6 10:00:04 2007 From: edi at agharta.de (Edi Weitz) Date: Tue, 06 Mar 2007 11:00:04 +0100 Subject: [hunchentoot-devel] Re: Hunchentoot sbcl :win32 patches In-Reply-To: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> (Marko =?utf-8?q?Koci=C4=87's?= message of "Tue, 6 Mar 2007 10:44:42 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> Message-ID: [Cc to mailing list.] Hi Marko, On Tue, 6 Mar 2007 10:44:42 +0100, "Marko Koci?" wrote: > I wanted to play with hunchentoot on widows using sbcl and made it > work (at least tests are working). Thanks. I won't have enough time to look at this before the second half of the week, though. Which version of SBCL did you use? > In order to do so I had to optinally disable ssl cause I couldn't > find appropriate ssl library to use. This one works for LispWorks: http://www.slproweb.com/products/Win32OpenSSL.html > and applied a patch from William Bland to work without threads. Hmm. I remember that one. I don't think you really want to have a single-threaded web server for anything but testing. Thanks, Edi. From edi at agharta.de Tue Mar 6 10:16:59 2007 From: edi at agharta.de (Edi Weitz) Date: Tue, 06 Mar 2007 11:16:59 +0100 Subject: [hunchentoot-devel] Re: Hunchentoot sbcl :win32 patches In-Reply-To: <9238e8de0703060211v3b931d4bwf2fff87a625f9c67@mail.gmail.com> (Marko =?utf-8?q?Koci=C4=87's?= message of "Tue, 6 Mar 2007 11:11:09 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> <9238e8de0703060211v3b931d4bwf2fff87a625f9c67@mail.gmail.com> Message-ID: On Tue, 6 Mar 2007 11:11:09 +0100, "Marko Koci?" wrote: > and there is no free win32 lisp implementation with threads support, > so at least it will work for testing. If you only need it for testing, why bother with "free"? You can for example use the trial version of LispWorks to test your web server. From Phlex at telenet.be Wed Mar 7 09:48:43 2007 From: Phlex at telenet.be (Phlex) Date: Wed, 07 Mar 2007 10:48:43 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 Message-ID: <45EE8A7B.2060001@telenet.be> Hello, I'm a user of tbnl and finally decided to make the switch to hunchentoot. When trying what's below, i get an empty page in the web browser. Here is what i'm trying : (defparameter *web-server* (start-server :port 3000)) (defmacro with-html (&body body) `(with-html-output-to-string (*standard-output* nil :prologue t) , at body)) (defparameter *original-standard-output* *standard-output*) (defmethod dispatch-request :around (dispatch-table) (pprint "coucou1" *original-standard-output*) (let ((result (call-next-method))) (pprint result *original-standard-output*) (pprint "coucou2" *original-standard-output*) result)) (defun bleh () (with-html (:html (:head (:title "easy demo")) (:body "That's bleh !")))) (setq *dispatch-table* (list (create-prefix-dispatcher "/" #'bleh))) Here is what i see on my standard ouput when i try to visit the web site at this address : http://localhost:3000/ "coucou1" "easy demoThat's bleh !" "coucou2" So it seems that everything goes well ... i'm at a loss wrt what i should do now to actually see the web page ... Thanks in advance for any pointer. My config : lispworks 5.0, win32, firefox, standalone hunchentoot (no mod_lisp, no apache) Sacha From info at jensteich.de Wed Mar 7 10:01:01 2007 From: info at jensteich.de (Jens Teich) Date: Wed, 7 Mar 2007 11:01:01 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 References: <45EE8A7B.2060001@telenet.be> Message-ID: <004301c7609f$88edf070$6402a8c0@JensSony> Phlex wrote: > Hello, > > I'm a user of tbnl and finally decided to make the switch to > hunchentoot. When trying what's below, i get an empty page in the web > browser. > > Here is what i'm trying : > > (defparameter *web-server* (start-server :port 3000)) > > (defmacro with-html (&body body) > `(with-html-output-to-string (*standard-output* nil :prologue t) > , at body)) > > (defparameter *original-standard-output* *standard-output*) > > (defmethod dispatch-request :around (dispatch-table) > (pprint "coucou1" *original-standard-output*) > (let ((result (call-next-method))) > (pprint result *original-standard-output*) > (pprint "coucou2" *original-standard-output*) > result)) > > (defun bleh () > (with-html > (:html > (:head (:title "easy demo")) > (:body "That's bleh !")))) > > (setq *dispatch-table* (list (create-prefix-dispatcher "/" #'bleh))) > > Here is what i see on my standard ouput when i try to visit the web > site at this address : http://localhost:3000/ > > "coucou1" > " \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">easy > demoThat's bleh !" > "coucou2" > > So it seems that everything goes well ... i'm at a loss wrt what i > should do now to actually see the web page ... > Thanks in advance for any pointer. > > My config : lispworks 5.0, win32, firefox, standalone hunchentoot (no > mod_lisp, no apache) Try an easy-handler like this (define-easy-handler (test :uri (prefixed "test"))() (with-html-output-to-string (out) (:html (:head (:title "Testpage")) (:body "Hello World)))) Jens From info at jensteich.de Wed Mar 7 10:06:32 2007 From: info at jensteich.de (Jens Teich) Date: Wed, 7 Mar 2007 11:06:32 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 References: <45EE8A7B.2060001@telenet.be> <004301c7609f$88edf070$6402a8c0@JensSony> Message-ID: <004a01c760a0$49eb26d0$6402a8c0@JensSony> > Try an easy-handler like this > > (define-easy-handler (test :uri (prefixed "test"))() > (with-html-output-to-string (out) > (:html (:head (:title "Testpage")) > (:body "Hello World")))) --------------------------^ one double quote missing, sorry > Jens > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Wed Mar 7 10:11:15 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 07 Mar 2007 11:11:15 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: <45EE8A7B.2060001@telenet.be> (Phlex@telenet.be's message of "Wed, 07 Mar 2007 10:48:43 +0100") References: <45EE8A7B.2060001@telenet.be> Message-ID: On Wed, 07 Mar 2007 10:48:43 +0100, Phlex wrote: > I'm a user of tbnl and finally decided to make the switch to > hunchentoot. When trying what's below, i get an empty page in the > web browser. > > Here is what i'm trying : > > (defparameter *web-server* (start-server :port 3000)) > > (defmacro with-html (&body body) > `(with-html-output-to-string (*standard-output* nil :prologue t) > , at body)) > > (defparameter *original-standard-output* *standard-output*) > > (defmethod dispatch-request :around (dispatch-table) > (pprint "coucou1" *original-standard-output*) > (let ((result (call-next-method))) > (pprint result *original-standard-output*) > (pprint "coucou2" *original-standard-output*) > result)) > > (defun bleh () > (with-html > (:html > (:head (:title "easy demo")) > (:body "That's bleh !")))) > > (setq *dispatch-table* (list (create-prefix-dispatcher "/" #'bleh))) > > Here is what i see on my standard ouput when i try to visit the web > site at this address : http://localhost:3000/ > > "coucou1" > " \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">easy > demoThat's bleh !" > "coucou2" > > So it seems that everything goes well ... i'm at a loss wrt what i > should do now to actually see the web page ... Thanks in advance > for any pointer. Your example works fine for me if entered in the order you showed above (assuming you're within a package where the Hunchentoot and CL-WHO symbols are accessible). If you don't see anything in your browser, my /guess/ is that maybe you redefined BLEH. I'd recommend using (setq *dispatch-table* (list (create-prefix-dispatcher "/" 'bleh))) instead, so changes to BLEH are immediately picked up. Let us know if that doesn't help. Cheers, Edi. From Phlex at telenet.be Wed Mar 7 10:25:44 2007 From: Phlex at telenet.be (Phlex) Date: Wed, 07 Mar 2007 11:25:44 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: References: <45EE8A7B.2060001@telenet.be> Message-ID: <45EE9328.30606@telenet.be> Edi Weitz wrote: > > > Your example works fine for me if entered in the order you showed > above (assuming you're within a package where the Hunchentoot and > CL-WHO symbols are accessible). > > If you don't see anything in your browser, my /guess/ is that maybe > you redefined BLEH. I'd recommend using > > (setq *dispatch-table* (list (create-prefix-dispatcher "/" 'bleh))) > > instead, so changes to BLEH are immediately picked up. > > Let us know if that doesn't help. > > Cheers, > Edi. > _____ I've tried Mr Teich solution with no success. Thanks for the pointer about using the symbol name of the function instead of the function pointer. I've been using an additional level of indirection with tbnl for months... and now i see this: very usefull =) I've been trying all this in a fresh image (only asdf:load-op's and use-package's are left out of my example code) and still the web browser shows nothing but an empty page (page size = 0 byte) Beside, the debug output shows that the bleh function was called and the result sent to hunchentoot. I'll try re-installing all support libraries (which i thought i did yesterday) and see if that helps... I'll keep you updated Thanks for your time Sacha From Phlex at telenet.be Wed Mar 7 10:44:46 2007 From: Phlex at telenet.be (Phlex) Date: Wed, 07 Mar 2007 11:44:46 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: <45EE9328.30606@telenet.be> References: <45EE8A7B.2060001@telenet.be> <45EE9328.30606@telenet.be> Message-ID: <45EE979E.7030303@telenet.be> > I'll try re-installing all support libraries (which i thought i did yesterday) and see if that helps... That was the problem... I didn't update the trivial-gray-streams and flexi-streams libraries. Sorry about this false alarm ! Sacha From info at jensteich.de Wed Mar 7 10:45:39 2007 From: info at jensteich.de (Jens Teich) Date: Wed, 7 Mar 2007 11:45:39 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 References: <45EE8A7B.2060001@telenet.be> <45EE9328.30606@telenet.be> Message-ID: <005901c760a5$c16aa2d0$6402a8c0@JensSony> Are you able to launch the hunchentoot testpage? Jens From edi at agharta.de Wed Mar 7 10:51:38 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 07 Mar 2007 11:51:38 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: <45EE979E.7030303@telenet.be> (Phlex@telenet.be's message of "Wed, 07 Mar 2007 11:44:46 +0100") References: <45EE8A7B.2060001@telenet.be> <45EE9328.30606@telenet.be> <45EE979E.7030303@telenet.be> Message-ID: On Wed, 07 Mar 2007 11:44:46 +0100, Phlex wrote: > That was the problem... I didn't update the trivial-gray-streams and > flexi-streams libraries. Hehe... :) > Sorry about this false alarm ! No problem. From jmckitrick at reedlarkeygroup.com Wed Mar 7 23:15:53 2007 From: jmckitrick at reedlarkeygroup.com (Jonathon McKitrick) Date: Wed, 7 Mar 2007 18:15:53 -0500 (EST) Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: References: <45EE8A7B.2060001@telenet.be> Message-ID: <3166.68.44.154.215.1173309353.squirrel@reedlarkeygroup.com> On Wed, March 7, 2007 5:11 am, Edi Weitz said: >> (setq *dispatch-table* (list (create-prefix-dispatcher "/" #'bleh))) > you redefined BLEH. I'd recommend using > > (setq *dispatch-table* (list (create-prefix-dispatcher "/" 'bleh))) > > instead, so changes to BLEH are immediately picked up. I'd like to understand from a lisp standpoint why this works the way it does. What is it about the function operator #' that it only grabs the value of the symbol when first evaluated? Is there a 'hidden' closure operation? -- Jonathon McKitrick Reed Larkey Group From nowhere.man at levallois.eu.org Wed Mar 7 23:35:37 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Thu, 8 Mar 2007 00:35:37 +0100 Subject: [hunchentoot-devel] standalone server lw 5.0 In-Reply-To: <3166.68.44.154.215.1173309353.squirrel@reedlarkeygroup.com> References: <45EE8A7B.2060001@telenet.be> <3166.68.44.154.215.1173309353.squirrel@reedlarkeygroup.com> Message-ID: <20070307233537.GP13599@bateleur.arcanes.fr.eu.org> Scribit Jonathon McKitrick dies 07/03/2007 hora 18:15: > I'd like to understand from a lisp standpoint why this works the way > it does. What is it about the function operator #' that it only grabs > the value of the symbol when first evaluated? Is there a 'hidden' > closure operation? No need for this. Each symbol has an associated reference to a function. The symbol-function operator just returns this reference. After calling it, changing the symbol's function to another one only makes that the function you just got a reference to is not referenced anymore by this symbol. If you want a function that would change when the symbol is redefined, use the following instead of symbol-function: (defun tracking-symbol-function (symbol) (lambda (&rest args) (apply (symbol-function symbol) args))) Obviously there's an overhead when calling this one. Quickly, Pierre -- nowhere.man at levallois.eu.org OpenPGP 0xD9D50D8A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jc at itsec.co.kr Thu Mar 8 05:27:58 2007 From: jc at itsec.co.kr (Jong-won Choi) Date: Thu, 08 Mar 2007 14:27:58 +0900 Subject: [hunchentoot-devel] Errors with test pages Message-ID: <45EF9EDE.5080002@itsec.co.kr> Hello I have errors with Hunchentoot's test pages - 'GET parameter handling with UTF-8 charset' and 'POST parameter handling with UTF-8 charset' get errors. I thought (setf (content-type) ...) in parameter-test function does this utf-8 magic, but it seems it does not work and raise an error later. I'm trying standalone Hunchentoot - I'm an old TBNL user. TBNL (with lighttpd + fastcgi) test pages work fine. My configurations is: Ubuntu 6.06.1 LTS LW 4.4.6 Professional chunga-0.2.4 cl-base64-3.3.2 cl-ppcre-1.2.19 cl-who-0.6.3 flexi-streams-0.10.3 hunchentoot-0.6.2 md5-1.8.5 rfc2388 trivial-gray-streams-2006-09-16 url-rewrite-0.1.1 Anyone can confirm the test pages are working? Fix for this problem? Cheers Jong-won Choi From edi at agharta.de Thu Mar 8 10:06:15 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 08 Mar 2007 11:06:15 +0100 Subject: [hunchentoot-devel] Errors with test pages In-Reply-To: <45EF9EDE.5080002@itsec.co.kr> (Jong-won Choi's message of "Thu, 08 Mar 2007 14:27:58 +0900") References: <45EF9EDE.5080002@itsec.co.kr> Message-ID: On Thu, 08 Mar 2007 14:27:58 +0900, Jong-won Choi wrote: > I have errors with Hunchentoot's test pages What errors do you get? Can you provide a backtrace? From jc at itsec.co.kr Thu Mar 8 11:29:29 2007 From: jc at itsec.co.kr (Jong-won Choi) Date: Thu, 08 Mar 2007 20:29:29 +0900 Subject: [hunchentoot-devel] Errors with test pages In-Reply-To: References: <45EF9EDE.5080002@itsec.co.kr> Message-ID: <45EFF399.5000207@itsec.co.kr> Edi Weitz wrote: > On Thu, 08 Mar 2007 14:27:58 +0900, Jong-won Choi wrote: > > >> I have errors with Hunchentoot's test pages >> > > What errors do you get? Can you provide a backtrace? I assume that means you don't have a such problem with '|http://localhost:4242/hunchentoot/test|'. I'll provide the backtrace soon then. From jc at itsec.co.kr Thu Mar 8 12:22:48 2007 From: jc at itsec.co.kr (Jong-won Choi) Date: Thu, 08 Mar 2007 21:22:48 +0900 Subject: [hunchentoot-devel] Errors with test pages In-Reply-To: References: <45EF9EDE.5080002@itsec.co.kr> Message-ID: <45F00018.8020705@itsec.co.kr> Edi Weitz wrote: > What errors do you get? Can you provide a backtrace? > Here is the backtrace. My example input for 'Enter a value:' is ??? And there are two backtrace(they look same) 1. http://localhost:4242/hunchentoot/test/parameter_utf8_get.html 2. http://localhost:4242/hunchentoot/test/parameter_utf8_post.html If you need any additional information, just let me know. Thanks Jong-won ============= 1. http://localhost:4242/hunchentoot/test/parameter_utf8_get.html [2007-03-08 21:03:35 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\? is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) SEQ::TARGET-SEQUENCE : "tml HTTP/1.1\\\" 200 1194 \\\"http://localhost:4242/hunchentoot/test/\\\" \\\"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\\\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\\\    44EA '  ??  ?   % %             )n \"                        '  ?B@  X ?:? ?t % ??? ???! %   ???!" SEQ::SOURCE-SEQUENCE : "[2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\\\<65E5> ist%2Fparameter_utf8_get.html%3Ffoo%3D%25ED%2595%259C%25EA%25B8%2580+HTTP%2F1.1%22+500+295+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+20%3A59%3A42%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0ARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8982> # #)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \" \" " SEQ::TARGET-START : 181 SEQ::TARGET-END : :DONT-KNOW SEQ::SOURCE-START : 0 SEQ::SOURCE-END : 71 Call to (METHOD STREAM:STREAM-WRITE-STRING (STREAM:BUFFERED-STREAM T)) (offset 346) STREAM : # STRING : "[2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\\\<65E5> ist%2Fparameter_utf8_get.html%3Ffoo%3D%25ED%2595%259C%25EA%25B8%2580+HTTP%2F1.1%22+500+295+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+20%3A59%3A42%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0ARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8982> # #)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \" \" " STREAM::START : 0 STREAM::END : 73 Call to # (offset 176) Call to SYSTEM::WRITE-STRING* (offset 706) STRING : "[2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\\\<65E5> ist%2Fparameter_utf8_get.html%3Ffoo%3D%25ED%2595%259C%25EA%25B8%2580+HTTP%2F1.1%22+500+295+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+20%3A59%3A42%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0ARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8982> # #)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \" \" " STREAM : # SYSTEM::START : 0 SYSTEM::END : 73 Call to LW-XP::FLUSH (offset 205) LW-XP::XP : # Call to LW-XP::WRITE-CHAR++ (offset 48) CHAR : #\s LW-XP::XP : # Call to LW-XP::WRITE-CHAR+ (offset 51) LW-XP::XP : # CHAR : #\s Call to IO::QUOTE-FAT-STRING (offset 206) IO::S : "[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> " IO::OUT : # IO::CHAR-METHOD : :NOT-WRITE-CHAR IO::STRING-METHOD : :NOT-WRITE-STRING LENGTH : 1266 Binding frame: LW-XP::*PARENTS* : NIL Call to LW-XP::WRITE+ (offset 383) LW-XP::OBJECT : "[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> " LW-XP::XP : # Catch frame: LW-XP::LINE-LIMIT-ABBREVIATION-EXIT Binding frame: LW-XP::*CURRENT-LEVEL* : 0 Call to LW-XP::DO-XP-PRINTING (offset 105) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> ") Call to LW-XP::XP-PRINT (offset 22) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> ") Binding frame: LW-XP::*INSIDE-MAYBE-INITIATE-XP-PRINTING* : NIL Binding frame: LW-XP::*RESULT* : NIL Binding frame: LW-XP::*PARENTS* : NIL Binding frame: LW-XP::*CIRCULARITY-HASH-TABLE* : NIL Binding frame: LW-XP::*LOCATING-CIRCULARITIES* : NIL Binding frame: LW-XP::*ABBREVIATION-HAPPENED* : NIL Call to LW-XP::MAYBE-INITIATE-XP-PRINTING (offset 312) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> ") Binding frame: IO:*ACTIVE-OUTPUT* : # Binding frame: IO::*DUPLICATE-ENTRIES* : NIL Binding frame: IO::*PRINTED-DUPLICATES* : NIL Binding frame: *PRINT-RIGHT-MARGIN* : NIL Binding frame: *PRINT-READABLY* : NIL Binding frame: *PRINT-RADIX* : NIL Binding frame: *PRINT-PRETTY* : NIL Binding frame: *PRINT-PPRINT-DISPATCH* : # Binding frame: *PRINT-MISER-WIDTH* : 40 Binding frame: *PRINT-LINES* : NIL Binding frame: *PRINT-LEVEL* : NIL Binding frame: *PRINT-LENGTH* : NIL Binding frame: *PRINT-GENSYM* : T Binding frame: *PRINT-ESCAPE* : T Binding frame: *PRINT-CIRCLE* : NIL Binding frame: *PRINT-CASE* : :UPCASE Binding frame: *PRINT-BASE* : 10 Binding frame: *PRINT-ARRAY* : T Call to WRITE (offset 912) IO::OBJECT : "[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> " STREAM : # *PRINT-ARRAY* : T *PRINT-BASE* : 10 *PRINT-CASE* : :UPCASE *PRINT-CIRCLE* : T *PRINT-ESCAPE* : T *PRINT-GENSYM* : T *PRINT-LENGTH* : 16384 *PRINT-LEVEL* : 128 *PRINT-LINES* : NIL *PRINT-MISER-WIDTH* : NIL *PRINT-PPRINT-DISPATCH* : NIL *PRINT-PRETTY* : NIL *PRINT-RADIX* : NIL *PRINT-READABLY* : NIL *PRINT-RIGHT-MARGIN* : NIL Call to PPRINT (offset 94) IO::OBJECT : "[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> " STREAM : # Catch frame: # Binding frame: *PACKAGE* : # Binding frame: *STANDARD-OUTPUT* : # Binding frame: *STANDARD-OUTPUT* : # Binding frame: *STANDARD-OUTPUT* : # Catch frame: # Call to HUNCHENTOOT-TEST::PARAMETER-TEST (offset 6844) METHOD : :GET HUNCHENTOOT-TEST::CHARSET : :UTF-8 DBG::OBJ : # DBG::DESC : (# T (CHARACTER)) *STANDARD-OUTPUT* : # *STANDARD-OUTPUT* : # *STANDARD-OUTPUT* : # *PACKAGE* : # DBG::OBJ : # DBG::DESC : (# T (BASE-CHAR)) HUNCHENTOOT-TEST::S : # DBG::G : "[2007-03-08 20:55:46] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html?foo=%ED%95%9C%EA%B8%80 HTTP/1.1\" 500 295 \"http://localhost:4242/hunchentoot/test/parameter_utf8_get.html\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 20:59:42] 127.0.0.1 - \"GET /hunchentoot/test/parameter_utf8_get.html HTTP/1.1\" 200 1194 \"http://localhost:4242/hunchentoot/test/\" \"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10\" [2007-03-08 21:00:33 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\\<65E5> is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) <65E5><672C><8A9E> " DBG::|tail-| : NIL FIRST : T Catch frame: HANDLER-DONE Binding frame: *DISPATCH-TABLE* : (DISPATCH-EASY-HANDLERS # # # # # # # # # # # # # # # # # # # # # #) Binding frame: *REQUEST* : # Binding frame: *REPLY* : # Binding frame: *SESSION* : # Catch frame: # Binding frame: HUNCHENTOOT::*HEADERS-SENT* : NIL Binding frame: HUNCHENTOOT::*TMP-FILES* : NIL Call to HUNCHENTOOT::PROCESS-REQUEST (offset 846) HEADERS-IN : ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:REFERER . "http://localhost:4242/hunchentoot/test/parameter_utf8_get.html")) HUNCHENTOOT::CONTENT-STREAM : # METHOD : :GET HUNCHENTOOT::URL-STRING : "/hunchentoot/test/parameter_utf8_get.html?foo=%5B2007-03-08+20%3A55%3A46%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%3Ffoo%3D%25ED%2595%259C%25EA%25B8%2580+HTTP%2F1.1%22+500+295+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+20%3A59%3A42%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0A" SERVER-PROTOCOL : :HTTP/1.1 HUNCHENTOOT::*TMP-FILES* : NIL HUNCHENTOOT::*HEADERS-SENT* : NIL *SESSION* : NIL *REPLY* : # *REQUEST* : # *DISPATCH-TABLE* : (DISPATCH-EASY-HANDLERS # # # # # # # # # # # # # # # # # # # # # #) HUNCHENTOOT::BACKTRACE : NIL DBG::G : # DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #1=#)) ((ERROR . #) (WARNING . #)) ((ERROR . #1#)) ((WARNING . #))) DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #1=#)) ((ERROR . #) (WARNING . #)) ((ERROR . #1#)) ((WARNING . #))) Binding frame: HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* : NIL Catch frame: # Binding frame: *SERVER* : # Catch frame: # Binding frame: HUNCHENTOOT::*REMOTE-PORT* : # Binding frame: HUNCHENTOOT::*REMOTE-HOST* : # Binding frame: HUNCHENTOOT::*LOCAL-HOST* : # Binding frame: HUNCHENTOOT::*HUNCHENTOOT-STREAM* : # Call to HUNCHENTOOT::PROCESS-CONNECTION (offset 970) HUNCHENTOOT::SERVER : # HUNCHENTOOT::HANDLE : 5 DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #)) ((WARNING . #))) DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #)) ((WARNING . #))) HUNCHENTOOT::*HUNCHENTOOT-STREAM* : # HUNCHENTOOT::*LOCAL-HOST* : "127.0.0.1" HUNCHENTOOT::*REMOTE-HOST* : "127.0.0.1" HUNCHENTOOT::*REMOTE-PORT* : 44677 *SERVER* : # HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* : T HEADERS-IN : ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:REFERER . "http://localhost:4242/hunchentoot/test/parameter_utf8_get.html")) HUNCHENTOOT::CONTENT-STREAM : # METHOD : :GET HUNCHENTOOT::URL-STRING : "/hunchentoot/test/parameter_utf8_get.html?foo=%5B2007-03-08+20%3A55%3A46%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%3Ffoo%3D%25ED%2595%259C%25EA%25B8%2580+HTTP%2F1.1%22+500+295+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+20%3A59%3A42%5D+127.0.0.1+-+%22GET+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0A" SERVER-PROTOCOL : :HTTP/1.1 DBG::EXTRA-VALS : :DONT-KNOW Catch frame: MP::PROCESS-TAG Catch frame: (NIL) Binding frame: MP:*CURRENT-PROCESS* : NIL Binding frame: MP::*ACTIONS-AFTER-SLEEPING* : NIL Binding frame: MP::*ACTIONS-BEFORE-SLEEPING* : NIL Binding frame: SYSTEM::*READER-STATE* : # Binding frame: *PACKAGE* : # Binding frame: EDITOR::*CURRENT-BUFFER* : NIL Binding frame: EDITOR::*CURRENT-WINDOW* : NIL Binding frame: EDITOR::*EDITOR-STATE* : NIL Binding frame: EDITOR::*EDITOR-INPUT-STYLE* : #S(EDITOR:EDITOR-INPUT-STYLE :KEY-BINDINGS # 1 334> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS # :EXECUTE-MODE # :ECHO-MODE # :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T) Binding frame: CAPI::*USE-ACCELERATORS* : T Catch frame: #:CATCHER92494 Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) (offset 277) MP::IGNORED : :DONT-KNOW Call to SYSTEM::%%FIRST-CALL-TO-STACK (offset 41) SYSTEM::%%FIRST-CALL-TO-STACK 2. http://localhost:4242/hunchentoot/test/parameter_utf8_post.html [2007-03-08 21:05:09 [ERROR]] In a call to SEQ::%SET-ACCESS-ARRAY: #\? is not of type BASE-CHAR. # Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION 5 HUNCHENTOOT::PROCESS-REQUEST) (offset 101) COND : # Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : T Call to SIGNAL (offset 699) CONDITIONS::DATUM : # CONDITIONS::ARGUMENTS : NIL Binding frame: CONDITIONS::*IN-SIGNAL-CATCH* : NIL Catch frame: CONDITIONS::SIGNAL-CATCH Binding frame: CONDITIONS::*BROKEN-ON-SIGNALS* : NIL Call to (SETF AREF) (offset 1203) Call to SYSTEM::REPLACE*-NO-CHECK (offset 1213) SEQ::TARGET-SEQUENCE : " \"POST-PARAMETER "foo") (POST-PARAMETER "foo"))5 67 37 69 56 37 65 65 37 57 69);q=0.5fox/1.5.0.1000 295 \\\"" SEQ::SOURCE-SEQUENCE : "\"<65E5><672C><8A9E>\"-PARAMETER \"foo\") (POST-PARAMETER \"foo\")) 69 54 37 57 67 37 65 67 37ITIALIZE-PROCESS-STACK) (offset 277) Table{335} 20C59D7C> 1 334> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS # :EXECUTE-MODE # :ECHO-MODE # :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T)T+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0A\"UIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C895A> #)FIX-DISPATCHER) 213C8932>)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \\\" \\\" \" \" " SEQ::TARGET-START : 1 SEQ::TARGET-END : :DONT-KNOW SEQ::SOURCE-START : 0 SEQ::SOURCE-END : 2 Call to (METHOD STREAM:STREAM-WRITE-STRING (STREAM:BUFFERED-STREAM T)) (offset 346) STREAM : # STRING : "\"<65E5><672C><8A9E>\"-PARAMETER \"foo\") (POST-PARAMETER \"foo\")) 69 54 37 57 67 37 65 67 37ITIALIZE-PROCESS-STACK) (offset 277) Table{335} 20C59D7C> 1 334> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS # :EXECUTE-MODE # :ECHO-MODE # :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T)T+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0A\"UIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C895A> #)FIX-DISPATCHER) 213C8932>)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \\\" \\\" \" \" " STREAM::START : 0 STREAM::END : 5 Call to # (offset 176) Call to SYSTEM::WRITE-STRING* (offset 706) STRING : "\"<65E5><672C><8A9E>\"-PARAMETER \"foo\") (POST-PARAMETER \"foo\")) 69 54 37 57 67 37 65 67 37ITIALIZE-PROCESS-STACK) (offset 277) Table{335} 20C59D7C> 1 334> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS # :EXECUTE-MODE # :ECHO-MODE # :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T)T+%2Fhunchentoot%2Ftest%2Fparameter_utf8_get.html+HTTP%2F1.1%22+200+1194+%22http%3A%2F%2Flocalhost%3A4242%2Fhunchentoot%2Ftest%2F%22+%22Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.8.0.10%29+Gecko%2F20070302+Ubuntu%2Fdapper-security+Firefox%2F1.5.0.10%22%0D%0A%5B2007-03-08+21%3A00%3A33+%5BERROR%5D%5D+In+a+call+to+SEQ%3A%3A%25SET-ACCESS-ARRAY%3A+%23%5C%E6%97%A5+is+not+of+type+BASE-CHAR.%0D%0A%23%3CPACKAGE+HUNCHENTOOT-TEST-USER%3E%0D%0A%0D%0A%0D%0ACall+to+%28HARLEQUIN-COMMON-LISP%3ASUBFUNCTION+5+HUNCHENTOOT%3A%3APROCESS-REQUEST%29+%28offset+101%29%0D%0A++COND+%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+T%0D%0A%0D%0ACall+to+SIGNAL+%28offset+699%29%0D%0A++CONDITIONS%3A%3ADATUM+++++%3A+%23%3CCONDITIONS%3ATYPE-ERROR-FUNCTION+2071246C%3E%0D%0A++CONDITIONS%3A%3AARGUMENTS+%3A+NIL%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*IN-SIGNAL-CATCH*+%3A+NIL%0D%0A%0D%0ACatch+frame%3A+CONDITIONS%3A%3ASIGNAL-CATCH%0D%0A%0D%0ABinding+frame%3A%0D%0A++CONDITIONS%3A%3A*BROKEN-ON-SIGNALS*+%3A+NIL%0D%0A%0D%0ACall+to+%28SETF+AREF%29+%28offset+1203%29%0D%0A%0D%0ACall+to+SYSTEM%3A%3AREPLACE*-NO-CHECK+%28offset+1213%29%0D%0A%E6%97%A5%E6%9C%AC%E8%AA%9E%0D%0A\"UIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C895A> #)FIX-DISPATCHER) 213C8932>)sure (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 CREATE-PREFIX-DISPATCHER) 213C8932>) \\\" \\\" \" \" " STREAM : # SYSTEM::START : 0 SYSTEM::END : 5 Call to LW-XP::FLUSH (offset 205) LW-XP::XP : # Catch frame: LW-XP::LINE-LIMIT-ABBREVIATION-EXIT Binding frame: LW-XP::*CURRENT-LEVEL* : 0 Call to LW-XP::DO-XP-PRINTING (offset 232) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("<65E5><672C><8A9E>") Call to LW-XP::XP-PRINT (offset 22) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("<65E5><672C><8A9E>") Binding frame: LW-XP::*INSIDE-MAYBE-INITIATE-XP-PRINTING* : NIL Binding frame: LW-XP::*RESULT* : NIL Binding frame: LW-XP::*PARENTS* : NIL Binding frame: LW-XP::*CIRCULARITY-HASH-TABLE* : NIL Binding frame: LW-XP::*LOCATING-CIRCULARITIES* : NIL Binding frame: LW-XP::*ABBREVIATION-HAPPENED* : NIL Call to LW-XP::MAYBE-INITIATE-XP-PRINTING (offset 312) LW-XP::FN : # STREAM : # LW-XP::ARGS : ("<65E5><672C><8A9E>") Binding frame: IO:*ACTIVE-OUTPUT* : # Binding frame: IO::*DUPLICATE-ENTRIES* : NIL Binding frame: IO::*PRINTED-DUPLICATES* : NIL Binding frame: *PRINT-RIGHT-MARGIN* : NIL Binding frame: *PRINT-READABLY* : NIL Binding frame: *PRINT-RADIX* : NIL Binding frame: *PRINT-PRETTY* : NIL Binding frame: *PRINT-PPRINT-DISPATCH* : # Binding frame: *PRINT-MISER-WIDTH* : 40 Binding frame: *PRINT-LINES* : NIL Binding frame: *PRINT-LEVEL* : NIL Binding frame: *PRINT-LENGTH* : NIL Binding frame: *PRINT-GENSYM* : T Binding frame: *PRINT-ESCAPE* : T Binding frame: *PRINT-CIRCLE* : NIL Binding frame: *PRINT-CASE* : :UPCASE Binding frame: *PRINT-BASE* : 10 Binding frame: *PRINT-ARRAY* : T Call to WRITE (offset 912) IO::OBJECT : "<65E5><672C><8A9E>" STREAM : # *PRINT-ARRAY* : T *PRINT-BASE* : 10 *PRINT-CASE* : :UPCASE *PRINT-CIRCLE* : T *PRINT-ESCAPE* : T *PRINT-GENSYM* : T *PRINT-LENGTH* : 16384 *PRINT-LEVEL* : 128 *PRINT-LINES* : NIL *PRINT-MISER-WIDTH* : NIL *PRINT-PPRINT-DISPATCH* : NIL *PRINT-PRETTY* : NIL *PRINT-RADIX* : NIL *PRINT-READABLY* : NIL *PRINT-RIGHT-MARGIN* : NIL Call to PPRINT (offset 94) IO::OBJECT : "<65E5><672C><8A9E>" STREAM : # Catch frame: # Binding frame: *PACKAGE* : # Binding frame: *STANDARD-OUTPUT* : # Binding frame: *STANDARD-OUTPUT* : # Binding frame: *STANDARD-OUTPUT* : # Catch frame: # Call to HUNCHENTOOT-TEST::PARAMETER-TEST (offset 7246) METHOD : :POST HUNCHENTOOT-TEST::CHARSET : :UTF-8 DBG::OBJ : # DBG::DESC : (# T (CHARACTER)) *STANDARD-OUTPUT* : # *STANDARD-OUTPUT* : # *STANDARD-OUTPUT* : # *PACKAGE* : # DBG::OBJ : # DBG::DESC : (# T (BASE-CHAR)) HUNCHENTOOT-TEST::S : # DBG::G : "<65E5><672C><8A9E>" DBG::|tail-| : NIL FIRST : T Catch frame: HANDLER-DONE Binding frame: *DISPATCH-TABLE* : (DISPATCH-EASY-HANDLERS # # # # # # # # # # # # # # # # # # # # # #) Binding frame: *REQUEST* : # Binding frame: *REPLY* : # Binding frame: *SESSION* : # Catch frame: # Binding frame: HUNCHENTOOT::*HEADERS-SENT* : NIL Binding frame: HUNCHENTOOT::*TMP-FILES* : NIL Call to HUNCHENTOOT::PROCESS-REQUEST (offset 846) HEADERS-IN : ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:REFERER . "http://localhost:4242/hunchentoot/test/parameter_utf8_post.html") (:CONTENT-TYPE . "application/x-www-form-urlencoded") (:CONTENT-LENGTH . "31")) HUNCHENTOOT::CONTENT-STREAM : # METHOD : :POST HUNCHENTOOT::URL-STRING : "/hunchentoot/test/parameter_utf8_post.html" SERVER-PROTOCOL : :HTTP/1.1 HUNCHENTOOT::*TMP-FILES* : NIL HUNCHENTOOT::*HEADERS-SENT* : NIL *SESSION* : NIL *REPLY* : # *REQUEST* : # *DISPATCH-TABLE* : (DISPATCH-EASY-HANDLERS # # # # # # # # # # # # # # # # # # # # # #) HUNCHENTOOT::BACKTRACE : NIL DBG::G : # DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #1=#)) ((ERROR . #) (WARNING . #)) ((ERROR . #1#)) ((WARNING . #))) DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #1=#)) ((ERROR . #) (WARNING . #)) ((ERROR . #1#)) ((WARNING . #))) Binding frame: HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* : NIL Catch frame: # Binding frame: *SERVER* : # Catch frame: # Binding frame: HUNCHENTOOT::*REMOTE-PORT* : # Binding frame: HUNCHENTOOT::*REMOTE-HOST* : # Binding frame: HUNCHENTOOT::*LOCAL-HOST* : # Binding frame: HUNCHENTOOT::*HUNCHENTOOT-STREAM* : # Call to HUNCHENTOOT::PROCESS-CONNECTION (offset 970) HUNCHENTOOT::SERVER : # HUNCHENTOOT::HANDLE : 5 DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #)) ((WARNING . #))) DBG::G : # CONDITIONS::*HANDLER-CLUSTERS* : (((ERROR . #)) ((WARNING . #))) HUNCHENTOOT::*HUNCHENTOOT-STREAM* : # HUNCHENTOOT::*LOCAL-HOST* : "127.0.0.1" HUNCHENTOOT::*REMOTE-HOST* : "127.0.0.1" HUNCHENTOOT::*REMOTE-PORT* : 44678 *SERVER* : # HUNCHENTOOT::*CLOSE-HUNCHENTOOT-STREAM* : T HEADERS-IN : ((:HOST . "localhost:4242") (:USER-AGENT . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302 Ubuntu/dapper-security Firefox/1.5.0.10") (:ACCEPT . "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:KEEP-ALIVE . "300") (:CONNECTION . "keep-alive") (:REFERER . "http://localhost:4242/hunchentoot/test/parameter_utf8_post.html") (:CONTENT-TYPE . "application/x-www-form-urlencoded") (:CONTENT-LENGTH . "31")) HUNCHENTOOT::CONTENT-STREAM : # METHOD : :POST HUNCHENTOOT::URL-STRING : "/hunchentoot/test/parameter_utf8_post.html" SERVER-PROTOCOL : :HTTP/1.1 DBG::EXTRA-VALS : :DONT-KNOW Catch frame: MP::PROCESS-TAG Catch frame: (NIL) Binding frame: MP:*CURRENT-PROCESS* : NIL Binding frame: MP::*ACTIONS-AFTER-SLEEPING* : NIL Binding frame: MP::*ACTIONS-BEFORE-SLEEPING* : NIL Binding frame: SYSTEM::*READER-STATE* : # Binding frame: *PACKAGE* : # Binding frame: EDITOR::*CURRENT-BUFFER* : NIL Binding frame: EDITOR::*CURRENT-WINDOW* : NIL Binding frame: EDITOR::*EDITOR-STATE* : NIL Binding frame: EDITOR::*EDITOR-INPUT-STYLE* : #S(EDITOR:EDITOR-INPUT-STYLE :KEY-BINDINGS # 1 334> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS # :EXECUTE-MODE # :ECHO-MODE # :PLIST NIL :INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2) #S(SYSTEM::GESTURE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T :USE-FACE-TO-FULL-WIDTH-P T) Binding frame: CAPI::*USE-ACCELERATORS* : T Catch frame: #:CATCHER92494 Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) (offset 277) MP::IGNORED : :DONT-KNOW Call to SYSTEM::%%FIRST-CALL-TO-STACK (offset 41) SYSTEM::%%FIRST-CALL-TO-STACK -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug URL: From jc at itsec.co.kr Thu Mar 8 12:46:08 2007 From: jc at itsec.co.kr (Jong-won Choi) Date: Thu, 08 Mar 2007 21:46:08 +0900 Subject: [hunchentoot-devel] Errors with test pages In-Reply-To: <45F00018.8020705@itsec.co.kr> References: <45EF9EDE.5080002@itsec.co.kr> <45F00018.8020705@itsec.co.kr> Message-ID: <45F00590.1050602@itsec.co.kr> Jong-won Choi wrote: > Edi Weitz wrote: >> What errors do you get? Can you provide a backtrace? >> > Here is the backtrace. > > My example input for 'Enter a value:' is ??? > > And there are two backtrace(they look same) > > 1. http://localhost:4242/hunchentoot/test/parameter_utf8_get.html > 2. http://localhost:4242/hunchentoot/test/parameter_utf8_post.html I'm sorry for the duplicated attachment. My kid acted like a little tiger when I was sending the message. I hope you can see the Japanese characters without a problem. Regards Jong-won From nowhere.man at levallois.eu.org Fri Mar 9 05:17:12 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Fri, 9 Mar 2007 06:17:12 +0100 Subject: [hunchentoot-devel] Re: Mercurial repositories In-Reply-To: References: <7EB05352-CA54-4431-9CE3-73AE8D913992@bobobeach.com> <20070119003232.GC16524@bateleur.arcanes.fr.eu.org> <20070215024100.GA7532@bateleur.arcanes.fr.eu.org> Message-ID: <20070309051712.GC8176@bateleur.arcanes.fr.eu.org> Scribit Edi Weitz dies 15/02/2007 hora 08:27: > Let me know once you're done with the other libs, and I'll add links > there as well. Now hunchentoot is available too, with versions from 0.4.0 to 0.6.2. http://arcanes.fr.eu.org/~pierre/2007/02/weitz/ As I have in the chunga and hunchentoot repositories all released versions that could be mirrored, those two repositories should remain stable, that is changesets identities will be preserved. Distributively, Pierre -- nowhere.man at levallois.eu.org OpenPGP 0xD9D50D8A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From edi at agharta.de Fri Mar 9 11:09:53 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 12:09:53 +0100 Subject: [hunchentoot-devel] New release 0.7.0 (Was: Hunchentoot sbcl :win32 patches) In-Reply-To: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> (Marko =?utf-8?q?Koci=C4=87's?= message of "Tue, 6 Mar 2007 10:44:42 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> Message-ID: On Tue, 6 Mar 2007 10:44:42 +0100, "Marko Koci?" wrote: > I wanted to play with hunchentoot on widows using sbcl and made it > work (at least tests are working). In order to do so I had to > optinally disable ssl cause I couldn't find appropriate ssl library > to use. Also, I fixed issue with sbcl win32 port pushing :unix to > *features* and applied a patch from William Bland to work without > threads. Thanks. I've released a new version (haven't testet with SBCL/Win32, though) which incorportates your patches. From edi at agharta.de Fri Mar 9 11:10:32 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 12:10:32 +0100 Subject: [hunchentoot-devel] Re: New release 0.7.0 In-Reply-To: (Edi Weitz's message of "Fri, 09 Mar 2007 12:09:53 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> Message-ID: On Fri, 09 Mar 2007 12:09:53 +0100, Edi Weitz wrote: > Thanks. I've released a new version (haven't testet with > SBCL/Win32, though) which incorportates your patches. s/testet/tested/ of course... From edi at agharta.de Fri Mar 9 11:26:00 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 12:26:00 +0100 Subject: [hunchentoot-devel] Re: New release 0.7.0 In-Reply-To: (Edi Weitz's message of "Fri, 09 Mar 2007 12:10:32 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> Message-ID: On Fri, 09 Mar 2007 12:10:32 +0100, Edi Weitz wrote: > On Fri, 09 Mar 2007 12:09:53 +0100, Edi Weitz wrote: > >> Thanks. I've released a new version (haven't testet with >> SBCL/Win32, though) which incorportates your patches. > > s/testet/tested/ of course... Not to mention "incorportates"... :) Oh well, (at least) two bugs in one sentence. I need a rest... From edi at agharta.de Fri Mar 9 12:11:43 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 13:11:43 +0100 Subject: [hunchentoot-devel] New release 0.7.1 (Was: New release 0.7.0) In-Reply-To: <9238e8de0703090353v45b9863o6b2ea4b9beeabac1@mail.gmail.com> (Marko =?utf-8?q?Koci=C4=87's?= message of "Fri, 9 Mar 2007 12:53:22 +0100") References: <9238e8de0703060144i21d0532eq9efc11e1b74a81ec@mail.gmail.com> <9238e8de0703090353v45b9863o6b2ea4b9beeabac1@mail.gmail.com> Message-ID: On Fri, 9 Mar 2007 12:53:22 +0100, "Marko Koci?" wrote: > There's one more error in server.lisp 172-179 #-:hunchentoot-no-ssl > doesn't handle all parameters. Oh my, bad day today. Thanks for the heads-up, should be fixed now. From edi at agharta.de Fri Mar 9 12:23:49 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 13:23:49 +0100 Subject: [hunchentoot-devel] New release 0.7.2 (Was: Errors with test pages) In-Reply-To: <45F00018.8020705@itsec.co.kr> (Jong-won Choi's message of "Thu, 08 Mar 2007 21:22:48 +0900") References: <45EF9EDE.5080002@itsec.co.kr> <45F00018.8020705@itsec.co.kr> Message-ID: And here's the next release. Sorry for the noise today. On Thu, 08 Mar 2007 21:22:48 +0900, Jong-won Choi wrote: > Here is the backtrace. > > My example input for 'Enter a value:' is ??? Yes, there was a bug in the test suite which only affected LispWorks. I could only reproduce it because I had your example input to copy and paste from... :) The new release should fix that. Thanks for the bug report, Edi. From lispercat at gmail.com Fri Mar 9 14:00:55 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 9 Mar 2007 09:00:55 -0500 Subject: [hunchentoot-devel] Showing progress to the user Message-ID: I'd like to know if there is some functionality in hunchentoot that would allow me to show the progress page to the user. Let's say a user click on a link handle by hunchentoot hander method which takes a lot of time to process. How can I show a page that says "Please, wait" which will redirect to the actual data view of the handler? Here I can think of only " Message-ID: On Fri, 9 Mar 2007 09:00:55 -0500, "Andrei Stebakov" wrote: > I'd like to know if there is some functionality in hunchentoot that > would allow me to show the progress page to the user. Let's say a > user click on a link handle by hunchentoot hander method which takes > a lot of time to process. How can I show a page that says "Please, > wait" which will redirect to the actual data view of the handler? > Here I can think of only " References: Message-ID: On 3/9/07, Andrei Stebakov wrote: > I'd like to know if there is some functionality in hunchentoot that would > allow me to show the progress page to the user. Let's say a user click on a > link handle by hunchentoot hander method which takes a lot of time to > process. How can I show a page that says "Please, wait" which will redirect > to the actual data view of the handler? > Here I can think of only " Edi Weitz wrote: > The new release should fix that. > > Thanks for the bug report, You're welcome. My thanks for the fix. * * * I may need to write some additional encoding support to Hunchentoot, for my client. For example, euc-jp(LW supports this), Big5(LW does not support this), etc. Would you tell me any of guidelines, hints, tips, files to read, etc? I'll submit the final result to you, if it has a quality. Regards Jong-won From edi at agharta.de Fri Mar 9 15:36:56 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 09 Mar 2007 16:36:56 +0100 Subject: [hunchentoot-devel] Additional encoding support In-Reply-To: <45F17891.2010700@itsec.co.kr> (Jong-won Choi's message of "Sat, 10 Mar 2007 00:09:05 +0900") References: <45F17891.2010700@itsec.co.kr> Message-ID: On Sat, 10 Mar 2007 00:09:05 +0900, Jong-won Choi wrote: > I may need to write some additional encoding support to Hunchentoot, > for my client. For example, euc-jp(LW supports this), Big5(LW does > not support this), etc. Additional encoding support should go into FLEXI-STREAMS, not into Hunchentoot. http://weitz.de/flexi-streams/ (Cc sent to FLEXI-STREAMS mailing list where we should continue with this discussion.) As FLEXI-STREAMS doesn't rely on a specific implementation, you can't use LispWorks' built-in EUC-JP support, but you can probably use it as a reference for testing. > Would you tell me any of guidelines, hints, tips, files to read, > etc? You'll have to add your own stream classes and methods for reading and writing a character to that stream. You could probably look at how UTF-8 or UTF-16 are implemented and work from there. You should also add tests for these new formats and update the documentation accordingly. > I'll submit the final result to you, if it has a quality. Yes, I'll gladly accept clean patches to add more external formats to FLEXI-STREAMS. Cheers, Edi. From emailmac at gmail.com Fri Mar 9 17:52:02 2007 From: emailmac at gmail.com (Mac Chan) Date: Fri, 9 Mar 2007 09:52:02 -0800 Subject: [hunchentoot-devel] Showing progress to the user In-Reply-To: References: Message-ID: <4877ae640703090952o4430a90fg94d18848f38c91e1@mail.gmail.com> Unless one of your requirements is to support clients with javascript disabled, your best bet is not to tie up the connection while your server is doing some busy calculations. There are many javascript libraries out there that provide ajax progress bar component. Basically the browser send all the relevant inforamtion to the server via an async ajax call, and the server will return a token or id. If you are using one of those progress bar components, it should handle the polling and UI updates. All you need to do is provide an ajax handler to send the job progress (0-100%, or error status) in XML/JSON, etc. HTH, -- Mac On 3/9/07, Lars Rune N?stdal wrote: > On 3/9/07, Andrei Stebakov wrote: > > I'd like to know if there is some functionality in hunchentoot that would > > allow me to show the progress page to the user. Let's say a user click on a > > link handle by hunchentoot hander method which takes a lot of time to > > process. How can I show a page that says "Please, wait" which will redirect > > to the actual data view of the handler? > > Here I can think of only " might work. > > http://www.w3schools.com/jsref/jsref_onload.asp > > (i'm new to the list btw. .. hope this ends up in the right location/thread) > > -- > Mvh, > Lars Rune N?stdal > http://nostdal.org/ > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From peter.denno at nist.gov Thu Mar 15 23:41:07 2007 From: peter.denno at nist.gov (Peter Denno) Date: Thu, 15 Mar 2007 19:41:07 -0400 Subject: [hunchentoot-devel] log-message and *log-lisp-warnings-p* Message-ID: <200703151941.07700.peter.denno@nist.gov> Hi, Is there a reason why these two calls to log-message in server.lisp are not wrapped in (when *log-lisp-warnings-p*) and (when *log-lisp-errors-p*) like they are in process-request? (defun process-connection (server handle) "This...occurs." (handler-bind ((error ;; abort if there's an error which isn't caught inside (lambda (cond) (log-message *lisp-errors-log-level* "Error while processing connection: ~A" cond) (return-from process-connection))) (warning ;; log all warnings which aren't caught inside (lambda (cond) (log-message *lisp-warnings-log-level* "Warning while processing connection: ~A" cond)))) Hunchentoot is wonderful software, BTW. I use it here: http://syseng.nist.gov/se-interop and here http://syseng.nist.gov/moss -- Best regards, - Peter From wdtate at comcast.net Thu Mar 15 23:50:30 2007 From: wdtate at comcast.net (Bill Tate) Date: Thu, 15 Mar 2007 19:50:30 -0400 Subject: [hunchentoot-devel] Form Processing & responding to events Message-ID: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> Lisp and Hunchentoot newbie here. I haven't been able to find an answer to the following question by searching the existing archives. I have a very substantial application written in PHP and MYSQL and would love to convert it over to Lisp using Hunchentoot and CL-SQL. My question is that I can't find anything to indicate how I can capture something like an onClick or an onLoad event using the keyword notation provided by Hunchentoot. I noticed from the test demo for the easy handler example that hitting the enter key while on a text box will cause the form to be submitted but I can't see where in the code this is explicitly called for. Any clarification or assistance would be most appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu Mar 15 23:51:13 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 16 Mar 2007 00:51:13 +0100 Subject: [hunchentoot-devel] log-message and *log-lisp-warnings-p* In-Reply-To: <200703151941.07700.peter.denno@nist.gov> (Peter Denno's message of "Thu, 15 Mar 2007 19:41:07 -0400") References: <200703151941.07700.peter.denno@nist.gov> Message-ID: On Thu, 15 Mar 2007 19:41:07 -0400, Peter Denno wrote: > Is there a reason why these two calls to log-message in server.lisp > are not wrapped in (when *log-lisp-warnings-p*) and (when > *log-lisp-errors-p*) like they are in process-request? Yes, these variables are supposed to control whether errors or warnings which happen within /handlers/ are logged. Hunchentoot unconditionally logs unexpected events that don't happen in "user code." > Hunchentoot is wonderful software, BTW. I use it here: > http://syseng.nist.gov/se-interop > and here > http://syseng.nist.gov/moss Ah, nice! Cheers, Edi. From urym at two-bytes.com Fri Mar 16 00:19:48 2007 From: urym at two-bytes.com (Ury Marshak) Date: Fri, 16 Mar 2007 02:19:48 +0200 Subject: [hunchentoot-devel] Form Processing & responding to events In-Reply-To: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> Message-ID: <45F9E2A4.2060403@two-bytes.com> Bill Tate wrote: > how I can capture something like an onClick or an > onLoad event using the keyword notation provided by Hunchentoot. onclick and other on-something events happen on the client, in the browser. Hunchentoot lives on the server side and therefore has nothing to with those events. If you really want to receive those events on the server you'll have to generate some Javascript to capture the events and, for example, make the call to the server using AJAX. > I noticed > from the test demo for the easy handler example that hitting the enter key > while on a text box will cause the form to be submitted but I can't see > where in the code this is explicitly called for. > > This behaviour is built into forms. Cheers, Ury Marshak From emailmac at gmail.com Fri Mar 16 00:22:41 2007 From: emailmac at gmail.com (Mac Chan) Date: Thu, 15 Mar 2007 17:22:41 -0700 Subject: [hunchentoot-devel] Form Processing & responding to events In-Reply-To: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> Message-ID: <4877ae640703151722k7553f50csc1e3ef2ccb2e1573@mail.gmail.com> > I noticed > from the test demo for the easy handler example that hitting the enter key > while on a text box will cause the form to be submitted but I can't see > where in the code this is explicitly called for. A lot of html objects (like , etc) have default action associated with them. So even if you bind a onclick handler to the tag to do some interesting stuff, but unless your handler explicitly instructs the browser to prevent the default action from taking place, it will redirect to the href target after your handler is finished executing. The enter key behavior that you described above also triggers a browser default action (submitting the form), so if you don't want that, you need to bind a custom handler and use it to prevent the default behavior. "Javascript the definitive guide" is a very good tutorial and reference if you want to learn more about this. > My question is that I can't > find anything to indicate how I can capture something like an onClick or an > onLoad event using the keyword notation provided by Hunchentoot. I think you're referring to cl-who, not hunchentoot. I'm not sure if this answers your question, but setting a onclick handler for a tag is just a matter of assigning the corresponding attribute. (cl-who:with-html-output (out *standard-output*) (:a :href "target.html" :onclick "javascript:myFunc(); return false;" "Click Me")) => Click Me Of couse, you still need to define the javascript function myFunc(), either by including a js file or embedding it in the cl-who form (cl-interprol is of great help here) or even use the parentscript library so you can write it in lisp too! HTH, -- Mac From wdtate at comcast.net Fri Mar 16 00:40:10 2007 From: wdtate at comcast.net (Bill Tate) Date: Thu, 15 Mar 2007 20:40:10 -0400 Subject: [hunchentoot-devel] Form Processing & responding to events In-Reply-To: <4877ae640703151722k7553f50csc1e3ef2ccb2e1573@mail.gmail.com> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> <4877ae640703151722k7553f50csc1e3ef2ccb2e1573@mail.gmail.com> Message-ID: <003601c76763$ad73a910$6401a8c0@Magnolia> >>>(cl-who:with-html-output (out *standard-output*) >>> (:a :href "target.html" :onclick "javascript:myFunc(); return false;" >>> "Click Me")) Basically this is what I was looking for. I assumed it was some kind of keyword association for events associated with specific html forms but I wasn't terribly sure what the syntax would be or its format. After looking at your response, I should have known - always seem to get that feeling after using LISP :>) Thanks very much for the help. From wdtate at comcast.net Fri Mar 16 20:47:31 2007 From: wdtate at comcast.net (Bill Tate) Date: Fri, 16 Mar 2007 16:47:31 -0400 Subject: [hunchentoot-devel] Form Processing - hopefully a quick one In-Reply-To: <45F9E2A4.2060403@two-bytes.com> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> <45F9E2A4.2060403@two-bytes.com> Message-ID: <00a301c7680c$517ea8e0$6401a8c0@Magnolia> I apologize if this is a stupid question, but this is driving me nuts. I'm doing a simple test to get acquainted with Hunchentoot and CL-WHO. I need to do the typical navigate to form page ->fill out the form and submit form -> go to a different response page. Handlers for both form and response pages have been defined. I've tried to set an :action attribute on the form to go to the desired response page as you would in normal HTML. However, I keep getting the original form page when hitting submit button. I'm obviously missing something here. Here's a snippet of the form page (define-easy-handler (my-demo-form :uri "/hunchentoot/test/my-demo-form.html" :default-request-type :post) (person city state) (with-html (:html (:head (:title "Simple Form Response Example")) (:body (:h2 "Test Form ") (:p (:form :method :post :action "/Hunchentoot/test/my-demo-response.html" (:table :border 1 :cellpadding 2 :cellspacing 0 (:tr ..... Any help would be appreciated. From rsynnott at gmail.com Fri Mar 16 21:10:46 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Fri, 16 Mar 2007 21:10:46 +0000 Subject: [hunchentoot-devel] Form Processing - hopefully a quick one In-Reply-To: <00a301c7680c$517ea8e0$6401a8c0@Magnolia> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia> <45F9E2A4.2060403@two-bytes.com> <00a301c7680c$517ea8e0$6401a8c0@Magnolia> Message-ID: <24f203480703161410s5aff4cfdla0b0052c09db4960@mail.gmail.com> On 3/16/07, Bill Tate wrote: > I apologize if this is a stupid question, but this is driving me nuts. > I'm doing a simple test to get acquainted with Hunchentoot and CL-WHO. I > need to do the typical navigate to form page ->fill out the form and submit > form -> go to a different response page. Handlers for both form and > response pages have been defined. > > I've tried to set an :action attribute on the form to go to the desired > response page as you would in normal HTML. However, I keep getting the > original form page when hitting submit button. I'm obviously missing > something here. Here's a snippet of the form page > > (define-easy-handler (my-demo-form :uri > "/hunchentoot/test/my-demo-form.html" > :default-request-type :post) > (person city state) > (with-html > (:html > (:head (:title "Simple Form Response Example")) > (:body > (:h2 "Test Form ") > (:p (:form :method :post :action > "/Hunchentoot/test/my-demo-response.html" > (:table :border 1 :cellpadding 2 :cellspacing 0 > (:tr ..... > > > Any help would be appreciated. > > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > What does your dispatch table look like? (in particular, does it have an entry for /hunchentoot/test/my-demo-response.html - I'm assuming that's the target page?) Rob From wdtate at comcast.net Fri Mar 16 21:24:52 2007 From: wdtate at comcast.net (Bill Tate) Date: Fri, 16 Mar 2007 17:24:52 -0400 Subject: [hunchentoot-devel] Form Processing - hopefully a quick one In-Reply-To: <24f203480703161410s5aff4cfdla0b0052c09db4960@mail.gmail.com> References: <002b01c7675c$bd5f73b0$6401a8c0@Magnolia><45F9E2A4.2060403@two-bytes.com><00a301c7680c$517ea8e0$6401a8c0@Magnolia> <24f203480703161410s5aff4cfdla0b0052c09db4960@mail.gmail.com> Message-ID: <00a401c76811$89995a90$6401a8c0@Magnolia> Uggh - forgot to add it. Thanks - I'll test it out. Thanks much -----Original Message----- >>What does your dispatch table look like? (in particular, does it have >>an entry for /hunchentoot/test/my-demo-response.html - I'm assuming >>that's the target page?) >>Rob _______________________________________________ tbnl-devel site list tbnl-devel at common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel From victor.kryukov at gmail.com Sat Mar 17 05:42:03 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Sat, 17 Mar 2007 00:42:03 -0500 Subject: [hunchentoot-devel] Using utf-8 strings with with-html macro. Message-ID: Hello list, I'm trying to output some cyrillic letters on the web page like this: (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) (defun main-page () (setf (content-type) "text/html; charset=utf-8") (with-html (:html (:head (:title "Test page")) (:body (:h2 "Main page") (:p "??????? ????") ; Cyrillic letters - "Russian test" )))) but the resulted page is empty. The lisp file itself in utf-8 coding system. Am I missing something? My system is Ubuntu 2.6.17, sbcl 1.0.3.38, hunchentoot 0.7.2 Thanks a lot, Victor Kryukov http://antlook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsynnott at gmail.com Sat Mar 17 18:06:38 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Sat, 17 Mar 2007 18:06:38 +0000 Subject: [hunchentoot-devel] Using utf-8 strings with with-html macro. In-Reply-To: References: Message-ID: <24f203480703171106v761ece3bwe421efcf8eebfe64@mail.gmail.com> On 3/17/07, Victor Kryukov wrote: > > Hello list, > > I'm trying to output some cyrillic letters on the web page like this: > > (setf *hunchentoot-default-external-format* > (flex:make-external-format :utf-8 :eol-style :lf)) > > (defun main-page () > (setf (content-type) "text/html; charset=utf-8") > (with-html > (:html > (:head (:title "Test page")) > (:body > (:h2 "Main page") > (:p "??????? ????") ; Cyrillic letters - "Russian test" > )))) > > but the resulted page is empty. The lisp file itself in utf-8 coding system. > Am I missing something? > > My system is Ubuntu 2.6.17, sbcl 1.0.3.38, hunchentoot 0.7.2 > > Thanks a lot, > > Victor Kryukov > http://antlook.com > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net I think, though I'm not sure, that you should be using the with-html-output-to-string macro; it may be that at the moment it's just printing it to standard output (whereas it should be returning the page as a string). You could try something like (defun my-page () "Put some unicode characters here") to see if it's an issue with your hunchentoot, though. Rob From tobia.conforto at linux.it Sat Mar 17 18:13:59 2007 From: tobia.conforto at linux.it (Tobia) Date: Sat, 17 Mar 2007 19:13:59 +0100 Subject: [hunchentoot-devel] Using utf-8 strings with with-html macro. In-Reply-To: References: Message-ID: <20070317181359.GT26517@localhost.localdomain> Victor Kryukov wrote: > I'm trying to output some cyrillic letters Your example, slightly modified, works fine on my system* I say slightly modified as I don't know where to find the with-html macro you used. Here's what I did: (asdf:operate 'asdf:load-op :hunchentoot) (asdf:operate 'asdf:load-op :cl-who) (defpackage :test (:use :cl :cl-who :hunchentoot)) (in-package :test) (setf *default-content-type* "text/html; charset=utf-8") (setf *hunchentoot-default-external-format* (flex:make-external-format :utf-8 :eol-style :lf)) (setf *dispatch-table* (list #'dispatch-easy-handlers)) (define-easy-handler (home :uri "/") () (with-html-output (*standard-output* nil) (:html (:head (:title "Test page")) (:body (:h2 "Main page") (:p "??????? ????"))))) HTH, Tobia * Debian Sid, SBCL 1.0, Hunchentoot 0.7.2, CL-WHO 0.6.2, Opera 9.10 From victor.kryukov at gmail.com Sat Mar 17 18:24:49 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Sat, 17 Mar 2007 13:24:49 -0500 Subject: [hunchentoot-devel] Using utf-8 strings with with-html macro. In-Reply-To: <20070317181359.GT26517@localhost.localdomain> References: <20070317181359.GT26517@localhost.localdomain> Message-ID: On Mar 17, 2007, at 1:13 PM, Tobia wrote: > Victor Kryukov wrote: >> I'm trying to output some cyrillic letters > > Your example, slightly modified, works fine on my system* > > I say slightly modified as I don't know where to find the with-html > macro you used. Here's what I did: > > (asdf:operate 'asdf:load-op :hunchentoot) > (asdf:operate 'asdf:load-op :cl-who) > > (defpackage :test (:use :cl :cl-who :hunchentoot)) > (in-package :test) > > (setf *default-content-type* "text/html; charset=utf-8") > Ah! Here it is! I forgot to set *default-content-type*! Thanks a lot Tobia!! Victor Kryukov http://antlook.com From vamlists at gmail.com Mon Mar 19 20:14:54 2007 From: vamlists at gmail.com (Vamsee Kanakala) Date: Tue, 20 Mar 2007 01:44:54 +0530 Subject: [hunchentoot-devel] How to create custom url routes? In-Reply-To: References: <45FE3D1F.8090407@gmail.com> Message-ID: <45FEEF3E.1070906@gmail.com> Edi Weitz wrote: > > That looks like you'll have to write your own dispatcher for this. > The advantage is that you can go berserk and re-implement something > like mod_rewrite in Lisp... :) > Sounds like fun :). But I guess I have to wait a few more weeks before I get the time to dig into it :). Thanks, Vamsee. From rsynnott at gmail.com Wed Mar 21 19:24:34 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Wed, 21 Mar 2007 19:24:34 +0000 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow Message-ID: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> Hi, I've messed around with Hunchentoot before a good bit, but this week launched my first real site with a moderate number of visitors (http://twitterbuzz.com - hunchentoot/mod_proxy). Now, the site seemed slightly sluggish, but at first I was inclined to blame this on the page generation. Looking closer, though, the page generation happens practically instantly, and the slowness seems to turn up in sending the data back to the user. Playing with apache-bench, I found that transfer speed seems to cap out at about 250KB/s, even when just sending a huge static page (a largish ebook off Gutenburg). For the moment, I've shifted the site to using tbnl (with mod_lisp), and things seem to run faster; ab can now download the ebook at about 30MB/s, and page loading on the site itself seems snappier. However, I'm aware that tbnl is deprecated. Is this something silly I'm doing, or an inherent limitation of hunchentoot/flexi-streams? Also, are there any major issues with tbnl I should be aware of? I'm particularly concerned about this because I'm currently moving a far larger site with lots of users to lisp, and I suspect that the speed problem would be a real issue with it. Rob From edi at agharta.de Wed Mar 21 19:52:09 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 21 Mar 2007 20:52:09 +0100 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> (Robert Synnott's message of "Wed, 21 Mar 2007 19:24:34 +0000") References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> Message-ID: Hi, On Wed, 21 Mar 2007 19:24:34 +0000, "Robert Synnott" wrote: > I've messed around with Hunchentoot before a good bit, but this week > launched my first real site with a moderate number of visitors > (http://twitterbuzz.com - hunchentoot/mod_proxy). Now, the site > seemed slightly sluggish, but at first I was inclined to blame this > on the page generation. Looking closer, though, the page generation > happens practically instantly, and the slowness seems to turn up in > sending the data back to the user. Playing with apache-bench, I > found that transfer speed seems to cap out at about 250KB/s, even > when just sending a huge static page (a largish ebook off > Gutenburg). > > For the moment, I've shifted the site to using tbnl (with mod_lisp), > and things seem to run faster; ab can now download the ebook at > about 30MB/s, and page loading on the site itself seems > snappier. However, I'm aware that tbnl is deprecated. > > Is this something silly I'm doing, or an inherent limitation of > hunchentoot/flexi-streams? Also, are there any major issues with > tbnl I should be aware of? > > I'm particularly concerned about this because I'm currently moving a > far larger site with lots of users to lisp, and I suspect that the > speed problem would be a real issue with it. It would surely help if you could give us some info, like what Lisp you are using, which operating system you're on, the usual stuff... Also, maybe you can isolate a bit of stand-alone code (maybe the single page you're talking about) so I can easily reproduce your problems. Having said that, you are aware of the sentence "Make sure to use the /newest/ versions of all of these libraries" in the installation instructions, aren't you? One of the culprits for slow responses in the past has been FLEXI-STREAMS, but that should be mostly fixed in newer releases. (Or maybe not, but it's hard to say without any data provided.) Cheers, Edi. From rsynnott at gmail.com Wed Mar 21 20:57:12 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Wed, 21 Mar 2007 20:57:12 +0000 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> Message-ID: <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> On 3/21/07, Edi Weitz wrote: > Hi, > > It would surely help if you could give us some info, like what Lisp > you are using, which operating system you're on, the usual stuff... > Also, maybe you can isolate a bit of stand-alone code (maybe the > single page you're talking about) so I can easily reproduce your > problems. > > Having said that, you are aware of the sentence > > "Make sure to use the /newest/ versions of all of these libraries" > > in the installation instructions, aren't you? One of the culprits for > slow responses in the past has been FLEXI-STREAMS, but that should be > mostly fixed in newer releases. (Or maybe not, but it's hard to say > without any data provided.) > > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list Sorry about that, yes. SBCL 1, Linux. All dependencies are newest available, as is Hunchentoot. The function which just sent back a big file was simply: (defun speedtest () *big-string*) where *big-string* contained the contents of a 700kb text file. Rob From edi at agharta.de Wed Mar 21 22:25:29 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 21 Mar 2007 23:25:29 +0100 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> (Robert Synnott's message of "Wed, 21 Mar 2007 20:57:12 +0000") References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> Message-ID: On Wed, 21 Mar 2007 20:57:12 +0000, "Robert Synnott" wrote: > The function which just sent back a big file was simply: > > (defun speedtest () *big-string*) > > where *big-string* contained the contents of a 700kb text file. OK, I see. The culprit /is/ FLEXI-STREAMS, but there's not much to do about it in the general case. Its WRITE-SEQUENCE function gets a string and loops through it element by element calling WRITE-CHAR for each one in turn. This is necessary because a) the sequences you can output with FLEXI-STREAMS can be almost anything, even lists or vectors containing a mixture of octets and characters and b) you can't know in advance whether you'll have encoding errors further down the string. I have a crude optimization for some special cases which I'll release one of these days, but it is just that - a crude optimization for special cases. To solve your problem there are at least two ways, though: 1. To output a static file you shouldn't keep the file in memory anyway - use CREATE-STATIC-FILE-DISPATCHER-AND-HANDLER instead (or see HANDLE-STATIC-FILE). 2. If you insist on using a variable like above and you know its contents in advance, convert it to an array of element type FLEX:OCTET, i.e. (UNSIGNED-BYTE 8), and let the handler return this array. (This is the only "optimization" that'll always work with FLEXI-STREAMS.) In both cases, the transfer rate should be in the ballpark of Apache handling static files. Let us know if it's not. HTH, Edi. From rsynnott at gmail.com Thu Mar 22 12:39:40 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 22 Mar 2007 12:39:40 +0000 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> Message-ID: <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> On 3/21/07, Edi Weitz wrote: > On Wed, 21 Mar 2007 20:57:12 +0000, "Robert Synnott" wrote: > > > The function which just sent back a big file was simply: > > > > (defun speedtest () *big-string*) > > > > where *big-string* contained the contents of a 700kb text file. > > OK, I see. The culprit /is/ FLEXI-STREAMS, but there's not much to do > about it in the general case. Its WRITE-SEQUENCE function gets a > string and loops through it element by element calling WRITE-CHAR for > each one in turn. This is necessary because a) the sequences you can > output with FLEXI-STREAMS can be almost anything, even lists or > vectors containing a mixture of octets and characters and b) you can't > know in advance whether you'll have encoding errors further down the > string. > > I have a crude optimization for some special cases which I'll release > one of these days, but it is just that - a crude optimization for > special cases. > > To solve your problem there are at least two ways, though: > > 1. To output a static file you shouldn't keep the file in memory > anyway - use CREATE-STATIC-FILE-DISPATCHER-AND-HANDLER instead (or > see HANDLE-STATIC-FILE). > > 2. If you insist on using a variable like above and you know its > contents in advance, convert it to an array of element type > FLEX:OCTET, i.e. (UNSIGNED-BYTE 8), and let the handler return this > array. (This is the only "optimization" that'll always work with > FLEXI-STREAMS.) > > In both cases, the transfer rate should be in the ballpark of Apache > handling static files. Let us know if it's not. > > HTH, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > I was really just using the big static file to demonstrate the problem; it's visible when sending dynamically generated pages as well, but just not by so huge a margin (because the pages aren't as big, I think; the bigger the page, the more the speed difference between tbnl and hunchentoot seems to be). Rob From gwking at metabang.com Thu Mar 22 12:58:28 2007 From: gwking at metabang.com (Gary King) Date: Thu, 22 Mar 2007 08:58:28 -0400 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> Message-ID: <6AD99EB4-7898-4FE1-A565-86516D313192@metabang.com> > I was really just using the big static file to demonstrate the > problem; it's visible when sending dynamically generated pages as > well, but just not by so huge a margin (because the pages aren't as > big, I think; the bigger the page, the more the speed difference > between tbnl and hunchentoot seems to be). > Rob Do you mean that there is a non-linear dependency? How hard / useful would it be to measure the difference between tbnl and hunchentoot for pages of size 1 - N MBs? -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From rsynnott at gmail.com Thu Mar 22 13:32:30 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Thu, 22 Mar 2007 13:32:30 +0000 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <6AD99EB4-7898-4FE1-A565-86516D313192@metabang.com> References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> <6AD99EB4-7898-4FE1-A565-86516D313192@metabang.com> Message-ID: <24f203480703220632u6c7d37f6wc7ea0e6602f28467@mail.gmail.com> On 3/22/07, Gary King wrote: > > Do you mean that there is a non-linear dependency? How hard / useful > would it be to measure the difference between tbnl and hunchentoot > for pages of size 1 - N MBs? > > -- No, as far as I can see there's more or less a linear dependency. The bigger a page is the longer it seems to take to send, with transfer rates peaking (on my machine, which isn't very fast) at about 250KB/s. With tbnl, though, this restriction doesn't seem to exist, and transfer rates can hit multiple megabytes per second. It would be quite easy to measure, but I'm not sure how useful it would be. Rob From edi at agharta.de Thu Mar 22 13:37:13 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 22 Mar 2007 14:37:13 +0100 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703220632u6c7d37f6wc7ea0e6602f28467@mail.gmail.com> (Robert Synnott's message of "Thu, 22 Mar 2007 13:32:30 +0000") References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> <6AD99EB4-7898-4FE1-A565-86516D313192@metabang.com> <24f203480703220632u6c7d37f6wc7ea0e6602f28467@mail.gmail.com> Message-ID: On Thu, 22 Mar 2007 13:32:30 +0000, "Robert Synnott" wrote: > With tbnl, though, this restriction doesn't seem to exist See the explanation I sent yesterday. From gwking at metabang.com Thu Mar 22 13:42:14 2007 From: gwking at metabang.com (Gary King) Date: Thu, 22 Mar 2007 09:42:14 -0400 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703220632u6c7d37f6wc7ea0e6602f28467@mail.gmail.com> References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> <6AD99EB4-7898-4FE1-A565-86516D313192@metabang.com> <24f203480703220632u6c7d37f6wc7ea0e6602f28467@mail.gmail.com> Message-ID: <295F8014-C06A-473E-9BFE-3A1C2EBCCE64@metabang.com> > It would be quite easy to measure, but I'm not sure how useful it > would be. I agree; I wasn't clear to me from your description whether it was linear or non-linear... thanks. -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From edi at agharta.de Thu Mar 22 22:19:10 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 22 Mar 2007 23:19:10 +0100 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> (Robert Synnott's message of "Thu, 22 Mar 2007 12:39:40 +0000") References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> Message-ID: On Thu, 22 Mar 2007 12:39:40 +0000, "Robert Synnott" wrote: > I was really just using the big static file to demonstrate the > problem; it's visible when sending dynamically generated pages as > well, but just not by so huge a margin (because the pages aren't as > big, I think; the bigger the page, the more the speed difference > between tbnl and hunchentoot seems to be). I've just uploaded a new release of FLEXI-STREAMS (0.11.1) which incorporates the patches I was talking about. This should make Hunchentoot output significantly faster /if/ you're using an 8-bit encoding without line encoding conversions (like the default format), but it'll still be an order of magnitude slower than writing binary data directly to the stream. Let us know if this helps. I'm happy to accept reasonable patches to make FLEXI-STREAMS faster, but obviously there's a certain price you have to pay for flexibility and portability. Note that you can of course bypass FLEXI-STREAMS if you absolutely need the speed. Something like this (untested): (defun my-handler () ;; no need to generate the content before calling SEND-HEADERS, ;; but that way your errors will be handled by Hunchentoot (let ((content (generate-content)) (stream (flexi-stream-stream (send-headers)))) (write-sequence (maybe-convert content) stream))) Try it... STREAM will either be the raw socket stream or a chunked stream from Chunga depending on how you've started your server. (You can put Hunchentoot behind mod_lisp and use :INPUT-CHUNKING-P NIL and :MOD-LISP-P T to bypass Chunga as well.) From rsynnott at gmail.com Fri Mar 23 00:23:55 2007 From: rsynnott at gmail.com (Robert Synnott) Date: Fri, 23 Mar 2007 00:23:55 +0000 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> Message-ID: <24f203480703221723n7cbc1f42o2cad0d0bd446978@mail.gmail.com> On 3/22/07, Edi Weitz wrote: > On Thu, 22 Mar 2007 12:39:40 +0000, "Robert Synnott" wrote: > > > I was really just using the big static file to demonstrate the > > problem; it's visible when sending dynamically generated pages as > > well, but just not by so huge a margin (because the pages aren't as > > big, I think; the bigger the page, the more the speed difference > > between tbnl and hunchentoot seems to be). > > I've just uploaded a new release of FLEXI-STREAMS (0.11.1) which > incorporates the patches I was talking about. This should make > Hunchentoot output significantly faster /if/ you're using an 8-bit > encoding without line encoding conversions (like the default format), > but it'll still be an order of magnitude slower than writing binary > data directly to the stream. > > Let us know if this helps. > > I'm happy to accept reasonable patches to make FLEXI-STREAMS faster, > but obviously there's a certain price you have to pay for flexibility > and portability. > > Note that you can of course bypass FLEXI-STREAMS if you absolutely > need the speed. Something like this (untested): > > (defun my-handler () > ;; no need to generate the content before calling SEND-HEADERS, > ;; but that way your errors will be handled by Hunchentoot > (let ((content (generate-content)) > (stream (flexi-stream-stream (send-headers)))) > (write-sequence (maybe-convert content) stream))) > > Try it... > > STREAM will either be the raw socket stream or a chunked stream from > Chunga depending on how you've started your server. (You can put > Hunchentoot behind mod_lisp and use :INPUT-CHUNKING-P NIL and > :MOD-LISP-P T to bypass Chunga as well.) > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Hi, This works perfectly; it's nearly as fast as tbnl, and certainly fast enough that it's not a worry; when putting together my new site, I know it's there to fall back on if speed does become an issue. Thanks Rob From edi at agharta.de Fri Mar 23 01:03:35 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 23 Mar 2007 02:03:35 +0100 Subject: [hunchentoot-devel] Hunchentoot data-transfers seem slow In-Reply-To: <24f203480703221723n7cbc1f42o2cad0d0bd446978@mail.gmail.com> (Robert Synnott's message of "Fri, 23 Mar 2007 00:23:55 +0000") References: <24f203480703211224w18601ebbta47577b61c34bea3@mail.gmail.com> <24f203480703211357s2393300jbd457b76855de0d3@mail.gmail.com> <24f203480703220539t286cd75ah5fc49df3aa6d3636@mail.gmail.com> <24f203480703221723n7cbc1f42o2cad0d0bd446978@mail.gmail.com> Message-ID: On Fri, 23 Mar 2007 00:23:55 +0000, "Robert Synnott" wrote: > This works perfectly; it's nearly as fast as tbnl, and certainly > fast enough that it's not a worry; Which one? Using the new FLEXI-STREAMS release or bypassing it? From victor.kryukov at gmail.com Sat Mar 24 00:40:33 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Fri, 23 Mar 2007 19:40:33 -0500 Subject: [hunchentoot-devel] Strange error message. In-Reply-To: <20070317181359.GT26517@localhost.localdomain> References: <20070317181359.GT26517@localhost.localdomain> Message-ID: <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> Hello list, I've got the following strange error message while running Hunchentoot on my linux box: * WARNING: Strange result... message type 0x54 arrived from server while idle message type 0x43 arrived from server while idle message type 0x5a arrived from server while idle debugger invoked on a UNBOUND-VARIABLE in thread #: The variable *REPLY* is unbound. Anybody has any idea where should I look for the problem? I'm using SBCL 1.0.3.38 and Hunchentoot 0.7.2 on linux. Best Regards, Victor Kryukov http://antlook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.kryukov at gmail.com Sat Mar 24 00:42:29 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Fri, 23 Mar 2007 19:42:29 -0500 Subject: [hunchentoot-devel] Re: Strange error message. In-Reply-To: <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> References: <20070317181359.GT26517@localhost.localdomain> <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> Message-ID: <4432A74B-6B1B-4CD2-9925-B9A0A28D203E@gmail.com> Forgot to mention: I'm running Hunchentoot under mod_lisp2 and Apache2.0. I also pre-compiled core with Hunchentoot, CL-WHO, CL- PPCRE and CLSQL to shorten the startup time - not sure if it's related or not. Best, Victor Kryukov http://antlook.com On Mar 23, 2007, at 7:40 PM, Victor Kryukov wrote: > Hello list, > > I've got the following strange error message while running > Hunchentoot on my linux box: > > * WARNING: Strange result... > message type 0x54 arrived from server while idle > message type 0x43 arrived from server while idle > message type 0x5a arrived from server while idle > > debugger invoked on a UNBOUND-VARIABLE in thread # "hunchentoot-worker-14" {C0FCAF1}>: > The variable *REPLY* is unbound. > > Anybody has any idea where should I look for the problem? I'm using > SBCL 1.0.3.38 and Hunchentoot 0.7.2 on linux. > > Best Regards, > > Victor Kryukov > http://antlook.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Sat Mar 24 00:56:25 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 24 Mar 2007 01:56:25 +0100 Subject: [hunchentoot-devel] Strange error message. In-Reply-To: <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> (Victor Kryukov's message of "Fri, 23 Mar 2007 19:40:33 -0500") References: <20070317181359.GT26517@localhost.localdomain> <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> Message-ID: On Fri, 23 Mar 2007 19:40:33 -0500, Victor Kryukov wrote: > I've got the following strange error message while running > Hunchentoot on my linux box: > > * WARNING: Strange result... > message type 0x54 arrived from server while idle > message type 0x43 arrived from server while idle > message type 0x5a arrived from server while idle > > debugger invoked on a UNBOUND-VARIABLE in thread # "hunchentoot-worker-14" {C0FCAF1}>: > The variable *REPLY* is unbound. > > Anybody has any idea where should I look for the problem? I'm using > SBCL 1.0.3.38 and Hunchentoot 0.7.2 on linux. The "message type ..." warning comes from PostgreSQL. My /guess/ is that you're somehow screwing up by using the same resources to talk to the database from different threads. Or maybe having CLSQL's FFI code in your saved image is the culprit... From victor.kryukov at gmail.com Sat Mar 24 01:02:42 2007 From: victor.kryukov at gmail.com (Victor Kryukov) Date: Fri, 23 Mar 2007 20:02:42 -0500 Subject: [hunchentoot-devel] Strange error message. In-Reply-To: References: <20070317181359.GT26517@localhost.localdomain> <16719727-8AB5-42E3-BEA0-3A23DC2E48EF@gmail.com> Message-ID: <053BA21F-4794-4B20-B0F1-43CE3C698D10@gmail.com> Hello Edi, thanks a lot - both of your suggestions seem probable, I just haven't thought about CLSQL/Postgresql here. Best regards, Victor Kryukov http://antlook.com On Mar 23, 2007, at 7:56 PM, Edi Weitz wrote: > On Fri, 23 Mar 2007 19:40:33 -0500, Victor Kryukov > wrote: > >> I've got the following strange error message while running >> Hunchentoot on my linux box: >> >> * WARNING: Strange result... >> message type 0x54 arrived from server while idle >> message type 0x43 arrived from server while idle >> message type 0x5a arrived from server while idle >> >> debugger invoked on a UNBOUND-VARIABLE in thread #> "hunchentoot-worker-14" {C0FCAF1}>: >> The variable *REPLY* is unbound. >> >> Anybody has any idea where should I look for the problem? I'm using >> SBCL 1.0.3.38 and Hunchentoot 0.7.2 on linux. > > The "message type ..." warning comes from PostgreSQL. My /guess/ is > that you're somehow screwing up by using the same resources to talk to > the database from different threads. Or maybe having CLSQL's FFI code > in your saved image is the culprit... > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Mon Mar 26 14:47:06 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Mon, 26 Mar 2007 10:47:06 -0400 Subject: [hunchentoot-devel] Displaying partial output from the handler? Message-ID: I was wondering if it's possible to create a handler which can output some message to the user browser and then continue with it's own lengthy operation so that a user could see some output? Thank you, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobia.conforto at linux.it Mon Mar 26 19:51:26 2007 From: tobia.conforto at linux.it (Tobia) Date: Mon, 26 Mar 2007 21:51:26 +0200 Subject: [hunchentoot-devel] Displaying partial output from the handler? In-Reply-To: References: Message-ID: <20070326195125.GA24992@localhost.localdomain> Andrei Stebakov wrote: > I was wondering if it's possible to create a handler which can output > some message to the user browser and then continue with it's own > lengthy operation so that a user could see some output? Yes it's possible, but you cannot use the "return value as document" paradigm anymore, you need to write to the stream directly. Which means you might have some trouble with HTML abstraction tools such as CL-WHO. This works for me: (define-easy-handler (test :uri "/") () (let ((*standard-output* (send-headers))) (format t "Progressive output") (dolist (s '("Respect" "to" "the" "man" "in" "the" "icecream" "van!")) (format t "~A
" s) (force-output) (sleep 1)) (format t "

Over and out

"))) Although, if the operation is very lengthy (say, more than a minute) you should consider an anyncronous approach: a separate working thread plus client-side page refreshes (or AJAX or an iframe) for status polling. Tobia From nowhere.man at levallois.eu.org Tue Mar 27 03:08:58 2007 From: nowhere.man at levallois.eu.org (Pierre THIERRY) Date: Tue, 27 Mar 2007 05:08:58 +0200 Subject: [hunchentoot-devel] Displaying partial output from the handler? In-Reply-To: <20070326195125.GA24992@localhost.localdomain> References: <20070326195125.GA24992@localhost.localdomain> Message-ID: <20070327030858.GJ19256@bateleur.arcanes.fr.eu.org> Scribit Tobia dies 26/03/2007 hora 21:51: > Although, if the operation is very lengthy (say, more than a minute) > you should consider an anyncronous approach: a separate working thread > plus client-side page refreshes (or AJAX or an iframe) for status > polling. AJAX is maybe a bit overkill here. Many sites just show an intermediate page with an immediate refresh to goes to the URL of the lengthy computation. As all browsers won't redraw anything before they get data, you can then use the "data as return value" paradigm for both handlers, the intermediate page and the lengthy computation. Alternatively, Pierre -- nowhere.man at levallois.eu.org OpenPGP 0xD9D50D8A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From lispercat at gmail.com Tue Mar 27 14:36:54 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Tue, 27 Mar 2007 10:36:54 -0400 Subject: [hunchentoot-devel] Displaying partial output from the handler? In-Reply-To: <20070327030858.GJ19256@bateleur.arcanes.fr.eu.org> References: <20070326195125.GA24992@localhost.localdomain> <20070327030858.GJ19256@bateleur.arcanes.fr.eu.org> Message-ID: Pierre, I am not sure I understood you. Could you give some example of what you described? Thank you, Andrew On 3/26/07, Pierre THIERRY wrote: > > Scribit Tobia dies 26/03/2007 hora 21:51: > > Although, if the operation is very lengthy (say, more than a minute) > > you should consider an anyncronous approach: a separate working thread > > plus client-side page refreshes (or AJAX or an iframe) for status > > polling. > > AJAX is maybe a bit overkill here. Many sites just show an intermediate > page with an immediate refresh to goes to the URL of the lengthy > computation. > > As all browsers won't redraw anything before they get data, you can then > use the "data as return value" paradigm for both handlers, the > intermediate page and the lengthy computation. > > Alternatively, > Pierre > -- > nowhere.man at levallois.eu.org > OpenPGP 0xD9D50D8A > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGCIrKxe13INnVDYoRAtmwAJ4uBw2+ZpHfaOl/3YiXQogPYBX0qwCg5Qjn > sEoOgEFuXGpz1pI5gkYjcN8= > =GK2r > -----END PGP SIGNATURE----- > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Wed Mar 28 20:17:56 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 28 Mar 2007 22:17:56 +0200 Subject: [hunchentoot-devel] New release 0.7.3 Message-ID: ChangeLog: Version 0.7.3 2007-03-28 Added +HTTP-MULTI-STATUS+ Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi. From dathomp1 at yahoo.com Thu Mar 29 00:07:42 2007 From: dathomp1 at yahoo.com (dat) Date: Wed, 28 Mar 2007 17:07:42 -0700 (PDT) Subject: [hunchentoot-devel] GET-REQUEST-DATA unhappiness with firefox's xforms plugin Message-ID: <720292.48149.qm@web34007.mail.mud.yahoo.com> I've been using hunchentoot with the firefox xforms plugin and recently switched to mod_lisp2 with apache's httpd. xhtml pages seem to work fine. However, when submitting results from an xforms document to hunchentoot under mod_lisp2, the client request is never answered -- when the client request is interrupted, sbcl complains... end of file on # [Condition of type END-OF-FILE] The backtrace suggested that GET-REQUEST-DATA is unhappy with the request... 8: (ERROR END-OF-FILE) 9: (READ-LINE # T NIL #) 10: (HUNCHENTOOT::GET-REQUEST-DATA) 11: (HUNCHENTOOT::PROCESS-CONNECTION # #) If I take mod_lisp out of the picture and just make the request from hunchentoot directly there doesn't seem to be a problem. If I change the code for key/value reading in GET-REQUEST-DATA (headers.lisp) to for value = (read-line *hunchentoot-stream* nil nil) ;;for value = (read-line *hunchentoot-stream* t) things work like a charm (at least, superficially...). Unfortunately, at this point, I'm a little out of my depth... Does hunchentoot throwing an error indicate that the xforms plugin is buggy (maybe leaving an extra blank line somewhere in the http where it shouldn't)? Thanks for any thoughts/suggestions... Alan Thompson ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ From edi at agharta.de Thu Mar 29 06:45:22 2007 From: edi at agharta.de (Edi Weitz) Date: Thu, 29 Mar 2007 08:45:22 +0200 Subject: [hunchentoot-devel] GET-REQUEST-DATA unhappiness with firefox's xforms plugin In-Reply-To: <720292.48149.qm@web34007.mail.mud.yahoo.com> (dat's message of "Wed, 28 Mar 2007 17:07:42 -0700 (PDT)") References: <720292.48149.qm@web34007.mail.mud.yahoo.com> Message-ID: On Wed, 28 Mar 2007 17:07:42 -0700 (PDT), dat wrote: > I've been using hunchentoot with the firefox xforms plugin and > recently switched to mod_lisp2 with apache's httpd. xhtml pages seem > to work fine. However, when submitting results from an xforms > document to hunchentoot under mod_lisp2, the client request is never > answered -- when the client request is interrupted, sbcl > complains... > > end of file on # > [Condition of type END-OF-FILE] > > The backtrace suggested that GET-REQUEST-DATA is unhappy with the request... > > 8: (ERROR END-OF-FILE) > 9: (READ-LINE > # > T > NIL > #) > 10: (HUNCHENTOOT::GET-REQUEST-DATA) > 11: (HUNCHENTOOT::PROCESS-CONNECTION > # > #) > > If I take mod_lisp out of the picture and just make the request from > hunchentoot directly there doesn't seem to be a problem. If I change > the code for key/value reading in GET-REQUEST-DATA (headers.lisp) to > > for value = (read-line *hunchentoot-stream* nil nil) > ;;for value = (read-line *hunchentoot-stream* t) > > things work like a charm (at least, > superficially...). Unfortunately, at this point, I'm a little out of > my depth... Does hunchentoot throwing an error indicate that the > xforms plugin is buggy (maybe leaving an extra blank line somewhere > in the http where it shouldn't)? > > Thanks for any thoughts/suggestions... Hmm, I don't have the XForms plug-in to test this, but my initial guess would be that the plug-in sends content to the server using chunked transfer encoding and your combination of Apache and mod_lisp can't cope with that. Try to start the server with :INPUT-CHUNKING-P set to NIL and see if that makes a difference. http://common-lisp.net/pipermail/mod-lisp-devel/2006-December/000104.html Let us know what comes out of it. Cheers, Edi. From lispercat at gmail.com Fri Mar 30 20:24:43 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 30 Mar 2007 16:24:43 -0400 Subject: [hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Fri Mar 30 20:57:52 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 Mar 2007 22:57:52 +0200 Subject: [hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler In-Reply-To: (Andrei Stebakov's message of "Fri, 30 Mar 2007 16:24:43 -0400") References: Message-ID: On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" wrote: > I got a folder on my linux box that contains about 240 images of font > preview generated from cl-gd (Thanks, Edi!). Nice... :) > When I show them from static apache handler it takes approximately 30 > seconds. Same thing from hunchentoot static handler > (create-folder-dispatcher-and-handler) takes about 50 seconds. I understand > it's not a big deal, but still I'd like to know what might get in the way. I > use hunchentoot behind mod-proxy. > Here are links (first is static apache, second is hunchentoot): > http://www.greenpixeldesign.com/fonts.html > http://www.greenpixeldesign.com/cphandler/fonts.html I guess it's the thread switching that takes the additional time. >From tests on my Linux box (using ApacheBench and a localhost connection) my impression was that serving static files with Hunchentoot wasn't slower than with Apache. On your website it looks like on the Apache page always two or three pictures are downloaded concurrently while on the Hunchentoot version they come one after another. It seems you're using CMUCL which uses "green threads," so that would explain it. If you want to pursue this further, I'd recommend testing with ApacheBench and different settings for its "-c" parameter. Of course, you could/should also try without mod_proxy. And with mod_lisp - that takes a bit of the concurrency off of CMUCL's shoulders. From lispercat at gmail.com Fri Mar 30 21:10:18 2007 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 30 Mar 2007 17:10:18 -0400 Subject: [hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler In-Reply-To: References: Message-ID: Edi, do you think SBCL would change the picture? I am not sure but I heard it uses native threads. I'll try ApacheBench. Do you think switching to Apache 2 would help here? Thank you, Andrew On 3/30/07, Edi Weitz wrote: > > On Fri, 30 Mar 2007 16:24:43 -0400, "Andrei Stebakov" > wrote: > > > I got a folder on my linux box that contains about 240 images of font > > preview generated from cl-gd (Thanks, Edi!). > > Nice... :) > > > When I show them from static apache handler it takes approximately 30 > > seconds. Same thing from hunchentoot static handler > > (create-folder-dispatcher-and-handler) takes about 50 seconds. I > understand > > it's not a big deal, but still I'd like to know what might get in the > way. I > > use hunchentoot behind mod-proxy. > > Here are links (first is static apache, second is hunchentoot): > > http://www.greenpixeldesign.com/fonts.html > > http://www.greenpixeldesign.com/cphandler/fonts.html > > I guess it's the thread switching that takes the additional time. > >From tests on my Linux box (using ApacheBench and a localhost > connection) my impression was that serving static files with > Hunchentoot wasn't slower than with Apache. On your website it looks > like on the Apache page always two or three pictures are downloaded > concurrently while on the Hunchentoot version they come one after > another. It seems you're using CMUCL which uses "green threads," so > that would explain it. > > If you want to pursue this further, I'd recommend testing with > ApacheBench and different settings for its "-c" parameter. > > Of course, you could/should also try without mod_proxy. And with > mod_lisp - that takes a bit of the concurrency off of CMUCL's > shoulders. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Fri Mar 30 21:22:52 2007 From: edi at agharta.de (Edi Weitz) Date: Fri, 30 Mar 2007 23:22:52 +0200 Subject: [hunchentoot-devel] Different speed loading images from static apache and hunchentoot handler In-Reply-To: (Andrei Stebakov's message of "Fri, 30 Mar 2007 17:10:18 -0400") References: Message-ID: On Fri, 30 Mar 2007 17:10:18 -0400, "Andrei Stebakov" wrote: > Edi, do you think SBCL would change the picture? Dunno, you'll have to try. > I am not sure but I heard it uses native threads. It does. On certain platforms. Linux/x86 for example. > I'll try ApacheBench. Do you think switching to Apache 2 would help > here? Speed-wise? I doubt it. From edi at agharta.de Sat Mar 31 00:01:53 2007 From: edi at agharta.de (Edi Weitz) Date: Sat, 31 Mar 2007 02:01:53 +0200 Subject: [hunchentoot-devel] New release 0.8.0 Message-ID: ChangeLog: Version 0.8.0 2007-03-31 Added *APPROVED-RETURN-CODES*, *HEADER-STREAM*, and +HTTP-FAILED-DEPENDENCY+ Exported MIME-TYPE and SSL-P Some minor changes Download: http://weitz.de/files/hunchentoot.tar.gz