I added a more functional test for logical pathnames, and made a round of fixes for logical pathnames. Some things are still broken on CLISP and Allegro, but I blame the implementations (see test/test-logical-pathname.script for details).
p-cos, janderson, pjb: I believe you are the three known users of logical pathnames. Can you test the latest ASDF in your respective setups? (currently 2.20.10).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Think you can, or think you can't — either way, you'll be right. — Henry Ford
On 4/12/12 Apr 12 -3:51 PM, Faré wrote:
I added a more functional test for logical pathnames, and made a round of fixes for logical pathnames. Some things are still broken on CLISP and Allegro, but I blame the implementations (see test/test-logical-pathname.script for details).
p-cos, janderson, pjb: I believe you are the three known users of logical pathnames. Can you test the latest ASDF in your respective setups? (currently 2.20.10).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Think you can, or think you can't — either way, you'll be right. — Henry Ford
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
I ran this on CCL 1.8 on Mac OS X 1.6 and got 10 test failures, which is new
Using /Users/rpg/ccl/dx86cl64 --no-init --quiet --batch Ran 39 tests: 29 passing and 10 failing failing test(s): test-module-depend.script test-module-excessive-depend.script test-redundant-recompile.script test-samedir-modules.script test-source-file-type.script test-static-and-serial.script test-weakly-depends-on-present.script test-weakly-depends-on-unpresent.script test1.script test2.script
Cheers, r
On 4/12/12 Apr 12 -3:51 PM, Faré wrote:
I added a more functional test for logical pathnames, and made a round of fixes for logical pathnames. Some things are still broken on CLISP and Allegro, but I blame the implementations (see test/test-logical-pathname.script for details).
p-cos, janderson, pjb: I believe you are the three known users of logical pathnames. Can you test the latest ASDF in your respective setups? (currently 2.20.10).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Think you can, or think you can't — either way, you'll be right. — Henry Ford
asdf-devel mailing list asdf-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
I looked at that comment
Bug: Allegro Express 8.2 incorrectly reads #p"ASDF:" as relative.
I have a licensed copy of ACL 8.2 Mac OS X, which was updated w/in the past, say, 3 weeks. I see the following:
CL-USER> #p"ASDF:" #P"ASDF:"
and when I look I see:
CL-USER> (describe *) #P"ASDF:" is a structure of type LOGICAL-PATHNAME. It has these slots: HOST "ASDF" DEVICE NIL DIRECTORY NIL NAME NIL TYPE NIL VERSION NIL NAMESTRING NIL HASH NIL DIR-NAMESTRING NIL PLIST NIL
Is that other than it should be?
Also, I see this:
'(:source-registry (:tree #-allegro #p"ASDF:" #+allegro #.(asdf::pathname-root #p"ASDF"))
Why do you omit the host marker when this is for allegro?
When I put the ":" in the pathname for Allegro, the test passes for me.
Cheers, r
Bug: Allegro Express 8.2 incorrectly reads #p"ASDF:" as relative.
I have a licensed copy of ACL 8.2 Mac OS X, which was updated w/in the past, say, 3 weeks. I see the following:
CL-USER> #p"ASDF:" #P"ASDF:"
and when I look I see:
CL-USER> (describe *) #P"ASDF:" is a structure of type LOGICAL-PATHNAME. It has these slots: HOST "ASDF" DEVICE NIL DIRECTORY NIL NAME NIL TYPE NIL VERSION NIL NAMESTRING NIL HASH NIL DIR-NAMESTRING NIL PLIST NIL
Is that other than it should be?
DIRECTORY should be (:ABSOLUTE), as per (pathname-root #p"ASDF:"), that also (correctly this time) prints as #p"ASDF:".
Also, I see this:
'(:source-registry (:tree #-allegro #p"ASDF:" #+allegro #.(asdf::pathname-root #p"ASDF"))
Why do you omit the host marker when this is for allegro?
When I put the ":" in the pathname for Allegro, the test passes for me.
Oops. Thanks for the typo fix. Committed. I'm glad there isn't another bug. CLISP is the only to get asdf::subdirectories wrong for #p"ASDF:" then.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Funny how the so-called money-disparaging anti-materialist are always so prompt to demand other people's money in the form of taxes.
OK, I pulled the update to the test and reran the tests (Mac OS X 10.6) on
clisp sbcl ecl abcl allegro allegromodern
all succeed.
CCL 1.8 fails badly: 10 tests fail. Any chance that plugging in the logical pathnames fixes busted loading on CCL? Even test1.script fails:
Testing: test1.script + /Users/rpg/ccl/dx86cl64 --no-init --quiet --batch --eval '(load "test1.script")' ....
(1218E80) : 6 (PHYSICAL-PATHNAME-P "ASDF:test;file1.lisp.newest") 45 (CCL::PATH) CCL::PATH: "ASDF:test;file1.lisp.newest"
...
No idea why it thinks that *default-pathname-defaults* should have ASDF: in it here.
Interestingly, when I do
./run-tests.sh ccl test1.script
all is well. It seems like running the test inside make is breaking things.
make test-noupgrade lisp=ccl
also fails.
I can't see how context could bleed across lisp processes, can you?
R
On Thu, Apr 12, 2012 at 23:23, Robert Goldman rpgoldman@sift.info wrote:
OK, I pulled the update to the test and reran the tests (Mac OS X 10.6) on
clisp sbcl ecl abcl allegro allegromodern
all succeed.
CCL 1.8 fails badly: 10 tests fail. Any chance that plugging in the logical pathnames fixes busted loading on CCL? Even test1.script fails:
I believe the problem is due to the file test1.lisp being compiled either as a logical or physical pathname, with the pathname being saved for debugging purposes, and the loading failing when it was compiled as logical but loaded without the translations being setup.
If you clear your fasl cache, things should work again.
For a permanent workaround, we could have test-logical-pathname not share system and file with non-logical-pathname test.
For a real fix, we should examine how the asdf-output-translations interact with logical-pathnames. I thought that the idea was that if you use logical pathnames, then you are responsible for your own output translations. This error suggests that logical-pathnames are resolved at some point and asdf-output-translations take it from there, which might not be what we want (or then again, might).
-#f drug, n: A substance that, injected into a rat, produces a scientific paper.
On 4/12/12 Apr 12 -11:57 PM, Faré wrote:
On Thu, Apr 12, 2012 at 23:23, Robert Goldman rpgoldman@sift.info wrote:
OK, I pulled the update to the test and reran the tests (Mac OS X 10.6) on
clisp sbcl ecl abcl allegro allegromodern
all succeed.
CCL 1.8 fails badly: 10 tests fail. Any chance that plugging in the logical pathnames fixes busted loading on CCL? Even test1.script fails:
I believe the problem is due to the file test1.lisp being compiled either as a logical or physical pathname, with the pathname being saved for debugging purposes, and the loading failing when it was compiled as logical but loaded without the translations being setup.
If you clear your fasl cache, things should work again.
For a permanent workaround, we could have test-logical-pathname not share system and file with non-logical-pathname test.
For a real fix, we should examine how the asdf-output-translations interact with logical-pathnames. I thought that the idea was that if you use logical pathnames, then you are responsible for your own output translations. This error suggests that logical-pathnames are resolved at some point and asdf-output-translations take it from there, which might not be what we want (or then again, might).
-#f drug, n: A substance that, injected into a rat, produces a scientific paper.
Does this seem like the sort of thing we should raise with openmcl-devel? Sounds like we need a more deep understanding of what goes on inside their fasl format....
I have mixed feelings about what is right here. My growing dislike of Logical Pathnames suggests to me that trying to squeeze them out and resolve to physical might be the right thing. But, of course, if someone carefully built an application based on logical pathnames as a portability solution, and moved a bundle of files with carefully-maintained logical pathnames, then resolving would be The Wrong Thing.
It would help if the error was more understandable. If CCL tossed up something that looked a lot more like "referencing a logical pathname host that's not loaded," then I would be happier about ignoring this problem and just fixing the test not to share files with the other tests. Then we could count on programmers and users having a reasonable experience using ASDF and CCL.
Best, r
-
Faré -
Robert Goldman