asdf-devel March 2021

asdf-devel@common-lisp.net

11 participants
8 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

Dependency issue with program-op
by Didier Verna 22 Mar '21

22 Mar '21

Hello, I'm cross-posting because I don't know if the issue is related to ASDF or ECL. I'm using the most recent repos of both. When dumping a very simple system defined like this: (asdf:defsystem :simple :depends-on (:net.didierverna.clon) :components ((:file "simple")) :entry-point "simple:main") with (asdf:operate 'asdf:program-op :simple), I'm getting a runtime error with the executable: Condition of type: SIMPLE-PACKAGE-ERROR There exists no package with name "NET.DIDIERVERNA.CLON.SETUP" No restarts available. Top level in: #<process TOP-LEVEL 0x10a821f80>. So it seems that the net.didierverna.clon.setup system is not dumped in the executable. In Clon, the dependency on setup is indirect: net.didierverna.clon <- net.didierverna.clon.core net.didierverna.clon.core <- net.didierverna.clon.setup If I add an explicit dependency on setup in the :simple ASDF system above like this: :depends-on (:net.didierverna.clon.setup :net.didierverna.clon)) the problem goes away. This doesn't happen with the 5 other Lisp implementations that I've tested. Also, it may be worth mentioning that Clon's setup system gets a special treatment. It's loaded explicitly at the top of several .asd files like this (with the utmost disrespect for the Almighty ASDF Gods recommendations): (asdf:load-system :net.didierverna.clon.setup) I'm wondering if this may have something to do with the problem. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

3 4

Pushed 3.3.4.11 and then 3.3.4.12
by Robert Goldman 21 Mar '21

21 Mar '21

The first has a fix for the incorrect argument handling in `launch-program`, and the second has two fixes for feature handling from Eric Timmons. At 4.12 it seems to me that we have a bunch of bug fixes that should be released into the wild, and there seems little cost to doing so, since there aren't breaking changes. So.... Please test out the current version if you can -- just download or clone it and use it in your day-to-day work, and report any issues. I plan to release ASDF 3.3.5 next weekend, assuming no one finds any real stinkers in the meantime, or if anyone has a high priority fix that needs to go in ASAP. Best, R

2 1

Is program-op supported on Lispworks ?
by Didier Verna 20 Mar '21

20 Mar '21

Hi, sorry for asking, I can't test it locally (I only have the personal edition here). -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

"How-to" request
by Marco Antoniotti 20 Mar '21

20 Mar '21

Hi I am trying to create a new ASDF:OPERATION, but I must be missing something and the manual (or Google) does not seem to help much. How do you create a new operation, which may be quite simple? Or better, how do you get PERFORM and/or OPERATE to actually do something for you. I know I should RTFM, but in this case it is more of a RTFC, which is far more difficult. I tried the following (defclass my-op (non-propagating-operation) ()) (defmethod perform ((o my-op) (s system)) (print 42)) (defmethod operate ((o my-op) (s system) &key &allow-other-keys) (print 666)) But then, doing cl-user 42> (operate 'my-op (find-system "somesys") :bar 1024) #<MY-OP > #<ASDF/PLAN:SEQUENTIAL-PLAN 2301B97B> is all I get. Any tutorial or advice? Thanks -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY

4 12

System cleanup
by Didier Verna 19 Mar '21

19 Mar '21

Hi, I would like to remove some old workaround code from a couple of systems, wrt to ASDF 3.1.4 bugs (see below). Is it safe to do so now, or are these "bugs" still lurking around? The relevant parts are as follows: :defsystem-depends-on (:net.didierverna.clon.setup/termio #+sbcl ;; BUG in ASDF 3.1.4: d-d-o can't deal dependency expanding to NIL (:feature :sbcl (:require :sb-grovel)) #+(or allegro clisp lispworks) (:feature (:or :allegro :clisp :lispworks) :cffi-grovel)) and :components (;; bug in ASDF 3.1.4: cannot deal with conditionally defined ;; component class! #+sbcl (sb-grovel:grovel-constants-file "sbcl/constants" :package :net.didierverna.clon :if-feature :sbcl) #+(or allegro clisp lispworks) (:cffi-grovel-file "cffi/constants" :if-feature (:or :allegro :clisp :lispworks)) Thank you! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

4 12

Re: System cleanup
by Didier Verna 18 Mar '21

18 Mar '21

François-René ÐVB Rideau écrivait: > What more, even Xach seems to have miraculously seen the light: one > months and one week ago, he updated the fallback ASDF in Quicklisp > from 2.26 to 3.2.1! That's also what made me think I could perhaps do some clean up! > That was the first update of ASDF in Quicklisp since 2012, to a > version then-current, to a version 4 years old. By linear > extrapolation, we should expect the next update to happen in 2030, to > a version from 2022. I admit that I was thinking his next move would > be to downgrade ASDF to 1.369 (the last version before I took over). :-) :-) -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now!

1 0

Where is my executable?
by Didier Verna 17 Mar '21

17 Mar '21

Hi, what's the proper way to find out where a dumped executable (resulting from a program-op) has landed? I would like to it to literally :move-here #p"./", to speak in MAKE-BUILD terms... Note that *I* know where it is in the cache; what I want is programmatic access to its location. Thanks! -- ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php Available on all digital platforms now! Lisp, Jazz, Aïkido: http://www.didierverna.info

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel March 2021