asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Regression on Allegro Common Lisp
by Robert P. Goldman 08 Apr '15

08 Apr '15

I pulled an update this afternoon, and now on ACL 9.0 on Mac OS X I get a failure on asdf-pathname-test.script I get an error as follows: Above backtrace due to this condition: attempt to take the length of a non-sequence: :UNSPECIFIC I get an enormous backtrace, but this is I think the direct call that gets an error: (LET ((STREAM (OPEN . #16=((ASDF/COMPONENT:COMPONENT-PATHNAME ASDF-PATHNAME-TEST::FILE) :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE :IF-DOES-NOT-EXIST :ERROR))) (#12=#:WITH-OPEN-FILE-ABORT-398 . #61=(T))) (UNWIND-PROTECT (MULTIPLE-VALUE-PROG1 (PROGN . #17=((PRINT ASDF-PATHNAME-TEST::START-TIME STREAM) T)) (SETQ #12# . #58=(NIL))) (WHEN (STREAMP STREAM) (CLOSE STREAM :ABORT #12#)))) More as I find out more. Best, r

3 4

Re: trying some ASuDF tests on Windows (was: Re: [asdf-devel] Volunteer for LispWorks testing?)
by Dave Cooper 08 Apr '15

08 Apr '15

Fare wrote: > > The test-bundle.script output suggests that, on Windows, there might > be a bug in ccl:fasl-concatenate. Please create a reduced test, and > open a bug against CCL if that is indeed the case, using > http://trac.clozure.com/ccl/newticket > Ok, I went ahead and opened a CCL bug, which was (almost immediately) reported as fixed in the subversion trunk and the ticket (#1109) was closed. Then I built a CCL from the trunk (which is 1.10-dev), and indeed this failure goes away when using 1.10-dev. See the results in the 2013-09-05 folder in the link below. > > The test-multiple.script failure reveals an error in run-program, that > looks like it does a (cons "cmd" argument) instead of a (list "cmd" > argument). Same failure in test-run-program.script. > I tried changing the code in uiop/run-program.lisp from: #+clozure (cons "cmd" (strcat "/c" command)) to #+clozure (list "cmd" (strcat "/c" command)) but still get some failures in test-run-program.script. Maybe they are different failures. See results below. https://www.dropbox.com/sh/jc2cqwpkp06dupm/1FZ_YlVvVW/cl/tests/asdf/output By the way, the run-program tests seem to use the command "ln" for testing -- this command isn't there by default on Windows, is it? The issue with ";" vs. ":" for path separator I'm not sure exactly where to fix, so I leave that alone for the time being (anyone else care to jump on it?) --- apparently that's not CCL-specific, but a general Windows asdf testing issue? On Wed, Sep 4, 2013 at 5:07 PM, Robert P. Goldman <rpgoldman(a)sift.info>wrote: > Dave Cooper wrote: > > > > Hi Robert, > > > > [also cc'ing this to asdf-devel in case anyone else has feedback] > > > > Ok, shifting gears a little bit here first... > > > > I'm trying a few test runs of the ASDF test suite on Windows. Platforms > > on Windows which I have available to test right now are: Allegro CL > > (several variations), and CCL. > > > > To prepare to run the tests on Windows, I installed cygwin and cygwin's > > make. Then to run the tests, I do (for lack of having this more > > automated so far): > > > > 1. set ASDF_TEST_LISPS appropriately. > > > > 2. Edit run-tests.sh to point to appropriate Lisp executables. > > You actually shouldn't need to do that -- there is one environment > variable for each of the executables, and you can set those, if the > default values don't work for you. > > > > > 3 Invoke "make test-all-no-upgrade" from the cygwin command shell. > > > > Let's try CCL first. Here are the outputs: > > > > > https://www.dropbox.com/sh/jc2cqwpkp06dupm/-vvd5gFwTk/cl/tests/asdf/output/… > > > > Summary: 42 out of 47 pass (5 failures). > > > > I can try to dive into these further, but I thought I would post the > > results here first in case anything is obvious to anyone. > > > > Incidentally, I have been running ASDF in production with Allegro CL for > > some time now (including asdf:monolithic-fasl-op) and it has been > > working well. There are some startup glitches for running ASDF tests on > > Windows/Allegro right now. After the CCL issue is resolved I will return > > to trying to get the tests to run for Allegro on Windows. > That would be great. > > By the way, the bundle tests aren't working for me on a couple of other > lisps. > > cheers, > r > > > -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

4 17

[asdf-devel] In defense of ASDF & Semantic versioning
by Robert P. Goldman 08 Apr '15

08 Apr '15

Anton Vodonosov wrote: > The manual says: > "the :version, :author, description and other [defsystem] fields are not required but they provide documentation and information for people that want to use this system. > It also says in the section about asdf:operate: > "If a version argument is supplied, then operate also ensures that the system found satisfies it using the version-satisfies method." > > From some other places in the manual we can even guess how version-satisfies work. > > Still, I think it was too much to expect from closer-mop to encode > API compatibility information in the version identifier. > Note also, in 2009 ASDF didn't consider version "0.6" as satisfying > requirement for "0.55": Yes, that's because the version scheme in ASDF is not a sequence of period-separated integers, but a sequence of period-separated strings. That was in ASDF 1, and we didn't dare mess with it. Pascal was very kind about this oddity, and has tweaked his revision numbering to fit ASDF's constraints. > http://lists.common-lisp.net/pipermail/moptilities-devel/2009-December/date… When Faré wrote up the design rationale for ASDF, one of the principles was that ASDF should ask the right person for the right information. For example, the library should not dictate where files go -- that's the job of the library's installer (user). The library itself knows where its components are *relative to the installation* -- that's information the library implementor will have, which the installer will not have. Similarly, if I am the library supplier, I am the one who knows when I have changed the API incompatibly. That is why major component version changes were intended *not* to satisfy version requirements that have different major components. This is reasonable, because it provides a channel of information from the library supplier, that can be checked automatically, and if the downstream is still compatible, it should be a relatively easy fix (but is it? I don't know if there's a good way to say "I'll accept version 0.55+ or 1.0+"). The only other option would be to have the library client provide both upper and lower bounds on the version numbers that the client will accept. But, except for cases of *known* upgrade incompatibility, this is information that the library client simply cannot have. The rules here are simple and easy to understand: if you change the API in an incompatible way, bump the major version number. Yes, this rules out the false modestly of version numbers like 0.0.145, which looks like an alpha, but in fact turns out to be the fifth full release, but that's a sacrifice we can all live with! ;-) As my own devil's advocate, the counter-argument is that the state of the art in CL libraries is so poor that even getting a version number is unusual. But this seems to be a counsel of despair: it says that since we have a bad state of affairs now, we are doomed to live with it forever. I suppose I could take a little while and write up a candidate "versioning systems with ASDF" node for the ASDF manual, and push it for consideration by the community. > > Also, as we speak about versioning, I have been trying to use semantic > versioning as described at http://semver.org/ and I don't think it is > a silver bullet - it doesn't solve all problems. Isn't the subtitle of /The Mythical Man-Month/ "No Silver Bullet"? Yes, this doesn't solve every problem, but it might give you a useful warning if your upstream has changed under you.... Pascal's case is an odd one, because the bump to 1.0 is, in some sense, a false positive. OTOH, it's not really so bad to have to take a look at a library that has seen no commits in three years. Cheers, r

9 27

[asdf-devel] One failure on ASDF 3.1.0.70 on Allegro/Windows
by Dave Cooper 08 Apr '15

08 Apr '15

Sorry to be late to the party again with Windows testing... So far I'm seeing a consistent failure for every Allegro variant on Windows for test-sysdef-asdf. Here is the error: These two expressions fail comparison with equal: (asdf-test::system-lisp-files :uiop) evaluates to ("uiop\\package.lisp" "uiop\\common-lisp.lisp" "uiop\\utility.lisp" "uiop\\os.lisp" "uiop\\pathname.lisp" "uiop\\filesystem.lisp" "uiop\\stream.lisp" "uiop\\image.lisp" "uiop\\run-program.lisp" "uiop\\lisp-build.lisp" "uiop\\configuration.lisp" "uiop\\backward-driver.lisp" "uiop\\driver.lisp") (asdf-test::makefile-lisp-files "driver-files") evaluates to ("uiop/package.lisp" "uiop/common-lisp.lisp" "uiop/utility.lisp" "uiop/os.lisp" "uiop/pathname.lisp" "uiop/filesystem.lisp" "uiop/stream.lisp" "uiop/image.lisp" "uiop/run-program.lisp" "uiop/lisp-build.lisp" "uiop/configuration.lisp" "uiop/backward-driver.lisp" "uiop/driver.lisp") Script failed -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

7 27

[asdf-devel] Releasing asdf 3.1.1 ?
by Faré 08 Apr '15

08 Apr '15

Dear Robert, do you think we can release this year? All tests pass for me on Linux, and I believe all tests were passing for Dave Cooper on Windows. There has been very light development this past month, with no intent for further development ahead, but notable new features and bug fixes since the last release in October. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A student who changes the course of history is probably taking an exam.

5 21

Test failure: CCL 1.9 on Mac OSX
by Robert Goldman 08 Apr '15

08 Apr '15

Just pulled and ran all the tests, and CCL 1.9 fails test-utilities on Mac OSX: TEST ABORTED: These two expressions fail comparison with EQUAL: NIL evaluates to NIL (FISHY-ASDF-EXPORTED-SYMBOLS) evaluates to (ASDF/OPERATION:ORIGINAL-INITARGS) cheers, r

2 2

Re: [asdf-devel] Port of ASDF 3.1.0.94 to MKCL
by Jean-Claude Beaudoin 08 Apr '15

08 Apr '15

On Mon, Mar 17, 2014 at 2:47 PM, Robert P. Goldman <rpgoldman(a)sift.info>wrote: > Jean-Claude Beaudoin wrote: > > > > > > > > On Mon, Mar 17, 2014 at 12:48 PM, Robert P. Goldman <rpgoldman(a)sift.info > > <mailto:rpgoldman@sift.info>> wrote: > > > > Random minor question: > > > > In bundle.lisp why the replacement of 'defsystem with > > 'asdf/defsystem:defsystem? Did something go wrong for you with the > > former? > > > > > > The "defsystem" symbol was interned in the wrong package, being read at > > that point of the code into package "asdf/bundle". Package "asdf/bundle" > > does > > not use package "asdf/defsystem". All this resulting into a failure to > > properly > > expand the defsystem macro. > > So, in other words, the bundle code was buggy before, right? You are quite right yourself. > I wonder > why we didn't see this.... What piece of your code exercised this? I'd > like to know so we can test. > The bundle facility is a central part of the MKCL build process. A large part of what MKCL puts in its "contrib" sub-directory is built using it. > > > > > > > > > > Other than that, I didn't see anything in the diff. > > > > > > I hope that you mean that you didn't see anything *wrong* in the diff. > > You are quite right! > > I'll merge to master and tag this afternoon. > > Thanks, > R > > > P.S.: I took the liberty to CC the asdf-devel list since your initial "defsystem" question had too, I left the CC out of my reply by simply not paying enough attention to which reply button I clicked.on.

2 8

Re: [asdf-devel] Releasing asdf 3.1.1 ?
by Faré 08 Apr '15

08 Apr '15

OK, so I've run complete tests of ASDF 3.1.0.34 on Linux x64 with ASDF_TEST_LISPS="ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes ecl abcl xcl gcl" I got one unexpected failure, excepted failures: cmucl upgrade total failure https://bugs.launchpad.net/asdf/+bug/1209272 3 failures in gcl (gcl bugs, Camm needs to get back to me). The unexpected failure was ecl's test-bundle: due to misconfiguration in test-asdf.asd, the explicit secondary definitions of test-asdf/dll-test was now overridden by package-system, which was causing asdf/package-system to fail ungracefully because the file had no defpackage form. Failing with end-of-file error rather than giving a user-meaningful error message was a bug. package-system now yields a user-readable error in such cases, with test cases added to the test suite. And the configuration error in test-asdf is now fixed. I'm re-running all the tests with ASDF 3.1.0.35. Looking good so far. Please keep testing in view of a release 3.1.1. PS: Regarding the previously mentioned Quicklisp bugs, see https://github.com/quicklisp/quicklisp-controller/issues/7 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Reason isn't about not having prejudices, it's about having (appropriate) postjudices. — Faré

2 5

[asdf-devel] asdf/bundle and ECL prologue / epilogue
by Faré 08 Apr '15

08 Apr '15

Is anyone at all using asdf-bundle with ECL? It looks like the prologue and epilogue support were casualties of some operation canonicalization. Also, the way the flags are or aren't propagated to sub-operations is misdesigned. Finally, it seems like prologue and epilogue ought to be part of the system, not of the operation — and they are possibly superseded by ASDF3's image support. If anyone is using these features, please contact me ASAP. Otherwise, I'm going to commit into asdf/bundle whatever I believe makes sense. (Bug found through thorough testing of cl-launch.) And of course, please fix that bug that breaks building a program in recent ECL: https://sourceforge.net/p/ecls/bugs/285/ —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré]

3 6

[asdf-devel] Loading pre-compiled fasls
by Yellow Dog 08 Apr '15

08 Apr '15

Hi, I was wondering if I could ask for some advice. I'm currently working with lisp-zmq which uses grovel to create the CFFI declarations. This is fine and works great on my development box, but I would prefer not to require that other developers in my organization also run grovel. As such, I would like to be able to check in the files that were generated by grovel and have these automatically loaded in other environments. This already works! However, my problem is that in our environment, ASDF compiles fasls into a default user output path and then loads them (something like ~/.cache/common-lisp/...). I will not have any control over the content at this location prior to loading the lisp-zmq system for the first time, and so there isn't really anywhere that I can automatically deploy the pre-generated grovel files. My questions are: * Is there any way to specify using defsystem that a local fasl should be used? * Are there any suggestions that anybody can give me to solve my problem. Perhaps I should precompile the lisp-zmq system and load that instead. I'd rather not change any of the behavior on anybody's development environment, so (asdf:disable-output-translations) isn't an option. I'd like to have this self contained as much as possible. Many Thanks, Kevin

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