Hello again,

A while ago I ran across a large lisp library that consisted of upward
of 50 files.  It contained all kinds of utilities (one of them was
plotting) with the purpose of providing a common extended layer to cl.

Can someone please remind me of its name?

Thank you,

Mirko

Mirko wrote:
> It contained all kinds of utilities (one of them was
> plotting) with the purpose of providing a common extended layer to cl.


CLLIB / CLOCC perhaps?

On 2010-02-19 09:00:20 -0500, Mirko said:

> Hello again,
> 
> A while ago I ran across a large lisp library that consisted of upward
> of 50 files.  It contained all kinds of utilities (one of them was
> plotting) with the purpose of providing a common extended layer to cl.
> 
> Can someone please remind me of its name?

libcl:
<http://libcl.com/>

btw, its uber (�ber - german for over, beyond, hence superlative).

I think a luber library would be one that lets you interface common 
lisp to WD-40 or KY jelly. ;^)
-- 
Raffael Cavallaro

On Feb 19, 10:23=A0am, Raffael Cavallaro
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2010-02-19 09:00:20 -0500, Mirko said:
>
> > Hello again,
>
> > A while ago I ran across a large lisp library that consisted of upward
> > of 50 files. =A0It contained all kinds of utilities (one of them was
> > plotting) with the purpose of providing a common extended layer to cl.
>
> > Can someone please remind me of its name?
>
> libcl:
> <http://libcl.com/>
>
> btw, its uber (=FCber - german for over, beyond, hence superlative).
>
> I think a luber library would be one that lets you interface common
> lisp to WD-40 or KY jelly. ;^)
> --
> Raffael Cavallaro

libcl is it.  Thank you both.  And indeed, I misspelled the subject.
I did mean uber.

Mirko

Raffael Cavallaro <raffaelcavallaro@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?

Nicolas

Raffael Cavallaro wrote:
> 
> I think a luber library would be one that lets you interface common lisp 
> to WD-40 or KY jelly. ;^)

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

Alberto

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

On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
> Raffael Cavallaro<raffaelcavallaro@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

D Herring <dherring@at.tentpost.dot.com> writes:

> On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
>> Raffael Cavallaro<raffaelcavallaro@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

On 02/21/2010 09:04 AM, Nicolas Neuss wrote:
> D Herring<dherring@at.tentpost.dot.com>  writes:
>
>> On 02/19/2010 01:42 PM, Nicolas Neuss wrote:
>>> Raffael Cavallaro<raffaelcavallaro@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