From rsynnott at gmail.com Mon Sep 4 00:09:10 2006 From: rsynnott at gmail.com (Robert Synnott) Date: Mon, 4 Sep 2006 01:09:10 +0100 Subject: [tbnl-devel] Slow connection with CMUCL? Message-ID: <24f203480609031709i17172648s49d46bd61dff99c0@mail.gmail.com> Hi, Running under CMUCL, it seems to take about half a second for the browser to get a connection to the tbnl-served site. If going through mod_lisp, this pause turns up for the first few requests, then vanishes. There doesn't seem to be a similar pause using SBCL or OpenMCL. Any ideas? Rob From edi at agharta.de Mon Sep 4 06:18:25 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Sep 2006 08:18:25 +0200 Subject: [tbnl-devel] Slow connection with CMUCL? In-Reply-To: <24f203480609031709i17172648s49d46bd61dff99c0@mail.gmail.com> (Robert Synnott's message of "Mon, 4 Sep 2006 01:09:10 +0100") References: <24f203480609031709i17172648s49d46bd61dff99c0@mail.gmail.com> Message-ID: On Mon, 4 Sep 2006 01:09:10 +0100, "Robert Synnott" wrote: > Running under CMUCL, it seems to take about half a second for the > browser to get a connection to the tbnl-served site. If going > through mod_lisp, this pause turns up for the first few requests, > then vanishes. There doesn't seem to be a similar pause using SBCL > or OpenMCL. Any ideas? Yes, that's an FAQ and not related to TBNL but to CMUCL's MP implementation. See for example here: http://mcclim.cliki.net/Tip [Section "Multiprocessing with CMUCL"] http://common-lisp.net/pipermail/tbnl-devel/2005-October/000465.html Cheers, Edi. From ccalca at essex.ac.uk Mon Sep 4 17:50:12 2006 From: ccalca at essex.ac.uk (Xristos Kalkanis) Date: Mon, 4 Sep 2006 18:50:12 +0100 Subject: [tbnl-devel] TBNL/SBCL 0.9.16 problems Message-ID: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> I encountered the following problems with latest TBNL (0.10.1) under sbcl 0.9.16: ; file: /Users/xristos/.sbcl/site/tbnl-0.10.1/easy-handlers.lisp ; in: DEFUN COMPUTE-ARRAY-PARAMETER ; (CL-PPCRE:REGISTER-GROUPS-BIND ; (TBNL::NAME TBNL::INDEX-STRING) ; ("^(.*)\\[(\\d+)\\]$" TBNL::FULL-NAME) ; (WHEN ; (STRING= TBNL::NAME TBNL::PARAMETER-NAME) ; (PARSE-INTEGER TBNL::INDEX-STRING))) ; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF ; --> PROGN LET* LET IF ; ==> ; NIL ; ; caught WARNING: ; This is not a STRING: ; NIL This stops compilation and throws me in the debugger where the only option i have in order to continue compilation is to accept the operation as completed. Result: easy-handler test example does not work properly (blank page). This happens under both linux and osx. ----- decoding error on stream # (:EXTERNAL-FORMAT :UTF-8): the octet sequence (233 34 10) cannot be decoded. [Condition of type SB-INT:STREAM-DECODING-ERROR] This happens only on osx. #lisp regulars informed me that default locale on osx is utf-8 and since test.lisp contains invalid character according to utf-8, it cant be read properly. Compiles ok on linux with posix locale. ----- TBNL/Kmrcl still hangs approx 50% of the time when serving requests (both linux & osx). The solution is to use (close socket) instead of (sb-bsd-sockets:socket-close socket) in function close-active-socket in latest kmrcl (sockets.lisp line 118). I'd really like to see this fixed. ----- File uploads using the upload example do not work under osx. This is most probably related to utf-8 issues as certain text files are uploaded correctly whilst binaries are not. Uploads work ok under linux. From edi at agharta.de Mon Sep 4 19:05:56 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 04 Sep 2006 21:05:56 +0200 Subject: [tbnl-devel] TBNL/SBCL 0.9.16 problems In-Reply-To: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> (Xristos Kalkanis's message of "Mon, 4 Sep 2006 18:50:12 +0100") References: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> Message-ID: Hi! On Mon, 4 Sep 2006 18:50:12 +0100, Xristos Kalkanis wrote: > I encountered the following problems with > latest TBNL (0.10.1) under sbcl 0.9.16: > > ; file: /Users/xristos/.sbcl/site/tbnl-0.10.1/easy-handlers.lisp > ; in: DEFUN COMPUTE-ARRAY-PARAMETER > ; (CL-PPCRE:REGISTER-GROUPS-BIND > ; (TBNL::NAME TBNL::INDEX-STRING) > ; ("^(.*)\\[(\\d+)\\]$" TBNL::FULL-NAME) > ; (WHEN > ; (STRING= TBNL::NAME TBNL::PARAMETER-NAME) > ; (PARSE-INTEGER TBNL::INDEX-STRING))) > ; --> LET MULTIPLE-VALUE-BIND MULTIPLE-VALUE-CALL FUNCTION WHEN COND IF > ; --> PROGN LET* LET IF > ; ==> > ; NIL > ; > ; caught WARNING: > ; This is not a STRING: > ; NIL > > This stops compilation and throws me in the debugger where the only > option i have in order to continue compilation is to accept the > operation as completed. Result: easy-handler test example does not > work properly (blank page). This happens under both linux and osx. Hmm, SBCL's error message is not very helpful, I'm afraid. My /guess/ is that it looks at the macro-expansion of REGISTER-GROUPS-BIND and infers that NAME or INDEX-STRING could in theory be NIL and thus aren't valid arguments for STRING= or PARSE-INTEGER. However, in this particular case it is perfectly clear that his won't happen - the body of the macro will only be executed if there's a match; and if there's a match, then all registers will match as well. I'd propose that you ask the SBCL experts if my guess is right and if so how one can convince the compiler to be a bit less overzealous. > decoding error on stream > # "file /Users/xristos/.sbcl/site/tbnl-0.10.1/test/test.lisp" {13F903C9}> > (:EXTERNAL-FORMAT :UTF-8): > the octet sequence (233 34 10) cannot be decoded. > [Condition of type SB-INT:STREAM-DECODING-ERROR] > > This happens only on osx. #lisp regulars informed me that default > locale on osx is utf-8 and since test.lisp contains invalid > character according to utf-8, it cant be read properly. Compiles ok > on linux with posix locale. Ah, Pel?... :) Well, before SBCL came up with Unicode support, it was perfectly fine to use ISO-8859-1 files. Now, everybody has to change their code in order to appease their compiler - sigh. I'll change that in the next release. > TBNL/Kmrcl still hangs approx 50% of the time when serving requests > (both linux & osx). The solution is to use (close socket) instead of > (sb-bsd-sockets:socket-close socket) in function close-active-socket > in latest kmrcl (sockets.lisp line 118). I'd really like to see this > fixed. Then you should probably contact KMRCL's author. I think that's the most likely way to get it changed. Thanks for the report. Cheers, Edi. From rsynnott at gmail.com Mon Sep 4 20:41:30 2006 From: rsynnott at gmail.com (Robert Synnott) Date: Mon, 4 Sep 2006 21:41:30 +0100 Subject: [tbnl-devel] Slow connection with CMUCL? In-Reply-To: References: <24f203480609031709i17172648s49d46bd61dff99c0@mail.gmail.com> Message-ID: <24f203480609041341kd5e32a9sc49d0377ec4c1c6b@mail.gmail.com> On 9/4/06, Edi Weitz wrote: > On Mon, 4 Sep 2006 01:09:10 +0100, "Robert Synnott" wrote: > > > > > Yes, that's an FAQ and not related to TBNL but to CMUCL's MP > implementation. See for example here: > > http://mcclim.cliki.net/Tip > [Section "Multiprocessing with CMUCL"] > > http://common-lisp.net/pipermail/tbnl-devel/2005-October/000465.html > > Cheers, > Edi. > Yep, just after posting this I found a reference in the mailing list archive. I should have looked harder before posting, I suppose. Working great now :) Rob. From edi at agharta.de Mon Sep 4 23:01:26 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 05 Sep 2006 01:01:26 +0200 Subject: [tbnl-devel] New versions 0.10.2 (TBNL) and 0.3.0 (Hunchentoot) Message-ID: TBNL: ----- ChangeLog: Version 0.10.2 2006-09-05 Better reporting of IP addresses and ports if not behind mod_lisp Improved logging Fixed REAL-REMOTE-ADDR Cookies always use UTF-8 encoding (which is opaque to the client anyway) Read request bodies without 'Content-Length' header (for Hunchentoot) Removed accented character from test.lisp to appease SBCL (reported by Xristos Kalkanis) Download: http://weitz.de/files/tbnl.tar.gz Hunchentoot: ------------ ChangeLog: Version 0.3.0 2006-09-05 Accept HTTP requests with chunked transfer encoding Use Chunga for chunking Download: http://weitz.de/files/hunchentoot.tar.gz Cheers, Edi. From erik.enge at gmail.com Tue Sep 5 02:55:03 2006 From: erik.enge at gmail.com (Erik Enge) Date: Mon, 4 Sep 2006 22:55:03 -0400 Subject: [tbnl-devel] TBNL/SBCL 0.9.16 problems In-Reply-To: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> References: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> Message-ID: <58f839b70609041955l1430223em14b5df47dc8a137@mail.gmail.com> On 9/4/06, Xristos Kalkanis wrote: > TBNL/Kmrcl still hangs approx 50% of the time when serving requests > (both linux & osx). The solution is to use (close socket) instead of > (sb-bsd-sockets:socket-close socket) in function > close-active-socket in latest kmrcl (sockets.lisp line 118). I'd really > like to see this fixed. Really? How can I reproduce this on my Linux, SBCL, TBNL and kmrcl system? Erik. From edi at agharta.de Tue Sep 5 12:49:21 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 05 Sep 2006 14:49:21 +0200 Subject: [tbnl-devel] TBNL survey / re-org Message-ID: Hi! I'm thinking about re-organizing/purifying the TBNL code-base. It looks pretty messy to me now and I think I could get rid of a couple of things if I find the time. Before I do that, I'd need some info about current usage patterns. My impression is that TBNL is used with these implementations LispWorks SBCL CMUCL OpenMCL and usually behind mod_lisp or stand-alone. Is that right? Does anybody still use TBNL with Araneida? Does anybody use it with AllegroCL or some other Lisp I haven't listed above? Would people be interested in something like Hunchentoot for non-LispWorks Lisps? Thanks, Edi. From erik.enge at gmail.com Tue Sep 5 13:07:52 2006 From: erik.enge at gmail.com (Erik Enge) Date: Tue, 5 Sep 2006 09:07:52 -0400 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <58f839b70609050607n34dd9a18vdc13b102ad907cc3@mail.gmail.com> On 9/5/06, Edi Weitz wrote: > SBCL This is what I use. > and usually behind mod_lisp or stand-alone. I use mod_lisp. > Would people be interested in something like Hunchentoot > for non-LispWorks Lisps? I wouldn't. Thanks, Erik. From emailmac at gmail.com Tue Sep 5 15:01:50 2006 From: emailmac at gmail.com (Mac Chan) Date: Tue, 5 Sep 2006 08:01:50 -0700 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <4877ae640609050801h72cd2c0dxe87257d10ba42ff4@mail.gmail.com> lispworks 4.4.6 / 5.0 on win32, apache 2 + modlisp On 9/5/06, Edi Weitz wrote: > Hi! > > I'm thinking about re-organizing/purifying the TBNL code-base. It > looks pretty messy to me now and I think I could get rid of a couple > of things if I find the time. > > Before I do that, I'd need some info about current usage patterns. My > impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? Does > anybody still use TBNL with Araneida? Does anybody use it with > AllegroCL or some other Lisp I haven't listed above? Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? > > Thanks, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From erick at fsl.org.mx Tue Sep 5 16:03:00 2006 From: erick at fsl.org.mx (Erick Ivaan Lopez Carreon) Date: Tue, 05 Sep 2006 11:03:00 -0500 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <1157472180.3835.31.camel@localhost.localdomain> On Tue, 2006-09-05 at 14:49 +0200, Edi Weitz wrote: > Before I do that, I'd need some info about current usage patterns. My > impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? SBCL on Debian GNU/Linux, apache2 + mod_lisp2 > Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? > I'm interested Thanks. -- Erick Ivaan Lopez Carreon -- erick at fsl.org.mx PGP Key 1024D/9741C03A 2004-11-19 Key fingerprint = 1764 3C6F B433 B2DD 9029 98B1 8E6B 58D3 9741 C03A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ocorrain at yahoo.com Tue Sep 5 16:26:09 2006 From: ocorrain at yahoo.com (Tiarnan O'Corrain) Date: Tue, 5 Sep 2006 09:26:09 -0700 (PDT) Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <4877ae640609050801h72cd2c0dxe87257d10ba42ff4@mail.gmail.com> Message-ID: <20060905162609.99329.qmail@web33307.mail.mud.yahoo.com> Hi-- OpenMCL / Mac OS X + modlisp + apache 1 CMUCL / FreeBSD + modlisp + apache 2 >> Would people be > > interested in something like Hunchentoot for non-LispWorks Lisps? Why not? Tiarnan From rsynnott at gmail.com Tue Sep 5 16:32:35 2006 From: rsynnott at gmail.com (Robert Synnott) Date: Tue, 5 Sep 2006 17:32:35 +0100 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <24f203480609050932v24b57c9bkeb280d3481a5b318@mail.gmail.com> On 9/5/06, Edi Weitz wrote: > Hi! > > I'm thinking about re-organizing/purifying the TBNL code-base. It > looks pretty messy to me now and I think I could get rid of a couple > of things if I find the time. > > Before I do that, I'd need some info about current usage patterns. My > impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? OpenMCL and standalone for dev, CMUCL and mod_lisp for deployment. > Does > anybody still use TBNL with Araneida? Does anybody use it with > AllegroCL or some other Lisp I haven't listed above? Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? > Not really. > Thanks, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From ignas.mikalajunas at gmail.com Tue Sep 5 15:50:54 2006 From: ignas.mikalajunas at gmail.com (Ignas Mikalajunas) Date: Tue, 5 Sep 2006 18:50:54 +0300 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <4877ae640609050801h72cd2c0dxe87257d10ba42ff4@mail.gmail.com> References: <4877ae640609050801h72cd2c0dxe87257d10ba42ff4@mail.gmail.com> Message-ID: SBCL on Ubuntu Dapper Linux, standalone for development, apache 2 + mod_lisp for deployment. Ignas From phillip.m.jordan at gmail.com Tue Sep 5 16:28:11 2006 From: phillip.m.jordan at gmail.com (Phillip Jordan) Date: Tue, 5 Sep 2006 17:28:11 +0100 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <4dc0430c0609050928n5012d896ya467f398aec202c3@mail.gmail.com> I'm running TBNL on CMUCL/Linux behind mod_lisp2. On 05/09/06, Edi Weitz wrote: > Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? I'm certainly interested. ~phil From ccalca at essex.ac.uk Tue Sep 5 17:27:49 2006 From: ccalca at essex.ac.uk (Xristos Kalkanis) Date: Tue, 5 Sep 2006 18:27:49 +0100 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <8B0A573E-BB27-4E63-B360-771C2D3F6B20@essex.ac.uk> SBCL Linux & OSX standalone for development I'd be very interested in Hunchentoot for SBCL. From jsnell at iki.fi Tue Sep 5 17:37:44 2006 From: jsnell at iki.fi (Juho Snellman) Date: Tue, 5 Sep 2006 17:37:44 +0000 (UTC) Subject: [tbnl-devel] Re: TBNL/SBCL 0.9.16 problems References: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> Message-ID: wrote: > Hmm, SBCL's error message is not very helpful, I'm afraid. My /guess/ > is that it looks at the macro-expansion of REGISTER-GROUPS-BIND and > infers that NAME or INDEX-STRING could in theory be NIL and thus > aren't valid arguments for STRING= or PARSE-INTEGER. However, in this > particular case it is perfectly clear that his won't happen - the body > of the macro will only be executed if there's a match; and if there's > a match, then all registers will match as well. > > I'd propose that you ask the SBCL experts if my guess is right and if > so how one can convince the compiler to be a bit less overzealous. That guess is right. A couple of ways to decrease the zeal: * Just muffle the warning by adding the following declaration at the start of the function: #+sbcl (declare (sb-ext:muffle-conditions warning)) * Ensure that the compiler also knows that it really can't happen by replacing: (when (string= name parameter-name) (parse-integer index-string)) With: (when (and (string= name parameter-name) index-string) (parse-integer index-string)) -- Juho Snellman From tobia.conforto at linux.it Tue Sep 5 18:07:02 2006 From: tobia.conforto at linux.it (Toby) Date: Tue, 5 Sep 2006 20:07:02 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: <24f203480609050932v24b57c9bkeb280d3481a5b318@mail.gmail.com> Message-ID: <20060905180702.GS30171@localhost.localdomain> Edi Weitz wrote: > My impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? Yes. SBCL/standalone + SBCL/mod_lisp2/apache2/Debian > Would people be interested in something like Hunchentoot for > non-LispWorks Lisps? I'm not sure what the advantages and disadvantages of such a solution would be. Toby -- Pascal is for building pyramids?imposing, breathtaking structures built by armies pushing heavy blocks into place. Lisp is for building organisms . . . ?Alan Perlis From rsi at panix.com Tue Sep 5 18:02:11 2006 From: rsi at panix.com (Rajappa Iyer) Date: Tue, 05 Sep 2006 11:02:11 -0700 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: (Edi Weitz's message of "Tue, 05 Sep 2006 14:49:21 +0200") References: Message-ID: <86irk28a58.fsf@panix.com> Edi Weitz writes: > Hi! > > I'm thinking about re-organizing/purifying the TBNL code-base. It > looks pretty messy to me now and I think I could get rid of a couple > of things if I find the time. > > Before I do that, I'd need some info about current usage patterns. My > impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? Does > anybody still use TBNL with Araneida? Does anybody use it with > AllegroCL or some other Lisp I haven't listed above? Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? I use TBNL with SBCL and CMUCL on FreeBSD and Debian with mod_lisp2. Would sure be interested in Huchentoot for SBCL and CMUCL. Thanks, Rajappa -- a.k.a. Rajappa Iyer. Absinthe makes the tart grow fonder. From edi at agharta.de Tue Sep 5 18:42:35 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 05 Sep 2006 20:42:35 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <20060905180702.GS30171@localhost.localdomain> (Toby's message of "Tue, 5 Sep 2006 20:07:02 +0200") References: <24f203480609050932v24b57c9bkeb280d3481a5b318@mail.gmail.com> <20060905180702.GS30171@localhost.localdomain> Message-ID: On Tue, 5 Sep 2006 20:07:02 +0200, Toby wrote: > Edi Weitz wrote: > >> Would people be interested in something like Hunchentoot for >> non-LispWorks Lisps? > > I'm not sure what the advantages and disadvantages of such a > solution would be. It's a pure Lisp solution (like AllegroServe), no Apache or any other external program involved. It's like the "stand-alone" version of TBNL, but with features that a "real" web server should have - like chunked encoding, persistent connections, or SSL. (That's the part Apache does for you if you use mod_lisp.) http://weitz.de/hunchentoot/ Cheers, Edi. From edi at agharta.de Tue Sep 5 19:33:35 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 05 Sep 2006 21:33:35 +0200 Subject: [tbnl-devel] New version 0.10.3 (Was: TBNL/SBCL 0.9.16 problems) In-Reply-To: (Juho Snellman's message of "Tue, 5 Sep 2006 17:37:44 +0000 (UTC)") References: <794ADCC8-1DC1-466B-9CBC-075996A86549@essex.ac.uk> Message-ID: On Tue, 5 Sep 2006 17:37:44 +0000 (UTC), Juho Snellman wrote: > * Just muffle the warning by adding the following declaration at > the start of the function: > > #+sbcl (declare (sb-ext:muffle-conditions warning)) Thanks. I've added that and made a new release. > * Ensure that the compiler also knows that it really can't happen > by replacing: > > (when (string= name parameter-name) > (parse-integer index-string)) > > With: > > (when (and (string= name parameter-name) > index-string) > (parse-integer index-string)) Adding something to otherwise correct code just to appease the compiler feels a bit like static typing to me - I'd rather not do that... :) Yeah, I know, it's only a friendly warning, but at least it stops ASDF compilation. Thanks, Edi. From hutch at recursive.ca Tue Sep 5 20:44:18 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Tue, 5 Sep 2006 16:44:18 -0400 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <89ECE898-725D-4817-8DA0-DC5FCAE13E31@recursive.ca> On Sep 5, 2006, at 8:49 AM, Edi Weitz wrote: > Hi! > > I'm thinking about re-organizing/purifying the TBNL code-base. It > looks pretty messy to me now and I think I could get rid of a couple > of things if I find the time. > > Before I do that, I'd need some info about current usage patterns. My > impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL > OpenMCL LispWorks on OS X and linux, perhaps SBCL on the same platforms at some point. > > and usually behind mod_lisp or stand-alone. ProxyPass/ProxyPassReverse behind Apache 1.something and 2.something, and standalone. > Is that right? Does > anybody still use TBNL with Araneida? Does anybody use it with > AllegroCL or some other Lisp I haven't listed above? Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? If I ever get around to getting my own stuff to work on SBCL then Hunchentoot for SBCL would be nice. Thanks, Bob > > Thanks, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From diesenbacher at gmail.com Tue Sep 5 22:13:55 2006 From: diesenbacher at gmail.com (Otto Diesenbacher) Date: Wed, 06 Sep 2006 00:13:55 +0200 Subject: [tbnl-devel] Re: TBNL survey / re-org References: Message-ID: Edi Weitz writes: > and usually behind mod_lisp or stand-alone. Is that right? Does OpenMCL behind apache 1.3/mod_lisp for development (I love my iBook :) sbcl + apache 2.x/mod_lisp for productive instances. > interested in something like Hunchentoot for non-LispWorks Lisps? a plain lispy way - without apache - would be very interesting! Simply delivering one lisp-image - no need to juggle with apache (1.3 vs 2.X) and mod_lisp... Great! (additionally a replacement for postgres would make dreams come true - waiting for rucksack... :)) > Thanks, > Edi. thanks for tbnl - which brought me to Common Lisp :) -- Otto Diesenbacher mailto:diesenbacher at gmail.com Salzburg, Austria From dan at cambrianhouse.com Wed Sep 6 15:14:41 2006 From: dan at cambrianhouse.com (Daniel Gackle) Date: Wed, 6 Sep 2006 09:14:41 -0600 Subject: [tbnl-devel] Re: TBNL survey / re-org Message-ID: <20060906151516.1E1E074815@spunkymail-a17.dreamhost.com> < Does anybody use it with Allegro CL > We're using TBNL with Allegro, Apache, and mod_lisp. < Would people be interested in something like Hunchentoot for non-LispWorks Lisps? > Yes. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.garcia at gmail.com Thu Sep 7 20:10:22 2006 From: sergio.garcia at gmail.com (Sergio Garcia) Date: Thu, 7 Sep 2006 22:10:22 +0200 Subject: [tbnl-devel] Re: TBNL survey / re-org In-Reply-To: References: Message-ID: <34ec25750609071310xb1fe2e7td7fa6144dc93e901@mail.gmail.com> SBCL/Apache2/mod-lisp2 > Would people be > interested in something like Hunchentoot for non-LispWorks Lisps? > Yes, totally. > Thanks, > Edi. From quasilists at gmail.com Fri Sep 8 09:21:38 2006 From: quasilists at gmail.com (quasi) Date: Fri, 08 Sep 2006 14:51:38 +0530 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: (Edi Weitz's message of "Tue, 05 Sep 2006 14:49:21 +0200") References: Message-ID: <877j0esogt.fsf@agni4.cltp.com> On 5 Sep 2006, Edi Weitz spake thusly: > Hi! > > I'm thinking about re-organizing/purifying the TBNL code-base. It > looks pretty messy to me now and I think I could get rid of a couple > of things if I find the time. > > Before I do that, I'd need some info about current usage patterns. > My impression is that TBNL is used with these implementations > > LispWorks > SBCL > CMUCL I use CMUCL > OpenMCL > > and usually behind mod_lisp or stand-alone. Is that right? Does > anybody still use TBNL with Araneida? Does anybody use it with > AllegroCL or some other Lisp I haven't listed above? Would people > be interested in something like Hunchentoot for non-LispWorks Lisps? CMUCL+mod_lisp+TBNL on a GNU/Linux machine. Is the performance of huchentoot+TBNL better than mod_lisp+TBNL ? Anyway a CL webserver would be interesting. thanks, -- quasi Utopia Unlimited! From edi at agharta.de Fri Sep 8 10:34:54 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 08 Sep 2006 12:34:54 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <877j0esogt.fsf@agni4.cltp.com> (quasi's message of "Fri, 08 Sep 2006 14:51:38 +0530") References: <877j0esogt.fsf@agni4.cltp.com> Message-ID: On Fri, 08 Sep 2006 14:51:38 +0530, quasi wrote: > Is the performance of huchentoot+TBNL better than mod_lisp+TBNL ? Do you have an application where the performance difference would matter? I haven't seen one yet. If you're serving hundreds of users per minute with a Lisp web application, you should probably add it to one of the "success stories" pages. I'm much more interested in correct behaviour and convenience - both mod_lisp and Hunchentoot have always been fast enough for me. Cheers, Edi. From mail at chaitanyagupta.com Sat Sep 9 10:00:58 2006 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Sat, 9 Sep 2006 15:30:58 +0530 Subject: [tbnl-devel] Threads and exceptions Message-ID: Hi, I am using TBNL on CMUCL 19c. If I create a new thread (using #'mp:make-process), what will happen if an exception is signalled (and not handled) in that thread? Will tbnl log the error? And If tbnl:*show-lisp-backtraces-p* it t, will it display the backtrace from that thread? Basically I just want that any error or warning signalled by that thread should be logged by tbnl, and if necessary, the backtrace shown in the browser window. What is the best way to do it? Thanks, Chaitanya From edi at agharta.de Sun Sep 10 20:27:46 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 10 Sep 2006 22:27:46 +0200 Subject: [tbnl-devel] Threads and exceptions In-Reply-To: (Chaitanya Gupta's message of "Sat, 9 Sep 2006 15:30:58 +0530") References: Message-ID: On Sat, 9 Sep 2006 15:30:58 +0530, "Chaitanya Gupta" wrote: > I am using TBNL on CMUCL 19c. If I create a new thread (using > #'mp:make-process), what will happen if an exception is signalled > (and not handled) in that thread? YOU create that thread? Manually? Or are you talking about threads that are created by TBNL? > Will tbnl log the error? And If tbnl:*show-lisp-backtraces-p* it t, > will it display the backtrace from that thread? > > Basically I just want that any error or warning signalled by that > thread should be logged by tbnl, and if necessary, the backtrace > shown in the browser window. What is the best way to do it? Hmm, I think the best way is to just try it. Or to read the documentation. Either I don't unerstand your question correctly or you haven't read the relevant parts of the manual. From edi at agharta.de Sun Sep 10 20:32:14 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 10 Sep 2006 22:32:14 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <878xktpj4c.fsf@agni4.cltp.com> (quasi's message of "Sat, 09 Sep 2006 13:27:39 +0530") References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> Message-ID: [Cc to mailing list] On Sat, 09 Sep 2006 13:27:39 +0530, quasi wrote: > www.cleartrip.com right now runs on CMUCL+TBNL+apache+mod_lisp2. We > have load tested it for up to 1000 concurrent users. It did not > break or leak. The performance was purely a factor of the > computational complexity of the page being displayed. For the front > page, which uses HTML_TEMPLATE, apache serving SSI was only slightly > faster. Excellent performance generally Good... :) > Unfortunately I could not manage to get SBCL to perform anywhere > near what CMUCL could. My shortcomings, mostly, I guess. You might see the difference between "green" threads (CMUCL) and OS threads (SBCL). My guess is that thread creation and/or thread switching is more expensive on SBCL. Maybe your tests amplify this difference? Have you tried with other Lisps which use native threads? From mail at chaitanyagupta.com Mon Sep 11 11:36:21 2006 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Mon, 11 Sep 2006 17:06:21 +0530 Subject: [tbnl-devel] Threads and exceptions In-Reply-To: References: Message-ID: On 9/11/06, Edi Weitz wrote: > On Sat, 9 Sep 2006 15:30:58 +0530, "Chaitanya Gupta" wrote: > > > I am using TBNL on CMUCL 19c. If I create a new thread (using > > #'mp:make-process), what will happen if an exception is signalled > > (and not handled) in that thread? > > YOU create that thread? Manually? Or are you talking about threads > that are created by TBNL? I create that thread manually. What I want is that whenever a request is made to some URL, a string should be returned immediately while processing goes in Lisp. For this I create a new thread using mp:make-process in the handler function, and then this function returns the string. > > > Will tbnl log the error? And If tbnl:*show-lisp-backtraces-p* it t, > > ... > > shown in the browser window. What is the best way to do it? > > Hmm, I think the best way is to just try it. Or to read the > documentation. Either I don't unerstand your question correctly or > you haven't read the relevant parts of the manual. >From what I have seen, TBNL doesn't log any errors for the new thread created. I get a new debugger window in SLIME everytime there's any error in the new thread created. Is there anyway I can make TBNL log these errors too? Thanks, Chaitanya From edi at agharta.de Mon Sep 11 12:50:41 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 11 Sep 2006 14:50:41 +0200 Subject: [tbnl-devel] Threads and exceptions In-Reply-To: (Chaitanya Gupta's message of "Mon, 11 Sep 2006 17:06:21 +0530") References: Message-ID: On Mon, 11 Sep 2006 17:06:21 +0530, "Chaitanya Gupta" wrote: > I create that thread manually. What I want is that whenever a > request is made to some URL, a string should be returned immediately > while processing goes in Lisp. For this I create a new thread using > mp:make-process in the handler function, and then this function > returns the string. Ah, OK, I see. > From what I have seen, TBNL doesn't log any errors for the new > thread created. I get a new debugger window in SLIME everytime > there's any error in the new thread created. Is there anyway I can > make TBNL log these errors too? Not automatically, because the HANDLER-BIND which TBNL wraps around the request handler doesn't extend to other threads. You will have to wrap another HANDLER-BIND around your new thread yourself which might look pretty similar to the one in modlisp.lisp. Cheers, Edi. From mail at chaitanyagupta.com Tue Sep 12 07:48:55 2006 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Tue, 12 Sep 2006 13:18:55 +0530 Subject: [tbnl-devel] Threads and exceptions In-Reply-To: References: Message-ID: <45066667.3090403@chaitanyagupta.com> Edi Weitz wrote: > On Mon, 11 Sep 2006 17:06:21 +0530, "Chaitanya Gupta" wrote: > >> From what I have seen, TBNL doesn't log any errors for the new >> thread created. I get a new debugger window in SLIME everytime >> there's any error in the new thread created. Is there anyway I can >> make TBNL log these errors too? >> > > Not automatically, because the HANDLER-BIND which TBNL wraps around > the request handler doesn't extend to other threads. You will have to > wrap another HANDLER-BIND around your new thread yourself which might > look pretty similar to the one in modlisp.lisp. > Ok, thanks. I will check that out. Chaitanya From quasilists at gmail.com Tue Sep 12 08:54:00 2006 From: quasilists at gmail.com (quasi) Date: Tue, 12 Sep 2006 14:24:00 +0530 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: (Edi Weitz's message of "Sun, 10 Sep 2006 22:32:14 +0200") References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> Message-ID: <87mz95mpnb.fsf@agni4.cltp.com> On 11 Sep 2006, Edi Weitz spake thusly: >> Unfortunately I could not manage to get SBCL to perform anywhere >> near what CMUCL could. My shortcomings, mostly, I guess. > > You might see the difference between "green" threads (CMUCL) and OS > threads (SBCL). My guess is that thread creation and/or thread > switching is more expensive on SBCL. Maybe your tests amplify this > difference? Have you tried with other Lisps which use native > threads? I am in the process of convincing my CTO to purchase Lispworks. But it takes time. In Indian Rupees, the software cost is a little high. I have not used any other lisp which uses native threads. I tried to profile SBCL, but the statistical profiler used to die. I tried asking on #lisp, but I am not an expert lisp programmer and those guys were a bit of "go read up", which I should. I think I will give a shot again when I have more specific questions and understand a bit more. We are using lisp software to connect to Abacus air reservation systems and processing of the data and for all the search logic. The good news is our inhouse software is more than 10x faster than the Java solution purchased from a large software house here and 100x more stable. :) thanks. -- quasi Utopia Unlimited! From edi at agharta.de Tue Sep 12 12:20:02 2006 From: edi at agharta.de (Edi Weitz) Date: Tue, 12 Sep 2006 14:20:02 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <87mz95mpnb.fsf@agni4.cltp.com> (quasi's message of "Tue, 12 Sep 2006 14:24:00 +0530") References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> <87mz95mpnb.fsf@agni4.cltp.com> Message-ID: On Tue, 12 Sep 2006 14:24:00 +0530, quasi wrote: > I am in the process of convincing my CTO to purchase Lispworks. But > it takes time. You can ask LispWorks for a time-limited evaluation copy (which is different from the Personal Edition) which I'm sure they'll be happy to supply. > I tried asking on #lisp, but I am not an expert lisp programmer and > those guys were a bit of "go read up" Well, that's open source software for you... :) > We are using lisp software to connect to Abacus air reservation > systems and processing of the data and for all the search logic. > The good news is our inhouse software is more than 10x faster than > the Java solution purchased from a large software house here and > 100x more stable. Great! Cheers, Edi. From rsynnott at gmail.com Tue Sep 12 12:57:46 2006 From: rsynnott at gmail.com (Robert Synnott) Date: Tue, 12 Sep 2006 13:57:46 +0100 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> <87mz95mpnb.fsf@agni4.cltp.com> Message-ID: <24f203480609120557x25abc9ffs6bc501fe02d2d5e0@mail.gmail.com> On 9/12/06, Edi Weitz wrote: > On Tue, 12 Sep 2006 14:24:00 +0530, quasi wrote: > > > > We are using lisp software to connect to Abacus air reservation > > systems and processing of the data and for all the search logic. > > The good news is our inhouse software is more than 10x faster than > > the Java solution purchased from a large software house here and > > 100x more stable. > I'd just like to echo this, actually; I'm completely amazed at the speed of applications, especially non-db-backed applications, written in tbnl. It's a great library. Rob From hutch at recursive.ca Wed Sep 13 12:46:46 2006 From: hutch at recursive.ca (Bob Hutchison) Date: Wed, 13 Sep 2006 08:46:46 -0400 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <24f203480609120557x25abc9ffs6bc501fe02d2d5e0@mail.gmail.com> References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> <87mz95mpnb.fsf@agni4.cltp.com> <24f203480609120557x25abc9ffs6bc501fe02d2d5e0@mail.gmail.com> Message-ID: On Sep 12, 2006, at 8:57 AM, Robert Synnott wrote: > On 9/12/06, Edi Weitz wrote: >> On Tue, 12 Sep 2006 14:24:00 +0530, quasi >> wrote: >> >> >> > We are using lisp software to connect to Abacus air reservation >> > systems and processing of the data and for all the search logic. >> > The good news is our inhouse software is more than 10x faster than >> > the Java solution purchased from a large software house here and >> > 100x more stable. >> > > I'd just like to echo this, actually; I'm completely amazed at the > speed of applications, especially non-db-backed applications, written > in tbnl. It's a great library. I agree. Edi sometimes likes to say he is more interested in correctness than speed, which is good, but I find this a bit amusing at the same time. The predominant feature of CL/TBNL when I was coming from Java was its shear speed -- I still remember clearly my complete disbelief and confusion almost. The stability side comes in later, in my case about a year later, when I realised that a webapp that I had written was still running happily with a bunch of regular users. Of course, I was also a bit startled that I had forgotten about the thing. Nice work Edi. Cheers, Bob > Rob > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur -- xampl for Ruby -- From ocorrain at yahoo.com Wed Sep 13 19:57:18 2006 From: ocorrain at yahoo.com (=?utf-8?B?VGlhcm7DoW4gw5MgQ29ycsOhaW4=?=) Date: Wed, 13 Sep 2006 20:57:18 +0100 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: (Bob Hutchison's message of "Wed, 13 Sep 2006 08:46:46 -0400") References: <877j0esogt.fsf@agni4.cltp.com> <878xktpj4c.fsf@agni4.cltp.com> <87mz95mpnb.fsf@agni4.cltp.com> <24f203480609120557x25abc9ffs6bc501fe02d2d5e0@mail.gmail.com> Message-ID: >>>>> "BH" == Bob Hutchison writes: BH> I agree. Edi sometimes likes to say he is more interested BH> in correctness than speed, which is good, but I find this a BH> bit amusing at the same time. I agree, but it's nice to have both. I have been seriously impressed with the performance of TBNL/CMUCL: it is also rock solid. My thanks to Edi. -- Tiarn?n From edi at agharta.de Thu Sep 14 20:11:27 2006 From: edi at agharta.de (Edi Weitz) Date: Thu, 14 Sep 2006 22:11:27 +0200 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) Message-ID: Both new versions (try to) add better debugging capabilities - see http://weitz.de/tbnl/#*catch-errors-p* Cheers, Edi. From erik.enge at gmail.com Thu Sep 14 20:53:15 2006 From: erik.enge at gmail.com (Erik Enge) Date: Thu, 14 Sep 2006 16:53:15 -0400 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: References: Message-ID: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> On 9/14/06, Edi Weitz wrote: > Both new versions (try to) add better debugging capabilities - see Wonderful addition, can't wait to try it out. Thanks, Erik. From dan at cambrianhouse.com Fri Sep 15 05:26:43 2006 From: dan at cambrianhouse.com (Daniel Gackle) Date: Thu, 14 Sep 2006 22:26:43 -0700 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: Message-ID: <20060915052645.E22BCA54557@ethoserver.ezone.net> This is highly amusing. We just added that ability to our system last week, since TBNL didn't have it. Time to delete some code! Thanks, Edi. Daniel -----Original Message----- From: tbnl-devel-bounces at common-lisp.net [mailto:tbnl-devel-bounces at common-lisp.net] On Behalf Of Edi Weitz Sent: Thursday, September 14, 2006 1:11 PM To: tbnl-devel at common-lisp.net; tbnl-announce at common-lisp.net Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) Both new versions (try to) add better debugging capabilities - see http://weitz.de/tbnl/#*catch-errors-p* Cheers, Edi. _______________________________________________ tbnl-devel site list tbnl-devel at common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Fri Sep 15 07:02:29 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Sep 2006 09:02:29 +0200 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: <20060915052645.E22BCA54557@ethoserver.ezone.net> (Daniel Gackle's message of "Thu, 14 Sep 2006 22:26:43 -0700") References: <20060915052645.E22BCA54557@ethoserver.ezone.net> Message-ID: On Thu, 14 Sep 2006 22:26:43 -0700, "Daniel Gackle" wrote: > This is highly amusing. We just added that ability to our system > last week, since TBNL didn't have it. Sending a patch would have been an option as well... From edi at agharta.de Fri Sep 15 07:03:55 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Sep 2006 09:03:55 +0200 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> (Erik Enge's message of "Thu, 14 Sep 2006 16:53:15 -0400") References: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> Message-ID: On Thu, 14 Sep 2006 16:53:15 -0400, "Erik Enge" wrote: > Wonderful addition, can't wait to try it out. Yes, please test. I've only tried with LispWorks, but as I use INVOKE-DEBUGGER I'm pretty confident that it should work equally well with other Lisps. From erik.enge at gmail.com Fri Sep 15 13:47:29 2006 From: erik.enge at gmail.com (Erik Enge) Date: Fri, 15 Sep 2006 09:47:29 -0400 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: References: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> Message-ID: <58f839b70609150647j5bf3529ar94d178462999c655@mail.gmail.com> On 9/15/06, Edi Weitz wrote: > Yes, please test. I've only tried with LispWorks, but as I use > INVOKE-DEBUGGER I'm pretty confident that it should work equally well > with other Lisps. It works on SBCL 0.9.13 on Linux x86, thanks. Though I get this error after terminating the TBNL thread: There is no applicable method for the generic function # when called with arguments (#). [Condition of type SIMPLE-ERROR] Erik. From edi at agharta.de Fri Sep 15 15:54:52 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 15 Sep 2006 17:54:52 +0200 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: <58f839b70609150647j5bf3529ar94d178462999c655@mail.gmail.com> (Erik Enge's message of "Fri, 15 Sep 2006 09:47:29 -0400") References: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> <58f839b70609150647j5bf3529ar94d178462999c655@mail.gmail.com> Message-ID: On Fri, 15 Sep 2006 09:47:29 -0400, "Erik Enge" wrote: > It works on SBCL 0.9.13 on Linux x86, thanks. Though I get this > error after terminating the TBNL thread: > > There is no applicable method for the generic function > # > when called with arguments > (#). > [Condition of type SIMPLE-ERROR] Looks like the problem with SBCL and KMRCL that was already mentioned on this mailing list. You usually don't see this because of IGNORE-ERRORS. That probably means that with an unpatched KMRCL your sockets are never closed... From erik.enge at gmail.com Fri Sep 15 16:28:37 2006 From: erik.enge at gmail.com (Erik Enge) Date: Fri, 15 Sep 2006 12:28:37 -0400 Subject: [tbnl-devel] New versions 0.11.1 (TBNL) and 0.3.2 (Hunchentoot) In-Reply-To: References: <58f839b70609141353la3005c2ye5454bde6fd47bca@mail.gmail.com> <58f839b70609150647j5bf3529ar94d178462999c655@mail.gmail.com> Message-ID: <58f839b70609150928w32ad99a0rc2c39d448743122@mail.gmail.com> [Added Kevin to recipient list.] On 9/15/06, Edi Weitz wrote: > Looks like the problem with SBCL and KMRCL that was already mentioned > on this mailing list. You usually don't see this because of > IGNORE-ERRORS. That probably means that with an unpatched KMRCL your > sockets are never closed... Well, that would explain the error I'm seeing every now and then when Apache wants to try now-closed Lisp connections. They're not closed! I'm not completely convinced that kmrcl is in the wrong. CLOSE-ACTIVE-SOCKET seems to me to want a socket as an argument, not a stream. Though I'm confused if that's the case as to why it also doesn't use, say, the CMUCL operator for closing sockets, not streams. Unless the CMUCL CLOSE operator actually works on a socket as well. Kevin, can you clarify, is CLOSE-ACTIVE-SOCKET supposed to work as is in 1.87 with a socket or a stream as an argument? The current condition I'm seeing in TBNL is: There is no applicable method for the generic function # when called with arguments (#). [Condition of type SIMPLE-ERROR] and I'm trying to figure out if a) TBNL shouldn't be passing a stream, or b) kmrcl should accept a stream. Thanks, Erik. From jasondunsmore at gmail.com Sat Sep 16 22:34:50 2006 From: jasondunsmore at gmail.com (Jason Dunsmore) Date: Sat, 16 Sep 2006 15:34:50 -0700 Subject: [tbnl-devel] TBNL hangs on every other request Message-ID: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> I'm using TBNL with SBCL 0.9.15, mod_lisp, and apache2, and the browser hangs indefinitely on every other request. I've also tried using mod_lisp and apache, but it has the same problem. Any idea what's wrong? Thanks, Jason Dunsmore From edi at agharta.de Sat Sep 16 23:50:07 2006 From: edi at agharta.de (Edi Weitz) Date: Sun, 17 Sep 2006 01:50:07 +0200 Subject: [tbnl-devel] TBNL hangs on every other request In-Reply-To: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> (Jason Dunsmore's message of "Sat, 16 Sep 2006 15:34:50 -0700") References: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> Message-ID: On Sat, 16 Sep 2006 15:34:50 -0700, "Jason Dunsmore" wrote: > I'm using TBNL with SBCL 0.9.15, mod_lisp, and apache2, and the > browser hangs indefinitely on every other request. I've also tried > using mod_lisp and apache, but it has the same problem. Any idea > what's wrong? Are you aware of this http://weitz.de/tbnl/#sbcl and the other SBCL problems that were posted to the list? Have you tested in stand-alone mode? I'm afraid I can't be very helpful w.r.t. SBCL, but maybe someone else on the list has an idea. Cheers, Edi. From erik.enge at gmail.com Sun Sep 17 00:16:40 2006 From: erik.enge at gmail.com (Erik Enge) Date: Sat, 16 Sep 2006 20:16:40 -0400 Subject: [tbnl-devel] TBNL hangs on every other request In-Reply-To: References: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> Message-ID: <58f839b70609161716wbcd25e8q9ccb369c9e286a0d@mail.gmail.com> On 9/16/06, Edi Weitz wrote: > I'm afraid I can't be very helpful w.r.t. SBCL, but maybe someone else > on the list has an idea. Please post your log entries and enable debug logging in Apache. Erik. From erik.enge at gmail.com Sun Sep 17 18:45:02 2006 From: erik.enge at gmail.com (Erik Enge) Date: Sun, 17 Sep 2006 14:45:02 -0400 Subject: [tbnl-devel] Add hook before uploading a file. Message-ID: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> My users will upload files as large as 500M to my servers. This will of course take awhile and I think it's asking for trouble to let them submit and then just let the browser sit there and spin a currently-working-cursor without any other feedback. So, I use an IFRAME and some Ajax to submit the form and also poll to see how the submittion is coming along. Then I report this to user in the form of a progress-bar. (Lots of examples of this, just search for "ajax upload progress" in Google.) Anyway, by default in TBNL, as far as I can tell, the request doesn't hit my code until after the file has been uploaded. What I think I really need instead is to have access to the temporary filename created for the upload (so I can track its size) right before TBNL starts reading the file. I've put this together locally by creating a hook in MAKE-TMP-FILE-NAME[1] which is simply called with the tmp-file-name created before returning. In my code I then use this filename to create data for the progress-bar. My question is whether there's a better way to achieve this and/or whether or not you want a patch. Thanks, Erik. [1] I think a comment explaining that it's called from the RFC2388 code would've been really helpful. :-) From edi at agharta.de Sun Sep 17 22:08:03 2006 From: edi at agharta.de (Edi Weitz) Date: Mon, 18 Sep 2006 00:08:03 +0200 Subject: [tbnl-devel] Add hook before uploading a file. In-Reply-To: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> (Erik Enge's message of "Sun, 17 Sep 2006 14:45:02 -0400") References: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> Message-ID: On Sun, 17 Sep 2006 14:45:02 -0400, "Erik Enge" wrote: > My users will upload files as large as 500M to my servers. This > will of course take awhile and I think it's asking for trouble to > let them submit and then just let the browser sit there and spin a > currently-working-cursor without any other feedback. So, I use an > IFRAME and some Ajax to submit the form and also poll to see how the > submittion is coming along. Then I report this to user in the form > of a progress-bar. > > (Lots of examples of this, just search for "ajax upload progress" in > Google.) See also here: http://common-lisp.net/pipermail/tbnl-devel/2006-February/000559.html > Anyway, by default in TBNL, as far as I can tell, the request > doesn't hit my code until after the file has been uploaded. What I > think I really need instead is to have access to the temporary > filename created for the upload (so I can track its size) right > before TBNL starts reading the file. > > I've put this together locally by creating a hook in > MAKE-TMP-FILE-NAME[1] which is simply called with the tmp-file-name > created before returning. In my code I then use this filename to > create data for the progress-bar. > > My question is whether there's a better way to achieve this and/or > whether or not you want a patch. I don't think there's a better way. But do you think that a hook for MAKE-TMP-FILE-NAME is the right solution? At that point you won't know for /which/ uploaded file you're called. > [1] I think a comment explaining that it's called from the RFC2388 > code would've been really helpful. :-) Hehe, yeah, even "Edit Callers" won't help you much in this case... :) Seriously, this is a bit hacky anyway because the RFC2388 calls back into TBNL. I'd like to have a cleaner solution, but that'd probably imply that TBNL implements its own RFC2388 parsing. I'd like to provide something in TBNL to enable things like upload progress bars, but I'm still looking for a solution that looks clean and unobtrusive to me. Cheers, Edi. From erik.enge at gmail.com Sun Sep 17 23:33:51 2006 From: erik.enge at gmail.com (Erik Enge) Date: Sun, 17 Sep 2006 19:33:51 -0400 Subject: [tbnl-devel] Add hook before uploading a file. In-Reply-To: References: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> Message-ID: <58f839b70609171633q1198cf71o3ebfcaac1ab2fb27@mail.gmail.com> On 9/17/06, Edi Weitz wrote: > See also here: > > http://common-lisp.net/pipermail/tbnl-devel/2006-February/000559.html Thanks! > I don't think there's a better way. But do you think that a hook for > MAKE-TMP-FILE-NAME is the right solution? Conceptually the hook should probably be "after we have the filename, before we start reading the file". Good luck finding a good name! ;-) (I named mine *pre-file-upload-hook* which I'm not satisfied with but I can't think of anything better right now.) Whether that's in MAKE-TMP-FILE-NAME or not doesn't really matter to me. The reason I picked it was simply that I didn't want to change RFC2388, because as you say, the way it works now by calling back into TBNL is hackish enough already. :-) > At that point you won't know for /which/ uploaded file you're called. Actually I do know. At that time *REQUEST* is bound and I store a session-key in a cookie that's passed in. So what I do in my hook is retrieve the user doing the upload, via the cookie, then store the temporary filename in my database as part of the user's session. This way my Ajax calls won't have to pass around a filename and there's no way for the user or browser to see my filesystem layout and/or change the filename that's checked in the progress bar. > Seriously, this is a bit hacky anyway because the RFC2388 calls back > into TBNL. I'd like to have a cleaner solution, but that'd probably > imply that TBNL implements its own RFC2388 parsing. Yeah, not sure what the best approach is yet. To be honest, I haven't looked much at the RFC2388 library. > I'd like to provide something in TBNL to enable things like upload > progress bars, but I'm still looking for a solution that looks clean > and unobtrusive to me. The simplest way I can think of is with a hook right when we have the filename but before we start writing to that file. It's the one I'll be using for now but if I think of something better down the line I'll be sure to suggest it here. The older thread you linked suggested modifying RFC2388 to write a status file but this is an extreme specialization of the RFC2388 library, in my opinion. Thanks, Erik. From ccalca at essex.ac.uk Mon Sep 18 01:26:49 2006 From: ccalca at essex.ac.uk (Xristos Kalkanis) Date: Mon, 18 Sep 2006 02:26:49 +0100 Subject: [tbnl-devel] TBNL hangs on every other request In-Reply-To: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> References: <93f5c6d70609161534m531de858vb2ce49418cab12ff@mail.gmail.com> Message-ID: Its probably kmrcl (sockets.lisp, close-active-socket) See my previous messages to the list for a possible solution. On 16 Sep 2006, at 23:34, Jason Dunsmore wrote: > I'm using TBNL with SBCL 0.9.15, mod_lisp, and apache2, and the > browser hangs indefinitely on every other request. I've also tried > using mod_lisp and apache, but it has the same problem. Any idea > what's wrong? > > Thanks, > Jason Dunsmore > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From erik.enge at gmail.com Mon Sep 18 17:25:27 2006 From: erik.enge at gmail.com (Erik Enge) Date: Mon, 18 Sep 2006 13:25:27 -0400 Subject: [tbnl-devel] Add hook before uploading a file. In-Reply-To: <58f839b70609171633q1198cf71o3ebfcaac1ab2fb27@mail.gmail.com> References: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> <58f839b70609171633q1198cf71o3ebfcaac1ab2fb27@mail.gmail.com> Message-ID: <58f839b70609181025y7f8afc2bnd9dea4bb3237b9e0@mail.gmail.com> On 9/17/06, Erik Enge wrote: > Actually I do know. At that time *REQUEST* is bound Hm, there are gremlins in my code. *request* can't be bound at that point because make-tmp-file-name is called from rfc2388:parse-mime which is called from parse-rfc2388-form-data which is called in initialize-instance :after on request. I guess I'll patch TBNL locally to write the raw-post-data after initialize-instance is done. Erik. From stesch at no-spoon.de Wed Sep 20 08:14:05 2006 From: stesch at no-spoon.de (Stefan Scholl) Date: Wed, 20 Sep 2006 10:14:05 +0200 Subject: [tbnl-devel] Add hook before uploading a file. In-Reply-To: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> References: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> Message-ID: <20060920081405.GF13935@parsec.no-spoon.de> On 2006-09-17 14:45:02, Erik Enge wrote: > (Lots of examples of this, just search for "ajax upload progress" in > Google.) Arghl. A lot of silly junk. Those PHP guys can't think as far as the they can throw a rack full of LAMP boxen. From edi at agharta.de Wed Sep 20 19:40:05 2006 From: edi at agharta.de (Edi Weitz) Date: Wed, 20 Sep 2006 21:40:05 +0200 Subject: [tbnl-devel] New version 0.11.2 Message-ID: ChangeLog: Version 0.11.2 2006-09-20 DEFINE-EASY-HANDLER: fixed and clarified redefinition DEFINE-EASY-HANDLER: allow for functions designators as "URIs" DEFINE-EASY-HANDLER: take file uploads into account Made logging a little bit more robust Added mime type for XSL-FO (.fo) Download: http://weitz.de/files/tbnl.tar.gz Have fun, Edi. From edi at agharta.de Thu Sep 28 22:47:54 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 29 Sep 2006 00:47:54 +0200 Subject: [tbnl-devel] Serving large files Message-ID: Frank Zappa once said that "Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Sometimes I think #lisp is a bit similar... :) OK, nobody has asked, but here's the answer anyway: RTFM where it says (right at the beginning) that you should use SEND-HEADERS "if you want to serve very large static files." SEND-HEADERS has been in there since 2005 (version 0.9.0) and it is used in HANDLE-STATIC-FILE (html.lisp) as well as in the UTF-8 example. Cheers, Edi. From xach at xach.com Thu Sep 28 23:33:03 2006 From: xach at xach.com (Zach Beane) Date: Thu, 28 Sep 2006 19:33:03 -0400 Subject: [tbnl-devel] Serving large files In-Reply-To: References: Message-ID: <20060928233303.GG11045@xach.com> On Fri, Sep 29, 2006 at 12:47:54AM +0200, Edi Weitz wrote: > Frank Zappa once said that "Rock journalism is people who can't write > interviewing people who can't talk for people who can't read." > Sometimes I think #lisp is a bit similar... :) > > But...but... http://meme.b9.com/cview.html?channel=lisp&start=3368462909&end=3368468500 Zach From erik.enge at gmail.com Thu Sep 28 23:41:19 2006 From: erik.enge at gmail.com (Erik Enge) Date: Thu, 28 Sep 2006 19:41:19 -0400 Subject: [tbnl-devel] Serving large files In-Reply-To: References: Message-ID: <58f839b70609281641g7b6965e6obc42ab68917e5962@mail.gmail.com> On 9/28/06, Edi Weitz wrote: > Frank Zappa once said that "Rock journalism is people who can't write > interviewing people who can't talk for people who can't read." > Sometimes I think #lisp is a bit similar... :) Ouch... > OK, nobody has asked, but here's the answer anyway: RTFM where it says > (right at the beginning) that you should use SEND-HEADERS "if you want > to serve very large static files." Mea maxima culpa; and thanks. Erik. From edi at agharta.de Fri Sep 29 06:13:45 2006 From: edi at agharta.de (Edi Weitz) Date: Fri, 29 Sep 2006 08:13:45 +0200 Subject: [tbnl-devel] Serving large files In-Reply-To: <20060928233303.GG11045@xach.com> (Zach Beane's message of "Thu, 28 Sep 2006 19:33:03 -0400") References: <20060928233303.GG11045@xach.com> Message-ID: On Thu, 28 Sep 2006 19:33:03 -0400, Zach Beane wrote: > But...but... > > http://meme.b9.com/cview.html?channel=lisp&start=3368462909&end=3368468500 Ugh, sorry, missed that part. Anyway, it was a good occasion to throw in a Zappa quote... :) From travis at travislists.com Fri Sep 29 22:18:03 2006 From: travis at travislists.com (Travis Cross) Date: Fri, 29 Sep 2006 18:18:03 -0400 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: Message-ID: <451D9B9B.2050002@travislists.com> Edi Weitz wrote: > Before I do that, I'd need some info about current usage > patterns. My impression is that TBNL is used with these > implementations > > SBCL I use SBCL rather exclusively. > usually behind mod_lisp or stand-alone. Is that right? I usually test and deploy behind mod_lisp2 / apache2 - this works well (after updating kmrcl to play nicely with SBCL) though this introduces a rather opaque layer into the debugging process when things just don't quite work correctly. > Does anybody still use TBNL with Araneida? Not me. > Would people be interested in something like Hunchentoot for > non-LispWorks Lisps? I would be very likely to use this as a solution to a number of projects where taking Apache out of the setup would greatly simplify things. After you released Hunchentoot, I took a hard look at the source and have been considering factoring out the non-portable code ever since. I'd be terribly happy if you beat me to it though ;) Another project on my TBNL agenda that I started part way down was seeing if I could remove some dependencies (primarily kmrcl) without adding a whole lot a code to TBNL. Do you happen to be sold on the wonders of the Darcs version control system? ;) If you're not strongly tied to whatever VCS you're currently using, a public darcs repository could be a real boon. Cheers, -- Travis From edi at agharta.de Fri Sep 29 22:34:45 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 30 Sep 2006 00:34:45 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <451D9B3A.60001@officetone.com> (Travis Cross's message of "Fri, 29 Sep 2006 18:16:26 -0400") References: <451D9B3A.60001@officetone.com> Message-ID: On Fri, 29 Sep 2006 18:16:26 -0400, Travis Cross wrote: > After you released Hunchentoot, I took a hard look at the source and > have been considering factoring out the non-portable code ever > since. I'd be terribly happy if you beat me to it though ;) There's a slight chance that this will happen... :) > Another project on my TBNL agenda that I started part way down was > seeing if I could remove some dependencies (primarily kmrcl) without > adding a whole lot a code to TBNL. LispWorks/Hunchentoot doesn't use KMRCL, so that's the plan for SBCL and the other Lisps as well. > Do you happen to be sold on the wonders of the Darcs version control > system? ;) If you're not strongly tied to whatever VCS you're > currently using, a public darcs repository could be a real boon. You wouldn't win anything, because I immediately make a new release if I add new code. Im the case of RDNZL I once tried with a public repository, but although several people had write access nothing came out of it. The only result was that it became harder for me and I couldn't work offline anymore... Cheers, Edi. From travis at travislists.com Fri Sep 29 23:23:34 2006 From: travis at travislists.com (Travis Cross) Date: Fri, 29 Sep 2006 19:23:34 -0400 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: <451D9B3A.60001@officetone.com> Message-ID: <451DAAF6.1000307@travislists.com> Edi Weitz wrote: >> Another project on my TBNL agenda that I started part way down was >> seeing if I could remove some dependencies (primarily kmrcl) without >> adding a whole lot a code to TBNL. > > LispWorks/Hunchentoot doesn't use KMRCL, so that's the plan for SBCL > and the other Lisps as well. I had a feeling this was on your agenda as well. >> Do you happen to be sold on the wonders of the Darcs version control >> system? ;) If you're not strongly tied to whatever VCS you're >> currently using, a public darcs repository could be a real boon. > > You wouldn't win anything, because I immediately make a new release if > I add new code. Im the case of RDNZL I once tried with a public > repository, but although several people had write access nothing came > out of it. The only result was that it became harder for me and I > couldn't work offline anymore... I suspected that, which is why I think you would like darcs. With darcs, everything is an offline operation - there really is no online mode so to speak. An online repository is simply a darcs working copy whose files are accessible via HTTP. You can therefore 'pull' from a HTTP repository, but not 'push' to it. Pushing across the web is handled via SSH or email. Contributions to a project such as this would likely still flow through email -- darcs just provides some (nice) tools to facilitate making and merging those contributions. It really isn't a big deal though. Right now, I have a special weitz.de-project-updater bash/perl script which pulls the latest releases from the website periodically and tries to merge them against any local changes I'm working on, and then makes a commit to my working copy if a version update has occurred. If the project was darcs based, of course, I could truncate that process down to `darcs pull` :) The feature of darcs which really hooked me is that you can 'cherry-pick' patches from one working copy to another. The darcs homepage is: http://abridgegame.org/darcs/ The advanced features, offline operation model, and distributed development capabilities, along with the conceptual elegance of the author's "Theory of Patches" is probably why this VCS has been attracting more and more projects in the lisp community, such as UCW, CFFI, detachtty, CLX, araneida, etc. (http://bc.tech.coop/blog/050710.html) Cheers, -- Travis From rm at seid-online.de Sat Sep 30 10:19:11 2006 From: rm at seid-online.de (Ralf Mattes) Date: Sat, 30 Sep 2006 12:19:11 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: References: <451D9B3A.60001@officetone.com> Message-ID: <1159611551.8174.3.camel@localhost.localdomain> On Sat, 2006-09-30 at 00:34 +0200, Edi Weitz wrote: > On Fri, 29 Sep 2006 18:16:26 -0400, Travis Cross wrote: > > > After you released Hunchentoot, I took a hard look at the source and > > have been considering factoring out the non-portable code ever > > since. I'd be terribly happy if you beat me to it though ;) > > There's a slight chance that this will happen... :) > > > Another project on my TBNL agenda that I started part way down was > > seeing if I could remove some dependencies (primarily kmrcl) without > > adding a whole lot a code to TBNL. > > LispWorks/Hunchentoot doesn't use KMRCL, so that's the plan for SBCL > and the other Lisps as well. > > > Do you happen to be sold on the wonders of the Darcs version control > > system? ;) If you're not strongly tied to whatever VCS you're > > currently using, a public darcs repository could be a real boon. > > You wouldn't win anything, because I immediately make a new release if > I add new code. Im the case of RDNZL I once tried with a public > repository, but although several people had write access nothing came > out of it. The only result was that it became harder for me and I > couldn't work offline anymore... Well, the one advantage i see in using darcs: it eases the creation racking and maintenance of patches. And you don't need to develop in your "public" darcs repository. Actually, you usually don't want to do this: just develop on your box and propagate the patches to the public repro. But the - last time i found a bugglet your fix was faster then my patch, so why should i complaint ;-) Cheers, RalfD > Cheers, > Edi. > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From edi at agharta.de Sat Sep 30 13:24:20 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 30 Sep 2006 15:24:20 +0200 Subject: [tbnl-devel] New version 0.11.3 (Was: Add hook before uploading a file.) In-Reply-To: <58f839b70609171633q1198cf71o3ebfcaac1ab2fb27@mail.gmail.com> (Erik Enge's message of "Sun, 17 Sep 2006 19:33:51 -0400") References: <58f839b70609171145i490568d5kc6b2814e9cbade0e@mail.gmail.com> <58f839b70609171633q1198cf71o3ebfcaac1ab2fb27@mail.gmail.com> Message-ID: On Sun, 17 Sep 2006 19:33:51 -0400, "Erik Enge" wrote: > The simplest way I can think of is with a hook right when we have > the filename but before we start writing to that file. I've added that now - see doc entry for *FILE-UPLOAD-HOOK*. Please try if it works for you. I think that's the best I can do ATM without modifying the RFC2388 code. Cheers, Edi. From edi at agharta.de Sat Sep 30 13:41:03 2006 From: edi at agharta.de (Edi Weitz) Date: Sat, 30 Sep 2006 15:41:03 +0200 Subject: [tbnl-devel] TBNL survey / re-org In-Reply-To: <451DAAF6.1000307@travislists.com> (Travis Cross's message of "Fri, 29 Sep 2006 19:23:34 -0400") References: <451D9B3A.60001@officetone.com> <451DAAF6.1000307@travislists.com> Message-ID: On Fri, 29 Sep 2006 19:23:34 -0400, Travis Cross wrote: > http://abridgegame.org/darcs/ Yeah, now I remember. I tried to install darcs on Windows (which is my main development platform right now) a couple of months ago. I'm probably too dumb for that kind of stuff, but I shipwrecked - I never managed to set up something that worked, with or without Cygwin.