- tbnl-devel@lists.common-lisp.net - mailman3.common-lisp.net

None
by Harrison Maseko 12 Mar '09

12 Mar '09

1 0

[hunchentoot-devel] *catch-errors-p*
by Anthony Fairchild 12 Mar '09

12 Mar '09

Hi, I'm converting my web app over to Hunchentoot 1.0 and I am really missing *catch-errors-p*. I just need errors that occur while processing the http request to signal the debugger. Are there any workarounds to achieve this with the new 1.0 version? I'm using Lispworks 5.1. Thanks! Anthony

4 5

[hunchentoot-devel] developing in hunchentoot
by Eric Abrahamsen 10 Mar '09

10 Mar '09

Hi, I'm relatively new to both Lisp and Hunchentoot, and I've got a question about how experienced developers go about working on a hunchentoot site. Specifically, I've made myself a helper macro to wrap define-easy-handler and make it simpler to add handlers from the REPL. I find that every time I use it, it adds a new entry to the *dispatch-table*. Most often, I'm redefining an existing handler (to expand or correct it) and would rather overwrite that handler with its new version, rather than adding a new entry. I'm finding it awkward to modify my macro so that it checks for an existing handler with that function name and overwrites it – more importantly I'm not certain this is the best way to do it. If any more experienced users were willing to share how they address this issue, and in general what tools they've made to assist in developing a hunchentoot site, this newbie would be very grateful. Thanks, Eric

3 4

[hunchentoot-devel] Setup of Hunchentoot 1.0.0
by Mackram Raydan 10 Mar '09

10 Mar '09

Hey Everyone, I am not sure how everyone got their new Hunchentoot server setup but I had a kind of rough experience and wanted to share so that maybe it is spared from the next guy giving Hunchentoot. Below is my humble experience feel free to tell me where I went wrong (if I did) or in posting possible solutions First off, I use an Ubuntu installation and unfortunately all there repositories for cl code seem to be out of date and hence it will cause alot of pain. I had to go through uninstalling everything for cl downloaded using apt-get. Second, if you choose to use ASDF-INSTALL you are in for some trouble too. I tried ASDF-INSTALL a couple of times but to no avail. Hunchentoot is installed and you can load a server but you can not get it to reply. My guess is that one of the socket code libraries happen to be the problem but I am not sure of that. If it is any help Drakma kept pointing out an issue with sockets! (I can reproduce the error if any one wants). Third and finally, I tried clbuild which I am glad to say works but with a twist. For some reason, which I have not yet gotten to, clbuild can not tell that Hunchentoot depends on Bordeaux-threads (and consequently lift) or Usockets (and consequently split-sequence) and therefore will not download them. I had to install each on its own. After that, everything works beautifully. I am not sure how much this info is actionable, after all it is not an issue of Hunchentoot fundamentally; however without some guidelines to those who do not keep updated libraries (dracs copies :) ) getting Hunchentoot to run might be too much. Just my 2 cents on an otherwise awesome project :) Mackram Raydan Website: www.trailoflight.net (unfortunately does not run Hunchentoot ---- YET). "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo

2 1

[hunchentoot-devel] "Proxy Error" with new Hunchentoot
by Andrei Stebakov 08 Mar '09

08 Mar '09

I got the new version of hunchentoot, modified my code and started the acceptor. When I try to connect to the web pages handled by hunchentoot, I got "Proxy Error" message in the browser without any delay. At the same time I have my production hunchentoot (old version) running without problems. I also tried to put ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentoot into the apache httpd.conf file to use the hunchentoot test package After I start the acceptor (setf acc1 (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 3000))) And run the tests I have a bunch of messages like: "<p>The requested URL /hunchentoot/test/parameter_utf8_get.html was not found on this server.</p>" (BTW, I think there is some discrepancy in the hunchentoot documentation where it say to create proxy port 3000 and then says to create acceptor on port 4242) "sudo sudo netstat -atnp" shows that all servers are running properly. Does it mean that I have some problem with hunchentoot and apache mod_proxy? How can I troubleshoot it? I tried to put a (break) in my own my-list-request-dispatcher, but the request doesn't even get there. I use sbcl-1.0.23 on Ubuntu. Thank you, Andrei

3 5

[hunchentoot-devel] COMET with Hunchentoot?
by Jim Prewett 04 Mar '09

04 Mar '09

Hello, I'm not quite sure what I'm after except that the buzzword seems to be "COMET". AFAICT, much of the time, this involves having javascript send an XMLHttpRequest to the server which the server keeps open until there is data to be sent to the client. Has anyone done anything like this? Does anyone have thoughts on how one might implement something along these lines? All I am really after is some sort of "Server Push" - I'd be happy to hear any thoughts anyone has along these lines. Thanks, Jim James E. Prewett Jim(a)Prewett.org download(a)hpc.unm.edu Systems Team Leader LoGS: http://www.hpc.unm.edu/~download/LoGS/ Designated Security Officer OpenPGP key: pub 1024D/31816D93 HPC Systems Engineer III UNM HPC 505.277.8210

6 16

[hunchentoot-devel] hunchentoot errors
by Harrison Maseko 28 Feb '09

28 Feb '09

Hi all, I just installed Hunchentoot 1.0.0. When I do (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) I get the following error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION HUNCHENTOOT:START-LISTENING (0)> when called with arguments (#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>). [Condition of type SIMPLE-ERROR] 0: [DEFAULT-DEBUGGER] Use default debugger. 1: [ABORT] Return to SLIME's top level. 2: [CLOSE-CONNECTION] Close SLIME connection 3: [ABORT] Exit debugger, returning to top level. I don't understand this message and other similar errors that come up when I try to run the examples in the Hunchentoot documentation. I am a Lisp newbie running SBCL 1.0.6 via Cusp on Vista. Can you help? Harrison.

3 9

[hunchentoot-devel] *print-readably* et al.
by Leslie P. Polzer 27 Feb '09

27 Feb '09

bt:make-thread uses a funny table with custom bindings to initialize standardized globals like *print-readably*. This seriously interferes with applications using Hunchentoot. I have already posted to bordeaux-thread-devel stating that the new thread should probably inherit the values from the parent thread, but things are slow there I think. FYI we now have this in Weblocks to work around at least the aforementioned variable (which causes the biggest problem because a lot of ~S format directives suddenly become trip mines): (defmethod process-connection ((acceptor weblocks-acceptor) socket) (let ((*print-readably* nil)) (call-next-method))) Hunchentoot should probably provide a similar workaround until the thing is sorted out on the BT side. Other rebindings seem to be pretty harmless in comparison, but YMMV. :( Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

3 4

[hunchentoot-devel] A couple of issues in Hunchentoot 1.0.0
by Slawek Zak 27 Feb '09

27 Feb '09

Hi list, Thank you very much for your work on Hunchentoot. It's one of my top Lisp tools! After upgrading to 1.0.0 and trying to port and run some of my apps I found several issues, which might use some looking at :) - stream returned by send-headers is binary now. It used to be a flexi stream.It might be worth mentioning in the documentation that it's necessary to wrap it in flexi stream to write character sequences - do-sessions is gone and *session-db* is internal to hunchentoot - *catch-errors-p* is gone and *http-error-handler* is called with HTTP code only (for error page customisation only?). Not-catching lisp errors by hunchentoot was excellent for debugging - calling reset-sessions outside of request context complains about *acceptor* not being set Thanks again, and all the best to you :) Best Regards, /S

2 2

[hunchentoot-devel] *session-secret*
by Leslie P. Polzer 27 Feb '09

27 Feb '09

When the HT user application does not initialize the session secret before starting the first acceptor, a warning is emitted. However neither *session-secret* nor reset-session-secret are exported from the package, so there's no clean way to handle this. I think it should be initialized automatically without any warning (just mention it in the manual) and the symbols should be exported. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

2 2