- asdf-devel - mailman3.common-lisp.net

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

Window of inaction through Tuesday
by Robert Goldman 30 Sep '16

30 Sep '16

I have personal things (all good) that will keep me busy through the end of Monday. I will start to spin back up on ASDF activities Tuesday morning. Have a good weekend, everyone. r

1 0

Locations
by Greg Bennett 26 Sep '16

26 Sep '16

Good morning from Greg Bennett. I am trying to learn enough asdf to port some systems which now use mk:defsystem. Running under Linux Mint 17.2 and sbcl (or clozure) and using asdf3.1.7, My (current) difficulty is in understanding the specification of the locations of source and binary files. I *suspect* that I fall among those described in Section 9.2: "This incompatibility shouldn’t inconvenience many people. Indeed, few people use and customize these packages; these few people are experts who can trivially adapt to the new configuration. Most people are not experts, could not properly configure these features (except inasmuch as the default configuration of |common-lisp-controller| and/or |cl-launch| might have been doing the right thing for some users), and yet will experience software that “just works”, as configured by the system distributor, or by default" I'm not an expert, and I am very pleased in somethings "just work", but I am inconvenienced. I find code such as (defsystem zot :source-pathname (etc..) :binary-pathname (etcc..) :components (( ....) clear and helpful. I have tried to understand Sections 8 and 9 of the ASDF manual, indeed I thought I had Section 8 on source locations straight and looked ahead into Section 9, only find myself without any usable idea of how to proceed. I have scanned through assorted .asd files in the hope of seeing a working example, but none of them use asdf other than as a mechanism for specifying dependencies. I can define a system pqr with zot.asd, stored in the same directory as the source files. I can run (asdf:operate 'asdf:compile-op 'pqr) and have all the .fasl files squirreled away down in ~/.cache/common-lisp/lots-of-other-depths/. I should appreciate it very much if someone could point me to examples of working code for specifying source and binary locations. Thanks for any and all assistance. Cheers /Greg Bennett

3 2

Just pushed 3.1.7.26: RUN-PROGRAM extensions
by Robert Goldman 26 Sep '16

26 Sep '16

I have just pushed 3.1.7.26, which features merge of Elias Pipping's extensive re-engineering of UIOP:RUN-PROGRAM, and addition of UIOP:LAUNCH-PROGRAM. Thanks to Elias for an enormous amount of work. Thanks also to Faré for his extensive reviewing, to Daniel Kochmanski for his extensive work on UIOP (and apologies for my inability to figure out how to put an accent properly in his name!). RUN-PROGRAM has changed quite a bit, and whenever we move to a new release, I propose to bump to 3.2, to make it easier for people to detect these extensions. Best, Robert

2 2