[asdf-devel] pathname case issue ...
Hi, ASDF developer Recently I found a strange behaivour in latest ASDF: it internally converts all my pathname namestrings into lower-case, although I'm using a case-insentive HFS on Mac. I have following items in asdf:*central-registry*, these packages are either maintained/modified by me or not yet with Quicklisp: SNMP 14 > asdf:*central-registry* (#P"/Applications/FileMaker Pro 11/fm-plugin-tools-0.2.9/" #P"/Users/binghe/Lisp/packages/trivial-gray-streams/" #P"/Users/binghe/Lisp/packages/lisa/" #P"/Users/binghe/Lisp/packages/elephant/" #P"/Users/binghe/Lisp/packages/cffi/" #P"/Users/binghe/Lisp/packages/cl-base64/" #P"/Users/binghe/Lisp/packages/iolib/src/" #P"/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/" #P"/Users/binghe/Lisp/usocket/branches/0.5.x/" #P"/Users/binghe/quicklisp/quicklisp/") Notice that all of those pathnames except the first one is started from directory "/Users/binghe", in which the letter "U" is upper-cased. But, when I manually compiled a changed definition in one of above projects (snmp), I got a warning from my Lisp platform: """ Warnings: (DEFUN SNMP-CONNECT) being redefined in /users/binghe/Lisp/cl-net-snmp/snmp/branches/6/session.lisp (previously in /Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/session.lisp). """ See, now ASDF think the Lisp file was in another different directory which started from "/users/binghe/, in which the first letter "u" is lower-cased. I hate this new behaviour, either because I want to keep all my namestring cases in a case-insentive file system, or I doubt that if I'm in a case-sensitive HFS filesystem, ASDF may failed to distinguish /Users and /users or something like this. Please confirm it's a new feature or bug and please consider reverting to previous status. Regards, Chun Tian (binghe)
Recently I found a strange behaivour in latest ASDF: it internally converts all my pathname namestrings into lower-case, although I'm using a case-insentive HFS on Mac.
I have following items in asdf:*central-registry*, these packages are either maintained/modified by me or not yet with Quicklisp:
That's weird. I don't remember doing anything recently that might affect the central-registry. Which implementation are you using? Did you upgrade it recently? What version of ASDF are you using now, and which were you using previously? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To make an apple pie from scratch, you must first create the universe. — Carl Sagan
Hi, Faré Sorry, actually I'm using a old ASDF, now the latest. It's from latest Quicklisp, the version is 2.014.6 I'm on LispWorks. Currently, every time I manually eval a definition, I was prompted that the definition has been redefined from one file to another ... But if I upgrade to latest ASDF after Quicklisp being loaded, I cannot do ASDF:LOAD-SYSTEM to those packages behind Quicklisp: CL-USER 1 > (upgrade-asdf) ;; compile latest asdf.lisp and load it ... lots of redefinition warnings ... CL-USER 2 > (asdf:load-system :snmp) ; Loading system definition from /Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp.asd into #<The ASDF0 package, 0/16 internal, 0/16 external> ; Loading text file /Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/snmp.asd ; Registering #<SYSTEM "snmp"> ; Loading system definition from /Users/binghe/Lisp/usocket/branches/0.5.x/usocket.asd into #<The ASDF0 package, 0/16 internal, 0/16 external> ; Loading text file /Users/binghe/Lisp/usocket/branches/0.5.x/usocket.asd ; Registering #<SYSTEM "usocket"> Error: Component :IRONCLAD not found, required by #<ASDF:SYSTEM "snmp"> 1 (continue) Retry loading IRONCLAD. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. Here, IRONCLAD was managed by Quicklisp, but I cannot load it any more. --binghe 在 2011-6-16，00:58， Faré 写道：
Recently I found a strange behaivour in latest ASDF: it internally converts all my pathname namestrings into lower-case, although I'm using a case-insentive HFS on Mac.
I have following items in asdf:*central-registry*, these packages are either maintained/modified by me or not yet with Quicklisp:
That's weird. I don't remember doing anything recently that might affect the central-registry. Which implementation are you using? Did you upgrade it recently? What version of ASDF are you using now, and which were you using previously?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To make an apple pie from scratch, you must first create the universe. — Carl Sagan
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
Hi, Faré
Sorry, actually I'm using a old ASDF, now the latest. It's from latest Quicklisp, the version is 2.014.6
I'm on LispWorks. Currently, every time I manually eval a definition, I was prompted that the definition has been redefined from one file to another ...
But if I upgrade to latest ASDF after Quicklisp being loaded, I cannot do ASDF:LOAD-SYSTEM to those packages behind Quicklisp:
[snip]
Error: Component :IRONCLAD not found, required by #<ASDF:SYSTEM "snmp"> 1 (continue) Retry loading IRONCLAD. 2 (abort) Return to level 0. 3 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
Here, IRONCLAD was managed by Quicklisp, but I cannot load it any more.
Quicklisp systems are located via a function appended to the end of ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*. It looks like ASDF defines this variable with DEFPARAMETER, so every time asdf.lisp is loaded, the value is set to ASDF's initial value. It seems to me that ASDF should use DEFVAR instead. You can restore the Quicklisp ASDF system search configuration by calling (ql:setup). Zach
Zach Beane <xach@xach.com> writes:
Quicklisp systems are located via a function appended to the end of ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*. It looks like ASDF defines this variable with DEFPARAMETER, so every time asdf.lisp is loaded, the value is set to ASDF's initial value. It seems to me that ASDF should use DEFVAR instead.
After a moment's reflection, I don't think DEFVAR is suitable for this situation, since it would make upgrading from an old ASDF1 to a new ASDF2 fail to pick up the new ASDF system definition search functions. Zach
Quicklisp systems are located via a function appended to the end of ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*. It looks like ASDF defines this variable with DEFPARAMETER, so every time asdf.lisp is loaded, the value is set to ASDF's initial value. It seems to me that ASDF should use DEFVAR instead.
After a moment's reflection, I don't think DEFVAR is suitable for this situation, since it would make upgrading from an old ASDF1 to a new ASDF2 fail to pick up the new ASDF system definition search functions.
Upgrading from ASDF1 is one thing. Another thing is that on some implementations (notably SBCL), you can't undo a defgeneric and if the signature changed, you have to use a new symbol, which invalidates ASDF extensions, that have to be reloaded. That is why I recommend that any upgrading of ASDF should happen first. Maybe Quicklisp should upgrade ASDF with (asdf:upgrade-asdf) first thing after loading its own? (and issue an cerror if the new one was actually a downgrade?) If you have great ideas on how to avoid these issues, we could rename the variable to something different, and then use DEFVAR on the new variable. This would allow both upgrading from previous versions and smoothly upgrading to new ones. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Insanity is hereditary — you get it from your kids.
Faré <fahree@gmail.com> writes:
Upgrading from ASDF1 is one thing.
Another thing is that on some implementations (notably SBCL), you can't undo a defgeneric
What does that mean?
and if the signature changed, you have to use a new symbol, which invalidates ASDF extensions, that have to be reloaded.
How does that relate to asdf:*system-definition-search-functions*? Zach
On 15 June 2011 21:00, Faré <fahree@gmail.com> wrote:
Another thing is that on some implementations (notably SBCL), you can't undo a defgeneric and if the signature changed,
This is not intentional. If (fmakunbound 'foo) doesn't nuke your defgeneric properly, it's an SBCL bug that I'm happy to fix. What goes wrong if you do that? Cheers, -- nikodemus
On 15 June 2011 14:12, Nikodemus Siivola <nikodemus@random-state.net> wrote:
On 15 June 2011 21:00, Faré <fahree@gmail.com> wrote:
Another thing is that on some implementations (notably SBCL), you can't undo a defgeneric and if the signature changed,
This is not intentional. If (fmakunbound 'foo) doesn't nuke your defgeneric properly, it's an SBCL bug that I'm happy to fix.
What goes wrong if you do that?
It's been a while, I don't know the answer. And so I retried with fmakunbound instead of unintern. I found another problem, which is not specific to sbcl, but to the fact that several ASDF functions the signature of which was redefined were used in the continuation of compile-file, in the path to load'ing the compiled asdf fasl, so that if they were fmakunbound rather than unintern'ed, asdf was unable to load itself after having compiled the new version. I solved that by making sure ASDF is first loaded as source via load-source-op before it is compiled via compile-op. Therefore, when it is compiled, the package frobbing has already been done and resolved, and since no version discrepancy is detected at compile-time, no further package frobbing will be done. This is done with a special eql-defmethod on the component for the asdf.lisp file, in asdf.asd. Conclusion: there's no bug in SBCL that's affecting ASDF. Instead, it was suboptimial design in ASDF's self-ugrade procedure. I must have been confused with some other problem I had with fmakunbound and type information hardwired into SBCL's infodb, probably from time I was dealing with defining methods on CLOSE or redefining some SBCL internals. Apologies for the mistake, thanks for prompting me to dig into it and fix it, and soon 2.016.3 with a more robust upgrade procedure that doesn't unintern more than it should. Zach: so now I can replace *system-definition-search-functions* with something else that I defvar instead of defparameter. Problem being backward compatibility, which pretty much requires squashing the old symbol or its contents. I propose I create a new variable that is defvar'ed, and either use it and ignore the old variable, or append its content in front of the previous variable, or use (or new-var old-var) to prefer it, or put at the proper end of one a function that chains into the other. What do you think for the sake of Quicklisp? --#f
Faré <fahree@gmail.com> writes:
Zach: so now I can replace *system-definition-search-functions* with something else that I defvar instead of defparameter. Problem being backward compatibility, which pretty much requires squashing the old symbol or its contents. I propose I create a new variable that is defvar'ed, and either use it and ignore the old variable, or append its content in front of the previous variable, or use (or new-var old-var) to prefer it, or put at the proper end of one a function that chains into the other. What do you think for the sake of Quicklisp?
I see no reason to change the current behavior at this time. Zach
Hi, Zach Thanks for providing (ql:setup), now I can normally use Quicklisp after upgrading ASDF. Hi, Faré My problem still exists after turn to latest ASDF: every time I eval a definition in LispWorks, it warns me that the definition's location changed from a pathname to another same but lower-cased pathname: Warnings: (DEFUN LOAD-MIB) being redefined in /users/binghe/Lisp/cl-net-snmp/snmp/branches/6/update-mib.lisp (previously in /Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/update-mib.lisp). --binghe 在 2011-6-16，01:42， Zach Beane 写道：
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
Hi, Faré
Sorry, actually I'm using a old ASDF, now the latest. It's from latest Quicklisp, the version is 2.014.6
I'm on LispWorks. Currently, every time I manually eval a definition, I was prompted that the definition has been redefined from one file to another ...
But if I upgrade to latest ASDF after Quicklisp being loaded, I cannot do ASDF:LOAD-SYSTEM to those packages behind Quicklisp:
[snip]
Error: Component :IRONCLAD not found, required by #<ASDF:SYSTEM "snmp"> 1 (continue) Retry loading IRONCLAD. 2 (abort) Return to level 0. 3 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
Here, IRONCLAD was managed by Quicklisp, but I cannot load it any more.
Quicklisp systems are located via a function appended to the end of ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS*. It looks like ASDF defines this variable with DEFPARAMETER, so every time asdf.lisp is loaded, the value is set to ASDF's initial value. It seems to me that ASDF should use DEFVAR instead.
You can restore the Quicklisp ASDF system search configuration by calling (ql:setup).
Zach
My problem still exists after turn to latest ASDF: every time I eval a definition in LispWorks, it warns me that the definition's location changed from a pathname to another same but lower-cased pathname:
Do you know at which version of ASDF, or between which versions of ASDF this behavior started? That would help me track down the relevant change. Also, what do these return in various versions of ASDF? (cl:truename "/Users/binghe/Lisp/") (cl:probe-file "/Users/binghe/Lisp/") (asdf::probe-file* "/Users/binghe/Lisp/") (asdf::truenamize "/Users/binghe/Lisp/") If it's a recent thing, I made a change for LW in 2.016.1. If it's older, I have no idea what it is. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. — Henry Ford
Hi, Faré It's caused by LispWorks' ASDF integration feature [1], it's also in attach. I have following line in my LispWorks init file: (example-compile-file "misc/asdf-integration.lisp" :load t) I didn't use it much, so I disabled it to make my life easier. But it's also quite hard to determine which version of ASDF2 broke it. Hi, Zach I see current latest Quicklisp release 2011051901 ships with ASDF 2.014.6, but which ASDF version was shipped in last months' Quicklisp? I believe in that ASDF version I didn't met any issue with LispWorks' ASDF integration. Regards, Chun Tian (binghe) [1] http://www.lispworks.com/documentation/lw60/RNIG/html/readme-372.htm#pgfId-9... 在 2011-6-16，02:06， Faré 写道：
My problem still exists after turn to latest ASDF: every time I eval a definition in LispWorks, it warns me that the definition's location changed from a pathname to another same but lower-cased pathname:
Do you know at which version of ASDF, or between which versions of ASDF this behavior started? That would help me track down the relevant change.
Also, what do these return in various versions of ASDF?
(cl:truename "/Users/binghe/Lisp/") (cl:probe-file "/Users/binghe/Lisp/") (asdf::probe-file* "/Users/binghe/Lisp/") (asdf::truenamize "/Users/binghe/Lisp/")
If it's a recent thing, I made a change for LW in 2.016.1. If it's older, I have no idea what it is.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. — Henry Ford
"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:
Hi, Zach
I see current latest Quicklisp release 2011051901 ships with ASDF 2.014.6, but which ASDF version was shipped in last months' Quicklisp? I believe in that ASDF version I didn't met any issue with LispWorks' ASDF integration.
Before 2.014.6, I used 2.011. Zach
On 6/15/11 Jun 15 -9:05 PM, Chun Tian (binghe) wrote:
Hi, Faré
It's caused by LispWorks' ASDF integration feature [1], it's also in attach. I have following line in my LispWorks init file:
(example-compile-file "misc/asdf-integration.lisp" :load t)
I didn't use it much, so I disabled it to make my life easier. But it's also quite hard to determine which version of ASDF2 broke it.
There's nothing obvious in that asdf-integration file that should break asdf's normal functioning. They define a number of behaviors that exploit ASDF data structures, but I don't see anything there that should redefine existing behavior. Of course, I may be overlooking something. Cheers, r
Hi, Zach
I see current latest Quicklisp release 2011051901 ships with ASDF 2.014.6, but which ASDF version was shipped in last months' Quicklisp? I believe in that ASDF version I didn't met any issue with LispWorks' ASDF integration.
Regards,
Chun Tian (binghe)
[1] http://www.lispworks.com/documentation/lw60/RNIG/html/readme-372.htm#pgfId-9...
在 2011-6-16，02:06， Faré 写道：
My problem still exists after turn to latest ASDF: every time I eval a definition in LispWorks, it warns me that the definition's location changed from a pathname to another same but lower-cased pathname:
Do you know at which version of ASDF, or between which versions of ASDF this behavior started? That would help me track down the relevant change.
Also, what do these return in various versions of ASDF?
(cl:truename "/Users/binghe/Lisp/") (cl:probe-file "/Users/binghe/Lisp/") (asdf::probe-file* "/Users/binghe/Lisp/") (asdf::truenamize "/Users/binghe/Lisp/")
If it's a recent thing, I made a change for LW in 2.016.1. If it's older, I have no idea what it is.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. — Henry Ford
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 16 June 2011 08:45, Robert Goldman <rpgoldman@sift.info> wrote:
On 6/15/11 Jun 15 -9:05 PM, Chun Tian (binghe) wrote:
Hi, Faré
It's caused by LispWorks' ASDF integration feature [1], it's also in attach. I have following line in my LispWorks init file:
(example-compile-file "misc/asdf-integration.lisp" :load t)
I didn't use it much, so I disabled it to make my life easier. But it's also quite hard to determine which version of ASDF2 broke it.
There's nothing obvious in that asdf-integration file that should break asdf's normal functioning. They define a number of behaviors that exploit ASDF data structures, but I don't see anything there that should redefine existing behavior. Of course, I may be overlooking something.
Using either ASDF 2.014.6 or ASDF 2.016.2 on LispWorks Personal 6.0.1 on Macintosh on a hfs volume, I cannot reproduce your issue. Is there something magic about the specific file you're seeing in the otherwise magic cl-net-snmp system you're using? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Problem solved. My HFS filesystem seems going wrong, the directory node "/Users" was recognized by LispWorks as "/users". Today I mounted the disk into another Mac computer, manually created a new "/Users" directory and move previous sub-directories in, restart my laptop, and then everything goes fine now. I remembered that several days ago, my Time Machine backup system suddenly decided to re-backup over 300GB data from my laptop, that must be the point when the "/Users" directory node change. I don't know why this happen, but I solved it. Definitely not any issue in ASDF or LispWorks. Sorry for disturb. --binghe 在 2011-6-16，21:15， Faré 写道：
On 16 June 2011 08:45, Robert Goldman <rpgoldman@sift.info> wrote:
On 6/15/11 Jun 15 -9:05 PM, Chun Tian (binghe) wrote:
Hi, Faré
It's caused by LispWorks' ASDF integration feature [1], it's also in attach. I have following line in my LispWorks init file:
(example-compile-file "misc/asdf-integration.lisp" :load t)
I didn't use it much, so I disabled it to make my life easier. But it's also quite hard to determine which version of ASDF2 broke it.
There's nothing obvious in that asdf-integration file that should break asdf's normal functioning. They define a number of behaviors that exploit ASDF data structures, but I don't see anything there that should redefine existing behavior. Of course, I may be overlooking something.
Using either ASDF 2.014.6 or ASDF 2.016.2 on LispWorks Personal 6.0.1 on Macintosh on a hfs volume, I cannot reproduce your issue. Is there something magic about the specific file you're seeing in the otherwise magic cl-net-snmp system you're using?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
participants (5)
-
Chun Tian (binghe) -
Faré -
Nikodemus Siivola -
Robert Goldman -
Zach Beane