From cavandusen at gmail.com Sun Feb 1 04:06:00 2009 From: cavandusen at gmail.com (Chris Van Dusen) Date: Sat, 31 Jan 2009 22:06:00 -0600 Subject: [hunchentoot-devel] Maximum Request Size In-Reply-To: References: <87prigzl0s.fsf@alamut.mobiliz.com.tr> <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com> <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com> Message-ID: <2EF50AC0-5B25-4EFE-875B-FE947505C43D@gmail.com> Egads. My comment was not to beat the dead horse of why Git will save the world, but that using any other version control other than what the project is currently using is a distraction from the goal(s) of the project itself. The Slime mailing list went through this same thing a while back, and I it never got resolved. When I said "fork" I meant if you want to maintain the code under some version control, go right ahead, but don't clutter the mailing list with advocacy for version control. On the other hand, I guess I could go to the version control mailing lists and tell them that they should be using Hunchentoot for their projects' web site. Chris. On Jan 29, 2009, at 10:22 PM, Bob Hutchison wrote: > Hi, > > On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote: > >> It would be, but (at the risk of being presumptuous) allowing for >> easy >> forks and experimentation is not the goal of the maintainers. >> >> >> I could see that as being the goal of a person that wanted to fork >> the >> code and/or experiment. As Edi said, you have the freedom to >> fork..., >> or not. > > This 'fork' business when using git seems to be more due to github > than git, and doesn't normally mean a forked project like, say, the > Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a > bunch of tools that allow for core maintainers (e.g. Edi and Hans) to > keep control of the code base but to have other people contribute > (without worrying about things like commit privileges, and messed up > patch files). This made a *huge* difference to the Rails project > starting last April or so. These two links give more information along > the lines of that on the page linked to by cmo-0: > > modifications> > > > > And they give you shiny baubles like: > > > > This is the arbitrarily chosen (near the top of the most-forked list > with a few forks yet to be pulled) scrit.aculo.us project, 292 forks > -- but still only one script.aculo.us :-) > > I've been using github for my company and my personal work for about > 10 months now. Works well for me. Big wins: > > -- works off line > -- branching and tagging easy and fast > -- master branch can be 'rebased' into the branches, and the > branches > commited as though a single commit (you can, if you want, lose all > those micro commits and sub-branches -- if you look at the github > network/fork graph, each of the forks can be reduced into a single > 'dot' on the master branch, or not). > -- commits are orders of magnitude faster than SVN, at least for me. > > I think git might make things easier for Edi and Hans at the cost of > having to learn it. More importantly, things like Volkan's patch might > be better tested or improved by having people contribute to the fork > rather than the master branch. Keep this kind of thing out of their > hair until it's more ready. > > Cheers, > Bob > >> >> >> Chris. >> >> On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote: >> >>>> What is the plan for the git repository? Why is it needed, what >>>> makes >>>> it useful? >>> >>> i find the following feature helpful (YMMV) >>> >>> http://github.com/guides/pull-requests >>> >>> it will be a helpful tool of using git to allow for easy forks and >>> experimentation and easy cherry pick any changes made by other >>> forks. >>> >>> cmo-0 >>> >>> On Thu, Jan 29, 2009 at 11:27 PM, Hans H?bner >>> wrote: >>>> Hi, >>>> >>>> bknr.net was temporarily down due to a power failure at the data >>>> center. The machine is back up now. >>>> >>> I'm aware of the "centralized maintenance" "problem" of >>>> Subversion, but as Hunchentoot is not going to convert into a >>>> community project (i.e. we'll review all patches that we accept >>>> into >>>> the repository that eventually becomes the release), I'm not sure >>>> how >>>> another level of indirection helps. It may be possible to convince >>>> us >>>> to switch to git if there is a good reason to do so, but that'd >>>> need >>>> some explanation. >>>> >>>> -Hans >>>> >>>> On Thu, Jan 29, 2009 at 18:28, William Halliburton >>>> wrote: >>>>> Hello everyone... >>>>> >>>>> I would like to volunteer any amount of time needed to get Hans's >>>>> changes >>>>> folded into the main repository and/or get the development version >>>>> moving >>>>> forward and more accessible. I am working on a startup that is >>>>> currently >>>>> using hunchentoot and, as chance may have it, I am right about now >>>>> going to >>>>> be digging into hunchentoot and friends as part of a performance >>>>> and >>>>> understanding push. >>>>> >>>>> Currently the BKNR repository is down, but once it gets back up I >>>>> would like >>>>> to set up a git repository of flexi-streams, hunchentoot, chunga, >>>>> and drakma >>>>> and I invite anyone that wishes to help contribute to this effort. >>>>> >>>>> I am most interested in figuring out and testing the performance >>>>> characteristics of the libraries with respects to threading/non- >>>>> threading, >>>>> select/epoll, and proxy/no-proxy on SBCL and am most willing to >>>>> put in the >>>>> time and effort to develop and test these different scenarios. >>>>> >>>>> Thanks to everyone. >>>>> >>>>> Peace, >>>>> Will >>>>> >>>>> On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz wrote: >>>>>> >>>>>> On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Thanks Hans Huebner for his kindly helps and Edi Weitz for his >>>>>>> uninterest in any effort. >>>>>> >>>>>> Volkan, >>>>>> >>>>>> If you think you're somehow entitled to an immediate reply or any >>>>>> action from me just because you sent a patch that is "not well >>>>>> tested" >>>>>> and "doesn't include any documentation", you're obviously living >>>>>> on a >>>>>> different planet or at least you don't know what it means to >>>>>> have a >>>>>> job and a family in addition to taking care of more than a dozen >>>>>> open >>>>>> source libraries in your spare time. I might look at these >>>>>> patches if >>>>>> and when I find the time to work on Hunchentoot again or I might >>>>>> not. >>>>>> If that's not acceptable to you, the license on all of my libs >>>>>> always >>>>>> allows you to fork them and basically do with them whatever you >>>>>> want. >>>>>> >>>>>> For those of you who wonder why Hunchentoot and some other >>>>>> libraries >>>>>> have been in limbo for quite some time now, here's a quick >>>>>> explanation: A company paid Hans to make a couple of additions to >>>>>> Hunchentoot which are now in the bknr.net repository. I also >>>>>> worked >>>>>> on this a bit in my spare time and added some code, mainly for >>>>>> performance improvements. The good thing is that due to Hans' >>>>>> work >>>>>> the development version is much improved in several aspects over >>>>>> the >>>>>> current release. The bad thing is that due to Hans' and my >>>>>> changes >>>>>> the dev versions of Hunchentoot, Chunga, and Drakma have to be >>>>>> released together, because they are mutually incompatible with >>>>>> the >>>>>> released versions. And, for them to become acceptable (for me) >>>>>> release versions, there's a certain amount of clean-up and >>>>>> documentation needed that still has to be done. >>>>>> >>>>>> Now, the deal with the afore-mentioned company was that they >>>>>> would pay >>>>>> Hans and me to do this clean-up and integration work so that we >>>>>> once >>>>>> again have "official" release versions that are feature-wise in >>>>>> sync >>>>>> with the current dev versions. This hasn't happened so far, and >>>>>> right >>>>>> now I fail to see why I should spend a significant amount of my >>>>>> spare >>>>>> time to do this clean-up work when I have more interesting things >>>>>> to >>>>>> do. /Maybe/, this will happen in the future (paid or unpaid), or >>>>>> maybe there'll at some point just be another Hunchentoot release >>>>>> based >>>>>> on 0.15.7 and the dev changes will be lost. Until then, I think >>>>>> the >>>>>> current release isn't perfect, but certainly something that can >>>>>> be >>>>>> used (and is used) without significant problems. >>>>>> >>>>>> Cheers, >>>>>> Edi. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> tbnl-devel site list >>>> tbnl-devel at common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/tbnl-devel >>>> >>> >>> >>> >>> -- >>> It does not matter how fast your code is, if it does not work! >>> >>> _______________________________________________ >>> 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 > > ---- > Bob Hutchison > Recursive Design Inc. > http://www.recursive.ca/ > weblog: http://www.recursive.ca/hutch > > > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From jsc at crispylogics.com Sun Feb 1 10:25:52 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Sun, 1 Feb 2009 11:25:52 +0100 Subject: [hunchentoot-devel] Maximum Request Size In-Reply-To: <2EF50AC0-5B25-4EFE-875B-FE947505C43D@gmail.com> References: <87prigzl0s.fsf@alamut.mobiliz.com.tr> <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com> <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com> <2EF50AC0-5B25-4EFE-875B-FE947505C43D@gmail.com> Message-ID: <8C51EB6F-AE5E-4E92-A742-3A3DE47DAD2F@crispylogics.com> Am 01.02.2009 um 05:06 schrieb Chris Van Dusen: > Egads. > > My comment was not to beat the dead horse of why Git will save the > world, but that using any other version control other than what the > project is currently using is a distraction from the goal(s) of the > project itself. The Slime mailing list went through this same thing a > while back, and I it never got resolved. > > When I said "fork" I meant if you want to maintain the code under some > version control, go right ahead, but don't clutter the mailing list > with advocacy for version control. On the other hand, I guess I could > go to the version control mailing lists and tell them that they should > be using Hunchentoot for their projects' web site. Well said! actually my experience is, that a well done distributed version control system should allow anyone to track a central CVS/SVN repository WITHOUT urging the developers to change their ways. If the release is done, the question may rise up again. I fully understand Hans and Edi, that they want to get their project done their styles. Complete new features or major changes in project infrastructure are just unnecessary distractions. We as a community can help best by testing of whats there, reporting bugs or suggesting/ doing improvements in style and function. If help comes back as a patch it should be well tested, documented and in the sense of what the dev-branch tries to fix (no completely new things). just my ? 0.02 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 at crispylogics.com http://www.crispylogics.com From edi at agharta.de Sun Feb 1 17:42:11 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 1 Feb 2009 12:42:11 -0500 Subject: [hunchentoot-devel] Maximum Request Size In-Reply-To: <8C51EB6F-AE5E-4E92-A742-3A3DE47DAD2F@crispylogics.com> References: <87prigzl0s.fsf@alamut.mobiliz.com.tr> <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com> <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com> <2EF50AC0-5B25-4EFE-875B-FE947505C43D@gmail.com> <8C51EB6F-AE5E-4E92-A742-3A3DE47DAD2F@crispylogics.com> Message-ID: On Sun, Feb 1, 2009 at 5:25 AM, Jochen Schmidt wrote: > just my ? 0.02 Well spent... :) Thanks, Edi. From whalliburton at gmail.com Sun Feb 1 18:34:26 2009 From: whalliburton at gmail.com (William Halliburton) Date: Sun, 1 Feb 2009 13:34:26 -0500 Subject: [hunchentoot-devel] Maximum Request Size In-Reply-To: <8C51EB6F-AE5E-4E92-A742-3A3DE47DAD2F@crispylogics.com> References: <87prigzl0s.fsf@alamut.mobiliz.com.tr> <4e7bd29e0901290928x777c3d71s479d331d49462aaf@mail.gmail.com> <6D64BB22-F36F-4924-84FF-C5FBBF5FB4E6@gmail.com> <2EF50AC0-5B25-4EFE-875B-FE947505C43D@gmail.com> <8C51EB6F-AE5E-4E92-A742-3A3DE47DAD2F@crispylogics.com> Message-ID: <4e7bd29e0902011034l39de1b2ew72f7b8d2f7abda1c@mail.gmail.com> Egads is right. I never intended to start such a discussion was not asking the maintainers to switch version control systems, just that I was about to set up a git repo to help in collaboration and anyone else interested in hacking on the devel version in that manner was happily invited. Very easy to then push any collaborative patches back upstream. Anyhow, I'll sink back into obscurity until I have some real code contributions. Will On Sun, Feb 1, 2009 at 5:25 AM, Jochen Schmidt wrote: > > Am 01.02.2009 um 05:06 schrieb Chris Van Dusen: > > > Egads. > > > > My comment was not to beat the dead horse of why Git will save the > > world, but that using any other version control other than what the > > project is currently using is a distraction from the goal(s) of the > > project itself. The Slime mailing list went through this same thing a > > while back, and I it never got resolved. > > > > When I said "fork" I meant if you want to maintain the code under some > > version control, go right ahead, but don't clutter the mailing list > > with advocacy for version control. On the other hand, I guess I could > > go to the version control mailing lists and tell them that they should > > be using Hunchentoot for their projects' web site. > > Well said! > > actually my experience is, that a well done distributed version > control system should allow anyone to track a central CVS/SVN > repository WITHOUT urging the developers to change their ways. If the > release is done, the question may rise up again. > > I fully understand Hans and Edi, that they want to get their project > done their styles. Complete new features or major changes in project > infrastructure are just unnecessary distractions. We as a community > can help best by testing of whats there, reporting bugs or suggesting/ > doing improvements in style and function. If help comes back as a > patch it should be well tested, documented and in the sense of what > the dev-branch tries to fix (no completely new things). > > just my ? 0.02 > > 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 at crispylogics.com > http://www.crispylogics.com > > > _______________________________________________ > 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 edi at agharta.de Thu Feb 19 01:58:21 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Feb 2009 02:58:21 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga Message-ID: 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. From rohan.nicholls at googlemail.com Thu Feb 19 06:47:48 2009 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Thu, 19 Feb 2009 07:47:48 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: 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 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From mail at chaitanyagupta.com Thu Feb 19 07:36:58 2009 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Thu, 19 Feb 2009 13:06:58 +0530 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: <499D0C1A.9050201@chaitanyagupta.com> 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > > From hans.huebner at gmail.com Thu Feb 19 07:55:23 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 19 Feb 2009 08:55:23 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: On Thu, Feb 19, 2009 at 07:47, Rohan Nicholls 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 From sky at viridian-project.de Thu Feb 19 09:34:02 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 19 Feb 2009 10:34:02 +0100 (CET) Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: <62153.88.73.252.233.1235036042.squirrel@mail.stardawn.org> > 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/ From edi at agharta.de Thu Feb 19 10:38:39 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Feb 2009 11:38:39 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: On Thu, Feb 19, 2009 at 8:55 AM, Hans H?bner 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? From edi at agharta.de Thu Feb 19 10:52:24 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 19 Feb 2009 11:52:24 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <499D0C1A.9050201@chaitanyagupta.com> References: <499D0C1A.9050201@chaitanyagupta.com> Message-ID: On Thu, Feb 19, 2009 at 8:36 AM, Chaitanya Gupta 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. From sky at viridian-project.de Thu Feb 19 11:59:24 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 19 Feb 2009 12:59:24 +0100 (CET) Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: <64604.88.73.252.233.1235044764.squirrel@mail.stardawn.org> > 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/ From jackalmage at gmail.com Thu Feb 19 13:28:13 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Thu, 19 Feb 2009 07:28:13 -0600 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: 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 From rohan.nicholls at googlemail.com Thu Feb 19 15:30:53 2009 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Thu, 19 Feb 2009 16:30:53 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <64604.88.73.252.233.1235044764.squirrel@mail.stardawn.org> References: <64604.88.73.252.233.1235044764.squirrel@mail.stardawn.org> Message-ID: 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 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From ctdean at sokitomi.com Thu Feb 19 18:02:07 2009 From: ctdean at sokitomi.com (Chris Dean) Date: Thu, 19 Feb 2009 10:02:07 -0800 Subject: [hunchentoot-devel] [drakma-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: (Edi Weitz's message of "Thu, 19 Feb 2009 02:58:21 +0100") References: Message-ID: > I've just released new versions (all called 1.0.0) of Hunchentoot, > Drakma, and Chunga. Great news! Thanks for all your work. Cheers, Chris Dean From vseloved at gmail.com Thu Feb 19 18:03:43 2009 From: vseloved at gmail.com (Vsevolod) Date: Thu, 19 Feb 2009 20:03:43 +0200 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> Message-ID: <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> On Thu, Feb 19, 2009 at 1:16 PM, Edi Weitz wrote: > On Thu, Feb 19, 2009 at 12:04 PM, Vsevolod wrote: > > > 1. Last year I've sent a patch to CL+SSL, that allows it to work with > > password-protected private key files. So the appropriate mention in the > docs > > can be removed. > > Thanks, didn't know that. But we'll have to change in ssl.lisp then, > right? Do you have a patch for that? I prepared the patch (it's a copy of how it works for me in the previous version). Basically, it's just an addition of a keyword parameter to the function call in ssl.lisp. It works without any problems with the previous version (for quite a long time now). With 1.0.0. I was as well able to create an acceptor and view the default page over SSL. NIL works for not encrypted key files. The diff it attached. Additionally, I want to report some problems, which I've encountered while testing vesrion 1.0.0. 1. I get USOCKET:CONNECTION-REFUSED-ERROR on (hunchentoot-test:test-hunchentoot "http://localhost:4240") (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the latest versions. flexi-streams v.1.0.7 I was already using). 2. If I do everything manually (setf *server* (make-instance 'hunchentoot:acceptor :port 4242)) (hunchentoot:start *server*) returns. If I browse to the site there's a default page there. But (hunchentoot:stop *server*) hangs. Best regards, Vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl.diff Type: text/x-diff Size: 1704 bytes Desc: not available URL: From sky at viridian-project.de Thu Feb 19 20:09:22 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 19 Feb 2009 21:09:22 +0100 (CET) Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: Message-ID: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> 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/ From hans.huebner at gmail.com Thu Feb 19 21:29:01 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 19 Feb 2009 22:29:01 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> Message-ID: On Thu, Feb 19, 2009 at 21:09, Leslie P. Polzer 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 From vseloved at gmail.com Thu Feb 19 23:16:33 2009 From: vseloved at gmail.com (Vsevolod) Date: Fri, 20 Feb 2009 01:16:33 +0200 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> Message-ID: <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Fri Feb 20 05:48:41 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 20 Feb 2009 06:48:41 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 00:16, Vsevolod 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 From edi at agharta.de Fri Feb 20 07:16:23 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 08:16:23 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> Message-ID: On Thu, Feb 19, 2009 at 9:09 PM, Leslie P. Polzer 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. From edi at agharta.de Fri Feb 20 07:23:36 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 08:23:36 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 6:48 AM, Hans H?bner 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 ) 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. From edi at agharta.de Fri Feb 20 07:34:43 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 08:34:43 +0100 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> Message-ID: On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: > I prepared the patch (it's a copy of how it works for me in the previous > version). Thanks, it's in the dev version now. You forgot to update the docstrings and the documentation, though... > Additionally, I want to report some problems, which I've encountered while > testing vesrion 1.0.0. > 1. I get USOCKET:CONNECTION-REFUSED-ERROR on > (hunchentoot-test:test-hunchentoot "http://localhost:4240") > (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the latest > versions. flexi-streams v.1.0.7 I was already using). > > 2. If I do everything manually (setf *server* (make-instance > 'hunchentoot:acceptor :port 4242)) > (hunchentoot:start *server*) returns. If I browse to the site there's a > default page there. > But (hunchentoot:stop *server*) hangs. You're saying you get this even without SSL? Unfortunately, I don't have an installation of SBCL to test this right now. Hans, do you? BTW, what's the value of bt:*supports-threads-p* for you? From vseloved at gmail.com Fri Feb 20 08:00:14 2009 From: vseloved at gmail.com (Vsevolod) Date: Fri, 20 Feb 2009 10:00:14 +0200 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> Message-ID: <89dc7c5b0902200000o430a2b9fs41323acc83d76dfd@mail.gmail.com> On Fri, Feb 20, 2009 at 9:34 AM, Edi Weitz wrote: > On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: > > > I prepared the patch (it's a copy of how it works for me in the previous > > version). > > Thanks, it's in the dev version now. You forgot to update the > docstrings and the documentation, though... > Sorry. > > Additionally, I want to report some problems, which I've encountered > while > > testing vesrion 1.0.0. > > 1. I get USOCKET:CONNECTION-REFUSED-ERROR on > > (hunchentoot-test:test-hunchentoot "http://localhost:4240") > > (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the > latest > > versions. flexi-streams v.1.0.7 I was already using). > > > > 2. If I do everything manually (setf *server* (make-instance > > 'hunchentoot:acceptor :port 4242)) > > (hunchentoot:start *server*) returns. If I browse to the site there's a > > default page there. > > But (hunchentoot:stop *server*) hangs. > > You're saying you get this even without SSL? Yes. It's independent of SSL and occurred even before making my changes (on a vanilla version). > > BTW, what's the value of bt:*supports-threads-p* for you? T -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at chaitanyagupta.com Fri Feb 20 07:24:36 2009 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Fri, 20 Feb 2009 12:54:36 +0530 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: <499E5AB4.5090302@chaitanyagupta.com> 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 From hans.huebner at gmail.com Fri Feb 20 08:58:27 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 20 Feb 2009 09:58:27 +0100 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: <89dc7c5b0902200000o430a2b9fs41323acc83d76dfd@mail.gmail.com> References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> <89dc7c5b0902200000o430a2b9fs41323acc83d76dfd@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 09:00, Vsevolod wrote: > On Fri, Feb 20, 2009 at 9:34 AM, Edi Weitz wrote: >> On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: >> > But (hunchentoot:stop *server*) hangs. >> >> You're saying you get this even without SSL? > > Yes. It's independent of SSL and occurred even before making my changes (on > a vanilla version). This is a usocket bug that I have a patch for. I will investigate this today and eventually commit a change for the problem. In the mean time, using an older usocket version helps (maybe from 6 months ago). -Hans From sky at viridian-project.de Fri Feb 20 09:59:10 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Fri, 20 Feb 2009 10:59:10 +0100 (CET) Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <499E5AB4.5090302@chaitanyagupta.com> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <499E5AB4.5090302@chaitanyagupta.com> Message-ID: <62136.88.73.203.160.1235123950.squirrel@mail.stardawn.org> > 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/ From sky at viridian-project.de Fri Feb 20 10:01:58 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Fri, 20 Feb 2009 11:01:58 +0100 (CET) Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: <62419.88.73.203.160.1235124118.squirrel@mail.stardawn.org> > *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/ From jsc at crispylogics.com Fri Feb 20 10:34:45 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Fri, 20 Feb 2009 11:34:45 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> Am 20.02.2009 um 06:48 schrieb Hans H?bner: > On Fri, Feb 20, 2009 at 00:16, Vsevolod 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 at crispylogics.com http://www.crispylogics.com From jsc at crispylogics.com Fri Feb 20 10:53:50 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Fri, 20 Feb 2009 11:53:50 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: 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 at crispylogics.com http://www.crispylogics.com From hans.huebner at gmail.com Fri Feb 20 11:13:06 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 20 Feb 2009 12:13:06 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <62419.88.73.203.160.1235124118.squirrel@mail.stardawn.org> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <62419.88.73.203.160.1235124118.squirrel@mail.stardawn.org> Message-ID: On Fri, Feb 20, 2009 at 11:01, Leslie P. Polzer 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 From hans.huebner at gmail.com Fri Feb 20 11:14:40 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 20 Feb 2009 12:14:40 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> Message-ID: On Fri, Feb 20, 2009 at 11:34, Jochen Schmidt 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 From edi at agharta.de Fri Feb 20 14:24:34 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 15:24:34 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> Message-ID: On Fri, Feb 20, 2009 at 11:34 AM, Jochen Schmidt 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. From edi at agharta.de Fri Feb 20 14:35:17 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 15:35:17 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 11:53 AM, Jochen Schmidt 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.) From edi at agharta.de Fri Feb 20 14:20:31 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 15:20:31 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: <499E5AB4.5090302@chaitanyagupta.com> References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <499E5AB4.5090302@chaitanyagupta.com> Message-ID: On Fri, Feb 20, 2009 at 8:24 AM, Chaitanya Gupta 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. From jsc at crispylogics.com Fri Feb 20 14:50:16 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Fri, 20 Feb 2009 15:50:16 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: 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 at crispylogics.com http://www.crispylogics.com From edi at agharta.de Fri Feb 20 14:18:22 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 15:18:22 +0100 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> Message-ID: On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: > Additionally, I want to report some problems, which I've encountered while > testing vesrion 1.0.0. > 1. I get USOCKET:CONNECTION-REFUSED-ERROR on > (hunchentoot-test:test-hunchentoot "http://localhost:4240") > (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the latest > versions. flexi-streams v.1.0.7 I was already using). Some more questions: 1. Did you also use the newest version of Drakma? 2. I guess this is a typo and you really meant "4242"? 3. Does it make a difference if you use "127.0.0.1" instead of "localhost"? 4. Does it make a difference if you run the server and the test in two different Lisp images? Thanks, Edi. From jsc at crispylogics.com Fri Feb 20 15:05:29 2009 From: jsc at crispylogics.com (Jochen Schmidt) Date: Fri, 20 Feb 2009 16:05:29 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> Message-ID: Am 20.02.2009 um 15:24 schrieb Edi Weitz: > On Fri, Feb 20, 2009 at 11:34 AM, Jochen Schmidt > 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 at crispylogics.com http://www.crispylogics.com From edi at agharta.de Fri Feb 20 15:14:48 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 16:14:48 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> <9514BC01-E900-40EE-A393-31C63E2E9BDA@crispylogics.com> Message-ID: On Fri, Feb 20, 2009 at 4:05 PM, Jochen Schmidt 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. From edi at agharta.de Fri Feb 20 15:16:15 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 16:16:15 +0100 Subject: [hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga In-Reply-To: References: <61169.88.73.252.233.1235074162.squirrel@mail.stardawn.org> <89dc7c5b0902191516p3bf140ccp2c11d0cc210e02cf@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 3:50 PM, Jochen Schmidt 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... :) From hans.huebner at gmail.com Fri Feb 20 15:21:57 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 20 Feb 2009 16:21:57 +0100 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 15:18, Edi Weitz wrote: > On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: > >> Additionally, I want to report some problems, which I've encountered while >> testing vesrion 1.0.0. >> 1. I get USOCKET:CONNECTION-REFUSED-ERROR on >> (hunchentoot-test:test-hunchentoot "http://localhost:4240") >> (my lisp is SBCL 1.0.20. I've updated bordeux_threads, chunga to the latest >> versions. flexi-streams v.1.0.7 I was already using). Just as a side note: I verified that hunchentoot-test:test-hunchentoot (sic) passes with no problems, in one image, on sbcl 1.0.21.18 (FreeBSD) multi-threaded. There currently is a problem with stopping and then starting the same acceptor. For some reason, this does not work, so for now, please always create a fresh acceptor object. -Hans From vseloved at gmail.com Fri Feb 20 20:58:51 2009 From: vseloved at gmail.com (Vsevolod) Date: Fri, 20 Feb 2009 22:58:51 +0200 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> Message-ID: <89dc7c5b0902201258u307a96c7xccf599c133fa510b@mail.gmail.com> On Fri, Feb 20, 2009 at 4:18 PM, Edi Weitz wrote: > On Thu, Feb 19, 2009 at 7:03 PM, Vsevolod wrote: > Some more questions: > > 4. Does it make a difference if you run the server and the test in two > different Lisp images? >From this question I understand, that the server should be already running by the time I make the test. Unfortunately, from the doc I've got the impression, that it's some kind of a clever test, that will start the server on it's own, will try to connect to it and will stop it afterwards (maybe it there's a point in doing that this way, because otherwise its not very useful -- it may be easier to browse to the web-page). If I start the server manually, it works. Sorry for the wrong input. Thanks, Vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Fri Feb 20 22:10:38 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 20 Feb 2009 23:10:38 +0100 Subject: [hunchentoot-devel] Hunchentoot new release In-Reply-To: <89dc7c5b0902201258u307a96c7xccf599c133fa510b@mail.gmail.com> References: <89dc7c5b0902190304s24d4297ey7e59933a13f1e698@mail.gmail.com> <89dc7c5b0902191003w323e63cax3415370ccad465c8@mail.gmail.com> <89dc7c5b0902201258u307a96c7xccf599c133fa510b@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 9:58 PM, Vsevolod wrote: > maybe it > there's a point in doing that this way No, actually it's the other way around. The test suite should not be able to start and stop the server, it should just test it from the POV of a client. It shouldn't even be part of Hunchentoot but of Drakma and we will change that. > otherwise its not very > useful -- it may be easier to browse to the web-page The point is that it is faster and less error-prone to not do it manually. > If I start the server manually, it works. That's good to hear. Thanks, Edi. From daniel at dbrunner.de Wed Feb 25 08:50:44 2009 From: daniel at dbrunner.de (Daniel Brunner) Date: Wed, 25 Feb 2009 09:50:44 +0100 Subject: [hunchentoot-devel] New Version: Stop hangs // Problem with usocket Message-ID: <49A50664.4010206@dbrunner.de> I started to test with Hunchentoot 1.0.0 too and I ran into the same problem with the hanging hunchentoot:stop. As mentioned by Hans I installed some erlier versions of usocket. None of the 0.3.* and the 0.4.0 versions I tested worked well. The hunchentoot:stop hangs until I make another request to the web server. Then the stop function terminates. Kind regards, Daniel. From hans.huebner at gmail.com Wed Feb 25 09:30:48 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 25 Feb 2009 10:30:48 +0100 Subject: [hunchentoot-devel] New Version: Stop hangs // Problem with usocket In-Reply-To: <49A50664.4010206@dbrunner.de> References: <49A50664.4010206@dbrunner.de> Message-ID: On Wed, Feb 25, 2009 at 09:50, Daniel Brunner wrote: > I started to test with Hunchentoot 1.0.0 too and I ran into the same > problem with the hanging hunchentoot:stop. > > As mentioned by Hans I installed some erlier versions of usocket. None > of the 0.3.* and the 0.4.0 versions I tested worked well. The bug has been fixed in the Hunchentoot repository. Also, I committed a bug fix for usocket. Until both of them are released, you may want to check out the development versions from svn://bknr.net/svn/ediware There still is a bug in usocket (I think) that makes it impossible to re-start a server when it has been stopped. -Hans From info at jensteich.de Wed Feb 25 16:04:30 2009 From: info at jensteich.de (Jens Teich) Date: Wed, 25 Feb 2009 17:04:30 +0100 Subject: [hunchentoot-devel] time of webserver access Message-ID: <49A56C0E.7070606@jensteich.de> I want to print on my website the time of access

