From hans.huebner at gmail.com Mon Mar 2 10:49:57 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 2 Mar 2009 11:49:57 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> Message-ID: On Sat, Feb 28, 2009 at 14:01, Slawek Zak wrote: > On Fri, Feb 27, 2009 at 5:14 PM, Hans H?bner wrote: >> 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. Wouldn't you be able to write a task manager that first reads the request header, then decides whether the request is a COMET request and queue it or hand it over to another thread for processing? You might still want to have multiple connection handling threads in order to have some concurrency in request header reading, but such a scheme should be possible with the current architecture. Or am I missing something? -Hans From edi at agharta.de Mon Mar 2 11:49:00 2009 From: edi at agharta.de (Edi Weitz) Date: Mon, 2 Mar 2009 12:49:00 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> Message-ID: On Mon, Mar 2, 2009 at 11:49 AM, Hans H?bner wrote: > Wouldn't you be able to write a task manager that first reads the > request header, then decides whether the request is a COMET request > and queue it or hand it over to another thread for processing? If you first read the request header, you're interfering with the rest of the architecture which expects to be able to read the whole request including headers from the client. Edi. From hans.huebner at gmail.com Mon Mar 2 13:31:13 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 2 Mar 2009 14:31:13 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> Message-ID: On Mon, Mar 2, 2009 at 12:49, Edi Weitz wrote: > On Mon, Mar 2, 2009 at 11:49 AM, Hans H?bner wrote: > >> Wouldn't you be able to write a task manager that first reads the >> request header, then decides whether the request is a COMET request >> and queue it or hand it over to another thread for processing? > > If you first read the request header, you're interfering with the rest > of the architecture which expects to be able to read the whole request > including headers from the client. The interaction between PROCESS-CONNECTION and PROCESS-REQUEST would need to be revised in a manner that makes it possible for a request handler to return to in a manner that prevents the stream from being closed or polled for data again. As a start, reading the request header, creating the request object instance, processing the request and sending back the reply should be split and made more explicit so that an application could implement a different flow of control, but still use the components that Hunchentoot uses. The COMET acceptor class would then be able to interrogate after the headers of the request have been read and handle COMET requests differently from others. -Hans From slawek.zak at gmail.com Mon Mar 2 17:04:48 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Mon, 2 Mar 2009 18:04:48 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> Message-ID: <787bbe1c0903020904n73cabe37ta042633cced393b9@mail.gmail.com> On Mon, Mar 2, 2009 at 11:49 AM, Hans H?bner wrote: > On Sat, Feb 28, 2009 at 14:01, Slawek Zak wrote: > > On Fri, Feb 27, 2009 at 5:14 PM, Hans H?bner > wrote: > >> 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. > > Wouldn't you be able to write a task manager that first reads the > request header, then decides whether the request is a COMET request > and queue it or hand it over to another thread for processing? You > might still want to have multiple connection handling threads in order > to have some concurrency in request header reading, but such a scheme > should be possible with the current architecture. Or am I missing > something? It is possible, but handle-incomming-connection is now in fact a thin wrapper around process-connection which does all the work, thus having process management depend on request contents requires one to patch or rewrite process-connection to simply avoid reading request data which have been read already. /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From slawek.zak at gmail.com Mon Mar 2 17:07:37 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Mon, 2 Mar 2009 18:07:37 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> Message-ID: <787bbe1c0903020907x4eea4658o70511f1269004283@mail.gmail.com> On Mon, Mar 2, 2009 at 12:49 PM, Edi Weitz wrote: > On Mon, Mar 2, 2009 at 11:49 AM, Hans H?bner > wrote: > > > Wouldn't you be able to write a task manager that first reads the > > request header, then decides whether the request is a COMET request > > and queue it or hand it over to another thread for processing? > > If you first read the request header, you're interfering with the rest > of the architecture which expects to be able to read the whole request > including headers from the client. > You are obviously right. My suggestion was splitting the request retrieval from it's processing (as done by process-connection) to be able to make an informed decission about further processing. Process-connection or any other API devised for this purpose would have to somehow accept request data read up the stack. /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.huebner at gmail.com Mon Mar 2 18:01:27 2009 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 2 Mar 2009 19:01:27 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: <787bbe1c0903020904n73cabe37ta042633cced393b9@mail.gmail.com> References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> <787bbe1c0903020904n73cabe37ta042633cced393b9@mail.gmail.com> Message-ID: On Mon, Mar 2, 2009 at 18:04, Slawek Zak wrote: > It is possible, but handle-incomming-connection is now in fact a thin > wrapper around?process-connection which does all the work, thus having > process management depend on request contents requires one to patch or > rewrite process-connection to simply avoid reading request data which have > been read already. I did not mean to say that it would be possible without changing Hunchentoot. In fact, I meant to say that the interaction between PROCESS-CONNECTION and PROCESS-REQUEST would need to be rewritten. I have no current plans to do this, as I don't need the feature. If you plan on doing it, looking at http://weitz.de/patches.html and discussing the details of the proposed API here will increase the likeliness that it will end up in Hunchentoot itself. -Hans From slawek.zak at gmail.com Wed Mar 4 16:10:57 2009 From: slawek.zak at gmail.com (Slawek Zak) Date: Wed, 4 Mar 2009 17:10:57 +0100 Subject: [hunchentoot-devel] COMET with Hunchentoot? In-Reply-To: References: <787bbe1c0902270742q3d08ee5bpd46bfb21db7c9aa2@mail.gmail.com> <787bbe1c0902280501q17030c5cx953d0fa500ca7b26@mail.gmail.com> <787bbe1c0903020904n73cabe37ta042633cced393b9@mail.gmail.com> Message-ID: <787bbe1c0903040810v14ec92d6i560df731c56ccf61@mail.gmail.com> On Mon, Mar 2, 2009 at 7:01 PM, Hans H?bner wrote: > On Mon, Mar 2, 2009 at 18:04, Slawek Zak wrote: > > It is possible, but handle-incomming-connection is now in fact a thin > > wrapper around process-connection which does all the work, thus having > > process management depend on request contents requires one to patch or > > rewrite process-connection to simply avoid reading request data which > have > > been read already. > > I did not mean to say that it would be possible without changing > Hunchentoot. In fact, I meant to say that the interaction between > PROCESS-CONNECTION and PROCESS-REQUEST would need to be rewritten. I > have no current plans to do this, as I don't need the feature. If you > plan on doing it, looking at http://weitz.de/patches.html and > discussing the details of the proposed API here will increase the > likeliness that it will end up in Hunchentoot itself. > Fine, I will try to come up with some clean API and implementation to do this. /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From lispercat at gmail.com Sat Mar 7 16:10:23 2009 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 7 Mar 2009 11:10:23 -0500 Subject: [hunchentoot-devel] "Proxy Error" with new Hunchentoot Message-ID: I got the new version of hunchentoot, modified my code and started the acceptor. When I try to connect to the web pages handled by hunchentoot, I got "Proxy Error" message in the browser without any delay. At the same time I have my production hunchentoot (old version) running without problems. I also tried to put ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentoot into the apache httpd.conf file to use the hunchentoot test package After I start the acceptor (setf acc1 (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 3000))) And run the tests I have a bunch of messages like: "

