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

weirdness with compile-op and retry restart
by Attila Lendvai 21 Jul '17

21 Jul '17

dear devs, i have a system with a file that has a compilation error. i try to load it: (asdf:load-system :hu.dwim.web-server.application.test) it leads to an error with the following restart (notice its unusual wording, and that it's about the entire system, not just that one source file): 6: RETRY Retry completing compilation for #<HU.DWIM.TEST-SYSTEM "hu.dwim.web-server.application.test">. the rest FTR: 5: ACCEPT Continue, treating completing compilation for #<HU.DWIM.TEST-SYSTEM "hu.dwim.web-server.application.test"> as having been successful. 4: RETRY Retry ASDF operation. 3: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. if i touch the file and select the restart, then cl:compile-file doesn't get called and no compilation seems to happen. there used to be a restart to recompile the single source file that has failed. i'm on ASDF 3.2.1 and the very latest SBCL (i'm testing it for the current freeze) note: these systems have some customizations from hu.dwim.asdf, but not much changed there recently. is this something obvious that i'm failing to see, or should i dig deeper? what else would help? it's not a show-stopper for me, so feel free to ignore this. i'm writing this up more as offering help than asking for help. thanks for your time, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Understand and abide by the following self-evident principle, and you will be an anarchist: If there is something that would be wrong for you to do yourself, then you shouldn't ask anyone else to do it either.” — Larken Rose (1968–)

2 3

Testing new ASDF
by Robert Goldman 21 Jul '17

21 Jul '17

Our new version of ASDF has 5 failures for me on Linux, testing against the master branch. Is that what I should be testing, or should I be testing against the dev branch? The tests which are failing are: ecl-make-image.script ecl-prebuilt-systems.script test-bundle.script test-program.script test-require.script Thanks, r

3 4

make-build
by Faré 21 Jul '17

21 Jul '17

Dear Daniel, if you're willing to fork ASDF over make-build, would putting a make-build compatibility function back in ASDF make you adopt the upstream version again? I have an implementation for it at the end of https://gitlab.common-lisp.net/asdf/asdf/merge_requests/34 but I'd need you to provide some more test case (a simple one exists somewhere in some old version in git). There were many fixes in ASDF 3.2 and 3.3, including ECL-specific fixes, compared to the 3.1.7 from which you forked, and forking is just more work for both you and us. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Social peace will come when the socialists will love the poor more than they hate the rich. — Not Golda Meir

2 1

source-registry configuration
by Greg Bennett 20 Jul '17

20 Jul '17

Running under Linux Mint 18.1 64 bit, and either ccl or sbcl Apologies, I'm afraid I have made a mess of configuring the path to some .asd files. I believe that items 3,4,6,7,8 of Section 8.1 Configurations do not exist. I believe I have used item 5 as in Section 4.1 Configuring ASDF to find your systems. In ./config/common-lisp/source-registry.conf.d I once created the file gb-lisp.conf containing the single line (:tree "/home/gwbennett/asdf-tests") <- no trailing / instead of (:tree "/home/gwbennett/asdf-tests/") <- trailing / I have since replaced that file with source.conf holding just the line (:tree "/home/gwbennett/asdf-tests/") In the asdf-tests directory there is a file gb-a.asd and associated lisp files When I try (asdf:load-system "gb-a") I get (under ccl64 Version 1.11-r16812M) > Error: Is a directory : #P"/home/gwbennett/asdf-tests" > While executing: CCL::MAKE-FILE-STREAM, in process listener(1). Under sbcl 1.3.18 I get an analogous message, always pointing to the same pathname. If I remove the .conf file completely, restart either lisp, retry the load-system, the error persists. Some how I seem to have managed to get the incorrect specification squirreled away in asdf's memory in a way which survives not just restarting either lisp, but restarting linux too. What in the world have I managed to do ? More usefully, how do I undo it ? Thanks for advice and assistance. Cheers Greg Bennett

3 2

read-depend branch is ready for another review...
by Robert Goldman 17 Jul '17

17 Jul '17

Tests now passing on all implementations, and there's been substantial clean-up. Likely the first two commits on this branch should be merged with the plan branch directly, since they don't have anything to do with read dependencies per se. Then we could move on to reviewing (and then squash-merging) read-depends. Cheers, r

2 9

relocate/locate fasl files
by Greg Bennett 17 Jul '17

17 Jul '17

2 1

Updated read-depends branch
by Robert Goldman 10 Jul '17

10 Jul '17

Incorporated some of Fare's suggestions and also improved the testing.

1 0

the new read-depends branch is pushed
by Robert Goldman 30 Jun '17

30 Jun '17

This is a solution that seems to work well enough to be reviewed for merging.

2 1

Problem with adding input files...
by Robert Goldman 30 Jun '17

30 Jun '17

Recording the included files (from read-file-form and read-file-line) has so far failed to solve the problem of ASDF missing updates to the included files. I could use a little advice here. Running the test I have pushed, I tried tracing asdf/action:action-up-to-date-p. It is not called during the second invocation of (asdf:load-system "test-include") So at the moment I do not see how the flow of control works to decide whether or not it is necessary to redo the DEFINE-OP. And maybe DEFINE-OP isn't the operation that should be re-triggered by changes to the system definition file or included files? Is the right place for these new dependencies on included files DEFINE-OP or PREPARE-OP? thanks, r

2 7

Possible incompleteness in INPUT-FILES for DEFINE-OP
by Robert Goldman 30 Jun '17

30 Jun '17

I think I may have stumbled on an incompleteness in this method. Here's the test case: 1. Define a system. S1, with a version loaded from a version file; 2. Load S1 into session. 3. Hack hack hack. 4. Bump S1's version number in the version.lisp-expr file 5. Load S2 that depends on new version of S1. As far as I can tell, ASDF is simply checking the .asd file, not S1-version.lisp-expr, to see if it's stale. So my load in step 5 is failing. This is, I believe, because S1-version.lisp-expr is not in the set of INPUT-FILES for S1's DEFINE-OP. It's a little unsettling to change this on the fly, but I think the right thing is probably to push the version.lisp-expr file onto a set of ancillary dependencies when it's read. If this sounds right, I'll stick this in as a ticket, and try to find where we could inject a fix. Best, r

3 8