I'm loving lisp as I continue to learn more, but coming from ruby I'm
finding the package management to be sort of cumbersome. Hopefully
this is just because I don't have it figured out yet though. First, a
couple of quick questions:
* How do you get the path of the current file? In my unit tests, for
example, I'd like to load up other files based on some relative path
from the test file. (Say a fixtures directory with test data or
something...)
* How do you add to the search path for require, rather than having to
specify the exact path to a file?
So as I understand so far...
I'm using SBCL, but I'd like what I write to be portable. This very
unfortunately means I can't even use
(require 'foo)
instead I'm relegated to the, IMHO ridiculous,
(asdf:operate 'asdf:load-op 'foo)
This has it's own load paths which are in asdf:*central-registry*,
which is for loading systems. A system is a collection of files that
in turn implement packages. Packages are basically a namespace
mechanism. (Is there a way to just export everything in a package?
At least for development, I'd rather not have to both add a function
and also an export as I code new stuff...)
In the meantime, reading the hyperspec documentation for require you
read about modules. What's a module? In SBCL it's actually just asdf
systems, but I'm guessing I don't get what this is supposed to do.
At the bottom I guess you just have files that can be included in the
current image with (load "foo"). Systems are basically just wrappers
for doing (load ...) on a number of files and their dependencies.
(Ruby's gem.)
Any insight, pointers to examples, or discussion about making this
stuff better would be helpful and interesting. It feels like asdf and
asdf-install are almost there, but when compared to ruby gems and
doing
gem install foo
it's still painful. My guess is that for newbies like me it would
help A LOT to get this kind of stuff streamlined so as long as you
have SBCL installed the rest is gravy.
Thanks for the help and happy new year,
Jeff
From: Edi Weitz
Subject: Re: packages, system definitions, and file paths
Date:
Message-ID: <uodbvbsjr.fsf@agharta.de>
On Tue, 8 Jan 2008 18:45:41 -0800 (PST), Jeff <······@gmail.com> wrote:
> * How do you get the path of the current file?
See for example
http://www.lispworks.com/documentation/HyperSpec/Body/v_ld_pns.htm
http://www.lispworks.com/documentation/HyperSpec/Body/v_cmp_fi.htm
> * How do you add to the search path for require, rather than having
> to specify the exact path to a file?
There is no portable way of doing this as the behaviour of REQUIRE is
implementation-dependent.
> I'm using SBCL, but I'd like what I write to be portable. This very
> unfortunately means I can't even use
> (require 'foo)
> instead I'm relegated to the, IMHO ridiculous,
> (asdf:operate 'asdf:load-op 'foo)
Why does that seem ridiculous to you? Probably because you haven't
figured out yet that there are more operations than LOAD-OP and that
you can define your own?
Anyway, ASDF is just one of many system definition tools for CL.
Others are, for example, MK:DEFSYSTEM, Common Defsystem, and so on.
ASDF is currently the most popular one, though, especially in the open
source world, and it comes pre-loaded with a couple of Lisp
implementations.
Still, it is not 100% portable and will never be as it's not part of
the ANSI standard. Just like "make" is not part of the C standard, I
guess.
> A system is a collection of files that in turn implement packages.
No. Systems and packages are completely orthogonal. Yes, most
systems contain code that defines one or more packages and pretty
often one of these packages happens to have the same name as the
system, but you should view this is a funny coincidence. Packages are
first-class objects in the language with defined semantics, systems
aren't.
> At the bottom I guess you just have files that can be included in
> the current image with (load "foo"). Systems are basically just
> wrappers for doing (load ...) on a number of files and their
> dependencies.
System definitions can do a lot more than that. They can define,
amongst other things, how a system has to be compiled, they can define
dependencies, they can define tests, they can deal with non-Lisp stuff
like C source files or generating documentation, and so on. Look at
the system definitions of more complicated systems like McCLIM or
CLSQL to see examples.
> It feels like asdf and asdf-install are almost there, but when
> compared to ruby gems and doing
> gem install foo
> it's still painful. My guess is that for newbies like me it would
> help A LOT to get this kind of stuff streamlined so as long as you
> have SBCL installed the rest is gravy.
The fact that what you're looking for is not there is, as you can
probably infer yourself, mostly a matter of missing infrastructure.
Somebody has to set this up, like some people once started with CPAN
(or "gem", I don't know Ruby).
Lots of newbies here had the same complaints you have. They usually
either go away disappointed or they eventually reach a point where all
this isn't an issue anymore. And at that point they've usually lost
interest in improving the situation for their successor newbies.
Maybe in your case that'll be different...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
>> I'm using SBCL, but I'd like what I write to be portable. This very
>> unfortunately means I can't even use
>> (require 'foo)
>> instead I'm relegated to the, IMHO ridiculous,
>> (asdf:operate 'asdf:load-op 'foo)
>
> Why does that seem ridiculous to you? Probably because you haven't
> figured out yet that there are more operations than LOAD-OP and that
> you can define your own?
>
Well, it is a tad long. Obviously it doesn't take long to
(defun sysload (sys) (asdf:operate 'asdf:load-op sys))
yourself if your require isn't hookable, but the
(asdf:operate 'asdf:load-op :foo) thing is a bit long-winded in
interactive use.
I'm now unclear on why there wasn't a (asdf:load ...) provided that was
just defined to do that. Maybe risk of people misunderstanding the
control flow and trying to specialise the wrong thing, maybe the very
fact it is trivial to do.
Of course, on several major implementations, require IS hookable and
hooked by asdf, so I imagine most people using asdf interactively are
just typing "(require :foo)", or hey, if they're using SLIME,
doing ",l<RET>foo"
On Jan 8, 8:12 pm, Edi Weitz <········@agharta.de> wrote:
Thanks for responding. I'm using Hunchentoot and Drakma too, so
thanks for those also!
> > I'm using SBCL, but I'd like what I write to be portable. This very
> > unfortunately means I can't even use
> > (require 'foo)
> > instead I'm relegated to the, IMHO ridiculous,
> > (asdf:operate 'asdf:load-op 'foo)
>
> Why does that seem ridiculous to you? Probably because you haven't
> figured out yet that there are more operations than LOAD-OP and that
> you can define your own?
This seems to be a typical line of reasoning for convoluted API's.
I'm sure ASDF supports all kinds of wonderful functionality, but the
common operations should take as little work as possible. If 99% of
people are using asdf to compile, load and copy source, then it seems
like those should be the primary functions right? The users of the
API should not be exposed to the implementation details, such as the
fact that operations are actually objects which are specialized down
below.
(asdf:load 'my-proj)
seems nice and clear, doesn't it?
> Anyway, ASDF is just one of many system definition tools for CL.
> Others are, for example, MK:DEFSYSTEM, Common Defsystem, and so on.
> ASDF is currently the most popular one, though, especially in the open
> source world, and it comes pre-loaded with a couple of Lisp
> implementations.
>
> Still, it is not 100% portable and will never be as it's not part of
> the ANSI standard. Just like "make" is not part of the C standard, I
> guess.
I don't think ANSI standards are that relevant anyways. The
development world moves too fast for standards committees, so it seems
more important to reach community consensus so that we can get things
done without wasting time.
> > A system is a collection of files that in turn implement packages.
>
> No. Systems and packages are completely orthogonal. Yes, most
> systems contain code that defines one or more packages and pretty
> often one of these packages happens to have the same name as the
> system, but you should view this is a funny coincidence. Packages are
> first-class objects in the language with defined semantics, systems
> aren't.
> System definitions can do a lot more than that. They can define,
> amongst other things, how a system has to be compiled, they can define
> dependencies, they can define tests, they can deal with non-Lisp stuff
> like C source files or generating documentation, and so on. Look at
> the system definitions of more complicated systems like McCLIM or
> CLSQL to see examples.
Ok, thanks for the clarification.
> > It feels like asdf and asdf-install are almost there, but when
> > compared to ruby gems and doing
> > gem install foo
> > it's still painful. My guess is that for newbies like me it would
> > help A LOT to get this kind of stuff streamlined so as long as you
> > have SBCL installed the rest is gravy.
>
> The fact that what you're looking for is not there is, as you can
> probably infer yourself, mostly a matter of missing infrastructure.
> Somebody has to set this up, like some people once started with CPAN
> (or "gem", I don't know Ruby).
Ok. It seems like cliki is moving in the right direction. Does it
support plugin modules or something? Maybe if we could add some
plugins to help manage projects it could turn into what we need.
Besides that, I guess maybe having the capacity to store packages
directly on the cliki site rather than having to use third-party
servers would be good. I don't have a server to do this on, but I'd
be willing to contribute. It would probably be helpful to have a few
utilities that let you generate packaged tarballs and upload them and
things like that. Maybe this already exists and it just needs to get
integrated into ASDF?
> Lots of newbies here had the same complaints you have. They usually
> either go away disappointed or they eventually reach a point where all
> this isn't an issue anymore. And at that point they've usually lost
> interest in improving the situation for their successor newbies.
> Maybe in your case that'll be different...
That's the impression I get with a lot of the lisp world, but I see it
as much more of a problem then just something to help newbies. Easy
access to libraries and not wasting time with boiler plate code helps
everyone.
> Edi.
>
> --
>
> European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Hopefully I'll be there.
-Jeff
On Jan 10, 11:11 pm, Jeff <······@gmail.com> wrote:
> On Jan 8, 8:12 pm, Edi Weitz <········@agharta.de> wrote:
> > Anyway, ASDF is just one of many system definition tools for CL.
> > Others are, for example, MK:DEFSYSTEM, Common Defsystem, and so on.
> > ASDF is currently the most popular one, though, especially in the open
> > source world, and it comes pre-loaded with a couple of Lisp
> > implementations.
>
> > Still, it is not 100% portable and will never be as it's not part of
> > the ANSI standard. Just like "make" is not part of the C standard, I
> > guess.
>
> I don't think ANSI standards are that relevant anyways. The
> development world moves too fast for standards committees, so it seems
> more important to reach community consensus so that we can get things
> done without wasting time.
... and that's exactly what ASDF is. A third party library that
nevertheless is a de-facto standard for system management.
Cheers,
Maciej
Well you can always make it simpler (stolen from Edi Weitz's starter
pack - start.lisp)
(in-package "CL-USER")
(defun asdf (lib)
"Shortcut for ASDF."
(asdf:oos 'asdf:load-op lib))
Also another useful function (especially on Windows)
(defun update-asdf-central-registry (&optional (dir *asdf-dir*))
(dolist (dir-candidate (directory (make-pathname :name :wild
:type :wild
:defaults dir)))
(when (file-directory-p dir-candidate)
(update-asdf-central-registry dir-candidate)
(let ((asd-candidate (merge-pathnames "*.asd" dir-candidate)))
(when (directory asd-candidate)
(pushnew dir-candidate asdf:*central-registry*
:test #'equal))))))
(update-asdf-central-registry)
So everytime you add a new package (I'm putting mine in C:\LW\sp, where
sp stands for the "starter pack"), you just call
(update-asdf-central-registry) and it would rescan and update
asdf:*central-registry*
Then just do
(asdf 'some-package-name)
Works quite well, except when you have duplicate *.asd filenames, it
does not report an error, so you got to be carefull.
--=-=-=
Jeff <······@gmail.com> writes:
> This seems to be a typical line of reasoning for convoluted API's.
> I'm sure ASDF supports all kinds of wonderful functionality, but the
> common operations should take as little work as possible.
[...and on and on...]
<URL:http://svn.quadium.net/svn/asdf-op/tags/1.0/>
--=-=-=
Content-Disposition: inline
Content-Description: asdf-op.lisp
(defpackage #:net.quadium.asdf-op
(:nicknames #:asdf-op))
(in-package #:net.quadium.asdf-op)
(defun find-asdf-operations ()
(let (operations)
(do-external-symbols (symbol :asdf operations)
(let ((symbol-name (symbol-name symbol)))
(when (ignore-errors
(string-equal symbol-name "-OP"
:start1 (- (length symbol-name) 3)))
(push symbol operations))))))
(defun make-operation-wrapper (operation)
(let* ((*package* (find-package #.(package-name *package*)))
(operation-name (symbol-name operation))
(function-name (intern (subseq operation-name 0 (- (length operation-name) 3)))))
(shadow function-name)
(export function-name)
(values function-name
(setf (symbol-function function-name)
(lambda (&rest args)
(apply 'asdf:operate operation args))))))
(prog2
(unuse-package '#:common-lisp)
(common-lisp:mapcar #'make-operation-wrapper (find-asdf-operations))
(common-lisp:use-package '#:common-lisp))
--=-=-=
--
vsync
http://quadium.net/~vsync/
If language is not correct, then what is said is not what is meant; if
what is said is not what is meant, then what must be done remains
undone; if this remains undone, morals and art will deteriorate; if
justice goes astray, the people will stand about in helpless
confusion. Hence there must be no arbitrariness in what is said. This
matters above everything.
-- Confucius
--=-=-=--