asdf-devel August 2016

asdf-devel@common-lisp.net

11 participants
14 discussions

Operations on package-inferred-system
by Eric Timmons 22 Sep '16

22 Sep '16

I *really* like using package-inferred-system for defining systems, but I often find it doesn't behave as I expect when performing operations on it. I'm curious if these behaviors are intended or if the implementation is just incomplete. I approach package-inferred-system as a way of automatically finding dependencies between files and on third-party systems for a given system I'm writing. Under the hood, I know it makes a new system for every source file, but I consider that just an implementation detail and that when I refer to the primary system, I really mean everything that logically belongs to that system and not just the source files declared in the system's :components option. (Perhaps this assumption just needs to be adjusted on my end). The difference between expectation and reality often manifests itself in two places for me: + When I'm trying to distribute my system with a non-monolithic operation. E.g. `(asdf:perform 'asdf:concatenate-source-op :some-package-inferred-system) results in only the files explicitly declared in the system's :components option being concatenated. (Similar things happen with compile-bundle-op). + `(asdf:load-system :some-package-inferred-system :force t)` results in only the files explicitly declared in the system's :components option being reloaded. I was planning to write my own system class to address these issues, but figured I should see if this is even intended behavior before doing that =). -Eric

2 3

Re: Version 3.1.7.7 has been pushed
by Robert Goldman 02 Sep '16

02 Sep '16

On 8/21/16 Aug 21 -7:49 PM, Elias Pipping wrote: > Dear Robert, dear list, > > I’m happy to see the first changes to run-program in ASDF-3.1.7.7. I’m now working more pragmatically towards making others mergeable. As usual, the list can be viewed at > > https://gitlab.common-lisp.net/asdf/asdf/merge_requests/3 > > As of right now, it looks like this: > > 8e4f7fd Add and use process-info class > ec74b27 Add %if-on-lispworks?+ > ba8c24e Bug fix: Exit code with LispWorks 7 > a35fbe2 Bug fix: Store exit code with Allegro CL > 104da21 Change :if-*-exists default to :supersede > 4ef7409 Add and use not-implemented-error > 6359a4b Add file-stream*-p > c2d5de3 Add and use parameter-error. Reorganise errors. > 7ae0bcf Fix warnings on ABCL, etc. > fb3dd9a Add and use close-streams > 4971606 Add %process-info-*put getters > c7570da Tests: Cover %run-program and %wait-process-result > 1f43e5d Do not pass unnecessary keywords to SBCL Should we have another iteration on this, putting it into a topic branch and letting me test it on Windows, Mac, and Linux? TBH, I have never used merge requests on gitlab or github (except as submitting them), so I don't know the workflow from the recipient side. My use of git is mostly limited to command-line. best, r

4 17

Pushed ASDF 3.1.7.8: fixes for CLISP, etc.
by Faré 02 Sep '16

02 Sep '16

