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

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

Discussions about merge request 3
by Robert Goldman 24 Sep '16

24 Sep '16

Elias requests we merge this sooner, rather than later, as he has to go off-line for several days. I'll try to get this done tomorrow, but my review will probably be sub-ideal, since I really am not fully on top of this very complex chunk of code (aside from the tests, I've only really used it on SBCL and ACL). I'd particularly like feedback from Faré, obviously, and opinions about whether it's ready for a merge. Thanks, r

2 2

Enforcing assumptions
by Robert Goldman 24 Sep '16

24 Sep '16

I have been working on enforcing assumptions recently added to the ASDF docs. Specifically, that OPERATION instances only be created by MAKE-OPERATION and SYSTEMs only be parsed inside LOAD-ASD. I should have a merge request up for review soon, but find that it's more tricky than I expected, because we don't even play by the rules ourselves! Specifically, there are calls to MAKE-INSTANCE on OPERATIONs in the ASDF codebase itself. Cheers, r

3 9