From: Stelian Ionescu on
On Sun, 07 Mar 2010 12:55:05 +0100, Pascal Costanza wrote:

> Hi,
>
> In one library, I used *load-pathname* / *load-truename* to find
> additional files to load, relative to the location where the library was
> found. This worked quite well for a couple of years. Alas, ASDF seems to
> have changed the meaning of these two variables (or something) - they
> now refer to some automatically created cache directory, where the
> resources I'm looking for are, of course, not available. This happened
> to me with the new release of ECL that was released two days ago, which
> includes a newer version of ASDF.
>
> So: What's the recommended way to locate such resources? (In my
> particular case, it's .lisp files in a subfolder, to be loaded and
> evaluated by the library - they cannot be declared as part of the system
> definition, but have to be found in that folder.)
>
> Any hints are appreciated.
>
> Thanks,
> Pascal

For example,

(truename
(asdf:system-definition-pathname
(asdf:find-system :closer-mop)))

yields #P"/usr/share/common-lisp/source/closer-mop/closer-mop.asd" here.
You can then merge that with the pathname of your resource file relative
to the .asd

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
From: Pascal Costanza on
On 08/03/2010 14:35, Stelian Ionescu wrote:
> On Sun, 07 Mar 2010 12:55:05 +0100, Pascal Costanza wrote:
>
>> Hi,
>>
>> In one library, I used *load-pathname* / *load-truename* to find
>> additional files to load, relative to the location where the library was
>> found. This worked quite well for a couple of years. Alas, ASDF seems to
>> have changed the meaning of these two variables (or something) - they
>> now refer to some automatically created cache directory, where the
>> resources I'm looking for are, of course, not available. This happened
>> to me with the new release of ECL that was released two days ago, which
>> includes a newer version of ASDF.
>>
>> So: What's the recommended way to locate such resources? (In my
>> particular case, it's .lisp files in a subfolder, to be loaded and
>> evaluated by the library - they cannot be declared as part of the system
>> definition, but have to be found in that folder.)
>>
>> Any hints are appreciated.
>>
>> Thanks,
>> Pascal
>
> For example,
>
> (truename
> (asdf:system-definition-pathname
> (asdf:find-system :closer-mop)))
>
> yields #P"/usr/share/common-lisp/source/closer-mop/closer-mop.asd" here.
> You can then merge that with the pathname of your resource file relative
> to the .asd

Thanks a lot indeed, this is exactly what I need!


Best,
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/
From: Pascal Costanza on
On 07/03/2010 17:37, joswig(a)corporate-world.lisp.de wrote:
> On 7 Mrz., 12:55, Pascal Costanza<p...(a)p-cos.net> wrote:
>> Hi,
>>
>> In one library, I used *load-pathname* / *load-truename* to find
>> additional files to load, relative to the location where the library was
>> found. This worked quite well for a couple of years. Alas, ASDF seems to
>> have changed the meaning of these two variables (or something) - they
>> now refer to some automatically created cache directory, where the
>> resources I'm looking for are, of course, not available. This happened
>> to me with the new release of ECL that was released two days ago, which
>> includes a newer version of ASDF.
>>
>> So: What's the recommended way to locate such resources? (In my
>> particular case, it's .lisp files in a subfolder, to be loaded and
>> evaluated by the library - they cannot be declared as part of the system
>> definition, but have to be found in that folder.)
>>
>> Any hints are appreciated.
>
> Time to use another defsystem + logical pathnames?

Maybe. Last time I checked logical pathnames, I found them hard to
understand, and I didn't quite understand what problem they solved. Is
there a good resource to read about them? Does Peter Seibel describe
them in his book?


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/
From: Zach Beane on
Pascal Costanza <pc(a)p-cos.net> writes:

> Last time I checked logical pathnames, I found them hard to
> understand, and I didn't quite understand what problem they solved. Is
> there a good resource to read about them? Does Peter Seibel describe
> them in his book?

