[drakma-devel] Re: Portability of Drakma
On Sun, 25 Feb 2007 14:38:02 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
- The code should have been tested successfully on at least the Lisp/OS combinations that are currently supported by Drakma.
Is there a list somewhere as a reference to what I'm getting into?
No, unfortunately not. I myself use mostly LispWorks (Windows and Linux/x86) and SBCL (Linux/x86). (LispWorks shouldn't be a problem anyway as it's not affected by the switch.) I think that at least LispWorks, SBCL, AllegroCL, CMUCL, CLISP, and OpenMCL should be supported, everything else being a bonus. Operating systems: Windows (where applicable), Linux, OS X. If you don't want to test all of this for yourself, how about offering a tarball of Drakma which uses usocket for download? Send an announcement to this mailing list including an overview of what you've tested and what not. We can ask "interested parties" to try it out and we'll switch to the new version in four weeks, say, unless someone objects. Does that sound OK? Cheers, Edi.
On 2/25/07, Edi Weitz <edi@agharta.de> wrote:
On Sun, 25 Feb 2007 14:38:02 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
- The code should have been tested successfully on at least the Lisp/OS combinations that are currently supported by Drakma.
Is there a list somewhere as a reference to what I'm getting into?
No, unfortunately not. I myself use mostly LispWorks (Windows and Linux/x86) and SBCL (Linux/x86). (LispWorks shouldn't be a problem anyway as it's not affected by the switch.)
I think that at least LispWorks, SBCL, AllegroCL, CMUCL, CLISP, and OpenMCL should be supported, everything else being a bonus. Operating systems: Windows (where applicable), Linux, OS X.
If you don't want to test all of this for yourself, how about offering a tarball of Drakma which uses usocket for download? Send an announcement to this mailing list including an overview of what you've tested and what not. We can ask "interested parties" to try it out and we'll switch to the new version in four weeks, say, unless someone objects. Does that sound OK?
Sounds great. I did an initial port which works, but I then realised it doesn't exactly conform to the current usocket API :-( What I did was bind the socket-stream associated with the usocket object instead of the open-stream return value by trivial-sockets. That will work on all (current) implementations, but doesn't really conform with the API. The only benefit will be that Drakma runs on more platforms, but none of the additional usocket functionality can be used (as the usocket object itself can't be retrieved from the stream). This means I have 3 choices: 1) return both the stream and the socket object in the return values 2) use trivial-usocket: the trivial-sockets portability library which associates a usocket with a gray stream. Closing the stream will close the socket. But it adds another (rather useless IMO) call for every socket stream operation. Also, trivial-usocket has a smaller supported set of implementations than usocket does. 3) slightly violate/change the usocket API to require changing the stream to be a valid action for closing the socket. So, my initial reaction would be to change the http-request interface: still returning the http-stream return value, but return also a seventh value: the socket. On input we'd require the stream and the socket when the :stream key is supplied. But I could live with (3) as well. Do you have any preferences? bye, Erik.
On Fri, 2 Mar 2007 22:44:42 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
This means I have 3 choices:
1) return both the stream and the socket object in the return values 2) use trivial-usocket: the trivial-sockets portability library which associates a usocket with a gray stream. Closing the stream will close the socket. But it adds another (rather useless IMO) call for every socket stream operation. Also, trivial-usocket has a smaller supported set of implementations than usocket does. 3) slightly violate/change the usocket API to require changing the stream to be a valid action for closing the socket.
So, my initial reaction would be to change the http-request interface: still returning the http-stream return value, but return also a seventh value: the socket. On input we'd require the stream and the socket when the :stream key is supplied.
But I could live with (3) as well.
Do you have any preferences?
I'd prefer (3) because it means we don't have to change Drakma and I won't have to do any work (for which I don't have time right now). But I can live with (1), if you provide a clean patch for that - including all the necessary updates to docstrings and the HTML documentation... What is the additional usocket functionality we'd lose if we opt for (3)? Thanks, Edi.
On 3/4/07, Edi Weitz <edi@agharta.de> wrote:
On Fri, 2 Mar 2007 22:44:42 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
This means I have 3 choices:
1) return both the stream and the socket object in the return values 2) use trivial-usocket: the trivial-sockets portability library which associates a usocket with a gray stream. Closing the stream will close the socket. But it adds another (rather useless IMO) call for every socket stream operation. Also, trivial-usocket has a smaller supported set of implementations than usocket does. 3) slightly violate/change the usocket API to require changing the stream to be a valid action for closing the socket.
So, my initial reaction would be to change the http-request interface: still returning the http-stream return value, but return also a seventh value: the socket. On input we'd require the stream and the socket when the :stream key is supplied.
But I could live with (3) as well.
Do you have any preferences?
I'd prefer (3) because it means we don't have to change Drakma and I won't have to do any work (for which I don't have time right now).
I figured so much, so I've been working to make the API support (3). It looks like I'll be able to make it so.
But I can live with (1), if you provide a clean patch for that - including all the necessary updates to docstrings and the HTML documentation...
I'll regard (3) as a minimal version. I can submit a patch for (1) which will ofcourse change the docs and docstrings. For now, I'll focus on (3) though.
What is the additional usocket functionality we'd lose if we opt for (3)?
It won't be possible to support any other function than reading/writing content on the socket. Other functionality includes retrieving the local or remote socket 'names' (ip+port). I hope to support read/write timeout settings in the future too. That functionality won't be available (outside of http-request; internally, it could bind the usocket, ofcourse). I hope that answers your question. bye, Erik.
On Sun, 4 Mar 2007 17:07:01 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I'd prefer (3) because it means we don't have to change Drakma and I won't have to do any work (for which I don't have time right now).
I figured so much, so I've been working to make the API support (3). It looks like I'll be able to make it so.
But I can live with (1), if you provide a clean patch for that - including all the necessary updates to docstrings and the HTML documentation...
I'll regard (3) as a minimal version. I can submit a patch for (1) which will ofcourse change the docs and docstrings. For now, I'll focus on (3) though.
OK, fine with me.
What is the additional usocket functionality we'd lose if we opt for (3)?
It won't be possible to support any other function than reading/writing content on the socket. Other functionality includes retrieving the local or remote socket 'names' (ip+port). I hope to support read/write timeout settings in the future too. That functionality won't be available (outside of http-request; internally, it could bind the usocket, ofcourse).
I hope that answers your question.
Yes, thanks. It looks like (1) should be the medium-term goal, especially as (user-defined) timeouts are currently only available for LispWorks. Thanks, Edi.
On 2/25/07, Edi Weitz <edi@agharta.de> wrote:
On Sun, 25 Feb 2007 14:38:02 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I think that at least LispWorks, SBCL, AllegroCL, CMUCL, CLISP, and OpenMCL should be supported, everything else being a bonus. Operating systems: Windows (where applicable), Linux, OS X.
If you don't want to test all of this for yourself, how about offering a tarball of Drakma which uses usocket for download? Send an announcement to this mailing list including an overview of what you've tested and what not. We can ask "interested parties" to try it out and we'll switch to the new version in four weeks, say, unless someone objects. Does that sound OK?
I created a patch (and a full archive) for drakma 0.6.0. I did initial testing with usocket 0.3.2 and sbcl on linux 2.6. I'll put up a text file at the same location to log the already-tested combinations. The archive is at http://hix.nu/drakma/ (which is behind my dsl line at 1Mbit). Version 0.3.2 for usocket is required: I added the close-the-stream-means-closing-the-socket API guarantee in that version. Any problems with usocket can be reported directly to me, here (for reference for other testers), or at usocket-devel@common-lisp.net. I'll be testing a number of other combinations too, but I was out of time this weekend. Thanks in advance for any help provided! bye, Erik.
On Mon, 5 Mar 2007 08:54:57 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I created a patch (and a full archive) for drakma 0.6.0. I did initial testing with usocket 0.3.2 and sbcl on linux 2.6. I'll put up a text file at the same location to log the already-tested combinations. The archive is at http://hix.nu/drakma/ (which is behind my dsl line at 1Mbit).
Version 0.3.2 for usocket is required: I added the close-the-stream-means-closing-the-socket API guarantee in that version.
Any problems with usocket can be reported directly to me, here (for reference for other testers), or at usocket-devel@common-lisp.net.
I'll be testing a number of other combinations too, but I was out of time this weekend.
Did you get any more test results in the meantime?
On 3/9/07, Edi Weitz <edi@agharta.de> wrote:
On Mon, 5 Mar 2007 08:54:57 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I created a patch (and a full archive) for drakma 0.6.0. I did initial testing with usocket 0.3.2 and sbcl on linux 2.6. I'll put up a text file at the same location to log the already-tested combinations. The archive is at http://hix.nu/drakma/ (which is behind my dsl line at 1Mbit).
Version 0.3.2 for usocket is required: I added the close-the-stream-means-closing-the-socket API guarantee in that version.
Any problems with usocket can be reported directly to me, here (for reference for other testers), or at usocket-devel@common-lisp.net.
I'll be testing a number of other combinations too, but I was out of time this weekend.
Did you get any more test results in the meantime?
I did. I tested with LispWorks, Allegro 8, cmucl, ecl and clisp on Linux. My clisp was incompatible with cl+ssl, so I'll post more results later. ECL isn't compatible with trivial-gray-streams, it seems. The other 3 worked without problems. Leaves OpenMCL (which I can't test) and LispWorks and Allegro on Windows (which I'll post about later, since I'm in Linux now). All in all, it seems to work just fine. bye, Erik.
On 4/6/07, Erik Huelsmann <ehuels@gmail.com> wrote:
On 3/9/07, Edi Weitz <edi@agharta.de> wrote:
On Mon, 5 Mar 2007 08:54:57 +0100, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I created a patch (and a full archive) for drakma 0.6.0. I did initial testing with usocket 0.3.2 and sbcl on linux 2.6. I'll put up a text file at the same location to log the already-tested combinations. The archive is at http://hix.nu/drakma/ (which is behind my dsl line at 1Mbit).
Version 0.3.2 for usocket is required: I added the close-the-stream-means-closing-the-socket API guarantee in that version.
Any problems with usocket can be reported directly to me, here (for reference for other testers), or at usocket-devel@common-lisp.net.
I'll be testing a number of other combinations too, but I was out of time this weekend.
Did you get any more test results in the meantime?
I did. I tested with LispWorks, Allegro 8, cmucl, ecl and clisp on Linux.
My clisp was incompatible with cl+ssl, so I'll post more results later. ECL isn't compatible with trivial-gray-streams, it seems.
The other 3 worked without problems.
Leaves OpenMCL (which I can't test) and LispWorks and Allegro on Windows (which I'll post about later, since I'm in Linux now).
Ok. I tested on Windows too. I have LispWorks and ACL 6.2 on Windows. The latter doesn't work with start.lisp from STARTER-PACK, so I wasn't really able to tell. LispWorks works beautifully though. That was all the testing I can do. BTW: the CL+SSL problems I experienced were with the newest clisp (2.41), so it looks like Drakma isn't able to run on clisp anymore (?). If there are any more Windows/Linux implementations you want me to test with, just say so! bye, Erik.
On Fri, 6 Apr 2007 14:43:30 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
Ok. I tested on Windows too. I have LispWorks and ACL 6.2 on Windows. The latter doesn't work with start.lisp from STARTER-PACK
Sure. STARTER-PACK is only for LispWorks. For AllegroCL, you'd have to figure out a way to locate the ASDF systems. FWIW, the relevant parts of my ~/.clinit.cl on Windows look like this: (in-package :cl-user) (require :asdf) #+:asdf (dolist (dir-candidate (directory "c:/home/lisp/*" :directories-are-files nil)) (when (excl:file-directory-p dir-candidate) (let ((asd-candidate (merge-pathnames "*.asd" dir-candidate))) (when (directory asd-candidate) (push dir-candidate asdf:*central-registry*))))) That should slurp in all "c:/home/lisp/*/*.asd" system definitions.
That was all the testing I can do. BTW: the CL+SSL problems I experienced were with the newest clisp (2.41), so it looks like Drakma isn't able to run on clisp anymore (?).
Hmm, maybe the CLISP users on this list should try and report to the CL+SSL mailing list if necessary. I personally don't use CLISP.
If there are any more Windows/Linux implementations you want me to test with, just say so!
AllegroCL and LispWorks are important for me. I guess that some people would eventually be interested in SBCL/Win, but I don't know how mature it is. CormanLisp would be nice to have, but I'm not aware that there is currently anyone using Corman with Drakma. They should probably take care of testing themselves. Thanks, Edi.
Scribit Edi Weitz dies 06/04/2007 hora 15:30:
I guess that some people would eventually be interested in SBCL/Win, but I don't know how mature it is.
Threads are not working yet, so it's not a valid choice for using Hunchentoot, I suppose. It may be possible to test it's compatibility, though. Quickly, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
On 4/6/07, Edi Weitz <edi@agharta.de> wrote:
On Fri, 6 Apr 2007 14:43:30 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
Ok. I tested on Windows too. I have LispWorks and ACL 6.2 on Windows. The latter doesn't work with start.lisp from STARTER-PACK
Sure. STARTER-PACK is only for LispWorks.
For AllegroCL, you'd have to figure out a way to locate the ASDF systems. FWIW, the relevant parts of my ~/.clinit.cl on Windows look like this:
(in-package :cl-user)
(require :asdf)
#+:asdf (dolist (dir-candidate (directory "c:/home/lisp/*" :directories-are-files nil)) (when (excl:file-directory-p dir-candidate) (let ((asd-candidate (merge-pathnames "*.asd" dir-candidate))) (when (directory asd-candidate) (push dir-candidate asdf:*central-registry*)))))
That should slurp in all "c:/home/lisp/*/*.asd" system definitions.
That was all the testing I can do. BTW: the CL+SSL problems I experienced were with the newest clisp (2.41), so it looks like Drakma isn't able to run on clisp anymore (?).
Hmm, maybe the CLISP users on this list should try and report to the CL+SSL mailing list if necessary. I personally don't use CLISP.
If there are any more Windows/Linux implementations you want me to test with, just say so!
AllegroCL and LispWorks are important for me. I guess that some people would eventually be interested in SBCL/Win, but I don't know how mature it is. CormanLisp would be nice to have, but I'm not aware that there is currently anyone using Corman with Drakma.
That should be hard: Corman doesn't have octet socket streams, nor does it have trivial-sockets support. I'm working on making Corman support octet/binary sockets, but it has a bit of a weird subtypep implementation (ie non-conforming) which may make it hard to use it with flexi-streams [(progn (deftype 'octet '(unsigned-byte 8)) (subtypep 'octet '(unsigned-byte 8))) -> NIL NIL ]
They should probably take care of testing themselves.
Ok.
Thanks, Edi.
I'm not aware of a public Drakma repository. If there isn't, could you tell me whether you applied the patch if/when you do? I can update the Drakma item in the cl-directory then. Thank you too, for all the libraries you provide! bye, Erik.
On Sat, 7 Apr 2007 00:13:28 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I'm not aware of a public Drakma repository.
There isn't any.
If there isn't, could you tell me whether you applied the patch if/when you do? I can update the Drakma item in the cl-directory then.
Sorry for asking dumb questions, but did you send the patch already? When was that?
Thank you too, for all the libraries you provide!
You're welcome... :)
On 4/7/07, Edi Weitz <edi@agharta.de> wrote:
On Sat, 7 Apr 2007 00:13:28 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
I'm not aware of a public Drakma repository.
There isn't any.
If there isn't, could you tell me whether you applied the patch if/when you do? I can update the Drakma item in the cl-directory then.
Sorry for asking dumb questions, but did you send the patch already? When was that?
In a message on March 5th, I sent a message which included a reference to a patch located on the net and also an archive based on drakma-0.6.0, with the patch built in. (http://hix.nu/drakma/) For your convenience, I attached the patch to this message too. I see that you have released 0.6.2 now, but the patch still seems to apply just fine. It updates doc/index.html, drakma.asd and request.lisp. bye, Erik.
On Sat, 7 Apr 2007 16:52:40 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
For your convenience, I attached the patch to this message too.
OK, thanks, I've now made a new release (0.7.0) based on your patch. Cheers, Edi.
Scribit Edi Weitz dies 07/04/2007 hora 20:23:
OK, thanks, I've now made a new release (0.7.0) based on your patch.
BTW, I now also mirror drakma: http://arcanes.fr.eu.org/~pierre/2007/02/weitz/ Recently, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
On Sat, 7 Apr 2007 16:52:40 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
For your convenience, I attached the patch to this message too.
As the docs point to the CLiki page and say 0.3.2 or higher is required, it'd be nice if the CLiki page pointed to something like 0.3.2 (or higher) - also for ASDF-INSTALL.
On 4/7/07, Edi Weitz <edi@agharta.de> wrote:
On Sat, 7 Apr 2007 16:52:40 +0200, "Erik Huelsmann" <ehuels@gmail.com> wrote:
For your convenience, I attached the patch to this message too.
As the docs point to the CLiki page and say 0.3.2 or higher is required, it'd be nice if the CLiki page pointed to something like 0.3.2 (or higher) - also for ASDF-INSTALL.
Ofcourse. I updated it now. Thank you for accepting the patch. Bye, Erik.
Scribit Erik Huelsmann dies 05/03/2007 hora 08:54:
Any problems with usocket can be reported directly to me, here (for reference for other testers), or at usocket-devel@common-lisp.net.
Testing a network system is far more difficult and error-prone than testing e.g. a calculus library, so maybe providing a test suite would be valuable here. I was about to test this usocket version of drakma when I realized that I wouldn't where to begin... Uncertainly, Pierre -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
On Fri, 9 Mar 2007 02:23:47 +0100, Pierre THIERRY <nowhere.man@levallois.eu.org> wrote:
Testing a network system is far more difficult and error-prone than testing e.g. a calculus library, so maybe providing a test suite would be valuable here.
I thought about a test suite for Drakma, but for that to make sense you'd need a reasonable set of very stable URLs (can always be reached, content never changes). These are hard to find, I'd say...
I was about to test this usocket version of drakma when I realized that I wouldn't where to begin...
Just visit a few URLs you're usually visiting with your web browser. Or follow the examples in the Drakma documentation.
participants (3)
-
Edi Weitz -
Erik Huelsmann -
Pierre THIERRY