Hi, ASDF developers Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more. I updated to latest ASDF 2 and compile/load it into MCL (my current version is 6.0, but 5.2.1 has the same problem): ? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket)
Error: Not an absolute pathname: #4P"home:" While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT Type Command-. to abort. See the Restarts… menu item for further choices. 1 >
I don't know what does ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT try to do, but I see a fact that MCL's standard function USER-HOMEDIR-PATHNAME can only return the MCL installation directory but current Mac user's home directory: ? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:" I think above function should return #P"Macintosh HD:Users:binghe:" instead. And I see ASDF depend on USER-HOMEDIR-PATHNAME, so that there's no way to store compiled fasls into "~/.cache/common-lisp" ... Regards, Chun Tian (binghe)
I found a workaround for myself: (in-package :asdf) (defun user-homedir () #P"Macintosh HD:Users:binghe:") with above code loaded as a ASDF patch, I can load other packages well. --binghe 在 2011-5-18，13:05， Chun Tian (binghe) 写道：
Hi, ASDF developers
Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more.
I updated to latest ASDF 2 and compile/load it into MCL (my current version is 6.0, but 5.2.1 has the same problem):
? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket)
Error: Not an absolute pathname: #4P"home:" While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT Type Command-. to abort. See the Restarts… menu item for further choices. 1 >
I don't know what does ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT try to do, but I see a fact that MCL's standard function USER-HOMEDIR-PATHNAME can only return the MCL installation directory but current Mac user's home directory:
? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:"
I think above function should return #P"Macintosh HD:Users:binghe:" instead. And I see ASDF depend on USER-HOMEDIR-PATHNAME, so that there's no way to store compiled fasls into "~/.cache/common-lisp" ...
Regards,
Chun Tian (binghe)
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
with above code loaded as a ASDF patch, I can load other packages well.
As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly. Isn't that right?
--binghe
在 2011-5-18，13:05， Chun Tian (binghe) 写道：
Hi, ASDF developers
Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more.
I updated to latest ASDF 2 and compile/load it into MCL (my current version is 6.0, but 5.2.1 has the same problem):
? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket)
Error: Not an absolute pathname: #4P"home:" While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT Type Command-. to abort. See the Restarts… menu item for further choices. 1 >
I don't know what does ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT try to do, but I see a fact that MCL's standard function USER-HOMEDIR-PATHNAME can only return the MCL installation directory but current Mac user's home directory:
? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:"
I think above function should return #P"Macintosh HD:Users:binghe:" instead. And I see ASDF depend on USER-HOMEDIR-PATHNAME, so that there's no way to store compiled fasls into "~/.cache/common-lisp" ...
Regards,
Chun Tian (binghe)
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Dear binghe, first, which version of ASDF are you using? I added RMCL support in 2.012.3. Please run with the latest ASDF (currently 2.015.3), and comment out your (otherwise nice) workaround, to check whether ASDF runs out of the box. I don't have RMCL, but I'm willing to patch ASDF further to support it.
? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:"
This is a known limitation of MCL.
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
Nice workaround — but can we replace it with something portable? Is there a way in RMCL to detect the actual home directory? Maybe with a call out to C?
? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket)
Error: Not an absolute pathname: #4P"home:" While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT Type Command-. to abort. See the Restarts… menu item for further choices. 1 > If error persists with the latest ASDF, can you get a backtrace?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The best place to find a helping hand is at the end of your own arm.
On 18 May 2011, at 15:28, Robert Goldman wrote:
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
with above code loaded as a ASDF patch, I can load other packages well.
As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.
Isn't that right?
No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL. MCL (and thus RMCL) were originally developed for Mac OS 9 and older. In those operating systems, the notion of a user directory didn't exist, so the user-homedir-pathname function doesn't have any meaning there, and is allowed by ANSI CL to be implementation-dependent, so MCL does something that seems arbitrary to non-MCL users, but has a meaning for MCL users. RMCL's existence is justified to be able to run code that was originally developed for MCL, so changing the meaning of user-homedir-pathname would unnecessarily break existing applications (and it seems that there are considerably more users than some people seem to assume). It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:
On 18 May 2011, at 15:28, Robert Goldman wrote:
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
with above code loaded as a ASDF patch, I can load other packages well.
As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.
Isn't that right?
No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.
I was not very careful here. The meaning of U-H-D is *not* underspecified when the host is provided as an (optional) argument. If we were providing our host as an argument to the function, then I believe the MCL behavior would be clearly buggy, since the spec says: "The definition of home directory is implementation-dependent, but defined in Common Lisp to mean the directory where the user keeps personal files such as initialization files and mail." I don't think that the MCL behavior of supplying the installation directory of the lisp implementation is defensible in light of the above language. *HOWEVER*, the behavior is allowed to be more implementation specific in the case where we do not provide the host as an argument, so in that sense what MCL does is defensible. ... Unfortunately, I don't believe that there is a specified way to indicate a host, so AFAICT, there is no portable way to provide a host argument to U-H-D, which makes it somewhat perverse to make this the case where the behavior is defined!
It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days.
Point taken, but I think this is unfair to ASDF. This seems more like a case where (as with many things involving interaction with filenames and directories) the ANSI standard doesn't give us any /specified/ features that fill a very real need. So we necessarily rely on underspecified features. What are the /specified/ features that will fill this need? Indeed, one of the things that ASDF does is provide a POSIX-ish portable file system sub-system precisely because the specified facilities (pathnames, logical pathnames) didn't do the job. Best, r
On 19 May 2011, at 20:58, Robert Goldman wrote:
On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:
On 18 May 2011, at 15:28, Robert Goldman wrote:
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
(in-package :asdf)
(defun user-homedir () #P"Macintosh HD:Users:binghe:")
with above code loaded as a ASDF patch, I can load other packages well.
As I read this, it's simply a bug in MCL --- they just aren't implementing user-homedir-pathname properly.
Isn't that right?
No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.
I was not very careful here. The meaning of U-H-D is *not* underspecified when the host is provided as an (optional) argument. If we were providing our host as an argument to the function, then I believe the MCL behavior would be clearly buggy, since the spec says:
"The definition of home directory is implementation-dependent, but defined in Common Lisp to mean the directory where the user keeps personal files such as initialization files and mail."
There is no such directory in pre Mac OS X.
I don't think that the MCL behavior of supplying the installation directory of the lisp implementation is defensible in light of the above language.
OK, in this case I was not careful. Here is what the documentation says: When Macintosh Common Lisp is run, two logical hosts are set up automatically: * The host "ccl" is set to the directory holding the MCL application. * The host "home" is set to the directory holding the document that was launched with Macintosh Common Lisp. user-homedir-pathname returns #P"home:" which points to wherever you started MCL from (for example, by double-clicking on some .lisp file).
It would be good if ASDF wouldn't rely on such underspecified features, or if it would have a way to deal with the lack of such features in a more meaningful way because, for example, this may not be the last time in history that the notion of a user directory isn't supported or, as another example, that pathnames look different from the usual Unix flavors that you see these days.
Point taken, but I think this is unfair to ASDF. This seems more like a case where (as with many things involving interaction with filenames and directories) the ANSI standard doesn't give us any /specified/ features that fill a very real need. So we necessarily rely on underspecified features. What are the /specified/ features that will fill this need?
Indeed, one of the things that ASDF does is provide a POSIX-ish portable file system sub-system precisely because the specified facilities (pathnames, logical pathnames) didn't do the job.
Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell (but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...) Pascal -- Pascal Costanza
On 5/19/11 May 19 -2:12 PM, Pascal Costanza wrote:
On 19 May 2011, at 20:58, Robert Goldman wrote:
On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:
On 18 May 2011, at 15:28, Robert Goldman wrote:
On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
I found a workaround for myself:
.....
Indeed, one of the things that ASDF does is provide a POSIX-ish portable file system sub-system precisely because the specified facilities (pathnames, logical pathnames) didn't do the job.
Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell (but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)
One undesirable feature is their refusal to permit filenames containing underscores or spaces: word---one or more uppercase letters, digits, and hyphens. I have also found that in practice merge-pathnames works inconsistently across lisp implementations. Those inconsistencies seem acceptable within the scope of the ANSI spec. This is actually something that is true of pathnames in general, and not just logical pathnames. I believe that this is part of the reason that Faré moved to his own POSIX-y pathnames. Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another. I, for one, welcome Fare replacing them inside ASDF2... Best, r
: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell
Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other — or be absent or not well supported. In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.
If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.
(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)
Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?
: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:
word---one or more uppercase letters, digits, and hyphens.
And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.
I have also found that in practice merge-pathnames works inconsistently across lisp implementations. Those inconsistencies seem acceptable within the scope of the ANSI spec. This is actually something that is true of pathnames in general, and not just logical pathnames. I believe that this is part of the reason that Faré moved to his own POSIX-y pathnames.
CL Pathnames are a pile of FAIL. Implementors try to save the day, each in his own way, incompatible with what other implementors do. ASDF papers somewhat over the fail with its own syntactic abstraction layer.
Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another. I, for one, welcome Fare replacing them inside ASDF2...
Thank you! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Trillions of fossils can't be wrong!
On 5/19/11 May 19 -2:57 PM, Faré wrote:
: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell
Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other — or be absent or not well supported. In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.
If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.
(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)
Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?
: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:
word---one or more uppercase letters, digits, and hyphens.
And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.
Whereas ACL being the commercial, we don't please the customer by nagging him, easygoing dude that he is, lets me write very useful (to me) logical pathname definitions that then blow up spectacularly when the language lawyer SBCL gets her hands on them.... If you use multiple lisp implementations, I'm now convinced that using logical pathnames is tantamount to taking a big pile of hours, putting them in an ashtray, and setting fire to them.
If you use multiple lisp implementations, I'm now convinced that using logical pathnames is tantamount to taking a big pile of hours, putting them in an ashtray, and setting fire to them.
However, if you are only ever, ever, ever going to use but one implementation, then feel free to use "portable" pathnames and other forms of non-portable pathnames to your heart's content. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There's no worse blasphemy than to claim authority on telling what pleases or displeases God. Hence prophets and priests are the most impious men on earth.
On 19 May 2011, at 22:13, Robert Goldman wrote:
On 5/19/11 May 19 -2:57 PM, Faré wrote:
: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell
Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other — or be absent or not well supported. In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.
If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.
(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)
Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?
: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:
word---one or more uppercase letters, digits, and hyphens.
And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.
Whereas ACL being the commercial, we don't please the customer by nagging him, easygoing dude that he is, lets me write very useful (to me) logical pathname definitions that then blow up spectacularly when the language lawyer SBCL gets her hands on them....
If you use multiple lisp implementations, I'm now convinced that using logical pathnames is tantamount to taking a big pile of hours, putting them in an ashtray, and setting fire to them.
I tried to use the mechanism promoted by ASDF. It worked in 7 out of 8 Common Lisp implementations that I have checked. Unfortunately, it didn't work in the eighth one at all, no matter what I tried. This has cost me quite some time that was eventually wasted. I then invested the time to learn logical pathnames, and came up with a solution that works in 8 out of 8 Common Lisp implementations. So my experience is exactly the opposite of yours. I'm just the messenger. I don't understand why I get attacked for delivering the message. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
I tried to use the mechanism promoted by ASDF. It worked in 7 out of 8 Common Lisp implementations that I have checked. Unfortunately, it didn't work in the eighth one at all, no matter what I tried. This has cost me quite some time that was eventually wasted.
I apologize for any such bug. What mechanism are you talking about, which implementation did it fail on, and how may we help you with it? Communication is a two-way street, and we can't fix your problems if you don't communicate about them. I now see that there was an issue about RMCL that didn't get fixed in my attempt in january, and that in the long email discussion that took place I missed one of your complaints. Please keep complaining if there is anything we miss. It sometimes helps to start a new discussion with a specific complaint, rather than respond to a long earlier discussion that started with a different complaint, even when the two complaints are somehow related.
I then invested the time to learn logical pathnames, and came up with a solution that works in 8 out of 8 Common Lisp implementations. So my experience is exactly the opposite of yours.
I'm just the messenger. I don't understand why I get attacked for delivering the message.
Logical pathnames work well as long as all your files follow the naming restrictions. Which is not the case for all CL programs and libraries, even less so when you're integrating with other languages and their naming conventions, or (shudder) files that have version numbers in them... If they work well for you, more power to you. But ASDF cannot possibly depend on them. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Life is the worst of all social inequalities. To suppress inequalities, one must either resurrect all the dead people (and give life to all the potential living people), or exterminate all the actually living. Egalitarians, since they cannot further their goal by the former method, inevitably come to further it by the latter method.
Logical pathnames work well as long as all your files follow the naming restrictions. Which is not the case for all CL programs and libraries, even less so when you're integrating with other languages and their naming conventions, or (shudder) files that have version numbers in them...
If they work well for you, more power to you. But ASDF cannot possibly depend on them.
Also, logical-pathnames require some magic setup to happen early in the system configuration. Details of such configuration is completely implementation-dependent, and it would be a bootstrapping catch-22 to require casual users to do this configuration before they could use ASDF. More work for less bang. Yet another reason why ASDF does not depend on logical-pathnames, and why I do not recommend that anyone should bother with them for anything remotely "portable". Of course, if you already paid the price, you're free to keep using them and live with their limitations. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Obama's economic policies will be so remembered that he'll be the president picked for the face on the hundred trillion dollar bill.
On 21 May 2011, at 01:21, Faré wrote:
Logical pathnames work well as long as all your files follow the naming restrictions. Which is not the case for all CL programs and libraries, even less so when you're integrating with other languages and their naming conventions, or (shudder) files that have version numbers in them...
If they work well for you, more power to you. But ASDF cannot possibly depend on them.
Also, logical-pathnames require some magic setup to happen early in the system configuration. Details of such configuration is completely implementation-dependent, and it would be a bootstrapping catch-22 to require casual users to do this configuration before they could use ASDF. More work for less bang. Yet another reason why ASDF does not depend on logical-pathnames, and why I do not recommend that anyone should bother with them for anything remotely "portable". Of course, if you already paid the price, you're free to keep using them and live with their limitations.
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. 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. Either they are useful for people who only care for Unix-like environments, but then they probably care independent from whether they want to use ASDF or not. Or they don't want to narrow themselves down to Unix-style environments, but then getting that overhead just for wanting to use ASDF doesn't make that much sense. In my opinion, this speaks for separating them out of ASDF (and ASDF could take advantage of them in case it detects they are present). 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. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
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.
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.
Either they are useful for people who only care for Unix-like environments,
No they are NOT. Systems defined with the above syntax will compile just fine on RMCL or Genera, not to talk about Windows-based implementations or implementations will URL pathnames (such as SCL or ABCL). Wherever ASDF uses this "Unix-like" syntax, it is translated into appropriate calls to make-pathname, ASDF does NOT rely on parse-namestring being Unix-like.
In my opinion, this speaks for separating them out of ASDF (and ASDF could take advantage of them in case it detects they are present).
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" ...)
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? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Slogans rarely convince the unconvinced. However, they do rally the troops already on your side. — John McCarthy
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.
On 5/28/11 May 28 -1:50 PM, Pascal Costanza wrote:
....
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.
I would be happy to splice into the manual an account of the "old school" way to configure ASDF. I mostly still use this myself, albeit with the aid of a couple of ancillary libraries that are used at our company to make it possible to smoothly make consistent configurations across users without enforcing commonality in users' directory trees. Hence my configuration instructions are not easily portable. But I would be happy to merge contributions from you or others to the manual and wrangle the texinfo. Until then, the manual states that asdf:*central-registry* is maintained for backwards compatibility, so I believe Fare is correct to refer to this as the simplest method, with the implicit qualifier of "current" or "going forward." Again, if you disagree strongly enough, you are more than welcome to supply a documentation patch.
- 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).
Actually, it does say what some problems are. E.g., The `asdf-output-translation' layer will avoid trying to resolve and translate logical-pathnames. The advantage of this is that you can define yourself what translations you want to use with the logical pathname facility. The disadvantage is that if you do not define such translations, any system that uses logical pathnames will behave differently under asdf-output-translations than other systems you use. The non-uniformity of treatment here qualifies as a problem, IMO. That said, I will push a patch with a more neutral title.
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.
You are certainly free to do so. Our experience differs from yours.
On 29 May 2011, at 23:05, Robert Goldman wrote:
On 5/28/11 May 28 -1:50 PM, Pascal Costanza wrote:
....
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.
I would be happy to splice into the manual an account of the "old school" way to configure ASDF. I mostly still use this myself, albeit with the aid of a couple of ancillary libraries that are used at our company to make it possible to smoothly make consistent configurations across users without enforcing commonality in users' directory trees. Hence my configuration instructions are not easily portable. But I would be happy to merge contributions from you or others to the manual and wrangle the texinfo.
Until then, the manual states that asdf:*central-registry* is maintained for backwards compatibility, so I believe Fare is correct to refer to this as the simplest method, with the implicit qualifier of "current" or "going forward." Again, if you disagree strongly enough, you are more than welcome to supply a documentation patch.
Why is the *central-registry* approach considered "old school?" What exactly is better about the approach put forward by ASDF 2?
- 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).
Actually, it does say what some problems are. E.g.,
The `asdf-output-translation' layer will avoid trying to resolve and translate logical-pathnames. The advantage of this is that you can define yourself what translations you want to use with the logical pathname facility. The disadvantage is that if you do not define such translations, any system that uses logical pathnames will behave differently under asdf-output-translations than other systems you use.
The non-uniformity of treatment here qualifies as a problem, IMO.
This sounds like a weird statement to me: If you don't provide the necessary logical pathname translations, then the logical pathname doesn't make any sense anyway, or so it seems to me. What is the motivation behind that paragraph? To me it sounds like it talks about something that cannot work in the first place. Maybe I misunderstand this.
That said, I will push a patch with a more neutral title.
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.
You are certainly free to do so. Our experience differs from yours.
That's fine, of course. I only object to the ASDF 2 documentation seemingly promoting a particular approach for which there is not necessarily a community-wide consensus that it's the best one under all circumstances. Pascal -- Pascal Costanza
That's fine, of course. I only object to the ASDF 2 documentation seemingly promoting a particular approach for which there is not necessarily a community-wide consensus that it's the best one under all circumstances.
Logical pathnames are not recommended because there is no documentation on how to use them. If you want them to be more supported than they are, you pretty much will have to support them yourself. Please write the documentation on how to use them, and then commit to answering the questions of newbies who'll try to use them. Having little experience with them, except to get rid of them when James Anderson tried to introduce them in a large project where they couldn't fit, I am unfit to provide this support. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Truth comes as conqueror only to those who have lost the art of receiving it as friend. — Tagore
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.
Does not compute. Setting up logical pathname is a step that ought to be done before ASDF is loaded and/or used. Some implementations don't even provide a way to load an initialization file (e.g. lwper). If you're willing to contribute a guide to how to do these things on each of the 15 platforms we support, I'll include it in the ASDF manual. I could have tried to resurrect one of the old mechanisms of loading configuration files as lisp code, but they were decidedly neither modular nor portable nor future-proof. There's a reason they didn't take on.
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?
It's possible to have nested modules, indeed, and rpgoldman importantly fixed the bug in module dependencies for ASDF 2. But let's just suppose for a minute that you're part of a project with thousands of files where tens of developers simultaneously edit files. At some point, you need to add a dependencyn between files that were originally in different directories, and you don't want to move the file, either because it would cause painful gratuitous merge conflicts, or just because the directories denote some logical grouping independent from the dependency order. Suddenly, you find yourself either creating plenty of gratuitous modules with different names but identical pathname, or using hierarchical names, which in the bad old days meant playing games with merge-pathnames.
- 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.
"old style" is much simpler if you either solve the issue of documenting configuration for 15 different implementations, or don't support the writing of lisp scripts distributed independently from the libraries they are using. I invite you to read the paper Robert Goldman and I wrote, particularly section 4.5 "Decentralized configuration". http://common-lisp.net/project/asdf/ilc2010draft.pdf
- 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).
I renamed it to "Using logical pathnames", and added a note regarding why we do not recommend logical pathnames to newcomers.
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 don't believe there will be many "future Common Lisp implementations". Several existing implementations have problems with logical pathnames (or sometimes physical pathnames) that are decidedly not going away. Logical pathnames have limitations that are enforced in SBCL, and make them inapplicable to a variety of situations.
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.
Between James Anderson and you, I know of only two people who ever care about logical pathnames — and either of you is welcome to write a guide to using them, though I will only include it in the ASDF doc if it is comprehensive enough in (1) how to configure them on each of 15 supported implementations (distinguishing LW and LWper), and (2) how to deal with physical pathnames that don't fit. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The rule is perfect: in all matters of opinion our adversaries are insane. — Mark Twain
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] On 28 May 2011 14:50, Pascal Costanza <pc@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.
On 19 May 2011, at 21:57, Faré wrote:
: Pascal Costanza Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell
Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other —
Not according to my experience.
or be absent or not well supported.
That would be a non-conforming CL implementation.
In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.
If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.
I don't understand what I did to deserve such snippy remarks. ASDF 2 has problems with a particular conforming Common Lisp implementation because it depends on a feature that is implementation-dependent by definition. All I did is that I asked for workarounds and reported whatever I could to enable you to fix the problem.
(but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)
Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?
I did report this particular issue on 23 January 2011 in this mailing list.
: Robert Goldman One undesirable feature is their refusal to permit filenames containing underscores or spaces:
word---one or more uppercase letters, digits, and hyphens.
And SBCL, being the language lawyering prick we love it to be, does enforce these limitations like all those it can from the standard. Of course, Corman doesn't have portable pathnames, I wouldn't trust GCL, and there might be bugs in ABCL, etc.
Yes, some CL implementations extend certain CL features with additional capabilities. This is allowed by the CL specification, and relying on such extensions makes your programs non-portable by definition. So if you want your program / library to be portable, you shouldn't rely on them. I don't see what's so hard to understand about these concepts.
Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another. I, for one, welcome Fare replacing them inside ASDF2...
Thank you!
I think it's ok to have alternatives to the existing standard features. I don't think that ASDF should push such an alternative to the extent that the existing standard feature cannot be used anymore (or only with workarounds). I'm not sure what your intention is, but the way you react to my problem reports gives me the impression that you _may_ not be interested in giving CL logical pathnames the same status as your own Unix-specific solution. Maybe my impression is wrong, but then I don't understand your reaction at all. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Beware logical pathnames. They may "work extremely well" in some implementations, and completely differently in some other —
Not according to my experience.
Have you tried to deal SBCL's enforcing of "portable" pathname restrictions?
or be absent or not well supported.
That would be a non-conforming CL implementation.
And we have been supporting these implementations.
In other words, they are not portable, not enough the extremely constrained subset that is defined as portable in the spec. That's the main reason why ASDF2, while it will let you use them, isn't based on them.
If you want to start on a crusade to the spec to be extended to be more useful and/or to get all Lisp implementations to actually use such a spec — I'm sure many CL users will love you (especially janderson!). Good luck.
I don't understand what I did to deserve such snippy remarks. ASDF 2 has problems with a particular conforming Common Lisp implementation because it depends on a feature that is implementation-dependent by definition. All I did is that I asked for workarounds and reported whatever I could to enable you to fix the problem.
My apologies for miscommunicating. My remarks were certainly not intended as "snippy". I just wanted to explain why ASDF2 made no attempt at actively using so-called "portable" pathnames, though once again we do try to support them when the user uses them.
Why do you have to :ignore-inherited-configuration ??? Is there or was there something buggy in ASDF2? Why didn't you report the bug and get it fixed?
I did report this particular issue on 23 January 2011 in this mailing list.
I thought I had provided required fixes. Apparently, I failed to make it all happy in my previous attempts. Since I do not have access to RMCL, I could not test whether my fixes did work, and was relying on you to provide further feedback it they didn't. Once again, my apologies for any miscommunication. Please keep bugging me until RMCL is completely happy with ASDF2 without the need for any workaround on your side.
I think it's ok to have alternatives to the existing standard features. I don't think that ASDF should push such an alternative to the extent that the existing standard feature cannot be used anymore (or only with workarounds).
I am not aware that ASDF prevents any standard feature from being used, and if it does this is certainly a bug indeed. Please report any such bug.
I'm not sure what your intention is, but the way you react to my problem reports gives me the impression that you _may_ not be interested in giving CL logical pathnames the same status as your own Unix-specific solution. Maybe my impression is wrong, but then I don't understand your reaction at all.
We do intend to support your using logical pathnames if you fancy, and have indeed many times over patched ASDF for use with them. Please report any issues with using them. Thanks a lot for your feedback, and my apologies again for any mistake on our part. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Chuangtse and Hueitse had strolled onto the bridge over the Hao, when the former observed, ``See how the small fish are darting about! That is the happiness of the fish.'' ``You are not a fish yourself,'' said Hueitse. ``How can you know the happiness of the fish?'' ``And you not being I,'' retorted Chuangtse, ``how can you know that I do not know?'' — Chuangtse, circa 300 B.C.
* Robert Goldman <ectbyqzna-+oH95RRTAwguy2c70OcIdD@choyvp.tznar.bet> [2011-05-19 14:26:19 -0500]: Every time I have used logical pathnames, or even just used pathnames, they have blown up in my face, sooner or later, when code moved from one lisp implementation to another.
with all due respect, I am not sure I agree both with your experience (pathnames are non-trivial to use, but quite powerful and useful) and conclusions.
I, for one, welcome Fare replacing them inside ASDF2...
I, for one, am severely disappointed with the size of asdf. Now that you told me that Fare reimplemented pathnames, I am starting to understand why. A brief look at asdf.lisp appalled me. I even tried to simplify it a little bit, e.g.: diff -r 0195ae274543 modules/asdf/asdf.lisp --- a/modules/asdf/asdf.lisp Fri May 20 15:45:46 2011 -0400 +++ b/modules/asdf/asdf.lisp Fri May 20 16:40:47 2011 -0400 @@ -387,6 +387,8 @@ a list for each collection, in order. \(foo \(first x\)\) \(bar \(second x\)\)\)\) Returns two values: \(A B C\) and \(1 2 3\)." + #+clisp `(ext:with-collect ,collectors . ,body) + #-clisp (let ((vars (mapcar #'(lambda (x) (gensym (symbol-name x))) collectors)) (initial-values (mapcar (constantly nil) collectors))) `(let ,(mapcar #'list vars initial-values) but soon gave up. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://thereligionofpeace.com http://openvotingconsortium.org http://ffii.org http://www.PetitionOnline.com/tap12009/ http://truepeace.org Diplomacy is the art of saying "nice doggy" until you can find a rock.
: sds I, for one, am severely disappointed with the size of asdf.
To be frank, so am I. I hate it every time I add a line. But I couldn't find any other way to make it seamlessly configurable across 13 implementations that we support over 4 families of OSes. Which is quite a few more than were fully supported before I started. I'm not even sure CLISP was supported back then, by lack of long-form define-method-combination.
Now that you told me that Fare reimplemented pathnames, I am starting to understand why.
I conspicuously did NOT "reimplement pathnames". But I certainly did build a lot of abstractions on top of them, for the sake of portability and robustness. Just take a look at subdirectories, merge-pathnames* or truenamize.
A brief look at asdf.lisp appalled me.
And it appals me, too. You're welcome to do better.
I even tried to simplify it a little bit, e.g.:
diff -r 0195ae274543 modules/asdf/asdf.lisp --- a/modules/asdf/asdf.lisp Fri May 20 15:45:46 2011 -0400 +++ b/modules/asdf/asdf.lisp Fri May 20 16:40:47 2011 -0400 @@ -387,6 +387,8 @@ a list for each collection, in order. \(foo \(first x\)\) \(bar \(second x\)\)\)\) Returns two values: \(A B C\) and \(1 2 3\)." + #+clisp `(ext:with-collect ,collectors . ,body) + #-clisp (let ((vars (mapcar #'(lambda (x) (gensym (symbol-name x))) collectors)) (initial-values (mapcar (constantly nil) collectors))) `(let ,(mapcar #'list vars initial-values)
but soon gave up.
You add two lines. How is that a simplification? Does it provide a big performance boost on CLISP to justify two lines of code? Or does it fix some strange corner case? That said, if you insist that it does matter, I will gladly take your word for it and apply that patch. I do welcome actual simplifications to the code. So far as I know there is no superfluous line of code in ASDF — and if you find one, I'll be glad to remove it or refactor it away. By all means, if you think you're able to support ASDF better than I do, and make it work on all the implementations that it does work — go ahead and do it! You may find, as I did, and still do to this date, that's it easier said than done. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Don't expect coherence from a loosely-defined group of people. Even individuals have trouble with coherence. Argue issues. Change incentives.
participants (5)
-
Chun Tian (binghe) -
Faré -
Pascal Costanza -
Robert Goldman -
Sam Steingold