ASDF: how to locate resources
in [Lisp]
|
From: Pascal Costanza on 13 Mar 2010 16:38 On 13/03/2010 16:21, Zach Beane wrote: > 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. OK, thanks. I will take a look at it... 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: Rainer Joswig on 13 Mar 2010 16:42 In article <87tyskot3e.fsf(a)galatea.lan.informatimago.com>, pjb(a)informatimago.com (Pascal J. Bourguignon) wrote: > Zach Beane <xach(a)xach.com> writes: > > > pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > > > >> Rainer Joswig <joswig(a)lisp.de> writes: > > > >>> 19.3.1.1.7 > >>> > >>> When parsing words and wildcard-words, > >>> lowercase letters are translated to uppercase. > >> > >> All right. So logical pathnames are case insensitive. Good to know. > >> Thanks. > > > > Last time I checked, Allegro CL gets this wrong. In fact, their > > documentation on logical pathnames reeks of "this part of the standard > > seemed stupid so we made it easy to make incompatible use of them." It > > dismays me. > > Yes, it is indeed Allegro CL behavior that made me think it was case > sensitive. Lisp Machine: Command: "http:server;url.lisp" "http:server;url.lisp" Command: (pathname *) #P"HTTP:SERVER;URL.LISP" Command: (translate-logical-pathname *) #P"RJNXP:>rel-8-3>sys>http>server>url.lisp" Btw., the Lisp Machine file system usually is case insensitive, case preserving. Just like the default of HFS+ on the Mac. LispWorks on my Mac: CL-USER 228 > "http:server;url.lisp" "http:server;url.lisp" CL-USER 229 > (pathname *) #P"HTTP:SERVER;URL.LISP" CL-USER 230 > (translate-logical-pathname *) #P"/Lisp/cl-http/cl-http-380/server/url.lisp" Parsing the string to a logical pathname object, converts the characters to uppercase. Translating the logical pathname to a physical pathname may do a lot of things. It can convert the characters to the preferred case for example. Lowercase, probably. It can shorten the name for filesystems with limited name lengths, it can shorten the extension for filesystems with limited extension lengths, and more... If the extension is "LISP" and the file system only has 3 character long extensions, it may also abbreviate it for the physical pathname to the preferred extension "lsp" . -- http://lispm.dyndns.org/
From: Pascal Costanza on 13 Mar 2010 16:44 On 13/03/2010 17:07, Rainer Joswig wrote: > 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 ... To me, this seems exactly the wrong way around. I don't want to set up anything. What I do know is that my library distribution contains a subfolder "tests" with lisp source files to be loaded and evaluated by the library. ASDF gives me a path to the location of the system definition, and then I can just refer to that subfolder. It seems to me that with logical pathnames, I would have to require users to configure where they put the library, which seems a lot less reliable to me. In other words, I still don't quite understand what problem logical pathnames solve. But I will read the chapter in CLtL2... > Not sure if ASDF supports this or if it makes > sense for it - I mostly don't use ASDF. Which system definition facility does this better? 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: Rainer Joswig on 13 Mar 2010 17:03 In article <802fa0F9gcU1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 13/03/2010 17:07, Rainer Joswig wrote: > > 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 ... > > To me, this seems exactly the wrong way around. I don't want to set up > anything. What I do know is that my library distribution contains a > subfolder "tests" with lisp source files to be loaded and evaluated by > the library. ASDF gives me a path to the location of the system > definition, and then I can just refer to that subfolder. It seems to me > that with logical pathnames, I would have to require users to configure > where they put the library, which seems a lot less reliable to me. I think you missed the part where I mentioned that the logical pathname can, in the primitive case, be automagically configured when loading the software or when loading the library. > In other words, I still don't quite understand what problem logical > pathnames solve. Machine, OS and host independent pathnames. In your Lisp software you then never have to use physical pathnames. On every machine you can do (compile-file "dred:src;rectangle.lisp") . No need to remember where the file actually is on this particular machine. What is so difficult to understand? DOS/Windows/Mac/Unix/VMS/... all have different pathname semantics. All have different file system layouts (user home directories, fonts, applications, libraries, tmp directories, help files, ...). Logical pathname give you a independent way to specify pathnames and a resolution mechanism to find the actual physical pathname on the Lisp/OS/Filesystem combination you are using. > But I will read the chapter in CLtL2... > > > Not sure if ASDF supports this or if it makes > > sense for it - I mostly don't use ASDF. > > Which system definition facility does this better? Don't know. I can't compare it. I'm using platform specific defsystems or mk-defsystem. > > > Pascal -- http://lispm.dyndns.org/
From: Pascal J. Bourguignon on 13 Mar 2010 17:06
Pascal Costanza <pc(a)p-cos.net> writes: > To me, this seems exactly the wrong way around. I don't want to set up > anything. What I do know is that my library distribution contains a > subfolder "tests" with lisp source files to be loaded and evaluated by > the library. Then you should indeed only use physical pathnames. > ASDF gives me a path to the location of the system > definition, and then I can just refer to that subfolder. It seems to > me that with logical pathnames, I would have to require users to > configure where they put the library, which seems a lot less reliable > to me. It would actually be impossible, in general. (Unless you declare a logical pathname translation for each of the physical pathnames). > In other words, I still don't quite understand what problem logical > pathnames solve. But I will read the chapter in CLtL2... The problem it solves is: Access to some files with portable and easy to write pathnames. You could access some files portably using the various pathname functions including make-pathname and merge-pathnames, but their portable use is complex. You could use the easy to write physical pathnames or namestrings, but they wouldn't be portable. If you want both, you want logical pathnames. Note that accessing ALL the files present in a file system is hard to do using logical pathnames. For this, you would have to define a mapping from logical pathnames to each of the physical pathnames. If you want to write a program that must deal with an existing file system, then you must use physical pathnames. On the other hand, if you want to access files portably, using pathnames, without caring about their exact physical name, or accepting restrictions on their physical names, then logical pathnames will do nicely. -- __Pascal Bourguignon__ |