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

Introspecting test suite passing/failing
by Mark Evenson 07 Jun '18

07 Jun '18

We use ASDF to encapsulate the building and testing many systems under an automated test runner. For a given system, ASDF:TEST-SYSTEM always returns boolean truth as long as the invocation of the underlying test suite succeeds. This means there is no programatic way to provide a boolean as to whether all the tests passed or not on the invocation of a test suite to the invoker of ASDF:TEST-SYSTEM. It seems that this issue has been raised before, as the ASDF manual documents TEST-OP <https://www.common-lisp.net/project/asdf/asdf/Predefined-operations-of-ASDF…> with: > The results of this operation are not defined by ASDF. It has proven difficult > to define how the test operation should signal its results to the user in a way > that is compatible with all of the various test libraries and test techniques > in use in the community, and given the fact that ASDF operations do not return > a value indicating success or failure. For those willing to go to the effort, > we suggest defining conditions to signal when a test-op fails, and storing in > those conditions information that describes which tests fail. Is this still the best current practice to introspect the situation of failing tests? Can someone point me to an example implementation of this technique? -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 12

Pushed fix for SBCL deferred warnings as 3.3.2.1
by Robert Goldman 05 Jun '18

05 Jun '18

Squashed and merged this, pushed, and deleted the feature branch. Thanks to Eric Timmons for detecting the bug, and to Fare and Attila for reviewing the fix. We can think about a bug fix release sometime soon. I think right before merging the syntax fix, which should give us the basis for 3.4 Best to all, r

2 1

Last call for suggestions on merge request 95 (fix deferred warnings on SBCL)
by Robert Goldman 01 Jun '18

01 Jun '18

I believe all the critiques are now addressed. I am rerunning the tests on Mac and Linux, and if all goes well with squash-merge this topic branch to master. So if there are any last issues, please let me know. thanks, r

1 0

New candidate patch for DEFERRED-WARNINGS on SBCL
by Robert Goldman 31 May '18

31 May '18

Many thanks to Attila and Fare for suggesting ways to rewrite my original patch. New version now available in the repo. Note: has not been tested on *old* SBCL yet: I will do that later today when I get to the office. Best, r

1 0

Fixing deferred warnings on SBCL 1.4.7+
by Robert Goldman 30 May '18

30 May '18

OK, I have pushed a better solution to gitlab on cl.net, as merge request 95. The history of this branch is a little messy, so I will squash-merge it later. But I would definitely appreciate other eyes on. I had hoped to localize the fix, but it was too hard for me -- getting it right involved excruciatingly complex dealing with evaluation at read, compile, and load times, and the difference between loading ASDF as a big single file and as an ASDF system itself. I'll plan to merge this into master at the end of the week unless I hear some screams before then. P.S. I created a milestone for a bug fix release, but mis-named it, and I don't seem to be able to edit it. 😜 Cheers, r

1 0

Deferred warnings broken on SBCL 1.4.7
by Eric Timmons 30 May '18

30 May '18

Looks like SBCL 1.4.7 changed the slots of sb-c::compiler-error-context (in particular enclosing-source -> %enclosing-source, source -> %source, and original-source was removed). As a result, deferred warnings are broken. Attached is the output of `./run-tests.sh sbcl test-deferred-warnings.script` -Eric

3 8

Re: asdf-announce post from nimiux@gentoo.org requires approval
by Faré 05 May '18

05 May '18

Chema Alonso asked: > Where can I download the 3.3.2 tarball? > > Normally I get it from here: > > https://common-lisp.net/project/asdf/archives/ > > But I can't find it right now. > > Thanks. > I took the liberty of running "make archive publish-archive" from the release branch. The tarballs should now all be present. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The hacker: someone who figured things out and made something cool happen. — Alan Schmitt

1 0

ASDF 3.3.2 Released
by Robert Goldman 04 May '18

04 May '18

Today we release ASDF 3.3.2, the second bugfix release for the 3.3 release series. Of primary interest in this release are 1. Multiple fixes in handling misnamed (or "legacy-named," if you prefer) secondary systems ("foo-test" instead of "foo/test"). Thanks to Eric Timmons, there is also a similar fix for package-inferred-systems. 2. Fix an annoying warning message for compute-action-stamp. 3. Add support for the Mezzano implementation (thanks to E. Housel, H. Harrington). 4. Miscellaneous minor fixes and documentation tweaks. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.2 at their earliest convenience. Immense thanks, as always, to Fare Rideau. Also thanks to the many bug reporters and patch submitters (see the Changelog), and to Anton Vodonosov and Dave Cooper for help with testing. Here is the changelog entry for 3.3.2: cl-asdf (2:3.3.2-1) unstable; urgency=low Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Add package location information to define-package on SBCL. * Upgrade: fix issue with asdf/bundle. * Portability: add support for Mezzano (thanks to E. Housel, H. Harrington) * Documentation: add discussion of best practices. * Package-inferred system: Improve source file handling. * Test and documentation improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Thu, 03 May 2018 22:46:19 -0400

1 0

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

Problems with DEFSYSTEM-DEPENDS-ON
by Mark Evenson 09 Apr '18

09 Apr '18

The usage of DEFSYSTEM-DEPENDS-ON to specify dependencies that will be satisfied by QL:QUICKLOAD no longer seems to be working in asdf-3.3.1. It used to be the case that to use the [PROVE testing framework][1], it was sufficient to place a … :defsystem-depends-on (:prove-asdf) … clause in the secondary system to be tested, and then upon a QL:QUICKLOAD of this system, the dependency on PROVE was then resolved via a network download from Quicklisp. [1]: https://github.com/fukamachi/prove I believe this was working with asdf-3.2, but testing that assumption is a little hard as asdf-3.3 refuses to degrade itself with a downgrade, and all my systems are running asdf-3.3. Maybe something in Quicklisp changed as well?

5 11