asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

17 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

Running tests with test coverage enabled
by Alexey Veretennikov 19 Oct '16

19 Oct '16

Hi all, Right now I'm running unit tests using Fukamachi's prove library: (asdf/operate:test-system 'my-system). I want to run my tests generating the tests coverage of my system. For this I would like to have similar operation, but which will: 1) turn on the code coverage in LispWorks (just call to some global function) 2) rebuild system which I want to test (in this case my-system), but only (!) this system (not dependencies) 3) run tests 4) call coverage results processing function. 5) on normal run (asdf/operate:test-system 'my-system) rebuild the system without coverage. How could I proceed with this task? -- Br, /Alexey

2 6

Recent disappearance of asdf:bundle-system.
by Jean-Claude Beaudoin 18 Oct '16

18 Oct '16

Hello ASDF devs, I noticed recently that asdf/bundle:bundle-system has disappeared from ASDF. MKCL is/was a user of that function as a convenient entry point to the ASDF bundle facility. My impression was that, along the lines of asdf:load-system and asdf:compile-system, asdf:bundle-system was playing a (small but) useful role as a convenience function. I will most probably simply have to fold that function inside the build code of MKCL if it is to be removed from ASDF for good. Yet, to see a publicly exported function disappear between version 3.1.7.10 and 3.1.7.12 to most likely result in a 3.1.8 release gives pause. Are we really seeing here a public API code breaking modification being done between two patch level releases? BTW, there seems to have been a few other MKCL related breakage issues introduced by the recent wave of changes. I will have to examine each one in turn... Cheers, JCB

6 12

poiu 1.31
by Faré 10 Oct '16

10 Oct '16

I was considering merging POIU into ASDF, or at least part of it: https://gitlab.common-lisp.net/qitab/poiu The part that I am really interested in merging is the plan that completely and correctly models the action graph based on an explicit graph (duh). This would be a prelude to allowing more meaningful queries on the build plan, but also hopefully to allowing better support for operate-in-operate as necessary for defsystem-depends-on and such. I just split poiu into multiple files, and added some docstrings, to get an idea of which part takes how much. These implement the aforementioned action graph (wc output), where queue would go to uiop (it could be stripped down a bit), and action-graph in asdf (with some more commenting needed): 123 591 4609 queue.lisp 186 764 8360 action-graph.lisp The parallelizing implementation (currently only for allegro, clisp, clozure, sbcl and only on unix) is this big (the first two files would go to uiop; the last part is the asdf-specific code and needs more commenting): 219 977 8972 fork.lisp 180 714 8362 background-process.lisp 145 533 6714 poiu.lisp This would have been a lot in the times of ASDF1 when ASDF was < 1000 loc (and then, the original POIU was even larger, for it needed to patch ASDF that was lacking suitable interfaces). But it's not that much now that ASDF is >12.5kloc. We've grown a lot, yet much slower than Moore's Law. So, should I import the first part of POIU? All of it? Is there anything bad about compiling in a fork, when available? Actually, I'm thinking the forking part should probably be left in an extension, since it won't be used in SLIME anyway, because SLIME uses threads, which invalidates the forking ability of POIU. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced misquotation is indistinguishable from an original statement. — John McCarthy, misquoted

2 1

require-test persistently failing for me on ECL Windows
by Robert Goldman 10 Oct '16

10 Oct '16

I just reported this to ECL in their tracker: https://gitlab.com/embeddable-common-lisp/ecl/issues/293 for those interested.

1 0

Strange behavior with :function output translations and custom output-files method
by Jason Miller 09 Oct '16

09 Oct '16

Hi, I reduced a testcase from the metacopy-with-contextl .asd file. It defines an output-files method to rename the .fasl so that it can compile the same lisp files with different features set. This worked fine when I was using normal output translations, but when I switched to a :function output translation, it failed. I'm not sure if this is a bug in asdf, a bug in my output translation function or a bug in metacopy, so I'm posting it here for some advice. Test-case is in a tarball below. There is a shell script "test.sh" which invokes sbcl twice. The first time the output translation is left unaltered, the second time it specifies a :function translator for all paths, and this causes an error. -Jason https://phab.jasomfiles.org/orfiles/asdtest.tar.gz

2 1

bulletin
by Robert Goldman 06 Oct '16

06 Oct '16

I've tested Elias's two minor updates, and they pass all my tests, so I will be merging them and tagging a new version (NOT a new RELEASE!) this morning. cheers, r

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel