asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Finding out from where the .asd was loaded and/or referencing a non-executable data file
by Robert Dodier 16 Mar '18

16 Mar '18

Hi, I am resuming my tinkering on the Maxima interface to ASDF. I have bumped into a kind of minor problem for which I don't see a solution. Maxima can read .info files for documentation items. An index file (Lisp) which is created ahead of time (not run time) tells where the items are in the .info. The .asd, index, and .info are all in the same directory. Some code in the index file tells Maxima to read the .info from the same place from which the index is loaded (via *LOAD-PATHNAME*). That works great when the asd is loaded via LOAD-SOURCE-OP since *LOAD-PATHNAME* points to the directory where the .info file is. But when the asd is loaded via LOAD-OP, it doesn't work, since *LOAD-PATHNAME* points into the place that ASDF puts fasls. I gather from the ASDF reference manual that there isn't any way to load, without compiling, only the index file (I'm looking at "How do I mark a source file to be loaded only and not compiled?"). So I'm thinking about some other way to locate the .info file. Is there a special variable or something which tells the path from which the .asd is being loaded? I looked at the documentation and the list of external symbols but couldn't puzzle out anything. The more general idea is that the system contains a non-Lisp data file. Is there a general approach to work with that? Thanks for any light you can shed on this problem. Robert Dodier

3 7

Best Practice for an ASDF Variable Like *compile-file-failure-behaviour*
by Mark H. David 10 Mar '18

10 Mar '18

As has been discussed here over the years, asdf:*compile-file-failure-behaviour* is :warn on most platforms, but it is notoriously :error on #+sbcl. So what would you do if you wanted to change asdf:*compile-file-failure-behaviour* to be :warn on #+SBCL? How would you recommend to change it. Where? I don't want to really have to impose an init file on everyone. Also, I don't really want to necessarily make this global across every use of ASDF, but let's say I just want it to apply to one main system and all subsystems loaded as part of this. I cannot think of anything better than a top-level setq in the .asd file of the system, something like this? #+sbcl (setq asdf:*compile-file-failure-behaviour* :warn) What else can one do that's any better? Maybe there's a less crude way, like something like an around method that wraps around the compile/load. I'm really just barely a novice user, so I'm sorry this if this is such a naive question. If there's a simple example one could provide or point me to that does this, I'd appreciate it. Thanks, Mark

3 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

Patch: Add support for Mezzano
by Peter Housel 01 Mar '18

01 Mar '18

Enclosed is a patch (which can be applied using git am) that adds ASDF support for the Mezzano Common Lisp operating system. -Peter S. Housel-

2 1

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel