asdf-devel February 2020

asdf-devel@common-lisp.net

2 participants
5 discussions

[PATCH] Add a TEST-OP-TEST-FAILURE condition for test libraries to sub-class
by Vladimir Sedach 26 Mar '21

26 Mar '21

Hello! I recently wrote a script to run FiveAM tests for one of my libraries on many different implementations on your own machine: https://gitlab.common-lisp.net/uri-template/uri-template2/blob/master/run-t… It would be really nice if I did not have to copy-paste that script to my other libraries, and instead could contribute a generalized version to Roswell (on which the script is based) and have it work for any project using any test library. What I would like to be able to do, for any system: (handler-case (asdf:test-system "system") (asdf:test-op-test-failure (condition) (princ condition uiop:*stderr*) (uiop:quit 1))) The attached patch adds an ASDF:TEST-OP-TEST-FAILURE condition that test libraries can inherit from. I also added the necessary functionality to FiveAM: https://github.com/sionescu/fiveam/pull/58 It should be easy to add similar functionality to other testing libraries. This will make test automation trivial, with few, if any, changes required to systems that use ASDF and the testing libraries. One thing I would like to discuss is which condition ASDF:TEST-OP-TEST-FAILURE should inherit from. It definitely should not be ERROR - there is no error in test-op, or in running the tests; test failures are a regular and expected occurrence of running tests. Also problematic is widespread abuse of HANDLER-CASE to catch any ERROR; I am afraid if signaled from popular test libraries it would break someone's test running code somewhere. WARNING seems like a nice parent condition, but maybe having ASDF:TEST-OP-TEST-FAILURE inherit from CONDITION is a better idea. Thoughts? Vladimir

4 15

Debian package for ASDF 3.3.4
by Robert Goldman 14 Feb '20

14 Feb '20

Is anyone still interested in building the Debian package? I'm developing mostly on Mac, and don't have the zorch required to stand up a Debian toolchain and build the package, and also I'm not trusted by the Debian project, so I don't know how to upload. I believe ASDF is all ready for Debian building if anyone has the tool support and motivation to turn the crank. There's even support for it in the Makefile. Please contact me if you are interested. Thanks, R

1 0

ASDF 3.3.4 is now available
by Robert Goldman 14 Feb '20

14 Feb '20

In honor of Valentine's Day, and more honestly, just because it's overdue, today we release ASDF 3.3.4, the fourth bugfix release for the 3.3 release series. 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.4 at their earliest convenience. This is especially true for SBCL, for which 3.3.4 fixes a bug preventing ASDF upgrade from working smoothly. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Rommel Martinez * Jan Moringen * Karsten Poeck * François-René Rideau * Martin Simmons * Eric Timmons * Guillaume Le Vaillant

1 0

Delay in 3.3.4 release
by Robert Goldman 12 Feb '20

12 Feb '20

Unfortunately, the pressures of my day job have prevented me from spending the time required to get 3.3.4 released. I now hope for this weekend. Apologies for the delay: I very much want to get this released to solve a critical issue in recent SBCL versions.

1 0

Plans for 3.3.4
by Robert Goldman 05 Feb '20

05 Feb '20

There are two issues and three merge requests that are essentially ready to go. I will work through them as quickly as the pressures of work permit, hoping to release 3.3.4 at the end of the week. If you have time, please test, especially if you use Windows, where I am unable to run the test suite. Thanks!

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel February 2020