[asdf-devel] MCL issue

[Faré]

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]




On 28 May 2011 14:50, Pascal Costanza <pc at p-cos.net> wrote:
>
> On 23 May 2011, at 00:17, Faré wrote:
>
>>> The setup is not that hard. Here is what I have in my .sbclrc
>>>
>>> (setf (logical-pathname-translations "costanza")
>>>      `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl"
>>>                               (lisp-implementation-type)
>>>                               (lisp-implementation-version)))
>>>        ("**;*.*.*" "/Users/costanza/**/*.*")))
>>>
>>> This is all that is necessary, and it looks pretty much the same for all CL implementations. This can probably very easily be abstracted to make it even easier to set up.
>>>
>> But ASDF can't require each and every user to learn about
>> logical pathnames and how to set them up in their specific implementation,
>> each and every system writer to adhere to naming limitations of
>> "logical pathnames", etc. That would raise the bar to adoption, not lower it.
>
> This is only true under the assumption that what ASDF 2 adds on top of ASDF 1 is easy to learn, but that's not the case either.
>
>>> I don't have anything against the support for Unix-style pathnames,
>>> but I don't think that ASDF is the right place to define them.
>>>
>> We needed *some* syntax for relative pathnames, to allow things like
>>   (:module "baz/quux" :components ((:file "foo/bar-V1.200")))
>> And considering their limitations, logical pathnames didn't cut it.
> [...]
>
>> Please explain what you want to separate from ASDF, and how you propose
>> users of ASDF to portably specify relative pathnames.
>>
>> In the bad old days of ASDF 1, I've done my lot of
>>       (:module "foo-bar" :pathname
>>       #.(merge-pathnames (make-pathname :directory '(:relative "foo" "bar")
>> :defaults *some-directory* #| required for the :host and :device slots
>> |#) *some-directory*) ...)
>>
>> NO, THANKS! Now it's just (:module "foo/bar" ...)
>
> Why was that necessary? It was possible to say (:module "foo" (:module "bar" ...) ...) [or something similar], no?
>
>>> I know this is all difficult to set up and requires a lot of time and energy, so I also understand why you may not want to go the extra mile to work on such a separation.
>>>
>> Since you seem to be the only one here with a clue what you mean,
>> why don't you come with a proposal and/or a patch?
>
> Well, as a minimum, I have two requests to make changes in the documentation:
>
> - In Section 3.1, the documentation says the following: "The simplest way to add a path to your search path, say /home/luser/.asd-link-farm/ is to create the directory ~/.config/common-lisp/source-registry.conf.d/ and there create a file with any name of your choice but the type conf, for instance 42-asd-link-farm.conf containing the line: (:directory "/home/luser/.asd-link-farm/")"
>
> This is very confusing, because the "old style" using asdf:*central-registry* is decidedly much simpler. So the sentence above needs some explanation in what sense the "new style" is simpler.
>
>
> - Section 5.3.6 should be renamed. The main body of the text is about how to use logical pathnames with ASDF 2, and is not a "warning." The recommendation not to use logical pathnames should also be removed, because it is not substantiated (and is therefore not a "warning," because it doesn't say what the potentially bad effects of using logical pathnames are).
>
> There are advantages and disadvantages with using both either logical pathnames or the ASDF 2 approach. Any future Common Lisp implementation that claims adherence to ANSI CL will support logical pathnames, and so it will be relatively straightforward to use logical pathnames in conjunction with ASDF 2, while ASDF 2 will probably need patching in order to support such a future Common Lisp system, which can be regarded as an advantage of logical pathnames over the ASDF 2 approach.
>
> I think that statements of personal preference should not have a place in the documentation of a tool that is supposed to be used by the whole Common Lisp community, but such a documentation should rather reflect the wide range of opinions in that community.
>
>
> Pascal
>
> --
> Pascal Costanza
> The views expressed in this email are my own, and not those of my employer.
>
>
>
>