page created in 0.023s

How can I use (time ...) within hunchentoot::define-easy-handler? Or is there any other way to go? Jens From hans.huebner at gmail.com Wed Feb 25 16:51:59 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Wed, 25 Feb 2009 17:51:59 +0100 Subject: [hunchentoot-devel] time of webserver access In-Reply-To: <49A56C0E.7070606@jensteich.de> References: <49A56C0E.7070606@jensteich.de> Message-ID: Hi Jens, I'd use CL:GET-INTERNAL-REAL-TIME to determine the start and end times, calculate a delta, scale it using CL:INTERNAL-TIME-UNITS-PER-SECOND and generate the desired HTML. Maybe wrapped in a macro. HTH, Hans On Wed, Feb 25, 2009 at 17:04, Jens Teich wrote: > I want to print on my website the time of access > >

page created in 0.023s

> > How can I use (time ...) within hunchentoot::define-easy-handler? > > Or is there any other way to go? > > Jens > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From info at jensteich.de Wed Feb 25 17:03:01 2009 From: info at jensteich.de (Jens Teich) Date: Wed, 25 Feb 2009 18:03:01 +0100 Subject: [hunchentoot-devel] time of webserver access In-Reply-To: <49A56C0E.7070606@jensteich.de> References: <49A56C0E.7070606@jensteich.de> Message-ID: <49A579C5.3090207@jensteich.de> Jens Teich schrieb: > I want to print on my website the time of access > >

