February 2018 - asdf-devel - mailman3.common-lisp.net

Testing for ASDF 3.3.2 and beyond?
by Faré 27 Apr '18

27 Apr '18

Dear Anton, can you run the below tests, in order or priority? 1- Can you test what is currently in master, a.k.a. 3.3.1.3, as a release candidate for 3.3.2? It has been too long since 3.3.1 was released with several bugs that have impacted Quicklisp users. 2- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0? We want to merge syntax control, but it's a significant enough change that we don't want it at the same time as the bug fixes. Also... 3- Can you test what is currently in the syntax-control branch as a release candidate for 3.3.3 or 3.4.0, but with the following addition just after you load asdf but before you start using it: (defparameter uiop:*shared-readtable* (copy-readtable nil)) ? Indeed, we want to see what breaks if we disable extensions implementation-specific reader extensions. Test most important on CCL. I don't expect much breakage on other implementations, but it may exist, too. 4- While you're at it, can you also run the test, at least on sbcl, with (defparameter uiop:*shared-readtable* uiop:*standard-readtable*)) ? This will detect what breaks when we make the default readtable read-only. The thing is, we really want to have this syntax control, but we also want to preserve backward compatibility, and we can't make asdf stricter until every client is fixed (famous last word; of course we failed at exactly that in 3.3.1 — we could build correctly, but would also spuriously rebuild if secondary systems were misnamed; fixed in 3.3.1.3). https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-con… https://gitlab.common-lisp.net/asdf/asdf/merge_requests/86 http://blog.quicklisp.org/2018/01/build-failures-with-asdf-331.html —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A friend once asked me if I had ever considered terrorism as a means for political change. I replied that yes, I had considered it... and rejected it. Because it only causes change for the worse. Killing innocent people does not promote a culture of peaceful interaction.

5 26

"deprecated recursive use" warning
by Attila Lendvai 01 Apr '18

01 Apr '18

dear list, shall i be concerned about this? WARNING: Deprecated recursive use of (ASDF/OPERATE:OPERATE 'ASDF/LISP-ACTION:LOAD-OP '("cffi/c2ffi-generator")) while visiting (CFFI/C2FFI::GENERATE-LISP-OP "hu.dwim.zlib" "c2ffi-spec" "zlib.h") - please use proper dependencies instead it happens due to this in cffi/src/c2ffi/asdf.lisp: (defmethod perform ((op generate-lisp-op) (c c2ffi-file)) ... (unless (component-loaded-p :cffi/c2ffi-generator) (load-system :cffi/c2ffi-generator)) ... ) that system only needs to get loaded when the action is executed. or is it safe to ignore that warning long term? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If we have the truth, it cannot be harmed by investigation. If we have not the truth, it ought to be harmed.” — J. Reuben Clark (1871–1961)

4 7

package-inferred-systems and primary-system-name
by Eric Timmons 08 Mar '18

08 Mar '18

If a have a package-inferred-systems "a" and "a/b/c", the following code used to return "a": (primary-system-name (find-system "a/b/c")) But after commit 069cd2a6 it returns nil. Happy to patch it, but I wanted to check how to do it before starting. The root cause right now is that system-source-file returns nil for the inferred systems. The easiest fix would be to have it return the asd file for the primary system. That's probably not *technically* correct since the system isn't actually defined in that file, but it's probably correct in the principle of least surprise sense. Thoughts? -Eric

3 4

test-bundle
by Robert Goldman 21 Feb '18

21 Feb '18

