asdf-devel January 2020

asdf-devel@common-lisp.net

5 participants
3 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

I should know this... finding INPUT-FILES
by Robert Goldman 25 Jan '20

25 Jan '20

I'm looking at the documentation for `INPUT-FILES` and `OUTPUT-FILES` and I see this: ``` (defgeneric output-files (operation component) (:documentation "Methods for this function return two values: a list of output files corresponding to this action, and a boolean indicating if they have already been subjected to relevant output translations and should not be further translated. Methods on PERFORM *must* call this function to determine where their outputs are to be located. They may rely on the order of the files to discriminate between outputs. ")) (defgeneric input-files (operation component) (:documentation "A list of input files corresponding to this action. Methods on PERFORM *must* call this function to determine where their inputs are located. They may rely on the order of the files to discriminate between inputs. ")) ``` Missing in the above is an explanation of how to tell `INPUT-FILES` whether to apply output translations or not. Is this left to the author of the relevant `PERFORM` method? Or is there something one should do when writing a `PERFORM` method or an operator definition?

4 8

Re: ASDF dependency graph or complexity score
by Robert Goldman 11 Jan '20

11 Jan '20

What kind of dependency graph are you looking to make? Just the systems, or also the individual system components? And do you want a visible representation of this graph, or just some set of data structures? I assume the former, since you should be able to use the system components themselves to get all the dependency links. If it's the former, the easiest thing might be to use CL-DOT and write the necessary methods to create a graph. You might need to get ASDF to compute the plan for `LOAD-OP` as a way to ensure that all the required system definitions are loaded. With respect to test systems, I have usually found it best to have my systems, say "foo", have "foo/test" related systems, delegate the `test-op` for "foo" to "foo/test" using `in-order-to`, and then only "foo/test" needs to depend on the test library -- "foo" itself doesn't need it. HtH, R On 23 Dec 2019, at 19:08, Jay wrote: > Thanks. > > I will follow up with Rob later. > > Anyway, thanks for help in the past. I will liaise with Rob to figure > out > the best way forward. > > Jay > > Faré > 6:52 PM (14 minutes ago) > to me >> I guess, I will have to step up at some point. I have a tool that's >> built > with CL. I'll start small from the easier tasks and work my way up the > graph one you highlighted above. >> Then, I will be able to tackle the graph thing, as you said it's no >> easy > fit. >> > Makes sense. > >> Are the TODO you mentioned ordered in some priority list or tagged >> with > easier/medium/hard. >> > Unhappily not. Give it a look and/or give a look at the issues on > launchpad, and/or ask Robert, for guidance. Sorry I don't have time to > sort out the issues right now. > >> And the repo is still the version on gitlab right? Does Rob hang over >> at > #lisp irc? >> > Yes the repo is on gitlab, but the issues are still mostly on > launchpad. > > Robert sometimes is on IRC as rpg (or is is rpgoldman? notthatrpg?). > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > "Floating point numbers are like sandpiles; every time you move one > you lose a little sand and pick up a little dirt" > — Vic Vissotsky > > > On Mon, Dec 23, 2019 at 6:52 PM Faré <fahree(a)gmail.com> wrote: > >>> I guess, I will have to step up at some point. I have a tool that's >> built with CL. I'll start small from the easier tasks and work my way >> up >> the graph one you highlighted above. >>> Then, I will be able to tackle the graph thing, as you said it's no >>> easy >> fit. >>> >> Makes sense. >> >>> Are the TODO you mentioned ordered in some priority list or tagged >>> with >> easier/medium/hard. >>> >> Unhappily not. Give it a look and/or give a look at the issues on >> launchpad, and/or ask Robert, for guidance. Sorry I don't have time >> to >> sort out the issues right now. >> >>> And the repo is still the version on gitlab right? Does Rob hang >>> over at >> #lisp irc? >>> >> Yes the repo is on gitlab, but the issues are still mostly on >> launchpad. >> >> Robert sometimes is on IRC as rpg (or is is rpgoldman? notthatrpg?). >> >> —♯ƒ • François-René ÐVB Rideau >> •Reflection&Cybernethics• >> http://fare.tunes.org >> "Floating point numbers are like sandpiles; every time you move one >> you lose a little sand and pick up a little dirt" >> — Vic Vissotsky >> >> >> >>> On Fri, Nov 29, 2019 at 11:33 AM Faré <fahree(a)gmail.com> wrote: >>>> >>>>> I could not follow up in the past as I had to relocate between >>>>> cities >> (central to west coast) so that caused a lot of changes in my >> schedule. >> What is the state of the asdf contributors you mentioned last time -- >> the >> developers taking over asdf development albeit gradually. >>>>> >>>> No one has really stepped forward. It's still Robert Goldman >>>> maintaining things, while I have moved away from active maintenance >>>> and am only reviewing patches and giving advice, sometimes making >>>> small edits to documentation. >>>> >>>>> I just started working on my fairly large system again, and >>>>> recently >> had issues when I was trying to disentangle systems to avoid loading >> multiple test systems that clobber global variables. A secondary goal >> is to >> reduce unnecessary dependencies ( btw I use :class >> :package-inferred-system >> in my setup). >>>>> >>>>> Is there some asdf option that I can use to get the graph for a >>>>> given >> loaded system or some score of complexity due to linkages. I have >> been able >> to improve this over the years and the system is a more stable but >> occasionally hangs when it has to load many packages (hundreds of >> files) >> after compiler update (using SBCL primarily) >>>>> >>>> Aha. Well, it used to be that POIU could extract a dependency graph >>>> from an ASDF system, and act on it to build; but this has bitrotten >>>> a >>>> bit with the latest changes in ASDF 3.3, and POIU is not currently >>>> very stable. If you could fix it, that would be great. But beware, >>>> it's no small undertaking: you have to really get into a lot of >>>> internals to do it right, and make non-trivial changes to UIOP, >>>> likely >>>> including subtle changes to ASDF itself. >>>> >>>> —♯ƒ • François-René ÐVB Rideau >>>> •Reflection&Cybernethics• >> http://fare.tunes.org >>>> Appropriate fear keeps you alive. Excessive fear prevents the very >>>> thing >>>> it's supposed to protect: life. — Attila Lendvai >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> Jay >>

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel January 2020