Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?
From: D Herring on 23 Jan 2010 20:27
Steffen Schulz wrote:
....
> In the end, I have to resolve any dependencies by hand, visit the individual
> websites and keep track of their latest tarball, svn, cvs, darcs or git
> repository.
>
> Debian also ships quite a bit of cl packages, but of course they don't have all
> of them. I would end up with a mixture of current and older packages, which is
> at least as complicated as finding the most recent version of all of them.
>
> Did I miss something? Is there a hidden package server that you only tell your
> friends about? Do you all do the package management on your own?

This is a common issue with all languages; but CL's diverse nature
does aggravate the problem.

Here's my attempt at making life easier:
http://libcl.com

- Daniel
From: Nicolas Neuss on 24 Jan 2010 05:05
pjb(a)informatimago.com (Pascal J. Bourguignon) writes:

> You're right, the situation is a mess.
>
> There's asdf-install/cliki.net and asdf, but they have the drawbacks
> you noted (and some more).
>
> There are newer and different attempts, such as xcvb, cl-build, libcl,
> etc, but AFAIK, nothing is comprehensive and definitive.
>
> You might want to have a look at libcl, it's the approach I take for
> the dependencies of my own lisp application.
>
> But really, we were waiting for somebody like you, motivated to solve
> this mess with a great definite solution. Serriously.

I have the impression that for this really important issue it would
really be time that the maintainers of the different implementations,
system definition facilities and packaging systems should try to agree
on a common solution working under most CL implementations.

The best possible outcome would probably be a substandards document on
KMP's <http://substandards.org/> accompanied with a reasonable
CCLAN-like server.

Who could participate in a committee? Here a proposal: Whoever is
interested out of the following groups:

1. Implementors (Franz, Lispworks, SBCL, ECL, ...)

2. System definition facility maintainers (Dan Barlow, Fare Rideau,
Marco Antoniotti, ...)

3. Package system maintainers (Kevin Rosenberg, Dan Herring, Dan Barlow,
...)

Work involved would probably not be terribly large for the members of
the committee, but would be quite large for a single individual who
would act as chairman. Therefore it would be necessary to compensate
that person financially for this effort which might be done by
collecting money from all of us here interested in such an effort. I
personally think that I would pay around 200 EUR, probably even more, to
someone having the right qualification for doing such a job.

The following questions remain:

1. Who else would like to contribute financially to something like that?
Would there be sufficiently many contributions? I would really like
to know how much money one could expect here out of a community
effort.

2. Is there anyone with high reputation (i.e. who would be agreed on by
the committee) who would act as chairman of that committee, who would
write the standards document proposal and final document, and
possibly also implement a reference implementation (extracting parts
out of MK-DEFSYSTEM/ASDF/ASDF-INSTALL/etc, maybe adding some missing
parts like versioning)?

3. Further ideas? Opinions?

Nicolas
From: Tamas K Papp on 24 Jan 2010 05:35
On Sun, 24 Jan 2010 11:05:00 +0100, Nicolas Neuss wrote:

> pjb(a)informatimago.com (Pascal J. Bourguignon) writes:
>
>> You're right, the situation is a mess.
>>
>> There's asdf-install/cliki.net and asdf, but they have the drawbacks
>> you noted (and some more).
>>
>> There are newer and different attempts, such as xcvb, cl-build, libcl,
>> etc, but AFAIK, nothing is comprehensive and definitive.
>>
>> You might want to have a look at libcl, it's the approach I take for
>> the dependencies of my own lisp application.
>>
>> But really, we were waiting for somebody like you, motivated to solve
>> this mess with a great definite solution. Serriously.
>
> I have the impression that for this really important issue it would
> really be time that the maintainers of the different implementations,
> system definition facilities and packaging systems should try to agree
> on a common solution working under most CL implementations.
>
> The best possible outcome would probably be a substandards document on
> KMP's <http://substandards.org/> accompanied with a reasonable
> CCLAN-like server.
>
> Who could participate in a committee? Here a proposal: Whoever is
> interested out of the following groups:
>
> 1. Implementors (Franz, Lispworks, SBCL, ECL, ...)
>
> 2. System definition facility maintainers (Dan Barlow, Fare Rideau,
> Marco Antoniotti, ...)
>
> 3. Package system maintainers (Kevin Rosenberg, Dan Herring, Dan Barlow,
> ...)
>
> Work involved would probably not be terribly large for the members of
> the committee, but would be quite large for a single individual who
> would act as chairman. Therefore it would be necessary to compensate
> that person financially for this effort which might be done by
> collecting money from all of us here interested in such an effort. I
> personally think that I would pay around 200 EUR, probably even more, to
> someone having the right qualification for doing such a job.
>
> The following questions remain:
>
> 1. Who else would like to contribute financially to something like that?
> Would there be sufficiently many contributions? I would really like
> to know how much money one could expect here out of a community
> effort.
>
> 2. Is there anyone with high reputation (i.e. who would be agreed on by
> the committee) who would act as chairman of that committee, who would
> write the standards document proposal and final document, and
> possibly also implement a reference implementation (extracting parts
> out of MK-DEFSYSTEM/ASDF/ASDF-INSTALL/etc, maybe adding some missing
> parts like versioning)?
>
> 3. Further ideas? Opinions?

