On Dec 19, 2013, at 17:23, Mark Evenson <evenson@panix.com> wrote: […]

I’ll take a look at the ABCL problem in the next day, reporting back to the list if I have a fix

Unfortunately, I have come to the end of a long day for me without much to report as I have spent most of my non-work time mucking with getting a virtualized version of Windows running/patched/configured in which to test the ABCL ASDF failures. It isn’t quite clear how to run the tests under Windows. I am using Cygwin, so I thought I could just ensure that ‘abcl’ is in my path and symlinked to ‘abcl.bat cygwin-bash$ sh run-tests.sh abcl but I get an “access is denied” message, which is odd as I can invoke `abcl` directly. Probably some faulty understanding on my part of cygwin v. DOS scripting. So, if someone can please provide a quick sketch of how to run the ASDF tests under Windows, I can try pick this up tomorrow. And if abcl is the only thing holding up a release, y’all might as well pull the trigger without the Bear, as the social aspect of holidays with family will place additional stress on my spare time. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

I have started cl-test-grid tests with the latest ASDF (git revision 38337a5) After SBCL and CCL tests complete we can run tests on the previous ASDF and compare results. The question: what is the previous stable and tested ASDF version? Best regards, - Anton 27.12.2013, 17:34, "Mark Evenson" <evenson@panix.com>:

On Dec 20, 2013, at 22:34, Mark Evenson <evenson@panix.com> wrote:

[…]

...

 It isn’t quite clear how to run the tests under Windows.  I am using Cygwin, so I thought I could just ensure that ‘abcl’ is in my path and symlinked to ‘abcl.bat

         cygwin-bash$ sh run-tests.sh abcl

 but I get an “access is denied” message, which is odd as I can invoke `abcl` directly.  Probably some faulty understanding on my part of cygwin v. DOS scripting.

A couple of notes on running ASDF tests under Windows:

1.  The “Access is denied” message comes from problems with mismatched NTFS permissions.  I think it was the result of using “hg clone" in the Windows "System Administrator” role which creates directories don’t automatically have all necessary permissions for writes.  Or something.  The solution for me was to use the “Edit” dialog accessed “Properties >> Security” popup from Windows Explorer to recursively set “Full Control” for “Everyone” from the root `asdf` folder.  Those who wish to contribute a more nuanced understanding of what Windows is trying to protect against are invited to explain in a more articulate manner the more proper set of restricted permissions to grant.

2.  Using cygwin, one cannot get ‘test/run-tests.sh’ to use the ‘abcl.bat’ Windows batch script to invoke ABCL, as it fails with problems in escaping the VERTICAL_LINE (#\|) from some being interpreted as a pipe operation by some part of the invocation chain.  The solution is to use the Bourne-shell ‘abcl’ invocation script.

More soon…

-- "A screaming comes across the sky.  It has happened before but there is nothing to compare to it now."

31.12.2013, 10:31, "Faré" <fahree@gmail.com>:

Dear Anton,

On Tue, Dec 31, 2013 at 1:25 AM, Anton Vodonosov <avodonosov@yandex.ru> wrote:

...

 I have started cl-test-grid tests with the latest ASDF (git revision 38337a5)  After SBCL and CCL tests complete we can run tests on the previous ASDF  and compare results.

Thanks a whole lot for cl-test-grid, it has been extremely valuable in the past, especially when initially releasing ASDF 3.

You are welcome.

...

 The question: what is the previous stable and tested ASDF version?

I suppose the real question is: which version did YOU last use?

Yes, but I thought you may have some additional information form non cl-test-grid testing. When we tested with cl-test-grid, ABCL, CMUCL, CCL, CLISP, ECL, SBCL were tested on 2.31.8 http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html The latest cl-test-grid cycle was for ASDF 2.32.35, it was tested on CCL, CLISP, ECL, SBCL on Linux. http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-23.html So, as you see we ended up testing last fixes only on some lisps, not all lisps. Probably that's because it was stabilizing period and the fixes were for concrete bugs. Still, we didn't make a firm "rollback" point - an ASDF version where we ensured we have no regressions on all lisps. For now I suggest to consider 2.32.35 as more or less reliable previous comparison point, where all regressions were proved to be not ASDF bugs, but bugs in libraries, and were reported to the library maintainers. I hope in this ASDF release, we will test the released version on maximum number of lisps, so that in future we will have reliable comparison point.

But then, you'd have to check with both old and new Quicklisp.

I am going to run tests of both previous stable ASDF version and the current HEAD on the same Quicklisp - 2013-12-13.

I suppose that you should compare with whatever comes with the implementation.

OK, we can do this too - we will compare result for the latest ASDF with the results for the "main", unpatched quicklisp, which uses ASDF coming with the implementation. It also would be nice to compare with some concrete previous stable ASDF version, as described above, to be sure we cover full ASDF evolution on all lisps.

Therefore, for SBCL, that would be 3.0.2, and for CCL, 3.0.3. If you need the same in both cases, make it ASDF 3.0.3.

I think the further back in time we go, the better, for full coverage. I suggest compare the HEAD with 2.32.35. Then we can also test with some intermediate version, like 3.0.3, to ensure we not only don't have regressions since 2.32.35, but also don't lose improvements introduced in 3.0.3 (if any). Best regards, - Anton

Hi Mark, Here is my toplevel "run" script which I run from cygwin, from the parent of the git clone'd asdf/ directory. I commented all the ASDF_TEST_LISPS for windows so as to leave only abcl. You should just have to edit the line export ABCL=... to match the location of your abcl executable (yes, if you're running through cygwin, then you can use the bare "abcl" executable, which itself is a shell script and will be handled properly, as long as "java" is in the execution path of the cygwin bash shell). When you run this "run" script, it will create asdf-windows/ directory to do the actual testing. If you run on MacOS and/or Linux it will make similarly named subdirectories; this allows hypothetically running the tests in parallel on several virtual machines from the same shared parent directory. Regards and Happy Holidays, Dave On Fri, Dec 20, 2013 at 4:34 PM, Mark Evenson <evenson@panix.com> wrote:

On Dec 19, 2013, at 17:23, Mark Evenson <evenson@panix.com> wrote:

[…]

...

I’ll take a look at the ABCL problem in the next day, reporting back to

the list if I have a fix

Unfortunately, I have come to the end of a long day for me without much to report as I have spent most of my non-work time mucking with getting a virtualized version of Windows running/patched/configured in which to test the ABCL ASDF failures.

It isn’t quite clear how to run the tests under Windows. I am using Cygwin, so I thought I could just ensure that ‘abcl’ is in my path and symlinked to ‘abcl.bat

cygwin-bash$ sh run-tests.sh abcl

but I get an “access is denied” message, which is odd as I can invoke `abcl` directly. Probably some faulty understanding on my part of cygwin v. DOS scripting.

So, if someone can please provide a quick sketch of how to run the ASDF tests under Windows, I can try pick this up tomorrow.

And if abcl is the only thing holding up a release, y’all might as well pull the trigger without the Bear, as the social aspect of holidays with family will place additional stress on my spare time.

-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

On Thu, Dec 19, 2013 at 11:24 AM, Dave Cooper <david.cooper@genworks.com> wrote:

I had a couple failures: abcl/windows, clisp/windows, clisp/linux:

https://www.dropbox.com/sh/jc2cqwpkp06dupm/1IBEQ9XyKi/asdf-failures/3.1.0.24

OK, can you try the latest, 3.1.0.26, where undo a previous hack and punt for the ending space from cmd.exe's echo on Windows? It also has some test fixes for clisp on Linux as compared to 3.1.0.24. Also, if you see asdf-pathname-test failures a the test report, can you attach the corresponding build/results/clisp-pathnames.text? Thanks a lot for your patient testing! I also updated the TODO and Changelog, and took the liberty of implementing that optimization I had been talking about: when upgrading from forward-compatible-enough version (i.e. 2.27 or later), have a softer upgrade that doesn't clear the defined system table or override some hook variables. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org man, n: a computer that can pass the Turing test. — Corey Sweeney

On Thu, Dec 19, 2013 at 4:58 PM, Dave Cooper <david.cooper@genworks.com> wrote:

Finished clisp on Linux, still the one failure for pathname, here is the -test.text and -pathnames.text:

https://www.dropbox.com/sh/jc2cqwpkp06dupm/Jmq7a3BhtZ/asdf-failures/3.1.0.26

Windows tests still running, results will be copied into windows/ folder at above location.

It's working for me on a native Linux setup, and I'm way too tired to try and find out what's going on there, probably related to your weird virtual machine and filesystem mounts. Are you somehow running the test in parallel on two implementations at once sharing the filesystem? That could explain the failures, though not why it happens exactly for half the file tests. I don't see any obvious pattern in the failures, but I admit I never understood this test that well. All files seem to be affected. Maybe, when there are more than a handful failures, we should print successful tests as well as failing tests, so patterns are more obvious to see? I'm also too tired to implement that at this point. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'm a polyatheist — there are many gods I don't believe in. — Dan Fouts

On Thu, Dec 19, 2013 at 8:02 PM, Faré <fahree@gmail.com> wrote:

OK, I'm sick and tired, but I'm even more obsessive and procrastinating, so I hacked asdf-pathname-test some more.

This file is a big pile of fail, some of it maybe due to the three-star programming of the original by janderson, a lot of it no doubt due to my trying and failing to make sense of it.

Please try again with asdf 3.1.0.27, which will not fix any bug, but will hopefully yield more useful debugging output.

I will. I can also try with using the local filesystem instead of the "weird" shared filesystem from the virtual host. Will do the 3.1.0.27 with the current setup first, and try that next. Sticking with Linux only until things settle out then will revisit the Windows testing. -- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

On Fri, Dec 20, 2013 at 12:02 AM, Dave Cooper <david.cooper@genworks.com> wrote:

...

I will. I can also try with using the local filesystem instead of the "weird" shared filesystem from the virtual host. Will do the 3.1.0.27 with the current setup first, and try that next. Sticking with Linux only until things settle out then will revisit the Windows testing.

Indeed when running with local filesystem in the Linux VM, all 48 tests pass on clisp.

The failures for 3.1.0.27 are for the mounted filesystem and can be seen here:

CLISP tries to open a file for writing on your filesystem, and gets a UNIX error 71 (EPROTO): Protocol error I suppose this is a CLISP bug — maybe it's trying a filesystem syscall not available via NFS (or however your filesystem is mounted — how is that?). CLISP also miserably fails upgrade for ASDF 2.27 to 2.31, with: TEST ABORTED: APPLY: undefined function NIL Script failed, with no backtrace. The proximate problem was UIOP was not defined (it was called asdf/driver then), but asdf::pathname-equal was, which was then erroneously interned from uiop — but then, why was CLISP the only one to fail that way? Because CLISP was the only implementation for which the *test-directory* is not EQUAL, but only PATHNAME-EQUAL to (asdf::pathname-directory-pathname (nth-value 2 (asdf::locate-system :test-asdf)): the former, derived from *LOAD-PATHNAME*, has :version :newest, and the latter, derived from DIRECTORY, has :version nil. Also, it would be nice if CLISP accepted (require :asdf) as well as (require "ASDF"), but oh well. I also fixed the way CLISP handles function redefinition, and it looks upgrade from versions older than 2.27 now works without punting. All that was needed was removing gf methods before your fmakunbound, apparently. That was a big issue since 2.27. CMUCL still fails horribly with PCL errors during upgrade, though. Meh. This was your minute of CL (pathname and CLOS) portability horrors. Welcome to asdf 3.1.0.32. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life — so I became a scientist. This is like becoming an archbishop so you can meet girls." — Matt Cartmill

The Linux CLISP failures are the same as before: all file accesses fail, probably due to the weird filesharing setup, that doesn't provide whatever syscalls that CLISP relies on. The Windows CLISP failures have all directory accesses fail, with file access working, so I suppose it's balancing the karma. The run-program tests also fail, though it's hard to tell whether it's due to the system() call (do we need to explicitly call CMD.EXE?) or to some file access failure during redirection. I would need access to a Windows machine to tell... Does anyone have a Windows image for KVM or some such? The Windows ABCL failures are the same error in SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS. The bug can be reproduced even on Linux by copy-pasting from the backtrace: (apply 'funcall ' (SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS (:ABSOLUTE "users" "dcooper8" "asdf" "asdf-windows" "test" "preflight-checks") (:ABSOLUTE "users" "dcooper8" "asdf" "asdf-windows" :WILD-INFERIORS) (:ABSOLUTE "users" "dcooper8" "asdf" "asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64" "asdf" :WILD-INFERIORS) NIL)) (apply 'SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS '( (:ABSOLUTE "users" "dcooper8" "asdf" "asdf-windows" "test" "preflight-checks") (:ABSOLUTE "Users" "dcooper8" "asdf" "asdf-windows" :WILD-INFERIORS) (:ABSOLUTE "Users" "dcooper8" "asdf" "asdf-windows" "build" "fasls" "abcl-1.2.1-fasl42-win-x64" "asdf" :WILD-INFERIORS) NIL)) fails because of the upper-case U in Users, but not in users. Why should ABCL care about the case of directory components in a TRANSLATE-PATHNAME operation, I don't know. Maybe this is leakage from sharing some misfactored bits with the implementation of logical(!?)-pathname's, that have some restriction in the source pattern? More probably, it's a very misleading error message from ABCL: "Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS". Instead it should be something like "Error in TRANSLATE-PATHNAME: source ~S does not match from-wildcard ~S". Dave, why is the source "users" lower case when the rest is upper-case? Is it a bug in your configuration, or is ABCL or some other software trying to "normalize" the name, and ending up confusing TRANSLATE-PATHNAME? But why is it happening only for these two tests? Some more inspection shows that these two tests are the only ones using (defsystem ... :pathname "some_string" :source-file nil ...) so this suggests something funky happening in determine-system-directory. Can you run only one of these tests while tracing RESOLVE-SYMLINKS*, DETERMINE-SYSTEM-DIRECTORY, ENSURE-ABSOLUTE-PATHNAME, LOAD-PATHNAME, GET-PATHNAME-DEFAULTS, and see who's introducing a lower-case "users"? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reality must take precedence over public relations, for Mother Nature cannot be fooled. — R.P. Feynman

Managed to crash both my virtual machines while trying to do some manipulation of a Lidar (LAS) geodata file containing almost 2 million 3D points on the host and gobbling up all physical RAM... will have to fire these VMs up again tomorrow... On Thu, Dec 19, 2013 at 9:47 PM, Faré <fahree@gmail.com> wrote:

Well, my procrastination has yielded renewed XCL support, for what it's worth (admittedly not much, besides testing).

PS: Mark, if you have more debugging cycles, check the abcl workarounds in our test framework: grep '#.*abcl' *.script */*.lisp Each of them might be an ABCL bug, or may have to be annotated as not a bug. test-url* are not a bug.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The truth of a proposition has nothing to do with its credibility. And vice versa. — Robert Heinlein, "Time Enough For Love"

On Thu, Dec 19, 2013 at 8:36 PM, Dave Cooper <david.cooper@genworks.com> wrote:

...

On Thu, Dec 19, 2013 at 8:02 PM, Faré <fahree@gmail.com> wrote:

...

OK, I'm sick and tired, but I'm even more obsessive and procrastinating, so I hacked asdf-pathname-test some more.

This file is a big pile of fail, some of it maybe due to the three-star programming of the original by janderson, a lot of it no doubt due to my trying and failing to make sense of it.

Please try again with asdf 3.1.0.27, which will not fix any bug, but will hopefully yield more useful debugging output.

I will. I can also try with using the local filesystem instead of the "weird" shared filesystem from the virtual host. Will do the 3.1.0.27

with

...

the current setup first, and try that next. Sticking with Linux only until things settle out then will revisit the Windows testing.

-- My Best,

Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699