Hi Mark,
Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows:
[java] Error while trying to load definition for system abcl from pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log.
While I'm not asking you to fix it, could you indicate where I should start looking?
Thanks in advance!
Bye,
Erik.
On 4/30/10 8:26 PM, Erik Huelsmann wrote:
Hi Mark,
Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows:
[java] Error while trying to load definition for system abclfrom pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log.
While I'm not asking you to fix it, could you indicate where I should start looking?
Carlos Ungil's mail to <armedbear-develop@…> of 04.30.2010 diagnoses this as a problem with the pathname translation function, he suggests:
Is there a reason why the pathname has to start with "/:"? I changed it to #P"/jar:file/**.*" (and made a similar change inside translate-jar-pathname, from "/:jar:file/" to "/jar:file/"). This seems to work on both macosx and windows (at least I can load asdf systems).
There is no reason that I can remember that I coded it that way: I just needed an intermediate path to match via the TRANSLATE-JAR-PATHNAME function. If his suggestion works, we should patch ASDF as included in ABCL for 0.20, and then propagate the patch back to ASDF2 when we get a chance.
[Apologies: time to work on ABCL has been real short this week, so I'm at least trying to respond to accumulated email.]
On Sat, May 1, 2010 at 8:26 AM, Mark Evenson evenson@panix.com wrote:
There is no reason that I can remember that I coded it that way: I just needed an intermediate path to match via the TRANSLATE-JAR-PATHNAME function. If his suggestion works, we should patch ASDF as included in ABCL for 0.20, and then propagate the patch back to ASDF2 when we get a chance.
In fact there are still some problems with the change I proposed: if there are multiple devices involved, paths are not resolved properly. For example, if I remember correcly when the current directory was D: an ASDF system somewhere in D: couldn't be loaded because the path "/Documents And Settings/....../.cache" was in C: and not in D: (but device info was not included in the translated pathname). I'll try to look at it, but a first glance at Pathname.java suggests that it won't be easy to fix...
Carlos
On 5/1/10 10:14 AM, Carlos Ungil wrote: […]
In fact there are still some problems with the change I proposed: if there are multiple devices involved, paths are not resolved properly. For example, if I remember correcly when the current directory was D: an ASDF system somewhere in D: couldn't be loaded because the path "/Documents And Settings/....../.cache" was in C: and not in D: (but device info was not included in the translated pathname). I'll try to look at it, but a first glance at Pathname.java suggests that it won't be easy to fix...
Could you briefly describe what sort of behavior you see as necessary to introduce to Pathname.java? The current Pathname implementation was designed to incorporate both Windows drive letters as DEVICE and the location of the JAR as a list of PATHNAMEs in the DEVICE, so I think we just need to get the translation right in ASDF2 rather than re-work Pathname.java. Then again, I might have missed something, so would be interested in understanding a bit more about your analysis.
On 5/1/10 8:26 AM, Mark Evenson wrote:
On 4/30/10 8:26 PM, Erik Huelsmann wrote:
Hi Mark,
Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows:
[java] Error while trying to load definition for system abclfrom pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log.
While I'm not asking you to fix it, could you indicate where I should start looking?
After further analysis, the problem reported by Erik is not related to the issue that Carlos is looking at solving. Under win32, ASDF2 is trying to make a Pathname that contains a TYPE whose value is "asd.lnk" to work with Windows shortcuts. ABCL asserts that TYPE cannot have a '.' character in it on an attempt to return a namestring.
When I get the time, I planning on relaxing the constraint that a namestring will not be returned under Windows if the TYPE string ends with ".lnk", and then test the code dealing with Windows shortcuts.
On 4/30/10 8:26 PM, Erik Huelsmann wrote:
Hi Mark,
Today I tried to run ABCL's tests on Windows. I seem to have an issue, either with the new ASDF stuff, or with the new Pathname stuff. I'm not sure which, but hopefully you do. This is the output I get from "ant test.abcl" on Windows:
[java] Error while trying to load definition for system abclfrom pathname C:\Users\Erik\Documents\abcl-j\abcl.asd: Pathname has no namestring: #P(:DEVICE "C" :DIRECTORY (:ABSOLUTE "Users" "Erik" "Documents" "abcl-j") :NAME "abcl-test-lisp" :TYPE "asd.lnk" :VERSION :NEWEST) [java] Java Result: 2 [echo] Finished recording test output in abcl-test-20101530-1515.log.
This should be fixed with [12642][1]. Now to tackle the problems reported by Carlos…
[1]: http://trac.common-lisp.net/armedbear/changeset/12642
armedbear-devel@common-lisp.net
-
Carlos Ungil -
Erik Huelsmann -
Mark Evenson