Prev: documentation generation libraries: which ones work?
Next: looking for the uber-utilities-library
From: Raffael Cavallaro on 20 Feb 2010 11:33
On 2010-02-20 10:36:57 -0500, Alberto Riva said:

> It would give the word APPLY a whole new meaning... ;)

Not to mention length, member, fill, union, do, and pop. (Be sure to
use the appropriate safety declaration or you might end up with a
serious-condition.)

Yes, many potential symbol conflicts, but after all, this is what
packages are for.
;^)
--
Raffael Cavallaro

From: D Herring on 20 Feb 2010 15:46
On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
> Raffael Cavallaro<raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com>
> writes:
>
>> libcl:<http://libcl.com/>
>
> This looks also very interesting. Can some user say more about it? How
> does it compare with clbuild?

ClBuild's design is lightweight on its maintainers. It basically
automates the download and install process, without attempting
integration testing, portability, code refactoring, etc.

LibCL is my attempt to build a (de-facto) "standard" set of libraries,
with tested releases, portability fixes, etc. This is a heavier
approach; for example, it requires keeping local repositories of
everything.

IMO, LibCL is better tested and easier to install, but clbuild has
more packages available and is always "up to date". Based on download
server logs, I'd guess 200 people have tried LibCL; based on blog
posts and the like, I'd guess more people use clbuild.

- Daniel
From: Nicolas Neuss on 21 Feb 2010 09:04
D Herring <dherring(a)at.tentpost.dot.com> writes:

> On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
>> Raffael Cavallaro<raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com>
>> writes:
>>
>>> libcl:<http://libcl.com/>
>>
>> This looks also very interesting. Can some user say more about it? How
>> does it compare with clbuild?
>
> ClBuild's design is lightweight on its maintainers. It basically
> automates the download and install process, without attempting
> integration testing, portability, code refactoring, etc.
>
> LibCL is my attempt to build a (de-facto) "standard" set of libraries,
> with tested releases, portability fixes, etc. This is a heavier
> approach; for example, it requires keeping local repositories of
> everything.

But this is precisely where I do not understand why you do not work
together. More precisely, couldn't you apply your tests (portability,
etc) to some snapshot of a subset of clbuild libraries which then could
get simply a blessing as being tested and portable? (Ideally, clbuild
should probably be extended to allow a more flexible download of tested
library versions instead of only the most current version.)

Also, when I looked in the clbuild mailing list I found the following
post:
http://common-lisp.net/pipermail/clbuild-devel/2010-January/000476.html
It is from Peter Van Eynde, one of the Debian clc authors (IIUC), who
asks for collaboration. Strangely, he didn't receive an answer,
although IMO it would be quite some saved work if clbuild, libcl, clc
people would somehow build on each others work.

Who is clbuild maintainer now?

> IMO, LibCL is better tested and easier to install, but clbuild has more
> packages available and is always "up to date".

As much as I have seen, LibCL lacks some libraries like Hunchentoot and
CLSQL which would be quite important for many users. OTOH, I have found
the "up-to-date"-ness of clbuild also a problem: when I tried it, there
was an incompatibility between clsql-postgresql and uffi-compat.

Nicolas

> Based on download server logs, I'd guess 200 people have tried LibCL;
> based on blog posts and the like, I'd guess more people use clbuild.
>
> - Daniel
From: D Herring on 21 Feb 2010 14:19
On 02/21/2010 09:04 AM, Nicolas Neuss wrote:
> D Herring<dherring(a)at.tentpost.dot.com> writes:
>
>> On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
>>> Raffael Cavallaro<raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com>
>>> writes:
>>>
>>>> libcl:<http://libcl.com/>
>>>
>>> This looks also very interesting. Can some user say more about it? How
>>> does it compare with clbuild?
>>
>> ClBuild's design is lightweight on its maintainers. It basically
>> automates the download and install process, without attempting
>> integration testing, portability, code refactoring, etc.
>>
>> LibCL is my attempt to build a (de-facto) "standard" set of libraries,
>> with tested releases, portability fixes, etc. This is a heavier
>> approach; for example, it requires keeping local repositories of
>> everything.
>
> But this is precisely where I do not understand why you do not work
> together. More precisely, couldn't you apply your tests (portability,
> etc) to some snapshot of a subset of clbuild libraries which then could
> get simply a blessing as being tested and portable? (Ideally, clbuild
> should probably be extended to allow a more flexible download of tested
> library versions instead of only the most current version.)

:) Life usually has wrinkles that hide until we trip on them.

Here are a couple reasons why LibCL couldn't be layered on top of the
systems existing when it was started.
- The need to stage a set of all libraries, each at a specific
revision, disqualified ASDF-install, etc. [*]
- The need for portability disqualified clc, **box, FFI libs, etc.
- The need to commit patches when upstream is offline or that don't
belong upstream disqualified everything -- nobody else was maintaining
mirrors in a single version-control format.
- The need to isolate end users from N version-control systems
disqualified many. [*]
- A desire to establish a group of "trusted" developers who can freely
maintain any of the libraries.

In principle, the [*] items may be fixable by layering on top of other
systems. However, this requires keeping local mirrors of the other
system's packages, and we still need local git repos. In the end, it
looked (and still does) like less work to simply cut out the middleman
and go straight to the source project.

This lead to the current LibCL design:
- git repos providing a "pure" mirror of upstream, regardless of
revision system
- git repos holding the local version of each upstream, may be edited
- git repos holding tools to stage releases

Desire (which started after LibCL) has progressed in the meantime; I
need to look into leveraging it again. It has some infrastructure
which I might be able to use for mirroring repos. That said, simply
getting a git version of upstream is much easier than accurately
mirroring all of it.


> Also, when I looked in the clbuild mailing list I found the following
> post:
> http://common-lisp.net/pipermail/clbuild-devel/2010-January/000476.html
> It is from Peter Van Eynde, one of the Debian clc authors (IIUC), who
> asks for collaboration. Strangely, he didn't receive an answer,
> although IMO it would be quite some saved work if clbuild, libcl, clc
> people would somehow build on each others work.

Each of these projects is optimizing for a different set of
parameters. Thus we are making different design decisions. At the
moment, LibCL is on a significantly different track.


>> IMO, LibCL is better tested and easier to install, but clbuild has more
>> packages available and is always "up to date".
>
> As much as I have seen, LibCL lacks some libraries like Hunchentoot and
> CLSQL which would be quite important for many users. OTOH, I have found
> the "up-to-date"-ness of clbuild also a problem: when I tried it, there
> was an incompatibility between clsql-postgresql and uffi-compat.

LibCL may never have some of these libraries. It didn't take long to
realize that FFI bindings increase portability issues by an order of
magnitude. I know how to fix this, but haven't had time to finish the
easy stuff (pure-CL) yet, and few people want to go down the path
required for proper FFI portability. I'm currently more interested in
improving documentation and refactoring some libraries than in adding
the infrastructure for FFI libs.

Later,
Daniel
First  |  Prev  | 
Pages: 1 2
Prev: documentation generation libraries: which ones work?
Next: looking for the uber-utilities-library