The requested URL /hunchentoot/test/parameter_utf8_get.html was not found on this server.

" (BTW, I think there is some discrepancy in the hunchentoot documentation where it say to create proxy port 3000 and then says to create acceptor on port 4242) "sudo sudo netstat -atnp" shows that all servers are running properly. Does it mean that I have some problem with hunchentoot and apache mod_proxy? How can I troubleshoot it? I tried to put a (break) in my own my-list-request-dispatcher, but the request doesn't even get there. I use sbcl-1.0.23 on Ubuntu. Thank you, Andrei From william.bruschi at gmail.com Sat Mar 7 18:31:13 2009 From: william.bruschi at gmail.com (William Bruschi) Date: Sat, 7 Mar 2009 13:31:13 -0500 Subject: [hunchentoot-devel] "Proxy Error" with new Hunchentoot In-Reply-To: References: Message-ID: Do you have anything in your global proxy configuration file for Apache? It's normally located in /etc/apache2/mods-available/proxy.conf for Ubuntu systems.. If so, try commenting out everything in that file. Also, be sure to enable mod_proxy AND mod_proxy_http. On Sat, Mar 7, 2009 at 11:10 AM, Andrei Stebakov wrote: > I got the new version of hunchentoot, modified my code and started the acceptor. > When I try to connect to the web pages handled by hunchentoot, I got > "Proxy Error" message in the browser without any delay. > At the same time I have my production hunchentoot (old version) > running without problems. > I also tried to put > ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot > ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentoot > into the apache httpd.conf file to use the hunchentoot test package > After I start the acceptor (setf acc1 (hunchentoot:start > (make-instance 'hunchentoot:acceptor :port 3000))) > And run the tests I have a bunch of messages like: > "

