From: Raymond W. <Ray...@fa...> - 2001-01-28 13:43:38
|
I've just spent a couple of hours getting CLX to build (and work :-) under SBCL again. The only things I had to change this time round were due to the change in behaviour of defconstant - I had to use sb-int:defconstant-eqx instead. Actually, I suspect that there is something wrong with the current behaviour of defconstant. Given a file containing only (defconstant *foo* :foo) If I compile this file, using (compile-file "test"), I can then evaluate *foo* to :foo. I.e, the defconstant from the compiled file modifies the running Lisp. This means that it is impossible to compile a file containing, say (defconstant *bar* '#(1 2 3)) and subsequently loading this file. Is this the correct behaviour? While investigating this, I looked at the definition of sb-int:defconstant-eqx in src/code/primordial-extensions.lisp. It seems that there is a bug there; the main body of the macro evaluates expr twice (it should use expr-tmp in the defconstant form). CLX currently builds and works (for some of the demos, at least). It requires a working internet.lisp, which I've also worked on. This is possibly something that other SBCL users may have an interest in - should I put it on a web server somewhere? Alternatively, should it be put under SBCL's "contrib" directory? Note that, with CLX and Gray-streams available, it should be possible to build FreeCLIM (aka McCLIM) under SBCL... //Raymond. -- Raymond Wiker Ray...@fa... |
From: William H. N. <wil...@ai...> - 2001-01-30 04:08:19
|
On Sun, Jan 28, 2001 at 02:43:44PM +0100, Raymond Wiker wrote: > I've just spent a couple of hours getting CLX to build (and > work :-) under SBCL again. The only things I had to change this time > round were due to the change in behaviour of defconstant - I had to > use sb-int:defconstant-eqx instead. > > Actually, I suspect that there is something wrong with the > current behaviour of defconstant. Given a file containing only > > (defconstant *foo* :foo) > > If I compile this file, using (compile-file "test"), I can > then evaluate *foo* to :foo. I.e, the defconstant from the compiled > file modifies the running Lisp. This means that it is impossible to > compile a file containing, say > > (defconstant *bar* '#(1 2 3)) > > and subsequently loading this file. > > Is this the correct behaviour? I think the biggest problem is that DEFCONSTANT is not a particularly good name for the behavior specified by ANSI. This is definitely conforming behavior. From the HyperSpec for DEFCONSTANT: If a DEFCONSTANT form appears as a top level form, the compiler must recognize that name names a constant variable. An implementation may choose to evaluate the value-form at compile time, load time, or both. Therefore, users must ensure that the initial-value can be evaluated at compile time (regardless of whether or not references to NAME appear in the file) and that it always evaluates to the same value. and The consequences are undefined if there are any bindings of the variable named by name at the time DEFCONSTANT is executed or if the value is not EQL to the value of INITIAL-VALUE. So (DEFCONSTANT *BAR* #'(1 2 3)) is not conforming code, at least not unless you make sure you never load it into the same image which compiled it. If I understand correctly, the preferred solution in most cases of non-EQL values, probably including this one, is to use DEFVAR instead of DEFCONSTANT. (And thus it seems to me that DEFCONSTANT is a rather non-mnemonic name. It certainly seems to spawn controversy regularly on comp.lang.lisp.) > While investigating this, I looked at the definition of > sb-int:defconstant-eqx in src/code/primordial-extensions.lisp. It > seems that there is a bug there; the main body of the macro evaluates > expr twice (it should use expr-tmp in the defconstant form). Yes, I think you're right. I'll make a note to myself to check in the fix after my hacking on intersection types settles down. Maybe around the same time I'll finally get around to trying the suggestion from your 2000-12-01 mail, too: I also suggested that "-Xlinker -export-dynamic" might work under OpenBSD instead of simply "-export-dynamic" - has anybody looked at this? > CLX currently builds and works (for some of the demos, at > least). It requires a working internet.lisp, which I've also worked > on. This is possibly something that other SBCL users may have an > interest in - should I put it on a web server somewhere? > Alternatively, should it be put under SBCL's "contrib" directory? That sounds useful to me. (Not useful to me personally, at least not for a while, but useful on general principles.) Unless it's incredibly huge, I'd be happy to use SBCL's SourceForge site to make it available. How big is it? If it's small, it could be in contrib/. Otherwise, I'd prefer to put it in the anonymous ftp area if you consider it experimental, or if you prefer, and if you think you'll be supporting it for a while, to make it into a separately released module. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Raymond W. <Ray...@fa...> - 2001-01-30 07:58:57
|
William Harold Newman writes: > I think the biggest problem is that DEFCONSTANT is not a particularly > good name for the behavior specified by ANSI. > > This is definitely conforming behavior. From the HyperSpec for > DEFCONSTANT: > If a DEFCONSTANT form appears as a top level form, the compiler must > recognize that name names a constant variable. An implementation may > choose to evaluate the value-form at compile time, load time, or both. > Therefore, users must ensure that the initial-value can be evaluated > at compile time (regardless of whether or not references to NAME > appear in the file) and that it always evaluates to the same value. > and > The consequences are undefined if there are any bindings of the > variable named by name at the time DEFCONSTANT is executed or if the > value is not EQL to the value of INITIAL-VALUE. > So (DEFCONSTANT *BAR* #'(1 2 3)) is not conforming code, at least > not unless you make sure you never load it into the same image > which compiled it. If I understand correctly, the preferred > solution in most cases of non-EQL values, probably including this > one, is to use DEFVAR instead of DEFCONSTANT. (And thus it seems > to me that DEFCONSTANT is a rather non-mnemonic name. It certainly > seems to spawn controversy regularly on comp.lang.lisp.) Ok, I see the sense in this :-) I guess I should change the CLX code to use defparameter (better than defvar, I think?) instead of defconstant wherever it's used to set a value that is not trivially eql to itself (errr....) > > CLX currently builds and works (for some of the demos, at > > least). It requires a working internet.lisp, which I've also worked > > on. This is possibly something that other SBCL users may have an > > interest in - should I put it on a web server somewhere? > > Alternatively, should it be put under SBCL's "contrib" directory? > > That sounds useful to me. (Not useful to me personally, at least not > for a while, but useful on general principles.) Unless it's incredibly > huge, I'd be happy to use SBCL's SourceForge site to make it > available. How big is it? If it's small, it could be in contrib/. > Otherwise, I'd prefer to put it in the anonymous ftp area if you > consider it experimental, or if you prefer, and if you think you'll be > supporting it for a while, to make it into a separately released > module. "du" on a clean source tree claims that CLX is about 1200 kB; the compressed tar file is probably about 700-700 kB. I guess this amkes it slightly too large to put in contrib :-) The options, as I see them, are: - put a tar file in the ftp area at SourceForge - put CLX under contrib (I think it's a bit too large for that); the file "internet.lisp" may be a better candidate for placement under contrib. - create a new SourceForge project for SBCL extensions - create a new SourceForge project for CLX (cross-platform) It's possible that CLX won't need much maintenance. If so, the ftp file solution is probably best. Maybe we should start with this approach, and see if it works? //Raymond. |
From: William H. N. <wil...@ai...> - 2001-01-30 16:32:15
|
On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > Ok, I see the sense in this :-) I guess I should change the > CLX code to use defparameter (better than defvar, I think?) instead of > defconstant wherever it's used to set a value that is not trivially > eql to itself (errr....) As I understand it, this is what ANSI wants you to do. It's basically what I did for SBCL. (One of the reasons why I made SBCL's DEFCONSTANT strict is that I want SBCL itself to be portable to any ANSI compiler, and I usually build SBCL with itself, and I didn't want to fall into relying on non-ANSI behavior.) > It's possible that CLX won't need much maintenance. If so, the > ftp file solution is probably best. Maybe we should start with this > approach, and see if it works? That sounds good to me. Could you tell me more about how you'd like to do the distribution? E.g. * What files do you want to have in the FTP area? Besides the tarball, it would probably be nice to have at least something like README-clx-1.1. * What information would you like on the SBCL web pages? I can write a sentence or two on the http://sbcl.sourceforge.net/libs.php page, but if you'd like a descriptive page or something, you should probably send me HTML text for it, since I don't know enough about CLX to write it myself. * Do you have some way of securely signing the distribution files? I use an ancient version of PGP for mine, but you could use something else instead if it's more convenient. * What version numbering scheme do you want to use? Then, if you have an FTP area I can get the file(s) from, or a guest account somewhere I can scp them from, or some such thing, send me e-mail with information on how to get them. Otherwise, we can try to figure out some more roundabout way to transfer them. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Raymond W. <Ray...@fa...> - 2001-01-30 17:47:03
|
William Harold Newman writes: > On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > > Ok, I see the sense in this :-) I guess I should change the > > CLX code to use defparameter (better than defvar, I think?) instead of > > defconstant wherever it's used to set a value that is not trivially > > eql to itself (errr....) > > As I understand it, this is what ANSI wants you to do. It's basically > what I did for SBCL. (One of the reasons why I made SBCL's DEFCONSTANT > strict is that I want SBCL itself to be portable to any ANSI compiler, > and I usually build SBCL with itself, and I didn't want to fall into > relying on non-ANSI behavior.) Ok, I'll do that, then. > > It's possible that CLX won't need much maintenance. If so, the > > ftp file solution is probably best. Maybe we should start with this > > approach, and see if it works? > > That sounds good to me. > > Could you tell me more about how you'd like to do the distribution? E.g. > * What files do you want to have in the FTP area? Besides the > tarball, it would probably be nice to have at least something > like README-clx-1.1. An associated README file sounds good. > * What information would you like on the SBCL web pages? I can write > a sentence or two on the http://sbcl.sourceforge.net/libs.php page, > but if you'd like a descriptive page or something, you should > probably send me HTML text for it, since I don't know enough > about CLX to write it myself. Ok, I'll look into this. > * Do you have some way of securely signing the distribution files? > I use an ancient version of PGP for mine, but you could use > something else instead if it's more convenient. PGP sounds fine. > * What version numbering scheme do you want to use? How about just a date (on the README and the tarball)? That would avoid any confusion with "official" CLX version numbers. > Then, if you have an FTP area I can get the file(s) from, or a guest > account somewhere I can scp them from, or some such thing, send me > e-mail with information on how to get them. Otherwise, we can try to > figure out some more roundabout way to transfer them. I have access to several ftp servers, so this should not be a problem. Daniel Barlow mentioned that he was going to package up his sockets package so that it was compatible with Peter Van Eynde's "Common Lisp Controller" system. This sounds like a good idea for CLX, too. I'll contact you again as soon as I've got this into something that others may be able to use. //Raymond. -- Raymond Wiker Ray...@fa... |
From: Sunil M. <sun...@ev...> - 2001-01-30 21:15:25
|
William Harold Newman wrote: > On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > >> Ok, I see the sense in this :-) I guess I should change the >> CLX code to use defparameter (better than defvar, I think?) instead of >> defconstant wherever it's used to set a value that is not trivially >> eql to itself (errr....) > > > As I understand it, this is what ANSI wants you to do. It's basically > what I did for SBCL. (One of the reasons why I made SBCL's DEFCONSTANT > strict is that I want SBCL itself to be portable to any ANSI compiler, > and I usually build SBCL with itself, and I didn't want to fall into > relying on non-ANSI behavior.) I probably should have chimed in earlier... I was responsible for starting one of the threads on DEFCONSTANT behavior, so the solutions proposed have stayed with me a while. There is another standard means for getting the "right" behavior from DEFCONSTANT: LOAD-TIME-VALUE. If you look at the hyperspec entry: --- Special Operator LOAD-TIME-VALUE ... load-time-value provides a mechanism for delaying evaluation of form until the expression is in the run-time environment; see Section 3.2 (Compilation). --- So, if you wrap the evaluation of the defined constant in load-time-value, you should be able to get EQL comparable non-atomic objects across compilation units (files). I don't know if SBCL is equipped to do the right thing using this form, that you will have to experiment with yourself :-) S |
From: Peter V. E. <pva...@de...> - 2001-01-31 16:09:55
|
On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > "du" on a clean source tree claims that CLX is about 1200 kB; > the compressed tar file is probably about 700-700 kB. I guess this > amkes it slightly too large to put in contrib :-) > > The options, as I see them, are: > > - put a tar file in the ftp area at SourceForge > > - put CLX under contrib (I think it's a bit too large for > that); the file "internet.lisp" may be a better candidate > for placement under contrib. > > - create a new SourceForge project for SBCL extensions > > - create a new SourceForge project for CLX (cross-platform) - put it into CLOCC There are other people interested in working on CLX, putting it on CLOCC and replacing the socket interface with the one of CLOCC would enable a lot of people to run it, use it and enhance it. Groetjes, Peter -- It's logic Jim, but not as we know it. | pva...@de... "God, root, what is difference?" - Pitr| "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/ |
From: Raymond W. <Ray...@fa...> - 2001-01-31 16:20:43
|
Peter Van Eynde writes: > On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > > "du" on a clean source tree claims that CLX is about 1200 kB; > > the compressed tar file is probably about 700-700 kB. I guess this > > amkes it slightly too large to put in contrib :-) > > > > The options, as I see them, are: [ Snip ] > > - put it into CLOCC > > There are other people interested in working on CLX, putting it on > CLOCC and replacing the socket interface with the one of CLOCC would > enable a lot of people to run it, use it and enhance it. This is an excellent idea! Do you have any names/addresses for people that I should contact (or maybe I should just post to one of the CLOCC mailing lists?) //Raymond. -- Raymond Wiker Ray...@fa... |
From: William H. N. <wil...@ai...> - 2001-01-31 17:01:17
|
On Wed, Jan 31, 2001 at 05:20:39PM +0100, Raymond Wiker wrote: > Peter Van Eynde writes: > > On Tue, Jan 30, 2001 at 08:59:03AM +0100, Raymond Wiker wrote: > > > "du" on a clean source tree claims that CLX is about 1200 kB; > > > the compressed tar file is probably about 700-700 kB. I guess this > > > amkes it slightly too large to put in contrib :-) > > > > > > The options, as I see them, are: > > [ Snip ] > > > > - put it into CLOCC > > > > There are other people interested in working on CLX, putting it on > > CLOCC and replacing the socket interface with the one of CLOCC would > > enable a lot of people to run it, use it and enhance it. > > This is an excellent idea! Do you have any names/addresses for > people that I should contact (or maybe I should just post to one of > the CLOCC mailing lists?) Yes, yes, yes! Anyone who's read the list for a long time may remember that I've argued in the past that things like this should be libraries if possible. I haven't lost the courage of my convictions, I just didn't know enough about the guts of CLX to realize that it could easily be maintained as a portable or semi-portable library, or I'd have suggested this myself. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Martin A. <ma...@at...> - 2001-01-30 11:10:14
|
Raymond Wiker wrote: [...] > CLX currently builds and works (for some of the demos, at > least). It requires a working internet.lisp, which I've also worked Sounds great! > on. This is possibly something that other SBCL users may have an > interest in - should I put it on a web server somewhere? > Alternatively, should it be put under SBCL's "contrib" directory? Well, thanks to the code you sent me some time ago, I have a working internet.lisp sitting around, too - but others may not. So, making this available is a good idea, IMO, since SBCL does not have a native socket-library per se. IMHO, internet.lisp is a valid option for sockets, and it probably makes porting work easier - but the socket-library by Dan Barlow is really more powerful ... Cheers, Martin -- Martin Atzmueller <ma...@at...> |
From: Raymond W. <Ray...@fa...> - 2001-01-30 12:17:30
|
Martin Atzmueller writes: > Raymond Wiker wrote: > > [...] > > > CLX currently builds and works (for some of the demos, at > > least). It requires a working internet.lisp, which I've also worked > Sounds great! > > > on. This is possibly something that other SBCL users may have an > > interest in - should I put it on a web server somewhere? > > Alternatively, should it be put under SBCL's "contrib" directory? > Well, thanks to the code you sent me some time ago, I have a working > internet.lisp sitting around, too - but others may not. What changes have you made to this file? I don't think I made any changes after I sent a version to you; if you've made any changes, then your version is the one that we should keep. > So, making this available is a good idea, IMO, since SBCL does not > have a native socket-library per se. > > IMHO, internet.lisp is a valid option for sockets, and it probably makes > porting work easier - but the socket-library by Dan Barlow is really > more powerful ... Agreed. Actually, I had CLX working with db-sockets as well - the changes required are absolutely minimal. //Raymond. -- Raymond Wiker Ray...@fa... |
From: Daniel B. <da...@no...> - 2001-01-30 12:33:25
|
Martin Atzmueller <ma...@at...> writes: > IMHO, internet.lisp is a valid option for sockets, and it probably makes > porting work easier - but the socket-library by Dan Barlow is really > more powerful ... For what it's worth, I intend to make said socket library compatible with PVE's Common Lisp Controller just as soon as (a) I have time, (b) I work out what that entails. I'm hoping that should make it easier for people to install. Of course, I'm perfectly happy to be sent patches in the meantime ... -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: William H. N. <wil...@ai...> - 2001-01-30 21:37:31
|
On Tue, Jan 30, 2001 at 10:57:51PM +0100, Martin Atzmueller wrote: > William Harold Newman wrote: > > > > On Tue, Jan 30, 2001 at 01:08:27PM +0100, Martin Atzmueller wrote: > > [...] > > > > IMHO, internet.lisp is a valid option for sockets, and it probably makes > > > porting work easier - but the socket-library by Dan Barlow is really > > > more powerful ... > > > > Would you like to put this somewhere on the SBCL site? If the > > socket-library stuff is preferred, then perhaps internet.lisp > > shouldn't be in contrib/, but if it's still useful in some cases, and > > it doesn't have any home elsewhere, perhaps it should go in the SBCL > > FTP directory. > Yes, I guess it should at least go into the ftp-directory, when it is > ready. > Sometimes a socket-interface is not only very nice, it is necessary. :) True. I have some perl-based socket-using glue code which may turn into SBCL code one of these days. I'm glad that socket support is available. Also.. You wrote in an earlier message that the sockets stuff is based in part on some functions in SB-UNIX. IMHO it would be much better to build the sockets library, or other libraries, directly on the public, stable extensions in SB-ALIEN and SB-C-CALL, rather than trying to reuse the private, unstable wrapper functions in SB-UNIX. (I really don't want core SBCL to be in the business of providing publicly accessible wrappers for general Unix stuff. As I've written before, the CMU CL people have tried to do this, and they've been unsuccessful in keeping it up to date, which is a sobering thing to keep in mind. SBCL does provide interfaces to a few Unix/POSIX things which are available under almost any system (e.g. command line arguments, environment variables, process return values, and running other processes via exec(3)). Those interfaces are exported from public packages like SB-EXT, and I'd like them to be stable. But SB-UNIX is an internal implementation package, not a public package. I consider things in SB-UNIX to be private implementation details, subject to change without notice.) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Martin A. <ma...@at...> - 2001-02-02 23:18:02
|
William Harold Newman wrote: [ ... snip ... ] > You wrote in an earlier message that the sockets stuff is based in > part on some functions in SB-UNIX. Yes. It is/was based on a lot of functions in SB-UNIX. > IMHO it would be much better to build the sockets library, or other > libraries, directly on the public, stable extensions in SB-ALIEN and > SB-C-CALL, rather than trying to reuse the private, unstable wrapper > functions in SB-UNIX. Agreed. Actually I already had done that in part, but I've now added a lot more alien wrappers for things that are in sb-unix, too. The only dependency left is mainly #'sb-unix:get-unix-error-msg, and I don't know how this can be resolved without duplicating _lots of code_ from unix.lisp. -- Martin Atzmueller <ma...@at...> |
From: Martin A. <ma...@at...> - 2001-01-30 21:02:31
|
Raymond Wiker wrote: [...] > > > on. This is possibly something that other SBCL users may have an > > > interest in - should I put it on a web server somewhere? > > > Alternatively, should it be put under SBCL's "contrib" directory? > > Well, thanks to the code you sent me some time ago, I have a working > > internet.lisp sitting around, too - but others may not. > > What changes have you made to this file? I don't think I made > any changes after I sent a version to you; if you've made any changes, > then your version is the one that we should keep. Well, I have made some changes, because some functions that internet.lisp uses, like sb-unix:unix-getsockname are not (yet?) in the sb-unix package, so I added some alien-definitions for that. And then there were other cleanup issues involved to get it working ... I'll probably look into that soon and send you my version. This is, because I first moved it into its seperate package. Additionally I added some "higher level stuff" for socket handling modelled after the CLOCC's "port.lisp". I borrowed some code from Daniel Barlow's library to have SO_REUSEADDR and such, so every time I opened a socket if the connection was in timeout, this would be taken care of. (I'll probably leave it there as it is, so you can have a look at it). After that I decided it would be great to have Dan's library and some classes that employ Gray streams and db-sockets. So, sockets would be useable as streams, and still have the underlying "low-level" power. I'm currently testing my private beta-version ... > > So, making this available is a good idea, IMO, since SBCL does not > > have a native socket-library per se. > > > > IMHO, internet.lisp is a valid option for sockets, and it probably makes > > porting work easier - but the socket-library by Dan Barlow is really > > more powerful ... > > Agreed. Actually, I had CLX working with db-sockets as well - > the changes required are absolutely minimal. Maybe it would be a good idea to have a CLX that works with both socket-APIs? -- Martin Atzmueller <ma...@at...> |
From: Raymond W. <Ray...@fa...> - 2001-01-31 08:36:22
|
Martin Atzmueller writes: [ Much good stuff snipped ] > > Agreed. Actually, I had CLX working with db-sockets as well - > > the changes required are absolutely minimal. > Maybe it would be a good idea to have a CLX that works with both > socket-APIs? No problem - I think this could be based on a feature-test on db-sockets. //Raymond. |