Hi!
I've just tried hunchentoot on sbcl win32. When you first time start hunchentoot, lisp enters debugger with message "undefined function sb-unix:create-timer" or something in that fashion. Looks like timeouts are not implemented in sbcl win32 so I've changed with-timeout macro in the port-sbcl.lisp to just execute its body without timeout. It helps.
(defmacro with-timeout ((seconds &body timeout-forms) &body body) "Executes the code BODY and returns the results of the last form but stops execution after SECONDS seconds and then instead executes the code in TIMEOUT-FORMS." #+:win32 `(progn ,@body) #-:win32 `(cl:handler-case (sb-ext:with-timeout ,seconds ,@body) (sb-ext:timeout () ,@timeout-forms)))
Best regards, -Anton
On Sun, 01 Jul 2007 02:32:06 +0400, Anton Vodonosov vodonosov@mail.ru wrote:
I've just tried hunchentoot on sbcl win32. When you first time start hunchentoot, lisp enters debugger with message "undefined function sb-unix:create-timer" or something in that fashion. Looks like timeouts are not implemented in sbcl win32 so I've changed with-timeout macro in the port-sbcl.lisp to just execute its body without timeout. It helps.
Thanks for the info. I wonder why this hasn't been an issue for the other SBCL/Win32 users so far, though.
Anyway, I'd rather see a more unobtrusive patch which automagically starts to work once timeouts are implemented. Something along the lines of
http://www.cl-user.net/asp/web-sites/features
Cheers, Edi.
Edi Weitz:
I wonder why this hasn't been an issue for the other SBCL/Win32 users so far, though.
I'm using sbcl 1.0.6 win32 binary downloaded from sbcl site. The error UNDEFINED-FUNCTION: SB-UNIX:UNIX-SETITIMER is signaled only when you start hunchentoot first time (i.e. when you invoke sb-ext:with-timeout first time). You may just press 'q' in the slime debugger and start hunchentoot again. But the function is definitely not works for win32, I even checkd sbcl sources.
BTW, in the patch suggested here http://common-lisp.net/pipermail/tbnl-devel/2006-November/000815.html Luís Oliveira also removes sb-ext:with-timeout (he redefines force-output* - the only place where with-timout is used)
Anyway, I'd rather see a more unobtrusive patch which automagically starts to work once timeouts are implemented. Something along the lines of
Thank you for the link. What do you think about the following mega-solution:
;; determine whether SB-EXT:WITH-TIMEOUT function is supported; ;; we can't just check (FBOUNDP 'SB-EXT:WITH-TIMEOUT) ;; because, for example in sbcl 1.0.6 for win32, the function ;; is present, but doesn't work (it signals UNDEFINED-FUNCTION: ;; SB-UNIX:UNIX-SETITIMER) (eval-when (:compile-toplevel :load-toplevel :execute) (defun ensured-sleep-millis (milliseconds) "Sleeps (in fact loops) not less then MILLISECONDS number of milliseconds; the minimal sleep time is one internal time unit. Don't use this function for large time values, because it may take up much processor power." (do ((start-time (get-internal-real-time))) ((< (+ start-time (ceiling (* internal-time-units-per-second (/ milliseconds 1000)))) (get-internal-real-time))))) (handler-case (sb-ext:with-timeout 0.0000001 (ensured-sleep-millis 5)) (sb-ext:timeout () (pushnew :hunchentoot-sbcl-with-timeout *features*)) (t ())))
(defmacro with-timeout ((seconds &body timeout-forms) &body body) "Executes the code BODY and returns the results of the last form but stops execution after SECONDS seconds and then instead executes the code in TIMEOUT-FORMS." #-:hunchentoot-sbcl-with-timeout `(progn ,@body) #+:hunchentoot-sbcl-with-timeout `(cl:handler-case (sb-ext:with-timeout ,seconds ,@body) (sb-ext:timeout () ,@timeout-forms)))
In the paper it is suggested to insert symbols from library's package but not keywoards into *features*, but I follow the way already used in port-sbcl (see :hunchentoot-sbcl-debug-print-variable-alist).
I've tried this code on sbcl win32 and on linux. It works as expected.
Best regards, -Anton
It's strange. Today I've tried to load hunchentoot via asdf and the code I've sent in previous message don't work.
I fixed it a little and now it's possible to load hunchentoot using asdf and sbcl win32:
;; Determine whether sb-ext:with-timeout is supported; ;; we can't just check (FIND-SYMBOL "WITH-TIMEOUT" "SB-EXT") ;; because, for example in sbcl 1.0.6 for win32, the function ;; is present, but doesn't work (it signals UNDEFINED-FUNCTION: ;; SB-UNIX:UNIX-SETITIMER) (eval-when (:compile-toplevel :load-toplevel :execute) (defun ensured-sleep-millis (milliseconds) "Sleeps (in fact loops) not less then MILLISECONDS number of milliseconds; the minimal sleep time is one internal time unit. Don't use this function for large time values, because it eats processor power." (do ((start-time (get-internal-real-time))) ((< (+ start-time (ceiling (* internal-time-units-per-second (/ milliseconds 1000)))) (get-internal-real-time))))) (cl:handler-case (sb-ext:with-timeout 0.0000001 (ensured-sleep-millis 5)) (sb-ext:timeout () (pushnew :hunchentoot-sbcl-with-timeout *features*)) (cl:t ())))
(defmacro with-timeout ((seconds &body timeout-forms) &body body) "Executes the code BODY and returns the results of the last form but stops execution after SECONDS seconds and then instead executes the code in TIMEOUT-FORMS." (declare (ignorable seconds timeout-forms body)) #-:hunchentoot-sbcl-with-timeout `(cl:progn ,@body) #+:hunchentoot-sbcl-with-timeout `(cl:handler-case (sb-ext:with-timeout ,seconds ,@body) (sb-ext:timeout () ,@timeout-forms)))
BTW, in the top of port-sbcl.lisp there is #-:sb-thread (eval-when (:compile-toplevel :load-toplevel :execute) (warn "Without thread support, this library is only useful for development."))
It's quite annoying because compilation with asdf fails on this (today; strange again I don't remember that it happened before)
Regards, -Anton
On Sat, 14 Jul 2007 04:34:05 +0400, Anton Vodonosov vodonosov@mail.ru wrote:
It's strange. Today I've tried to load hunchentoot via asdf and the code I've sent in previous message don't work.
I fixed it a little and now it's possible to load hunchentoot using asdf and sbcl win32:
Thanks, I finally managed to add this code.
BTW, in the top of port-sbcl.lisp there is #-:sb-thread (eval-when (:compile-toplevel :load-toplevel :execute) (warn "Without thread support, this library is only useful for development."))
It's quite annoying because compilation with asdf fails on this (today; strange again I don't remember that it happened before)
Yeah, sorry, this is ASDF's default behaviour that I don't necessarily like. Still, I think for pedagogical purposes it it good to have this warning in there.
Cheers, Edi.
-
Anton Vodonosov -
Edi Weitz