From: <kr...@n-...> - 2000-09-08 19:16:12
|
> My impression is that internet.lisp is sufficiently far from core > functionality that it should not be part of the base > system. However, it, like CLX, is useful to many people. quite frankly, in this day and age, i can't imagine how a system like lisp could do without sockets and internet-connectivity, and some access to graphics, such as through CLX. this is important enough that it actually should be considered part of the essential core functionality. i can not see how to use sbcl without it. that networking stuff is not (yet) standardized as part of ansi cl is very unfortunate, and is more of an ugly historic artefact rather than an intentional design decision. -- greetings markus krummenacker |
From: William H. N. <wil...@ai...> - 2000-09-11 23:05:24
|
On Mon, Sep 11, 2000 at 08:20:06AM +0200, Peter Van Eynde wrote: > > I still think this is more appropriate as a library, rather than > > something which is built into the system. I'd like to bring > > the core system size down, rather than up, not just for limitations > > of system RAM, but because large systems tend to be unmanageable. > > I agree with this. But the connection with the libraries should be > pretty tight. Using the mk-defsystem and 'require' [1] we could bring > the core size down. Having separate maintainers for the libraries, but > including them in the distribution (if they are sbcl specific, otherwise > they should go in clocc or something similar). > > Most of the other issues raised are already solved in one way or another > (MaiSQL, f2cl, McCLIM). I have some comments on: > > > * CORBA > > Humpf. I just left a CORBA-based project from h*ll. I think perhaps the > technology is mature, and the lisp standard seems "nice", but the people > using it (especially the C/C++ programmers) misuse the technology a lot. > I won't work with people on CORBA unless they have at least once > successful project behind them :-(. Well, yes, there's enough cruft in CORBA to build some pretty ugly stuff, and anyway it's dead easy to screw up the architecture of a distributed system no matter what interconnection technology you use. But.. I'm currently using UNIX socket tricks on stdin/stdout to talk between a compute engine written in SBCL and a various GUI/sockets wrappers mostly written in Perl. This is one of the few possible ways of doing it in SBCL, and it's less than ideal. I'm pretty sure that using some subset of CORBA could solve this kind of problem better than it can be solved with what we have now. And besides being able to use CORBA in new designs, it could also be really handy to be able to talk with existing software systems.. > > * general UNIX support at the level of Perl > > Perl's big goodie is regexp/string manipulation. We can do even better, > but we need a portable/fast implementation. point 1: Yes, Perl has a nice regexp package. But it is easy to make a FFI wrapper around the PCRE (Perl-compatible regular expression) library. (I know because I did a specialized version for CMU CL early this year, as part of some consulting work.) This might be 80+% of the functionality that people are looking for. If someone's avoiding SBCL (or CMU CL, for that matter) because of missing regexp support, that's easy to fix. (A simple clean interface won't be blindingly fast if substring matches are required, since any clean interface will cons the substrings. But (0) most people don't need blinding performance anyway, and (0a) some people don't even need substring matches, and (1) if you wanted to avoid consing in general, you could probably hack up something involving passing adjustable strings as arguments to the function. But I don't need regexps right now for anything I'm doing, so I'm not likely to do it unless there's another consulting client out there who not only wants this but wants it merged into the general code base. point 2: For me, Perl is as useful as semi-portable Unix duct tape as it is for general string munging. Several times I have used Perl to solve small socket-intensive problems in Perl. I've been sufficiently impressed with the Unix library support, as well as the large volume of reasonably usable example code in books and on the net, that I'm likely to use it again in the future for other small hacks involving sockets, processes, and other comparably-low-level Unix stuff (unless someone comes up with some really nice libraries for SBCL:-). > I am agreeing here, but don't downclass the sbcl-specific libraries to > second-class code by asking people to hunt around for pieces here and > there. Include it in the distribution and have hooks for mk-defsystem > and require. Yes. Small, reasonably-well-maintained libraries of reasonably general interest should be welcome in the distribution. Larger libraries, or libraries of narrow interest (e.g. support for ham radio:-) can go on the web site. Really big ones should probably become their own project, on SourceForge or elsewhere, and I'll make links to them. I don't know enough about DEFSYSTEM yet to know what help it needs, but a lot of people like it, so as long as hooks aren't too hard, I'm receptive to the idea. As far as I can see, most of the be-friendly-to-users issues involved with libraries are the responsibility of library maintainers, not maintainers of SBCL in general. It seems to me that the main responsibility of SBCL maintainers for libraries is to avoid breaking libraries by changing things like FFI. -- 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 ----- End forwarded message ----- -- 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: Daniel B. <da...@te...> - 2000-09-12 22:16:25
|
William Harold Newman <wil...@ai...> writes: > On Mon, Sep 11, 2000 at 08:20:06AM +0200, Peter Van Eynde wrote: > > Perl's big goodie is regexp/string manipulation. We can do even better, > > but we need a portable/fast implementation. > > point 1: Yes, Perl has a nice regexp package. But it is easy to make a > FFI wrapper around the PCRE (Perl-compatible regular expression) Yep. Oddly enough, I've done that too - and then found that I never had a use for the thing. Something about Lisp makes me tend to want to write a proper parser for whatever-it-is instead of hacking it with regexes. > point 2: For me, Perl is as useful as semi-portable Unix duct tape as Undoubtedly. If, say, you want to get a stock quote out of the middle of a web site somewhere and recalculate a bunch of columns in a comma-separated text file based on it, Perl is very definitely your baby. > As far as I can see, most of the be-friendly-to-users issues involved > with libraries are the responsibility of library maintainers, not > maintainers of SBCL in general. It seems to me that the main > responsibility of SBCL maintainers for libraries is to avoid breaking > libraries by changing things like FFI. That and telling people where to get said libraries from. Yes, I'd tend to agree. Again. And distribution maintainers can gather the whole thing together and package it neatly. Is anyone planning on doing RPMs/.debs? (Peter?) (Not that the thought hasn't crossed my mind too, but I've seen the tortuous process that it is to join the debian developer community these days, so perhaps when I have more time) -dan -- http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm |
From: Peter V. E. <pva...@de...> - 2000-09-14 20:19:37
|
> And distribution maintainers can gather the whole thing together and > package it neatly. Is anyone planning on doing RPMs/.debs? (Peter?) I've been investigating creating a common-lisp-manager for debian, just like emacsen-common, that registers common lisp compilers and common lisp source trees. That should tie in with require, so that you install cmucl, it registers. You install clocc, it registers a whole bunch of stuff and common-lisp-manager then compiles clocc for all known compilers and makes libraries (concatenated fasls) of all subsystems. If you then do (require :McClim) loads clim. Life should be so simple... I want to recompile on installation because some packages almost never change (like series) and checking if a new version of the compiler breaks previously released packages is a bitch... > (Not that the thought hasn't crossed my mind too, but I've seen the > tortuous process that it is to join the debian developer community > these days, so perhaps when I have more time) Hmm. It was not so difficult in my days and new-developer reopened, not? Groetjes, Peter -- It's logic Jim, but not as we know it. | pva...@de... for pleasure, "God, root, what is difference?" - Pitr| "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/ |
From: William H. N. <wil...@ai...> - 2000-09-08 22:00:28
|
On Fri, Sep 08, 2000 at 12:15:08PM -0700, kr...@n-... wrote: > > My impression is that internet.lisp is sufficiently far from core > > functionality that it should not be part of the base > > system. However, it, like CLX, is useful to many people. > > quite frankly, in this day and age, i can't imagine how a system like > lisp could do without sockets and internet-connectivity, and some > access to graphics, such as through CLX. this is important enough > that it actually should be considered part of the essential core > functionality. i can not see how to use sbcl without it. that > networking stuff is not (yet) standardized as part of ansi cl is very > unfortunate, and is more of an ugly historic artefact rather than an > intentional design decision. I still think this is more appropriate as a library, rather than something which is built into the system. I'd like to bring the core system size down, rather than up, not just for limitations of system RAM, but because large systems tend to be unmanageable. I agree that it's unfortunate that the Common Lisp world doesn't have * windowing support at least at the level of Tk * nice sockets support * CORBA * general UNIX support at the level of Perl * math support at least at the level of the various FOOPACK FORTRAN libraries * database support But * I think that as a rule extensions are better as libraries. (Of course, there are some exceptions to the rule, discussed below.) * I think there's a lot of value to Common Lisp even without these things. Consider all the nifty programs in Paul Graham's books, or Peter Norvig's books.. Some things are naturally part of the base system, not extra libraries, because they're used to implement the base system: * the foreign function interface * RUN-PROGRAM Some relatively small extensions, which can't really be done as libraries, are reasonable additions to the base system: * weak pointers * Gray streams There's also a place for multithreading, and I think that multithreading support is one of the best things about CMU CL. Multithreading can't be added as a library, and has to go in the core system. Unfortunately, that's a really big job, and it's my judgment that SBCL certainly (and CMU CL arguably) doesn't have the development manpower to make a solid system in any reasonable period of time while addressing this. There are enough problems already with: * substantial violations of Common Lisp semantics (e.g. implicit standard typing of DEFUN, which I still haven't gotten around to fixing, argh!) * various brokenness in the debugger * various compiler bugs * remaining serious performance problems (e.g. floating point consing, no DYNAMIC-EXTENT, and mediocre GC performance) My first priority for SBCL is, roughly, to be a good, solid environment for doing stuff a la Graham's _ANSI Common Lisp_ or Norvig's _Paradigms of Artificial Intelligence Programming_. Anything good which doesn't much interfere with that priority (like including someone's X11 support as a library) is good. Anything else, however good, which I perceive to interfere with that priority, is not very interesting to me right now. -- 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: Peter V. E. <pva...@de...> - 2000-09-11 19:24:51
|
> I still think this is more appropriate as a library, rather than > something which is built into the system. I'd like to bring > the core system size down, rather than up, not just for limitations > of system RAM, but because large systems tend to be unmanageable. I agree with this. But the connection with the libraries should be pretty tight. Using the mk-defsystem and 'require' [1] we could bring the core size down. Having separate maintainers for the libraries, but including them in the distribution (if they are sbcl specific, otherwise they should go in clocc or something similar). Most of the other issues raised are already solved in one way or another (MaiSQL, f2cl, McCLIM). I have some comments on: > * CORBA Humpf. I just left a CORBA-based project from h*ll. I think perhaps the technology is mature, and the lisp standard seems "nice", but the people using it (especially the C/C++ programmers) misuse the technology a lot. I won't work with people on CORBA unless they have at least once successful project behind them :-(. > * general UNIX support at the level of Perl Perl's big goodie is regexp/string manipulation. We can do even better, but we need a portable/fast implementation. > Some things are naturally part of the base system, not extra libraries, > because they're used to implement the base system: > * the foreign function interface > * RUN-PROGRAM * Basic OS interface. > Some relatively small extensions, which can't really be done as libraries, > are reasonable additions to the base system: > * weak pointers > * Gray streams * MOP * efficient MP. > My first priority for SBCL is, roughly, to be a good, solid > environment for doing stuff a la Graham's _ANSI Common Lisp_ or > Norvig's _Paradigms of Artificial Intelligence Programming_. Anything > good which doesn't much interfere with that priority (like including > someone's X11 support as a library) is good. Anything else, however > good, which I perceive to interfere with that priority, is not > very interesting to me right now. I am agreeing here, but don't downclass the sbcl-specific libraries to second-class code by asking people to hunt around for pieces here and there. Include it in the distribution and have hooks for mk-defsystem and require. Groetjes, Peter 1: Yes, require is depricated, but don't see it as a left-over from CLTL1, but as a utility macro from mk-defsystem that just finds and loads the required subsystem 'as by magic' :-). -- It's logic Jim, but not as we know it. | pva...@de... for pleasure, "God, root, what is difference?" - Pitr| "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/ |