I still see these "dependency not done" warnings in test-bundle on SBCL and other implementations (I haven't checked them all, but at least my big three: SBCL, Allegro, and CCL). ``` Running test-bundle.script with sbcl-1.4.3-macosx-x64 ; loading #P"/Users/rpg/lisp/asdf/test/test-bundle.script" ; Registering system test-asdf ;; loading #P"/Users/rpg/lisp/asdf/test/test-asdf.asd" TEST-BUNDLE ASDF-TEST::*BUNDLE-1* => #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-1--system.fasl" ASDF-TEST::*BUNDLE-2* => #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-2--system.fasl" ;; loading #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-1--system.fasl" WARNING: Computing just-done stamp for action (LOAD-OP "test-asdf/bundle-1"), but dependency (LOAD-OP "test-asdf/bundle-1" "file1") wasn't done yet! WARNING: Computing just-done stamp for action (LOAD-OP "test-asdf/bundle-1"), but dependency (LOAD-OP "test-asdf/bundle-1" "file3") wasn't done yet! WARNING: Computing just-done stamp for action (LOAD-OP "test-asdf/bundle-1"), but dependency (COMPILE-OP "test-asdf/bundle-1") wasn't done yet! ;; loading #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/file1.fasl" ;; loading #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/file3.fasl" ;; loading #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.4.3-macosx-x64/asdf/test/test-asdf/bundle-2--system.fasl" WARNING: Computing just-done stamp for action (LOAD-OP "test-asdf/bundle-2"), but dependency (LOAD-OP "test-asdf/bundle-2" "file2") wasn't done yet! WARNING: Computing just-done stamp for action (LOAD-OP "test-asdf/bundle-2"), but dependency (COMPILE-OP "test-asdf/bundle-2") wasn't done yet! ``` This seems like a bug somewhere, right? And it must be an ASDF bug, probably in the definition of LOAD-OP for bundles. So, even after the last email, I'm inclined to hold up a release until I understand this bug and kill it.

2 3

Re: Issues with package location information on SBCL
by Faré 21 Feb '18

21 Feb '18

On Mon, Feb 19, 2018 at 7:03 PM, Eric Timmons <etimmons(a)mit.edu> wrote: > Glad to help! I've also opened the following bug on SBCL to let them know > about it: https://bugs.launchpad.net/sbcl/+bug/1750466. > Thanks! > Also, I checked that nothing else in ASDF uses `parse-define-package-form`, > but I somehow missed until just now that it's actually exported from uiop > =/. Is there any concern about another library using it? If so, I can try to > fix it in such a way that the output of `parse-define-package-form` is > unchanged. > I wouldn't worry about that: grepping through quicklisp systems reveals no user. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It costs the nation millions to keep Gandhi living in poverty — Sarojini Naidu

2 2

Releasing 3.3.2
by Robert Goldman 20 Feb '18

20 Feb '18

I think we are ready to release 3.3.1.5 as 3.3.2 I am quite busy this week, so it will probably take me a while to get through the necessary drudgery to actually make the release, but there is a good population of fixes to send out, so I'll make it happen. Best, r

1 0

Test-multiple
by Robert Goldman 20 Feb '18

20 Feb '18

Faré --- Would you please add some comments to test-multiple? I got a failure on that with MKCL under jenkins on linux, but cannot replicate that failure running it myself. There's no comment saying what this is supposed to test, other than the name, which suggests that it's about testing where there are ... multiple systems defined (incorrectly) in one .asd file? the same systems defined in multiple .asd files? The test checks to make sure (I believe) that a variable is not rebound when we ask to reload a system, but not how this pertains to correct ASDF function. thanks! r

3 7

Issues with package location information on SBCL
by Eric Timmons 17 Feb '18

17 Feb '18

I've started testing ASDF 3.3.1.3 with my group's code on SBCL 1.4.4 and noticed some issues with uiop:define-package (due to commit 8281e011). First, when compiling ASDF I get 456 compilation notes (https://pastebin.com/NnRUKGWe) I get the same notes when using uiop:define-package in our code as well. I honestly think this is an issue of SBCL being over aggressive. It's also odd because if the recording of the source location is removed, then the notes aren't produced. It appears this started happening in SBCL 1.4.1 (potentially due to commit af5e2ed1e). The volume of notes (especially when using package-inferred-system) can drown out real issues. I'll likely report this as an issue to SBCL since the keywords *should* be constant and the source transform for apply doesn't seem to be preserving that. However, it could also be fixed in ASDF by changing the apply to a funcall in the define-package expansion (patch 2). Second, the comma on (sb-c:source-location) seems to cause the source location for the package to always point to the body of the define-package macro. Patch 1 changes this so that form is evaluated after the macro is expanded. I didn't test this on anything earlier than SBCL 1.4.4, but I don't believe this behavior is version dependent. -Eric

2 1

hu.dwim.zlib broke; broken operation-done-p
by Attila Lendvai 04 Feb '18

04 Feb '18

if you issue the following (available in quicklisp): (asdf:load-system :hu.dwim.zlib) then for the first time it should generate a lisp file, which then gets compiled and loaded. issuing it for the second time shouldn't do anything, but since some revisions it regenerates the lisp file every time. the relevant code is somewhere around here: https://github.com/cffi/cffi/blob/master/src/c2ffi/asdf.lisp#L135 i tried to trace the INPUT-FILES, OUTPUT-FILES, PERFORM, OPERATION-DONE-P methods, but i don't see anything wrong. one unusual thing is that the output of GENERATE-LISP-OP goes into the src/ directory, not to the usual fasl output dir. same applies to GENERATE-SPEC-OP. any ideas how to debug this? or what to look at? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “For an instant I think I saw. I saw the loneliness of man as a gigantic wave which had been frozen in front of me, held back by the invisible wall of a metaphor.” — Carlos Castaneda (1925–1998), 'Journey to Ixtlan' (1972)

2 6