asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

RFC: Slots on operations, and bundle filenames
by Robert Goldman 28 Jul '16

28 Jul '16

Once upon a time in old ASDF, there was an idea that one might put slots on operations. IIRC, this worked oddly, at best, because it wasn't clear how to propagate these slot values around in the plans that ASDF built. OTOH, we could really use the ability to add information to some of the ASDF operations. For example, now that we have an IMAGE-OP, we really don't want the images hidden away in the .cache directory where they are hard to find. Justification: it's fine to have fasl files hidden away there, because the fasls are loaded by ASDF:LOAD-OP based on computed fasl file locations. But if you want to load an image, you need to find that image *before* you have ASDF -- even before you have lisp -- so an invisible file, whose location is computed, is really inappropriate. Note also that by Faré's design principle -- the one who knows should specify -- this information cannot be somehow programmed into the system -- it must be supplied by the user. I'm inclined to think we could allow the user to set an output-file for some of the bundle operations with a keyword argument to OPERATE, and then jam the value of the keyword argument into the bundle-op for it to be written. This works, I think, because it's a trivial case. If we try to put some properties on an operation and need them to be propagated around the plan, I think we just lose. Comments?

2 1

Using ASDF as part of an interactive app framework - storing components in memory?
by Andrew Sengul 27 Jul '16

27 Jul '16

I'm interested in using ASDF to build interactive applications. Here's an example of the kind of thing I'd like to do. Imagine creating a Web-based multiple choice poll. When someone submits an entry to the poll, a data file containing all the responses is updated with the new entry. Two SVG graphics, a bar chart and a pie chart of the answers, are also updated according to the updated data set. If I wanted to implement something like this in Common Lisp, ASDF seems like a good foundation to build on, since it allows me to create a complex dependency graph of code and data files. In the example above, the SVG visualizations are dependent on the answers data set, and they get updated when the answer data is updated. However, I don't know how well this approach would scale because in order to use ASDF this way, a file needs to be written to disk and other files must be loaded from disk and compiled each time an entry is made to the poll. Would it make sense to create a new component type that represents a quoted piece of code stored as a variable in a running program rather than a file? If the poll is implemented with a persistent Web server, it could keep the answer data and the graphics in its memory instead of on disk, and use some means to periodically back up the contents of those variables to disk. I'm still new to ASDF so I'm not sure if there's a simple way I could add in this functionality or if it's a good idea. I know that the Web poll example I gave above would work better if the graphics generation and answer storage was just written into the Web server instead of using ASDF, but the poll is just an example; my goal is to develop a system that can handle much more complex code/data graphs. Any feedback appreciated. Thanks, Andrew

3 4

Request for advice on handling SERIOUS-CONDITIONs in ASDF tests
by Robert P. Goldman 25 Jul '16

25 Jul '16

Previously, in the ASDF test suite, we would run tests, checking for errors, and if there were errors, we would exit with a non-zero status, signaling to our shell script that a test had failed. However, experimenting with ECL, I found that there were cases where ECL would fail with a SERIOUS-CONDITION that was not an error. These were typically various flavors of STORAGE-CONDITION, and need to be caught so that non-interactive tests don't hang when there's some resource exhaustion. Accordingly, I modified the ASDF test suite to catch not just ERRORs, but also SERIOUS-CONDITIONs. Unfortunately, this breaks the tests on CCL. The problem appears in one of our tests where we call (EXIT-LISP 0). This is (ccl:quit 0) on CCL. Unfortunately, it seems that CCL signals a CCL:PROCESS-RESET when quitting and PROCESS-RESET is a SERIOUS-CONDITION. So how should I modify the tests so that I catch the other SERIOUS-CONDITIONs (like STORAGE-CONDITIONs) without mistakenly catching these PROCESS-RESET conditions? I suppose I can either catch all SERIOUS-CONDITIONs *except* PROCESS-RESET, and just decline those? Or could I have the definition of EXIT-LISP handle the PROCESS-RESET condition? Without more knowledge, it seems possible that could mess up graceful exit. Could you clarify PROCESS-RESET a little for me? The spec indicates that SERIOUS-CONDITIONs are "All conditions serious enough to require interactive intervention if not handled should inherit from the type serious-condition." I'm not sure how that aligns with the use of PROCESS-RESET as described in the manual. Thanks, R

1 0

Fixed the release branch
by Robert Goldman 21 Jul '16

21 Jul '16

I seem to have overlooked updating the "release" branch on common-lisp.net. So the 3.1.7 tag was fine, but if someone tried to pull from the release branch, they would get an old version. This is fixed now. Thanks to RME of Clozure Associates for bringing this to my attention. Best, r

1 0

Depending on and generating files in system definitions
by Jan Moringen 29 Jun '16

29 Jun '16

Hi. It seems to be a common pattern to maintain a project's version information as a string in a separate file, e.g. version.sexp, and use something like (:version (:read-file-form "version.sexp")) to get that information into the system definition. This seems like a good thing to do as long as version changes are rare and performed manually. Unless there is a better way for this simple case, no problems or questions so far. There are, however, situations in which this doesn't work. My use-case is a project which is maintained in a GIT repository and uses the following versioning scheme MAJOR.MINOR.NUMBER-OF-COMMITS-SINCE-RELEASE This is useful for things like bug reports or determining compatibility of input files with the current version of the software. The crucial part is maintaining NUMBER-OF-COMMITS-SINCE-RELEASE automatically. Previously, I implemented this behavior using some horrible hacks that I would rather not talk about. I started from scratch and came up with a potential solution (detailed description attached). Since this seems like a common problem, I would like to ask whether the outlined approach is the proper way to do this. If so, I can try to turn the description into something that could be added to the FAQ section of the ASDF manual. Thanks in advance and kind regards, Jan

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel