Without the attached patch, I believe the use of a function for output translations is hosed from post asdf-3.0.2 onwards.
I think ABCL is the only implementation actively using the ability to specify an output translation as a function, as indeed Faré expressly introduced this for us. ABCL uses a specialized output translation to translate the location of FASLs for ASDF systems stored in jar files (like ABCL’s contribs) which can’t otherwise be expressed in the translation DSL.
I have [committed an asdf-3.0.3.0.1 including this patch][r14583] to ABCL trunk, which I will sync in the near future to ASDF master if this is indeed the correct way to patch the problem.
[r14583]: http://abcl.org/trac/changeset/14583
On Sat, Nov 2, 2013 at 2:40 PM, Mark Evenson evenson@panix.com wrote:
Without the attached patch, I believe the use of a function for output translations is hosed from post asdf-3.0.2 onwards.
Oops. Applied as 3.1.0.3.
I think ABCL is the only implementation actively using the ability to specify an output translation as a function, as indeed Faré expressly introduced this for us. ABCL uses a specialized output translation to translate the location of FASLs for ASDF systems stored in jar files (like ABCL’s contribs) which can’t otherwise be expressed in the translation DSL.
I have [committed an asdf-3.0.3.0.1 including this patch][r14583] to ABCL trunk, which I will sync in the near future to ASDF master if this is indeed the correct way to patch the problem.
If you can provide a simple test case to include in the test suite, that'd be great. I'm feeling too lazy and not concerned enough to write one. [My, didn't I resign as a maintainer?]
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The man who will use his skill and constructive imagination to see how much he can give for a dollar, instead of how little he can give for a dollar, is bound to succeed. — Henry Ford
Faré wrote:
If you can provide a simple test case to include in the test suite, that'd be great. I'm feeling too lazy and not concerned enough to write one. [My, didn't I resign as a maintainer?]
Yes, a test that simply reads a file out of a jar file, and fails on older versions of ASDF would be very nice to have.
Is there any chance this is related to my issues with the bundle test?
https://bugs.launchpad.net/asdf/+bug/1207073
thanks, r
On Nov 4, 2013, at 15:46, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
If you can provide a simple test case to include in the test suite, that'd be great. I'm feeling too lazy and not concerned enough to write one. [My, didn't I resign as a maintainer?]
Yes, a test that simply reads a file out of a jar file, and fails on older versions of ASDF would be very nice to have.
Oh, such an ABCL specific test is quite easy: I guess I thought Faré was asking for something that ran on all implementations, which I didn’t quite understand.
But I must confess I dont really understand how to insert it into the ASDF test suite cleanly.
Should I be looking to add a foo.{script,lisp,asd} triple in the `asdf/test` directory with an assertion in foo.script?
How do I conditionalize the test to only be run on ABCL?
Is there any chance this is related to my issues with the bundle test?
Noted: I’ll take a look, eventually. The hairy backquote/read time conditional macro problem that Faré found is currently really stumping me, but I intend to eventually get around to all the ABCL specific problems that the release/test cycle of asdf-3.0.3 revealed.
Mark Evenson wrote:
On Nov 4, 2013, at 15:46, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
If you can provide a simple test case to include in the test suite, that'd be great. I'm feeling too lazy and not concerned enough to write one. [My, didn't I resign as a maintainer?]
Yes, a test that simply reads a file out of a jar file, and fails on older versions of ASDF would be very nice to have.
Oh, such an ABCL specific test is quite easy: I guess I thought Faré was asking for something that ran on all implementations, which I didn’t quite understand.
But I must confess I dont really understand how to insert it into the ASDF test suite cleanly.
Should I be looking to add a foo.{script,lisp,asd} triple in the `asdf/test` directory with an assertion in foo.script?
You can certainly do this. If you prefer, you can also add only the .script file and add your DEFSYSTEM (assuming you need one for the test) into test-asd.asd -- Faré added this file to keep down the clutter. It's entirely up to you. I find I can often reuse one of the .lisp files that's already there. There are many that, when loaded, will just cause a global variable to be bound to a particular value. So many of the test scripts are of this form:
<perform actions that should cause a particular .lisp file to be loaded> <assert something about the global variable in that .lisp file>
How do I conditionalize the test to only be run on ABCL?
Probably the easiest would be to put the line
#-abcl (leave-test "This test is only intended for ABCL." 0)
at the head of the .script file. Exiting with zero will cause the test to automatically pass on all other lisps.
I'll be happy to help you get this installed if you can provide the key bit -- a place where the test would fail if not for your recent patch.
Thanks! r
The ABCL contribs are all defined via ASDF in a jar file, so the test is simply to try to load one of them, here JSS.
Not all downstream packaging systems include the abcl-contrib.jar, so I try to guard against a false negative with an UNLESS clause in the abcl-contrib REQUIRE, but in my testing by removing abcl-contrib.jar this didn’t seem to work correctly.
Maybe this test can be combined with the bundle and/or run-program test: make a jar (in a subprocess?), load it.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Sexless marriages basically force the partner that wants sex into three outcomes (1) Misery (2) Cheating or (3) Leaving — Athol Kay
On Thu, Nov 7, 2013 at 2:05 AM, Mark Evenson evenson@panix.com wrote:
The ABCL contribs are all defined via ASDF in a jar file, so the test is simply to try to load one of them, here JSS.
Not all downstream packaging systems include the abcl-contrib.jar, so I try to guard against a false negative with an UNLESS clause in the abcl-contrib REQUIRE, but in my testing by removing abcl-contrib.jar this didn’t seem to work correctly.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
On Nov 7, 2013, at 8:14, Faré fahree@gmail.com wrote:
Maybe this test can be combined with the bundle and/or run-program test: make a jar (in a subprocess?), load it.
Sounds like a reasonable proposal: when I get to debugging the bundle op, I’ll take a stab at this.
If someone else has spare cycles to get to this before I do, here are some implementation hints:
In ABCL, SYS:ZIP is the interface for creating jar archives, which uses the zip compression/packaging scheme.
An example of creating a jar archive can be [found in ABCL-TEST::JAR-FILE-INIT][1].
[1]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/abcl/jar-pathname.lisp#L44
OK, I leave that between you and Robert.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You may easily play a joke on a man who likes to argue — agree with him. — Edgar Waston Howe
On Thu, Nov 7, 2013 at 2:22 AM, Mark Evenson evenson@panix.com wrote:
On Nov 7, 2013, at 8:14, Faré fahree@gmail.com wrote:
Maybe this test can be combined with the bundle and/or run-program test: make a jar (in a subprocess?), load it.
Sounds like a reasonable proposal: when I get to debugging the bundle op, I’ll take a stab at this.
If someone else has spare cycles to get to this before I do, here are some implementation hints:
In ABCL, SYS:ZIP is the interface for creating jar archives, which uses the zip compression/packaging scheme.
An example of creating a jar archive can be [found in ABCL-TEST::JAR-FILE-INIT][1].
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
(Found this old mail in my draftbox. I see that ABCL on Mac is still in need of some testing and debugging love: test/test-bundle.script test/stamp-propagation/test-stamp-propagation.lisp )
Yes, a test that simply reads a file out of a jar file, and fails on older versions of ASDF would be very nice to have.
Oh, such an ABCL specific test is quite easy: I guess I thought Faré was asking for something that ran on all implementations, which I didn’t quite understand.
I'd prefer a general test, but one that runs just on ABCL would be a good start.
But I must confess I dont really understand how to insert it into the ASDF test suite cleanly.
Best is to find an existing somewhat related test and extend it, or else copy it, e.g. test-system-pathnames or test-module-pathnames.
Should I be looking to add a foo.{script,lisp,asd} triple in the `asdf/test` directory with an assertion in foo.script?
I'd rather you don't use a new .asd, but def-test-system in the .script instead, unless your test is specifically about how .asd's are found.
How do I conditionalize the test to only be run on ABCL?
#+abcl around the abcl-specific parts is one way. If the test is entirely abcl, then as rpgoldman said, #-abcl (leave-test "This test is only for ABCL" 0)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Rocky's Lemma of Innovation Prevention Unless the results are known in advance, funding agencies will reject the proposal.
-
Faré -
Mark Evenson -
Robert P. Goldman