common-lisp-controller vs. asdf-install
Josef Wolf
I see that debian/ubuntu use common-lisp-controller to package
libraries. Cliki, OTOH, seems to prefer asdf-install. Unfortunately, many
packages are missing from debian/ubuntu. What would be the proper way to
install additional packages on those machines? Install asdf-install in
parallel? Or tell common-lisp-installer how to install asdf-install'able
packages?
Zach Beane
Many people I know who use Linux get libraries via clbuild:
http://common-lisp.net/project/clbuild/
I'm also working on a project along those lines. The software isn't
released yet (it's not nearly ready), but you can see it in action via
my screencast here:
I hope to have something anyone can use soon.
Zach
Robert Uhl
The Right Way is to create a Debian package which uses clc (which isn't
an installer; it solves the problem of using multiple Lisp packages with
multiple Lisp implementations). The Easy Way is to just ASDF-INSTALL
and move on with life.
I've done both.
--
Robert A. Uhl
Tim X
Well, it all depends on what your requirements are.
The clc framework is really good if you plan to run multiple lisp
implementations and want to have all your libraries available for all of
them.
You can have both clc and asdf packages and provided you follow a few
key steps, it will work well. It isn't an either or situation. However,
it can become a pain if you don't follow a consistent path.
I recommend looking at
http://pkg-common-lisp.alioth.debian.org/clid/clid.html/index.html
I use the debian packages if available AND they are the version I need.
I use ASDF when they are not available or I want a later version than
the current debian one.
I use ASDF in my projects to handle loading what I need.
I like using clc as it is easy to see how my projects run under
different implementations. For some tasks I prefer clisp and for other
sbcl. The clc allows me to do this with little pain.
Tim
--
tcross (at) rapttech dot com dot au
Scott L. Burson
What makes quicklisp better than the other projects with similar goals?
-- Scott
Pascal Costanza
It seems _extremely_ easy to set up.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Zach Beane
> What makes quicklisp better than the other projects with similar goals?
It's not better - it's not released yet, it's vaporware. If you have a
project you like and it works for you, excellent. I wouldn't hold off
trying e.g. clbuild, Lispy, LibCL, etc. because Quicklisp is coming out
someday.
I want to make something that is easier to install and use, and that
works everywhere CL does, i.e. not limited to Unix-like systems. I think
I have a good start on it, but there's still a long way to go.
If you'd like to try an early demo, drop me an email or join #quicklisp
on freenode.
Zach
Josef Wolf
> Zach Beane wrote:
>>
>> http://www.quicklisp.org/
>
> What makes quicklisp better than the other projects with similar goals?
Exactly what I am looking for... Unfortunately, not much information to be
found about it.
Josef Wolf
>
> http://common-lisp.net/project/clbuild/
Looks promising at first glance, I'll take a look into that.
> I'm also working on a project along those lines. The software isn't
> released yet (it's not nearly ready), but you can see it in action via
> my screencast here:
>
> http://www.quicklisp.org/
Could not find any information about that. Any pointers to some textual
information (not screencasts)?
Josef Wolf
> Josef Wolf <j...@raven.inka.de> writes:
>>
>> I see that debian/ubuntu use common-lisp-controller to package
>> libraries. Cliki, OTOH, seems to prefer asdf-install. Unfortunately, many
>> packages are missing from debian/ubuntu. What would be the proper way to
>> install additional packages on those machines? Install asdf-install in
>> parallel? Or tell common-lisp-installer how to install asdf-install'able
>> packages?
>
> The Right Way is to create a Debian package which uses clc (which isn't
> an installer; it solves the problem of using multiple Lisp packages with
> multiple Lisp implementations).
That won't work if you have multiple (non-debian) distros.
> The Easy Way is to just ASDF-INSTALL and move on with life.
Yeah, but clc needs to know about that, I guess...
Josef Wolf
> Josef Wolf <j...@raven.inka.de> writes:
>> Hello,
>> I see that debian/ubuntu use common-lisp-controller to package
>> libraries. Cliki, OTOH, seems to prefer asdf-install. Unfortunately, many
>> packages are missing from debian/ubuntu. What would be the proper way to
>> install additional packages on those machines? Install asdf-install in
>> parallel? Or tell common-lisp-installer how to install asdf-install'able
>> packages?
>
> Well, it all depends on what your requirements are.
I am trying to learn lisp. In order to get beyond trivial examples, I'd like
to try some still simple, but real useful examples, involving some existing
libraries which don't come pre-packaged with debian.
> The clc framework is really good if you plan to run multiple lisp
> implementations and want to have all your libraries available for all of
> them.
As a beginner, I'm pretty much happy with whatever is easy to install.
> You can have both clc and asdf packages
Yeah, since clc uses asdf under the hood, that'd be expected.
> and provided you follow a few
> key steps, it will work well. It isn't an either or situation. However,
> it can become a pain if you don't follow a consistent path.
The problem is, I can't find any information about what those "key steps"
are.
> I recommend looking at
> http://pkg-common-lisp.alioth.debian.org/clid/clid.html/index.html
Thanks for the pointer. But this seems to be a policy that tells package
maintainers how to create their packages. No pointers where to put libraries
I download from cliki.net. Don't look like a "user manual" to me.
> I use the debian packages if available AND they are the version I need.
>
> I use ASDF when they are not available or I want a later version than
> the current debian one.
>
> I use ASDF in my projects to handle loading what I need.
So where do you extract the downloaded tarball and and where do you put the
symlinks to the asd files? How do you tell clc about that?
Zach Beane
Not at the moment. If you'd like talk about it, try #quicklisp on
Freenode.
Zach
Tim X
OK, a good starting point is
http://common-lisp.net/project/asdf-install/tutorial/index.html
which will give you a good overview of how ASDF works and how to use it.
Also read
/usr/share/doc/common-lisp-controller/DESIGN.txt
which will explain how things interact (it even gives you a clue to your
quesiton re: where ASDF libs are unpacked).
and don't discount the Common Lisp in Debian Manual, its not just about
policy. It will help you understand how Debian manages CL
implementations and libraries, which will make it easier to know what
the right thing to do is when it is not spelt out precisely and you are
a bit unsure. Understanding the architecture will also help you resolve
problems etc. It isn't a big document.
Tim X
BTW, given your just learning, I wouldn't worry about additional
libraries yet. CL isn't like other languages which have a relatively
small core and rely on a lot of libraries. The CL standard is very
extensive and has enough in it to do non-trivial things without the need
for many libraries. Also, it will only be after you have gained a bit of
experience that you wil be able to tell the good libs from the not so
good and recognise the ones that suit your style. Also, many of the libs
available frequently don't have a lot of documentation. Without a bit of
experience with Cl, you will burn up a lot of frustrating time trying to
work out how to use them.
The CL packages that come packaged on Debian will provide the few libs
you may need at first i.e. pcre-cl, clsql and possibly a couple of the
web related libs and you will likely have more than enough to drown in!
Keep it simple and just start writing code. Once you get a feel for it
and notice parts of your work that seem too repetitive, build your own
lib. Then once you understand the problem better, look for other libs
that may be more mature or feature rich. Initially, you will find just
locating what is already in CL and using the hyperspec will be quite
enough to be a challenge.
Avoid getting caught up in learning how to use libraries and use that
effort to learn how to write lisp. I think this is the biggest
difference between learning CL compared to something like Java. Java is
very much about learning how to use APIs while CL is about learning how
to explore and solve problems writing code. Initial progress may seem
slower, but the rewards tend to be much greater, particularly if your
focus is on the programming and not just the result.
Scott L. Burson
> On 2010-09-01, Zach Beane<xa...@xach.com> wrote:
>> Josef Wolf<j...@raven.inka.de> writes:
>>
>> Many people I know who use Linux get libraries via clbuild:
>>
>> http://common-lisp.net/project/clbuild/
>
> Looks promising at first glance, I'll take a look into that.
The one I have used (and contributed a bit to as well) is Daniel
Herring's LibCL:
I guess as far as Quicklisp goes I have some concern that the wheel is
being reinvented yet again. Wouldn't it be better to pick something
that already exists and improve it? But, not knowing how Quicklisp
works, I don't really know if that's true.
Anyway, personally, I recommend LibCL at this time (though I've never
tried clbuild).
-- Scott
Scott L. Burson
> On 03/09/2010 08:04, Scott L. Burson wrote:
>>
>> What makes quicklisp better than the other projects with similar goals?
>
> It seems _extremely_ easy to set up.
Easier than LibCL?
-- Scott
Zach Beane
To install quicklisp, you download one file and load it. Same file can
be used on any* CL, on any operating system.
Zach
*Actually, just ABCL, Allegro, ClozureCL, CLISP, CMUCL, ECL, LispWorks,
Scineer CL, and SBCL.
D Herring
> "Scott L. Burson"<Sc...@ergy.com> writes:
>
>> Pascal Costanza wrote:
>>> On 03/09/2010 08:04, Scott L. Burson wrote:
>>>>
>>>> What makes quicklisp better than the other projects with similar goals?
>>>
>>> It seems _extremely_ easy to set up.
>>
>> Easier than LibCL?
>
> To install quicklisp, you download one file and load it. Same file can
> be used on any* CL, on any operating system.
Yes. But you have to load that file each time...
LibCL had two files to load.
1) configure-libcl probes around and tells you how to update your
favorite lisp's rc files
2) compile-libcl [technically optional] causes all libraries to be
built, giving a summary of what worked and what didn't (intended to be
the null set)
Not seeing a huge difference here...
The big differences I see between quicklisp and LibCL are
- LibCL was quiet until nearly ready
- LibCL had a few releases and then went stagnant
- LibCL is a single download, including all docs
- quicklisp has more stuff, but doesn't guarantee it will run on your
system (especially cffi bindings -- something LibCL will not include)
;)
Honestly, I look forward to giving quicklisp a try, but there are many
open questions. I don't think they need to be resolved in favor of
either system, and there may be opportunities for us to share
resources (especially now that I'm moving towards plain tarballs). A
little choice and competition are good.
Later,
Daniel
Zach Beane
> Honestly, I look forward to giving quicklisp a try, but there are many
> open questions. I don't think they need to be resolved in favor of
> either system, and there may be opportunities for us to share
> resources (especially now that I'm moving towards plain tarballs). A
> little choice and competition are good.
If nothing else, I hope a new minimum is set for the amount of pain a
Lisp user is willing to endure to get a lot of useful libraries into
their development environment.
Zach
Scott L. Burson
> A little choice and competition are good.
Except that we have way too much of them in the CL world -- too many CL
implementations, too many Web app frameworks (as someone recently
posted), too many redundant libraries of all kinds really, and, as we
see here, too many meta-libraries. If our resources weren't so badly
stretched to begin with, maybe all this choice and competition would be
good. But we have so little time. As happy as I am to see somebody
like Zach doing something, I really would have liked it if we had first
had a conversation about whether LibCL was good enough, if not why not
and what could be done about it, and whether Zach's time was best spent
on building yet another such meta-library from scratch or on improving
LibCL.
Of course one could say the same thing about LibCL vis-a-vis any of its
predecessors, not all of which I ever got around to trying, but my
impression nonetheless is that they all have problems which LibCL at
least makes a good solid try at fixing. LibCL certainly struck me at
its introduction as going about things the right way, which is why I put
some effort into helping out at one point. But, it doesn't seem to have
achieved critical mass.
Anyway I guess the constructive point I'm trying to make here is, can't
we all please try to coordinate our efforts better instead of just going
off and doing stuff all the time? The keyword here is "all" the time --
we're certainly all going to do our own things a lot of the time (FSet
being a fine example, heh) -- but on projects that are specifically
intended to benefit the CL community, like meta-libraries, maybe a
little more communication would help?
-- Scott
Josef Wolf
>> On 2010-09-01, Zach Beane<xa...@xach.com> wrote:
>>> Josef Wolf<j...@raven.inka.de> writes:
>>>
>>> Many people I know who use Linux get libraries via clbuild:
>>>
>>> http://common-lisp.net/project/clbuild/
>>
>> Looks promising at first glance, I'll take a look into that.
>
> The one I have used (and contributed a bit to as well) is Daniel
> Herring's LibCL:
>
> http://libcl.com/
>
> I guess as far as Quicklisp goes I have some concern that the wheel is
> being reinvented yet again. Wouldn't it be better to pick something
> that already exists and improve it? But, not knowing how Quicklisp
> works, I don't really know if that's true.
To be honest, I have the same feeling about all those clc/asdf/whatever
I bet I'm missing the point of having many (incompatible) packages to manage
libraries. And it doesn't really help if none of them has usable instructions
how to configure/use it properly.
> Anyway, personally, I recommend LibCL at this time (though I've never
> tried clbuild).
Ah, yet another library-management-package? Fine. Want to take a look into
it. But first, I'll go to check out all the other methods (I gave up counting
them) mentioned here.
Josef Wolf
> Josef Wolf <j...@raven.inka.de> writes:
>>> I use ASDF in my projects to handle loading what I need.
>>
>> So where do you extract the downloaded tarball and and where do you put the
>> symlinks to the asd files? How do you tell clc about that?
>
> OK, a good starting point is
> http://common-lisp.net/project/asdf-install/tutorial/index.html
Thanks for the pointer. Was there, seen that...
First, this tutorial seems to be pretty much outdated. E.g. Current ASDF
documentation deprecates *central-registry*
Second, searching for instructions about clc integration, I'd bet is pretty
much hopeless.
> which will give you a good overview of how ASDF works and how to use it.
Yeah, I've been there a while ago. But how to integrate it with clc?
> Also read
> /usr/share/doc/common-lisp-controller/DESIGN.txt
Yeah, that's really helpful. It explains what library implementors should do
and it talks about what implementors should do. But when it comes to talk
about what the _user_ want to do, it gets strange:
| - a user wants to use another library. He or she used adsf-install
| and the sources got placed in ~/.sbcl or ~/sdf-install-dir/. We do not
| interfere with this use as we expect the user to be able to correct all
| errors :-).
OK, they expect the user is able to correct the errors. Fine. I bet I would
be able to fix the errors, if only I had the information how all those things
stick together. Unfortunately, I can't find any information about how the
things are meant to fit.
> which will explain how things interact (it even gives you a clue to your
> quesiton re: where ASDF libs are unpacked).
Strange, I don't see how they interact. Anyway, while there's a description
where clc libs are unpacked, I can't find a description where to put libraries
downloaded manually or by (e.g.) asdf-install.
> and don't discount the Common Lisp in Debian Manual, its not just about
> policy. It will help you understand how Debian manages CL
> implementations and libraries, which will make it easier to know what
> the right thing to do is when it is not spelt out precisely and you are
> a bit unsure. Understanding the architecture will also help you resolve
> problems etc. It isn't a big document.
It tells me how to create/package my own library/implementation/whatever
Honestly, this is not what I am trying to do. What I am trying to do is to
install some libs from cliki.net. And there's nothing in this paper telling
me how to integrate it into the system.
You wrote you do this all the time. Why can't you provide some simple
instructions what exactly you are ding?
Scott L. Burson
I see elsewhere in the thread that you're still having a little trouble
with those other methods. I would at least suggest taking a moment to
glance at the LibCL package list to see if everything you want is in
there (it's at http://libcl.com/libcl-current/index.html). If it has
what you want, I'm fairly certain you'll find it much easier to use than
the pain you're going through now. In short, I don't think it belongs
at the end of your list.
-- Scott
Josef Wolf
> libraries yet. CL isn't like other languages which have a relatively
> small core and rely on a lot of libraries. The CL standard is very
> extensive and has enough in it to do non-trivial things without the need
> for many libraries.
Not true, IMHO. Learning gets much more interesting if you can do some
"fancy" stuff like GUI or networking or something. Using such libraries
pretty much increase the probability that your "learning example" might
get a useful toy worth to fiddle around with it and explore what can be
done with it. Playing with the language is a good training for learning
the language, IMHO. The interest of doing fibonacci don't last very long.
> Also, it will only be after you have gained a bit of
> experience that you wil be able to tell the good libs from the not so
> good and recognise the ones that suit your style.
Ummm, I tend to disagree here. You won't be able to tell good from bad
if you were never confronted with both. The important point is to recognize
the reason _why_ good is good and why bad is bad. Hiding the bad under the
hood is no good. The better approach is to show the bad and show/explain the
reasons _why_ it is bad. After that, show the good, again with explanation.
But never hide the bad.
> Also, many of the libs
> available frequently don't have a lot of documentation. Without a bit of
> experience with Cl, you will burn up a lot of frustrating time trying to
> work out how to use them.
To be honest, I've already collected a lot of frustrating time trying to
install at least one lib. I'm not even up to the point of actually use one
of them.
> The CL packages that come packaged on Debian will provide the few libs
> you may need at first i.e. pcre-cl, clsql and possibly a couple of the
> web related libs and you will likely have more than enough to drown in!
For sure. But then there are really interesting packages out there which
give me the hope to learn new paradigms. That's where I'd like to play
around.
> Keep it simple and just start writing code. Once you get a feel for it
> and notice parts of your work that seem too repetitive, build your own
> lib.
Well, in the past I used to avoid to reinvent the wheel. For example, if
there exists XXX/Tk or GTK or something, why on earth should I go and write
my own lib?
> Then once you understand the problem better, look for other libs
At the moment, I don't really care about the quality of the libs. The only
thing I want to achieve is to be able to _install_ libs. Why shall I go
comparing libs while I am not able to install them?
> Avoid getting caught up in learning how to use libraries and use that
> effort to learn how to write lisp.
But isn't using libraries part of _any_ language paradigm? You don't really
want to code the same instructions over and over and over again, do you?
> I think this is the biggest
> difference between learning CL compared to something like Java. Java is
> very much about learning how to use APIs while CL is about learning how
> to explore and solve problems writing code.
But you won't reinvent the wheel, do you?
Tim X
> On 2010-09-03, Tim X <ti...@nospam.dev.null> wrote:
>> Josef Wolf <j...@raven.inka.de> writes:
>>>> I use ASDF in my projects to handle loading what I need.
>>>
>>> So where do you extract the downloaded tarball and and where do you put the
>>> symlinks to the asd files? How do you tell clc about that?
>>
>> OK, a good starting point is
>> http://common-lisp.net/project/asdf-install/tutorial/index.html
>
> Thanks for the pointer. Was there, seen that...
>
> First, this tutorial seems to be pretty much outdated. E.g. Current ASDF
> documentation deprecates *central-registry*
Largely irrelevant to what you are wanting
>
> Second, searching for instructions about clc integration, I'd bet is pretty
> much hopeless.
don't worry about it at this time. As I said in a previous post, the
benefits/power of clc really only come into play if your using multiple
cl implementations. As you are at a learning stage, just pick an
implementation and work with that.
>
>> which will give you a good overview of how ASDF works and how to use it.
>
> Yeah, I've been there a while ago. But how to integrate it with clc?
>
don't
>> Also read
>> /usr/share/doc/common-lisp-controller/DESIGN.txt
>
> Yeah, that's really helpful. It explains what library implementors should do
> and it talks about what implementors should do. But when it comes to talk
> about what the _user_ want to do, it gets strange:
If your wanting to mix in clc and asdf, then you need to look at things
from the lib implementor point of view. However, at a learning stage,
just ignore clc and get on with writing code!
>
> | - a user wants to use another library. He or she used adsf-install
> | and the sources got placed in ~/.sbcl or ~/sdf-install-dir/. We do not
> | interfere with this use as we expect the user to be able to correct all
> | errors :-).
>
> OK, they expect the user is able to correct the errors. Fine. I bet I would
> be able to fix the errors, if only I had the information how all those things
> stick together. Unfortunately, I can't find any information about how the
> things are meant to fit.
The point you missed from that file was that they don't have to be
integrated/connected. CLC will leave asdf installed libs alone and under
the management/control of the user. What this is telling you is that you
don't have to integrate them.
they don't have to fit. CLC is only relevant when you want to run
multiple lisp implementations. This is not relevant when you are at a
learning stage. Just pick an implementation, use ASDF for any libs
that are not available for debian and go
>
>> which will explain how things interact (it even gives you a clue to your
>> quesiton re: where ASDF libs are unpacked).
>
> Strange, I don't see how they interact. Anyway, while there's a description
> where clc libs are unpacked, I can't find a description where to put libraries
> downloaded manually or by (e.g.) asdf-install.
>
>> and don't discount the Common Lisp in Debian Manual, its not just about
>> policy. It will help you understand how Debian manages CL
>> implementations and libraries, which will make it easier to know what
>> the right thing to do is when it is not spelt out precisely and you are
>> a bit unsure. Understanding the architecture will also help you resolve
>> problems etc. It isn't a big document.
>
> It tells me how to create/package my own library/implementation/whatever
> Honestly, this is not what I am trying to do. What I am trying to do is to
> install some libs from cliki.net. And there's nothing in this paper telling
> me how to integrate it into the system.
Well, I think your description is possibly clouding what you need or
want. If all you want to do is install ASDF based libs for your own use,
then just use asdf and do it. From your stated position of being at a
learning stage, this would seem the sane direction to go. However, if
you want to install the ASDF libs AND have them fully integrated into
your debian system then you need to read and understand the clc docs and
the debian cl manual. I don't believe you need this at this stage.
>
>
> You wrote you do this all the time. Why can't you provide some simple
> instructions what exactly you are ding?
Thats simple, because what I am doing is more complex than you need to
get started. I can provide you with full and long details of how I deal
with this, but 80% of it will be irrelevant for what you need. I have
also heavily customized the process since I initially started so that it
suits my setup and how I like to work. My setup means I can use any of
the Cl implementations the libs I've installed support and I can use
multiple different users to do this i.e. the extra libs I've installed
are fully integrated into the system.
Note that I started with absolutely no knowledge of clc or asdf. The
references I gave you are the same ones I used to get started.
From the additional information you have provided, it seems you don't
actually want to fully integrate the asdf based libs into your system.
All you want to do is install them and use them with an implementation.
I think this is the right approach if you are just wanting to learn.
Therefore, you don't want/need the libs to be fully integrated. You can
ignore clc and just install the asdf based libs using asdf. Don't over
think things - keep it simple to start with.
Below is the relevant section from that asdf tutorial I referred you to.
Yes, it is a bit outdated, but the basics have not changed enough for
this to be an issue. It covers all the questions you asked. You don't
even need to install asdf as Debian has that as a package (for those
implementations that don't already include it)
Location:
http://common-lisp.net/project/asdf-install/tutorial/install.html
ASDF-INSTALL Tutorial
• contents
• intro
• setup
• install
• uninstall
• reference
• changelog
• license
How to install a library
Here and in the following sections we assume that you have set up your
environment as described in Prerequisites.
Note: Of course, the fact that a library can be installed with ASDF-INSTALL
and that ASDF-INSTALL was ported to your Lisp implementation doesn't necessary
mean that the library itself will work with your Lisp! Check the library's
docs before you try to install it.
Installing a library by name
The webpage http://www.cliki.net/asdf-install contains a list of libraries
which can automatically be downloaded and installed via ASDF-INSTALL. Listed
here are libraries which are explicitely prepared to work with ASDF-INSTALL
and where the author decided to announce this via CLiki. This is the preferred
way to install a library via ASDF-INSTALL.
You can click on the name of each library to get a description. Use the
library's name from the list to install it. If, say, you want to install
CL-PPCRE make sure you're connected to the Internet and use this command:
(asdf-install:install :cl-ppcre)
Then proceed with Where to store the library below.
Note: If you install a library by name, ASDF-INSTALL will connect to the CLiki
website and from there it'll be redirected to the actual download location
provided by the library's author.
Note: The argument to the ASDF-INSTALL:INSTALL function is a string designator
, i.e. instead of :CL-PPCRE you can also use "cl-ppcre". CLiki is
case-insensitive and therefore case doesn't matter if you install a library by
name.
Installing a library by URL
The list mentioned above is not necessary complete, i.e. there might as well
exist libraries which aren't listed there but which can be installed via
ASDF-INSTALL.
In order to be ASDF-installable a library has to contain a system definition
for ASDF. It also has to be packaged in a certain way: It is assumed to come
as a gzipped tar archive (usually ending in .tar.gz or .tgz) which unpacks
into one directory possibly containing sub-directories. The system definition
has to have a name corresponding to the name of the library (so if your
library is called "foobar" the system definition is supposed to be foobar.asd)
and has to reside in the top-level directory.
If this is the case you can download and install the library directly by
providing the download URL of the package like so:
(asdf-install:install "http://weitz.de/files/cl-ppcre.tar.gz")
Now proceed with Where to store the library below.
Note: Currently, ASDF-INSTALL only understands http. Other protocols like ftp
or https aren't supported.
Note: It's obviously rather easy to make an existing library ASDF-installable
if it isn't already. If you come across a library which you'd like to use but
which isn't listed on http://www.cliki.net/asdf-install, it might be
worthwhile to kindly ask the library's author to change this.
Installing from a local file
The third way to install a library via ASDF-INSTALL is to use a local tar
archive (in the format described in the last section). In this case you use
the file's namestring
(asdf-install:install "/path/to/library/library.tar.gz")
and afterwards carry on with the next section.
Note: For obvious reasons this namestring must not start with "http://"
although your operating system might otherwise allow this.
Where to store the library
ASDF-INSTALL will now ask you where the library should be stored. (This can be
customized.) In the default configuration this'll look more or less like so:
Install where?
1) System-wide install:
System in /usr/local/asdf-install/site-systems/
Files in /usr/local/asdf-install/site/
2) Personal installation:
System in /Users/gwking/.asdf-install-dir/systems/
Files in /Users/gwking/.asdf-install-dir/site/
0) Abort installation.
-->
Choose one of these options and enter the corresponding number, then press the
Return key. (Note that on Unix-like systems you usually don't have write
access in /usr/local/ unless you're root.) Choice 0 will always be assigned to
canceling the installation.
The security check
If you don't install from a local file, ASDF-INSTALL will now check the
validity of the library. (This behaviour can be customized.) Library authors
are supposed to crypto-sign their libraries and provide a file with the (PGP)
signature in the same place where the library can be downloaded, i.e. if the
library is at http://www.example.com/frob.tar.gz then ASDF-INSTALL will try to
download the signature from http://www.example.com/frob.tar.gz.asc.
ASDF-INSTALL will check
• if the signature exists on your computer,
• if there is a GPG trust relationship between the package signer and you
(i.e. that the package comes from someone whose key you've signed, or
someone else you have GPG trust with has signed), and
• if the signer is listed in your personal list of valid suppliers of Lisp
code.
If all these tests succeed, ASDF-INSTALL will compile and install the library
and you can now use it. (This will also happen instantly if you have installed
from a local file.)
If one of the checks fails, you'll most likely be confronted with one of these
situations:
Downloading 157777 bytes from http://weitz.de/files//cl-ppcre.tgz ...
Error: Server responded 404 for GET http://weitz.de/files//cl-ppcre.tgz.asc
[condition type: DOWNLOAD-ERROR]
Restart actions (select using :continue):
0: Don't ckeck GPG signature for this package
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
There was no signature corresponding to this package.
Downloading 6365 bytes from http://files.b9.com//cl-base64-latest.tar.gz ...gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Thu 12 Jun 2003 04:06:04 PM CEST using DSA key ID C4A3823E
gpg: Can't check signature: public key not found
Error: No key found for key id 0x112ECDF2C4A3823E. Try some command like
gpg --recv-keys 0x112ECDF2C4A3823E
[condition type: KEY-NOT-FOUND]
Restart actions (select using :continue):
0: Don't ckeck GPG signature for this package
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
The library was signed but the signer's public key wasn't found in your public
keyring.
Downloading 6365 bytes from http://files.b9.com//cl-base64-latest.tar.gz ...gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Thu 12 Jun 2003 04:06:04 PM CEST using DSA key ID C4A3823E
gpg: Good signature from "Kevin M. Rosenberg <k...@debian.org>"
gpg: aka "Kevin Rosenberg <ke...@rosenberg.net>"
gpg: aka "Kevin M. Rosenberg <ke...@b9.com>"
gpg: aka "Kevin Marcus Rosenberg, M.D. <ke...@b9.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: D7A0 55B6 4768 3582 B10D 3F0C 112E CDF2 C4A3 823E
Error: GPG warns that the key id 0x112ECDF2C4A3823E (Kevin M. Rosenberg <k...@debian.org>) is not fully trusted
[condition type: KEY-NOT-TRUSTED]
Restart actions (select using :continue):
0: Don't ckeck GPG signature for this package
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
The signer's key is in your public keyring but you have no GPG trust
relationship with him.
Downloading 157777 bytes from http://weitz.de/files//cl-ppcre.tgz ...gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Fri 24 Oct 2003 11:22:11 AM CEST using DSA key ID 057958C6
gpg: Good signature from "Dr. Edmund Weitz <e...@weitz.de>"
Error: Dr. Edmund Weitz <e...@weitz.de> (key id 595FF045057958C6) is not on your package supplier list
[condition type: AUTHOR-NOT-TRUSTED]
Restart actions (select using :continue):
0: Add to package supplier list
1: Don't ckeck GPG signature for this package
2: Return to Top Level (an "abort" restart).
3: Abort entirely from this process.
The signer's key is in your public keyring, you have a GPG trust relationship
with him but the signer wasn't found in your list of valid suppliers of Lisp
code.
As you'll have noticed, in all these cases ASDF-INSTALL offers the restart not
to check the GPG signature in this particular case. How you can select this
restart depends on your Lisp implementation but if you select it ASDF-INSTALL
will proceed compiling and installing the package without further checks for
this library.
In the last case (condition type AUTHOR-NOT-TRUSTED) you are also offered
another restart. If you select this one the signer of the library will be
added to your package supplier list and you won't be asked again if you
install another library signed by the same person.
Note: You might be asking yourself if all this security stuff is really
necessary. Well, CLiki, the website where ASDF-INSTALL looks for the package
URL if you install by name, can be edited by anyone so it would be fairly easy
for a malicious hacker to redirect you to a library which once it's installed
insults your boss by email or withdraws US$ 100,000 from your bank account.
You better make sure this doesn't happen... See the section about
customization on how to (partly) disable security checks.
Note: If you're unsure about notions like public keyring or GPG trust
relationship, please read the GnuPG documentation. It is beyond the scope of
this text to explain these terms.
How to use an installed library
After you've successfully executed ASDF-INSTALL:INSTALL you can immediately
use the library you've just installed while you're still in the same Lisp
session. If you quit your Lisp image and start it anew you have to reload the
library. (Of course you don't have to install it again!) This is done like so:
(asdf:operate 'asdf:load-op :library-name)
Here :LIBRARY-NAME is either the name you've used if you installed by name or
it is the name of the main .asd file if you've installed by URL or from a
local file. If you're not sure about the name you have to use, you can list
the contents of your registry for all libraries which are available to you.
So, if your registry looks like this
edi@bird:~ > ls ~/.asdf-install-dir/systems/
cl-ppcre.asd cl-ppcre-test.asd cl-who.asd html-template.asd
you can substitute :LIBRARY-NAME with one of :CL-PPCRE, :CL-PPCRE-TEST,
:CL-WHO, or :HTML-TEMPLATE. (CL-PPCRE-TEST was most likely automatically
installed when you installed CL-PPCRE.)
If you use SBCL you can, instead of calling ASDF:OPERATE, simply REQUIRE the
library:
(require :library-name)
How ASDF-INSTALL resolves dependencies
Sometimes a library depends on one or more other libraries. This can be
expressed within an ASDF system definition. If there's a dependency and the
necessary libraries aren't already installed then ASDF-INSTALL will try to
download the missing libraries by name and install them before it proceeds to
install the main library. This of course requires that the missing libraries
are also listed on CLiki.
You can for example from CMUCL issue the command
(asdf-install:install :osicat)
and watch how ASDF-INSTALL not only downloads and installs Osicat but also
UFFI.
• contents
• intro
• setup
• install
• uninstall
• reference
• changelog
• license
Copyright
Tutorial Copyright (c) 2006-2009 Gary King. All rights reserved.
Tutorial Copyright (c) 2004-2006 Dr. Edmund Weitz. All rights reserved.
Last updated 20 July 2009 at 09:32
Robert Maas, http://tinyurl.com/uh3t
> OK, a good starting point is
> http://common-lisp.net/project/asdf-install/tutorial/index.html
> which will give you a good overview of how ASDF works and how to use it.
"Please send e-mail to if you have any questions or find anything amiss."
Please have somebody fix the typo there.
Tim X
> On 2010-09-03, Tim X <ti...@nospam.dev.null> wrote:
>> BTW, given your just learning, I wouldn't worry about additional
>> libraries yet. CL isn't like other languages which have a relatively
>> small core and rely on a lot of libraries. The CL standard is very
>> extensive and has enough in it to do non-trivial things without the need
>> for many libraries.
>
> Not true, IMHO. Learning gets much more interesting if you can do some
> "fancy" stuff like GUI or networking or something. Using such libraries
> pretty much increase the probability that your "learning example" might
> get a useful toy worth to fiddle around with it and explore what can be
> done with it. Playing with the language is a good training for learning
> the language, IMHO. The interest of doing fibonacci don't last very
> long.
I think this shows how unfamiliar you are with what is already built-in.
I'm not talking about doing trivial exercises like fibonacci sequences
or number factorials. You can do quite a lot of practicle things with
just the core language. However, you also need to have a firm grasp of
the languages support for abstraction and its data structures. Also,
note that pretty much all the implementations have extensions for things
like networking, OS interaction, some have support for Berkley DB or
basic GUI, regular expressions etc.
>
>> Also, it will only be after you have gained a bit of
>> experience that you wil be able to tell the good libs from the not so
>> good and recognise the ones that suit your style.
>
> Ummm, I tend to disagree here. You won't be able to tell good from bad
> if you were never confronted with both. The important point is to recognize
> the reason _why_ good is good and why bad is bad. Hiding the bad under the
> hood is no good. The better approach is to show the bad and show/explain the
> reasons _why_ it is bad. After that, show the good, again with explanation.
> But never hide the bad.
I never said anything about hiding the bad. However, I think you missed
my point. There is no quality control over the libs you can download.
Anyone can write a lib and put it up. I've found only a few are really
good, many show some promise, but never reached maturity and quite a few
are just rubbish. Until you have written quite a bit and found your
style and have a good grasp of what is already available in the core,
you don't have any yardstick to measure with and run the real risk of
learning bad habits and/or reinventing, usually in a less
efficient/elegant way, things you already have available. You will also
find that most of the libraries are severely lacking in documentation.
Until you have a very firm grasp of the languages and can easily
understand the code in these libraries, you are likely to just get
extremely frustrated. Don't expect clear API docs and examples.
The cliche with lisp is that it is easy to learn and hard to master.
Like many cliches, it has a core of truth. Often it is easier to
re-invent rather than understand. I think this goes a long way to
explain why we have so many libs that appear to do the same or very
similar thing. I also think this explains why we have so many different
solutions to managing libraries.
As you have seen from this thread, your original quesiton regarding how
to integrate CLC and ASDF has been met with a number of posts
recommending completely different solutions. Almost all of these
solutions have their own particular advantages and disadvantages. I
think that part of the problem here is due to the fact it is, at a
somehwat trivial level, easier to roll your own solution than
come to grips with and understand solutions written by others. Combine
this with individual differences in priorities/requirements and what I
beleive is still a lack of clear understanding regarding what we all
need and we end up with the result of multiple solutions that all do it
a little differently. This is further complicated by CL's support for
multiple paradigms.
>
>> Also, many of the libs
>> available frequently don't have a lot of documentation. Without a bit of
>> experience with Cl, you will burn up a lot of frustrating time trying to
>> work out how to use them.
>
> To be honest, I've already collected a lot of frustrating time trying to
> install at least one lib. I'm not even up to the point of actually use one
> of them.
>
Do you actually have a goal or a project to work on or are you just
looking to install libs that look interesting? I would strongly
recommend identifying a project with a clear goal and start writing it.
When you run into problems and think a library might be able to help,
come back to the group and ask for recommendations. I think part of your
frustration is due to only having a very cursory familiarity with CL.
As a rule you are not going to find much current documentation for many
of the libraries - the code is the documentation, but to understand it
you need to have a good grasp of the language and the only way you get
that is through writing code.
>> The CL packages that come packaged on Debian will provide the few libs
>> you may need at first i.e. pcre-cl, clsql and possibly a couple of the
>> web related libs and you will likely have more than enough to drown in!
>
> For sure. But then there are really interesting packages out there which
> give me the hope to learn new paradigms. That's where I'd like to play
> around.
Thats a good objective, but I think its important to have an end goal -
something you can aim for and recognise when you get there. Without
this, you are likely to lack direction and fail to get anywhere.
>
>> Keep it simple and just start writing code. Once you get a feel for it
>> and notice parts of your work that seem too repetitive, build your own
>> lib.
>
> Well, in the past I used to avoid to reinvent the wheel. For example, if
> there exists XXX/Tk or GTK or something, why on earth should I go and write
> my own lib?
>
Its about balance. Often, you cannot appreciate the issues involved in
solving a problem until you have tried to do it yourself. Knowing when
to use a library and when to write it yourself is not always clear - I
guess it comes down to experience. However, I would tend to favor
writing it yourself when first learning - even just mapping out how you
would write it can be worthwhile.
>> Then once you understand the problem better, look for other libs
>
> At the moment, I don't really care about the quality of the libs. The only
> thing I want to achieve is to be able to _install_ libs. Why shall I go
> comparing libs while I am not able to install them?
>
>> Avoid getting caught up in learning how to use libraries and use that
>> effort to learn how to write lisp.
>
> But isn't using libraries part of _any_ language paradigm? You don't really
> want to code the same instructions over and over and over again, do
> you?
No, but you need to walk before you can run. Suppose you set yourself a
task and you grab a heap of libs to help achieve that task. You then
find your software has constant problems - maybe it crashes all the
time, gives inconsistent results, is too slow etc. How do you proceed?
If you have spent time actually writing a fair amount of CL code - real
code to solve problems, not code that just calls functions others have
written, you are more likely to recognise good/bad code plus you will
have developed the debugging and diagnostic skills that will help you
find where the problem is. I think this is very important when dealing
with a language like CL where you have no guarantee of library quality.
>
>> I think this is the biggest
>> difference between learning CL compared to something like Java. Java is
>> very much about learning how to use APIs while CL is about learning how
>> to explore and solve problems writing code.
>
> But you won't reinvent the wheel, do you?
When I started and was learning CL, yes I re-invented many wheels. That
is what a large part of learning a new language is all about. Only after
reinventing some of these wheels do you really understand some of the
more subtle aspects, particularly those that are specific to the
language you are learning and only then can you really appreciate and
learn from others who have more experience and provided more efficient
or elegant solutions.
Of course, everyones mileage differs. However, after nearly 30 years of
writing code and having learnt many different languages, I have to say
that learning lisp has been fundamentally different from nearly
everything else I have done and required a very different mindset.
Learning perl, tcl, java, python and a number of other languages was not
a significant challenge as they were not much different conceptually
from my first languages (Modula-2, Pascal, C, C++). However, prolog,
smalltalk and most significantly lisp required considerably more effort
before things began to come together. Lisp has kept my interest for the
longest because of this and has had the biggest impact on my programming
of any language (though I do remember learning assembly had considerable
influence as well). I would also have to say that lisp is still the
language I would consider I have less mastery over than the others and
the one I still learn the most from.
Zach Beane
> On 09/03/2010 11:49 AM, Zach Beane wrote:
>> "Scott L. Burson"<Sc...@ergy.com> writes:
>>
>>> Pascal Costanza wrote:
>>>> On 03/09/2010 08:04, Scott L. Burson wrote:
>>>>>
>>>>> What makes quicklisp better than the other projects with similar goals?
>>>>
>>>> It seems _extremely_ easy to set up.
>>>
>>> Easier than LibCL?
>>
>> To install quicklisp, you download one file and load it. Same file can
>> be used on any* CL, on any operating system.
>
> Yes. But you have to load that file each time...
>
> LibCL had two files to load.
>
> 1) configure-libcl probes around and tells you how to update your
> favorite lisp's rc files
> 2) compile-libcl [technically optional] causes all libraries to be
> built, giving a summary of what worked and what didn't (intended to be
> the null set)
>
> Not seeing a huge difference here...
I've been sharing the early demo with folks who ask, and here are the
instructions:
"Download and load http://foo.bar.baz/quux.lisp."
I don't think LibCL setup is very complicated, but it isn't *that*
easy.
Zach
Zach Beane
> D Herring wrote:
>> A little choice and competition are good.
>
> Except that we have way too much of them in the CL world -- too many
> CL implementations, too many Web app frameworks (as someone recently
> posted), too many redundant libraries of all kinds really, and, as we
> see here, too many meta-libraries. If our resources weren't so badly
> stretched to begin with, maybe all this choice and competition would
> be good.
Time and effort isn't something you can allocate arbitrarily. I work on
Quicklisp because I like the idea, it's different from anything
currently in progress in ways that are important to me, it's fun, and
the early feedback from people who try it has been, for the most part,
extremely encouraging.
If I didn't work on Quicklisp, I would be working on other projects of
my own that need attention, not someone else's meta-library project.
> Anyway I guess the constructive point I'm trying to make here is,
> can't we all please try to coordinate our efforts better instead of
> just going off and doing stuff all the time? The keyword here is
> "all" the time -- we're certainly all going to do our own things a lot
> of the time (FSet being a fine example, heh) -- but on projects that
> are specifically intended to benefit the CL community, like
> meta-libraries, maybe a little more communication would help?
I talked to Daniel about it at ILC2009. It didn't seem like our
priorities for the user experience overlapped much.
Zach
D Herring
> I've been sharing the early demo with folks who ask, and here are the
> instructions:
>
> "Download and load http://foo.bar.baz/quux.lisp."
Apparently nobody saw me on #quicklisp a couple days ago... I would
like to try the current version. In particular, I am interested in
your tarball packaging infrastructure.
> I don't think LibCL setup is very complicated, but it isn't *that*
> easy.
I feel your advertising is a bit misleading here. Yes, I may be able
to further streamline the LibCL experience (help appreciated).
However, LibCL's "extra steps" lead the user through configuring their
implementation[1] and precompiling everything. Once that's done, the
user never directly interacts with LibCL until they install the next
version.
Last I saw, quicklisp's "single step" didn't do all that. The user
has to load quicklisp every time they need a new library (and every
session on impls without asdf?). The step that reports "lib X doesn't
run on your impl for reason Y" is hidden in the uncounted step that
says "please install X".
So I see the count as
LibCL: a few setup steps and done
Quicklisp: one setup step and a couple usage steps thereafter
Anyhow, I really see quicklisp as a potential successor to the
asdf-install/clbuild line of tools. The key features being fewer
system requirements and a tarball cache so things don't break easily.
Its a shame Samium got stalled on Desire; he had a lot of good
infrastructure, though a couple things were too complicated.
I never figured out how LibCL and Desire could share resources.
However, with LibCL moving from using git to tarballs[2], it is quite
possible that LibCL and Quicklisp could share source tarballs and
library metadata.
As Zach said, we have different goals for these systems. LibCL is
aiming to compile a set of "de-facto standard libraries", fix
portability issues, and address other infrastructure issues.
Quicklisp will always have a wider set of packages.
- Daniel
[1] Potentially easier with ASDF 2.
[2] Key problems were maintaining all the repos, converting other VCSs
to git, and seamlessly merging local patches.
Scott L. Burson
> "Scott L. Burson"<Sc...@ergy.com> writes:
>
>> D Herring wrote:
>>> A little choice and competition are good.
>>
>> Except that we have way too much of them in the CL world -- too many
>> CL implementations, too many Web app frameworks (as someone recently
>> posted), too many redundant libraries of all kinds really, and, as we
>> see here, too many meta-libraries. If our resources weren't so badly
>> stretched to begin with, maybe all this choice and competition would
>> be good.
>
> Time and effort isn't something you can allocate arbitrarily. I work on
> Quicklisp because I like the idea, it's different from anything
> currently in progress in ways that are important to me, it's fun, and
> the early feedback from people who try it has been, for the most part,
> extremely encouraging.
>
> If I didn't work on Quicklisp, I would be working on other projects of
> my own that need attention, not someone else's meta-library project.
Okay, well, that's certainly your choice. I can't "allocate" anyone's
time but my own, but I can try to gently persuade others that there
would be advantages to coordinating our efforts.
>> Anyway I guess the constructive point I'm trying to make here is,
>> can't we all please try to coordinate our efforts better instead of
>> just going off and doing stuff all the time? The keyword here is
>> "all" the time -- we're certainly all going to do our own things a lot
>> of the time (FSet being a fine example, heh) -- but on projects that
>> are specifically intended to benefit the CL community, like
>> meta-libraries, maybe a little more communication would help?
>
> I talked to Daniel about it at ILC2009. It didn't seem like our
> priorities for the user experience overlapped much.
I see. Seems like the high-level goal, of making it easy to install
stuff, is in common, but I guess you have divergent ideas of how to do that.
Well, I hope you will at least make use of the work that primarily
Daniel, and to a lesser extent I and others, put into tweaking the LibCL
libraries so they ran on as many platforms as possible.
-- Scott
Tim X
> I see. Seems like the high-level goal, of making it easy to install stuff, is
> in common, but I guess you have divergent ideas of how to do that.
>
I think this is the key issue and I suspect it is a sign we don't yet
have a handle on the best way to solve the problem. We all want it to be
easy to install libs, but how best to do that is still evolving.
> Well, I hope you will at least make use of the work that primarily Daniel, and
> to a lesser extent I and others, put into tweaking the LibCL libraries so they
> ran on as many platforms as possible.
>
Yes, my hope is that over time, things will converege, taking the best
ideas that each has to offer. Rather than seeing the different solutions
as competition, I tend to see them as different experiments in learning
which ideas work and which don't. From this perspective, the various
solutions are a positive thing as it indicates real interest and effort
to find a solution. However, I suspect we are still a way off from
finding that solution.