tbnl-devel November 2009

tbnl-devel@common-lisp.net

19 participants
17 discussions

[hunchentoot-devel] Anyone running Hunchentoot on an OpenBSD server?
by Jeff Cunningham 16 Nov '09

16 Nov '09

I'm looking into setting up a Hunchentoot server on an OpenBSD system and right away noticed problems in the notes about building threads into SBCL (it sounds experimental). Lack of thread support would be a problem, wouldn't it? Has anyone run Hunchentoot on OpenBSD before? If so, were you able to use SBCL? If not, what did you use? Thanks. --Jeff

4 8

[hunchentoot-devel] PATCH: cl-webdav using the newer condition from the flexi-streams package
by Matthew Curry 16 Nov '09

16 Nov '09

flexi-streams package changed the name of the condition: flexi-stream-encoding-error to external-format-encoding-error Patch to cl-webdav attached. -Matt

2 2

[hunchentoot-devel] Invoke-debugger
by frode＠netfonds.no 15 Nov '09

15 Nov '09

There are numerous options for what to do when an error occurs while processing a hunchentoot request. But unless I'm missing something, there's no option to (effectively) call invoke-debugger? While developing and debugging, I find this to seeing a log message etc. It's rather easy to modify the standard process-request to call invoke-debugger, but wouldn't it make sense to have something like hunchentoot:*invoke-debugger-on-error-p* ? -- Frode V. Fjeld

5 13

[hunchentoot-devel] Customising PROCESS-REQUEST for continuous output
by Samium Gromoff 15 Nov '09

15 Nov '09

Good day folks, I would like to employ a handler which continuously writes to the socket stream, so that the appended output becomes immediately available to the page viewer. Basically, I'm building a buildbot for CL libraries, and the build process can be long, so I want the feedback to be available as immediately as possible. So, I look at PROCESS-REQUEST and I see that the handler returns before any output is written to the stream. My understanding is that I need to customize PROCESS-REQUEST, unless I want to take over header generation and can tolerate headers re-appended after my output. The easiest way would appear to be subclassing REQUEST and providing a modified method for PROCESS-REQUEST. But it appears that this is impossible to do without affecting all handlers using the same acceptor, as the class of the request employed is the property of the acceptor -- as is mandated by PROCESS-CONNECTION -- which, again, dispatches on the acceptor. So, there appears to be no way to customise hunchentoot in this regard, without changing its request processing workings. Or am I just missing something? regards, Samium Gromoff -- P.S. In case this sounds negative -- it wasn't so intended. Hunchentoot is a really great server! _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

2 2

[hunchentoot-devel] create-folder-dispatcher-and-handler and pathname-name & pathname-type
by frode＠netfonds.no 10 Nov '09

10 Nov '09

Hi, I'm rather new to both hunchentoot and lispworks, so please bear with me. It seems to me that the function create-folder-dispatcher-and-handler uses the test (or (pathname-name base-path) (pathname-type base-path)) to see if base-path is indeed a directory. This fails on my system because both pathname accessors return :UNSPECIFIC, where base-path indeed names a directory. TBNL> (values (lisp-implementation-type) (lisp-implementation-version)) "LispWorks" "5.1.2" Funny thing is, when I do e.g. (pathname-name #p"/foo/bar") at the REPL, NIL is returned, where #p"/foo/bar" is cut'n'pasted from the error I get from hunchentoot. I had to modify the hunchentoot code to print the results from pathname-name to see that :UNSPECIFIC was returned. -- Frode V. Fjeld

4 13

[hunchentoot-devel] Scieneer Common Lisp
by Bob Krzaczek 09 Nov '09

09 Nov '09

Hi, I'm happy to say that I've managed to get most of Hunchentoot up and running on Scieneer Common Lisp (Solaris 10, SPARC, 64 bit) today, with fairly minimal tweaks to its dependencies' sources. Still, I've run into some problems. A handful of the hunchentoot-test pages are coming back with HTTP's Bad Request. So, although it's very promising, it isn't all quite there yet. Anyway, the main reason I'm writing to the list is to ask if anyone else is working on SCL, before I attack this in earnest tomorrow? I just didn't want to step on toes, or duplicate someone else's effort. Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz(a)cis.rit.edu, icbm 43.0848N 77.6789W

2 1

[hunchentoot-devel] No REPL after hunchentoot:start
by quasi 06 Nov '09

06 Nov '09

Hey, I do not get the Slime REPL back after I start the webserver (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I am using the latest Slime from CVS. SBCL 1.0.29 x86-64 on MBP with snow leopard. It works with Allegro 8.1. Am I missing something trivial here? thanks for the help, regards quasi

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

tbnl-devel November 2009