(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Gary King wrote:
(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
Gary,
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
Best, r
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
why with an asdf:oos? why not just incorporate the functionality into asdf? (possibly with such default values that preserve the current, imho bad, practice of writing .fasl files all around the disk)
just my 0.02,
Attila Lendvai wrote:
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
why with an asdf:oos? why not just incorporate the functionality into asdf? (possibly with such default values that preserve the current, imho bad, practice of writing .fasl files all around the disk)
just my 0.02,
I think what you suggest would be even better; I just hesitated to suggest it because there's been a tendency (I think correct) towards conservatism in ASDF development.
I have been using A-B-L for years, and I rely on it heavily. It has always been dead reliable for me. I'd be delighted to see it folded in.
Especially since it relies on un-exported aspects of ASDF, and is so bound very tightly with the core of ASDF.
R
hello;
i recall, that we have started down this path before, but we never got very far, so i would like to pick up the thread again:
what exactly fails (or is just inconsistent) in the respective logical pathname implementations to preclude accomplishing the same thing with logical pathnames? whatever that may be, why is it better to re-implement the functionality for asdf rather than to fix the problem?
On 2009-09-09, at 14:39 , Robert Goldman wrote:
Gary King wrote:
(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
Gary,
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
Best, r
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
james anderson wrote:
hello;
i recall, that we have started down this path before, but we never got very far, so i would like to pick up the thread again:
what exactly fails (or is just inconsistent) in the respective logical pathname implementations to preclude accomplishing the same thing with logical pathnames? whatever that may be, why is it better to re-implement the functionality for asdf rather than to fix the problem?
Two things rule out logical pathnames as a solution for this problem:
1. They don't actually solve the problem --- in order to get what you want you'd still need to have logic that redirects the binary files to different directories. I.e., we'd have to add logic to differentially define logical pathnames for binaries depending on features of the lisp implementation and then we'd have to add logic to methods for output-files. Gary's A-B-L just fixes this with methods for output-files. So it's a simpler solution and more portable.
2. Logical pathnames are defined in ANSI CL to use case-flattened pathnames. That means they are an extremely poor fit for modern case-sensitive file systems. Some number of existing ASDF systems would break because their directory structures contain case-sensitive pathnames. From the Hyperspec grammar for logical pathname namestrings (section 19.3.1):
"word---one or more uppercase letters, digits, and hyphens."
As long as SBCL hews to the letter of the ANSI spec for logical pathnames, I regard logical pathnames as useless in portable code. I now use them only in code that, for one reason or another, will only run in ACL. [Note that this is /not/ meant as a criticism of the SBCL policy.]
So Gary's existing solution is (a) more portable; (b) simpler; and (c) less damaging to existing ASDF systems; (d) it's done and (e) it's extensively tested in the wild.
I think the only question is whether we should make A-B-L optional as now (but distribute it with stock ASDF) or, as Attila suggests, integrate it fully, but configure it so that it behaves as current stock ASDF.
Best, R
On 2009-09-09, at 14:39 , Robert Goldman wrote:
Gary King wrote:
(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
Gary,
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
Best, r
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Note that I have been maintaining my variant of A-B-L as part of cl-launch, and upon noticing that resolve-symlinks had been removed, I immediately issued a new release 2.23 of cl-launch.
I for one would welcome A-B-L becoming part of ASDF, so I could have cl-launch just use that (after a transition period).
I agree that logical pathnames are indeed broken as specified, and that since at least SBCL enforces the specification, they shouldn't be used.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] To stay young requires unceasing cultivation of the ability to unlearn old falsehoods. -- Robert Heinlein, "Time Enough For Love"
2009/9/9 Robert Goldman rpgoldman@sift.info:
james anderson wrote:
hello;
i recall, that we have started down this path before, but we never got very far, so i would like to pick up the thread again:
what exactly fails (or is just inconsistent) in the respective logical pathname implementations to preclude accomplishing the same thing with logical pathnames? whatever that may be, why is it better to re-implement the functionality for asdf rather than to fix the problem?
Two things rule out logical pathnames as a solution for this problem:
- They don't actually solve the problem --- in order to get what you
want you'd still need to have logic that redirects the binary files to different directories. I.e., we'd have to add logic to differentially define logical pathnames for binaries depending on features of the lisp implementation and then we'd have to add logic to methods for output-files. Gary's A-B-L just fixes this with methods for output-files. So it's a simpler solution and more portable.
- Logical pathnames are defined in ANSI CL to use case-flattened
pathnames. That means they are an extremely poor fit for modern case-sensitive file systems. Some number of existing ASDF systems would break because their directory structures contain case-sensitive pathnames. From the Hyperspec grammar for logical pathname namestrings (section 19.3.1):
"word---one or more uppercase letters, digits, and hyphens."
As long as SBCL hews to the letter of the ANSI spec for logical pathnames, I regard logical pathnames as useless in portable code. I now use them only in code that, for one reason or another, will only run in ACL. [Note that this is /not/ meant as a criticism of the SBCL policy.]
So Gary's existing solution is (a) more portable; (b) simpler; and (c) less damaging to existing ASDF systems; (d) it's done and (e) it's extensively tested in the wild.
I think the only question is whether we should make A-B-L optional as now (but distribute it with stock ASDF) or, as Attila suggests, integrate it fully, but configure it so that it behaves as current stock ASDF.
Best, R
On 2009-09-09, at 14:39 , Robert Goldman wrote:
Gary King wrote:
(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
Gary,
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
Best, r
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
On 2009-09-09, at 16:27 , Robert Goldman wrote:
james anderson wrote:
hello;
i recall, that we have started down this path before, but we never got very far, so i would like to pick up the thread again:
what exactly fails (or is just inconsistent) in the respective logical pathname implementations to preclude accomplishing the same thing with logical pathnames? whatever that may be, why is it better to re-implement the functionality for asdf rather than to fix the problem?
Two things rule out logical pathnames as a solution for this problem:
- They don't actually solve the problem --- in order to get what you
want you'd still need to have logic that redirects the binary files to different directories. I.e., we'd have to add logic to differentially define logical pathnames for binaries depending on features of the lisp implementation and then we'd have to add logic to methods for output-files. Gary's A-B-L just fixes this with methods for output-files. So it's a simpler solution and more portable.
as i understand this statement, it is not accurate. while one does need the logic, one would not "still" need it. one specifies the mapping with the logical host definition. the logic is equivalent to that which abl implements. it is just realized in the pathname translation mechanism.
- Logical pathnames are defined in ANSI CL to use case-flattened
pathnames. That means they are an extremely poor fit for modern case-sensitive file systems. Some number of existing ASDF systems would break because their directory structures contain case-sensitive pathnames. From the Hyperspec grammar for logical pathname namestrings (section 19.3.1):
"word---one or more uppercase letters, digits, and hyphens."
As long as SBCL hews to the letter of the ANSI spec for logical pathnames, I regard logical pathnames as useless in portable code. I now use them only in code that, for one reason or another, will only run in ACL. [Note that this is /not/ meant as a criticism of the SBCL policy.]
is it perhaps time to deal with this as a community, rather that each asserting that they know better?
So Gary's existing solution is (a) more portable; (b) simpler; and (c) less damaging to existing ASDF systems; (d) it's done and (e) it's extensively tested in the wild.
I think the only question is whether we should make A-B-L optional as now (but distribute it with stock ASDF) or, as Attila suggests, integrate it fully, but configure it so that it behaves as current stock ASDF.
Best, R
On 2009-09-09, at 14:39 , Robert Goldman wrote:
Gary King wrote:
(cc'd to list)
Damn. The function disappeared recently (by my hand). I didn't realize (obviously) that it was used. I'll fix.
Gary,
Maybe this would be a good time to push A-B-L into the ASDF repository? I've always been in favor of this, acnyway, since it's such a critical extension. IMO it would be great if anyone who had ASDF could also get A-B-L with no more work than a call to asdf:oos.
Best, r
On Sep 8, 2009, at 11:17 PM, Robert Goldman wrote:
I just updated, and now can't start up lisp because asdf-binary-locations calls ASDF::RESOLVE-SYMLINKS which seems to have vanished from asdf.lisp.
Any insight?
r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
james anderson wrote:
On 2009-09-09, at 16:27 , Robert Goldman wrote:
james anderson wrote:
hello;
i recall, that we have started down this path before, but we never got very far, so i would like to pick up the thread again:
what exactly fails (or is just inconsistent) in the respective logical pathname implementations to preclude accomplishing the same thing with logical pathnames? whatever that may be, why is it better to re-implement the functionality for asdf rather than to fix the problem?
Two things rule out logical pathnames as a solution for this problem:
- They don't actually solve the problem --- in order to get what you
want you'd still need to have logic that redirects the binary files to different directories. I.e., we'd have to add logic to differentially define logical pathnames for binaries depending on features of the lisp implementation and then we'd have to add logic to methods for output-files. Gary's A-B-L just fixes this with methods for output-files. So it's a simpler solution and more portable.
as i understand this statement, it is not accurate. while one does need the logic, one would not "still" need it. one specifies the mapping with the logical host definition. the logic is equivalent to that which abl implements. it is just realized in the pathname translation mechanism.
- Logical pathnames are defined in ANSI CL to use case-flattened
pathnames. That means they are an extremely poor fit for modern case-sensitive file systems. Some number of existing ASDF systems would break because their directory structures contain case-sensitive pathnames. From the Hyperspec grammar for logical pathname namestrings (section 19.3.1):
"word---one or more uppercase letters, digits, and hyphens."
As long as SBCL hews to the letter of the ANSI spec for logical pathnames, I regard logical pathnames as useless in portable code. I now use them only in code that, for one reason or another, will only run in ACL. [Note that this is /not/ meant as a criticism of the SBCL policy.]
is it perhaps time to deal with this as a community, rather that each asserting that they know better?
Probably, but I don't think we should wait to get the function that A-B-L provides until we have fixed logical pathnames. At the expense of being flip, that's like saying "we'll wait until the Messiah comes." Especially given how many years the community has been saying "what comes after the ANSI standard?"
Best, Robert
On 2009-09-09, at 17:54 , Robert Goldman wrote:
james anderson wrote:
[...]
- Logical pathnames are defined in ANSI CL to use case-flattened
pathnames. That means they are an extremely poor fit for modern case-sensitive file systems. Some number of existing ASDF systems would break because their directory structures contain case-sensitive pathnames. From the Hyperspec grammar for logical pathname namestrings (section 19.3.1):
"word---one or more uppercase letters, digits, and hyphens."
As long as SBCL hews to the letter of the ANSI spec for logical pathnames, I regard logical pathnames as useless in portable code. I now use them only in code that, for one reason or another, will only run in ACL. [Note that this is /not/ meant as a criticism of the SBCL policy.]
is it perhaps time to deal with this as a community, rather that each asserting that they know better?
Probably, but I don't think we should wait to get the function that A-B-L provides until we have fixed logical pathnames. At the expense of being flip, that's like saying "we'll wait until the Messiah comes." Especially given how many years the community has been saying "what comes after the ANSI standard?"
there are now at least two re-implementations of (at least some aspects of) logical pathnames: a-b-l and fare's. in each case, because of the belief, that the language offered no alternative. i suggest that it is not only flip, but short-sighted, to exaggerate any impediments so as to render the problem unassailable.
has anyone ever tried to specify a form of logical pathname which would suffice for their use cases. are the only real issues the case- folding and the word constituents? i ask, as i've found that, exactly by observing those limitations, recent runtime implementations are sufficiently consistent to portably define logical hosts for use with asdf.
-
Attila Lendvai -
Faré -
Gary King -
james anderson -
Robert Goldman