On 1/30/16 Jan 30 -12:23 PM, Robert P. Goldman wrote:

I'll check the current version on Mac, Linux and Windows, as feasible.

This won't be until Monday, I'm afraid -- I need the console in the office to deal with the Windows VM, and the host machine is running experiments over the weekend, anyway.

If I can, I will also add a couple of debugging functions to help people figure out when their configs go awry. We had correspondence that gave calls top make, but they are kind of complicated.

Sent from my iPhone

...

On Jan 28, 2016, at 10:46, Faré <fahree@gmail.com> wrote:

There have been many small fixes since ASDF 3.1.6 in last October, and I suppose it's time for a new minor release.

Robert, do you want to handle the release? Are you done with it? What do you think?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself. — Rumi (1207–1273)

On 2/11/16 Feb 11 -8:17 PM, Faré wrote:

Pinging again for an ASDF 3.1.7 — there are fixes in there that some recent CFFI extensions depend on.

I may have a Windows VM and time to use it next week, for testing.

In the meantime, all tests (including upgrade) pass for me on Linux amd64 with ccl clisp sbcl ecl ecl_bytecodes cmucl allegro lispworks mkcl abcl allegromodern — though I had some flakiness with test-program.script on clisp, that I haven't investigated too much.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Malthusianism: because growth may stop within centuries, we must use extreme violence to put an end to it now and make everyone poor today.

I'm AFK for the weekend, but I will try to rerun all the tests on Monday and then release 3.1.7. cheers, r

I'm still finding oddities in the test process inside/outside of make.

First test on ccl failed on test-sysdef-asdf.script (inside make test-all-no-upgrade-no-stop):

Load ASDF with proper configuration: should find asdf.asd from the source above ;Loading #P"/Users/rpg/lisp/asdf/asdf.asd"... ;Loading #P"/Users/rpg/lisp/asdf/uiop/uiop.asd"... ;Loading #P"/Users/rpg/lisp/asdf/build/fasls/ccl-1.10-f96-macosx-x64/asdf/build/asdf.dx64fsl"... ; Upgrading ASDF from version 3.1.6.11 to version 3.1.6.12 TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (SYSTEM-SOURCE-FILE (FIND-SYSTEM :ASDF)) evaluates to #P"/Users/rpg/lisp/asdf/asdf.asd" (21065C10) : 1 (RAW-PRINT-BACKTRACE :STREAM #<BASIC-CHARACTER-OUTPUT-STREAM UTF-8 (FILE/1) #x30200044C77D> :COUNT 69 :CONDITION #<SIMPLE-ERROR #x302000B2215D>) 181 (&KEY :STREAM :COUNT :CONDITION) STREAM: #<BASIC-CHARACTER-OUTPUT-STREAM UTF-8 (FILE/1) #x30200044C77D> COUNT: 69 CONDITION: #<SIMPLE-ERROR #x302000B2215D>

*DEBUG-IO*: #<BASIC-CHARACTER-OUTPUT-STREAM UTF-8 (FILE/1) #x30200044C77D>

this failure occurs in this block:

(DBG "Load ASDF with proper configuration: should find asdf.asd from the source above") (initialize-source-registry `(:source-registry (:directory ,*asdf-directory*) (:directory ,*uiop-directory*) :ignore-inherited-configuration)) (clear-system "asdf") (load-system :asdf) ;; This time we found it, but it was skipped because the version was the same (assert-equal nil (system-source-file (find-system :asdf)))

Note the remarks about upgrading from one pre-release version of ASDF to another. This suggests to me that there's some leakage of prior state into the tests -- something isn't properly cleared.

Second test of make test l=ccl t=test-sysdef-asdf.script succeeds.

I suspect that there's some leakage of state in the filesystem

That's weird. This kind of failure doesn't fit in my understanding of what could happen, unless you have two make processes running in parallel in the same filesystem. That said, I admit most of the useful knowledge is paged out of my active memory. I admit that working on both bazel.io and asdf makes me sorry for both systems in some way and want to have a best of both worlds. But not so much that I've started working on it yet. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When you've seen one nuclear war, you've seen them all.