Sam Steingold (sds) probed me on some old bugs, which led me to waste a day debugging issues on and with CLISP. First I reproduced CLISP bug 677, figured out what CLISP was doing wrong (incorrect merging of logical pathnames in compile-file), and implemented a workaround (physicalize everything I can, trust compile-file's return value over my :output-file argument): https://sourceforge.net/p/clisp/bugs/677/ Then, I found a cleaner fix to the issue with DIRECTORY wanting "*" rather than "*.*" as the match-all pattern on CLISP and GCL. I also dug out the information in the old README.md that Robert stripped. I moved anything that may have been redundant with doc/index.html, move there what was complementary, and put back in README.md (after some editing) things that were not covered by either the home page or the manual: the documentation on how to navigate our source code, build and test ASDF, etc. Robert, please tell me if that's OK, since you were the one who deleted that information arguing of unmaintainable redundancy with web page and manual. I also slightly tweaked said web page and manual. Also, I see you disabled make doc in the Makefile. I presume it should be restored. Finally, I renamed make.bat to make-asdf.bat so that on Windows there is no risk of typing "make" and run make.bat in the current directory while believing one had run make.exe from the %PATH%. This may or may not help Robert make his tests pass on Windows. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org ...so this guy walks into a bar. "The usual, Mr. Descartes?" the barman asked. "I think not," Rene replied, and promptly disappeared.

5 11

*LOAD-TRUENAME* and ASDF
by Robert Goldman 31 Aug '16

31 Aug '16

I just realized that ASDF somewhat breaks *LOAD-TRUENAME*. I had some code in a DSL that has an :INCLUDE construct, and that DSL is being interpreted at load-time. The :INCLUDE directive tries to find other lisp files relative to the current file (the source file that contained the DSL :INCLUDE expression). Now, if we were not using ASDF, I would be able to find those files by merging a name with *load-truename* (and this is how things used to work). But ASDF's relocation of the fasls breaks this. Now, of course, I could change (:INCLUDE construct "construct-source.lisp") to (:INCLUDE construct #.(asdf:system-relative-pathname "foo" "construct-source.lisp")) but: 1. This is blatantly ugly, effortful, and error-prone for the programmer. 2. It is poor software engineering, because it requires the contained thing (the DSL expression) to "know" that it is being included in a very specific ASDF system. Now if we rename the ASDF system, or shuffle files, our DSL code is broken, and that's just wrong, because it makes the abstraction upside down. I somehow assumed it would be possible to go from the FASL to the source, but I don't actually see any obvious way to do this. suggestions? thanks! r

6 21

Re: Version 3.1.7.7 has been pushed
by Elias Pipping 27 Aug '16

27 Aug '16

> On 27 Aug 2016, at 19:45, Faré <fahree(a)gmail.com> wrote: > > All these are reasons why it's illusory to try to document a compatibility matrix in the source code itself. This matrix is extremely hard to accurately ascertain and maintain as the code evolves, and cannot possibly be future-proof. > > Please, don't pollute the source code with vain attempts at including a compatibility matrix in it. At best, have the code link to an informative URL, that at least stands a chance at being maintained. Dear Faré, I’ve already agreed with you in another mail on that topic, please see e.g. https://mailman.common-lisp.net/pipermail/asdf-devel/2016-August/005412.html I’d be interested in your thoughts on the proposal that I’ve made based on that. Elias

1 0

Question about UIOP: Any reason GET-TEMPORARY-FILE couldn't be exported?
by Robert Goldman 23 Aug '16

23 Aug '16

ACL offers a functionality like this with its make-temp-file-name and make temp file. I'd love to have a portable version that would, for example, make temporary files that could be used as arguments in RUN-PROGRAM. Is there any reason this could not be exported? thanks, r

3 7

Platform support: current status (3.1.7.7, linux)
by Elias Pipping 22 Aug '16

22 Aug '16

Dear list, I've been meaning to find out what lisp compilers/interpreters are effectively supported by current ASDF, to the point where they pass `make test-lisp` without a single (potentially harmless error), such as those stemming e.g. from unexpected warnings. I’ve now gotten around to a bit of testing. For future reference, on a recent Linux, with ASDF 3.1.7.7, the answer is as follows: ABCL: 1.2.0 (2013-06-01) or later looks good(*) Allegro CL: 10.0 Express Edition looks good(**) CCL: 1.10 (2014-09-12) or later looks good(***) CLISP: 2.49 (2010-07-07) looks good; hg checkout segfaults in asdf-pathname-test.script CMUCL: 20e (2013-09-28) or later looks good(+) ECL: 16.0.0 (2015-08-28) or later looks good LispWorks: HobbyistDV/Professional/Enterprise edition of 7.0 (2015-05-05) would probably look good(++1) LispWorks: Professional edition of 6.1 (and presumably others) currently emit an unexpected warning(++2) MKCL: 1.1.9 hangs in test-try-refinding.script; git checkout looks good SBCL: 1.1.13 (2013-10-31) or later looks good(+++) (*) sys::concatenate-fasls requires 1.2.0 or later (**) 9.0 can no longer be downloaded so that I could not test with earlier versions (***) 1.9 and earlier are broken on recent versions of linux, see http://trac.clozure.com/ccl/ticket/1208 (+) 20c/20d has known CLOS issues. (++1) I do not have access to them, so I cannot say for sure. The Hobbyist and Personal edition lack application delivery and image saving functionality, respectively. The tests put those features to the test and currently fail if they’re unavailable. (++2) causing `make test-lisp` to fail; This started with ASDF 3.1.7.5; 3.1.7.4 was fine. (+++) sb-debug:print-backtrace requires 1.1.5 or later, bundles require 1.1.13 or later Elias

4 5

RFC: new error class
by Robert Goldman 22 Aug '16

22 Aug '16

What about an UNSUPPORTED-FUNCTIONALITY ERROR subclass? I was thinking of putting it in UIOP, and exported, for the use of cases where a particular implementation doesn't support an operation. This might make it much easier to handle implementations that don't support all operations, PARTICULARLY in test cases. Best, r

2 1

Version 3.1.7.7 has been pushed
by Robert Goldman 22 Aug '16

22 Aug '16

This version contains bug fixes for RUN-PROGRAM contributed by Elias Pipping, for which many, many thanks!

2 1

CMU CL: #+cmu vs. #+cmucl
by Elias Pipping 20 Aug '16

20 Aug '16

Dear list, a quick and superficial analysis suggests that the :cmu feature has been defined for longer (probably forever) and :cmucl is relatively new(*), yet ASDF appears to use both and mix them rather arbitrarily. Assuming that the check for :cmucl is not meant to rule out old versions of cmucl, I think it would make sense to stick to one. While `make test` will currently fail right away with cmucl 20b because of the missing :cmucl feature, transforming all the occurrences of the :cmucl feature into :cmu still leaves two tests failing. And with 20c and 20d (which are not old at all and do define :cmucl), 5 tests will still be failing (and have been for quite some time). Only the very recent releases 20e, 20f, and 21a pass all tests. Is this known? Is it impossible to support old versions of cmucl? I did find that cmucl-20a at least does not expose (unix:unix-getenv) which ASDF puts to use but I cannot judge if there are ways to work around that. So to summary what I’d like to ask: - Is it known that tests fail on cmucl <20e? - What versions of cmucl is ASDF meant to support? - Should I turn checks for the :cmucl feature into ones for :cmu? Elias (*) in a shell, for v in 19a 20{a,b,c,d,e,f} 21a; do echo -n cmucl-$v:; cmucl-$v -eval '(write-line #+cmucl "yes" #-cmucl "no")' -eval '(quit)'; done prints: cmucl-19a:no cmucl-20a:no cmucl-20b:no cmucl-20c:yes cmucl-20d:yes cmucl-20e:yes cmucl-20f:yes cmucl-21a:yes

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel August 2016