[hunchentoot-devel] Hunchentoot with ECL
As I noticed, Hunchentoot is not yet ported to ECL, even though the ECL-documentation says that it has Gray-Streams-, Thread- and Socket-Support as far as I read. Was there simply no interest to port it to ECL so far, or is there any reason why it is not possible or very hard to port it to ECL, or why one should not use ECL? Another thing I am interested in is, why doesnt Hunchentoot use "external" Libraries, or store the whole Stuff in the port-*-Files in seperate "Libraries" - the functions defined there may be useful to other Projects, too, and they would also benefit from bugfixes and extensions (and would maybe add such, too).
On Fri, 21 Mar 2008 00:25:40 +0100, css <css@swissjabber.ch> wrote:
As I noticed, Hunchentoot is not yet ported to ECL, even though the ECL-documentation says that it has Gray-Streams-, Thread- and Socket-Support as far as I read.
Was there simply no interest to port it to ECL so far, or is there any reason why it is not possible or very hard to port it to ECL, or why one should not use ECL?
I suppose there was simply no interest so far. You're welcome to provide patches for ECL. http://weitz.de/patches.html
Another thing I am interested in is, why doesnt Hunchentoot use "external" Libraries, or store the whole Stuff in the port-*-Files in seperate "Libraries" - the functions defined there may be useful to other Projects, too, and they would also benefit from bugfixes and extensions (and would maybe add such, too).
There already exist compatibility libraries for things like MP and sockets which I think provide more functionality than what is in the port-xxx.lisp files. However, they're pretty big and using them would add another layer of complexity to Hunchentoot which already depends on a dozen other libs. Right now there are only a few lines per implementation which cover a small subset of four implementation-specific areas, namely MP, sockets, debugging, and OS integration. Loading four external libraries to cover this seems overdone to me. Having said that, a lot of the "design decisions" of Hunchentoot might actually be accidents or workarounds owed to its history - see the website. If I would start from scratch today, I would probably do a lot of things differently. But that's not going to happen anytime soon... :)
As I noticed, Hunchentoot is not yet ported to ECL, even though the ECL-documentation says that it has Gray-Streams-, Thread- and Socket-Support as far as I read.
Was there simply no interest to port it to ECL so far, or is there any reason why it is not possible or very hard to port it to ECL, or why one should not use ECL?
I suppose there was simply no interest so far. You're welcome to provide patches for ECL.
Not to say there was no interest at all, I'm quite interested in that, but there is not enough free time, as usually... Regards, -- Anton
2008/3/21, Anton Vodonosov <avodonosov@yandex.ru>:
As I noticed, Hunchentoot is not yet ported to ECL, even though the ECL-documentation says that it has Gray-Streams-, Thread- and Socket-Support as far as I read.
Was there simply no interest to port it to ECL so far, or is there any reason why it is not possible or very hard to port it to ECL, or why one should not use ECL?
I suppose there was simply no interest so far. You're welcome to provide patches for ECL.
Not to say there was no interest at all, I'm quite interested in that, but there is not enough free time, as usually...
I am trying to do this at the moment, but I have some problems. I have "ported" trivial-gray-streams, chunga and flexi-streams (and cl+ssl should also work, but I have a problem with the ssl-library at the moment). Any package required by Hunchentoot compiles successfully. Does anybody of you happen to know a Maintainer of these Packages, or where I can submit the changes I have made? Porting the Socket-Stuff was not hard, since it is compatible with sb-bsd-sockets. Porting the Thread-Stuff was so far not hard except for "with-timeout", and I use bordeaux-threads to implement this macro for the moment (I was too lazy to really implement it correctly - maybe I will do this soon, it shouldnt be too hard to replace it). I had to replace the form (loop for key = (read-line *hunchentoot-stream* nil nil) while (and key (string-not-equal key "end")) for value = (read-line *hunchentoot-stream* t) collect (cons (make-keyword key) value) do (maybe-write-to-header-stream key value))) by some tagbody-go-form, because ECL doesnt support it. I now have got a Version of Hunchentoot which compiles under ECL and starts listening to a port if told. But it doesnt answer requests for some reason. It doesnt throw errors (though *catch-errors-p*=nil) but it seems not to answer the requests. Maybe there is some Deadlock or endless loop (in my tagbody form for instance), I dont know. I will try to figure it out as soon as I have some free time again. If somebody is interested in this so far, just ask, I will give the patches I have made. C S S
On Wed, 26 Mar 2008 02:23:04 +0100, css <css@swissjabber.ch> wrote:
Does anybody of you happen to know a Maintainer of these Packages, or where I can submit the changes I have made?
That shouldn't be too hard to find out, should it?
I had to replace the form
(loop for key = (read-line *hunchentoot-stream* nil nil) while (and key (string-not-equal key "end")) for value = (read-line *hunchentoot-stream* t) collect (cons (make-keyword key) value) do (maybe-write-to-header-stream key value)))
by some tagbody-go-form, because ECL doesnt support it.
ECL doesn't support LOOP?!? Maybe you can put your patches on some server somewhere or send them to the list so others interested in the port can check them. Cheers, Edi.
Edi Weitz <edi@agharta.de> writes:
I had to replace the form
(loop for key = (read-line *hunchentoot-stream* nil nil) while (and key (string-not-equal key "end")) for value = (read-line *hunchentoot-stream* t) collect (cons (make-keyword key) value) do (maybe-write-to-header-stream key value)))
by some tagbody-go-form, because ECL doesnt support it.
ECL doesn't support LOOP?!?
The use of the FOR clause after WHILE is (unfortunately, IMO) not allowed by the standard. Nicolas
On Wed, 26 Mar 2008 09:40:00 +0100, Nicolas Neuss <neuss@math.uni-karlsruhe.de> wrote:
The use of the FOR clause after WHILE is (unfortunately, IMO) not allowed by the standard.
And I thought that if SBCL's compiler allows it, it must be ANSI-compliant... :) Anyway, I've changed the offending LOOP slightly to appease ECL.
Edi Weitz wrote:
On Wed, 26 Mar 2008 02:23:04 +0100, css <css@swissjabber.ch> wrote:
I had to replace the form
(loop for key = (read-line *hunchentoot-stream* nil nil) while (and key (string-not-equal key "end")) for value = (read-line *hunchentoot-stream* t) collect (cons (make-keyword key) value) do (maybe-write-to-header-stream key value)))
by some tagbody-go-form, because ECL doesnt support it.
ECL doesn't support LOOP?!?
Unfortunately though handy, LOOP has a lot of quirks as well as under specified areas. So here your usage of loop is not fully compliant because you use a FOR clause after a WHILE clause: From CLHS 6.1.2.1 Iteration Control: The iteration control clauses for, as, and repeat must precede any other loop clauses, except initially, with, and named, since they establish variable bindings. When iteration control clauses are used in a loop, the corresponding termination tests in the loop body are evaluated before any other loop body code is executed. This is why I switched to ITERATE in cl-pdf/cl-typesetting for complex loops. I still use LOOP a lot for all the simple loops though. Marc
On Wed, Mar 26, 2008 at 09:52:37AM +0100, Marc Battyani wrote:
Edi Weitz wrote:
On Wed, 26 Mar 2008 02:23:04 +0100, css <css@swissjabber.ch> wrote:
I had to replace the form
(loop for key = (read-line *hunchentoot-stream* nil nil) while (and key (string-not-equal key "end")) for value = (read-line *hunchentoot-stream* t) collect (cons (make-keyword key) value) do (maybe-write-to-header-stream key value)))
by some tagbody-go-form, because ECL doesnt support it.
ECL doesn't support LOOP?!?
Unfortunately though handy, LOOP has a lot of quirks as well as under specified areas.
[dangerously offtopic, but...] Are they really underspecified? My impression is that LOOP is strictly specified, but loosely (i.e. incorrectly) implemented in many Common Lisps. Zach
Zach Beane wrote:
On Wed, Mar 26, 2008 at 09:52:37AM +0100, Marc Battyani wrote:
Unfortunately though handy, LOOP has a lot of quirks as well as under specified areas.
[dangerously offtopic, but...]
Are they really underspecified? My impression is that LOOP is strictly specified, but loosely (i.e. incorrectly) implemented in many Common Lisps.
I had problems with some loops in cl-pdf which didn't work on CLISP. There have been several emails on the subject and the only conclusion was that the standard was ambiguous:
6.1.1.6., by saying that stepping and termination tests are "between" and "just before" the loop body executions, contradicts 6.1.1.4. and 6.1.2.1., which say that these are _part_ of the loop body.
This is this problem that decided me to switch to ITERATE for complex loops in cl-pdf/typesetting (and my own projects). BTW this is becoming off-topic and I don't want to start the debate again. I just wanted to say that complex loops with LOOP will not be portable. (anyway the first loop of this discussion is not compliant at all) Marc
ECL doesn't support LOOP?!?
It does support loop, but this LOOP seems not do be compliant with the Standard, and ECL sais: Iteration in LOOP follows body code. Current LOOP context: FOR VALUE = (READ-LINE *HUNCHENTOOT-STREAM* T) COLLECT. Clisp also warns: "WARNING: LOOP: FOR clauses should occur before the loop's main body" but expands the loop-macro.
Maybe you can put your patches on some server somewhere or send them to the list so others interested in the port can check them.
It is not very hard to port it. I had to shadow some Functions in trivial-gray-streams, and replace defmethods on these symbols (stream-element-type for instance) to the same symbols in the gray:-Package (gray:stream-element-type). I have put the patches on http://nasobem.i-networx.de/hunchentoot-patches/ (I used the Versions from cliki.net), however: They are compiling (for me at least, with a current checkout of ECL), but as I said, hunchentoot doesnt work yet (and port-ecl.lisp is not written in a "good" format, no documentation, etc., yet, and I have not written unix-ecl.lisp yet). C S S
Hello. 2008/3/22, Edi Weitz <edi@agharta.de>:
I suppose there was simply no interest so far. You're welcome to provide patches for ECL.
As I see in the other Topic of this list, ther will be some changes of Hunchentoot soon, and as far as I read, it is really planned to use external libraries like bordeaux-threads and usocket. This would mean, that for the moment, it is not useful to continue porting Hunchentoot. Is this correct? (Has meanwhile someone a working Port?)
On Thu, 10 Apr 2008 14:22:15 +0200, css <css@swissjabber.ch> wrote:
As I see in the other Topic of this list, ther will be some changes of Hunchentoot soon, and as far as I read, it is really planned to use external libraries like bordeaux-threads and usocket. This would mean, that for the moment, it is not useful to continue porting Hunchentoot. Is this correct?
Yes, it seems Hans wants to take up all of this work, so I'm going to eat what I said two weeks ago... :) If you want to help with making Hunchentoot usable on ECL, you should probably check if usocket and bordeaux-threads work correctly with ECL (if you haven't done so already).
2008/4/10, Edi Weitz <edi@agharta.de>:
Yes, it seems Hans wants to take up all of this work, so I'm going to eat what I said two weeks ago... :)
If you want to help with making Hunchentoot usable on ECL, you should probably check if usocket and bordeaux-threads work correctly with ECL (if you haven't done so already).
According to http://common-lisp.net/project/bordeaux-threads/ and http://common-lisp.net/project/usocket/ (and my personal "tests") it is working. This was the reason why I suggested using it.
participants (6)
-
Anton Vodonosov -
css -
Edi Weitz -
Marc Battyani -
Nicolas Neuss -
Zach Beane