Prev: RosettaCode
Next: can a make-instance method return a different class?
From: Tim X on 18 Feb 2010 17:50
Nicolas Neuss <firstname.lastname(a)kit.edu> writes:

> Hello,
>
> I use a combination of Hunchentoot, CLSQL and other Lisp software on
> several computers running Ubuntu and Debian. I also use several
> implementations: mostly SBCL, but from time to time also others (CCL,
> CMUCL, Lispworks,...)
>
> I recently have updated my to Hunchentoot 1.0 for two of my computers
> (two other computers that are running my web applications still work
> with Hunchentoot 0.15). However, I have run into several problems
> because I have now a strange mixture of libraries:
>
> 1. Some packages from Debian/Ubuntu
> 2. Some installed by asdf-install in .sbcl
> 3. Some installed by asdf-install in .asdf-install-dir
> 4. Some installed using asdf from a ~/CL-HOME directory
>
> I am now thinking about making a large restart by relying mostly on one
> of those methods, something like
>
> A. Try to use the bleeding edge of Debian and hope that libraries and CL
> implementations are sufficiently up-to-date
>
> Problems: integrating commercial Lisp implementations, relying on the
> Debian maintainer
>
> B. Download everything with asdf-install in .asdf-install-dir (for
> having it available with several CLs
>
> Problems: How to keep it up-to-date?
>
> C. Download everything needed in ~/CL-HOME without asdf-install (and
> -if possible- with CVS/SVN).
>
> Problems: more work, keeping it up-to-date and working with each
> other?
>
> D. ?
>
> I would be interested in how people reading this newsgroup and having
> similar needs have solved this problem.
>

Its non-trivial and I'm not sure there is a solution that will work for
everyone and everywhere.

For the case where you are using multiple lisp implementations, I think
the common-lisp-controller approach used by debian et. al. works pretty
well.

On the whole, I don't have too many issues with using a combination of
debian packaged libs and asdf installed ones, though I am tending to
move more and more towards just asdf to avoid some dependency issues
that can occur if your using a later version installed via asdf and a
deb packaged lib wants an earlier version or thinks you don't have it
installed at all etc.

I'm also a bit wary of the growing belief that you must be running the
latest version of all the libs you are using. I tend not to upgrade a
library until either I find a bug in the current version or the newer
version has a feature or improvement that is of real/actual (i.e. I'm
using it) benefit. Upgrading just so that your running the latest
version isn't necessarily a good thing - new versions can introduce new
bugs and if the new version doesn't have a real benefit to the way you
are using the lib, it just seems like work for the sake of work to me.

I don't think we will ever have a really universal standard approach to
this issue because we don't have a universal standard approach to
library extensions. I'm not convinced this is necessarily a real problem
as much as a perceived one arising from largely misguided comparisons
with other languages. Of course, everyones experiences are different,
but its probably because of this wide variation in individual experience
that we have not come up with a universally accepted approach. It is
possible that we cannot agree on how to do this because to some extent,
this conflicts with one of CLs strengths i.e. the freedom and
flexibility to solve things the way you want with minimal constraints
imposed by the language and/or some other individual/group who control
it.

I suspect an approach that is more likely to succeed is one in which
individual CL distributions bundle more and more additional libs as
standard extensions for that specific implementation. I realise some
will argue this is a really bad thing because it will reduce
portability, but I think the importance of implementation portability is
possibly a bit over stated and not as critical as platform portability.
Many people will develop a preference for a particular implementation
anyway and perhaps the types of extensions it offers will become
relevant in how they select their preferred option. I also suspect that
any extension added by one implementation that proves to be really
popular/desired will eventually be ported to another implementation
anyway.

In the meantime, I tend to deal with libs on a per application basis and
use a combination of asdf and the common -lisp-controller. When a
library is not asdf installable, I may create a .asdf file for it to
make it easier to manage locally or if I only want a couple of
functions and they are nicely encapsulated, I might just flat out steal
it and stick it in my local util lib

Tim

--
tcross (at) rapttech dot com dot au
From: Pascal J. Bourguignon on 18 Feb 2010 19:58
"Captain Obvious" <udodenko(a)users.sourceforge.net> writes:

> NN> I would be interested in how people reading this newsgroup and having
> NN> similar needs have solved this problem.
>
> Something like your C. There is a script update-systems.sh which finds all
> asd files and links them into a certain directory which is mentioned in
> asdf:*central-registry*. So installation process is very quick -- wget,
> unpack, run update-systems.sh, and that's all. If you want to temporarily
> try some different version, push its dir into asdf:*central-registry*

Well, I'm a lisp programmer therefore instead of writing a shell script
to symlink files, I wrote a Lisp function to collect the .asd and put
their directories onto asdf:*Central-registry*...

One advantage of proceeding this way is that I can deal with various
versions of the same asdf system (ie. same asd file name!), by ordering
the asdf:*central-registry* as I want.


--
__Pascal Bourguignon__
From: Erik Winkels on 19 Feb 2010 02:34
On 2010-02-18, Nicolas Neuss <firstname.lastname(a)kit.edu> wrote:
>
> C. Download everything needed in ~/CL-HOME without asdf-install (and
> -if possible- with CVS/SVN).
>
> Problems: more work, keeping it up-to-date and working with each
> other?

I use an .asdf-central-registry.lisp file that sets the *central-registry*.
This file is read in by each CL implementation's init file and this also
allows me to turn specific versions of packages on and off easily.

I've dropped the symlink approach on Unix so the above works well for me on
both Unix and Windows for CCL, CLISP and SBCL.

The initial setup perhaps takes the most time, about 5 or 10 minutes :-)

Also I've never found keeping libs up-to-date a big deal. Like others in
this thread have said: I only update when necessary.
From: Captain Obvious on 19 Feb 2010 06:26
PJB> Well, I'm a lisp programmer therefore instead of writing a shell
PJB> script to symlink files, I wrote a Lisp function to collect the .asd
PJB> and put their directories onto asdf:*Central-registry*...

Hmm, does it look for libraries each time you run lisp instance?
Won't it slow down start up, especially with a cold cache?


From: Pascal J. Bourguignon on 19 Feb 2010 09:32
"Captain Obvious" <udodenko(a)users.sourceforge.net> writes:

> PJB> Well, I'm a lisp programmer therefore instead of writing a shell
> PJB> script to symlink files, I wrote a Lisp function to collect the .asd
> PJB> and put their directories onto asdf:*Central-registry*...
>
> Hmm, does it look for libraries each time you run lisp instance?
> Won't it slow down start up, especially with a cold cache?

No, there's a cache. I can update it manually, or it will update only
when *asdf-interval-between-rescan* has passed.


--
__Pascal Bourguignon__
First  |  Prev  | 
Pages: 1 2
Prev: RosettaCode
Next: can a make-instance method return a different class?