page created in 0.023s

> > How can I use (time ...) within hunchentoot::define-easy-handler? > > Or is there any other way to go? Just discovered GET-INTERNAL-REAL-TIME and internal-time-units-per-second which solve my problem I think. Jens From sky at viridian-project.de Thu Feb 26 17:41:25 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 26 Feb 2009 18:41:25 +0100 (CET) Subject: [hunchentoot-devel] *session-secret* Message-ID: 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/ From sky at viridian-project.de Thu Feb 26 17:46:06 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Thu, 26 Feb 2009 18:46:06 +0100 (CET) Subject: [hunchentoot-devel] *print-readably* et al. Message-ID: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> 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/ From slawek.zak at gmail.com Thu Feb 26 18:25:09 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Thu, 26 Feb 2009 19:25:09 +0100 Subject: [hunchentoot-devel] A couple of issues in Hunchentoot 1.0.0 Message-ID: <787bbe1c0902261025y2edf8be3q861cfd60a31c11f2@mail.gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Thu Feb 26 19:13:28 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 26 Feb 2009 20:13:28 +0100 Subject: [hunchentoot-devel] *session-secret* In-Reply-To: References: Message-ID: On Thu, Feb 26, 2009 at 6:41 PM, Leslie P. Polzer wrote: > 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. As far as I can see, they're both exported and documented. Edi. From edi at agharta.de Thu Feb 26 19:47:02 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 26 Feb 2009 20:47:02 +0100 Subject: [hunchentoot-devel] *print-readably* et al. In-Reply-To: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> References: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> Message-ID: On Thu, Feb 26, 2009 at 6:46 PM, Leslie P. Polzer wrote: > Hunchentoot should probably provide a similar workaround > until the thing is sorted out on the BT side. I'd rather not have that. I'd prefer to wait until Bordeaux Threads has sorted that out instead of adding a kludge. Until then, user code should take care of this itself. Thanks for the info, though, I didn't know that. Edi. From edi at agharta.de Thu Feb 26 19:52:47 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 26 Feb 2009 20:52:47 +0100 Subject: [hunchentoot-devel] A couple of issues in Hunchentoot 1.0.0 In-Reply-To: <787bbe1c0902261025y2edf8be3q861cfd60a31c11f2@mail.gmail.com> References: <787bbe1c0902261025y2edf8be3q861cfd60a31c11f2@mail.gmail.com> Message-ID: Hi Slawek, On Thu, Feb 26, 2009 at 7:25 PM, Slawek Zak wrote: > 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 The docstring already says that the stream returned is binary. But, yeah, one might add a sentence about flexi streams. > do-sessions is gone and *session-db* is internal to hunchentoot Yes, see the section about customizing session behaviour. You can insert your own session-db method. Or, if you absolutely want to iterate globally across all sessions, you can catch the return value of the default method. > *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 See the recent discussion on the list. The next release will provide some changes w.r.t. error handling and debugging. > calling reset-sessions outside of request context complains about *acceptor* > not being set Yes, that's a consequence of making the session behaviour customizable. Is this a big problem? Thanks for the feedback, Edi. From download at hpc.unm.edu Thu Feb 26 21:01:13 2009 From: download at hpc.unm.edu (Jim Prewett) Date: Thu, 26 Feb 2009 14:01:13 -0700 (MST) Subject: [hunchentoot-devel] COMET with Hunchentoot? Message-ID: 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 at Prewett.org download at 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 From whalliburton at gmail.com Thu Feb 26 22:28:38 2009 From: whalliburton at gmail.com (William Halliburton) Date: Thu, 26 Feb 2009 17:28:38 -0500 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: Message-ID: <4e7bd29e0902261428r3edb44e6mf560ee7aa0c6bf39@mail.gmail.com> I have a working comet system using Hunchentoot. The basic way I'm operating is to have the browser contact the hunchentoot server and the server thread waits on a semaphore. Any other thread can then release the semaphore and cause a reply back to the browser. Hope this helps. I am only using this for development purposes, as I have been having problems with certain browsers, and this will also occupy one of the available browser requests, where many browsers have a very small number available. (defun kill-comet-thread (thread) (warn "KILLING COMET THREAD: ~a" thread) (ignore-errors (destroy-thread thread))) (defun handle-comet () (awhen (session-value 'comet-thread) (kill-comet-thread it)) (setf (session-value 'comet-thread) *current-thread*) (wait-on-semaphore (session-value 'comet-semaphore)) (setf (session-value 'comet-thread) nil) (aif (session-value 'comet-fn) (funcall it))) (defun comet (fn &optional (session *working-session*)) (setf (session-value 'comet-fn session) fn) (signal-semaphore (session-value 'comet-semaphore session))) On Thu, Feb 26, 2009 at 4:01 PM, Jim Prewett wrote: > > 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 at Prewett.org download at 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 > > _______________________________________________ > 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 sky at viridian-project.de Fri Feb 27 08:28:11 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Fri, 27 Feb 2009 09:28:11 +0100 (CET) Subject: [hunchentoot-devel] *session-secret* In-Reply-To: References: Message-ID: <83306a64769c2f7f8c5264509311c5e4.squirrel@mail.stardawn.org> >> However neither *session-secret* nor reset-session-secret are >> exported from the package, so there's no clean way to handle this. > > As far as I can see, they're both exported and documented. Yes, that must've been my mistake. Sorry! Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From hans.huebner at gmail.com Fri Feb 27 12:08:17 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 13:08:17 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: Message-ID: On Thu, Feb 26, 2009 at 22:01, Jim Prewett wrote: > 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. As William has posted as a followup, such a scheme is straightforward to implement with Hunchentoot when you are using the standard multi-threaded mode. In that mode, every new incoming connection is handled by a separate thread, so there is nothing wrong with keeping the handler function waiting for an even, and then return to the client. The issue with that approach is lack of scalability. It will only work well for a restricted number of threads, and you cannot expect it to work with hundreds or thousands of simultaneous connections. I cannot come up with any hard facts or numbers, but I have never seen anyone claim that his Hunchentoot based server works well with more than a few dozen simultaneous connections. Possible issues are the experimental nature of the threads implementation in a popular open source CL implementation, the memory footprint of the threads created, and the difficulty to create bug free multi-threaded programs in general. Successful and reliable COMET style servers are usually implemented using I/O multiplexing: There is only one thread which uses an optimized multiplexing system call to determine which of a number of channels (e.g. sockets) has data waiting to be received or space in its buffer so that the application can send some data. The server application is written in a non-blocking, event oriented style. All blocking operations in such a system are coordinated by the centralized event scheduling mechanism instead of relying on thread synchronization primitives. Hunchentoot, in its current form, does not support I/O multiplexing in that form. With our recent release, we have tried to restructure things so that adding such a mechanism would be easier than it was, but as we do not have the immediate need or funding to fully implement that, we've not completed it. The cleanest way to implement a high performance I/O multiplexing framework that could be used by Hunchentoot would be by implementing multiplexed socket streams using coroutines. Obviously, that would require a coroutine library, and I am not aware of such a thing. Other I/O multiplexing frameworks (i.e. ACE, Twisted, xSocket, iolib) come with their own, specialized HTTP servers which are aware of non-blocking I/O. The reason for this is that event oriented programs need to be structured differently than those which assume a linear flow of control, like Hunchentoot. All this is only relevant if you are planning to server more than a few users. For prototypes, demonstrations and small-scale applications, using threads as kind of an I/O multiplexing mechanism often works. -Hans From hans.huebner at gmail.com Fri Feb 27 12:09:49 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 13:09:49 +0100 Subject: [hunchentoot-devel] *print-readably* et al. In-Reply-To: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> References: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> Message-ID: On Thu, Feb 26, 2009 at 18:46, Leslie P. Polzer wrote: > bt:make-thread uses a funny table with custom bindings to > initialize standardized globals like *print-readably*. Can you be more specific about this? I have not found any funny tables in my copy of bordeaux-threads, and I am also wondering why *print-readably* would be non-nil in the first place. Maybe the global value has been messed with? -Hans From slawek.zak at gmail.com Fri Feb 27 12:11:50 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Fri, 27 Feb 2009 13:11:50 +0100 Subject: [hunchentoot-devel] A couple of issues in Hunchentoot 1.0.0 In-Reply-To: References: <787bbe1c0902261025y2edf8be3q861cfd60a31c11f2@mail.gmail.com> Message-ID: <787bbe1c0902270411t79cf2af3yfefa4fcd8b886a28@mail.gmail.com> > > > do-sessions is gone and *session-db* is internal to hunchentoot > > Yes, see the section about customizing session behaviour. You can > insert your own session-db method. Or, if you absolutely want to > iterate globally across all sessions, you can catch the return value > of the default method. Right. > > *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 > > See the recent discussion on the list. The next release will provide > some changes w.r.t. error handling and debugging. Much appreciated. > > > calling reset-sessions outside of request context complains about > *acceptor* > > not being set > > Yes, that's a consequence of making the session behaviour > customizable. Is this a big problem? > No really. I just have to remember to store the acceptor on a side to be able to reset sessions ;) Thanks, /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispmr at gmail.com Fri Feb 27 11:11:54 2009 From: lispmr at gmail.com (Harrison Maseko) Date: Fri, 27 Feb 2009 13:11:54 +0200 Subject: [hunchentoot-devel] hunchentoot errors Message-ID: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> 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 # when called with arguments (#). [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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sky at viridian-project.de Fri Feb 27 13:07:03 2009 From: sky at viridian-project.de (Leslie P. Polzer) Date: Fri, 27 Feb 2009 14:07:03 +0100 (CET) Subject: [hunchentoot-devel] *print-readably* et al. In-Reply-To: References: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> Message-ID: > Can you be more specific about this? I have not found any funny > tables in my copy of bordeaux-threads, and I am also wondering why > *print-readably* would be non-nil in the first place. Maybe the > global value has been messed with? It's a pretty recent change in BT. See src/bordeaux-threads.lisp:108*. The table is there, I'll leave it to yourself to judge whether it's funny or not. ;) Leslie * my copy of BT is at Sun Jan 11 03:04:10 CET 2009 Stelian Ionescu * Use "Anonymous" as default thread name. -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/ From hans.huebner at gmail.com Fri Feb 27 13:20:33 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 14:20:33 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> References: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> Message-ID: On Fri, Feb 27, 2009 at 12:11, Harrison Maseko wrote: > 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 > > # > when called with arguments > (#). Did you have a previous version of Hunchentoot installed? If so, please make sure that all old .fasl files are removed and that the old version is not in your ASDF search path. If that still does not help, please email again. > 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? We have not done any testing on Windows yet. You are also running a very old SBCL version, which could be a cause for problems. -Hans From hans.huebner at gmail.com Fri Feb 27 13:21:16 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 14:21:16 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: References: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> Message-ID: On Fri, Feb 27, 2009 at 14:20, Hans H?bner wrote: > We have not done any testing on Windows yet. ?You are also running a > very old SBCL version, which could be a cause for problems. (Windows and SBCL to be more precise. Edi tests with Lispworks on Windows regularily). -Hans From edi at agharta.de Fri Feb 27 13:52:16 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 27 Feb 2009 14:52:16 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> References: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> Message-ID: On Fri, Feb 27, 2009 at 12:11 PM, Harrison Maseko wrote: > 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 > > # > > when called with arguments > > (#). > > [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? The short answer is that this should not happen... :) My guess is the problem is SBCL on Windows which still is kind of experimental AFAIK. You should probably use another Lisp. Sorry, I don't have a better idea. Edi. From edi at agharta.de Fri Feb 27 13:53:39 2009 From: edi at agharta.de (Edi Weitz) Date: Fri, 27 Feb 2009 14:53:39 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: References: <49a7ca96.04ff300a.02bf.ffffc70e@mx.google.com> Message-ID: On Fri, Feb 27, 2009 at 2:20 PM, Hans H?bner wrote: > We have not done any testing on Windows yet. I have, FWIW. But only with LispWorks. From hans.huebner at gmail.com Fri Feb 27 14:14:34 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 15:14:34 +0100 Subject: [hunchentoot-devel] *print-readably* et al. In-Reply-To: References: <438789f5c34a5ed619f87aba3ea6cf12.squirrel@mail.stardawn.org> Message-ID: On Fri, Feb 27, 2009 at 14:07, Leslie P. Polzer wrote: > >> Can you be more specific about this? ?I have not found any funny >> tables in my copy of bordeaux-threads, and I am also wondering why >> *print-readably* would be non-nil in the first place. ?Maybe the >> global value has been messed with? > > It's a pretty recent change in BT. See src/bordeaux-threads.lisp:108*. I concur with Edi here: Please have the BT people fix that. -Hans From slawek.zak at gmail.com Fri Feb 27 15:42:26 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Fri, 27 Feb 2009 16:42:26 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: Message-ID: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> On Fri, Feb 27, 2009 at 1:08 PM, Hans H?bner wrote: > On Thu, Feb 26, 2009 at 22:01, Jim Prewett wrote: > > > I'm not quite sure what I'm after except that the buzzword seems to be > > "COMET". > ... > The cleanest way to implement a high performance I/O multiplexing > framework that could be used by Hunchentoot would be by implementing > multiplexed socket streams using coroutines. Obviously, that would > require a coroutine library, and I am not aware of such a thing. > Don't you think that having separate thread handling comet would be simpler? I/O multiplexing to the clients with some sort of message queueing API for requests from the app engine would be sufficient to make it work? The only obstacle for multiplexed I/O is lack of portable non-blocking I/O library. /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Fri Feb 27 16:14:09 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 27 Feb 2009 17:14:09 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> Message-ID: On Fri, Feb 27, 2009 at 16:42, Slawek Zak wrote: > On Fri, Feb 27, 2009 at 1:08 PM, Hans H?bner wrote: >> >> On Thu, Feb 26, 2009 at 22:01, Jim Prewett wrote: >> >> > I'm not quite sure what I'm after except that the buzzword seems to be >> > "COMET". > > ... >> >> The cleanest way to implement a high performance I/O multiplexing >> framework that could be used by Hunchentoot would be by implementing >> multiplexed socket streams using coroutines. ?Obviously, that would >> require a coroutine library, and I am not aware of such a thing. > > Don't you think that having separate thread handling comet would be simpler? > I/O multiplexing to the clients with some sort of message queueing API for > requests from the app engine would be sufficient to make it work? The only > obstacle for multiplexed I/O is lack of portable non-blocking I/O library. Yes, a specialized COMET handling system would be possible. It may make sense to use a specialized task master so that connections which are waiting on a server-side event do not tie up a worker thread. The new taskmaster/acceptor architecture is meant to support that. usocket has recently seen quite some changes to support non-blocking communications, although I think that this work is not yet finished. Working on that would propably be easier than replacing Hunchentoot's networking layer. Nothing of this is on my current task list, sadly. -Hans From vseloved at gmail.com Fri Feb 27 16:22:51 2009 From: vseloved at gmail.com (Vsevolod) Date: Fri, 27 Feb 2009 18:22:51 +0200 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> Message-ID: <89dc7c5b0902270822h3ecb01ddu118b35cf9fa4ad48@mail.gmail.com> There is NIO library (http://common-lisp.net/project/nio/), but it seems forsaken... On Fri, Feb 27, 2009 at 5:42 PM, Slawek Zak wrote: > On Fri, Feb 27, 2009 at 1:08 PM, Hans H?bner wrote: > >> On Thu, Feb 26, 2009 at 22:01, Jim Prewett wrote: >> >> > I'm not quite sure what I'm after except that the buzzword seems to be >> > "COMET". >> > ... > >> The cleanest way to implement a high performance I/O multiplexing >> framework that could be used by Hunchentoot would be by implementing >> multiplexed socket streams using coroutines. Obviously, that would >> require a coroutine library, and I am not aware of such a thing. >> > > Don't you think that having separate thread handling comet would be > simpler? I/O multiplexing to the clients with some sort of message queueing > API for requests from the app engine would be sufficient to make it work? > The only obstacle for multiplexed I/O is lack of portable non-blocking I/O > library. > > /S > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From vseloved at gmail.com Fri Feb 27 16:32:25 2009 From: vseloved at gmail.com (Vsevolod) Date: Fri, 27 Feb 2009 18:32:25 +0200 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: Message-ID: <89dc7c5b0902270832p7cdadf58t520fd9bd8bece061@mail.gmail.com> By the way, there's also SymbolicWeb ( http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing Comet and using Hunchentoot. But somehow its pages on Google(Groups and Code) have gone recently... On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett wrote: > > 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 at Prewett.org download at 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 > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispmr at gmail.com Sat Feb 28 09:20:21 2009 From: lispmr at gmail.com (Harrison Maseko) Date: Sat, 28 Feb 2009 11:20:21 +0200 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: Message-ID: <49a901ed.0eff300a.33a6.ffffa9ab@mx.google.com> Would this error perhaps shade any light on what the real problem is? ERROR MESSAGE (SBCL 1.0.6 via Cusp on Vista) ; compilation aborted because of fatal error: ; READ failure in COMPILE-FILE: ; READER-ERROR at 17279 (line 352, column 58) on #: ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. WARNING: COMPILE-FILE warned while performing # on #. erred while invoking # on # [Condition of type ASDF:COMPILE-FAILED] 0: [DEFAULT-DEBUGGER] Use default debugger. 1: [RETRY] Retry performing # on #. 2: [ACCEPT] Continue, treating # on # as having been successful. 3: [ABORT] Return to SLIME's top level. 4: [CLOSE-CONNECTION] Close SLIME connection 5: [ABORT] Exit debugger, returning to top level. ]> 1 ; compilation aborted because of fatal error: ; READ failure in COMPILE-FILE: ; READER-ERROR at 17279 (line 352, column 58) on #: ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. WARNING: COMPILE-FILE warned while performing # on #. erred while invoking # on # [Condition of type ASDF:COMPILE-FAILED] 0: [DEFAULT-DEBUGGER] Use default debugger. 1: [RETRY] Retry performing # on #. 2: [ACCEPT] Continue, treating # on # as having been successful. 3: [ABORT] Return to SLIME's top level. 4: [CLOSE-CONNECTION] Close SLIME connection 5: [ABORT] Exit debugger, returning to top level. -----Original Message----- From: Edi Weitz [mailto:edi at agharta.de] Sent: Friday, February 27, 2009 3:52 PM To: General interest list for Hunchentoot and CL-WEBDAV Subject: Re: [hunchentoot-devel] hunchentoot errors On Fri, Feb 27, 2009 at 12:11 PM, Harrison Maseko wrote: > 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 > > # > > when called with arguments > > (#). > > [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? The short answer is that this should not happen... :) My guess is the problem is SBCL on Windows which still is kind of experimental AFAIK. You should probably use another Lisp. Sorry, I don't have a better idea. Edi. _______________________________________________ tbnl-devel site list tbnl-devel at common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel Internal Virus Database is out of date. Checked by AVG. Version: 8.0.169 / Virus Database: 270.11.3/1967 - Release Date: 2/23/2009 7:17 AM From hans.huebner at gmail.com Sat Feb 28 10:27:14 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat, 28 Feb 2009 11:27:14 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <49a901ed.0eff300a.33a6.ffffa9ab@mx.google.com> References: <49a901ed.0eff300a.33a6.ffffa9ab@mx.google.com> Message-ID: Hi, I gave SBCL on windows a brief try and Hunchentoot did not work at all. Similar with CCL. At this current point in time, all I can say is that Hunchentoot does not support SBCL or CCL on Windows until someone really looks into it. -Hans On Sat, Feb 28, 2009 at 10:20, Harrison Maseko wrote: > Would this error perhaps shade any light on what the real problem is? > > ERROR MESSAGE (SBCL 1.0.6 via Cusp on Vista) > ; compilation aborted because of fatal error: > ; ? READ failure in COMPILE-FILE: > ; ? ? READER-ERROR at 17279 (line 352, column 58) on # "file > C:\\Home\\src\\lisp\\Cusp-0.9.390\\New\\eclipse\\plugins\\jasko.tim.lisp.lib > s_1.1.1\\libs\\hunchentoot-1.0.0\\acceptor.lisp" {AC04DA9}>: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. > WARNING: > ? COMPILE-FILE warned while performing # on > ? #. > erred while invoking # on > # > ? [Condition of type ASDF:COMPILE-FAILED] > ? ? ? ?0: [DEFAULT-DEBUGGER] Use default debugger. > ? ? ? ?1: [RETRY] Retry performing # on > #. > ? ? ? ?2: [ACCEPT] Continue, treating # on > # as having been successful. > ? ? ? ?3: [ABORT] Return to SLIME's top level. > ? ? ? ?4: [CLOSE-CONNECTION] Close SLIME connection > ? ? ? ?5: [ABORT] Exit debugger, returning to top level. > ]> 1 > ; compilation aborted because of fatal error: > ; ? READ failure in COMPILE-FILE: > ; ? ? READER-ERROR at 17279 (line 352, column 58) on # "file > C:\\Home\\src\\lisp\\Cusp-0.9.390\\New\\eclipse\\plugins\\jasko.tim.lisp.lib > s_1.1.1\\libs\\hunchentoot-1.0.0\\acceptor.lisp" {B44A299}>: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. > WARNING: > ? COMPILE-FILE warned while performing # on > ? #. > erred while invoking # on > # > ? [Condition of type ASDF:COMPILE-FAILED] > ? ? ? ?0: [DEFAULT-DEBUGGER] Use default debugger. > ? ? ? ?1: [RETRY] Retry performing # on > #. > ? ? ? ?2: [ACCEPT] Continue, treating # on > # as having been successful. > ? ? ? ?3: [ABORT] Return to SLIME's top level. > ? ? ? ?4: [CLOSE-CONNECTION] Close SLIME connection > ? ? ? ?5: [ABORT] Exit debugger, returning to top level. > > > -----Original Message----- > From: Edi Weitz [mailto:edi at agharta.de] > Sent: Friday, February 27, 2009 3:52 PM > To: General interest list for Hunchentoot and CL-WEBDAV > Subject: Re: [hunchentoot-devel] hunchentoot errors > > On Fri, Feb 27, 2009 at 12:11 PM, Harrison Maseko wrote: > >> 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 >> >> # >> >> when called with arguments >> >> (#). >> >> [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? > > The short answer is that this should not happen... :) > > My guess is the problem is SBCL on Windows which still is kind of > experimental AFAIK. ?You should probably use another Lisp. > > Sorry, I don't have a better idea. > > Edi. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Internal Virus Database is out of date. > Checked by AVG. > Version: 8.0.169 / Virus Database: 270.11.3/1967 - Release Date: 2/23/2009 > 7:17 AM > > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From slawek.zak at gmail.com Sat Feb 28 12:41:20 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Sat, 28 Feb 2009 13:41:20 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <89dc7c5b0902270832p7cdadf58t520fd9bd8bece061@mail.gmail.com> References: <89dc7c5b0902270832p7cdadf58t520fd9bd8bece061@mail.gmail.com> Message-ID: <787bbe1c0902280441v7ae18395v5d01b08d3c50d12e@mail.gmail.com> This project has been abandoned by this author, which is unfortunate. In it's late stages it started using new fully asynchronous HTTP server (sw-http) written just for the purpose of speeding up comet. It was before Hunchentoot's taskmanager API. /S On Fri, Feb 27, 2009 at 5:32 PM, Vsevolod wrote: > By the way, there's also SymbolicWeb ( > http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing > Comet and using Hunchentoot. But somehow its pages on Google(Groups and > Code) have gone recently... > > > On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett wrote: > >> >> 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 at Prewett.org download at 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 >> >> _______________________________________________ >> tbnl-devel site list >> tbnl-devel at common-lisp.net >> http://common-lisp.net/mailman/listinfo/tbnl-devel >> > > > > -- > vsevolod > > _______________________________________________ > 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 slawek.zak at gmail.com Sat Feb 28 13:01:37 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Sat, 28 Feb 2009 14:01:37 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> Message-ID: <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> On Fri, Feb 27, 2009 at 5:14 PM, Hans H?bner wrote: > On Fri, Feb 27, 2009 at 16:42, Slawek Zak wrote: > > On Fri, Feb 27, 2009 at 1:08 PM, Hans H?bner > wrote: > >> > >> On Thu, Feb 26, 2009 at 22:01, Jim Prewett > wrote: > >> > >> > I'm not quite sure what I'm after except that the buzzword seems to be > >> > "COMET". > > > > ... > >> > >> The cleanest way to implement a high performance I/O multiplexing > >> framework that could be used by Hunchentoot would be by implementing > >> multiplexed socket streams using coroutines. Obviously, that would > >> require a coroutine library, and I am not aware of such a thing. > > > > Don't you think that having separate thread handling comet would be > simpler? > > I/O multiplexing to the clients with some sort of message queueing API > for > > requests from the app engine would be sufficient to make it work? The > only > > obstacle for multiplexed I/O is lack of portable non-blocking I/O > library. > > Yes, a specialized COMET handling system would be possible. It may > make sense to use a specialized task master so that connections which > are waiting on a server-side event do not tie up a worker thread. The > new taskmaster/acceptor architecture is meant to support that. I see a bit of a problem with that API for this purpose. One would want to somehow distinguish between comet and non-commet calls. To do this you would have to inspect URI or method of the request to spawn a thread or pass the request to dedicated comet handler for example. Handle-incomming-connection is used to customize task creation. It uses process-connection to do the work which in turn calls get-request-data to get URI, method and headers. It's after taskmaster dispatch. It would be nice to be able to handle static content by single thread and dynamic content with one request per thread. Or even proxy the static content via external server. I don't know of any HTTP server able to do this :) Simplest method of implementing it would exposing process-connection API and adding optional argument, say request-info, which would be preloaded with info returned by get-request-data retrieved earlier to decide how to handle the request. Now you would have to rewrite process-connection altogether to get the same effect. usocket has recently seen quite some changes to support non-blocking > communications, although I think that this work is not yet finished. > Working on that would propably be easier than replacing Hunchentoot's > networking layer. Agreed. You must have some insider info on this ;) The only trace of non-blocking socket I/O in usocket that I could find was in two .txt files distributed with usocket 0.4.1 Regards, /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Sat Feb 28 15:10:40 2009 From: edi at agharta.de (Edi Weitz) Date: Sat, 28 Feb 2009 16:10:40 +0100 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: <49a901ed.0eff300a.33a6.ffffa9ab@mx.google.com> References: <49a901ed.0eff300a.33a6.ffffa9ab@mx.google.com> Message-ID: On Sat, Feb 28, 2009 at 10:20 AM, Harrison Maseko wrote: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. Are you using the latest version of usocket? If so, maybe it doesn't support SBCL on Windows correctly (or not at all)? Otherwise, see Hans' reply - none of us uses one of the open source Lisps on Windows, so you're on your own. Help is of course always appreciated. Edi. From download at hpc.unm.edu Sat Feb 28 18:34:45 2009 From: download at hpc.unm.edu (Jim Prewett) Date: Sat, 28 Feb 2009 11:34:45 -0700 (MST) Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <89dc7c5b0902270832p7cdadf58t520fd9bd8bece061@mail.gmail.com> References: <89dc7c5b0902270832p7cdadf58t520fd9bd8bece061@mail.gmail.com> Message-ID: The SymbolicWeb project has been canned according to its author, Lars Nostdal. :P Jim James E. Prewett Jim at Prewett.org download at 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 On Fri, 27 Feb 2009, Vsevolod wrote: > By the way, there's also SymbolicWeb ( > http://en.wikipedia.org/wiki/SymbolicWeb), which advertises to be doing > Comet and using Hunchentoot. But somehow its pages on Google(Groups and > Code) have gone recently... > > On Thu, Feb 26, 2009 at 11:01 PM, Jim Prewett wrote: > > > > > 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 at Prewett.org download at 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 > > > > _______________________________________________ > > tbnl-devel site list > > tbnl-devel at common-lisp.net > > http://common-lisp.net/mailman/listinfo/tbnl-devel > > > > > > -- > vsevolod > From lispmr at gmail.com Sat Feb 28 18:38:30 2009 From: lispmr at gmail.com (Harrison Maseko) Date: Sat, 28 Feb 2009 20:38:30 +0200 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: Message-ID: <49a984c6.03e9300a.6b7d.17eb@mx.google.com> Thanks so much Hans for your prompt input. Now my spirits must settle down and start looking for a way out. Once again thanks. -----Original Message----- From: Hans H?bner [mailto:hans.huebner at gmail.com] Sent: Saturday, February 28, 2009 12:27 PM To: General interest list for Hunchentoot and CL-WEBDAV Subject: Re: [hunchentoot-devel] hunchentoot errors Hi, I gave SBCL on windows a brief try and Hunchentoot did not work at all. Similar with CCL. At this current point in time, all I can say is that Hunchentoot does not support SBCL or CCL on Windows until someone really looks into it. -Hans On Sat, Feb 28, 2009 at 10:20, Harrison Maseko wrote: > Would this error perhaps shade any light on what the real problem is? > > ERROR MESSAGE (SBCL 1.0.6 via Cusp on Vista) ; compilation aborted > because of fatal error: > ; ? READ failure in COMPILE-FILE: > ; ? ? READER-ERROR at 17279 (line 352, column 58) on > # C:\\Home\\src\\lisp\\Cusp-0.9.390\\New\\eclipse\\plugins\\jasko.tim.li > sp.lib s_1.1.1\\libs\\hunchentoot-1.0.0\\acceptor.lisp" {AC04DA9}>: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. > WARNING: > ? COMPILE-FILE warned while performing # on > ? #. > erred while invoking # on # "acceptor" {A68DD79}> > ? [Condition of type ASDF:COMPILE-FAILED] > ? ? ? ?0: [DEFAULT-DEBUGGER] Use default debugger. > ? ? ? ?1: [RETRY] Retry performing # on > #. > ? ? ? ?2: [ACCEPT] Continue, treating # > on # as having been successful. > ? ? ? ?3: [ABORT] Return to SLIME's top level. > ? ? ? ?4: [CLOSE-CONNECTION] Close SLIME connection > ? ? ? ?5: [ABORT] Exit debugger, returning to top level. > ]> 1 > ; compilation aborted because of fatal error: > ; ? READ failure in COMPILE-FILE: > ; ? ? READER-ERROR at 17279 (line 352, column 58) on > # C:\\Home\\src\\lisp\\Cusp-0.9.390\\New\\eclipse\\plugins\\jasko.tim.li > sp.lib s_1.1.1\\libs\\hunchentoot-1.0.0\\acceptor.lisp" {B44A299}>: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. > WARNING: > ? COMPILE-FILE warned while performing # on > ? #. > erred while invoking # on # "acceptor" {A68DD79}> > ? [Condition of type ASDF:COMPILE-FAILED] > ? ? ? ?0: [DEFAULT-DEBUGGER] Use default debugger. > ? ? ? ?1: [RETRY] Retry performing # on > #. > ? ? ? ?2: [ACCEPT] Continue, treating # > on # as having been successful. > ? ? ? ?3: [ABORT] Return to SLIME's top level. > ? ? ? ?4: [CLOSE-CONNECTION] Close SLIME connection > ? ? ? ?5: [ABORT] Exit debugger, returning to top level. > > > -----Original Message----- > From: Edi Weitz [mailto:edi at agharta.de] > Sent: Friday, February 27, 2009 3:52 PM > To: General interest list for Hunchentoot and CL-WEBDAV > Subject: Re: [hunchentoot-devel] hunchentoot errors > > On Fri, Feb 27, 2009 at 12:11 PM, Harrison Maseko wrote: > >> 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 >> >> # >> >> when called with arguments >> >> (#). >> >> [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? > > The short answer is that this should not happen... :) > > My guess is the problem is SBCL on Windows which still is kind of > experimental AFAIK. ?You should probably use another Lisp. > > Sorry, I don't have a better idea. > > Edi. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > Internal Virus Database is out of date. > Checked by AVG. > Version: 8.0.169 / Virus Database: 270.11.3/1967 - Release Date: > 2/23/2009 > 7:17 AM > > > _______________________________________________ > 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 Internal Virus Database is out of date. Checked by AVG. Version: 8.0.169 / Virus Database: 270.11.3/1967 - Release Date: 2/23/2009 7:17 AM From lispmr at gmail.com Sat Feb 28 19:05:31 2009 From: lispmr at gmail.com (Harrison Maseko) Date: Sat, 28 Feb 2009 21:05:31 +0200 Subject: [hunchentoot-devel] hunchentoot errors In-Reply-To: Message-ID: <49a98b26.0116300a.318c.593c@mx.google.com> Yes. I am using USOCKET 0.4.1. Hans' reply is nevertheless assuring; that I am not just doing things right. Thanks for your prompt response, though. -----Original Message----- From: nhabedi at gmail.com [mailto:nhabedi at gmail.com] On Behalf Of Edi Weitz Sent: Saturday, February 28, 2009 5:11 PM To: Harrison Maseko Cc: General interest list for Hunchentoot and CL-WEBDAV Subject: Re: [hunchentoot-devel] hunchentoot errors On Sat, Feb 28, 2009 at 10:20 AM, Harrison Maseko wrote: > ; The symbol "*WILDCARD-HOST*" is not external in the USOCKET package. Are you using the latest version of usocket? If so, maybe it doesn't support SBCL on Windows correctly (or not at all)? Otherwise, see Hans' reply - none of us uses one of the open source Lisps on Windows, so you're on your own. Help is of course always appreciated. Edi. Internal Virus Database is out of date. Checked by AVG. Version: 8.0.169 / Virus Database: 270.11.3/1967 - Release Date: 2/23/2009 7:17 AM