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

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

Multiple processing compiling the same file
by Jim Newton 31 Jan '18

31 Jan '18

If I run several sbcl processes on different nodes in my compute cluster, it might happen that two different runs notice the same file needs to be recompiled (via asdf), and they might try to compile it at the same time. What is the best way to prevent this? I see in the asdf documentation that there is an asdf:*user-cache* variable whose value is the path name of the directory where asdf compiles into. Would it be advisable for my to arrange so that asdf:*user-cache* is a function of the pid and hostname and perhaps thread-id (if such a thing exists) to avoid such collisions? Or is there some better way to handle this which is build into asdf?

4 9

spurious reloads with systems not following the foo/bar naming convention?
by Attila Lendvai 31 Jan '18

31 Jan '18

dear list, i noticed it with CXML, but here's a smaller system to reproduce it with: git clone https://github.com/mmaul/cl-influxdb.git (ql:quickload :cl-influxdb) (asdf:load-system :cl-influxdb.examples) each time the examples are loaded the main systems gets reloaded. i see something interesting in the output that may be related: WARNING: Computing just-done stamp in plan NIL for action (ASDF/LISP-ACTION:PREPARE-OP "cl-influxdb" "cl-influxdb"), but dependency (ASDF/LISP-ACTION:LOAD-OP "cl-influxdb" "package") wasn't done yet! CL-USER> (asdf:asdf-version) "3.3.1.1" CL-USER> (lisp-implementation-version) "1.4.1.98.hu.dwim.3-a860f4780" -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “With or without religion, good people can behave well and bad people can do evil; but for good people to do evil — that takes religion.” — Steven Weinberg (1933–), 'A Designer Universe?'

2 3

Including uiop and not asdf in a built application
by Dave Cooper 16 Jan '18

16 Jan '18

Hi (I'm not sure who is current lead maintainer, but hopefully the group will have some wisdom), First of all, Happy New Year and thank you to whomever is monitoring this list. Your efforts are highly appreciated. Our build process for Gendl and GDL for the past several years has involved using monolithic-compile-bundle-op to make concatenated fasls, then loading these fasls into an empty image to create the final build. We do depend on (and include) uiop, but not asdf, in our final build product. In order to have uiop available separately for inclusion in the monolithic-compile-bundles, we have been putting a copy of the uiop/ directory (of the same version as the ASDF we're using) into quicklisp/local-projects/. Some time between ASDF 3.2.0.1 and ASDF 3.3.1, the function check-not-old-asdf-system got modified to add "uiop" to the test (first line of the function). This results (in ASDF 3.3.1) in a same-version uiop not getting loaded at all into a monolithic-compile-bundle, even if the system of said monolithic-compile-bundle contains a dependency on uiop and uiop is available in quicklisp/local-projects/. For this reason, out-of-the-box ASDF 3.3.1 was not working for our build process. I have "fixed" the problem temporarily by modifying my local asdf.lisp to remove the "uiop" from the test, i.e. I've replaced (or (not (member name '("asdf" "uiop") :test 'equal)) .... with (or (not (member name '("asdf") :test 'equal)) ... as the first line of the defun check-not-old-asdf-system. Question: Is there a supported way to do what I'm trying to do, without modifying the ASDF source code? Intuitively, it seems to me that we should be able to include uiop in build products using monolithic-compile-bundle-op, without including asdf. -- My Best, Dave Cooper, david.cooper(a)gen.works genworks.com, gendl.org +1 248-330-2979

3 4

package pollution by asdf
by Sam Steingold 16 Jan '18

16 Jan '18

Hi, When I start CLISP with the full linking set (i.e., including all possible extensions), I have 63 packages in (list-all-packages), and 37 of them (more than half!) comes from asdf (22 ASDF/* and 15 UIOP/*). I wonder if I am the only one unhappy about this. In particular, has it ever been considered that it might be a good idea to limit the number of packages asdf creates? Thanks. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://www.dhimmitude.org http://honestreporting.com http://no2bds.org WHO ATE MY BREAKFAST PANTS?

3 2

Syntax control code
by Robert Goldman 07 Jan '18

07 Jan '18

I just pushed an edit of syntax-control.md in which I try to capture the terminology. Status: several Allegro failures break for me on test-syntax-control. Results from Linux: build/results/allegro8_64-test.text build/results/allegro8_64_s-test.text build/results/allegromodern8_64-test.text build/results/allegromodern8_64_s-test.text build/results/allegromodern_64-test.text build/results/allegromodern_64_s-test.text These failures seem to be due to NAMED-READTABLES not working properly on these platforms, rather than on anything ASDF itself does. Concern: As I was reading over syntax-control.md, it was brought home to me that the ASDF shared syntax is initialized to the *initial syntax* on the host implementation, rather than the standard syntax of ANSI CL. My understanding is that this is done for backwards-compatibility with some QL systems that assume they have access to extended syntax from some implementation(s). I'm concerned that this will create a maintenance headache going forward just so someone *else* can avoid making some minor clean-up. Should we just suck it up and make the shared syntax start out with the initial syntax? Why not break it now, and save ourselves trouble later? Also, it seems like "initial syntax" is not well-defined, even on a single implementation, since ASDF might be loaded at arbitrary times, possibly after modifications to the "initial initial" readtable. Finally, going forward, people will be yelling at *us* if implementations change their initial syntax. Unless there's a really important reason to keep this, I think we should kill it.

4 4