The requested URL /hunchentoot/test/parameter_utf8_get.html was > not found on this server.

" > (BTW, I think there is some discrepancy in the hunchentoot > documentation where it say to create proxy port 3000 and then says to > create acceptor on port 4242) > "sudo sudo netstat -atnp" shows that all servers are running properly. > Does it mean that I have some problem with hunchentoot and apache > mod_proxy? How can I troubleshoot it? > I tried to put a (break) in my own my-list-request-dispatcher, but the > request doesn't even get there. > I use sbcl-1.0.23 on Ubuntu. > > Thank you, > Andrei > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel > From lispercat at gmail.com Sat Mar 7 21:04:20 2009 From: lispercat at gmail.com (Andrei Stebakov) Date: Sat, 7 Mar 2009 16:04:20 -0500 Subject: [hunchentoot-devel] "Proxy Error" with new Hunchentoot In-Reply-To: References: Message-ID: Ok, did that, unfortunately it didn't help :( On Sat, Mar 7, 2009 at 1:31 PM, William Bruschi wrote: > Do you have anything in your global proxy configuration file for > Apache? ?It's normally located in > /etc/apache2/mods-available/proxy.conf for Ubuntu systems.. ?If so, > try commenting out everything in that file. ?Also, be sure to enable > mod_proxy AND mod_proxy_http. > > On Sat, Mar 7, 2009 at 11:10 AM, Andrei Stebakov wrote: >> I got the new version of hunchentoot, modified my code and started the acceptor. >> When I try to connect to the web pages handled by hunchentoot, I got >> "Proxy Error" message in the browser without any delay. >> At the same time I have my production hunchentoot (old version) >> running without problems. >> I also tried to put >> ProxyPass /hunchentoot http://127.0.0.1:3000/hunchentoot >> ProxyPassReverse /hunchentoot http://127.0.0.1:3000/hunchentoot >> into the apache httpd.conf file to use the hunchentoot test package >> After I start the acceptor (setf acc1 (hunchentoot:start >> (make-instance 'hunchentoot:acceptor :port 3000))) >> And run the tests I have a bunch of messages like: >> "

The requested URL /hunchentoot/test/parameter_utf8_get.html was >> not found on this server.

" >> (BTW, I think there is some discrepancy in the hunchentoot >> documentation where it say to create proxy port 3000 and then says to >> create acceptor on port 4242) >> "sudo sudo netstat -atnp" shows that all servers are running properly. >> Does it mean that I have some problem with hunchentoot and apache >> mod_proxy? How can I troubleshoot it? >> I tried to put a (break) in my own my-list-request-dispatcher, but the >> request doesn't even get there. >> I use sbcl-1.0.23 on Ubuntu. >> >> Thank you, >> Andrei >> >> _______________________________________________ >> 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 > From edi at agharta.de Sun Mar 8 16:14:19 2009 From: edi at agharta.de (Edi Weitz) Date: Sun, 8 Mar 2009 17:14:19 +0100 Subject: [hunchentoot-devel] "Proxy Error" with new Hunchentoot In-Reply-To: References: Message-ID: On Sat, Mar 7, 2009 at 11:55 PM, Andrei Stebakov wrote: > After I upgraded to new chunga things started to move, but now I have > a problem with drakma:http-request. It returns a binary array on a > request like (http-request "http://lisp.org/"), so all my functions > depending on http-request fail. I'll ask about it in drakma ml. As I said in the release announcements, the new and the old (with 1.x.x being the dividing line) versions of Drakma, Hunchentoot, and Chunga are mutually incompatible. If you upgrade one of them, you need to upgrade all three libraries. HTH, Edi. From mackram at gmail.com Mon Mar 9 15:37:19 2009 From: mackram at gmail.com (Mackram Raydan) Date: Mon, 9 Mar 2009 17:37:19 +0200 Subject: [hunchentoot-devel] Setup of Hunchentoot 1.0.0 Message-ID: <37654d130903090837y4c471228l86856f7c8b4546ba@mail.gmail.com> Hey Everyone, I am not sure how everyone got their new Hunchentoot server setup but I had a kind of rough experience and wanted to share so that maybe it is spared from the next guy giving Hunchentoot. Below is my humble experience feel free to tell me where I went wrong (if I did) or in posting possible solutions First off, I use an Ubuntu installation and unfortunately all there repositories for cl code seem to be out of date and hence it will cause alot of pain. I had to go through uninstalling everything for cl downloaded using apt-get. Second, if you choose to use ASDF-INSTALL you are in for some trouble too. I tried ASDF-INSTALL a couple of times but to no avail. Hunchentoot is installed and you can load a server but you can not get it to reply. My guess is that one of the socket code libraries happen to be the problem but I am not sure of that. If it is any help Drakma kept pointing out an issue with sockets! (I can reproduce the error if any one wants). Third and finally, I tried clbuild which I am glad to say works but with a twist. For some reason, which I have not yet gotten to, clbuild can not tell that Hunchentoot depends on Bordeaux-threads (and consequently lift) or Usockets (and consequently split-sequence) and therefore will not download them. I had to install each on its own. After that, everything works beautifully. I am not sure how much this info is actionable, after all it is not an issue of Hunchentoot fundamentally; however without some guidelines to those who do not keep updated libraries (dracs copies :) ) getting Hunchentoot to run might be too much. Just my 2 cents on an otherwise awesome project :) Mackram Raydan Website: www.trailoflight.net (unfortunately does not run Hunchentoot ---- YET). "An invasion of armies can be resisted, but not an idea whose time has come." Victor Hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: From girzel at gmail.com Tue Mar 10 06:53:54 2009 From: girzel at gmail.com (Eric Abrahamsen) Date: Tue, 10 Mar 2009 14:53:54 +0800 Subject: [hunchentoot-devel] developing in hunchentoot Message-ID: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> Hi, I'm relatively new to both Lisp and Hunchentoot, and I've got a question about how experienced developers go about working on a hunchentoot site. Specifically, I've made myself a helper macro to wrap define-easy-handler and make it simpler to add handlers from the REPL. I find that every time I use it, it adds a new entry to the *dispatch-table*. Most often, I'm redefining an existing handler (to expand or correct it) and would rather overwrite that handler with its new version, rather than adding a new entry. I'm finding it awkward to modify my macro so that it checks for an existing handler with that function name and overwrites it ? more importantly I'm not certain this is the best way to do it. If any more experienced users were willing to share how they address this issue, and in general what tools they've made to assist in developing a hunchentoot site, this newbie would be very grateful. Thanks, Eric From edi at agharta.de Tue Mar 10 09:28:41 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Mar 2009 10:28:41 +0100 Subject: [hunchentoot-devel] developing in hunchentoot In-Reply-To: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> References: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> Message-ID: On Tue, Mar 10, 2009 at 7:53 AM, Eric Abrahamsen wrote: > Most often, I'm redefining an existing handler (to > expand or correct it) and would rather overwrite that handler with its > new version, rather than adding a new entry. I'm finding it awkward to > modify my macro so that it checks for an existing handler with that > function name and overwrites it ? more importantly I'm not certain > this is the best way to do it. DEFINE-EASY-HANDLER should overwrite existing handlers of the same name (or if they have the same - EQUAL - URI part). If it doesn't do that, it's a bug. Edi. From rohan.nicholls at googlemail.com Tue Mar 10 09:36:31 2009 From: rohan.nicholls at googlemail.com (Rohan Nicholls) Date: Tue, 10 Mar 2009 10:36:31 +0100 Subject: [hunchentoot-devel] Setup of Hunchentoot 1.0.0 In-Reply-To: <37654d130903090837y4c471228l86856f7c8b4546ba@mail.gmail.com> References: <37654d130903090837y4c471228l86856f7c8b4546ba@mail.gmail.com> Message-ID: Hi Mackram, On Mon, Mar 9, 2009 at 4:37 PM, Mackram Raydan wrote: > Hey Everyone, > > I am not sure how everyone got their new Hunchentoot server setup but I had > a kind of rough experience and wanted to share so that maybe it is spared > from the next guy giving Hunchentoot. Below is my humble experience feel > free to tell me where I went wrong (if I did) or in posting possible > solutions > > First off, I use an Ubuntu installation and unfortunately all there > repositories for cl code seem to be out of date and hence it will cause alot > of pain. I had to go through uninstalling everything for cl downloaded using > apt-get. It is unfortunate, but the debian packages and so also the ubuntu packages have always been out of date. The cl- packages are not important to the ubuntu project, as such, so they just use the debian defaults. My personal experience has been to avoid any of the apt-get lisp packages like the plague. > Second, if you choose to use ASDF-INSTALL you are in for some trouble too. I > tried ASDF-INSTALL a couple of times but to no avail. Hunchentoot is > installed and you can load a server but you can not get it to reply. My > guess is that one of the socket code libraries happen to be the problem but > I am not sure of that. If it is any help Drakma kept pointing out an issue > with sockets! (I can reproduce the error if any one wants). Sorry, I have no recent experience with asdf install. > Third and finally, I tried clbuild which I am glad to say works but with a > twist. For some reason, which I have not yet gotten to, clbuild can not tell > that Hunchentoot depends on Bordeaux-threads (and consequently lift) or > Usockets (and consequently split-sequence) and therefore will not download > them. I had to install each on its own. After that, everything works > beautifully. I find this odd, I use clbuild for my lisp stuff, and it works a treat. But a quick ./clbuild update hunchentoot shows that you are correct. I will mention this on the clbuild mailing list. There was a glitch where the ediware packages were not being updated properly, but that was fixed very promptly after I winged. :) So, bordeaux-threads and Usockets must be added to the dependencies. I will ask on the mailing list. Thanks for the heads up, because I keep referring people to clbuild. Thanks for the report. Rohan From vseloved at gmail.com Tue Mar 10 10:04:32 2009 From: vseloved at gmail.com (Vsevolod) Date: Tue, 10 Mar 2009 12:04:32 +0200 Subject: [hunchentoot-devel] developing in hunchentoot In-Reply-To: References: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> Message-ID: <89dc7c5b0903100304q2e7b4188y4bfd875e80be85f2@mail.gmail.com> On Tue, Mar 10, 2009 at 11:28 AM, Edi Weitz wrote: > On Tue, Mar 10, 2009 at 7:53 AM, Eric Abrahamsen wrote: > > Most often, I'm redefining an existing handler (to > > expand or correct it) and would rather overwrite that handler with its > > new version, rather than adding a new entry. I'm finding it awkward to > > modify my macro so that it checks for an existing handler with that > > function name and overwrites it ? more importantly I'm not certain > > this is the best way to do it. > > DEFINE-EASY-HANDLER should overwrite existing handlers of the same > name (or if they have the same - EQUAL - URI part). If it doesn't do > that, it's a bug. Maybe he is referring to the fact, that after redefining the DISPATCHER, the running server's dispatch table remains unchanged. In the sense, that the server continues to use the dispatcher closures, created at the time of the server start. At least for me it works this way (in old Hunchentoot): when I redefine a dispatcher, I need to modify the dispatch table (or plainly restart the server) for the change to take effect. To clarify, I'd like to add, that I refer to the handler functions as per the docs (e.g. html-generation functions). They take no arguments and are responsible for forming the reply object. If you redefine them, it has immediate effect. Dispatchers are the closures in the dispatch-table, that take 1 argument -- request. If you redefine the dispatcher (for example, with define-easy-handler, or manually), somehow, it doesn't effect the running server's dispatch-table. -- vsevolod -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi at agharta.de Tue Mar 10 10:58:30 2009 From: edi at agharta.de (Edi Weitz) Date: Tue, 10 Mar 2009 11:58:30 +0100 Subject: [hunchentoot-devel] developing in hunchentoot In-Reply-To: <89dc7c5b0903100304q2e7b4188y4bfd875e80be85f2@mail.gmail.com> References: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> <89dc7c5b0903100304q2e7b4188y4bfd875e80be85f2@mail.gmail.com> Message-ID: On Tue, Mar 10, 2009 at 11:04 AM, Vsevolod wrote: > Maybe he is referring to the fact, that after redefining the DISPATCHER, the > running server's dispatch table remains unchanged. I don't think so. He said that each time he redefines an easy handler a new entry is added. > In the sense, that the > server continues to use the dispatcher closures, created at the time of the > server start. At least for me it works this way (in old Hunchentoot): when I > redefine a dispatcher, I need to modify the dispatch table (or plainly > restart the server) for the change to take effect. > > To clarify, I'd like to add, that I refer to the handler functions as per > the docs (e.g. html-generation functions). They take no arguments and are > responsible for forming the reply object. If you redefine them, it has > immediate effect. Dispatchers are the closures in the dispatch-table, that > take 1 argument -- request. If you redefine the dispatcher (for example, > with define-easy-handler, or manually), somehow, it doesn't effect the > running server's dispatch-table. That shouldn't be the case with the 1.0.0 version. See how list-request-dispatcher works. Edi. From girzel at gmail.com Tue Mar 10 13:35:24 2009 From: girzel at gmail.com (Eric Abrahamsen) Date: Tue, 10 Mar 2009 21:35:24 +0800 Subject: [hunchentoot-devel] developing in hunchentoot In-Reply-To: References: <2D31B8A0-482D-48F6-AE84-45CFABA079DA@gmail.com> <89dc7c5b0903100304q2e7b4188y4bfd875e80be85f2@mail.gmail.com> Message-ID: <70CC6368-C37F-491D-B0AC-3206E04EF3AE@gmail.com> On Mar 10, 2009, at 6:58 PM, Edi Weitz wrote: > On Tue, Mar 10, 2009 at 11:04 AM, Vsevolod wrote: > >> Maybe he is referring to the fact, that after redefining the >> DISPATCHER, the >> running server's dispatch table remains unchanged. > > I don't think so. He said that each time he redefines an easy handler > a new entry is added. Sorry, nothing mysterious is happening. My stupid helper macro includes a create-prefix-dispatcher call and a push to *dispatch- table*, so obviously it pushes something new to the *dispatch-table* every time I call it. Using a plain old defun to redefine an existing handler does exactly what it should ? my problem was a confusion about how lisp works, not about how hunchentoot works, and I apologize for the noise. Back to mucking about, Eric > >> In the sense, that the >> server continues to use the dispatcher closures, created at the >> time of the >> server start. At least for me it works this way (in old >> Hunchentoot): when I >> redefine a dispatcher, I need to modify the dispatch table (or >> plainly >> restart the server) for the change to take effect. >> >> To clarify, I'd like to add, that I refer to the handler functions >> as per >> the docs (e.g. html-generation functions). They take no arguments >> and are >> responsible for forming the reply object. If you redefine them, it >> has >> immediate effect. Dispatchers are the closures in the dispatch- >> table, that >> take 1 argument -- request. If you redefine the dispatcher (for >> example, >> with define-easy-handler, or manually), somehow, it doesn't effect >> the >> running server's dispatch-table. > > That shouldn't be the case with the 1.0.0 version. See how > list-request-dispatcher works. > > Edi. > > _______________________________________________ > tbnl-devel site list > tbnl-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/tbnl-devel From fairchild.anthony at gmail.com Wed Mar 11 03:46:24 2009 From: fairchild.anthony at gmail.com (Anthony Fairchild) Date: Tue, 10 Mar 2009 19:46:24 -0800 Subject: [hunchentoot-devel] *catch-errors-p* Message-ID: Hi, I'm converting my web app over to Hunchentoot 1.0 and I am really missing *catch-errors-p*. I just need errors that occur while processing the http request to signal the debugger. Are there any workarounds to achieve this with the new 1.0 version? I'm using Lispworks 5.1. Thanks! Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From vseloved at gmail.com Wed Mar 11 12:33:46 2009 From: vseloved at gmail.com (Vsevolod) Date: Wed, 11 Mar 2009 14:33:46 +0200 Subject: [hunchentoot-devel] *catch-errors-p* In-Reply-To: References: Message-ID: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> This topic was discussed after the new version has appeared (look in the archives). Basically, you can use (setf *break-on-signals* 'error). Cheers, Vsevolod On Wed, Mar 11, 2009 at 5:46 AM, Anthony Fairchild < fairchild.anthony at gmail.com> wrote: > Hi, > > I'm converting my web app over to Hunchentoot 1.0 and I am really missing > *catch-errors-p*. I just need errors that occur while processing the http > request to signal the debugger. Are there any workarounds to achieve this > with the new 1.0 version? I'm using Lispworks 5.1. > > Thanks! > > Anthony > > _______________________________________________ > 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 fairchild.anthony at gmail.com Wed Mar 11 17:39:06 2009 From: fairchild.anthony at gmail.com (Anthony Fairchild) Date: Wed, 11 Mar 2009 10:39:06 -0700 Subject: [hunchentoot-devel] *catch-errors-p* In-Reply-To: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> References: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> Message-ID: Thanks for the response, I think that will work for me. Is there any good way to search the archives other than googling "site:common-lisp.net"? I don't see a search on the archives, is there a better way? Thanks, Anthony On Wed, Mar 11, 2009 at 5:33 AM, Vsevolod wrote: > This topic was discussed after the new version has appeared (look in the > archives). > Basically, you can use (setf *break-on-signals* 'error). > > Cheers, > Vsevolod > > On Wed, Mar 11, 2009 at 5:46 AM, Anthony Fairchild < > fairchild.anthony at gmail.com> wrote: > >> Hi, >> >> I'm converting my web app over to Hunchentoot 1.0 and I am really missing >> *catch-errors-p*. I just need errors that occur while processing the http >> request to signal the debugger. Are there any workarounds to achieve this >> with the new 1.0 version? I'm using Lispworks 5.1. >> >> Thanks! >> >> Anthony >> >> _______________________________________________ >> 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 avodonosov at yandex.ru Wed Mar 11 20:29:53 2009 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Wed, 11 Mar 2009 22:29:53 +0200 Subject: [hunchentoot-devel] *catch-errors-p* In-Reply-To: References: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> Message-ID: <1514743601.20090311222953@yandex.ru> on Wednesday, March 11, 2009, 7:39:06 PM Anthony wrote: > Is there any good way to search the archives other than googling > "site:common-lisp.net"?? I don't see a search on the archives, > is there a better way? googling for "site:common-lisp.net/pipermail/tbnl-devel/" works as well Best regards, - Anton From edi at agharta.de Wed Mar 11 23:22:11 2009 From: edi at agharta.de (Edi Weitz) Date: Thu, 12 Mar 2009 00:22:11 +0100 Subject: [hunchentoot-devel] *catch-errors-p* In-Reply-To: References: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> Message-ID: On Wed, Mar 11, 2009 at 6:39 PM, Anthony Fairchild wrote: > Is there any good > way to search the archives other than googling "site:common-lisp.net"?? I > don't see a search on the archives, is there a better way? Read this paragraph: http://weitz.de/hunchentoot/#mail Edi. From fairchild.anthony at gmail.com Thu Mar 12 00:38:29 2009 From: fairchild.anthony at gmail.com (Anthony Fairchild) Date: Wed, 11 Mar 2009 17:38:29 -0700 Subject: [hunchentoot-devel] *catch-errors-p* In-Reply-To: References: <89dc7c5b0903110533s15a04246gcdaba78cc5a76d96@mail.gmail.com> Message-ID: Excellent, thank you Edi! On Wed, Mar 11, 2009 at 4:22 PM, Edi Weitz wrote: > On Wed, Mar 11, 2009 at 6:39 PM, Anthony Fairchild > wrote: > > Is there any good > > way to search the archives other than googling "site:common-lisp.net"? > I > > don't see a search on the archives, is there a better way? > > Read this paragraph: > > http://weitz.de/hunchentoot/#mail > > Edi. > > _______________________________________________ > 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 lispmr at gmail.com Thu Mar 12 21:20:43 2009 From: lispmr at gmail.com (Harrison Maseko) Date: Thu, 12 Mar 2009 23:20:43 +0200 Subject: No subject Message-ID: <49b97cc3.09b6660a.27d6.fffffda1@mx.google.com> A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 1 bytes Desc: not available URL: From lispercat at gmail.com Sat Mar 14 01:33:22 2009 From: lispercat at gmail.com (Andrei Stebakov) Date: Fri, 13 Mar 2009 21:33:22 -0400 Subject: [hunchentoot-devel] Tracking file upload progress Message-ID: With the old hunchentoot I was able to get the flexi-stream of the request using (content-stream request) and then when my ajax handler wanted to update the upload progress it would read (flexi-stream-position of the stream that I kept in a session). With the new hunchentoot this doesn't work. I realize that (content-stream request) is not a flexi-stream, so when I save a stream in my session I make a flexi-stream using (make-flexi-stream (hunchentoot::content-stream request) :external-format hunchentoot::+latin-1+). Then when ajax handler reads flexi-stream-position of the saved stream I always get 0. What am I missing? Thank you, Andrei From hans at huebner.org Mon Mar 30 17:22:36 2009 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 30 Mar 2009 18:22:36 +0100 Subject: [hunchentoot-devel] Test, please ignore Message-ID: Tracking down a delay problem. From hans at huebner.org Mon Mar 30 18:41:49 2009 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 30 Mar 2009 19:41:49 +0100 Subject: [hunchentoot-devel] Test, please ignore In-Reply-To: References: Message-ID: Need another, apologies. On Mon, Mar 30, 2009 at 18:22, Hans H?bner wrote: > Tracking down a delay problem. > From stesch at no-spoon.de Tue Mar 31 06:37:18 2009 From: stesch at no-spoon.de (Stefan Scholl) Date: Tue, 31 Mar 2009 08:37:18 +0200 Subject: [hunchentoot-devel] Test, please ignore In-Reply-To: References: Message-ID: <20090331063718.GJ27332@parsec.no-spoon.de> On 2009-03-30 18:22:36, Hans H?bner wrote: > Tracking down a delay problem. Hey, and no more 550 go away ;-) -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/ From larry at theclapp.org Tue Mar 31 16:12:00 2009 From: larry at theclapp.org (Larry Clapp) Date: Tue, 31 Mar 2009 12:12:00 -0400 Subject: [hunchentoot-devel] Using Hunchentoot and cl-who with other people (non-coders) Message-ID: <20090331161200.GA22421@cupid.theclapp.org> Hi, list, I am developing my first web app of any kind. I've no experience with other web app frameworks (like RoR or what have you). I am working with a friend, who knows Dreamweaver and other fairly high level web-design tools, but can't code at all. On the other hand, I don't know web-design at all, using tools or not, so we're pretty complementary. So I'm seeking guidance on how I can continue to develop using Hunchentoot and cl-who, and yet integrate machine-generated html or css or what have you from Dreamweaver or other tools? As I understand it, this is a known difficulty that other teams and tool designers have faced, and if I'd ever worked with any other teams or tools then it might be a no-brainer, but given my lack of experience in this respect I'm not even sure what to Google to find answers for myself. I'd appreciate any advice, links, pointers, etc, that users of Hunchentoot and/or cl-who could provide. Thanks! -- Larry Clapp