asdf-devel November 2016

asdf-devel@common-lisp.net

11 participants
15 discussions

Misnamed secondary systems
by Faré 18 Nov '16

18 Nov '16

Starting with ASDF 3 (2013), ASDF officially supports "secondary systems", i.e. additional systems named in an asd, beside the main one. For the additional systems to be findable by ASDF, though, their name must be of the form "foo/bar" where "foo.asd" is the name of the file, and "foo" is called the primary system name. ASDF1 and ASDF2 would let you define those systems, as well as other systems of arbitrary names, but would be incapable of finding them. By badly copying each other, Lispers have developed a lot of misnamed secondary system the name of which doesn't match the pattern. I'd like to forbid such misnamed systems. Now a quick grepping through Quicklisp (see latest update to my ql-test) finds 233 .asd files with such misnamed secondary systems. Obviously it will take time to clean up the mess, so for after the next release, I'd like to signal a full WARNING when the condition is detected, and at some point, make that a CERROR, then later an ERROR. Cleaning up this mess will also prevent a subtle class of errors, such as when two .asd files define each other's systems (see test case test-mutual-redefinition.script in asdf/test). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Demand the establishment of the government in its rightful home at Disneyland.

4 6

test-run-program.script
by Robert Goldman 18 Nov '16

18 Nov '16

I see this in test-run-program: #+(and sbcl os-windows) (leave-test "SBCL won't let us pass unquoted arguments to cmd.exe" 0) #-(and sbcl os-windows) (progn (DBG "Testing echo ok 1 via run-program as a string") (assert-equal "ok 1" (dewindowize (run-program "echo ok 1" :output '(:string :stripped t))))) If we know that SBCL on Windows won't let us pass unquoted arguments to cmd.exe, should we raise a NOT-IMPLEMENTED-ERROR on that combination, and check for it in the test? Thanks, r

3 3

3.1.7.35 test status
by Robert Goldman 17 Nov '16

17 Nov '16

I show 3.1.7.35 passing all tests on Mac and Linux, failing test-require and test-run-program on ECL bytecodes on Windows. test-require is a long-standing ECL bug on Windows that Jason Miller has confirmed. There's a bug report in to ECL, so we don't have to worry about this. test-run-program shows a failure on run-program with a string argument versus with a list argument. Attaching a snippet of the transcript. I'd like to get this either fixed or dismissed as an ECL problem before we release. Cheers, R

2 2

Version 3.1.7.35 has been pushed
by Robert Goldman 17 Nov '16

17 Nov '16

This version contains many fixes to RUN-PROGRAM by Elias Pipping with support from Faré. Please try it out. Working towards a release of ASDF soon, so anything you could do to help iron out bugs would be very much appreciated!

5 7

Can we give up :INTERACTIVE I/O for RUN-PROGRAM?
by Robert Goldman 09 Nov '16

09 Nov '16

Interactive I/O is not reliable across implementations, and is also difficult to test. Do we really need to support this? If you, as a programmer, really want interactive I/O, you should probably write your own wrapper to manage I/O to the program. Some enterprising soul could even write a clone of "expect" for CL. I'd rather lose the :interactive option, than have it and have it work unreliably. So I'm soliciting comments -- particularly from those who think we should keep it. It seems like some people also have a means to search Quicklisp to screen suggestions like this. I'd also welcome feedback based on libraries in QL. thanks, r

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel November 2016