I've been researching logical pathnames recently. There is no logical
pathname info in Practical Common Lisp, but CLTL2 has the best info I've
seen so far. It explains the rationale and possible use cases fairly
well.

Zach
From: Rainer Joswig on
In article <801g7sFm8vU2(a)mid.individual.net>,
Pascal Costanza <pc(a)p-cos.net> wrote:

> On 07/03/2010 17:37, joswig(a)corporate-world.lisp.de wrote:
> > On 7 Mrz., 12:55, Pascal Costanza<p...(a)p-cos.net> wrote:
> >> Hi,
> >>
> >> In one library, I used *load-pathname* / *load-truename* to find
> >> additional files to load, relative to the location where the library was
> >> found. This worked quite well for a couple of years. Alas, ASDF seems to
> >> have changed the meaning of these two variables (or something) - they
> >> now refer to some automatically created cache directory, where the
> >> resources I'm looking for are, of course, not available. This happened
> >> to me with the new release of ECL that was released two days ago, which
> >> includes a newer version of ASDF.
> >>
> >> So: What's the recommended way to locate such resources? (In my
> >> particular case, it's .lisp files in a subfolder, to be loaded and
> >> evaluated by the library - they cannot be declared as part of the system
> >> definition, but have to be found in that folder.)
> >>
> >> Any hints are appreciated.
> >
> > Time to use another defsystem + logical pathnames?
>
> Maybe. Last time I checked logical pathnames, I found them hard to
> understand, and I didn't quite understand what problem they solved. Is
> there a good resource to read about them? Does Peter Seibel describe
> them in his book?


Logical pathnames are location and operating system independent
IDs for files and directories. Similar to URNs in the web area -
but more primitive.

Let's say you have a drawing editor called DRED
and you have a logical pathname host DRED.

DRED uses a bunch of directories:

dred:src; for the sources
dred:bin; for binaries
dred:fonts; for special fonts
dred:forms; for various graphical forms
dred:forms;icons; for various icons
dred:examples; for various examples

and more...

For the simple case one loads a file that sets the logical
pathname translations. The trivial version is something like
this:

(setf (logical-pathname-translations "DRED")
`(("dred:**;*.*" ,(compute-your-pathname-here))))

Where (compute-your-pathname-here) returns something like:

"/Lisp/software/dred/**/*.*" on a Mac

or

"rj-vlm:>software>dred>**>*.*" on a Lisp Machine

or a pathname under Windows ...

On a Lisp Machine one has a registry directory for
logical hosts and systems. Whenever I first use
a logical host, it loads the corresponding
translation via the registry (the sys;site; directory,
itself a logical pathname directory).

So once that is set up, you can refer to files
of your software everywhere the same way.

dred:src;color;chooser.lisp stays the same.

Wherever you work, (ed "dred:src;color;chooser.lisp") will
edit that file. Independent where it is in the directory
or the network (if your machine can access remote files).

Now the system definition should then be done with logical pathnames:

(my-defsystem dred ()
(:serial "dred:src;package"
"dred:src:macros"
"dred:src;drawing"
...
))

The defsystem then should call LOAD and COMPILE-SYSTEM
with the logical pathnames, so that the source locations
also will be recorded with logical pathnames.
Then you can load the fasls and press M-. on a symbol
and the editor will load the source - independent of
where you are running the code.

If you have some additional lisp files to load and you
know that they are in the contrib subdirectory of DRED, then
do for example
(map nil 'load (directory "dred:contrib;*.lisp")).

Given that you have a logical pathname and a translation,
then locating any piece of your software is easy.


You don't need that when

* you don't share software with other people
* you have only one computer, one file system, one OS
* you want to compute pathnames on your own

Remaining problems:

* there are restrictions to logical pathnames on various Lisps
* the interpretation of logical pathnames can be slightly different

For the better implementations it works okay, though.

Not sure if ASDF supports this or if it makes
sense for it - I mostly don't use ASDF.

--
http://lispm.dyndns.org/