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

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

Pushed version 3.1.7.6
by Robert Goldman 18 Aug '16

18 Aug '16

This contains bug fixes that make tests work better when run under cygwin on Windows. This is also preparatory place-holder before merging Elias's RUN-PROGRAM bug fixes. Cheers, r

1 0

extending uiop/run-program
by Elias Pipping 18 Aug '16

18 Aug '16

Dear list, I’ve recently made the switch from external-program to uiop/run-program::%run-program for asynchronous process execution after I read that its interface should remain essentially stable. I’ve also had to use uiop/run-program::%wait-process-result although I’m not sure if its interface in turn as subject to the same close-to-guarantee. So far the two are serving me well and I’m not looking back. I ended up writing two functions that I needed because uiop/run-program does not currently provide such functionality while external-program did. I’m sometimes interested in testing whether a process is running; I use the following function for that: (defun process-running-p (process-info) (let ((process (getf process-info :process))) #+clozure (eq :running (ccl:external-process-status process)) #+cmu (eq :running (ext:process-status process)) #+ecl (eq :running (ext:external-process-status process)) #+mkcl (eq :running (mk-ext:process-status process)) #+sbcl (eq :running (sb-ext:process-status process)) #-(or clozure cmu ecl mkcl sbcl) (error "Cannot determine if a process is running."))) Maybe something like this could be incorporated into UIOP as well? (or a function that returns the process status, or a function that checks that a process is alive, etc.) Sometimes, I also want to terminate a process before it finishes. To that end, I use the following: (alexandria:define-constant +kill-signal+ 9 :test #'=) (alexandria:define-constant +term-signal+ 15 :test #'=) (defun terminate-process (process-info &key force) (let ((process (getf process-info :process)) (sig (if force +kill-signal+ +term-signal+))) #+allegro (progn ; FIXME: untested #+os-unix (excl.osi:kill process sig) #+os-windows (uiop/run-program::%run-program (format nil "taskkill /f /pid ~a" process) :wait t) #-(or os-unix os-windows) (error "Cannot terminate a process.") (sys:reap-os-subprocess :pid process)) #+clozure (ccl:signal-external-process process sig :error-if-exited nil) #+cmu (ext:process-kill process sig) #+sbcl (sb-ext:process-kill process sig) #+scl (ext:process-kill process sig) ; FIXME: untested #+mkcl (mk-ext:terminate-process process :force force) #-(or allegro clozure cmu mkcl sbcl) (error "Cannot terminate a process."))) This is a special case of a more general signalling facility that many lisps have but which from my understanding can only work on unix. mkcl does not provide such a facility but it does provide a terminate-process function that works on windows, too. The Allegro CL documentation states that one should run (format nil "taskkill /f /pid ~a" process) on such platforms, which could also be done with other lisps, assuming that the PID is known or can be extracted from the process. Maybe a function of this type could be incorporated into UIOP as well? Elias Pipping

4 21

Removing content from README.md
by Robert Goldman 05 Aug '16

05 Aug '16

As someone who doesn't use the gitlab interface, it was only now that I realized that there was a README.md. I just looked over that README, and realized that it was not maintained. I quickly concluded that I do not have the resources to maintain both this file and the HTML file at https://common-lisp.net/project/asdf/, and the latter is what I have been updating with new releases. So the former must go. I apologize for this draconian step. Of course nothing has been lost, it is all in the git history. I am willing to entertain the argument that the index.html be deprecated instead of the Markdown page. However, I will not entertain requests for both. One will have to be merely a pointer to the other.

3 3

serious-condition
by Faré 01 Aug '16

01 Aug '16

Dear Robert, instead of adding a *fatal-condition-exceptions*, I would much rather you use (and serious-condition #+clozure (not ccl:process-reset)) or something like that. You may have to add a case to match-condition-p to support lists as condition type specifiers. This probably applies to the other handler-bind places where you catch serious-condition, too. git grep serious-condition is your friend. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves. — William Pitt, 1783

3 8