From hans.huebner at gmail.com Tue Mar 1 05:41:24 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 1 Mar 2011 06:41:24 +0100 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: Folks, please note that the API change which caused the problem reported here is not yet in the released version of Hunchentoot, but only in the trunk version. The released version of Hunchentoot does work as expected, including the simple example that is in the documentation. -Hans On Mon, Feb 28, 2011 at 10:16 PM, Edi Weitz wrote: > On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker > wrote: >> I finally got the New York version to work, but only with Lispbox CCL. Any >> other flavor of Common Lisp gives me trouble. > > What exactly does "any other flavor" mean? ?Which ones did you try on > which platforms? > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From andrew.pennebaker at gmail.com Tue Mar 1 10:07:17 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Tue, 1 Mar 2011 05:07:17 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using Aptitude and MacPorts respectively. In every case, Hunchentoot's start function hung, because the CL implementation failed to include thread support. On Mon, Feb 28, 2011 at 4:16 PM, Edi Weitz wrote: > On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker > wrote: > > I finally got the New York version to work, but only with Lispbox CCL. > Any > > other flavor of Common Lisp gives me trouble. > > What exactly does "any other flavor" mean? Which ones did you try on > which platforms? > > _______________________________________________ > 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 andrew.pennebaker at gmail.com Tue Mar 1 10:36:21 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Tue, 1 Mar 2011 05:36:21 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: In particular, Hunchentoot fails to compile in MacPorts ECL. (ql:quickload "hunchentoot") ... ;;; Note: ;;; Invoking external command: ;;; /usr/bin/gcc-4.2 -o /Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.fas -L/opt/local/lib/ /private/var/folders/N-/N-IxaaKuFae5ik1WKxV6wE+++TI/-Tmp-/eclinits0Tu3w.o /Users/andrew/.cache/common-lisp/ecl-11.1.1-macosx-x86/Users/andrew/quicklisp/dists/quicklisp/software/flexi-streams-1.0.7/mapping.o -bundle -L/opt/local/lib -arch x86_64 -L/opt/local/lib -arch x86_64 -lecl -lgmp -lm In function COERCE, the value of variable is 65533 which is not of expected type (INTEGER -128 127) On Mon, Feb 28, 2011 at 4:16 PM, Edi Weitz wrote: > On Mon, Feb 28, 2011 at 9:32 PM, Andrew Pennebaker > wrote: > > I finally got the New York version to work, but only with Lispbox CCL. > Any > > other flavor of Common Lisp gives me trouble. > > What exactly does "any other flavor" mean? Which ones did you try on > which platforms? > > _______________________________________________ > 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 sergio.garcia at gmail.com Tue Mar 1 13:33:53 2011 From: sergio.garcia at gmail.com (Sergio Garcia) Date: Tue, 1 Mar 2011 08:33:53 -0500 Subject: [hunchentoot-devel] Robustness change committed In-Reply-To: References: Message-ID: Great. I have a site that was having problems when it reached about 100 threads, I wonder if anybody has anecdotal data on how their hunchentoot settings behave under high load. On Thu, Feb 10, 2011 at 12:25 PM, Hans H?bner wrote: > Hi, > > I committed a (modified) patch submitted by Dan Weinreb that makes > Hunchentoot more resilient to high load conditions by limiting the > number of request handler threads that can be running at any time. ?If > you are running a site with a lot of traffic, you'll want to be aware > of this change. > > Documentation for this feature is not yet available. > > -Hans > > > ---------- Forwarded message ---------- > From: BKNR Commits > Date: Thu, Feb 10, 2011 at 6:22 PM > Subject: [bknr-cvs] hans changed trunk/thirdparty/hunchentoot/ > To: bknr-cvs at common-lisp.net > > > Revision: 4645 > Author: hans > URL: http://bknr.net/trac/changeset/4645 > > Patch from Dan Weinreb: > > limit the maximum number of request handler threads that a taskmaster may > create. > Support a new SOFT argument to the STOP function that makes Hunchentoot > wait until all currently outstanding requests have been processed before > returning. > > Add a favicon.ico to the standard file tree. > Refactorings in the START-OUTPUT function to separate out the actual > header sending from the request processing part. ?The new SEND-RESPONSE > function does the I/O part of sending the response header (and possibly > content) and also does the logging. ?Used by the thread count limiting > code to send a 503 message if no more threads can be created. > > U ? trunk/thirdparty/hunchentoot/acceptor.lisp > U ? trunk/thirdparty/hunchentoot/compat.lisp > U ? trunk/thirdparty/hunchentoot/headers.lisp > U ? trunk/thirdparty/hunchentoot/taskmaster.lisp > U ? trunk/thirdparty/hunchentoot/util.lisp > A ? trunk/thirdparty/hunchentoot/www/favicon.ico > > Change set too large, please see URL above > > _______________________________________________ > bknr-cvs mailing list > bknr-cvs at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-cvs > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From edi at weitz.de Tue Mar 1 14:08:36 2011 From: edi at weitz.de (Edi Weitz) Date: Tue, 1 Mar 2011 15:08:36 +0100 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker wrote: > I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using > Aptitude and MacPorts respectively. In every case, Hunchentoot's start > function hung, because the CL implementation failed to include thread > support. That should not happen. Can you check the values of bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they correct? If so, the default taskmaster should be one-thread-per-connection-manager which doesn't need threads. From andrew.pennebaker at gmail.com Thu Mar 3 14:02:41 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Thu, 3 Mar 2011 09:02:41 -0500 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: I've checked a bunch of implementations now. bt:*supports-threads-p* and tbnl::*supports-threads-p* are T for the implementations that work well with Hunchentoot. Typically both variables are NIL due to the underlying implementation lacking thread support: Success - Lispbox CCL on Ubuntu/Xen - Lispbox CCL on Mac OS X - MacPorts CCL on Mac OS X - Aptitude SBCL on Ubuntu/VMware - MacPorts SBCL on Mac OS X Partial Failure - Aptitude CLISP on Ubuntu/Xen (no threads; Hunchentoot server and command hang) - Fink CLISP on Mac OS X (no threads; Hunchentoot works with slight modification) Failure - Aptitude SBCL on Ubuntu/Xen (SBCL compilation fails) - MacPorts CLISP on Mac OS X (CFFI and threads missing) - Aptitude CCL on Ubuntu (no package named CCL) - ECL on Ubuntu/Xen (ECL compilation failure) - MacPorts ECL on Mac OS X (flexi-streams compilation failure) - ABCL on Ubuntu/Xen (Bordeaux Threads compilation failure) - MacPorts ABCL on Mac OS X (Quicklisp compilation failure) - GCL on Ubuntu/Xen (Quicklisp compilation failure) Cheers, Andrew Pennebaker www.yellosoft.us On Tue, Mar 1, 2011 at 9:08 AM, Edi Weitz wrote: > On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker > wrote: > > I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, using > > Aptitude and MacPorts respectively. In every case, Hunchentoot's start > > function hung, because the CL implementation failed to include thread > > support. > > That should not happen. Can you check the values of > bt:*supports-threads-p* and tbnl::*supports-threads-p*? Are they > correct? If so, the default taskmaster should be > one-thread-per-connection-manager which doesn't need threads. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at weitz.de Thu Mar 3 15:13:56 2011 From: edi at weitz.de (Edi Weitz) Date: Thu, 3 Mar 2011 16:13:56 +0100 Subject: [hunchentoot-devel] Hunchentoot on CLISP In-Reply-To: References: <4D6BF36E.2080106@itasoftware.com> Message-ID: Thanks for the detailed survey. Most of these combinations I don't have access to, though. If you think there are errors or missing features in Hunchentoot which are the cause for some of these failures, please send patches. http://weitz.de/patches.html Cheers, Edi. On Thu, Mar 3, 2011 at 3:02 PM, Andrew Pennebaker wrote: > I've checked a bunch of implementations now. bt:*supports-threads-p* and > tbnl::*supports-threads-p* are T for the implementations that work well with > Hunchentoot. Typically both variables are NIL due to the underlying > implementation lacking thread support: > Success > > Lispbox CCL on Ubuntu/Xen > Lispbox CCL on Mac OS X > MacPorts CCL on Mac OS X > Aptitude SBCL on Ubuntu/VMware > MacPorts SBCL on Mac OS X > > Partial Failure > > Aptitude CLISP on Ubuntu/Xen (no threads; Hunchentoot server and command > hang) > Fink CLISP on Mac OS X (no threads; Hunchentoot works with slight > modification) > > Failure > > Aptitude SBCL on Ubuntu/Xen (SBCL compilation fails) > MacPorts CLISP on Mac OS X (CFFI and threads missing) > Aptitude CCL on Ubuntu (no package named CCL) > ECL on Ubuntu/Xen (ECL compilation failure) > MacPorts ECL on Mac OS X (flexi-streams compilation failure) > ABCL on Ubuntu/Xen (Bordeaux Threads compilation failure) > MacPorts ABCL on Mac OS X (Quicklisp compilation failure) > GCL on Ubuntu/Xen (Quicklisp compilation failure) > > Cheers, > Andrew Pennebaker > www.yellosoft.us > > > On Tue, Mar 1, 2011 at 9:08 AM, Edi Weitz wrote: >> >> On Tue, Mar 1, 2011 at 11:07 AM, Andrew Pennebaker >> wrote: >> > I have installed ABCL, SBCL, CLISP, and ECL on Ubuntu and Mac OS X, >> > using >> > Aptitude and MacPorts respectively. In every case, Hunchentoot's start >> > function hung, because the CL implementation failed to include thread >> > support. >> >> That should not happen. ?Can you check the values of >> bt:*supports-threads-p* and tbnl::*supports-threads-p*? ?Are they >> correct? ?If so, the default taskmaster should be >> one-thread-per-connection-manager which doesn't need threads. > > From fbogdanovic at xnet.hr Wed Mar 9 20:19:47 2011 From: fbogdanovic at xnet.hr (Haris) Date: Wed, 9 Mar 2011 21:19:47 +0100 Subject: [hunchentoot-devel] encoding Message-ID: <466B0E1DD61C4D09859B9B7FAD9805BE@komp> Hi. How to set Hunchentoot encoding to utf-8 ? Thanks From lou.vanek at gmail.com Wed Mar 9 21:08:52 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Wed, 9 Mar 2011 16:08:52 -0500 Subject: [hunchentoot-devel] encoding Message-ID: Haris, see, https://sites.google.com/site/sabraonthehill/home/exploring-quicklisp-packages for an answer. From andrew.pennebaker at gmail.com Wed Mar 9 21:38:33 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Wed, 9 Mar 2011 16:38:33 -0500 Subject: [hunchentoot-devel] encoding In-Reply-To: <466B0E1DD61C4D09859B9B7FAD9805BE@komp> References: <466B0E1DD61C4D09859B9B7FAD9805BE@komp> Message-ID: Use cl-who to create the HTML output, in which a tag is used to specify UTF8. From https://github.com/mcandre/doeshunchentootwork/blob/master/doeshunchentootwork.lisp . (defmacro standard-page ((&key title) &body body) `(cl-who:with-html-output-to-string (*standard-output* nil :prologue t :indent t) (:html :xmlns "http://www.w3.org/1999/xhtml" :xml\:lang "en" :lang "en" (:head (:title ,title) (:meta :http-equiv "Content-Type" :content "text/html;charset=utf-8")) (:body :style "text-align: center;" (:a :href "https://github.com/mcandre/doeshunchentootwork" "GitHub") (:h1 "Does Hunchentoot work?") , at body)))) Cheers, Andrew Pennebaker www.yellosoft.us On Wed, Mar 9, 2011 at 3:19 PM, Haris wrote: > Hi. > > How to set Hunchentoot encoding to utf-8 ? > > Thanks > > _______________________________________________ > 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 fbogdanovic at xnet.hr Mon Mar 14 13:43:33 2011 From: fbogdanovic at xnet.hr (Haris) Date: Mon, 14 Mar 2011 14:43:33 +0100 Subject: [hunchentoot-devel] sessions Message-ID: <19F3D69ED4F24B4FA1707EFADC65BC30@komp> Hi. Could someone give me a simple example of using sessions ? I have a simple web application and want to add user registration so that the server knows who submitted some form. Thanks From jetmonk at gmail.com Mon Mar 14 20:53:06 2011 From: jetmonk at gmail.com (JTK) Date: Mon, 14 Mar 2011 10:53:06 -1000 Subject: [hunchentoot-devel] turning off logging, and socket backlogs (patches included) Message-ID: [This is all in a recent bknr svn hunchentoot running on opencml and sbcl on a mac 10.6] 1. Logging: I've been playing with running hunchentoot under heavy loads using easy-acceptor, and running against apache-bench (ab) I noticed that logging to *error-output* often causes socket failures under heavy load, at least in SLIME. Is there a reason why with-open-file-or-console in log.lisp couldn't use a NIL pathname to simply not log, and pathname=T would log to *error-output*, which is what NIL presently means? Now, there seems to be no way to turn off logging (besides subclassing acceptor). 2. Backlog in listener: I found that in the start-listening method in acceptor.lisp, there is no BACKLOG set for usocket:socket-listen. I think that others have pointed this out as well. The default apache backlog seems to be 100 to 512 [1,2,3] though the default on a macintosh seems silently limited to 128 [4]. In the usocket routines used by hunchentoot backlog seems to be only 5. This seems two orders of magnitude smaller than what is standard for web servers. I tried putting in :BACKLOG 50 into the start-listening method in acceptor.lisp and it eliminated most failures of ab. Is there any reason why acceptor objects shouldn't have a new backlog slot default value in them much larger than 5, which should be used in the start-listening method? The appended patches implement both changes, if these suggestions are judged useful. The backlog is 50. I hope they're done correctly; I'm not experienced in submitting patches. John [1] http://groups.google.com/group/modwsgi/browse_thread/thread/b6d66d3fe5a53d2c [2] http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/ [3] /usr/include/apache2/mpm_common.h:#define DEFAULT_LISTENBACKLOG 511 [4] http://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man2/listen.2.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: acceptor.lisp.diff Type: application/octet-stream Size: 2539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log.lisp.diff Type: application/octet-stream Size: 2715 bytes Desc: not available URL: From hans.huebner at gmail.com Tue Mar 15 05:54:50 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 15 Mar 2011 06:54:50 +0100 Subject: [hunchentoot-devel] turning off logging, and socket backlogs (patches included) In-Reply-To: References: Message-ID: Hi John, thank you for your suggestions and patches. I have committed slight variations of them: ACCEPTOR-ACCESS-LOG-PATHNAME and ACCEPTOR-MESSAGE-LOG-PATHNAME have been renamed to ACCEPTOR-ACCESS-LOG-DESTINATION and ACCEPTOR-MESSAGE-LOG-DESTINATION, respectively. Both can be set to either a string or pathname designating a file, to an open stream or to NIL. NIL suppresses logging, the other two option should be obvious. *ERROR-OUTPUT* is the default for both. A new LISTEN-BACKLOG slot has been added to the ACCEPTOR class which can be set by the corresponding initarg during ACCEPTOR creation. Patch review comments: - Documentation was missing - Use :INITARG instead of :INITFORM, in particular if you want a value to be configurable. In Hunchentoot, we use :INITFORM only for slots which can't be set by the user in the MAKE-INSTANCE call. Rather, we use :INITARG together with the :DEFAULT-INITARG clause in DEFCLASS. - If a slot cannot be set meaningfully, use :READER instead of :ACCESSOR. This was the case for the backlog slot, as it is never consulted after the listen() call has been made. - We do not use all-uppercase for CL symbols like T or NIL in our source code. (Obviously, these are just stylistic issues which are only valid in this form for Hunchentoot. I don't claim that they are universal). Thanks again! Please test what I've committed and send more patches if you need to. -Hans On Mon, Mar 14, 2011 at 9:53 PM, JTK wrote: > > [This is all in a recent bknr svn hunchentoot running on opencml and sbcl on > a mac 10.6] > > 1. ?Logging: > I've been playing with running hunchentoot under heavy loads using > easy-acceptor, > and running against apache-bench (ab) > I noticed that logging to *error-output* often causes socket failures under > heavy > load, at least in SLIME. ?Is there a reason why with-open-file-or-console in > log.lisp > couldn't use a NIL pathname to simply not log, and pathname=T would log > to *error-output*, which is what NIL presently means? ? Now, there seems to > be no > way to turn off logging (besides subclassing?acceptor). > > > 2. ?Backlog in listener: > I found that in the start-listening method in acceptor.lisp, there is no > BACKLOG > set for usocket:socket-listen. ?I think that others have pointed this out as > well. > The default apache backlog seems to be 100 to 512 > [1,2,3] though the default on a macintosh seems silently limited to 128 [4]. > In the usocket > routines used by hunchentoot backlog seems to be only 5. ? ?This seems > two orders of magnitude smaller than what is standard for web servers. > I tried putting in :BACKLOG 50 into the start-listening method in > acceptor.lisp > and it eliminated most failures of ab. ?Is there any reason why acceptor > objects > shouldn't have a ?new backlog slot default value in them much larger than > 5, > which should be used in the ?start-listening method? > The appended patches implement both changes, if these suggestions are judged > useful. > The backlog is 50. ?I hope they're done correctly; I'm not experienced in > submitting patches. > John > > [1]?http://groups.google.com/group/modwsgi/browse_thread/thread/b6d66d3fe5a53d2c > [2]?http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/ > [3]?/usr/include/apache2/mpm_common.h:#define DEFAULT_LISTENBACKLOG 511 > [4]?http://developer.apple.com/library/mac/#documentation/darwin/reference/manpages/man2/listen.2.html > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From olegsivokon at gmail.com Tue Mar 15 22:56:23 2011 From: olegsivokon at gmail.com (Oleg Sivokon) Date: Wed, 16 Mar 2011 00:56:23 +0200 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X Message-ID: Hello. Please forgive me asking questions with probably obvious answers. I'm new to the Lisp world in general, and to using Hunchentoot too. Since I'm new, I had a lot of problems installing Hunchentoot... I had successfully did it on two Ubuntu 10.4 machines, one 32 bit and another 64 bit both running last SBCL available from Ubuntu PPA. I had also tried to record my experience so I could explain it to anyone who asked. I'm effectively writing a mock-up server to do testing for the project that otherwise runs in a different environment, yet, at some point I would like other people to be also able to replicate my steps on installing the server and running my code. Major problems I encountered: - ASDF does not update... (I know, you have nothing to do with this, yet whenever the manual on the site mentions ASDF, it would be great if it would take in account that ASDF not only may do things wrong, it most probably will...). Long story short, I've tried to update ASDF following manual on their site - never worked due to some missing methods or just reverting to the last version w/o any notion. I've also tried building SBCL from sources. The last version in development comes with latest ASDF version (2.0), yet the installation instructions are bizarre and contradict themselves... At the most successful point I could install what compiles from trunk, but in order to run that version as root, I would need to specify the sbcl.core on launch. I could also install Hunchentoot into this version of SBCL, but it had problems with UFFI (separate story below). Various other packages in this mode would report missing files or non-existing functions and so on. It proved to be unusable. - ASDF-INSTALL, similarly, trying to install from archive or from site (clicky) were subsequently unsuccessful. Having only clean SBCL install, ASDF-INSTALL would break at random trying to solve dependencies. I couldn't find the pattern. By trial and error I found, that the combination of having CL-PPCRE, USOCKET, CLOSER-MOP and CXML (!) would most of the time lead to that Hunchentoot would be able to find all dependencies during install. This happened 2 times out of maybe 8... - There's some package, which during installation would break the display in console... (the console will start displaying random non-printable characters) It would also stop during compile offering different restarts, where you are forced to play pitch-n-toss :) And if you are lucky, then the console will recover. - Finally, the most sure way I found was to just (require :hunchentoot) using ASDF v 1 and resolve missing dependencies by hand. It would sometimes break when trying to install CL-PPCRE, presumably due to another dependency having something to do with Unicode, but it succeeded more often then failed. - UFFI - for all I tried it failed to compile and install properly always. It looks like the errors are in *insignificant* tests, yet for an unexperienced user this looks scary (mistyped pointers?!) :) Often the errors when compiling this package will also break the installation started by ASDF - it will not offer to skip the failed compilation, or so I understood what happened. (I also saw some messages regarding omission of "dead" code, while compiling this package - this also looks suspicious, why would anyone release such code, and may there be any connection between that, and that the code failed to compile in the end?) Some weird things I saw during installation: an attempt was made to install SLIME. It somehow got into dependency list of Hunchentoot... I've encountered several times notion of 64-bit processor architecture in different libraries related to Common Lisp as "PPC" - I never heard of this abbreviation before in this context, (no pun intended), what does it mean? This was one of really confusing places when reading the documentation (I would assume it to be Apple Motoralla processor from 10 years ago). For whatever other arcane reason Ubuntu / Debian tech papers call supported 64-bit processors AMD86 or AMD8664 (some of them having nothing to do with AMD!). Now, my question is, is my experience something you would expect a user to undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to develop in more stable environment, do I have to switch to another version of CL? (Back in the days I've used CMUCL on Windows, albeit very shortly, but I don't recall that many problems...) Or are Hunchentoot and SBCL not really compatible, and the attempt to put them together makes it so difficult? Of course, most chances are I am doing something wrong :) Yet it would be nice if someone more experience commented. Oh, and btw, I've managed to then install CL-GD and use it with Hunchentoot, for that I had to, again, delete some shared libraries in system folders and rewrite Make file... It worked, as I said, but, again, I've a feeling I do things the wrong way and it shouldn't be this difficult... And, one last thing, if there are bugs filed against the server, is it possible to view them somewhere? I've found few bug-trackers during my setup exercises :) however, I'm not sure which is an official one. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xach at xach.com Wed Mar 16 00:31:51 2011 From: xach at xach.com (Zach Beane) Date: Tue, 15 Mar 2011 20:31:51 -0400 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: (Oleg Sivokon's message of "Wed, 16 Mar 2011 00:56:23 +0200") References: Message-ID: <877hbzj47c.fsf@hangup.portland.xach.com> Oleg Sivokon writes: > Now, my question is, is my experience something you would expect a user to > undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to > develop in more stable environment, do I have to switch to another version of > CL? (Back in the days I've used CMUCL on Windows, albeit very shortly, but I > don't recall that many problems...) Or are Hunchentoot and SBCL not really > compatible, and the attempt to put them together makes it so difficult? > Of course, most chances are I am doing something wrong :) Yet it would be nice > if someone more experience commented. I've used Hunchentoot and SBCL on Linux with great success. There are a few things I do that I think help me avoid headaches. First, while I use Debian, I do not use the system-provided packages for Lisp-related projects. The projects are usually out-of-date (sometimes more than a year), and sometimes they have been modified in ways that can be hard to troubleshoot. So when I want to get SBCL for Linux, I go to www.sbcl.org and click Download and go from there. Second, I install and manage libraries with Quicklisp. Quicklisp is a relatively new option that, in my experience, works better than all previous library management systems like asdf-install. It's still in beta, so it's not polished and complete yet, but it's still very useful. See www.quicklisp.org for the download link. (Disclaimer: I wrote Quicklisp.) Hope this helps, Zach From lou.vanek at gmail.com Wed Mar 16 10:54:58 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Wed, 16 Mar 2011 06:54:58 -0400 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: Oleg, It would help if you were to include what type of machine(s) you are installing on when submitting these types of notes. For example, is it Intel, Intel/Mac, PPC (Power PC), Sun, ARM, etc. At the REPL, enter *features* to see what type of machine CL thinks you are trying to compile your packages into. If you are not using a Power PC then you shouldn't see PPC as one of the features, for example. If you do see an anomaly such as this that would explain some of the bizarre problems you are having. I can't see a single thing in your writing that directly relates to Hunchentoot. Yes, you had problems, but they relate to the CL and auxiliary packages, not to Hunchentoot. If you want things to change for the better you should be directing your concerns to those package maintainers whose packages gave you trouble. Of all the points you make below, not one stems from a problem in Hunchentoot code. When installing Hunchentoot it helps to have the latest versions of the packages it uses, especially if the support packages are also written by Edi. That may explain some of the problems you had, but I suspect there are deeper issues. On Tue, Mar 15, 2011 at 6:56 PM, Oleg Sivokon wrote: > Hello. > > Please forgive me asking questions with probably obvious answers. I'm new to > the Lisp world in general, and to using Hunchentoot too. > Since I'm new, I had a lot of problems installing Hunchentoot... I had > successfully did it on two Ubuntu 10.4 machines, one 32 bit and another 64 > bit both running last SBCL available from Ubuntu PPA. I had also tried to > record my experience so I could explain it to anyone who asked. If you recorded your experience with specific package versions and error messages that would be useful (not to this ML but to the package maintainers). > I'm > effectively writing a mock-up server to do testing for the project that > otherwise runs in a different environment, yet, at some point I would like > other people to be also able to replicate my steps on installing the server > and running my code. One option is you might be able to provide the Lisp image that you have built so that they do not have to build it themselves. If they are using the same architecture and OS this should work, assuming you can make your CL image available. > Major problems I encountered: > - ASDF does not update... (I know, you have nothing to do with this, yet > whenever the manual on the site mentions ASDF, it would be great if it would > take in account that ASDF not only may do things wrong, it most probably > will...). Long story short, I've tried to update ASDF following manual on > their site - never worked due to some missing methods or just reverting to > the last version w/o any notion. ASDF comes bundled with most of the free CLs. You do not need to install this yourself. In fact, it's better if you don't if it comes with your CL because it's easy to mess up the ASDF installation unless you know exactly how your CL distro installed ASDF. > I've also tried building SBCL from sources. > The last version in development comes with latest ASDF version (2.0), yet > the installation instructions are bizarre and contradict themselves... At > the most successful point I could install what compiles from trunk, but in > order to run that version as root, I would need to specify the sbcl.core on > launch. You should file a bug report with SBCL and ask them to clarify the install process at those areas where you had trouble. If you know what the solutions to your problems are, write them down and submit them to SBCL and maybe they will include them in their install instructions. I don't know why you mention this on a Hunchentoot ML. > I could also install Hunchentoot into this version of SBCL, but it > had problems with UFFI (separate story below). My version of Hunchentoot doesn't load UFFI, but it loads CFFI instead. No problems. > Various other packages in > this mode would report missing files or non-existing functions and so on. If you are referring to SLIME, non-existent functions are not errors or even warnings. SLIME is used by a large number of Lisps and not all Lisps support all of SLIME's API. Those are developer notes that can be ignored (if these are SLIME notes). If this is not SLIME, you should get in contact with the package maintainers. I have never seen these types of messages for Hunchentoot. > It > proved to be unusable. > - ASDF-INSTALL, similarly, trying to install from archive or from site > (clicky) were subsequently unsuccessful. I don't use ASDF-INSTALL since I like to install everything myself. It's actually quite simple: download the package and add one link (in most cases) to the .asd file. > Having only clean SBCL install, > ASDF-INSTALL would break at random trying to solve dependencies. I couldn't > find the pattern. By trial and error I found, that the combination of having > CL-PPCRE, USOCKET, CLOSER-MOP and CXML (!) would most of the time lead to > that Hunchentoot would be able to find all dependencies during install. This > happened 2 times out of maybe 8... Here's a tip: try loading Hunchentoot-dependent packages prior to Hunchentoot by REQUIREing them in a file and evaluating this file. This way you can pre-load your packages and if there are any problems you can see exactly which package is giving you trouble. > - There's some package, which during installation would break the display in > console... (the console will start displaying random non-printable > characters) It would also stop during compile offering different restarts, > where you are forced to play pitch-n-toss :) And if you are lucky, then the > console will recover. Don't know what's going on there. Never seen this. It could be tests, but unlikely. > - Finally, the most sure way I found was to just (require :hunchentoot) > using ASDF v 1 and resolve missing dependencies by hand. Don't do this be hand; put the dependencies in a file and evaluate it prior to loading hunchentoot. > It would sometimes > break when trying to install CL-PPCRE, I have never had a problem loading cl-ppcre. Maybe your packages are out of date. > presumably due to another dependency > having something to do with Unicode, but it succeeded more often then > failed. > - UFFI - for all I tried it failed to compile and install properly always. > It looks like the errors are in *insignificant* tests, yet for an > unexperienced user this looks scary (mistyped pointers?!) :) Often the > errors when compiling this package will also break the installation started > by ASDF - it will not offer to skip the failed compilation, or so I > understood what happened. (I also saw some messages regarding omission of > "dead" code, while compiling this package - this also looks suspicious, why > would anyone release such code, and may there be any connection between > that, and that the code failed to compile in the end?) > Some weird things I saw during installation: an attempt was made to install > SLIME. I can't think of any package that would try to install SLIME. By looking at the compilation notes you should be able to see what package is trying to do this. > It somehow got into dependency list of Hunchentoot... I've > encountered several times notion of 64-bit processor architecture in > different libraries related to Common Lisp as "PPC" - I never heard of this > abbreviation before in this context, (no pun intended), what does it mean? Power PC, the CPU Apple used prior to switching to Intel. If you are on an Intel machine and you have PPC in your lisp features then that would likely cause a lot of problems. > This was one of really confusing places when reading the documentation (I > would assume it to be Apple Motoralla processor from 10 years ago). For > whatever other arcane reason Ubuntu / Debian tech papers call supported > 64-bit processors AMD86 or AMD8664 (some of them having nothing to do with > AMD!). 32-bit Ubuntu/Debian will work with all modern 32-bit Intel and AMD CPUs. Likewise for 64-bit. Last time I checked, everything above a 386 was supported. For the most part, Intel and AMD have the same instruction set so there shouldn't be a problem using either vendor. > Now, my question is, is my experience something you would expect a user to > undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to > develop in more stable environment, do I have to switch to another version > of CL? SBCL is not experimental, but it does have trouble compiling a couple of packages. I find Clozure Common Lisp (CCL) to be more forgiving than SBCL. > (Back in the days I've used CMUCL on Windows, albeit very shortly, > but I don't recall that many problems...) Or are Hunchentoot and SBCL not > really compatible, and the attempt to put them together makes it so > difficult? >From your notes it appears that Hunchentoot has next to nothing to do with your problems. It's the other packages that seem to be giving you problems. > Of course, most chances are I am doing something wrong :) Yet it would be > nice if someone more experience commented. > > Oh, and btw, I've managed to then install CL-GD and use it with Hunchentoot, > for that I had to, again, delete some shared libraries in system folders and > rewrite Make file... It worked, as I said, but, again, I've a feeling I do > things the wrong way and it shouldn't be this difficult... > > And, one last thing, if there are bugs filed against the server, is it > possible to view them somewhere? I've found few bug-trackers during my setup > exercises :) however, I'm not sure which is an official one. > > Thank you. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > If you are interested in getting this fixed, break the problem down into small chunks and try to identify individual problems, providing version numbers (or dates) so that other people can try to reproduce these issues. You should also direct your email to those who are most likely to be in a position to fix them. Since you weren't able to specify a single Hunchentoot problem, this ML is the wrong place to post if you expect people to try to solve any of the problems you had. But since you had so many bizarre problems the odds are the problem is on your end. As previously stated, notes such as what you submitted are not of much use. They are not specific and don't appear to be addressed to the appropriate MLs. There are a couple of ways you can be more specific without making your email too long. You can use paste.lisp.org to save technical output that shows the errors, or you can submit bug reports. From edi at weitz.de Wed Mar 16 11:15:31 2011 From: edi at weitz.de (Edi Weitz) Date: Wed, 16 Mar 2011 12:15:31 +0100 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: On Wed, Mar 16, 2011 at 11:54 AM, Lou Vanek wrote: > When installing Hunchentoot it helps to have the latest versions of > the packages it > uses For which, BTW, Hans provides a convenient starting point in the BKNR repository: http://bknr.net/trac/browser/ediware But I agree with Zach that using Quicklisp seems to be the best strategy nowadays. Cheers, Edi. From haragx at gmail.com Wed Mar 16 11:53:12 2011 From: haragx at gmail.com (Phil Marneweck) Date: Wed, 16 Mar 2011 13:53:12 +0200 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: <1300276392.1786.32.camel@mohadib> Hi Here is a recipe of how to set up Hunchentoot on a server on linux. http://zaries.wordpress.com/2010/11/09/lisp-web-server-from-scratch-using-hunchentoot-and-nginx/ The recipe uses Quicklisp like was suggested in some of the other answers you received. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegsivokon at gmail.com Wed Mar 16 14:10:01 2011 From: olegsivokon at gmail.com (Oleg Sivokon) Date: Wed, 16 Mar 2011 16:10:01 +0200 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: <1300276392.1786.32.camel@mohadib> References: <1300276392.1786.32.camel@mohadib> Message-ID: Thank you for responses. I didn't intend to make it look as if I'm blaming Hunchentoot developers for anything I mentioned above. Sorry if that how it looks. My question was rather: is this an average path for someone to get things working? In attempt to study the subject myself I came across a lot of information, and being new I have sometimes no idea of whether the information is of any real value. For example, my choice of SBCL of all CL variety was based upon comments on Stack Overflow site. I did not try all other kinds. Now, this is not a complaint, I really want to know, if my final goal is to use Hunchentoot, is SBCL a good choice or not? In my experience "more forgiving" tends to give more problems in the end, but I'm not sure what that would meant in given context. Regarding installations - as per my experience with other environments, automatic tools rarely work (Ruby gems would be another perfect example!). Yet I don't know enough to make installations completely by hand, I would much prefer to see this sort of instructions. Again, per my experience, most often an "installation" would scale down to unpacking an archive to several folders and defining several environmental variables, however, I simply don't know which files should go where, and what environmental variables to set, if I wanted to make sure there was not an error on my side. This also leaves me in the situation when I'm clueless as to who to blame for broken installation... I don't even know how the properly working environment looks like... Another reason for asking here is that, again, knowing how it happens with other technologies, it's worth at least to try to figure out if what I'm facing is not some sort of known problem. For instance, I came across a notion of Hunchentoot not installing on SBCL, it was filed against some clone of SBCL on github under category "wishes and future improvements" in April last year. It is unresolved so far. This information helps understanding that there was a problem, yet I cannot figure out if it was ever fixed, and even if it has anything to do with my setup. That's why I asked about bug tracker. It would be ultimately helpful to search some source being certain that the information found may be trusted. This may sound again a silly question... but how would I log what happens during package installation? Often times the console capacity is not enough to accommodate all messages displayed during compile, but I cannot just redirect the output to a file, because I would miss the restarts etc... Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lou.vanek at gmail.com Wed Mar 16 15:23:05 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Wed, 16 Mar 2011 11:23:05 -0400 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: <1300276392.1786.32.camel@mohadib> Message-ID: On Wed, Mar 16, 2011 at 10:10 AM, Oleg Sivokon wrote: > Thank you for responses. I didn't intend to make it look as if I'm blaming > Hunchentoot developers for anything I mentioned above. Sorry if that how it > looks. I am not a hunchentoot committer. Your notes address issues that only tangentially involve hunchentoot. I was serious when I said that if you want to improve your situation you should direct your inquiries to those most interested in resolving them. This ML's primary focus is hunchentoot, not packages that hunchentoot may or may not be using, or SBCL issues. > My question was rather: is this an average path for someone to get > things working? No. You have likely screwed something up but since you provide so few specific details it's hard to tell. I have four CL implementations installed -- and that's on just one of my VMs. When things go south sometimes I'm forced to experiment until a pattern emerges. That often means that I have to expend energy trying to figure out what's going on. > In attempt to study the subject myself I came across a lot > of information, and being new I have sometimes no idea of whether the > information is of any real value. > For example, my choice of SBCL of all CL variety was based upon comments on > Stack Overflow site. I did not try all other kinds. Now, this is not a > complaint, I really want to know, if my final goal is to use Hunchentoot, is > SBCL a good choice or not? SBCL should work with all the common packages that are installed beside hunchentoot, yes, as long as it's a relatively recent SBCL. > In my experience "more forgiving" tends to give > more problems in the end, Not in this case. You don't have much experience. > but I'm not sure what that would meant in given > context. No, you don't. > Regarding installations - as per my experience with other environments, > automatic tools rarely work (Ruby gems would be another perfect example!). > Yet I don't know enough to make installations completely by hand, I would > much prefer to see this sort of instructions. Again, per my experience, most > often an "installation" would scale down to unpacking an archive to several > folders and defining several environmental variables, That's pretty much about it. To install a package that comes with an .asd file, all you have to do is download it, unzip/untar/git/pull/get/whatever the source code and place in a directory. Usually this is a common directory where all lisp library code is stored. It's not important where it is located, just as long as it is readable. Probably a good idea to change permissions of any of these files to anything other than root, preferably to the owner who is going to run CL. Then there is usually one directory where you place all your .asd links. This directory may be called something like site-systems. When ASDF wants to load one of the asdf packages it looks in this directory for a link back to the .asd file that you just installed. So, if you just installed package1 in /var/lib/cl/package1 you would want to add a link to its asd file by doing something like ln -s ../package1/*.asd . assuming that the cwd is /var/lib/cl/site-systems. Make sure that the asdf central repository can be found by asdf: (push "/var/lib/cl/site-systems/" asdf:*central-registry*) This is usually placed in your CL initialization file. For sbcl, this file is called .sbclrc. That's it. Or you could do what others have been advocating and use quicklisp. > however, I simply > don't know which files should go where, and what environmental variables to > set, Usually there are no env vars that require setting. If there are, they are usually set in code when the package loads. > if I wanted to make sure there was not an error on my side. This also > leaves me in the situation when I'm clueless as to who to blame for broken > installation... Look at the compilation messages and look for the package where the errors occur. That package maintainer should be contacted if you are having problems with that package. > I don't even know how the properly working environment looks > like... If you can do a (list-all-packages) and see the package you tried to install, and you didn't see any errors during installation, then that is a properly working environment. Many packages include tests that you can run, also. Each package has a unique method of running the tests, however, so you have to look through the package to see how to run the tests. Many times just loading a test package defined for that package will invoke the tests. And in order for that to work you would, again, have to have an .asd link defined between your asdf central repository directory and the asd file that defines the test package. > Another reason for asking here is that, again, knowing how it happens with > other technologies, it's worth at least to try to figure out if what I'm > facing is not some sort of known problem. For instance, I came across a > notion of Hunchentoot not installing on SBCL, it was filed against some > clone of SBCL on github under category "wishes and future improvements" in > April last year. It is unresolved so far. This information helps > understanding that there was a problem, yet I cannot figure out if it was > ever fixed, and even if it has anything to do with my setup. > That's why I asked about bug tracker. It would be ultimately helpful to > search some source being certain that the information found may be trusted. > > This may sound again a silly question... but how would I log what happens > during package installation? Often times the console capacity is not enough > to accommodate all messages displayed during compile, You don't say how you are running SBCL. If you are running from a command line you can simply increase the history that is saved by your shell. Check the documentation for your shell to see how that can be increased. Another -- preferred -- way to handle this would be to install emacs and slime and do your work in that environment. Emacs saves history and compilation messages when compiling/loading with slime. The internet is full of docs explaining how to set this up. > but I cannot just > redirect the output to a file, because I would miss the restarts etc... > Thank you. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lou.vanek at gmail.com Wed Mar 16 15:34:56 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Wed, 16 Mar 2011 11:34:56 -0400 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: <1300276392.1786.32.camel@mohadib> Message-ID: If you are using an xterm, the setting is, XTerm*saveLines: 1000 From andrew.pennebaker at gmail.com Fri Mar 18 18:17:42 2011 From: andrew.pennebaker at gmail.com (Andrew Pennebaker) Date: Fri, 18 Mar 2011 14:17:42 -0400 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: I also have trouble setting up Hunchentoot. The configurations that work for me are: Hunchentoot / Quicklisp / SBCL / Ubuntu Hunchentoot / Quicklisp / SBCL / MacPorts / Mac OS X Hunchentoot / Quicklisp / ClozureCL / Ubuntu Hunchentoot / Quicklisp / ClozureCL / Mac OS X If you do get Hunchentoot working, please setup a server like this oneto let others know which systems work well with Hunchentoot. Cheers, Andrew Pennebaker www.yellosoft.us On Tue, Mar 15, 2011 at 6:56 PM, Oleg Sivokon wrote: > Hello. > > Please forgive me asking questions with probably obvious answers. I'm new > to the Lisp world in general, and to using Hunchentoot too. > Since I'm new, I had a lot of problems installing Hunchentoot... I had > successfully did it on two Ubuntu 10.4 machines, one 32 bit and another 64 > bit both running last SBCL available from Ubuntu PPA. I had also tried to > record my experience so I could explain it to anyone who asked. I'm > effectively writing a mock-up server to do testing for the project that > otherwise runs in a different environment, yet, at some point I would like > other people to be also able to replicate my steps on installing the server > and running my code. > Major problems I encountered: > - ASDF does not update... (I know, you have nothing to do with this, yet > whenever the manual on the site mentions ASDF, it would be great if it would > take in account that ASDF not only may do things wrong, it most probably > will...). Long story short, I've tried to update ASDF following manual on > their site - never worked due to some missing methods or just reverting to > the last version w/o any notion. I've also tried building SBCL from sources. > The last version in development comes with latest ASDF version (2.0), yet > the installation instructions are bizarre and contradict themselves... At > the most successful point I could install what compiles from trunk, but in > order to run that version as root, I would need to specify the sbcl.core on > launch. I could also install Hunchentoot into this version of SBCL, but it > had problems with UFFI (separate story below). Various other packages in > this mode would report missing files or non-existing functions and so on. It > proved to be unusable. > - ASDF-INSTALL, similarly, trying to install from archive or from site > (clicky) were subsequently unsuccessful. Having only clean SBCL install, > ASDF-INSTALL would break at random trying to solve dependencies. I couldn't > find the pattern. By trial and error I found, that the combination of having > CL-PPCRE, USOCKET, CLOSER-MOP and CXML (!) would most of the time lead to > that Hunchentoot would be able to find all dependencies during install. This > happened 2 times out of maybe 8... > - There's some package, which during installation would break the display > in console... (the console will start displaying random non-printable > characters) It would also stop during compile offering different restarts, > where you are forced to play pitch-n-toss :) And if you are lucky, then the > console will recover. > - Finally, the most sure way I found was to just (require :hunchentoot) > using ASDF v 1 and resolve missing dependencies by hand. It would sometimes > break when trying to install CL-PPCRE, presumably due to another dependency > having something to do with Unicode, but it succeeded more often then > failed. > - UFFI - for all I tried it failed to compile and install properly always. > It looks like the errors are in *insignificant* tests, yet for an > unexperienced user this looks scary (mistyped pointers?!) :) Often the > errors when compiling this package will also break the installation started > by ASDF - it will not offer to skip the failed compilation, or so I > understood what happened. (I also saw some messages regarding omission of > "dead" code, while compiling this package - this also looks suspicious, why > would anyone release such code, and may there be any connection between > that, and that the code failed to compile in the end?) > Some weird things I saw during installation: an attempt was made to install > SLIME. It somehow got into dependency list of Hunchentoot... I've > encountered several times notion of 64-bit processor architecture in > different libraries related to Common Lisp as "PPC" - I never heard of this > abbreviation before in this context, (no pun intended), what does it mean? > This was one of really confusing places when reading the documentation (I > would assume it to be Apple Motoralla processor from 10 years ago). For > whatever other arcane reason Ubuntu / Debian tech papers call supported > 64-bit processors AMD86 or AMD8664 (some of them having nothing to do with > AMD!). > > Now, my question is, is my experience something you would expect a user to > undergo? Is SBCL an experimental brunch of Common Lisp, and, would I want to > develop in more stable environment, do I have to switch to another version > of CL? (Back in the days I've used CMUCL on Windows, albeit very shortly, > but I don't recall that many problems...) Or are Hunchentoot and SBCL not > really compatible, and the attempt to put them together makes it so > difficult? > Of course, most chances are I am doing something wrong :) Yet it would be > nice if someone more experience commented. > > Oh, and btw, I've managed to then install CL-GD and use it with > Hunchentoot, for that I had to, again, delete some shared libraries in > system folders and rewrite Make file... It worked, as I said, but, again, > I've a feeling I do things the wrong way and it shouldn't be this > difficult... > > And, one last thing, if there are bugs filed against the server, is it > possible to view them somewhere? I've found few bug-trackers during my setup > exercises :) however, I'm not sure which is an official one. > > Thank you. > > _______________________________________________ > 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 olegsivokon at gmail.com Sat Mar 19 11:49:53 2011 From: olegsivokon at gmail.com (Oleg Sivokon) Date: Sat, 19 Mar 2011 13:49:53 +0200 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: Hi. Yup, in the end it all worked well. It was more like... trying to set latest Tomcat using 1.4 JRE :) Of course one would get tons of errors if he tried. I am only learning about functional programming, and decided to try Common Lisp for the practical example. As my day job being web-developer, I thought that trying a web-server written in Common Lisp would be a good start. So any time I said "experience", I, in no way, meant experience with Lisp, of course! :) I went so far as to record some of my testing (those which worked ;) here http://www.flasher.ru/forum/blog.php?b=343 . Sorry, that's not in English, and, well, probably the Lisp part of it is silly... but, yey, it worked! :) Best. -------------- next part -------------- An HTML attachment was scrubbed... URL: From archimag at gmail.com Sat Mar 19 12:14:52 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Sat, 19 Mar 2011 15:14:52 +0300 Subject: [hunchentoot-devel] Installing Hunchentoot on SBCL, Ubuntu 10.X In-Reply-To: References: Message-ID: > http://www.flasher.ru/forum/blog.php?b=343 Hmm, if you will have questions about Hunchentoot or Common Lisp, you can also ask for help on http://lisper.ru/. By the way, lisper.ru runs on Hunchentoot. Andrey From fbogdanovic at xnet.hr Sat Mar 19 22:09:56 2011 From: fbogdanovic at xnet.hr (Haris) Date: Sat, 19 Mar 2011 23:09:56 +0100 Subject: [hunchentoot-devel] hunchentoot-mp Message-ID: <87BE74AFBD194BD591D373AD9034A286@komp> Hi. Where do I download hunchentoot-mp package ? Thanks From hans.huebner at gmail.com Sun Mar 20 06:39:12 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun, 20 Mar 2011 07:39:12 +0100 Subject: [hunchentoot-devel] hunchentoot-mp In-Reply-To: <87BE74AFBD194BD591D373AD9034A286@komp> References: <87BE74AFBD194BD591D373AD9034A286@komp> Message-ID: On Sat, Mar 19, 2011 at 11:09 PM, Haris wrote: > Where do I download hunchentoot-mp package ? hunchentoot-mp has been replaced by bordeaux-threads years ago. Please use quicklisp to install hunchentoot if you are new to lisp. It will install all dependencies for you and give you a much better overall experience than chasing dependencies manually or using asdf-install. -Hans From dochang at gmail.com Sun Mar 20 09:33:17 2011 From: dochang at gmail.com (Desmond O. Chang) Date: Sun, 20 Mar 2011 17:33:17 +0800 Subject: [hunchentoot-devel] [PATCH] handle ACCEPTOR-SHUTDOWN-P correctly Message-ID: <1300613597-8534-1-git-send-email-dochang@gmail.com> After stopping an acceptor with STOP, one can't start it again with START, because the START method doesn't reset the value of acceptor-shutdown-p to NIL, so the listener returns/quits instantly. Also, the default value of ACCEPTOR-SHUTDOWN-P should be T, because every acceptor should be closed when it is created. See [1] & [2] for details. [1] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2469 [2] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2868 --- acceptor.lisp | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/acceptor.lisp b/acceptor.lisp index ba90e2e..168c9b9 100644 --- a/acceptor.lisp +++ b/acceptor.lisp @@ -120,7 +120,7 @@ connections.") :documentation "Number of pending connections allowed in the listen socket before the kernel rejects further incoming connections.") - (acceptor-shutdown-p :initform nil + (acceptor-shutdown-p :initform t :accessor acceptor-shutdown-p :documentation "A flag that makes the acceptor shutdown itself when set to something other than NIL.") @@ -266,6 +266,7 @@ they're using secure connections - see the SSL-ACCEPTOR class.")) ;; general implementation (defmethod start ((acceptor acceptor)) + (setf (acceptor-shutdown-p acceptor) nil) (start-listening acceptor) (let ((taskmaster (acceptor-taskmaster acceptor))) (setf (taskmaster-acceptor taskmaster) acceptor) -- 1.7.4.1 From dochang at gmail.com Sun Mar 20 09:37:06 2011 From: dochang at gmail.com (Desmond O. Chang) Date: Sun, 20 Mar 2011 17:37:06 +0800 Subject: [hunchentoot-devel] [PATCH] handle ACCEPTOR-SHUTDOWN-P correctly In-Reply-To: <1300613597-8534-1-git-send-email-dochang@gmail.com> References: <1300613597-8534-1-git-send-email-dochang@gmail.com> Message-ID: I sent this patch here [2] but no response, no reason. So I decide to send it again. If it's still not accepted, I'm going to maintain my own fork somewhere. Thanks, Des From fbogdanovic at xnet.hr Sun Mar 20 13:17:47 2011 From: fbogdanovic at xnet.hr (Haris) Date: Sun, 20 Mar 2011 14:17:47 +0100 Subject: [hunchentoot-devel] hunchentoot-mp References: <87BE74AFBD194BD591D373AD9034A286@komp> Message-ID: I'm asking this because of a tutorial on Hunchentoot page http://myblog.rsynnott.com/2007/10/doing-more-with-hunchentoot-cl-server.html which uses hunchentoot-mp. Does that mean that the tutorial is not valid ? I want to implement user registration in my web app. Is there some tutorial about that (sessions, cookies ...) ? From edi at weitz.de Sun Mar 20 13:28:45 2011 From: edi at weitz.de (Edi Weitz) Date: Sun, 20 Mar 2011 14:28:45 +0100 Subject: [hunchentoot-devel] hunchentoot-mp In-Reply-To: References: <87BE74AFBD194BD591D373AD9034A286@komp> Message-ID: To quote from the Hunchentoot webpage: "Check the dates of these tutorials! Many of them might not be a perfect fit with the latest release of Hunchentoot as there have been several changes to its API recently, especially in 2009. Also, the fact that these tutorials are listed here doesn't necessarily mean that I endorse them or think that they show idiomatic Lisp code. You'll have to decide yourself if they're helpful to you or not." On Sun, Mar 20, 2011 at 2:17 PM, Haris wrote: > I'm asking this because of a tutorial on Hunchentoot page > > http://myblog.rsynnott.com/2007/10/doing-more-with-hunchentoot-cl-server.html > > which uses hunchentoot-mp. > Does that mean that the tutorial is not valid ? > I want to implement user registration in my web app. > Is there some tutorial about that (sessions, cookies ...) ? > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From swm at itasoftware.com Sun Mar 20 13:21:46 2011 From: swm at itasoftware.com (Scott McKay) Date: Sun, 20 Mar 2011 09:21:46 -0400 Subject: [hunchentoot-devel] hunchentoot-mp In-Reply-To: References: <87BE74AFBD194BD591D373AD9034A286@komp> Message-ID: <6306D2A9-2BA1-4AB5-9370-FAC72F58BD2B@itasoftware.com> hunchentoot/doc/index.xml has the definitive H'toot documentation On Mar 20, 2011, at 9:17 AM, Haris wrote: > I'm asking this because of a tutorial on Hunchentoot page > > http://myblog.rsynnott.com/2007/10/doing-more-with-hunchentoot-cl-server.html > > which uses hunchentoot-mp. > Does that mean that the tutorial is not valid ? > I want to implement user registration in my web app. > Is there some tutorial about that (sessions, cookies ...) ? > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From cmpitg at gmail.com Mon Mar 21 02:44:41 2011 From: cmpitg at gmail.com (Duong "Yang" Ha Nguyen) Date: Mon, 21 Mar 2011 09:44:41 +0700 (ICT) Subject: [hunchentoot-devel] [PATCH] handle ACCEPTOR-SHUTDOWN-P correctly In-Reply-To: References: <1300613597-8534-1-git-send-email-dochang@gmail.com> Message-ID: On Sun, 20 Mar 2011, Desmond O. Chang wrote: > I sent this patch here [2] but no response, no reason. So I decide to > send it again. If it's still not accepted, I'm going to maintain my > own fork somewhere. > > Thanks, > Des > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Hi Des, Thank you for your patch. It's very useful so that I've forked a version of Hunchentoot maintained by Andrey (archimag) on github and apply it. Hope it would be integrated into Hunchentoot's main development branch. All the best, Yang -- D??ng "Yang" H? Nguy?n Web log: http://cmpitg.wordpress.com/ "Life is a hack" [ Do not send me M$ Office attachments, please. http://www.gnu.org/philosophy/no-word-attachments.html ] -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/C/ED/L d++ s-:-(:) !a C+++(++++) ULU++++>$ P-- L+++>$ E+++ W++>+++ N+ o+ K w--- O- M@ V- PS+ PE++ Y+>++ PGP++ t+ 5 X+ R- tv+ b+++ DI+++ D++ G+++ e* h* r* y- -----END GEEK CODE BLOCK----- From hans.huebner at gmail.com Mon Mar 21 05:18:46 2011 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 21 Mar 2011 06:18:46 +0100 Subject: [hunchentoot-devel] [PATCH] handle ACCEPTOR-SHUTDOWN-P correctly In-Reply-To: <1300613597-8534-1-git-send-email-dochang@gmail.com> References: <1300613597-8534-1-git-send-email-dochang@gmail.com> Message-ID: On Sun, Mar 20, 2011 at 10:33 AM, Desmond O. Chang wrote: > After stopping an acceptor with STOP, one can't start it again with > START, because the START method doesn't reset the value of > acceptor-shutdown-p to NIL, so the listener returns/quits instantly. > > Also, the default value of ACCEPTOR-SHUTDOWN-P should be T, because > every acceptor should be closed when it is created. I've committed this change. It has been overlooked when it was first submitted. Thanks, Hans > > See [1] & [2] for details. > > [1] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2469 > [2] http://article.gmane.org/gmane.lisp.lib.tbnl.general/2868 > --- > ?acceptor.lisp | ? ?3 ++- > ?1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/acceptor.lisp b/acceptor.lisp > index ba90e2e..168c9b9 100644 > --- a/acceptor.lisp > +++ b/acceptor.lisp > @@ -120,7 +120,7 @@ connections.") > ? ? ? ? ? ? ? ? ? :documentation "Number of pending connections > ? ? ? ? ? allowed in the listen socket before the kernel rejects > ? ? ? ? ? further incoming connections.") > - ? (acceptor-shutdown-p :initform nil > + ? (acceptor-shutdown-p :initform t > ? ? ? ? ? ? ? ? ? ? ? ? :accessor acceptor-shutdown-p > ? ? ? ? ? ? ? ? ? ? ? ? :documentation "A flag that makes the acceptor > ?shutdown itself when set to something other than NIL.") > @@ -266,6 +266,7 @@ they're using secure connections - see the SSL-ACCEPTOR class.")) > ?;; general implementation > > ?(defmethod start ((acceptor acceptor)) > + ?(setf (acceptor-shutdown-p acceptor) nil) > ? (start-listening acceptor) > ? (let ((taskmaster (acceptor-taskmaster acceptor))) > ? ? (setf (taskmaster-acceptor taskmaster) acceptor) > -- > 1.7.4.1 > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From valgusk at inbox.lv Fri Mar 25 09:11:36 2011 From: valgusk at inbox.lv (valgusk lalala) Date: Fri, 25 Mar 2011 11:11:36 +0200 Subject: [hunchentoot-devel] any way to make upload more efficient? Message-ID: <1301044296.4d8c5c482b4c7@mail.inbox.lv> Hi there. I have just started with Hunchentoot. Being also a lisp newcomer i started out with reading tutorials and docs and this one mailing list, where I found some upload problems mentioned and getting interested in testing them out. After installation of hunchentoot (as a standalone server) on sbcl and trying to upload some files I got almost 100% cpu load on the host machine with just one file being uploaded. Then I tested it, hacking the rfc2388 module to only read from stream without processing or writing anything. I got a 50%+ cpu cload. The upload on apache/php is getting 5%. I saw that the lisp is equally heating the cpu just with stream reading-writing by making a separate file read-write test. It's an sbcl stream problem as i see it, nothing can be done here, I guess. It's acceptable for apache being held on this system, but i don't really want to run php alongside with lisp just for file uploads. So, do you think it would be possible to write some foreign module for just the multipart form-data processing and use it with Hunchentoot? Any way to make upload performance reasonable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at weitz.de Fri Mar 25 12:00:19 2011 From: edi at weitz.de (Edi Weitz) Date: Fri, 25 Mar 2011 13:00:19 +0100 Subject: [hunchentoot-devel] any way to make upload more efficient? In-Reply-To: <1301044296.4d8c5c482b4c7@mail.inbox.lv> References: <1301044296.4d8c5c482b4c7@mail.inbox.lv> Message-ID: On Fri, Mar 25, 2011 at 10:11 AM, valgusk lalala wrote: > So, do you think it would be possible to write some foreign module for just > the multipart form-data processing and use it with Hunchentoot? Any way to > make upload performance reasonable? First of all, we always meant to rewrite the RFC 2388 module anyway, but we haven't found the time for it so far, and obviously this stuff wasn't important enough that someone threatened to pay for it... :) If someone finds a way to make file uploads significantly more efficient in a portable way, I'm all for it and would happily accept patches adhering to the usual rules. However, I'm not interested in solutions based on foreign code. The idea of Hunchentoot is to have a stand-alone Lisp solution and if I had infinite time I'd even rewrite the SSL layer in CL... :) BTW, as you're saying that it's an SBCL problem, have you tried with other Lisps? If this is a real problem for you, alternative solutions might be to switch to another Lisp (if that helps) or to improve SBCL's stream code (if that's the culprit). Cheers, Edi. From jim.barrows at gmail.com Tue Mar 29 08:19:55 2011 From: jim.barrows at gmail.com (Jim Barrows) Date: Tue, 29 Mar 2011 01:19:55 -0700 Subject: [hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods. Message-ID: I have a uri "/my-uri", when a get request is made I want to return whatever information I have, and when a post request made, I want to update that information. I had thought that doing this: (define-easy-handler(get-business :uri "/business" :default-request-type :get)() (with-html-output-to-string (*standard-output* nil :prologue nil :indent t) (format t "{\"success\":true, \"data\": ~a}" (encode-json-plist-to-string (business::find-business))))) (define-easy-handler(post-business :uri "/business" :default-request-type :post) (business-name) (with-html-output-to-string( *standard-output* nil :prologue nil :indent t) (format t "post-business - ~a" business-name))) would accomplish that. However, the second handler is always called, for the get and the post. I'm new to Lisp, and was wondering what I'm missing. Any help would be greatly appreciated. -- James A Barrows -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at tuxteam.de Tue Mar 29 09:38:03 2011 From: rm at tuxteam.de (rm at tuxteam.de) Date: Tue, 29 Mar 2011 11:38:03 +0200 Subject: [hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods. In-Reply-To: References: Message-ID: <20110329093803.GA9487@seid-online.de> On Tue, Mar 29, 2011 at 01:19:55AM -0700, Jim Barrows wrote: > I have a uri "/my-uri", when a get request is made I want to return whatever > information I have, and when a post request made, I want to update that > information. > I had thought that doing this: > > (define-easy-handler(get-business :uri "/business" :default-request-type > :get)() > (with-html-output-to-string (*standard-output* nil :prologue nil :indent t) > (format t "{\"success\":true, \"data\": ~a}" > (encode-json-plist-to-string (business::find-business))))) > > (define-easy-handler(post-business :uri "/business" :default-request-type > :post) (business-name) > (with-html-output-to-string( *standard-output* nil :prologue nil :indent t) > (format t "post-business - ~a" business-name))) > > would accomplish that. However, the second handler is always called, for > the get and the post. > I'm new to Lisp, and was wondering what I'm missing. > Any help would be greatly appreciated. I think you missunderstand the :default-request-type parameter. HT doesn't dispatch on the request type, that parameter only decides where form parameters are taken from (unfortunately, I must say. Writing REST applications would be much easier with a dispatch on request method and uri ...) HTH Ralf Mattes > -- > James A Barrows > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From archimag at gmail.com Tue Mar 29 09:47:01 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Tue, 29 Mar 2011 13:47:01 +0400 Subject: [hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods. In-Reply-To: <20110329093803.GA9487@seid-online.de> References: <20110329093803.GA9487@seid-online.de> Message-ID: > unfortunately, I must say. Writing REST applications would be much > easier with a dispatch on request method and uri ... Hmm, look http://restas.lisper.ru/en/tutorial/hello-world.html#processing-of-post-requests and http://restas.lisper.ru/en/manual/routes.html Andrey From lou.vanek at gmail.com Tue Mar 29 13:52:50 2011 From: lou.vanek at gmail.com (Lou Vanek) Date: Tue, 29 Mar 2011 09:52:50 -0400 Subject: [hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods. In-Reply-To: References: Message-ID: You can still dispatch on request method but you have to write a few lines of code. Did you look at the /info test example that comes with HT? Look at the 7th line of the table produced by this test URL. All the information is there that you need in order to perform a branch on request method. ::: URL: /localhost/info?abc=123 Information Page This page has been called once since its handler was compiled. Some Information provides about this request: (HUNCHENTOOT:HOST) "localhost:8088" (HUNCHENTOOT:ACCEPTOR-ADDRESS WEB::*SERVER*) NIL (HUNCHENTOOT:ACCEPTOR-PORT WEB::*SERVER*) 8088 (HUNCHENTOOT:REMOTE-ADDR*) "127.0.0.1" (HUNCHENTOOT:REMOTE-PORT*) 55593 (HUNCHENTOOT:REAL-REMOTE-ADDR) "::1", ("::1") (HUNCHENTOOT:REQUEST-METHOD*) :GET (HUNCHENTOOT:SCRIPT-NAME*) "/info" (HUNCHENTOOT:QUERY-STRING*) "abc=123" (HUNCHENTOOT:GET-PARAMETERS*) (("abc" . "123")) (HUNCHENTOOT:HEADERS-IN*) ((:HOST . "localhost:8088") (:USER-AGENT . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13") (:ACCEPT . "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8") (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") (:COOKIE . "hunchentoot-session=1%3A6B0FCEA500DFA94C56F6273D56006E9D") (:AUTHORIZATION . "Basic bG91OjEyM2E=") (:X-FORWARDED-FOR . "::1") (:X-FORWARDED-HOST . "localhost") (:X-FORWARDED-SERVER . "::1") (:CONNECTION . "Keep-Alive")) (HUNCHENTOOT:COOKIES-IN*) (("hunchentoot-session" . "1:6B0FCEA500DFA94C56F6273D56006E9D")) (HUNCHENTOOT:USER-AGENT) "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13" (HUNCHENTOOT:REFERER) NIL (HUNCHENTOOT:REQUEST-URI*) "/info?abc=123" (HUNCHENTOOT:SERVER-PROTOCOL*) :HTTP/1.1 On Tue, Mar 29, 2011 at 4:19 AM, Jim Barrows wrote: > I have a uri "/my-uri", when a get request is made I want to return whatever > information I have, and when a post request made, I want to update that > information. > I had thought that doing this: > (define-easy-handler(get-business :uri "/business" :default-request-type > :get)() > (with-html-output-to-string (*standard-output* nil :prologue nil :indent t) > (format t "{\"success\":true, \"data\": ~a}" > (encode-json-plist-to-string (business::find-business))))) > (define-easy-handler(post-business :uri "/business" :default-request-type > :post) (business-name) > (with-html-output-to-string( *standard-output* nil :prologue nil :indent t) > (format t "post-business - ~a" business-name))) > would accomplish that. ?However, the second handler is always called, for > the get and the post. > I'm new to Lisp, and was wondering what I'm missing. > Any help would be greatly appreciated. > -- > James A Barrows > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From jim.barrows at gmail.com Wed Mar 30 03:14:16 2011 From: jim.barrows at gmail.com (Jim Barrows) Date: Tue, 29 Mar 2011 20:14:16 -0700 Subject: [hunchentoot-devel] Questions about using the same uri, but a different function for post and get methods. In-Reply-To: References: Message-ID: I hadn't seen that. Thanks! On Tue, Mar 29, 2011 at 6:52 AM, Lou Vanek wrote: > You can still dispatch on request method but you have to write a few > lines of code. > > Did you look at the /info test example that comes with HT? Look at the > 7th line of the table produced by this test URL. All the information > is there that you need in order to perform a branch on request method. > > > ::: URL: /localhost/info?abc=123 > > Information Page > > This page has been called once since its handler was compiled. > > Some Information provides about this request: > > (HUNCHENTOOT:HOST) > > > > "localhost:8088" > > (HUNCHENTOOT:ACCEPTOR-ADDRESS WEB::*SERVER*) > > > > NIL > > (HUNCHENTOOT:ACCEPTOR-PORT WEB::*SERVER*) > > > > 8088 > > (HUNCHENTOOT:REMOTE-ADDR*) > > > > "127.0.0.1" > > (HUNCHENTOOT:REMOTE-PORT*) > > > > 55593 > > (HUNCHENTOOT:REAL-REMOTE-ADDR) > > > > "::1", > ("::1") > > (HUNCHENTOOT:REQUEST-METHOD*) > > > > :GET > > (HUNCHENTOOT:SCRIPT-NAME*) > > > > "/info" > > (HUNCHENTOOT:QUERY-STRING*) > > > > "abc=123" > > (HUNCHENTOOT:GET-PARAMETERS*) > > > > (("abc" . "123")) > > (HUNCHENTOOT:HEADERS-IN*) > > > > ((:HOST . "localhost:8088") > (:USER-AGENT > . "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) > Gecko/20101206 Ubuntu/10.10 (maverick) Firefox/3.6.13") > (:ACCEPT . > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8") > (:ACCEPT-LANGUAGE . "en-us,en;q=0.5") (:ACCEPT-ENCODING . "gzip,deflate") > (:ACCEPT-CHARSET . "ISO-8859-1,utf-8;q=0.7,*;q=0.7") > (:COOKIE . "hunchentoot-session=1%3A6B0FCEA500DFA94C56F6273D56006E9D") > (:AUTHORIZATION . "Basic bG91OjEyM2E=") (:X-FORWARDED-FOR . "::1") > (:X-FORWARDED-HOST . "localhost") (:X-FORWARDED-SERVER . "::1") > (:CONNECTION . "Keep-Alive")) > > (HUNCHENTOOT:COOKIES-IN*) > > > > (("hunchentoot-session" . "1:6B0FCEA500DFA94C56F6273D56006E9D")) > > (HUNCHENTOOT:USER-AGENT) > > > > "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 > Ubuntu/10.10 (maverick) Firefox/3.6.13" > > (HUNCHENTOOT:REFERER) > > > > NIL > > (HUNCHENTOOT:REQUEST-URI*) > > > > "/info?abc=123" > > (HUNCHENTOOT:SERVER-PROTOCOL*) > > > > :HTTP/1.1 > > On Tue, Mar 29, 2011 at 4:19 AM, Jim Barrows > wrote: > > I have a uri "/my-uri", when a get request is made I want to return > whatever > > information I have, and when a post request made, I want to update that > > information. > > I had thought that doing this: > > (define-easy-handler(get-business :uri "/business" :default-request-type > > :get)() > > (with-html-output-to-string (*standard-output* nil :prologue nil :indent > t) > > (format t "{\"success\":true, \"data\": ~a}" > > (encode-json-plist-to-string (business::find-business))))) > > (define-easy-handler(post-business :uri "/business" :default-request-type > > :post) (business-name) > > (with-html-output-to-string( *standard-output* nil :prologue nil :indent > t) > > (format t "post-business - ~a" business-name))) > > would accomplish that. However, the second handler is always called, for > > the get and the post. > > I'm new to Lisp, and was wondering what I'm missing. > > Any help would be greatly appreciated. > > -- > > James A Barrows > > > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- James A Barrows -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbogdanovic at xnet.hr Wed Mar 30 12:49:37 2011 From: fbogdanovic at xnet.hr (Haris) Date: Wed, 30 Mar 2011 14:49:37 +0200 Subject: [hunchentoot-devel] session-value Message-ID: Hi. Can I increase session value with javascript/parenscript ? For example, I start the session, set a session value 'sum to 0 and then I want to increase its value on :onclick event ? Thanks From kiuma72 at gmail.com Wed Mar 30 16:49:09 2011 From: kiuma72 at gmail.com (Andrea Chiumenti) Date: Wed, 30 Mar 2011 18:49:09 +0200 Subject: [hunchentoot-devel] session-value In-Reply-To: References: Message-ID: session are handled server-side, to increase your value via user interaction you have to use an xhr call. kiuma 2011/3/30 Haris > Hi. > > Can I increase session value with javascript/parenscript ? > For example, I start the session, set a session value 'sum to 0 > and then I want to increase its value on :onclick event ? > > Thanks > > _______________________________________________ > 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 archimag at gmail.com Thu Mar 31 08:22:58 2011 From: archimag at gmail.com (Andrey Moskvitin) Date: Thu, 31 Mar 2011 12:22:58 +0400 Subject: [hunchentoot-devel] Trouble with finish-output in process-connection Message-ID: Hi, A few days ago on the site lisper.ru I started using Hunchentoot from trunk. And found that the system stopped working in a few hours. I watched the behavior of the system during the day and found that some threads do not complete their work and hangs on "finish-ouptut" (in "process-connection"). When they accumulate enough, the work stops. I have this problem on Debian 64-bit with SBCL-1.0.47 and SBCL-1.0.37. I have not had this trouble when used Hunchentoot-1.1.1 After replacing the "finish-output" on "force-output" in the "process-connection" the problem was fixed for me. Andrey From daniel at dbrunner.de Thu Mar 31 09:08:39 2011 From: daniel at dbrunner.de (Daniel Brunner) Date: Thu, 31 Mar 2011 11:08:39 +0200 Subject: [hunchentoot-devel] SSL and concurrency crashes Lisp Message-ID: <4D944497.4010601@dbrunner.de> Hi to everybody, I ran into the following problem with the SSL layer: I start my Lisp (CCL or SBCL, doesn't matter) and feed it with these lines: --8<-- (ql:quickload "hunchentoot") (defparameter *server* (hunchentoot:start (make-instance 'hunchentoot:ssl-acceptor :port 4711 :ssl-certificate-file #P"/home/dbr/local-cert.pem" :ssl-privatekey-file #P"/home/dbr/local-key.pem"))) --8<-- Then a SSL-ACCEPTOR is running and serving as wished. But when I use Apache Bench with some concurreny: > ab -f SSL2 -n 1000 -c 4 https://localhost:4711/ then the Lisp crashes and runs into the debugger. E.g. on CCL/Linux: --8<-- ? Unhandled exception 11 at 0x7f1843f1ebe9, context->regs at #x7f184390f428 Exception occurred while executing foreign code at lh_insert + 137 received signal 11; faulting address: 0x7f1843f8fa08 invalid permissions for mapped object --8<-- Or on SBCL/Linux: --8<-- CORRUPTION WARNING in SBCL pid 3549(tid 140737314223872): Memory fault at 0 (pc=0x7ffff4c6f940, sp=0x7ffff59ee280) The integrity of this image is possibly compromised. Continuing with fingers crossed. --8<-- I tested this scenario on different platforms: Clozure CL (1.7-dev-r14406M-trunk but it crashes on older versions as well) - 32 Bit on Windows Server 2003 - 64 Bit on Windows Server 2008 - 32 Bit on Ubuntu 10.04 - 64 Bit on Ubuntu 10.04 (libssl.0.9.8) SBCL 1.0.46 64 Bit on Ubuntu 10.04 (libssl.0.9.8) Used libraries/hunchentoot: - dists/quicklisp/software/cl+ssl-20101006-cvs/ - dists/quicklisp/software/hunchentoot-1.1.1/ Is this a known problem? Does anybody has an idea how to solve it? Kind regards, Daniel. From smanek at gmail.com Thu Mar 31 10:47:43 2011 From: smanek at gmail.com (Shaneal Manek) Date: Thu, 31 Mar 2011 03:47:43 -0700 Subject: [hunchentoot-devel] SSL and concurrency crashes Lisp In-Reply-To: <4D944497.4010601@dbrunner.de> References: <4D944497.4010601@dbrunner.de> Message-ID: A reasonable work around might be to stick hunchentoot behind a reverse proxy (I like nginx) that handles the SSL for it. Then nginx can forward the requests to hunchentoot via straight http. Historically, some lisp web servers were known to behave poorly with certain malformed requests so it was a best practice to put them behind a 'battle hardened' reverse proxy like nginx or apache/mod_proxy anyways. -Shaneal On Thu, Mar 31, 2011 at 2:08 AM, Daniel Brunner wrote: > Hi to everybody, > > I ran into the following problem with the SSL layer: I start my Lisp > (CCL or SBCL, doesn't matter) and feed it with these lines: > > --8<-- > (ql:quickload "hunchentoot") > > (defparameter *server* > ?(hunchentoot:start > ? (make-instance 'hunchentoot:ssl-acceptor > ? ? ? ? ? ? ? ? ?:port 4711 > ? ? ? ? ? ? ? ? ?:ssl-certificate-file #P"/home/dbr/local-cert.pem" > ? ? ? ? ? ? ? ? ?:ssl-privatekey-file ?#P"/home/dbr/local-key.pem"))) > --8<-- > > Then a SSL-ACCEPTOR is running and serving as wished. But when I use > Apache Bench with some concurreny: > >> ab -f SSL2 -n 1000 -c 4 https://localhost:4711/ > > then the Lisp crashes and runs into the debugger. E.g. on CCL/Linux: > > --8<-- > ? Unhandled exception 11 at 0x7f1843f1ebe9, context->regs at #x7f184390f428 > Exception occurred while executing foreign code > ?at lh_insert + 137 > received signal 11; faulting address: 0x7f1843f8fa08 > invalid permissions for mapped object > --8<-- > > Or on SBCL/Linux: > > --8<-- > CORRUPTION WARNING in SBCL pid 3549(tid 140737314223872): > Memory fault at 0 (pc=0x7ffff4c6f940, sp=0x7ffff59ee280) > The integrity of this image is possibly compromised. > Continuing with fingers crossed. > --8<-- > > I tested this scenario on different platforms: > > Clozure CL (1.7-dev-r14406M-trunk but it crashes on older versions as > well) > ?- 32 Bit on Windows Server 2003 > ?- 64 Bit on Windows Server 2008 > ?- 32 Bit on Ubuntu 10.04 > ?- 64 Bit on Ubuntu 10.04 (libssl.0.9.8) > > SBCL 1.0.46 64 Bit on Ubuntu 10.04 (libssl.0.9.8) > > Used libraries/hunchentoot: > - dists/quicklisp/software/cl+ssl-20101006-cvs/ > - dists/quicklisp/software/hunchentoot-1.1.1/ > > > > Is this a known problem? Does anybody has an idea how to solve it? > > > Kind regards, Daniel. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From jetmonk at gmail.com Thu Mar 31 22:59:04 2011 From: jetmonk at gmail.com (JTK) Date: Thu, 31 Mar 2011 12:59:04 -1000 Subject: [hunchentoot-devel] SSL and concurrency crashes Lisp In-Reply-To: <4D944497.4010601@dbrunner.de> References: <4D944497.4010601@dbrunner.de> Message-ID: <6A802DC6-B132-4972-833D-34035DC1F415@gmail.com> On an intel Mac 10.6 the same thing happens: ------ CCL: $ ab -f SSL2 -n 1000 -c 10 https://127.0.0.1:4712/ Unhandled exception 10 at 0x7fff887baf97, context->regs at #xb1aa1660 Exception occurred while executing foreign code at sha1_block_data_order + 87 received signal 10; faulting address: 0x7fff711a3000 ------ SBCL: $ ab -f SSL2 -n 1000 -c 10 https://127.0.0.1:4712/ CORRUPTION WARNING in SBCL pid 73051(tid 33598464): Memory fault at 11 (pc=0x7fff887cd0f5, sp=0xb2a4f00) The integrity of this image is possibly compromised. Continuing with fingers crossed. [2011-03-31 11:53:19 [error]] Error while processing connection: Unhandled memory fault at #x240000000011. ------ Both CCL and SBCL sometimes survive a concurrency of 4, but not 10. SSL is thread safe, but it is not allowed to use an SSL connection concurrently in several threads. http://www.openssl.org/support/faq.html#PROG1 But a look through h'toot fails to show how this might happen, because process connection is run inside one thread, and the stream is ssl'ized used and closed inside this thread. This happened even after I updated cl+ssl to the latest common-lisp.net version. John On Mar 30, 2011, at 11:08 PM, Daniel Brunner wrote: > Hi to everybody, > > I ran into the following problem with the SSL layer: I start my Lisp > (CCL or SBCL, doesn't matter) and feed it with these lines: > > --8<-- > (ql:quickload "hunchentoot") > > (defparameter *server* > (hunchentoot:start > (make-instance 'hunchentoot:ssl-acceptor > :port 4711 > :ssl-certificate-file #P"/home/dbr/local-cert.pem" > :ssl-privatekey-file #P"/home/dbr/local-key.pem"))) > --8<-- > > Then a SSL-ACCEPTOR is running and serving as wished. But when I use > Apache Bench with some concurreny: > >> ab -f SSL2 -n 1000 -c 4 https://localhost:4711/ > > then the Lisp crashes and runs into the debugger. E.g. on CCL/Linux: > > --8<-- > ? Unhandled exception 11 at 0x7f1843f1ebe9, context->regs at #x7f184390f428 > Exception occurred while executing foreign code > at lh_insert + 137 > received signal 11; faulting address: 0x7f1843f8fa08 > invalid permissions for mapped object > --8<-- > > Or on SBCL/Linux: > > --8<-- > CORRUPTION WARNING in SBCL pid 3549(tid 140737314223872): > Memory fault at 0 (pc=0x7ffff4c6f940, sp=0x7ffff59ee280) > The integrity of this image is possibly compromised. > Continuing with fingers crossed. > --8<-- > > I tested this scenario on different platforms: > > Clozure CL (1.7-dev-r14406M-trunk but it crashes on older versions as > well) > - 32 Bit on Windows Server 2003 > - 64 Bit on Windows Server 2008 > - 32 Bit on Ubuntu 10.04 > - 64 Bit on Ubuntu 10.04 (libssl.0.9.8) > > SBCL 1.0.46 64 Bit on Ubuntu 10.04 (libssl.0.9.8) > > Used libraries/hunchentoot: > - dists/quicklisp/software/cl+ssl-20101006-cvs/ > - dists/quicklisp/software/hunchentoot-1.1.1/ > > > > Is this a known problem? Does anybody has an idea how to solve it? > > > Kind regards, Daniel. > > _______________________________________________ > 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: