On 02 Aug 2016, at 00:06, Elias Pipping pipping.elias@icloud.com wrote:
Dear Robert,
On 01 Aug 2016, at 04:25, Robert Goldman rpgoldman@sift.net wrote:
If you were to move your work on uiop:run-program to a long-lived topic branch, I could test it on a wide variety of implementations on Mac and Linux.
Sure, that sounds good. I’ve requested an account on
https://gitlab.common-lisp.net
for this purpose.
The branch is now up at
https://gitlab.common-lisp.net/epipping/asdf/tree/run-program
with the first bug fix. I’ve also pushed to another branch
https://gitlab.common-lisp.net/epipping/asdf/tree/run-program-messy-with-reb...
the name of which is supposed to convey how messy it could potentially be (and how I might `push —force` to it). I’ve added a test script (to the messy branch only) that’s not currently connected in any way to the existing testing infrastructure. It serves me as a survey tool, since a test failure at this point can mean either a problem with run-program or with my understanding of it (I didn’t know about ccl’s
(with-open-file (… :sharing :lock))
until yesterday e.g. and there’s an odd issue with string streams under cmucl that I wrote to cmucl-help to about because I’m not sure if cmucl is doing something wrong or I am).
The output currently looks like this for me:
https://gitlab.common-lisp.net/epipping/asdf/commit/3e92222f97dddb2a6e838b64...
A quick glance reveals that clisp stands out as being particularly badly supported by run-program and that there’s an error with run-program on cmucl (the one I mentioned a few lines earlier). Among the tests that are skipped, there’s some where run-program has asserts in place to catch combinations of parameters that aren’t supported by the underlying implementation but also some where run-program fails to catch problems and the implementation either generates an error or silently misbehaves (both are marked with FIXMEs in the test script).
Elias