[hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga
Hi, I've just released new versions (all called 1.0.0) of Hunchentoot, Drakma, and Chunga. Note that none of these is compatible with earlier versions, so if you upgrade, you'll need to upgrade all of them. If you're using Hunchentoot or Drakma in a production environment and if it works well for you, you probably shouldn't switch. These are releases with a lot of changes and it is pretty likely that they contain bugs. If you're tracking the development, it'd be nice if you could download the new versions and provide feedback, though. The good news: * Hunchentoot has a new architecture that should hopefully make it much easier to extend or to customize it. * Both Huchentoot and Drakma should be faster now. * Now that we finally have release versions again, there are more things to come. Expect 1.0.1, 1.0.2, etc. releases in the next weeks. The bad news: * The Hunchentoot API has changed considerably and you'll have to read the documentation to see how it works now. Of course, we didn't do that to annoy you - we have to change our own web apps as well. We think that the new API is better, though, and that the change was worth it. * Some stuff has been removed, either because it seemed that nobody used it or because we thought it didn't really belong into a web server. Have fun, Edi.
Sorry, just to be clear. Does this mean that if I am pulling using clbuild, I have the latest? I just did an update and it said that everything was up to date. Thanks, Rohan On Thu, Feb 19, 2009 at 2:58 AM, Edi Weitz <edi@agharta.de> wrote:
Hi,
I've just released new versions (all called 1.0.0) of Hunchentoot, Drakma, and Chunga. Note that none of these is compatible with earlier versions, so if you upgrade, you'll need to upgrade all of them.
If you're using Hunchentoot or Drakma in a production environment and if it works well for you, you probably shouldn't switch. These are releases with a lot of changes and it is pretty likely that they contain bugs. If you're tracking the development, it'd be nice if you could download the new versions and provide feedback, though.
The good news:
* Hunchentoot has a new architecture that should hopefully make it much easier to extend or to customize it.
* Both Huchentoot and Drakma should be faster now.
* Now that we finally have release versions again, there are more things to come. Expect 1.0.1, 1.0.2, etc. releases in the next weeks.
The bad news:
* The Hunchentoot API has changed considerably and you'll have to read the documentation to see how it works now. Of course, we didn't do that to annoy you - we have to change our own web apps as well. We think that the new API is better, though, and that the change was worth it.
* Some stuff has been removed, either because it seemed that nobody used it or because we thought it didn't really belong into a web server.
Have fun, Edi.
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, Feb 19, 2009 at 07:47, Rohan Nicholls <rohan.nicholls@googlemail.com> wrote:
Sorry, just to be clear. Does this mean that if I am pulling using clbuild, I have the latest? I just did an update and it said that everything was up to date.
We are not using clbuild and we don't know which source it pulls Hunchentoot and its dependencies from. We have been working off svn://bknr.net/svn/ediware -Hans
On Thu, Feb 19, 2009 at 8:55 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
We are not using clbuild and we don't know which source it pulls Hunchentoot and its dependencies from. We have been working off svn://bknr.net/svn/ediware
I would hope that clbuild pulls the source from weitz.de so that it will eventually be up to date. Maybe there's a delay of some hours?
I would hope that clbuild pulls the source from weitz.de so that it will eventually be up to date. Maybe there's a delay of some hours?
clbuild:747:get_ediware() { clbuild:748: get_darcs $1 http://common-lisp.net/~loliveira/ediware/$1 clbuild never gets tarballs, its basic philosophy is to work with repositories. -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
Thanks for the responses. So it is not the development repository that is being used, but a darcs mirror of it. Okay, I will await an update of the darcs repos. Looking forward to seeing what changes have been made, as I have just started using it for a personal project. Thanks for all the hard work by the hunchentoot dev team. Rohan On Thu, Feb 19, 2009 at 12:59 PM, Leslie P. Polzer <sky@viridian-project.de> wrote:
I would hope that clbuild pulls the source from weitz.de so that it will eventually be up to date. Maybe there's a delay of some hours?
clbuild:747:get_ediware() { clbuild:748: get_darcs $1 http://common-lisp.net/~loliveira/ediware/$1
clbuild never gets tarballs, its basic philosophy is to work with repositories.
-- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Edi Weitz wrote:
Hi,
I've just released new versions (all called 1.0.0) of Hunchentoot, Drakma, and Chunga.
That is cool. Also, will the "bleeding-edge" development still happen in the bknr-svn repository? Chaitanya
Note that none of these is compatible with earlier versions, so if you upgrade, you'll need to upgrade all of them.
If you're using Hunchentoot or Drakma in a production environment and if it works well for you, you probably shouldn't switch. These are releases with a lot of changes and it is pretty likely that they contain bugs. If you're tracking the development, it'd be nice if you could download the new versions and provide feedback, though.
The good news:
* Hunchentoot has a new architecture that should hopefully make it much easier to extend or to customize it.
* Both Huchentoot and Drakma should be faster now.
* Now that we finally have release versions again, there are more things to come. Expect 1.0.1, 1.0.2, etc. releases in the next weeks.
The bad news:
* The Hunchentoot API has changed considerably and you'll have to read the documentation to see how it works now. Of course, we didn't do that to annoy you - we have to change our own web apps as well. We think that the new API is better, though, and that the change was worth it.
* Some stuff has been removed, either because it seemed that nobody used it or because we thought it didn't really belong into a web server.
Have fun, Edi.
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, Feb 19, 2009 at 8:36 AM, Chaitanya Gupta <mail@chaitanyagupta.com> wrote:
That is cool. Also, will the "bleeding-edge" development still happen in the bknr-svn repository?
Yes, I think for now we will continue to use Hans' repository. Edi.
I've just released new versions (all called 1.0.0) of Hunchentoot, Drakma, and Chunga.
That's great news, thanks a lot to everyone responsible for this. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
Thank y'all for your excellent work. I tried Hunchentoot a year or two ago when I was just breaking into webdev, and didn't know enough to use it well. Since then, I've been waiting for a definitive release to try it out again. I look forward to doing some nice Lisp hacking behind my webapps now! ~TJ
I have a small request: could you put up the documentation for the old generation of Hunchentoot, Drakma and Chunga as well? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
On Thu, Feb 19, 2009 at 21:09, Leslie P. Polzer <sky@viridian-project.de> wrote:
I have a small request: could you put up the documentation for the old generation of Hunchentoot, Drakma and Chunga as well?
Just check it out of a repository of your choice. It'd be confusing to have outdated documentation on the primary distribution site. svn://bknr.net/svn/trunk/thirdparty/hunchentoot (drakma, chunga) has some history, certainly not all of it. -Hans
Another thing worth mentioning, in my opinion, is that the old debug capabilities (*catch-errors-p* and *log-lisp-backtraces*) where indeed used (at least by me). So it's a pity not seeing them in the new release. Now the only way I found to get "under the hood" was with *break-on-signals*. -- vsevolod
On Fri, Feb 20, 2009 at 00:16, Vsevolod <vseloved@gmail.com> wrote:
Another thing worth mentioning, in my opinion, is that the old debug capabilities (*catch-errors-p* and *log-lisp-backtraces*) where indeed used (at least by me). So it's a pity not seeing them in the new release. Now the only way I found to get "under the hood" was with *break-on-signals*.
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot. If you want to have bracktraces in your error log, you can easily install your own message logging function using the new :MESSAGE-LOGGER initarg of the ACCEPTOR class. We removed that part of Hunchentoot because it was really the last piece of unportable code that we had, and we did not use it ourselves anyway. Maybe someone can make a good cause for getting it back in. I'm not missing it. -Hans
On Fri, Feb 20, 2009 at 6:48 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
If you want to have bracktraces in your error log, you can easily install your own message logging function using the new :MESSAGE-LOGGER initarg of the ACCEPTOR class.
Not quite. To log backtraces, you'll have to intercept Hunchentoot's error handling mechanism. One way to do it is to use your own request dispatcher (see <http://weitz.de/hunchentoot/#request-dispatch>) and to wrap HANDLER-BIND around it. I had an idea how to make this a bit simpler/clearer, but it didn't make it into the 1.0.0 release, so maybe in the next one. But as Hans said, the functionality for actually retrieving a backtrace was removed on purpose and is very unlikely to reappear. It's not a big deal, though. Grab the previous tarball, extract the version for your Lisp, and put it into your own webapp if you want it. Edi.
Am 20.02.2009 um 08:23 schrieb Edi Weitz:
But as Hans said, the functionality for actually retrieving a backtrace was removed on purpose and is very unlikely to reappear. It's not a big deal, though. Grab the previous tarball, extract the version for your Lisp, and put it into your own webapp if you want it.
Hans said it was removed because it was the only remaining non- portable part. As printing backtraces isn't really a core functionality of a webserver I do not understand why having it only for lw (with conditionals) would have been such a big problem? Just to make it clear - I personally do not miss it - but I would miss some other parts in hunchentoot were Lispworks is specially handled instead of using what is implemented for other lisps (e. g. some taskmanager stuff). There was a time in hunchentoot-dev development were I guessed Hans would throw the baby out with the bath water ;-) - I'm happy to see that this didn't happen. ciao, Jochen -- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:info@crispylogics.com http://www.crispylogics.com
On Fri, Feb 20, 2009 at 11:53 AM, Jochen Schmidt <jsc@crispylogics.com> wrote:
Hans said it was removed because it was the only remaining non-portable part.
More or less. We still maintain a portability layer for timeouts as usocket can't deal with them. We also have a special case for CCL "deadlines".
As printing backtraces isn't really a core functionality of a webserver I do not understand why having it only for lw (with conditionals) would have been such a big problem?
I don't understand the question. The previous release had backtrace functionality for all supported Lisps.
Just to make it clear - I personally do not miss it - but I would miss some other parts in hunchentoot were Lispworks is specially handled instead of using what is implemented for other lisps (e. g. some taskmanager stuff). There was a time in hunchentoot-dev development were I guessed Hans would throw the baby out with the bath water ;-) - I'm happy to see that this didn't happen.
As you might know, Hunchentoot was historically a LW-only library and thus its architecture was based in part on LispWork's way of implementing TCP/IP servers. While Hunchentoot now aims to be portable to several Lisp implementations, my policy still is that I care mostly about the LispWorks port and that's the one I'm working and testing with. Also, I don't want to deal with gazillions of portability libraries just to load a pretty simple and straightforward web server. (I would make an exception for trivial-backtrace as it seems pretty small and self-contained.) There's also a technical reason for keeping LW-specific stuff in there: Doing things the way they are done in usocket now would mean that we'd have to use undocumented and unsupported features of LispWorks. I don't think that's a good idea. So, if you're missing anything specifically for LispWorks or if you think the situation for LispWorks became worse due to the new release, I'm all ears. (Except for the debugging stuff we already discussed. See next release.)
Am 20.02.2009 um 15:35 schrieb Edi Weitz:
As printing backtraces isn't really a core functionality of a webserver I do not understand why having it only for lw (with conditionals) would have been such a big problem?
I don't understand the question. The previous release had backtrace functionality for all supported Lisps.
Sorry - my error - I just didn't understand why portability issues made it necessary to explicitely drop the backtrace stuff.
Just to make it clear - I personally do not miss it - but I would miss some other parts in hunchentoot were Lispworks is specially handled instead of using what is implemented for other lisps (e. g. some taskmanager stuff). There was a time in hunchentoot-dev development were I guessed Hans would throw the baby out with the bath water ;-) - I'm happy to see that this didn't happen.
As you might know, Hunchentoot was historically a LW-only library and thus its architecture was based in part on LispWork's way of implementing TCP/IP servers.
Yes I know - it was one of the reasons I switched from paserve to hunchentoot.
While Hunchentoot now aims to be portable to several Lisp implementations, my policy still is that I care mostly about the LispWorks port and that's the one I'm working and testing with. Also, I don't want to deal with gazillions of portability libraries just to load a pretty simple and straightforward web server. (I would make an exception for trivial-backtrace as it seems pretty small and self-contained.)
Thats exactly my reasoning too. After paserve I used UCW for a while - it just got to hairy to me.
There's also a technical reason for keeping LW-specific stuff in there: Doing things the way they are done in usocket now would mean that we'd have to use undocumented and unsupported features of LispWorks. I don't think that's a good idea.
Yes - thats very important to me too. I've done a significant investment and bought LW licenses for all platforms I support. Using undocumented features is almost always a bad idea even tough being sometimes unavoidable - but it shouldn't be in the case of a plain web server.
So, if you're missing anything specifically for LispWorks or if you think the situation for LispWorks became worse due to the new release, I'm all ears. (Except for the debugging stuff we already discussed. See next release.)
No I'm missing nothing - as I said my beginning my fears did not come true - Hans and you did a very good job and I'm happy to switch my servers to the final hunchentoot-dev asap. ciao, Jochen -- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:info@crispylogics.com http://www.crispylogics.com
On Fri, Feb 20, 2009 at 3:50 PM, Jochen Schmidt <jsc@crispylogics.com> wrote:
I've done a significant investment and bought LW licenses for all platforms I support.
I'm glad to hear that. The Hunchentoot mailing list has more than 180 subscribers now, but I always had the nagging feeling that I was the only active LW user on it... :)
Hans Hübner wrote:
If you want to have bracktraces in your error log, ... I'm not missing it.
I would miss it. The error log backtrace was one of our best friends in debugging those requests where something would go horribly wrong with a user's transaction. Chaitanya
Hans Hübner wrote:
If you want to have bracktraces in your error log, ... I'm not missing it.
I would miss it. The error log backtrace was one of our best friends in debugging those requests where something would go horribly wrong with a user's transaction.
Me too. I agree though that the details of getting the backtrace should be moved to another library (didn't gwk propose TRIVIAL-BACKTRACE?). -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
On Fri, Feb 20, 2009 at 8:24 AM, Chaitanya Gupta <mail@chaitanyagupta.com> wrote:
I would miss it. The error log backtrace was one of our best friends in debugging those requests where something would go horribly wrong with a user's transaction.
We're currently investigating trivial-backtrace and maybe it will make its way into the next Hunchentoot release.
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Is it? For example USOCKET attempts to parse a string that might or might not be an integer in its host resolution mechanism and catches the signal. *BREAK-ON-SIGNALS* always jumps in there which is pretty annoying and gets in my way. One could argue that this particular issue is misbehaviour in USOCKET but then again it's very common to catch signals routinely too. Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/
On Fri, Feb 20, 2009 at 11:01, Leslie P. Polzer <sky@viridian-project.de> wrote:
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Is it? For example USOCKET attempts to parse a string that might or might not be an integer in its host resolution mechanism and catches the signal. *BREAK-ON-SIGNALS* always jumps in there which is pretty annoying and gets in my way.
I fixed that bug in usocket, it is on trunk now. -Hans
Am 20.02.2009 um 06:48 schrieb Hans Hübner:
On Fri, Feb 20, 2009 at 00:16, Vsevolod <vseloved@gmail.com> wrote:
Another thing worth mentioning, in my opinion, is that the old debug capabilities (*catch-errors-p* and *log-lisp-backtraces*) where indeed used (at least by me). So it's a pity not seeing them in the new release. Now the only way I found to get "under the hood" was with *break-on-signals*.
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Thats actually not a feature. With *catch-errors-p* you ended up within an debugger too and it was actually a good thing that it was restricted to hunchentoot. *break-on-signals* is definitely the wrong tool to do that! Following the dev-tree for some time now I have just setup my own error handling using handler-bind in a custom dispatcher - similar to what Edi outlined in his answer. It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone. The new hunchentoot is meant to be more customizable - it actually is, because of fantastic the merits of CL like handler-bind - It would have been nicer (from a library designer perspective) to have this integrated within the protocols though.
If you want to have bracktraces in your error log, you can easily install your own message logging function using the new :MESSAGE-LOGGER initarg of the ACCEPTOR class. We removed that part of Hunchentoot because it was really the last piece of unportable code that we had, and we did not use it ourselves anyway. Maybe someone can make a good cause for getting it back in. I'm not missing it.
Never used that - I prefer using just a lispworks debugger session. ciao, Jochen -- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:info@crispylogics.com http://www.crispylogics.com
On Fri, Feb 20, 2009 at 11:34, Jochen Schmidt <jsc@crispylogics.com> wrote:
It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone.
Can you provide a patch and some text to add to the documentation? -Hans
On Fri, Feb 20, 2009 at 11:34 AM, Jochen Schmidt <jsc@crispylogics.com> wrote:
It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone.
As I said in an earlier mail, the situation will be improved in the next release. I spent three nights this week rewriting the Hunchentoot documentation and right now I'm a bit tired. But this will happen eventually.
Am 20.02.2009 um 15:24 schrieb Edi Weitz:
On Fri, Feb 20, 2009 at 11:34 AM, Jochen Schmidt <jsc@crispylogics.com> wrote:
It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone.
As I said in an earlier mail, the situation will be improved in the next release. I spent three nights this week rewriting the Hunchentoot documentation and right now I'm a bit tired. But this will happen eventually.
Taking Hans suggestion I actually started a little section on error handling for the documentation. I can understand if you want it to do for yourself - but perhaps you're interested in what I've got so far. Drop me a mail if you do. ciao, Jochen -- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83 mailto:info@crispylogics.com http://www.crispylogics.com
On Fri, Feb 20, 2009 at 4:05 PM, Jochen Schmidt <jsc@crispylogics.com> wrote:
Taking Hans suggestion I actually started a little section on error handling for the documentation. I can understand if you want it to do for yourself - but perhaps you're interested in what I've got so far. Drop me a mail if you do.
Thanks. Please send what you have and I'll see to incorporate it into the documentation. (Or it might be obsolete due to the next release. I'm afraid I'm not completely sure about what will be in there and how it'll look.) One thing that Hans just mentioned in private conversation and which I think is quite important: Users of Hunchentoot should not be encouraged to write around methods for existing methods because that means to rely on the fact that these methods currently don't have an around method and won't have one in the future. (There might even be places in the documentation where I wasn't too clear about that.) The recommended way is always to subclass and then to write your own primary methods (which eventually call call-next-method) and/or to write around methods specializing on your own classes.
On Fri, Feb 20, 2009 at 12:34, Jochen Schmidt <jsc@crispylogics.com> wrote:
*BREAK-ON-SIGNALS* is better than what Hunchentoot previously had - You're sent to a the debugger, making actual analysis possible, and the technique works everywhere, not just in Hunchentoot.
Thats actually not a feature. With *catch-errors-p* you ended up within an debugger too and it was actually a good thing that it was restricted to hunchentoot. *break-on-signals* is definitely the wrong tool to do that! Following the dev-tree for some time now I have just setup my own error handling using handler-bind in a custom dispatcher - similar to what Edi outlined in his answer. It should at least be documented how to properly install such a hunchentoot specific error- handler, because it might not be obvious to everyone. The new hunchentoot is meant to be more customizable - it actually is, because of fantastic the merits of CL like handler-bind - It would have been nicer (from a library designer perspective) to have this integrated within the protocols though.
So, I just spent a few hours (successfully) hemming and haw-ing about how to put these suggestions into real code, and this is what I came up with: ;;; An acceptor that invokes the debugger on errors: (defclass debuggable-acceptor (hunchentoot:acceptor) ()) (defmethod process-connection ((*acceptor* debuggable-acceptor) (socket t)) (declare (ignore socket)) (handler-bind ((error #'invoke-debugger)) (call-next-method))) (defmethod acceptor-request-dispatcher ((*acceptor* debuggable-acceptor)) (let ((dispatcher (call-next-method))) (lambda (request) (handler-bind ((error #'invoke-debugger)) (funcall dispatcher request))))) In my development system, I then do (make-instance 'debuggable-acceptor :port 4242) instead of 'hunchentoot:acceptor, and error conditions pop up a swank debugger again. Hope this is useful for everyone else, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs
On Thu, Feb 19, 2009 at 9:09 PM, Leslie P. Polzer <sky@viridian-project.de> wrote:
I have a small request: could you put up the documentation for the old generation of Hunchentoot, Drakma and Chunga as well?
The pre-1.0.0 versions can be downloaded here: http://weitz.de/files/hunchentoot-0.15.7.tar.gz http://weitz.de/files/drakma-0.11.5.tar.gz http://weitz.de/files/chunga-0.4.3.tar.gz http://weitz.de/files/url-rewrite-0.1.1.tar.gz Edi.
participants (10)
-
Andreas Fuchs -
Chaitanya Gupta -
Chris Dean -
Edi Weitz -
Hans Hübner -
Jochen Schmidt -
Leslie P. Polzer -
Rohan Nicholls -
Tab Atkins Jr. -
Vsevolod