Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?
From: Steffen Schulz on 24 Jan 2010 08:48

Thanks for the answers.

I was not aware of the several attempts to address this problem.


libcl certainly is the quick way to solve this. But it doesn't seem to
address the actual problem of dependency management, it is just replaced with a
central manually maintained repository. So it won't scale, although the idea of
having a stable distribution is nice.

xcvb looks interesting. Next step seems to be an installer similar to
asdf-install and corresponding infrastructure..


From: Tim Bradshaw on 24 Jan 2010 09:32
On 2010-01-24 13:18:59 +0000, Pascal J. Bourguignon said:

> 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.

Unfortunately "loading in sequence" turns out to be the problem: what
is the sequence?

From: Nicolas Neuss on 24 Jan 2010 10:16
Tamas K Papp <tkpapp(a)gmail.com> writes:

> 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.

Yes, but it is the easier problem, and it would be a good start, if at
least this point could be resolved in a way that one could expect every
implementation (also the commercial ones) to have one and the same
recommended "ASDF" available.

> 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.

Here one important task would be to standardize this Meta-information
such that I as a library author can use it. (At the same time pleading
guilty, because I did not yet make Femlisp asdf-installable.)

> 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.

Thank you,

Nicolas
From: Nicolas Neuss on 24 Jan 2010 10:48
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.

To elaborate here. In the last years I had difficulties in several
circumstances:

1. The Debian packages did not all work together. I think that it would
be important if the work for making this integration could be
distributed to more shoulders. Although Tamas is sceptical, I would
see the library authors here as the ones whose help is needed.

2. Debian did not integrate commercial Lisps nicely. Making something
like the Emacs/SLIME/common-lisp-controller combination together with
free CL librarires working independently of Debian could bring also a
net benefit for Lisp companies who might give support.

3. I wanted to port a web application to Clozure CL which was not
provided in Debian (at least not in my version of it). Putting
things together with asdf-install did not work painlessly. Obtaining
keys, etc, was a major hassle. And I needed also to introduce some
smaller patches.

I understand that this is all not easy. But having some sort of consent
on one method to formulate dependencies, together with an appeal/plead
to library authors to support this method could help a lot I think.

Nicolas

P.S.: One rather essential building-block would probably be a test suite
for libraries such that problems introduced by new versions of some
library could be easily detected. Is there something like that already?
Does common-lisp.net somehow check which libraries work together?
From: D Herring on 24 Jan 2010 13:58
Steffen Schulz wrote:
> libcl certainly is the quick way to solve this. But it doesn't seem to
> address the actual problem of dependency management, it is just replaced with a
> central manually maintained repository. So it won't scale, although the idea of
> having a stable distribution is nice.

It has been my experience that dependency management is overrated (the
reader may also consider that I prefer Slackware over Debian or
RedHat). If you have all the dependencies, then it is a non-issue.
Many dependency systems (e.g. apt or rpm) force upgrades, even when
they aren't really needed.

The bigger issue is that a dependency system can't detect or fix
incompatibilities. Note that the successful linux dependency systems
aren't fully automated. There is an integration team sitting behind
each one, deciding the hard problems like when to upgrade, when to
release, and how to resolve issues.

Yes, the current LibCL model will change as things scale, and it has a
higher scaling cost than systems like asdf-install. However, this
cost comes with a tradeoff; by their nature, more extensible systems
suffer from less integration testing. Also note that XCVB detects
when you need to recompile, but it doesn't handle where things come
from nor predict whether a recompile will work properly.

Not my best prose, but I think it gets the point across: dependency
tracking is a good tool for "to have X, get Y and Z" or "X changed, so
Y and Z may need to recompile"; it doesn't work too well for more
sophisticated issues. LibCL's current approach is to get everything
and recompile in tested releases.

First, people programmed by moving wires. Then by writing assembly,
later functions and libraries. IMO, today we're moving towards a
larger abstraction.

- Daniel
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: clisp on emacs+slime
Next: How to turn on multithreading capability in CLISP?