Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to suggests to me that the "ediware" repo is either out of date or too bleeding edge...
take care
Nick
Hi Nick,
thank you for reporting a problem - Can you provide me with details on how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for Lispworks? I have removed it because I believed that there is no code path that could be to recursive locking, but I could have been missing something.
In general, the Subversion repository is less stable than Edi's releases and we are planning to make a proper release, yet I can't make any promises.
Thanks, Hans
On Thu, Jul 31, 2008 at 03:58, Nick Allen rflug05@gmail.com wrote:
Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to suggests to me that the "ediware" repo is either out of date or too bleeding edge... take care Nick _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hello Hans, The specific problem I ran into was a recursive lock error thrown when setting a session value in the same request that starts a session. I'm using rev 3591. here's an example:
(defun test-dispatcher (hunchentoot:*request*) (lambda ()
;; set the session value FOO to the value of ;; the HTTP get parameter "set-foo", if it ;; exists (let ((set-foo (hunchentoot:get-parameter "set-foo"))) (when set-foo (setf (hunchentoot:session-value 'foo) set-foo)))
;; then return a page that shows the session ;; value FOO (format nil "The foo is ~A" (hunchentoot:session-value 'foo))))
;; start the server (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) (defvar *test-server* (hunchentoot:start-server :port 2001))
;; now go to: ;; ;; http://localhost:2001?set-foo=bar ;; ;; it should look like: ;; ;; The Foo is bar ;; ;; but it throws a recursive lock error
On Thu, Jul 31, 2008 at 7:09 AM, Hans Hübner hans@huebner.org wrote:
Hi Nick,
thank you for reporting a problem - Can you provide me with details on how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for Lispworks? I have removed it because I believed that there is no code path that could be to recursive locking, but I could have been missing something.
In general, the Subversion repository is less stable than Edi's releases and we are planning to make a proper release, yet I can't make any promises.
Thanks, Hans
On Thu, Jul 31, 2008 at 03:58, Nick Allen rflug05@gmail.com wrote:
Hello! Is the "ediware" location of the hunchentoot source the recommended
version
for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of
"lispworks.lisp",
which seems to have introducing some bugs, which seems to me to suggests
to
me that the "ediware" repo is either out of date or too bleeding edge... take care Nick _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Nick,
thank you for your detailed report. I think I have fixed the problem, can you svn up and let me know if it works better? If not, I'll hack on it more so that things get back to a good state tonight. Sorry for the glitch.
Thanks, Hans
On Thu, Jul 31, 2008 at 17:43, Nick Allen rflug05@gmail.com wrote:
Hello Hans, The specific problem I ran into was a recursive lock error thrown when setting a session value in the same request that starts a session. I'm using rev 3591. here's an example: (defun test-dispatcher (hunchentoot:*request*) (lambda () ;; set the session value FOO to the value of ;; the HTTP get parameter "set-foo", if it ;; exists (let ((set-foo (hunchentoot:get-parameter "set-foo"))) (when set-foo (setf (hunchentoot:session-value 'foo) set-foo))) ;; then return a page that shows the session ;; value FOO (format nil "The foo is ~A" (hunchentoot:session-value 'foo))))
;; start the server (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) (defvar *test-server* (hunchentoot:start-server :port 2001)) ;; now go to: ;; ;; http://localhost:2001?set-foo=bar ;; ;; it should look like: ;; ;; The Foo is bar ;; ;; but it throws a recursive lock error On Thu, Jul 31, 2008 at 7:09 AM, Hans Hübner hans@huebner.org wrote:
Hi Nick,
thank you for reporting a problem - Can you provide me with details on how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for Lispworks? I have removed it because I believed that there is no code path that could be to recursive locking, but I could have been missing something.
In general, the Subversion repository is less stable than Edi's releases and we are planning to make a proper release, yet I can't make any promises.
Thanks, Hans
On Thu, Jul 31, 2008 at 03:58, Nick Allen rflug05@gmail.com wrote:
Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to suggests to me that the "ediware" repo is either out of date or too bleeding edge... take care Nick _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hello, The session value / recursive lock stuff all seems to work as of rev #3712.
thanks for the quick response, keep up the good work!
Nick
On Thu, Jul 31, 2008 at 6:03 PM, Hans Hübner hans@huebner.org wrote:
Hi Nick,
thank you for your detailed report. I think I have fixed the problem, can you svn up and let me know if it works better? If not, I'll hack on it more so that things get back to a good state tonight. Sorry for the glitch.
Thanks, Hans
On Thu, Jul 31, 2008 at 17:43, Nick Allen rflug05@gmail.com wrote:
Hello Hans, The specific problem I ran into was a recursive lock error thrown when setting a session value in the same request that starts a session. I'm
using
rev 3591. here's an example: (defun test-dispatcher (hunchentoot:*request*) (lambda () ;; set the session value FOO to the value of ;; the HTTP get parameter "set-foo", if it ;; exists (let ((set-foo (hunchentoot:get-parameter "set-foo"))) (when set-foo (setf (hunchentoot:session-value 'foo) set-foo))) ;; then return a page that shows the session ;; value FOO (format nil "The foo is ~A" (hunchentoot:session-value 'foo))))
;; start the server (pushnew 'test-dispatcher hunchentoot:*dispatch-table*) (defvar *test-server* (hunchentoot:start-server :port 2001)) ;; now go to: ;; ;; http://localhost:2001?set-foo=bar ;; ;; it should look like: ;; ;; The Foo is bar ;; ;; but it throws a recursive lock error On Thu, Jul 31, 2008 at 7:09 AM, Hans Hübner hans@huebner.org wrote:
Hi Nick,
thank you for reporting a problem - Can you provide me with details on how the removal of WITH-RECURSIVE-LOCK breaks Hunchentoot for Lispworks? I have removed it because I believed that there is no code path that could be to recursive locking, but I could have been missing something.
In general, the Subversion repository is less stable than Edi's releases and we are planning to make a proper release, yet I can't make any promises.
Thanks, Hans
On Thu, Jul 31, 2008 at 03:58, Nick Allen rflug05@gmail.com wrote:
Hello! Is the "ediware" location of the hunchentoot source the recommended version for deployment? or should we be using the tarball linked off the documentation or the "hans" version? I'm wondering because WITH-RECURSIVE-LOCK-HELD seems to have disappeared out of "lispworks.lisp", which seems to have introducing some bugs, which seems to me to
suggests
to me that the "ediware" repo is either out of date or too bleeding
edge...
take care Nick _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Hans Hübner -
Nick Allen