From: Stelian Ionescu on 8 Mar 2010 08:35 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 13 Mar 2010 07:49 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 13 Mar 2010 07:54 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 13 Mar 2010 10:21 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 13 Mar 2010 11:07
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/ |