I am bit skeptical that this is going to work. The problem is a hard
one, and a good solution, if any, will most likely be the result of an
evolutionary process.

Don't forget that it is not only the development of such a framework
that requires effort---the integration of libraries into this system
requires a lot of continued dedication. Testing that your library
integrates well is not a trivial task.

I would settle for a system that would follow dependencies and make
sure that the correct version of libraries is on the hard disk. For
now, I would leave loading these libraries out of it: ASDF may or may
not be replaced in the near future, but maybe we can treat loading as
an orthogonal issue.

Libraries would include some meta-information, like a Debian package
(name, version, short description, and most importantly,
dependencies). The system would just make sure that it got
everything.

Many people use version control systems (eg git, svn, darcs). I don't
know about the others, but git can "tag" states of the repository (so
you can refer to something with 1.14.9a instead of 59f45c3245e...).

Even if people come up with an excellent system, it will not be
widespread unless it requires no more than a minimal effort from
library authors. Let's face it, many people write free software for
their own use, and fixing it for someone else is not always a
priority. So any solution would have to be automated, and only
require minimal intervention.

My 2 cents,

Tamas
From: Stelian Ionescu on 24 Jan 2010 06:51
On Sat, 23 Jan 2010 18:13:15 -0500, Raffael Cavallaro wrote:

> On 2010-01-23 10:19:57 -0500, Steffen Schulz said:
>
>> I'm pretty sure I stumbled on one of the reasons today, while trying to
>> deploy my work on a different machine: Much worse than the lack of
>> certain libraries and tools, I think, is the lack of a well-maintained
>> Lisp distribution.
>
> Don't confuse Common Lisp the language with whatever free implementation
> you're using. There are non-free implementations of common lisp that
> don't have these sorts of configuration issues - they more or less just
> work, which is a big part of what their users are paying for.

Such as ?

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
From: Pascal J. Bourguignon on 24 Jan 2010 08:18
Nicolas Neuss <lastname(a)math.uni-karlsruhe.de> writes:
> I have the impression that for this really important issue it would
> really be time that the maintainers of the different implementations,
> system definition facilities and packaging systems should try to agree
> on a common solution working under most CL implementations.

Well, I would argue the contrary: it is actually not an important issue.

What good is a system definition facility (basically, a "makefile")?
In what situation is it really useful?


When you program, the advice is to use emacs+slime and program
interactively and incrementally: you type a function in the editor
file, and C-x C-e to send it to the REPL so the image is updated.

Basically, the image is always up to date, and it's incrementally
updated. So there's no need here for a makefile equivalent.


When you start with a virgin image, then you will want to load all
your code: there is no point in finassing with the dependencies, just
loading in sequence all the needed files will do. So there's no need
here for a makefile equivalent.


Finally, when you gather libraries, you need indeed to identify the
other libraries they depend on (and it's nice to have here some formal
or at least homogenous lists of required libraries), but the problem
here is more of finding the right version (when you use library A
needing library C version C1, and library B needing library C version
C2, you will have fun whatever the kind of system definition
facility). The solution is to do that work once and for all
(ie. LibCL), but this may again reduce to a list of load expressions.


Remember, today, the minimal PC configuration buyable comes with 2.5
GHz dual core processors and with 3 GB of RAM, and a developer
computer will be more like a 3 GHz octo-core with 16 GB of RAM.
There's no point in trying to load or to compile only the "modified"
sources. Just reload everything (I mean, all the existing libraries),
or program incrementally.


--
__Pascal Bourguignon__ http://www.informatimago.com/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?