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

Re: [asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems
by Faré 08 Apr '15

08 Apr '15

>>: fahree >: rpgoldman >> Which UIOP patches were you thinking of? I fixed a simple one >> regarding ensure-function. I see other portability issues with >> directory* and symlinks, but I am not competent to address them. > > I'm thinking of 1205555 https://bugs.launchpad.net/asdf/+bug/1205555 and > 1205653 https://bugs.launchpad.net/asdf/+bug/1205653 > > I was hoping to get some work done on these, but that target is slipping. > I was thinking about them as well. Notice how the goals are opposite: one wants symlinks to be followed, the other not to. I admit to trying to introducing the avoidance of recursing through symlinks, because in some cases it could cause infinite recursion, etc., especially when some software likes to have an uplink to a directory full of dependencies, and the software is in the same directory. Although I would like there to be a semi-standard way to avoid symlinks, I understand it might not be possible, and the anti-symlink code might have to be removed, and such software will have to be amended. You're the maintainer, you get to decide. > I just tested on an old and crufty linux box. Worked for ccl sbcl cmucl > allegro allegromodern. ECL fails the test on my box. Goes into an > infinite loop compiling test/file3.lisp -- gets an error in compilation, > retries, gets an error .... > > This may be the fact that I'm trying this on an ancient OpenSUSE box, > with a distro version that's been EOLed, so that may be me, not ASDF. > > If you could test with ECL, and it works for you, I am going to chalk > this up to my ancient distro. > Which test script causes that? It's working here on ecl-13.5.1-914ce253-linux-x64 > I don't have a good way to tell if ABCL is busted on Mac or our bundle > op is busted on Mac. > Maybe we can convince someone on the ABCL team to run our tests? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Procrastination is great. It gives me a lot more time to do things that I'm never going to do.

1 0

[asdf-devel] testing uiop:enable-deferred-warnings-check with cl-test-grid
by Anton Vodonosov 08 Apr '15

08 Apr '15

12.02.2014, 09:24, "Faré" <fahree(a)gmail.com>: > On Tue, Feb 11, 2014 at 11:56 PM, Anton Vodonosov <avodonosov(a)yandex.ru> wrote: > >> Next I will try the deferred-warnings >> enabled and :uiop in the use-list of :asdf-user. > > Thanks a lot! > > I assume you're doing these tests separately: Yes, separately. I now have results for SBCL and CCL with (uiop:enable-deferred-warnings-check): http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-31.html

2 2

Re: [asdf-devel] Ordering of system :depends-on elements
by Zach Beane 08 Apr '15

08 Apr '15

Robert Goldman <rpgoldman(a)sift.info> writes: > Zach Beane wrote: >> Faré <fahree(a)gmail.com> writes: >> >>> A solution that is both backward-compatible and forward compatible is >>> >>> 1- to rename the systems so they follow the foo/bar convention for >>> naming systems in foo.asd, so that ASDF3 can find them. This solves >>> forward compatibility >> >> If anyone considering fixing mcclim is reading this, please don't use a >> slash-named system. It's incompatible with Quicklisp. >> >> Zach > > Can you explain the incompatibility? > > It would be hugely useful to be able to map multiple systems to a > single file, as your McCLIM example illustrates. I think it illustrates the problems of putting multiple systems in the same file, not the utility. > But, of course, we want to maximize quicklisp compatibility. > > So can you make suggestions about how to be quicklisp-compatible while > making it possible to have multiple findable system definitions in a > single file? Hmm, I think it might be workable if, when a system with a given slashed name is not found, the *system-definition-search-functions* chain was called recursively with the truncated name, instead of having each function in *s-d-s-f* have to know how to truncate on its own. E.g. imagine I had something like this: (push (lambda (name) (print (list 'trace name)) nil) *system-definition-search-functions*) Then it would be nice if the ASDF internals led to putput like this: (find-system "foo/bar") (TRACE "foo/bar") (TRACE "foo") => #<SYSTEM "foo/bar"> Does it work that way now? I don't think it does. Zach

3 7

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

08 Apr '15

Here is, as previously mentioned, the git format-patch with the modifications needed to port current ASDF head to MKCL 1.1.8 and later. This has been tested on Linux Ubuntu 12.04 and MKCL 1.1.8 where it passes all 51 tests of the current ASDF test-lisp without any failure. Cheers, Jean-Claude Beaudoin

3 8

[asdf-devel] has ":depends-on ((:version ...))" semantics changed?
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. Has the semantics of :depends-on with :version specified for the dependency changed recently? I am asking, because I observe problems in several libraries. For example, moptilities. moptilities.asd has :depends-on ((:version :closer-mop "0.55")) In Quicklisp 2013-11-11 closer-mop is updated, now its ASDF system has :version "1.0.0" Now moptilities fails to load on many lisps (clisp, ccl-1.8, ccl-1.8, ecl, sbcl-1.1.0.36). The error is MISSING-DEPENDENCY-OF-VERSION: Component :CLOSER-MOP does not match version 0.55, required by #<SYSTEM "moptilities"> But on sbcl-1.1.11 moptilities load OK. This is a relatively recent SBCL, so I assume it has newer ASDF than many other lisps. And probably that's why it it can load moptilities. Also interesting, that in the previous Quicklisp closer-mop version was "0.61". And moptilities, which depend on closer-mop "0.55" was loaded successfully by many lisps which now fail. Test results for moptilities for the current and previous Quiclisp may be found here: http://common-lisp.net/project/cl-test-grid/library/moptilities.html Moptilities is only on example, there are other libraries affected by this problem. So, my question is: how :depends-on ((:version ...)) should work, and is the change in the behavior intentional? Best regards, - Anton

5 13

[asdf-devel] Testing ASDF with cl-test-grid
by Faré 08 Apr '15

08 Apr '15

Dear Anton, > When we tested with cl-test-grid, > ABCL, CMUCL, CCL, CLISP, ECL, SBCL were tested on 2.31.8 > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-21.html > > The latest cl-test-grid cycle was for ASDF 2.32.35, it was tested > on CCL, CLISP, ECL, SBCL on Linux. > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-23.html > > So, as you see we ended up testing last fixes only on some lisps, > not all lisps. Probably that's because it was stabilizing period and > the fixes were for concrete bugs. > > Still, we didn't make a firm "rollback" point - an ASDF version where we > ensured we have no regressions on all lisps. For now I suggest to consider > 2.32.35 as more or less reliable previous comparison point, where > all regressions were proved to be not ASDF bugs, but bugs in libraries, > and were reported to the library maintainers. > > I hope in this ASDF release, we will test the released version > on maximum number of lisps, so that in future we will have reliable > comparison point. > Yes. This time, let's use 2.32.35 as our baseline, and if you can, test both ASDF 3.0.3 as the current stable, and 3.1.0.32 (current HEAD) as our release candidate for 3.1.1. I don't actually expect any change in cl-test-grid results between all these versions, except maybe that my own software (e.g. lisp-interface-library) might possibly fail on older versions of ASDF. >> But then, you'd have to check with both old and new Quicklisp. > > I am going to run tests of both previous stable ASDF version and the > current HEAD on the same Quicklisp - 2013-12-13. > Thanks a lot! >> I suppose that you should compare with whatever comes with the implementation. > > OK, we can do this too - we will compare result for the latest ASDF > with the results for the "main", unpatched quicklisp, which uses ASDF > coming with the implementation. > > It also would be nice to compare with some concrete previous stable > ASDF version, as described above, to be sure we cover full ASDF evolution > on all lisps. > Don't overdo it. I would do it with maybe 2.26 (default from Quicklisp), 2.32.35 (previous tested), 3.0.3 (latest stable) and 3.1.0.32 (release candidate), and that's already a lot. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty.

3 13

[asdf-devel] ASDF's MAKE-BUILD breaks ECL's DLL target
by Juan Jose Garcia-Ripoll 08 Apr '15

08 Apr '15

I have real trouble deciphering the new make-build code but I have come to the conclusion that the :DLL target has been eliminated. The current :DLL target claims to "Link together all the dynamic library used by this system into a single one." which is not what ECL's :DLL target was doing. ECL's :DLL/:SHARED-LIBRARY target did the same as :STATIC-LIBRARY, which is to link all FASL files into a single, linkable file, but in the shared library form. The elimination of this feature and the replacement with a possibly empty behavior (I see no opeartion associated to DLL at all), breaks ECL's users code and expectations, having had already some bug reports for that. The worse thing is that I no longer seem to understand ASDF's internal's logic well enough to provide any reliable kind of fix, but what I attached seems to do the job just as well. In this patch, since the DLL operation does nothing on any other platform, I took the liberty to condition it on ECL/MKCL Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://quinfog.iff.csic.es

2 5

[asdf-devel] Tests completed
by Robert P. Goldman 08 Apr '15

08 Apr '15

Over the weekend ran the full up tests, with upgrade as well as regression tests, on Mac OSX Lion with the following lispen: ccl clisp sbcl cmucl lispworks allegro_64 allegromodern_64 allegro8_64 allegromodern8_64 allegro_64_s allegromodern_64_s allegro8_64_s allegromodern8_64_s ecl abcl All tests completed successfully. I would like to do the following: 1. Add warnings as appropriate wrt changes in OPERATION hierarchy for code that extends OPERATION classes. 2. Add warnings for people using ABCL or ECL + bundle-op on Mac OS. ...and then do a release. Cheers, r

4 21

[asdf-devel] clisp, logical pathnames, and ASDF
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have been grappling with my inability to upgrade clisp, and find myself confused by the following events in my transcript: [17]> (uiop/pathname:ensure-pathname "home:lisp;asdf;") #P"home:lisp;asdf;" [18]> (probe-file (merge-pathnames (uiop/pathname:ensure-pathname "home:lisp;asdf;") "asdf.asd")) NIL [19]> (translate-logical-pathname "home:lisp;asdf;asdf.asd") #P"/Users/rpg/lisp/asdf/asdf.asd" [20]> (probe-file (translate-logical-pathname "home:lisp;asdf;asdf.asd")) #P"/Users/rpg/lisp/asdf/asdf.asd" [21]> (probe-file (merge-pathnames (translate-logical-pathname "home:lisp;asdf;") "asdf.asd")) #P"/Users/rpg/lisp/asdf/asdf.asd" Am I for some reasonnot to expect that the standard pathname functions (e.g., merge-pathnames) will work with logical pathnames? The online clisp manual page discussing LOGICAL PATHNAMES says only: "No notes." http://www.clisp.org/impnotes/log-path.html But as I understand the CLHS on MERGE-PATHNAMES, with reference to the definition of "pathname designator", the above behavior seems to be non-conforming. I am not at all experienced with clisp, and find myself on strange and shaky ground here. thanks, r

3 7

[asdf-devel] Ordering of system :depends-on elements
by Zach Beane 08 Apr '15

08 Apr '15

A few projects in quicklisp work something like this: ;;; foo.asd (defsystem foo ...) (defsystem foo-extra ...) ;;; bar.asd (defsystem bar :depends-on (:foo-extra :foo)) With asdf 2, (asdf:load-system "bar") seems to work fine, I guess because asdf 2 does the equivalent of find-system on the elements from right-to-left. With asdf 3, it doesn't seem to work fine, I guess because asdf 3 does the equivalent of find-system on the elements from left-to-right. Are those guesses correct? What's the best way to have a system definition that works equally well in asdf2 and asdf3 in this kind of situation? Zach

7 15