From: Paul K. <pv...@pv...> - 2009-12-17 23:29:58
|
The topic of a more fully-featured (binary) distribution was brought up on Tuesday at SBCL10. - Yes? No? - What should go there? - What solution do we suggest to distros? - Do we fork these, or do we always redirect requests, patches, etc. upstream, even if we can produce our own? - License restrictions? Paul Khuong |
From: Samium G. <_de...@fe...> - 2009-12-17 23:40:17
|
From: Paul Khuong <pv...@pv...> > The topic of a more fully-featured (binary) distribution was brought up on Tuesday at SBCL10. I realise that it's quite possible that everybody "who matters" attended SBCL10, but, do you think it'd be beneficial if somebody provided a summary on this? > - Yes? No? > > - What should go there? > > - What solution do we suggest to distros? > > - Do we fork these, or do we always redirect requests, patches, etc. upstream, even if we can produce our own? > > - License restrictions? > > Paul Khuong regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org |
From: Paul K. <pv...@pv...> - 2009-12-18 00:01:08
|
On 2009-12-17, at 11:45 PM, Samium Gromoff wrote: > From: Paul Khuong <pv...@pv...> >> The topic of a more fully-featured (binary) distribution was brought up on Tuesday at SBCL10. > > I realise that it's quite possible that everybody "who matters" attended SBCL10, > but, do you think it'd be beneficial if somebody provided a summary on this? The original message probably lacked some context. Do we want an alternative release with third-party libraries included, and if so, which ones? Paul Khuong |
From: Samium G. <_de...@fe...> - 2009-12-18 00:07:24
|
From: Paul Khuong <pv...@pv...> > On 2009-12-17, at 11:45 PM, Samium Gromoff wrote: >> From: Paul Khuong <pv...@pv...> >>> The topic of a more fully-featured (binary) distribution was brought up on Tuesday at SBCL10. >> >> I realise that it's quite possible that everybody "who matters" attended SBCL10, >> but, do you think it'd be beneficial if somebody provided a summary on this? > > The original message probably lacked some context. Do we want an alternative release with third-party libraries included, and if so, which ones? If we do, an obvious candidate is libcl, courtesy of Daniel Herring: http://libcl.com/ Which have following distinguishing properties: > LibCL Difference > > * Simple install -- download a single file per release > * Integration -- libraries are tested to work with each other > * Community building -- aiming for shared licensing and ownership of packages > * Platform neutrality -- the libraries should be portable across implementations and OSs > * Accountability -- public read-only git repositories track full history regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org |
From: Nikodemus S. <nik...@ra...> - 2009-12-18 08:49:15
|
2009/12/18 Samium Gromoff <_de...@fe...>: >>> I realise that it's quite possible that everybody "who matters" attended SBCL10, >>> but, do you think it'd be beneficial if somebody provided a summary on this? >> >> The original message probably lacked some context. Do we want an alternative release >> with third-party libraries included, and if so, which ones? > > If we do, an obvious candidate is libcl, courtesy of Daniel Herring: This is going to be a tricky discussion, because we have a reasonable start of a discussion from SBCL10, but anyone who wasn't there is going to get "we already talked about that" thrown in their face a fair bit. What follows is what I think, informed by what we talked about so far -- but it's not something anyone else necessarily agrees with. That said, I think it does summarize several of the points made at SBCL10. What? Kind-of like libcl, but not quite * SBCL specific libraries fine, encouraged in fact. (But things like CFFI are fine too, of course.) * Include libraries based on the directions of the library maintainers: ask maintainers of each library (1) are they OK with the bundling (2) which version should we bundle and how often should we update (3) how do they want bugreports handled? * License: libcl doesn't guarantee MIT/BSD compatibility right now, and I think we want that? * Contents: I don't actually have any major gripes with libcl contents, except I'm pretty sure we don't want to bundle quite so much at least to start with. Basically, unless the upstream author is actively following our bugreports to pick ones that deal with their library I would hope that at least one SBCL developer is familiar with the library before we include it. Otherwise we can't make an informed selection and users asking for help are not going to get any. * Documentation: while SBCL is not a poster child for documentation by any means, I don't think we should include utterly undocumented things. Since HTML is the common nominator these days we may want to consider making HTML the main documentation format for SBCL as well and link the library docs into main SBCL docs. (Rudi?) [ While from our users perspective the difference between libcl and SBCL extras may be minimal, I think from our perspective there are several points where goals and constraints diverge somewhat. ] How? * Think about how things like Linux distros should package this. James Knight (IIRC) suggested that mostly the right thing might be unbundling into several packages and making SBCL recommend them (in the apt-sense of the word.) * Make sure we don't annoy users or upstream hackers. I _must_ be easy to get either the bundled version or the alternative locally hacked version. * Doesn't really matter if it is a separate extras/ directory in the repo, or a separate repo entirely. Doesn't really matter (to me at least) if it is a single download or some on-demand thing. * I would be nice if APROPOS (or equivalent) knew about the contents of these libraries, so that people could figure which library to look at using an interactive tool instead of a webpage. Why? * Abuse our market position to give a boost to things we think are worth it. * People new to lisp don't have any reasonable way to conclude that CXML is probably what they want for XML processing, and similarly for any number of tasks. People _old_ to lisp can also fail at this spectacularly just because the world is large and no-one can keep up with it all. While this means that neither can we, we can at least let our users know about the bits of the world we do keep up with. There was other stuff in there as well, but I think this covers it mostly. In the abstract, we want an infrastructure we can put stuff into, and a process for putting stuff in there. :) Cheers, -- Nikodemus |
From: Brian M. <br...@ma...> - 2009-12-18 16:33:04
|
On Dec 18, 2009, at 2:48 AM, Nikodemus Siivola wrote: > This is going to be a tricky discussion, because we have a reasonable > start of a discussion from SBCL10, but anyone who wasn't there is > going to get "we already talked about that" thrown in their face a > fair bit. > *snip a bunch of discussion notes* I wish I had been able to attend SBCL10! It sounds like there were some very productive and interesting discussions. The one point that struck me in the list of reasons you included was: > * Abuse our market position to give a boost to things we think are worth it. I think whole enterprise is a good idea if-and-only-if there's a clear definition of "worth it" that lines up nicely with a vague notion of "the SBCL way". I think the licensing aspects of this have already been covered, but I think there are some technical issues that it would be nice to have a clear policy on as well: * Should software in the batteries-included distribution play nicely with both threaded and unthreaded SBCL? I'd argue strongly for "yes", and in particular such software should be able to use FD-HANDLERs wherever possible, even on a threaded SBCL. If you're making 1000 HTTP client requests, you don't want to have to use 1000 threads, nor should you be forced to serialize the requests where it doesn't make sense. Encouraging software to play nicely with FD-HANDLERs and SERVE-EVENT is a boon for both threaded and unthreaded SBCL users. There's probably work that should be done in SBCL in this area too. On the other side of the coin, should libraries be expected to be threadsafe - or at least document their level of thread safety? * Should software in the batteries-included distribution use SBCL-supplied character set encoders and decoders or third party libraries? It's difficult to piece together a complete program if you can't use the same character sets (or possibly even the same *designators* for the character sets) across libraries. * Should there be any guarantees of forward version compatibility? * Probably other issues that I'm missing right now... -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Nathan F. <fr...@gm...> - 2009-12-18 17:04:56
|
On Fri, Dec 18, 2009 at 11:32 AM, Brian Mastenbrook <br...@ma...> wrote: > I wish I had been able to attend SBCL10! It sounds like there were some very productive and interesting discussions. Ditto! > * Should software in the batteries-included distribution play nicely with both threaded and unthreaded SBCL? I'd argue strongly for "yes", and in particular such software should be able to use FD-HANDLERs wherever possible, even on a threaded SBCL. If you're making 1000 HTTP client requests, you don't want to have to use 1000 threads, nor should you be forced to serialize the requests where it doesn't make sense. Encouraging software to play nicely with FD-HANDLERs and SERVE-EVENT is a boon for both threaded and unthreaded SBCL users. There's probably work that should be done in SBCL in this area too. On the other side of the coin, should libraries be expected to be threadsafe - or at least document their level of thread safety? Yes, please, compatibility with both threaded/non-threaded. If you choose compatibility only with threaded, then you have just locked out Win32 users. We should get a better SERVE-EVENT story together (I didn't notice a lot of discussion on fu-streams on the whiteboard :) ). What did you have in mind for playing nicely with FD-HANDLERs? Do you mean that things should fall back on FD-HANDLERS if threads aren't available? Reasonable thread-safety would be nice, though I think that's more a upstream maintenance issue. > * Should software in the batteries-included distribution use SBCL-supplied character set encoders and decoders or third party libraries? It's difficult to piece together a complete program if you can't use the same character sets (or possibly even the same *designators* for the character sets) across libraries. I guess this calls for TRIVIAL-ENCODINGS, though I dislike wrappers for such things. (This would probably just do appropriate mappings between encoding designators, if such a thing is reasonable/possible.) Just to clarify what you want to do--this is what I am interpreting your suggestion as: Let's say there's a package deemed worthy called FOO. FOO uses Babel/Flexistreams/TRIVIAL-UTF8/whatever--something not SBCL. Do you want to modify FOO => SB-FOO (for this "batteries included" package only) that uses SBCL-supplied encodings/designators instead of Babel/Flexistreams/TRIVIAL-UTF8/watever? This modification means that SB-FOO is possibly source-incompatible with FOO and leads to bloat if some other package BAR requires FOO. Am I misinterpreting your suggestion? (I probably am.) > * Should there be any guarantees of forward version compatibility? I think responsibility is on the upstream authors to do this. I think we could make some guarantees about forward-version compatibility, but only if the connections between SBCL and the batteries were somewhat closer than it sounds like is being proposed. -Nathan |
From: Brian M. <br...@ma...> - 2009-12-18 18:57:48
|
On Dec 18, 2009, at 11:04 AM, Nathan Froyd wrote: > Yes, please, compatibility with both threaded/non-threaded. If you > choose compatibility only with threaded, then you have just locked out > Win32 users. > > We should get a better SERVE-EVENT story together (I didn't notice a > lot of discussion on fu-streams on the whiteboard :) ). What did you > have in mind for playing nicely with FD-HANDLERs? Do you mean that > things should fall back on FD-HANDLERS if threads aren't available? Yes, but in a (perhaps controversial) way: the library should use FD-HANDLERs in a way that makes it possible to multiplex different requests not only from the library but with other applications too. Unfortunately this tends to lead to the road to Inversion of Control City (it's right next to the resort town of Continuation Passing Style). > Reasonable thread-safety would be nice, though I think that's more a > upstream maintenance issue. > >> * Should software in the batteries-included distribution use SBCL-supplied character set encoders and decoders or third party libraries? It's difficult to piece together a complete program if you can't use the same character sets (or possibly even the same *designators* for the character sets) across libraries. > > I guess this calls for TRIVIAL-ENCODINGS, though I dislike wrappers > for such things. (This would probably just do appropriate mappings > between encoding designators, if such a thing is reasonable/possible.) > > Just to clarify what you want to do--this is what I am interpreting > your suggestion as: Let's say there's a package deemed worthy called > FOO. FOO uses Babel/Flexistreams/TRIVIAL-UTF8/whatever--something not > SBCL. Do you want to modify FOO => SB-FOO (for this "batteries > included" package only) that uses SBCL-supplied encodings/designators > instead of Babel/Flexistreams/TRIVIAL-UTF8/watever? This modification > means that SB-FOO is possibly source-incompatible with FOO and leads > to bloat if some other package BAR requires FOO. > > Am I misinterpreting your suggestion? (I probably am.) It wasn't necessarily a suggestion, just a challenge. But at a minimum it'd be nice if any batteries-included libraries could use the set of encodings that SBCL provides, if said encodings are not otherwise provided by something like Babel or Flexistreams. You're probably right that this calls for an encoding wrapper of some kind - or a pluggable interface from SBCL. -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Nikodemus S. <nik...@ra...> - 2009-12-18 20:18:45
|
2009/12/18 Brian Mastenbrook <br...@ma...>: > Yes, but in a (perhaps controversial) way: the library should use FD-HANDLERs in a way > that makes it possible to multiplex different requests not only from the library but with > other applications too. Unfortunately this tends to lead to the road to Inversion of I think we're entering speculative realms here. I suggest we revisit the issue of libraries using FD-HANDLERs when we get to the point of talking about a specific library that uses FD-HANDLERs -- the thing is, I suspect there is not one-size-fits-all here. > It wasn't necessarily a suggestion, just a challenge. But at a minimum it'd be nice if > any batteries-included libraries could use the set of encodings that SBCL provides, if > said encodings are not otherwise provided by something like Babel or Flexistreams. I *think* you're saying that while you'd prefer libraries to use "native" external formats, you're ok with those using Babel &co? Is this correct? Cheers, -- Nikodemus |
From: Faré <fa...@gm...> - 2009-12-18 21:06:03
|
For a batteries-included SBCL, why not have 1- a non-SBCL-specific library distribution mechanism, e.g. desire - or even Nix 2- as part of said non-SBCL-specific mechanism, a way to tag together a set of of versions of a subset of the above libraries 3- a non-SBCL-specific co-release of sets of such CL software, e.g. LibCL 4- as part of the SBCL release cycle, build big tarballs of the latest combo of SBCL and libraries that pass all the required tests. By factoring it this way, we may both minimize the pains for SBCL implementers and make things usable for CLers at large. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Due to circumstances beyond your control, you are master of your fate and captain of your soul. |
From: James Y K. <fo...@fu...> - 2009-12-18 21:19:28
|
On Dec 18, 2009, at 1:57 PM, Brian Mastenbrook wrote: > It wasn't necessarily a suggestion, just a challenge. But at a minimum it'd be nice if any batteries-included libraries could use the set of encodings that SBCL provides, if said encodings are not otherwise provided by something like Babel or Flexistreams. You're probably right that this calls for an encoding wrapper of some kind - or a pluggable interface from SBCL. This reminds me of something I wanted to say.... A lot of functionality in portable libraries already exists in SBCL under a different name, either internally-used or exported. So I'd consider seriously the question: will you throw out the SBCL implementation in favor of the other library? If not, does that indicate that said library isn't as good as the SBCL implementation? And if it's not good enough for you, that probably means you shouldn't recommend it to poor naive users, either. :) But, on the other hand, if it is good enough, kill the SBCL-internal implementation and both ship with and *use* the library in implementing SBCL. Reduce the code bloat and API duplication. In some cases, it might make sense to export the SBCL-specific implementation under the package/API the portable library uses, rather than actually including the portable library. That should be a serious consideration. There's of course some coordination issues there with the potential for API skew, but for mature libraries that shouldn't be a big issue. For me, the biggest value that could come from this push would be if all the random plumbing libraries were made redundant. Installing my own HTTP client library isn't a big deal when that's a thing I want. The problem is when I need to install and use and possibly even understand 5 other portability APIs, too. There's libraries for threads, sockets, streams, sane io, and a bunch of collections of just random useful utility functions. And all of that is mostly just cruft: every implementation already has them. So now I need to both understand my implementation's native API, and also the (sometimes with missing features) wrapper around it. Not a good place to be. Reducing that cruft into a sane system is probably going to be tricky, politically and perhaps technically. But once it's done, it becomes possible to directly pull in things like HTTP clients, without needing to also pull in wrappers or reimplementations of half of SBCL while you're at it...That'd be really neat. I don't want 5 different sockets libraries distributed with SBCL: I want just one. That *everything* uses. I don't want 5 different random utilities libraries containing partially overlapping sets of 10-line functions that should be in Common-Lisp to begin with: I want *one*. James |
From: Tobias C. R. <tc...@fr...> - 2009-12-19 09:21:46
|
James Y Knight <fo...@fu...> writes: > On Dec 18, 2009, at 1:57 PM, Brian Mastenbrook wrote: >> It wasn't necessarily a suggestion, just a challenge. But at a >> minimum it'd be nice if any batteries-included libraries could use >> the set of encodings that SBCL provides, if said encodings are not >> otherwise provided by something like Babel or Flexistreams. You're >> probably right that this calls for an encoding wrapper of some kind >> - or a pluggable interface from SBCL. > > This reminds me of something I wanted to say.... > > A lot of functionality in portable libraries already exists in SBCL > under a different name, either internally-used or exported. > > So I'd consider seriously the question: will you throw out the SBCL > implementation in favor of the other library? > > If not, does that indicate that said library isn't as good as the SBCL > implementation? And if it's not good enough for you, that probably > means you shouldn't recommend it to poor naive users, either. :) > > But, on the other hand, if it is good enough, kill the SBCL-internal > implementation and both ship with and *use* the library in > implementing SBCL. Reduce the code bloat and API duplication. In my experience, the libraries often trump the sbcl-internals because sbcl-internals were written ad-hoc for something that came up once or twice in past (then slightly extended again ad-hoc for a new task that came up and so on), whereas libraries were designed to be a solution for some kind of problem, and hence try to solve it well because someone focused on just that problem. > For me, the biggest value that could come from this push would be if > all the random plumbing libraries were made redundant. Installing my > own HTTP client library isn't a big deal when that's a thing I > want. The problem is when I need to install and use and possibly even > understand 5 other portability APIs, too. There's libraries for > threads, sockets, streams, sane io, and a bunch of collections of just > random useful utility functions. And all of that is mostly just cruft: > every implementation already has them. So now I need to both > understand my implementation's native API, and also the (sometimes > with missing features) wrapper around it. Not a good place to be. > > Reducing that cruft into a sane system is probably going to be tricky, > politically and perhaps technically. But once it's done, it becomes > possible to directly pull in things like HTTP clients, without needing > to also pull in wrappers or reimplementations of half of SBCL while > you're at it...That'd be really neat. I don't want 5 different sockets > libraries distributed with SBCL: I want just one. That *everything* > uses. I don't want 5 different random utilities libraries containing > partially overlapping sets of 10-line functions that should be in > Common-Lisp to begin with: I want *one*. How can SBCL change that? Become the de-facto implementation? Why should projects move away from portability layers? -T. |
From: Robert G. <rpg...@si...> - 2009-12-19 19:24:38
|
Tobias C. Rittweiler wrote: > James Y Knight <fo...@fu...> writes: > >> On Dec 18, 2009, at 1:57 PM, Brian Mastenbrook wrote: >>> It wasn't necessarily a suggestion, just a challenge. But at a >>> minimum it'd be nice if any batteries-included libraries could use >>> the set of encodings that SBCL provides, if said encodings are not >>> otherwise provided by something like Babel or Flexistreams. You're >>> probably right that this calls for an encoding wrapper of some kind >>> - or a pluggable interface from SBCL. >> This reminds me of something I wanted to say.... >> >> A lot of functionality in portable libraries already exists in SBCL >> under a different name, either internally-used or exported. >> >> So I'd consider seriously the question: will you throw out the SBCL >> implementation in favor of the other library? >> >> If not, does that indicate that said library isn't as good as the SBCL >> implementation? And if it's not good enough for you, that probably >> means you shouldn't recommend it to poor naive users, either. :) >> >> But, on the other hand, if it is good enough, kill the SBCL-internal >> implementation and both ship with and *use* the library in >> implementing SBCL. Reduce the code bloat and API duplication. > > In my experience, the libraries often trump the sbcl-internals because > sbcl-internals were written ad-hoc for something that came up once or > twice in past (then slightly extended again ad-hoc for a new task that > came up and so on), whereas libraries were designed to be a solution for > some kind of problem, and hence try to solve it well because someone > focused on just that problem. My subjective impression is also that SBCL internals provide very low level functionality, appropriate foundations for building higher-level abstractions in portable libraries. I am not familiar enough with the process of SBCL development to know if this is an articulated design philosophy. As someone who still develops primarily on ACL, but likes to be able to deliver code that will work with SBCL, I favor the portable library solution to this question! Best, R |
From: Robert G. <rpg...@si...> - 2009-12-18 17:25:35
|
Nikodemus Siivola wrote: > 2009/12/18 Samium Gromoff <_de...@fe...>: > > * Documentation: while SBCL is not a poster child for documentation by > any means, I don't think we should include utterly undocumented > things. Since HTML is the common nominator these days we may want to > consider making HTML the main documentation format for SBCL as well > and link the library docs into main SBCL docs. (Rudi?) I'm inclined to suggest that while HTML is good, there should be "bonus points" for texinfo. texinfo gives HTML /and/ info, which is handier for emacs users. Also texinfo gives a standard look and feel when rendered into HTML, and provides a solution to the indexing problem. I'm just saying this because, if you have the bully pulpit of libcl, it would be great to encourage people to use texinfo instead of raw HTML. But use of HTML instead of texinfo should not, of course, be an obstacle to inclusion. best, r |
From: James Y K. <fo...@fu...> - 2009-12-19 16:31:13
|
On Dec 19, 2009, at 3:40 AM, Tobias C. Rittweiler wrote: >> I don't want 5 different sockets >> libraries distributed with SBCL: I want just one. That *everything* >> uses. > > How can SBCL change that? Become the de-facto implementation? One option is for SBCL's API for <x> to be the "best" one that everyone uses and that a portability layer duplicates for other impls that haven't seen the light yet. :) The other alternative is for SBCL to provide the already existing "best" portable API instead of its own internal one. (potentially with implementation-specific extensions). James |
From: Martin C. <cra...@co...> - 2009-12-20 18:43:10
|
James Y Knight wrote on Sat, Dec 19, 2009 at 11:30:57AM -0500: > On Dec 19, 2009, at 3:40 AM, Tobias C. Rittweiler wrote: > >> I don't want 5 different sockets > >> libraries distributed with SBCL: I want just one. That *everything* > >> uses. > > > > How can SBCL change that? Become the de-facto implementation? > > One option is for SBCL's API for <x> to be the "best" one that > everyone uses and that a portability layer duplicates for other impls > that haven't seen the light yet. :) > > The other alternative is for SBCL to provide the already existing > "best" portable API instead of its own internal one. (potentially with > implementation-specific extensions). Benchmarks also help. In the case of Lisp libraries you usually have most libraries damage performance severely, either by consing, using CLOS (shudder), additional indirections etc. If you back up your choices with benchmarks to illuminate this aspect they suddenly become much less attached to particular toy libs. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: Rudi S. <ru...@co...> - 2009-12-18 15:30:56
|
Some random remarks thrown in below. On 18.12.2009, at 09:48, Nikodemus Siivola wrote: [...] > What? > > Kind-of like libcl, but not quite > > * SBCL specific libraries fine, encouraged in fact. (But things like > CFFI are fine too, of course.) How do we handle libraries that have sbcl-specific and other-implementation-specific bits in them? I would propose using the upstream versions unchanged if at all possible; there's much to be learned from other people's mistakes in this area. :) > > * Include libraries based on the directions of the library > maintainers: ask maintainers of each library (1) are they OK with the > bundling (2) which version should we bundle and how often should we > update (3) how do they want bugreports handled? This is good for all kinds of reasons, not least common courtesy. > * Contents: I don't actually have any major gripes with libcl > contents, except I'm pretty sure we don't want to bundle quite so much > at least to start with. Basically, unless the upstream author is > actively following our bugreports to pick ones that deal with their > library I would hope that at least one SBCL developer is familiar with > the library before we include it. Otherwise we can't make an informed > selection and users asking for help are not going to get any. For the beginning, we could try to choose libraries that implement features nowadays expected from a language (regexen, http client support, _perhaps_ database access) -- basically the stuff that enables CL to be used as a glue language for the data sources that have appeared since 1994. > * Documentation: while SBCL is not a poster child for documentation by > any means, I don't think we should include utterly undocumented > things. Since HTML is the common nominator these days we may want to > consider making HTML the main documentation format for SBCL as well > and link the library docs into main SBCL docs. (Rudi?) I think they can be handled like the asdf docs that we already include - a html file in the same place as the main sbcl documentation. Once we have 3 or 4 pieces of documentation, we can add an index.html file linking to sbcl, asdf and the libraries; this can be hand-edited since I don't expect monthly changes in the libraries we include. > * Make sure we don't annoy users or upstream hackers. I _must_ be easy > to get either the bundled version or the alternative locally hacked > version. The role model for that could be emacs; using upstream versions of some included package is just a matter of sticking its directory on the front of `load-path'. If it's as easy as that, we're fine I think. > * Doesn't really matter if it is a separate extras/ directory in the > repo, or a separate repo entirely. Doesn't really matter (to me at > least) if it is a single download or some on-demand thing. ... or even the default sbcl tarball, with an extra `sbcl-minimal' archive containing only sbcl and the current contribs. [...] Cheers, Rudi |
From: Nikodemus S. <nik...@ra...> - 2009-12-18 15:45:05
|
2009/12/18 Rudi Schlatte <ru...@co...>: >> * SBCL specific libraries fine, encouraged in fact. (But things like >> CFFI are fine too, of course.) > > How do we handle libraries that have sbcl-specific and other-implementation-specific bits > in them? I would propose using the upstream versions unchanged if at all possible; > there's much to be learned from other people's mistakes in this area. :) I definitely agree. > For the beginning, we could try to choose libraries that implement features nowadays > expected from a language (regexen, http client support, _perhaps_ database access) -- > basically the stuff that enables CL to be used as a glue language for the data sources > that have appeared since 1994. While I agree with the sentiment, I would rather look at library X and ask "do we want to include this?" rather than try to follow a checklist. It avoids the issue of what to do when there isn't an obvious good candidate for something desirable by approaching the question from the opposite direction. That is, not "What do we use for XML?" but "CXML is pretty neat. Should we bundle it so users have XML goodness out of the box?" > I think they can be handled like the asdf docs that we already include - a html file in & > The role model for that could be emacs; using upstream versions of some included package & > ... or even the default sbcl tarball, with an extra `sbcl-minimal' archive containing only All of these sound fine to me. Cheers, -- Nikodemus |
From: James Y K. <fo...@fu...> - 2009-12-18 21:35:37
|
On Dec 18, 2009, at 3:48 PM, James Y Knight wrote: > Reducing that cruft into a sane system is probably going to be tricky, politically and perhaps technically. But once it's done, it becomes possible to directly pull in things like HTTP clients, without needing to also pull in wrappers or reimplementations of half of SBCL while you're at it...That'd be really neat. I don't want 5 different sockets libraries distributed with SBCL: I want just one. That *everything* uses. I don't want 5 different random utilities libraries containing partially overlapping sets of 10-line functions that should be in Common-Lisp to begin with: I want *one*. Extra special Bonus Points if SBCL can team up with another open source implementation, like say CCL, and both do the same thing. Two CL implementations actually cooperating and coordinating would be such a surprising turn of events, it might just make people take notice. :) James |
From: Nathan F. <fr...@gm...> - 2009-12-18 21:56:23
|
On Fri, Dec 18, 2009 at 4:41 PM, Martin Cracauer <cra...@co...> wrote: > James Y Knight wrote on Fri, Dec 18, 2009 at 04:35:16PM -0500: >> Extra special Bonus Points if SBCL can team up with another open >> source implementation, like say CCL, and both do the same thing. Two >> CL implementations actually cooperating and coordinating would be such >> a surprising turn of events, it might just make people take notice. :) > > Just earlier today I thought that some Lisp implementations might want > to share a common cvs/git tree, with a common directory for this stuff > and separate ones for the base system. > > Keep in mind that code/ contains a lot of things that are 100% > implementation neutral. Just the loop macro alone is idiotic to > maintain in a dozens implementations. There might be a couple of > optimizations that are #+ed in but that's about it. That's an interesting idea. Modulo differences in VCS between implementations, it's so crazy it just might work. :) It might even eliminate differences in how free implementations interpret bits--CLISP had a different (wrong?) understanding of how bits of LOOP worked for a while. Also along the same vein: what if SBCL converted to git and used git submodules to handle this and the pulling of batteries-included libraries? That way, at build time, you'd get a sort of modern language distribution. If you wanted to, of course; there'd be switches to turn off batteries-included libraries. </crazy-idea> -Nathan |
From: Martin C. <cra...@co...> - 2009-12-18 22:06:48
|
Nathan Froyd wrote on Fri, Dec 18, 2009 at 04:56:12PM -0500: > On Fri, Dec 18, 2009 at 4:41 PM, Martin Cracauer <cra...@co...> wrote: > > James Y Knight wrote on Fri, Dec 18, 2009 at 04:35:16PM -0500: > >> Extra special Bonus Points if SBCL can team up with another open > >> source implementation, like say CCL, and both do the same thing. Two > >> CL implementations actually cooperating and coordinating would be such > >> a surprising turn of events, it might just make people take notice. :) > > > > Just earlier today I thought that some Lisp implementations might want > > to share a common cvs/git tree, with a common directory for this stuff > > and separate ones for the base system. > > > > Keep in mind that code/ contains a lot of things that are 100% > > implementation neutral. Just the loop macro alone is idiotic to > > maintain in a dozens implementations. There might be a couple of > > optimizations that are #+ed in but that's about it. > > That's an interesting idea. Modulo differences in VCS between > implementations, it's so crazy it just might work. :) It might even > eliminate differences in how free implementations interpret > bits--CLISP had a different (wrong?) understanding of how bits of LOOP > worked for a while. Right. You can argue that forcing different implementations to behave the same on ambiguity in the standard is a good thing anyway. CLISP and CMUCL once both lived at cons.org, I guess there's an opportunity lost there. > Also along the same vein: what if SBCL converted to git and used git > submodules to handle this and the pulling of batteries-included > libraries? That way, at build time, you'd get a sort of modern > language distribution. If you wanted to, of course; there'd be > switches to turn off batteries-included libraries. </crazy-idea> I think the bigger issue here is binary distributions. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: Samium G. <_de...@fe...> - 2009-12-18 22:10:29
|
From: Nathan Froyd <fr...@gm...> > On Fri, Dec 18, 2009 at 4:41 PM, Martin Cracauer <cra...@co...> wrote: >> James Y Knight wrote on Fri, Dec 18, 2009 at 04:35:16PM -0500: >>> Extra special Bonus Points if SBCL can team up with another open >>> source implementation, like say CCL, and both do the same thing. Two >>> CL implementations actually cooperating and coordinating would be such >>> a surprising turn of events, it might just make people take notice. :) >> >> Just earlier today I thought that some Lisp implementations might want >> to share a common cvs/git tree, with a common directory for this stuff >> and separate ones for the base system. >> >> Keep in mind that code/ contains a lot of things that are 100% >> implementation neutral. Just the loop macro alone is idiotic to >> maintain in a dozens implementations. There might be a couple of >> optimizations that are #+ed in but that's about it. > > That's an interesting idea. Modulo differences in VCS between > implementations, it's so crazy it just might work. :) It might even > eliminate differences in how free implementations interpret > bits--CLISP had a different (wrong?) understanding of how bits of LOOP > worked for a while. > > Also along the same vein: what if SBCL converted to git and used git > submodules to handle this and the pulling of batteries-included > libraries? That way, at build time, you'd get a sort of modern > language distribution. If you wanted to, of course; there'd be > switches to turn off batteries-included libraries. </crazy-idea> Both libcl and desire provide a process of conversion of library upstreams into git. Desire provides an API for doing that, and covers, at the present moment, about 180 of them. And don't forget the buildbot: http://feelingofgreen.ru/desire-waterfall [1] regards, Samium Gromoff -- 1. Might be offline once in a while, as I continue on my quest of rehashing things. _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org |
From: Nikodemus S. <nik...@ra...> - 2009-12-19 09:31:57
|
2009/12/19 Samium Gromoff <_de...@fe...>: >> That's an interesting idea. Modulo differences in VCS between >> implementations, it's so crazy it just might work. :) It might even >> eliminate differences in how free implementations interpret >> bits--CLISP had a different (wrong?) understanding of how bits of LOOP >> worked for a while. I don't particularly disagree, but obviously we'd need to talk to other implementations in order to figure out how to do this. :) Also, the question of ownership arises: I think Clisp interpreted things differently _knowingly_: either the shared code would be full of #+foo crap, or no-one would dare to touch it without getting an ack from all implementations. Not impossible, just tricky. ...and I think this is separate discussion from the batteries-included one. For those of you who've missed it, there now exists imp...@co..., where at least in theory this kind of thing could be talked about on neutral ground. Currently IIRC ABCL, Clisp, CMUCL, ECL, and SBCL are represented. > Both libcl and desire provide a process of conversion of library upstreams > into git. Desire provides an API for doing that, and covers, at the > present moment, about 180 of them. And don't forget the buildbot: In terms of technical solutions to *how* the batteries are included, I have no strong preferences. The optimal solution seems also to be largely affected by our choice of batteries: if we bundle 6 libraries and don't expect to add many the optimal choice if vastly different than if we bundle several dozen and expect to change the selection regularly. Cheers, -- Nikodemus |
From: Martin C. <cra...@co...> - 2009-12-18 21:42:15
|
James Y Knight wrote on Fri, Dec 18, 2009 at 04:35:16PM -0500: > > Extra special Bonus Points if SBCL can team up with another open > source implementation, like say CCL, and both do the same thing. Two > CL implementations actually cooperating and coordinating would be such > a surprising turn of events, it might just make people take notice. :) Just earlier today I thought that some Lisp implementations might want to share a common cvs/git tree, with a common directory for this stuff and separate ones for the base system. Keep in mind that code/ contains a lot of things that are 100% implementation neutral. Just the loop macro alone is idiotic to maintain in a dozens implementations. There might be a couple of optimizations that are #+ed in but that's about it. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: <dhe...@te...> - 2009-12-19 09:34:08
|
Nikodemus Siivola wrote: > 2009/12/18 Samium Gromoff <_de...@fe...>: >> If we do, an obvious candidate is libcl, courtesy of Daniel Herring: ... > Kind-of like libcl, but not quite > > * SBCL specific libraries fine, encouraged in fact. (But things like > CFFI are fine too, of course.) IMO, SBCL-specific libs should be included similarly to the current contribs. SVN remotes or git submodules could help with the versioning; or you could have an official directory for contrib tarballs to be staged for the next release. Most projects that bundle the work of others (e.g. BSD, Debian, RedHat, ...) develop a local patch and configuration system. It might be easier for SBCL to adopt the project hosting for all contribs. IMO, portable libraries should not appear in an SBCL-specific bundle. I will hold ASDF as an example of what happens when each implementation independently maintains a portable layer (others have mentioned LOOP; PCL/CLOS is another). Actions tend to reflect organizational structure; separate maintenance leads to divergence, and that's something avoid. One goal of LibCL is to encourage portable library development; there will be no overlap from my side. ;) > * Include libraries based on the directions of the library > maintainers: ask maintainers of each library (1) are they OK with the > bundling (2) which version should we bundle and how often should we > update (3) how do they want bugreports handled? 1) By releasing a project under an open-source license, you explicitly allow others to redistribute your work. 2) By bundling someone else's code, you get to choose which headaches to inherit. Its best to coordinate releases with the original authors; but there are many cases where one side will lag behind the other, and a friendly understanding is usually sufficient. Most authors are happy to see their work be promoted. 3) Best practice is something like the following. End-users report bugs to the packager; the packager triages these bugs and submits them upstream as appropriate, often with patches added. > * License: libcl doesn't guarantee MIT/BSD compatibility right now, > and I think we want that? Technically, its up to the end-user to pick which libraries they use... It is a stated goal of LibCL to get people moving towards a common license; but LibCL is dealing with other issues right now. > [ While from our users perspective the difference between libcl and > SBCL extras may be minimal, I think from our perspective there are > several points where goals and constraints diverge somewhat. ] And this is why I think both types of system server a purpose. LibCL is no nirvana -- feel free to build something better -- but we need some (implementation-independent) community to maintain portable libraries. > * Make sure we don't annoy users or upstream hackers. I _must_ be easy > to get either the bundled version or the alternative locally hacked > version. ASDF (and all other library systems I know of) make this easy. Simply change the order of the two versions in the search path. > * Doesn't really matter if it is a separate extras/ directory in the > repo, or a separate repo entirely. Doesn't really matter (to me at > least) if it is a single download or some on-demand thing. Most linux, bsd, latex, java, etc. distros encourage a large base download. Its just easier for all involved. Consider buying candy by the piece or by the bag. > * I would be nice if APROPOS (or equivalent) knew about the contents > of these libraries, so that people could figure which library to look > at using an interactive tool instead of a webpage. I've already talked to Alastair about the possibility of stripping debug info from fasls and optionally loading it later. This sounds like the reverse; load some debug info without the code... Later, Daniel |