From jmckitrick at gmail.com Tue Sep 1 17:52:24 2009 From: jmckitrick at gmail.com (Jonathon McKitrick) Date: Tue, 1 Sep 2009 13:52:24 -0400 Subject: [hunchentoot-devel] Backtrace display Message-ID: I recall some time ago, the break and backtrace capability of Hunchentoot was removed, perhaps to make it less platform dependent. But I still find myself often trying to find the origin of cryptic error messages, and adding FORMAT and BREAK statements to narrow down the problem area. What is a good way to drop in support for, say, SBCL, so that an error will break into the debugger with a backtrace, or even dump the backtrace to the log file? -- Jonathon McKitrick From sky at viridian-project.de Tue Sep 1 18:50:03 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 1 Sep 2009 20:50:03 +0200 (CEST) Subject: [hunchentoot-devel] Backtrace display In-Reply-To: References: Message-ID: Jonathon McKitrick wrote: > I recall some time ago, the break and backtrace capability of > Hunchentoot was removed, perhaps to make it less platform dependent. > But I still find myself often trying to find the origin of cryptic > error messages, and adding FORMAT and BREAK statements to narrow down > the problem area. What is a good way to drop in support for, say, > SBCL, so that an error will break into the debugger with a backtrace, > or even dump the backtrace to the log file? See http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/error-handler.lisp and http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/request-handler.lisp#cl-61 Leslie -- http://www.linkedin.com/in/polzer From jmckitrick at gmail.com Thu Sep 3 01:54:14 2009 From: jmckitrick at gmail.com (Jonathon McKitrick) Date: Wed, 2 Sep 2009 21:54:14 -0400 Subject: [hunchentoot-devel] Backtrace display In-Reply-To: References: Message-ID: Thanks, I'll check these out. It looks pretty weblocks-specific, but I assume it can be adapted to hunchentoot easily enough? I'll just look for a similar method to wrap with the AROUND method. On Tue, Sep 1, 2009 at 2:50 PM, Leslie P. Polzer wrote: > > Jonathon McKitrick wrote: >> I recall some time ago, the break and backtrace capability of >> Hunchentoot was removed, perhaps to make it less platform dependent. >> But I still find myself often trying to find the origin of cryptic >> error messages, and adding FORMAT and BREAK statements to narrow down >> the problem area. ?What is a good way to drop in support for, say, >> SBCL, so that an error will break into the debugger with a backtrace, >> or even dump the backtrace to the log file? > > See http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/error-handler.lisp > and http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/request-handler.lisp#cl-61 > > ?Leslie > > -- > http://www.linkedin.com/in/polzer > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- Jonathon McKitrick http://moltencopper.com From daniel at whitehouse.id.au Thu Sep 3 03:44:46 2009 From: daniel at whitehouse.id.au (Daniel White) Date: Thu, 3 Sep 2009 13:44:46 +1000 Subject: [hunchentoot-devel] Backtrace display In-Reply-To: References: Message-ID: <20090903134446.773f3059@whitehouse.id.au> On Wed, 2 Sep 2009 21:54:14 -0400 Jonathon McKitrick wrote: > Thanks, I'll check these out. It looks pretty weblocks-specific, but > I assume it can be adapted to hunchentoot easily enough? I'll just > look for a similar method to wrap with the AROUND method. > > On Tue, Sep 1, 2009 at 2:50 PM, Leslie P. Polzer wrote: > > > > Jonathon McKitrick wrote: > >> I recall some time ago, the break and backtrace capability of > >> Hunchentoot was removed, perhaps to make it less platform dependent. > >> But I still find myself often trying to find the origin of cryptic > >> error messages, and adding FORMAT and BREAK statements to narrow down > >> the problem area. ?What is a good way to drop in support for, say, > >> SBCL, so that an error will break into the debugger with a backtrace, > >> or even dump the backtrace to the log file? > > > > See http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/error-handler.lisp > > and http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/request-handler.lisp#cl-61 > > > > ?Leslie For debugging purposes, I've been using the following for a while. It only extends Andreas' suggestion slightly by handling the IO-TIMEOUT condition I was experiencing in SBCL. ;;; Acceptor that provides debugging from the REPL ;;; Based on an email by Andreas Fruchs: ;;; http://common-lisp.net/pipermail/tbnl-devel/2009-April/004688.html (defclass debuggable-acceptor (acceptor) () (:documentation "An acceptor that handles errors by invoking the debugger.")) (defmethod process-connection ((*acceptor* debuggable-acceptor) (socket t)) (declare (ignore socket)) ;; Invoke the debugger on any errors except for SB-SYS:IO-TIMEOUT. ;; HTTP browsers usually leave the connection open for futher requests, ;; and Hunchentoot respects this but sets a timeout so that old connections ;; are cleaned up. (let ((*debugging-p* t)) (handler-case (call-next-method) #+sbcl (sb-sys:io-timeout (condition) (values nil condition)) (error (condition) (invoke-debugger condition))))) (defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) (let ((dispatcher (call-next-method))) (lambda (request) (handler-bind ((error #'invoke-debugger)) (funcall dispatcher request))))) -- Daniel White From daniel at whitehouse.id.au Thu Sep 3 03:47:48 2009 From: daniel at whitehouse.id.au (Daniel White) Date: Thu, 3 Sep 2009 13:47:48 +1000 Subject: [hunchentoot-devel] Backtrace display In-Reply-To: <20090903134446.773f3059@whitehouse.id.au> References: <20090903134446.773f3059@whitehouse.id.au> Message-ID: <20090903134748.2001494e@whitehouse.id.au> On Thu, 3 Sep 2009 13:44:46 +1000 Daniel White wrote: > On Wed, 2 Sep 2009 21:54:14 -0400 > Jonathon McKitrick wrote: > > > Thanks, I'll check these out. It looks pretty weblocks-specific, but > > I assume it can be adapted to hunchentoot easily enough? I'll just > > look for a similar method to wrap with the AROUND method. > > > > On Tue, Sep 1, 2009 at 2:50 PM, Leslie P. Polzer wrote: > > > > > > Jonathon McKitrick wrote: > > >> I recall some time ago, the break and backtrace capability of > > >> Hunchentoot was removed, perhaps to make it less platform dependent. > > >> But I still find myself often trying to find the origin of cryptic > > >> error messages, and adding FORMAT and BREAK statements to narrow down > > >> the problem area. ?What is a good way to drop in support for, say, > > >> SBCL, so that an error will break into the debugger with a backtrace, > > >> or even dump the backtrace to the log file? > > > > > > See http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/error-handler.lisp > > > and http://bitbucket.org/S11001001/weblocks-dev/src/tip/src/request-handler.lisp#cl-61 > > > > > > ?Leslie > > For debugging purposes, I've been using the following for a while. It > only extends Andreas' suggestion slightly by handling the IO-TIMEOUT > condition I was experiencing in SBCL. > > ;;; Acceptor that provides debugging from the REPL > ;;; Based on an email by Andreas Fruchs: > ;;; http://common-lisp.net/pipermail/tbnl-devel/2009-April/004688.html > (defclass debuggable-acceptor (acceptor) > () > (:documentation "An acceptor that handles errors by invoking the > debugger.")) > > (defmethod process-connection ((*acceptor* debuggable-acceptor) (socket t)) > (declare (ignore socket)) > ;; Invoke the debugger on any errors except for SB-SYS:IO-TIMEOUT. > ;; HTTP browsers usually leave the connection open for futher requests, > ;; and Hunchentoot respects this but sets a timeout so that old connections > ;; are cleaned up. > (let ((*debugging-p* t)) > (handler-case (call-next-method) > #+sbcl (sb-sys:io-timeout (condition) (values nil condition)) > (error (condition) (invoke-debugger condition))))) > > (defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) > (let ((dispatcher (call-next-method))) > (lambda (request) > (handler-bind ((error #'invoke-debugger)) > (funcall dispatcher request))))) > I also have a special variable *DEBUGGING-P* defined for some other special cases I needed, so that can be safely discarded if not needed. -- Daniel White From sky at viridian-project.de Thu Sep 3 05:39:41 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 3 Sep 2009 07:39:41 +0200 (CEST) Subject: [hunchentoot-devel] Backtrace display In-Reply-To: References: Message-ID: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> Jonathon McKitrick wrote: > Thanks, I'll check these out. It looks pretty weblocks-specific, but > I assume it can be adapted to hunchentoot easily enough? Weblocks is built on Hunchentoot, and I think the code shown can be used with only minor modifications. Leslie -- http://www.linkedin.com/in/polzer From hans.huebner at gmail.com Thu Sep 3 06:45:00 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 3 Sep 2009 08:45:00 +0200 Subject: [hunchentoot-devel] Backtrace display In-Reply-To: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> References: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> Message-ID: We have removed the backtrace support from Hunchentoot because we wanted to get rid of all non-essential system dependencies. For interactive debugging, the *BREAK-ON-SIGNALS* special variable can (should) be used, it can do what the presented acceptor subclass can do. If you really need backtraces in your log files, the trivial-backtrace [2] library may be useful. It would be useful to have a section on debugging in the manual. -Hans [1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stbreak-on-signalsst.html [2] http://common-lisp.net/project/trivial-backtrace/ From asf at boinkor.net Thu Sep 3 07:00:07 2009 From: asf at boinkor.net (Andreas Fuchs) Date: Thu, 3 Sep 2009 09:00:07 +0200 Subject: [hunchentoot-devel] Backtrace display In-Reply-To: References: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> Message-ID: On Thu, Sep 3, 2009 at 08:45, Hans H?bner wrote: > We have removed the backtrace support from Hunchentoot because we > wanted to get rid of all non-essential system dependencies. ?For > interactive debugging, the *BREAK-ON-SIGNALS* special variable can > (should) be used, it can do what the presented acceptor subclass can > do. ?If you really need backtraces in your log files, the > trivial-backtrace [2] library may be useful. IME, *break-on-signals* didn't work too well when I was debugging my hunchentoot application. (I don't remember exactly what the problem was, sorry.) However, with just two definitions (posted in April[1]), HT gets much more debuggable in interactive use: (defclass debuggable-acceptor (hunchentoot:acceptor) ()) (defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) (let ((dispatcher (call-next-method))) (lambda (request) (handler-bind ((error #'invoke-debugger)) (funcall dispatcher request))))) Then, you use the hunchentoot web service with (make-instance 'debuggable-acceptor :port 4242), and you'll get a (swank) debugger every time an error condition slips through. Hope that helps. [1] http://common-lisp.net/pipermail/tbnl-devel/2009-April/004688.html -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From jsc at crispylogics.com Thu Sep 3 08:30:52 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Thu, 3 Sep 2009 10:30:52 +0200 Subject: [hunchentoot-devel] Backtrace display + idea for "representations" In-Reply-To: References: <91d4af8bc5cf8fc977275d3ec1d6c800.squirrel@mail.stardawn.org> Message-ID: <1BFA29A5-4421-42A4-894E-34D9319AAF74@crispylogics.com> Hans, As outlined before - *break-on-signals* is not a good solution. Not all conditions are errors or useful break points. If we really have to fallback to ANSI CL means for that purpose, wrapping a handler-bind like in Andreas' Solution is better - I use something similar in my code (Actually I do handle all conditions in my handlers now, because I didn't get hunchentoots error handling to do what I wanted). Documentation may help, or not; some clear protocols would be perfect :-) Hunchentoot evolved really well towards 1.0. I really appreciate the extensibility one now gets through some clearer protocols (task- managers, request-/reply-class a. s. o.). I still see some open problems though. Hunchentoot completely misses the concept of a "representation" - instead it uses either strings or octet-streams directly in an ad hoc way. Perhaps it would be a good idea to abstract this underlying representations using a small set of extensible representation classes? Something like: representation | / | \ | | string-representation | | | file-representation | stream-representation A handler would then not either return a string or write itself into the stream one gets from send-headers, but it would generate (or select) a representation object and hunchentoot handles this automatically. ciao, Jochen -- Jochen Schmidt Am 03.09.2009 um 08:45 schrieb Hans H?bner : > We have removed the backtrace support from Hunchentoot because we > wanted to get rid of all non-essential system dependencies. For > interactive debugging, the *BREAK-ON-SIGNALS* special variable can > (should) be used, it can do what the presented acceptor subclass can > do. If you really need backtraces in your log files, the > trivial-backtrace [2] library may be useful. > > It would be useful to have a section on debugging in the manual. > > -Hans > > [1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stbreak-on-signalsst.html > [2] http://common-lisp.net/project/trivial-backtrace/ > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From mackram at gmail.com Sun Sep 6 18:15:32 2009 From: mackram at gmail.com (Mackram Raydan) Date: Sun, 6 Sep 2009 21:15:32 +0300 Subject: [hunchentoot-devel] Issue with setting a dispatcher In-Reply-To: <37654d130908311205w27f73ce4o8f9fe6f4d4afccee@mail.gmail.com> References: <37654d130908311114j4fd62c87u3942d5d49e604572@mail.gmail.com> <37654d130908311205w27f73ce4o8f9fe6f4d4afccee@mail.gmail.com> Message-ID: <37654d130909061115j674c5497vc0e2c78b2e3d6519@mail.gmail.com> Hey just in case anyone interested i wrote a post explaining the solution at http://www.trailoflight.net/blog/?p=22 Mackram Raydan Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo On Mon, Aug 31, 2009 at 10:05 PM, Mackram Raydan wrote: > Thank you so much Hans for your quick reply, that makes so much sense now > :). > > > Mackram Raydan > > Website: www.trailoflight.net > "An invasion of armies can be resisted, but not an idea whose time has > come." Victor Hugo > > > On Mon, Aug 31, 2009 at 9:58 PM, Hans H?bner wrote: > >> On Mon, Aug 31, 2009 at 20:14, Mackram Raydan wrote: >> > I have been trying to get a dispatcher to work with hunchentoot but I >> have >> > been unable to do it at all. Specifically running the following line on >> the >> > REPL (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4555 >> > :request-dispatcher (apply 'hunchentoot:create-prefix-dispatcher '("/" >> > make-home-page)))) would result in an error appearing when i try to >> access >> > the localhost:4555. The error I get is [2009-08-31 21:04:16 [ERROR]] >> Error >> > while processing connection: The value MAKE-HOME-PAGE is not of type >> > SEQUENCE. >> >> Confusingly, the argument to :request-dispatcher is something >> completely different from what create-prefix-dispatcher creates. The >> :request-dispatcher argument is only used when you do not want to use >> the dispatcher/handler architecture of hunchentoot. It is a function >> designator for a function that is called for each request to be >> handled. This function needs to parse the request and call an >> appropriate handler, in whatever fashion your architecture requires. >> Contrasted to that, create-prefix-dispatcher is part of hunchentoot's >> own dispatcher and handler architecture. If you want to use that, >> you'll not supply a :request-dispatcher argument when you create the >> acceptor, as the default will do the right thing. >> >> -Hans >> >> _______________________________________________ >> 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 mackram at gmail.com Mon Sep 7 19:59:15 2009 From: mackram at gmail.com (Mackram Raydan) Date: Mon, 7 Sep 2009 22:59:15 +0300 Subject: [hunchentoot-devel] question about the url of the request Message-ID: <37654d130909071259h1a4ac9bcue8d05dbfb04bd446@mail.gmail.com> Hey everyone, so i was working on my website and i noticed something peculiar in the documentation of hunchentoot that i thought i should probably ask about. As i understand hunchentoot has a function called get-uri* which returns the full uri including the query (the thing after the ?) and also has a function called get-query which returns the string that is after the ?. So my question is, is there a function that returns the url without the query string so that i can use my own dispatchers or should i use string manipulation? Also a side question not related to hunchentoot but that which i would greatly appreciate an anser too, does anyone know of some library that offer mail server ability in lisp or maybe just can recieve emails and offer them for processing (i currently use a modified version of cl-smtp by bknr to send emails.) Thanks in advance. Mackram Raydan Company: www.imagimate.com Website: www.trailoflight.net "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Mon Sep 7 20:19:59 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 7 Sep 2009 22:19:59 +0200 Subject: [hunchentoot-devel] question about the url of the request In-Reply-To: <37654d130909071259h1a4ac9bcue8d05dbfb04bd446@mail.gmail.com> References: <37654d130909071259h1a4ac9bcue8d05dbfb04bd446@mail.gmail.com> Message-ID: On Mon, Sep 7, 2009 at 21:59, Mackram Raydan wrote: > so i was working on my website and i noticed something peculiar in the > documentation of hunchentoot that i thought i should probably ask about. As > i understand hunchentoot has a function called get-uri* which returns the > full uri including the query (the thing after the ?) and also has a function > called get-query which returns the string that is after the ?. So my > question is, is there a function that returns the url without the query > string so that i can use my own dispatchers or should i use string > manipulation? You should use the SCRIPT-NAME function. It has its name from its CGI heritage. We discussed whether we want to get rid of all those CGI names and use more intuitive ones at some point, but then decided that this would be too intrusive a change. > Also a side question not related to hunchentoot but that which i would > greatly appreciate an anser too, does anyone know of some library that offer > mail server ability in lisp or maybe just can recieve emails and offer them > for processing (i currently use a modified version of cl-smtp by bknr to > send emails.) I have successfully handled incoming emails with imap, using both the mel-base and Franz' own imap libraries. Using imap has the advantage that an existing email infrastructure can be used, which is also its disadvantage. Franz has published an open source smtp server, too, which can propably be made to run using the acl-compat library if you feel that a real mail server would serve you better. See http://github.com/franzinc for Franz' open source offerings, http://www.cliki.net/ACL-COMPAT for the Allegro CL compatibility library acl-compat, and http://common-lisp.net/project/mel-base/ for the mel-base project. -Hans From vseloved at gmail.com Mon Sep 7 20:09:25 2009 From: vseloved at gmail.com (Vsevolod) Date: Mon, 7 Sep 2009 23:09:25 +0300 Subject: [hunchentoot-devel] question about the url of the request In-Reply-To: <37654d130909071259h1a4ac9bcue8d05dbfb04bd446@mail.gmail.com> References: <37654d130909071259h1a4ac9bcue8d05dbfb04bd446@mail.gmail.com> Message-ID: <89dc7c5b0909071309w4e53108bvc710554f78b57587@mail.gmail.com> The function you're looking for is script-name* On Mon, Sep 7, 2009 at 10:59 PM, Mackram Raydan wrote: > Hey everyone, > > so i was working on my website and i noticed something peculiar in the > documentation of hunchentoot that i thought i should probably ask about. As > i understand hunchentoot has a function called get-uri* which returns the > full uri including the query (the thing after the ?) and also has a function > called get-query which returns the string that is after the ?. So my > question is, is there a function that returns the url without the query > string so that i can use my own dispatchers or should i use string > manipulation? > > Also a side question not related to hunchentoot but that which i would > greatly appreciate an anser too, does anyone know of some library that offer > mail server ability in lisp or maybe just can recieve emails and offer them > for processing (i currently use a modified version of cl-smtp by bknr to > send emails.) > > Thanks in advance. > > Mackram Raydan > > Company: www.imagimate.com > Website: www.trailoflight.net > > "An invasion of armies can be resisted, but not an idea whose time has > come." Victor Hugo > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.may at mac.com Sun Sep 13 14:53:56 2009 From: patrick.may at mac.com (Patrick May) Date: Sun, 13 Sep 2009 10:53:56 -0400 Subject: [hunchentoot-devel] [Openmcl-devel] Exception in foreign context In-Reply-To: <3445ED9C-FEA9-4ABB-B6BE-E8EDF7E61F0E@mac.com> References: <3445ED9C-FEA9-4ABB-B6BE-E8EDF7E61F0E@mac.com> Message-ID: <60F13ABB-B3C7-4BC8-BD10-8A2E53843E08@mac.com> On Sep 3, 2009, at 5:47 PM, Patrick May wrote: > On Sep 3, 2009, at 4:30 PM, R. Matthew Emerson wrote: >> On Sep 3, 2009, at 3:13 PM, Patrick May wrote: >>> I'm getting this error every couple of days when running >>> Hunchentoot >>> in CCL (1.3-r11936, 64 bit, Linux). Any idea what's causing it? >>> >>> ? exception in foreign context >>> Exception occurred while executing foreign code >>> at create_exception_callback_frame + 80 >>> ? for help >>> >>> [26583] Clozure CL kernel debugger: b >>> [26583] Clozure CL kernel debugger: current thread: tcr = >>> 0x7fe8ab2267b0, native thread ID = 0x11ec, interrupts disabled >>> >>> >>> (#x00007FE8ADBEDF48) #x0000300040018F7C : #>> LOCK #x0000300040018F2F> + 77 >>> Bogus frame 7fe8adbedf60 >>> [26583] Clozure CL kernel debugger: >> >> Those symptoms don't remind me of any bug I know about right off >> hand. >> >> You might try updating your CCL, though. You appear to be using the >> original 1.3 release binary, and I know that there have been >> important bug fixes to the 1.3 branch since release. > > Thanks for the quick response. I've updated from Subversion and > rebuilt CCL to 1.3-r12755M. Hopefully that will fix the problem. I just got the following problem. I don't know if it's related to Clozure or to Hunchentoot (64-bit Linux): Welcome to Clozure Common Lisp Version 1.3-r12755M (LinuxX8664)! ? STRING-OUTPUT-STREAM #x300041AC43AD> is not of the expected tyexception in foreign context Exception occurred while executing foreign code at create_exception_callback_frame + 80 ? for help [5067] Clozure CL kernel debugger: ? (G) Set specified GPR to new value (R) Show raw GPR/SPR register values (L) Show Lisp values of tagged registers (F) Show FPU registers (S) Find and describe symbol matching specified name (B) Show backtrace (T) Show info about current thread (X) Exit from this debugger, asserting that any exception was handled (K) Kill Clozure CL process (?) Show this help [5067] Clozure CL kernel debugger: b current thread: tcr = 0x7fd6b38177b0, native thread ID = 0x1e96, interrupts disabled [5067] Clozure CL kernel debugger: t Current Thread Context Record (tcr) = 0x7fd6b38177b0 Control (C) stack area: low = 0x7fd6b35c4000, high = 0x7fd6b3818000 Value (lisp) stack area: low = 0x7fd6b33a2000, high = 0x7fd6b35b3000 Exception stack pointer = 0x7fd6b35c3788 [5067] Clozure CL kernel debugger: k Any idea what could be causing this? Is anyone here running a website with Clozure and Hunchentoot? Thanks, Patrick From patrick.may at mac.com Sun Sep 13 16:36:18 2009 From: patrick.may at mac.com (Patrick May) Date: Sun, 13 Sep 2009 12:36:18 -0400 Subject: [hunchentoot-devel] [Openmcl-devel] Exception in foreign context In-Reply-To: <60F13ABB-B3C7-4BC8-BD10-8A2E53843E08@mac.com> References: <3445ED9C-FEA9-4ABB-B6BE-E8EDF7E61F0E@mac.com> <60F13ABB-B3C7-4BC8-BD10-8A2E53843E08@mac.com> Message-ID: <28F08135-36F0-4DFE-A3E9-A402D1857B5D@mac.com> On Sep 13, 2009, at 10:53 AM, Patrick May wrote: > I just got the following problem. I don't know if it's related to > Clozure or to Hunchentoot (64-bit Linux): > Welcome to Clozure Common Lisp Version 1.3-r12755M (LinuxX8664)! > ? STRING-OUTPUT-STREAM #x300041AC43AD> is not of the expected > tyexception in foreign context > Exception occurred while executing foreign code > at create_exception_callback_frame + 80 > ? for help > [5067] Clozure CL kernel debugger: ? > (G) Set specified GPR to new value > (R) Show raw GPR/SPR register values > (L) Show Lisp values of tagged registers > (F) Show FPU registers > (S) Find and describe symbol matching specified name > (B) Show backtrace > (T) Show info about current thread > (X) Exit from this debugger, asserting that any exception was handled > (K) Kill Clozure CL process > (?) Show this help > [5067] Clozure CL kernel debugger: b > current thread: tcr = 0x7fd6b38177b0, native thread ID = 0x1e96, > interrupts disabled > > > [5067] Clozure CL kernel debugger: t > Current Thread Context Record (tcr) = 0x7fd6b38177b0 > Control (C) stack area: low = 0x7fd6b35c4000, high = 0x7fd6b3818000 > Value (lisp) stack area: low = 0x7fd6b33a2000, high = 0x7fd6b35b3000 > Exception stack pointer = 0x7fd6b35c3788 > [5067] Clozure CL kernel debugger: k > > Any idea what could be causing this? Is anyone here running a > website with Clozure and Hunchentoot? I finally managed to get a backtrace on this problem. I've reduced the deployment down to the latest Clozure running on 64-bit Linux with Hunchentoot 1.0.0 hosting only static files. These files are generated from Dreamweaver, so I put them in a directory named 'static' and configure Hunchentoot like this: (push (hunchentoot:create-folder-dispatcher-and-handler "/" (make-pathname :directory (concatenate 'string *web-path* "/static"))) hunchentoot:*dispatch-table*) ;; (register-static-file "crossdomain.xml") (defun display-home-page () "Display the home page." (hunchentoot:redirect "/index.html")) (push (hunchentoot:create-regex-dispatcher "^/$" 'display-home-page) hunchentoot:*dispatch-table*) I start the server like this: (defparameter hunchentoot:*message-log-pathname* "/tmp/hunchentoot-message.log") (defparameter hunchentoot:*access-log-pathname* "/tmp/hunchentoot-access.log") (defparameter *web-acceptor* (make-instance 'hunchentoot:acceptor :port 8080)) (hunchentoot:start *web-acceptor*) This works for a random amount of time, then I get errors like this in the Hunchentoot message log: [2009-09-13 15:35:16 [ERROR]] Error while processing connection: Input timeout o n # [2009-09-13 15:35:16 [ERROR]] Error while processing connection: Input timeout o n # [2009-09-13 15:35:16 [ERROR]] Error while processing connection: Input timeout o n # And this in the output log (I'm running via detachtty, if that makes a difference): Welcome to Clozure Common Lisp Version 1.3-r12755M (LinuxX8664)! ? STRING-OUTPUT-STREAM #x300041A9E7CD> is not of the expected type STRUCTURE.# is not of the expected type ST RUCTURE.Error: is not of the expected type STRUCTURE. > Error: value # is not of the expected ty pe STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK > Error: value # is not of the expected ty pe STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK > Error: value # is not of the expected ty pe STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in process Hunchent oot worker (client: 67.86.101.207:62566)(28). , in process Hunchentoot worker (client: 67.86.101.207:62564)(26). , in process Hunchentoot listener (*:8080)(3). > Error: value # is not of the expected type STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in process Hunchentoot worker (client: 67.86.101.207:62567)(29). ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 3) to yield control to this thread. ;;; When I connect with attachtty and yield control to thread 3, I get this: (:y 3) ;;; ;;; Shared Terminal Input is now owned by # ;;; > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :r > Type (:C ) to invoke one of the following restarts: 0. Return to break level 1. 1. # 2. Reset this thread 3. Kill this thread 1 > :b *(7FC398197CC0) : 0 (CREATE-STRING-OUTPUT-STREAM-IOBLOCK :STREAM # :STRING "" :ELEMENT-TYPE CHARACTER :WRITE-CHAR- FUNCTION CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR :WRITE-CHAR-WHEN- LOCKED-FU NCTION CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR :WRITE-SIMPLE- STRING-FUNCTIO N CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-SIMPLE-STRING :FORCE-OUTPUT- FUNCTION # :CLOSE-FUNCTION #) 236 (7FC398197D50) : 1 (%%MAKE-STRING-OUTPUT-STREAM # "" CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR CCL::STRING- OUTPUT-STREA M-IOBLOCK-WRITE-SIMPLE-STRING) 269 . . . (7FC39824ADA8) : 7733 (FUNCALL #'#<#> # #) 181 (7FC39824ADD0) : 7734 (FUNCALL #'#<#> #) 1061 (7FC39824AE70) : 7735 (FUNCALL #'#<(:INTERNAL BORDEAUX- THREADS::BINDING-DEFAULT -SPECIALS)>) 805 (7FC39824AEB8) : 7736 (RUN-PROCESS-INITIAL-FORM # (#)) 717 (7FC39824AF48) : 7737 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET- INTERNAL)> # (#)) 389 (7FC39824AF98) : 7738 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE- STARTUP-FUNCTION )>) 301 1 > The full backtrace is available at http://www.softwarematters.org/ccl64-dribble.gz . Is this a Clozure or Hunchentoot issue? Thanks, Patrick From patrick.may at mac.com Tue Sep 15 22:25:41 2009 From: patrick.may at mac.com (Patrick May) Date: Tue, 15 Sep 2009 18:25:41 -0400 Subject: [hunchentoot-devel] invalid initarg error Message-ID: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> I'm running the latest version of Hunchentoot available from bknr.net in Clozure CL on a 64-bit Linux box. I see this error in the logs occasionally: [2009-09-15 19:44:49 [ERROR]] Error while processing connection: :REAL- ERROR is an invalid initarg to INITIALIZE-INSTANCE for #. Valid initargs: (:SOCKET). From poking around in the source it appears that this is only called in the usocket package. The site doesn't appear affected. Is this a known issue? Thanks, Patrick From edi at agharta.de Wed Sep 16 07:00:32 2009 From: edi at agharta.de (Edi Weitz) Date: Wed, 16 Sep 2009 09:00:32 +0200 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Wed, Sep 16, 2009 at 12:25 AM, Patrick May wrote: > ? ? ? ?I'm running the latest version of Hunchentoot available from bknr.net > in Clozure CL on a 64-bit Linux box. ?I see this error in the logs > occasionally: > > [2009-09-15 19:44:49 [ERROR]] Error while processing connection: :REAL- > ERROR is an invalid initarg to INITIALIZE-INSTANCE for # CLASS USOCKET:TIMEOUT-ERROR>. > Valid initargs: (:SOCKET). > > ?From poking around in the source it appears that this is only called > in the usocket package. ?The site doesn't appear affected. ?Is this a > known issue? Looks like a problem with usocket. Which versions of CCL and usocket are you using exactly? Are they the newest ones? Thanks, Edi. From patrick.may at mac.com Wed Sep 16 11:22:44 2009 From: patrick.may at mac.com (Patrick May) Date: Wed, 16 Sep 2009 07:22:44 -0400 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Sep 16, 2009, at 3:00 AM, Edi Weitz wrote: > On Wed, Sep 16, 2009 at 12:25 AM, Patrick May > wrote: >> I'm running the latest version of Hunchentoot available from bknr.net >> in Clozure CL on a 64-bit Linux box. I see this error in the logs >> occasionally: >> >> [2009-09-15 19:44:49 [ERROR]] Error while processing >> connection: :REAL- >> ERROR is an invalid initarg to INITIALIZE-INSTANCE for #> CLASS USOCKET:TIMEOUT-ERROR>. >> Valid initargs: (:SOCKET). >> >> From poking around in the source it appears that this is only called >> in the usocket package. The site doesn't appear affected. Is this a >> known issue? > > Looks like a problem with usocket. Which versions of CCL and usocket > are you using exactly? Are they the newest ones? I'm using CCL 1.3-r12755M and the version of usocket fro the bknr.net Subversion repository. Thanks, Patrick From edi at agharta.de Thu Sep 17 06:44:46 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 17 Sep 2009 08:44:46 +0200 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Wed, Sep 16, 2009 at 1:22 PM, Patrick May wrote: >> Looks like a problem with usocket. ?Which versions of CCL and usocket >> are you using exactly? ?Are they the newest ones? > > ? ? ? ?I'm using CCL 1.3-r12755M and the version of usocket fro the bknr.net > Subversion repository. I just talked to Hans who is not at home right now. He thinks he found the problem and will fix it when he's back. Edi. From hans.huebner at gmail.com Thu Sep 17 07:02:33 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 17 Sep 2009 10:02:33 +0300 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: I have committed the fix to this problem both to the usocket trunk and the bknr repositories. Thanks for reporting! -Hans On Thu, Sep 17, 2009 at 09:44, Edi Weitz wrote: > On Wed, Sep 16, 2009 at 1:22 PM, Patrick May wrote: > >>> Looks like a problem with usocket. ?Which versions of CCL and usocket >>> are you using exactly? ?Are they the newest ones? >> >> ? ? ? ?I'm using CCL 1.3-r12755M and the version of usocket fro the bknr.net >> Subversion repository. > > I just talked to Hans who is not at home right now. ?He thinks he > found the problem and will fix it when he's back. > > Edi. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From patrick.may at mac.com Thu Sep 17 11:05:31 2009 From: patrick.may at mac.com (Patrick May) Date: Thu, 17 Sep 2009 07:05:31 -0400 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Sep 17, 2009, at 3:02 AM, Hans H?bner wrote: > I have committed the fix to this problem both to the usocket trunk and > the bknr repositories. Thanks for reporting! Thanks for the incredibly fast fix! Regards, Patrick From patrick.may at mac.com Fri Sep 18 14:18:18 2009 From: patrick.may at mac.com (Patrick May) Date: Fri, 18 Sep 2009 10:18:18 -0400 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Sep 17, 2009, at 7:05 AM, Patrick May wrote: > On Sep 17, 2009, at 3:02 AM, Hans H?bner wrote: >> I have committed the fix to this problem both to the usocket trunk >> and >> the bknr repositories. Thanks for reporting! > > Thanks for the incredibly fast fix! I just updated from the bknr Subversion repository and started getting errors immediately when serving static content. The error messages are below, but when I reverted to revision 499 of the repository, the problem went away. Please let me know if there is any other debugging I can help with. Welcome to Clozure Common Lisp Version 1.3-r12755M (LinuxX8664)! ? > Error: STRUCTURE.STRING-OUTPUT-STREAM #x300041ECCB4D> is not of the expected type STRUCTURE.300041ECCB4D> is not of the expected type STRUCTURE.> Error: > Error: value # is not of the expected type STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK > Error: value # is not of the expected type STRUCTURE. > Error: value # is not of the expected type STRUCTURE.> While executing: RING-OUTPUT-STREAM #x3000419AB0ED> is not of the expected type STRUCTURE. > While executing: > While executing: CCL::CREATE-STRING-OUTPUT- STREAM-IOBLOCK, in process Hunchentoot worker (client: 67.86.101.207:57187)(13). , in process Hunchentoot worker (client: 67.86.101.207:57186) (12).CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in process Hunchentoot worker (cl, in process Hunchentoot worker (client: 67.86.101.207:57188) (14). > Error: value # is not of the expected type STRUCTURE. > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in process Hunchentoot worker (client: 67.86.101.207:57189)(16). ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 13) to yield control to this thread. ;;; ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 12) to yield control to this thread. ;;; ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 16) to yield control to this thread. ;;; ;;; ;;; # requires access to Shared Terminal Input ;;; Type (:y 14) to yield control to this thread. ;;; Attaching with attachtty and getting a backtrace gives: (:y 13) ;;; ;;; Shared Terminal Input is now owned by # ;;; > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > b *(7F09B788BB80) : 0 (CREATE-STRING-OUTPUT-STREAM-IOBLOCK :STREAM # :STRING "" :ELEMENT-TYPE CHARACTER :WRITE-CHAR- FUNCTION CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR :WRITE-CHAR-WHEN- LOCKED-FU NCTION CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR :WRITE-SIMPLE- STRING-FUNCTIO N CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-SIMPLE-STRING :FORCE-OUTPUT- FUNCTION # :CLOSE-FUNCTION #) 236 (7F09B788BC10) : 1 (%%MAKE-STRING-OUTPUT-STREAM # "" CCL::STRING-OUTPUT-STREAM-IOBLOCK-WRITE-CHAR CCL::STRING- OUTPUT-STREA M-IOBLOCK-WRITE-SIMPLE-STRING) 269 (7F09B788BC48) : 2 (XP-OUT-STREAM #) 149 (7F09B788BC68) : 3 (FLUSH #) 45 (7F09B788BC80) : 4 (WRITE-STRING++ "value ~S is not of the expected type ~S." # 39 40) 109 (7F09B788BCB0) : 5 (WRITE-STRING+ "value ~S is not of the expected type ~S." #< CCL::XP-STRUCTURE #x30004297B78D> # 40) 277 (7F09B788BCF8) : 6 (FUNCALL #'#<#> # "value ~S is not of the expected type ~S." 39 40) 245 (7F09B788BD48) : 7 (WRITE-SIMPLE-STRING "value ~S is not of the expected type ~ S." # 39 40) 1477 (7F09B788BD90) : 8 (SUB-FORMAT # 38 40) 2549 (7F09B788BE20) : 9 (DO-SUB-FORMAT #) 157 (7F09B788BE40) : 10 (DO-SUB-FORMAT-1 # (# STRUCTURE)) 221 (7F09B788BEC0) : 11 (DO-XP-PRINTING # # ((#< STRING-OUTPUT-STREAM #x3000419AB0ED> STRUCTURE))) 349 . . . (7F09B794EAC0) : 8398 (READ-LINE* # NIL) 77 (7F09B794EAF8) : 8399 (FUNCALL #'#<(:INTERNAL CHUNGA::READ-HEADER- LINE CHUNGA:READ-HTTP-HEADERS)>) 173 (7F09B794EB60) : 8400 (READ-HTTP-HEADERS # NIL) 205 (7F09B794EBB0) : 8401 (GET-REQUEST-DATA #) 429 (7F09B794EC20) : 8402 (FUNCALL #'#<#> # #) 1069 (7F09B794ECE0) : 8403 (%CALL-NEXT-METHOD (NIL # . 17459963928011)) 1069 (7F09B794ED60) : 8404 (FUNCALL #'#<#> # #) 693 (7F09B794EDF8) : 8405 (%%STANDARD-COMBINED-METHOD-DCODE (# #) 17459963928011) 773 (7F09B794EE70) : 8407 (FUNCALL #'#<(:INTERNAL BORDEAUX- THREADS::BINDING-DEFAULT-SPECIALS)>) 805 (7F09B794EEB8) : 8408 (RUN-PROCESS-INITIAL-FORM # (#)) 717 (7F09B794EF48) : 8409 (FUNCALL #'#<(:INTERNAL CCL::%PROCESS-PRESET- INTERNAL)> # (#)) 389 (7F09B794EF98) : 8410 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE- STARTUP-FUNCTION)>) 301 1 > The full backtrace is available at http://www.softwarematters.org/ccl64-dribble.gz . Thanks, Patrick From archimag at gmail.com Fri Sep 18 17:39:59 2009 From: archimag at gmail.com (Andrey Moskvitin) Date: Fri, 18 Sep 2009 21:39:59 +0400 Subject: [hunchentoot-devel] Hunchentoot on PORT 80 In-Reply-To: <1245393348.16614.13.camel@scatha> References: <1245393348.16614.13.camel@scatha> Message-ID: > So I was wondering if anybody else got this > configuration to work on port 80 and could share their experience with > me please. http://lisper.ru/apps/format/15 - this script starts sbcl-daemon (pure lisp, without GNU Screen, detachtty and etc.), which runs hunchentoot on port 80 after the rejection of root privileges. Required libcap2. Tested on Gentoo and Debian. Andrey 2009/6/19 Phil Marneweck > Hi > > Yesterday I tried to run hunchentoot on port 80 for the first time, but > a get a "Permission Denied" error when hunchentoot tries to bind to port > 80. Between the #ubuntu and #lisp guys we established that nothing else > was running on port 80 and that I was indeed running as root. > > > Everybody agreed that it must be that permissions gets dropped some > where along the line. Searching the web regarding dropped permissions > got me no where. So I was wondering if anybody else got this > configuration to work on port 80 and could share their experience with > me please. > > I have a clean ubuntu server, no apache or anything installed. I have an > in init.d script that starts up a screen session which runs swank and > start up stuff to load hunchentoot etc ie swank-daemon from clwiki. > > > Regards > Phil > > > _______________________________________________ > 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 patrick.may at mac.com Fri Sep 18 18:30:19 2009 From: patrick.may at mac.com (Patrick May) Date: Fri, 18 Sep 2009 14:30:19 -0400 Subject: [hunchentoot-devel] Hunchentoot on PORT 80 In-Reply-To: References: <1245393348.16614.13.camel@scatha> Message-ID: On Sep 18, 2009, at 1:39 PM, Andrey Moskvitin wrote: > > So I was wondering if anybody else got this > > configuration to work on port 80 and could share their experience > with > > me please. > > http://lisper.ru/apps/format/15 - this script starts sbcl-daemon > (pure lisp, without GNU Screen, detachtty and etc.), which runs > hunchentoot on port 80 after the rejection of root privileges. > Required libcap2. Tested on Gentoo and Debian. Another alternative is to use iptables to route requests for port 80 to another port (8080, in my configuration). Here's my /etc/sysconfig/ iptables: # Generated by iptables-save v1.3.5 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to :8080 COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [190:23308] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p esp -j ACCEPT -A RH-Firewall-1-INPUT -p ah -j ACCEPT -A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 - j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 8080 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 4005 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 4242 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT Regards, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Fri Sep 18 23:48:47 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 19 Sep 2009 02:48:47 +0300 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: On Fri, Sep 18, 2009 at 17:18, Patrick May wrote: > ? ? ? ?I just updated from the bknr Subversion repository and started > getting errors immediately when serving static content. ?The error > messages are below, but when I reverted to revision 499 of the > repository, the problem went away. > > ? ? ? ?Please let me know if there is any other debugging I can help with. > > Welcome to Clozure Common Lisp Version 1.3-r12755M ?(LinuxX8664)! > ? > Error: STRUCTURE.STRING-OUTPUT-STREAM ?#x300041ECCB4D> is not of > the expected type > STRUCTURE.300041ECCB4D> is not of the expected type STRUCTURE.> Error: > ?> Error: value # is not of the > expected type STRUCTURE. I fail to believe that my addition of a condition class and removal of two initargs creates the cited problem. Can you make sure that the problem is not related to your environment (i.e. reproduce it in a cleanly checked out environment) and, if the problem persists, provide us with minimal steps to reproduce the problem? Thanks, Hans From patrick.may at mac.com Tue Sep 22 14:07:36 2009 From: patrick.may at mac.com (Patrick May) Date: Tue, 22 Sep 2009 10:07:36 -0400 Subject: [hunchentoot-devel] invalid initarg error In-Reply-To: References: <36CCC4F7-CD27-40D8-AF47-9173C6C822DC@mac.com> Message-ID: <18B9200C-E5B7-4195-A4A5-ACA859C2C084@mac.com> On Sep 18, 2009, at 7:48 PM, Hans H?bner wrote: > On Fri, Sep 18, 2009 at 17:18, Patrick May > wrote: >> I just updated from the bknr Subversion repository and started >> getting errors immediately when serving static content. The error >> messages are below, but when I reverted to revision 499 of the >> repository, the problem went away. >> >> Please let me know if there is any other debugging I can >> help with. >> >> Welcome to Clozure Common Lisp Version 1.3-r12755M (LinuxX8664)! >> ? > Error: STRUCTURE.STRING-OUTPUT-STREAM #x300041ECCB4D> is not of >> the expected type >> STRUCTURE.300041ECCB4D> is not of the expected type STRUCTURE.> >> Error: >> > Error: value # is not of the >> expected type STRUCTURE. > > I fail to believe that my addition of a condition class and removal of > two initargs creates the cited problem. Can you make sure that the > problem is not related to your environment (i.e. reproduce it in a > cleanly checked out environment) and, if the problem persists, provide > us with minimal steps to reproduce the problem? Hans, I cleaned the system, including removing all my asdf-install directories and rebuilt from scratch. It has been up and running for several days now. I suspect the problem was due to different packages in the asdf registry. It was not your code. Thanks again for the help. Regards, Patrick From sebyte at smolny.plus.com Thu Sep 24 10:37:56 2009 From: sebyte at smolny.plus.com (Sebastian Tennant) Date: Thu, 24 Sep 2009 10:37:56 +0000 Subject: [hunchentoot-devel] Constructing development and production environments Message-ID: Hi all, I'd like to instantiate two acceptors that use the standard log functions (LOG-MESSAGE-TO-FILE & LOG-ACCESS-TO-FILE) but with different values of *access-log-pathname* and *message-log-pathname* for each acceptor. One way is to define two (cloned) log functions with hardcoded pathnames and pass these log functions to MAKE-INSTANCE when instantiating each acceptor, but I'm wondering if there isn't a better (more Lispy) way to do it? I'd also welcome any advice/tips/pointers/suggestions people may have regarding how best to construct development and production environments within a single Hunchentoot process. Unfortunately my server is very low-powered and I don't have the resources to run two Hunchentoot processes. Regards, Sebastian -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap From ndj at bitart.cc Wed Sep 30 17:24:31 2009 From: ndj at bitart.cc (Nico de Jager) Date: Wed, 30 Sep 2009 19:24:31 +0200 Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta Message-ID: <873a64ny5s.fsf@galileo.bitart.cc> $ diff -u lispworks.lisp_orig lispworks.lisp_patched --- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200 +++ lispworks.lisp_patched 2009-09-30 19:06:22.118317238 +0200 @@ -90,14 +90,14 @@ (defun make-socket-stream (socket acceptor) "Returns a stream for the socket SOCKET. The ACCEPTOR argument is used to set the timeouts." - #-:lispworks5 + #+:lispworks4 (when (acceptor-write-timeout acceptor) (parameter-error "You need LispWorks 5 or higher for write timeouts.")) (make-instance 'comm:socket-stream :socket socket :direction :io :read-timeout (acceptor-read-timeout acceptor) - #+:lispworks5 #+:lispworks5 + #-:lispworks4 :write-timeout (acceptor-write-timeout acceptor) :element-type 'octet)) From hans.huebner at gmail.com Wed Sep 30 23:04:54 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 30 Sep 2009 16:04:54 -0700 Subject: [hunchentoot-devel] Small patch for LispWorks 6 beta In-Reply-To: <873a64ny5s.fsf@galileo.bitart.cc> References: <873a64ny5s.fsf@galileo.bitart.cc> Message-ID: The patch does not look as if it worked for the Lispworks 4 case. Is LW 4 still in use? It might be sensible to remove support for it instead, but that'd be basically Edi's call. -Hans On Wed, Sep 30, 2009 at 10:24, Nico de Jager wrote: > $ diff -u lispworks.lisp_orig lispworks.lisp_patched > --- lispworks.lisp_orig 2009-09-30 11:42:22.000000000 +0200 > +++ lispworks.lisp_patched ? ? ?2009-09-30 19:06:22.118317238 +0200 > @@ -90,14 +90,14 @@ > ?(defun make-socket-stream (socket acceptor) > ? "Returns a stream for the socket SOCKET. ?The ACCEPTOR argument is > ?used to set the timeouts." > - ?#-:lispworks5 > + ?#+:lispworks4 > ? (when (acceptor-write-timeout acceptor) > ? ? (parameter-error "You need LispWorks 5 or higher for write timeouts.")) > ? (make-instance 'comm:socket-stream > ? ? ? ? ? ? ? ? ?:socket socket > ? ? ? ? ? ? ? ? ?:direction :io > ? ? ? ? ? ? ? ? ?:read-timeout (acceptor-read-timeout acceptor) > - ? ? ? ? ? ? ? ? #+:lispworks5 #+:lispworks5 > + ? ? ? ? ? ? ? ? #-:lispworks4 > ? ? ? ? ? ? ? ? ?:write-timeout (acceptor-write-timeout acceptor) > ? ? ? ? ? ? ? ? ?:element-type 'octet)) > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel >