ASDF: how to locate resources
in [Lisp]
|
From: Duane Rettig on 13 Mar 2010 20:32 On Mar 13, 11:12 am, Zach Beane <x...(a)xach.com> wrote: > p...(a)informatimago.com (Pascal J. Bourguignon) writes: > > > Rainer Joswig <jos...(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. This may be the case (pun intended :-). It is hard to get the :local mappings of pathnames correct for the various styles of filenames (e.g. case sensitive on Unix, and case-insensitive-preserving-original on Mac and Windows). However: > 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. Please show me such documentation - I'd like to see where you find this attitude anywhere in our docs. There are certainly places where we allow extensions to logical pathname parsing; for example, the spec doesn't allow the inclusion of underscores in a logical pathname, and so we allow an extension, if a variable is set, which allows a namestring with an underscore in it to be parsed as a logical pathname. But in reading that documentation I get no sense of "the standard seemed stupid" - it does seem very restrictive to disallow one character that occurs quite often in Unix and C names, but if we allow users to set a variable and use that character, do you consider that thumbing our nose at the spec? Duane
From: Zach Beane on 13 Mar 2010 21:15 Duane Rettig <duane(a)franz.com> writes: > On Mar 13, 11:12 am, Zach Beane <x...(a)xach.com> wrote: >> p...(a)informatimago.com (Pascal J. Bourguignon) writes: >> >> > Rainer Joswig <jos...(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. > > This may be the case (pun intended :-). It is hard to get the :local > mappings of pathnames correct for the various styles of filenames > (e.g. case sensitive on Unix, and case-insensitive-preserving-original > on Mac and Windows). It seems like this is a problem only if you want some translations to be automagic. If you are explicit with every translation, you don't have to worry local case conventions, right? > However: > >> 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. > > Please show me such documentation - I'd like to see where you find > this attitude anywhere in our docs. There are certainly places where > we allow extensions to logical pathname parsing; for example, the spec > doesn't allow the inclusion of underscores in a logical pathname, and > so we allow an extension, if a variable is set, which allows a > namestring with an underscore in it to be parsed as a logical > pathname. But in reading that documentation I get no sense of "the > standard seemed stupid" - it does seem very restrictive to disallow > one character that occurs quite often in Unix and C names, but if we > allow users to set a variable and use that character, do you consider > that thumbing our nose at the spec? I do. It defeats the purpose of a precise and complete specification of the syntax of logical pathnames. If a character appears in a physical pathname that isn't allowed in a logical pathname, it seems to me that the right reaction is to create a translation, not allow non-standard implementation-specific syntax to creep into the pathname literals in the source. Many have found this restriction onerous. Because actual work is typically done on just a few platforms, forbidding characters such as an underscore (_), which in fact causes no problems on any popular platform, contributes nothing to actual portability and adds additional development rules whose purpose (to non-Lisp programmers and to many Lisp programmers) is obscure. In particular, I find "contributes nothing to actual portability" extremely obnoxious, as breaking this restriction introduces real problems with actual portability to implementations that choose to take the spec at face value and implement it as written. Zach
From: His kennyness on 13 Mar 2010 22:14 Zach Beane wrote: > In particular, I find "contributes nothing to actual portability" > extremely obnoxious, ... Oh, OK, we are chewing the scenery foaming at the mouth over the top abusing the English language, sure, Franz is paving the way to hell and damnation for mankind and the ridiculously long red light at the corner of Ocean and Rte 35 is the end of civilization as we know it. Damn, it's fun talking this way. Al Sharpton move over! hth, hk
From: His kennyness on 13 Mar 2010 22:46 Pascal Costanza 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. What if one is distributing an application and ASDF is long gone (I'd rather say "dead and buried")? lpns then are a lispy config file. > > In other words, I still don't quite understand what problem logical > pathnames solve. But I will read the chapter in CLtL2... ISTR the ability to specify multiple possibilities was quite handy for running different ways without touching the source. On VMS with the more powerful logical names one specified a list of places to look for X, so a developer (or other experimenter) could put a substitute file early in the chain and have that be in effect for a run. I do not recall lpns going that far, but with entire directories yes. kt > >> 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? > I like a list of compile-file statements over ASDF. kt
From: Duane Rettig on 14 Mar 2010 03:03
On Mar 13, 6:15 pm, Zach Beane <x...(a)xach.com> wrote: > Duane Rettig <du...(a)franz.com> writes: > > On Mar 13, 11:12 am, Zach Beane <x...(a)xach.com> wrote: > >> p...(a)informatimago.com (Pascal J. Bourguignon) writes: > > >> > Rainer Joswig <jos...(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. > > > This may be the case (pun intended :-). It is hard to get the :local > > mappings of pathnames correct for the various styles of filenames > > (e.g. case sensitive on Unix, and case-insensitive-preserving-original > > on Mac and Windows). > > It seems like this is a problem only if you want some translations to be > automagic. If you are explicit with every translation, you don't have to > worry local case conventions, right? The "automagic" part is precisely what should be intended in the spirit of logical pathnames. Otherwise, why would you need logical pathnames over just pathnames? You could just name all of your pathnames using regular pathnames, and do all of the translations to account for operating system differences programmatically. > > However: > > >> 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. > > > Please show me such documentation - I'd like to see where you find > > this attitude anywhere in our docs. There are certainly places where > > we allow extensions to logical pathname parsing; for example, the spec > > doesn't allow the inclusion of underscores in a logical pathname, and > > so we allow an extension, if a variable is set, which allows a > > namestring with an underscore in it to be parsed as a logical > > pathname. But in reading that documentation I get no sense of "the > > standard seemed stupid" - it does seem very restrictive to disallow > > one character that occurs quite often in Unix and C names, but if we > > allow users to set a variable and use that character, do you consider > > that thumbing our nose at the spec? > > I do. It defeats the purpose of a precise and complete specification of > the syntax of logical pathnames. If a character appears in a physical > pathname that isn't allowed in a logical pathname, it seems to me that > the right reaction is to create a translation, not allow non-standard > implementation-specific syntax to creep into the pathname literals in > the source. It may seem that way to you, but many of our customers that use logical pathnames don't like that restriction at all, and do indeed use such a feature, to avoid having to mess with such translations. > Many have found this restriction onerous. Because actual work is > typically done on just a few platforms, forbidding characters such as > an underscore (_), which in fact causes no problems on any popular > platform, contributes nothing to actual portability and adds > additional development rules whose purpose (to non-Lisp programmers > and to many Lisp programmers) is obscure. > > In particular, I find "contributes nothing to actual portability" > extremely obnoxious, as breaking this restriction introduces real > problems with actual portability to implementations that choose to take > the spec at face value and implement it as written. Why should that be the case? If you want to be portable between CL implementations, don't use underscores, and don't turn on the feature that allows the nonportable code. It is exactly like any other extension to a CL implementation. If your argument is that a user who takes advantage of this extension is tied to one lisp, then that's the same kind of decision that a user must make about any other such extension. If you think the extension is a crock (and that's perfectly OK) then don't use it. Duane |