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

[hunchentoot-devel] export make-lock and with-lock?
by Cyrus Harmon 26 Apr '07

26 Apr '07

Should hunchentoot export make-lock and with-lock? Thanks, Cyrus

2 2

[hunchentoot-devel] URL-DECODE Problem with MultiByte (> 255) Characters
by Volkan YAZICI 25 Apr '07

25 Apr '07

Hi, While I was trying to issue some regression tests over my URI path handling routine, I met with such a problem: ; Any character that's bigger than 255 reproduces the error. KARPUZ> (code-char 305) #\LATIN_SMALL_LETTER_DOTLESS_I KARPUZ> (wiki-path-to :filename (wiki-path-from :uri "/image/foo/yok artık daha neler///.asd/&baz")) ; Evaluation aborted KARPUZ> (hunchentoot:url-decode (make-string 1 :initial-element (code-char 305)) (flex:make-external-format :utf8 :eol-style :lf)) The value 256 is not of type (UNSIGNED-BYTE 8). [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to SLIME's top level. 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B2637B1}>) Backtrace: 0: (SB-KERNEL:HAIRY-DATA-VECTOR-SET #() 0 256) Locals: SB-DEBUG::ARG-0 = 3 SB-DEBUG::ARG-1 = #() SB-DEBUG::ARG-2 = 0 SB-DEBUG::ARG-3 = 256 1: (VECTOR-PUSH 256 #()) Locals: SB-DEBUG::ARG-0 = 2 SB-DEBUG::ARG-1 = 256 SB-DEBUG::ARG-2 = #() 2: (URL-DECODE "Ā" #<FLEXI-STREAMS::EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) {AE0D729}>) Locals: HUNCHENTOOT::EXTERNAL-FORMAT = #<FLEXI-STREAMS::EXTERNAL-FORMAT (:UTF-8 :EOL-STYLE :LF) {AE0D729}> STRING = "Ā" Would somebody help me to fix the error please? Regards.

2 1

[hunchentoot-devel] Webdav client?
by David King 20 Apr '07

20 Apr '07

How useful would cl-webdav be as a webdav *client* as opposed to a server? -- David

2 1

[hunchentoot-devel] wrong version of sbcl
by Jens Teich 19 Apr '07

19 Apr '07

I'm trying to avoid buying LispWorks for Macintosh but want to run hunchentoot on Intel Mac OS X 10.4.9. The result is: (ERROR "This application will only run on SBCL with thread and Unicode support or on LispWorks.") I have the latest SBCL-Version (1.0.4) and can't find anything on sbcl.org about versions with or without these features. -jens

3 6

[hunchentoot-devel] Announcement: CL-WEBDAV
by Edi Weitz 19 Apr '07

19 Apr '07

This is a WebDAV server based on Hunchentoot. More info here: http://weitz.de/cl-webdav/ Cheers, Edi.

5 6

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

19 Apr '07

ChangeLog: Version 0.9.0 2007-04-19 Added socket timeouts for AllegroCL Catch IO timeout conditions for AllegroCL, SBCL and CMUCL (suggested by Red Daly and others) Added per-server dispatch tables (suggested by Robert Synnott and Andrei Stebakov) Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi.

1 0

[hunchentoot-devel] FIXED: New release 0.8.6 (Was: hunchentoot-mp and OpenMCL problems)
by Joel Boehland 18 Apr '07

18 Apr '07

Hi Edi, Hunchentoot version 0.8.6 fixed the problem. I can load up the test application without problems on OpenMCL/linux. That was very fast. Thanks! --Joel On 4/18/07, Edi Weitz <edi(a)agharta.de> wrote: > On Wed, 18 Apr 2007 11:10:48 -0700, "Joel Boehland" <jboehland+tbnl(a)gmail.com> wrote: > > > The following is a transcript captured using gnu screen, where I try > > your suggestions and have captured a back trace. > > Could you please try the new release and check if this fixes it? > > Thanks for the report, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel(a)common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel >

1 0

[hunchentoot-devel] hunchentoot-mp and OpenMCL problems
by Joel Boehland 18 Apr '07

18 Apr '07

Hi, I just ran into a problem starting up-to-date darcs hunchentoot on OpenMCL 1.1 (releases 070408 and 070214, linux-x86-64). I believe this problem is related to the recently added hunchentoot-mp package, as this error doesn't occur in an earlier install of darcs hunchentoot from March, right before the addition of that package. While trying to load this file: (hello-hunchentoot.lisp) (require :asdf) (asdf:oos 'asdf:load-op :hunchentoot-test) (hunchentoot:start-server :port 4242) I got this error: > Error: The function MAKE-LOCK is predefined in OpenMCL. > While executing: CCL::REDEFINE-KERNEL-FUNCTION, in process listener(1). > Type :GO to continue, :POP to abort, :R for a list of available restarts. > If continued: Replace the definition of MAKE-LOCK. > Type :? for other options. 1 > If anyone needs any more info, or wants me to test anything to help out, let me know. Thanks, Joel

2 3

[hunchentoot-devel] Handling Lisp errors.
by Victor Kryukov 17 Apr '07

17 Apr '07

Hello list, I want to accomplish the following: every time a lisp error happens, the whole backtrace and some additional information is sent to my mail account. The question is, what is the best way to do it with Hunchentoot? (I do know how to send email messages from lisp with the help of mel-base). The second question is: how do you use CLSQL thread-safely with Hunchentoot / SBCL? SBCL don't provide thread properties, so my first solution[1] was to create a hash-table and to assign each thread a connection, to check from every thread whether it already has a connection, and then to clean that hash-table periodically, closing connections for dead threads. That worked pretty well, but I was afraid of exhausting limit of database threads somehow, so I switched to the second solution. The second solution[2] is to open new connection every time I need to save something to database or read something from it, and to close it right after that. That of course solves connection limit problem (unless I have very many users simultaneously, which is not expected in the near term), however it's much slower. Anybody can share his/her strategy? Best regards, Victor. [1] http://paste.lisp.org/display/39787 (defparameter *database-mutex* (sb-thread:make-mutex :name "database lock")) (defparameter *threads-connection* (make-hash-table)) (defun setup-connection () (connect '("localhost" "lj" "victor" "victor") :database-type :postgresql :if-exists :new)) (defun db () (handler-case (sb-thread:with-mutex (*database-mutex*) (or (gethash sb-thread:*current-thread* *threads-connection*) (setf (gethash sb-thread:*current-thread* *threads-connection*) (setup-connection)))) (error () (progn (close-old-connections) (db))))) (defun close-old-connections () (maphash #'(lambda (thread connection) (unless (sb-thread:thread-alive-p thread) (clsql:disconnect :database connection) (remhash thread *threads-connection*))) *threads-connection*)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((*default-database* (db))) (apply old-select args)))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (apply old-insert-records :database (db) args))) [2] http://paste.lisp.org/display/39787#1 (defun db () (connect *connection-spec* :database-type :postgresql :if-exists :new)) (let ((old-select (symbol-function 'clsql:select))) (defun select (&rest args) (let ((clsql:*default-database* (db))) (prog1 (apply old-select args) (disconnect :database clsql:*default-database*))))) (let ((old-insert-records (symbol-function 'insert-records))) (defun insert-records (&rest args) (let ((db (db))) (prog1 (apply old-insert-records :database db args) (disconnect :database db))))) -- Yours Sincerely, Victor Kryukov

6 9

[hunchentoot-devel] Headers eaten during HTTP POST...
by Timofei Shatrov 16 Apr '07

16 Apr '07

I'm rather new to web-programming and I seem to have stumbled upon something horrible. My setup is lighttpd+mod_proxy on Windows XP which redirect to Hunchentoot running on SBCL on Ubuntu Feisty, which is running on VMWare player on the same PC. Everything works fine except HTTP POST, which behaves very weirdly. When I submit POST data, everything is screwed. After some attempts to debug, I found that beginning of headers becomes eaten for some reason, for example the first line may be: "8.1.2) Gecko/20061201 Firefox/2.0.0.2 (Ubuntu-feisty)" (which is part of User-agent: header), when it should be "POST /cl/test-form /HTTP1.1" After that Hunchentoot tries to parse this line and you can guess that nothing good comes out of it... Note that this only happens when I access the page through mod_proxy, when I point at Hunchentoot's IP, everything is fine. However I can't believe mod_proxy randomly eats headers, because that's rather huge bug and would be noticed by everyone. This is reproduceable with hutchentoot-test examples which involve POST. -- Best regards, Timofei Shatrov mailto:grue@mail.ru

2 1