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

[asdf-devel] uiop/filesystem:directory-files
by Станислав Кондратьев 08 Apr '15

08 Apr '15

Hello, I tried uiop and discovered two issues. I had installed uiop using quicklisp. The first issue looks like a bug: if I list the files of my home directory in CLISP, every file is included in the list twice as if the directory were listed two times. This takes place no matter if I specify the directory as "~/" or spell it out, and also if I run CLISP in my home directory and use uiop/os:getcwd. However, the function works normally with directories other than the home one. I did not specify wildcards in either case. I have observed this behaviour on Debian and OpenSuse. The second issue looks like a discrepancy between implementations: while in CLISP uiop/filesystem:directory-files returns a list of files (not subdirectories), in SBCL the directories are included into the output. I wonder at least which behaviour is the intended one. Best regards, Stanislav.

3 3

[asdf-devel] component-load-dependencies
by Didier Verna 08 Apr '15

08 Apr '15

Hello, currently Declt advertises component dependencies by using COMPONENT-LOAD-DEPENDENCIES. This function however only returns a list of symbols naming the components. What would be the best way to retrieve a list of component objects instead ? Thanks! -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

2 6

[asdf-devel] ASDF 3.0.3 ported to MKCL 1.1.7
by Jean-Claude Beaudoin 08 Apr '15

08 Apr '15

Hello ASDF maintainers, I just completed a port of ASDF 3.0.3 to what will soon be released as MKCL 1.1.7. It currently passes all the 48 tests of yours on Linux (Ubuntu 12.04) and I will very soon test it on Win32 and Win64 (I expect a routine ride there). I would like to submit back to you the few lines of ASDF code I had to conditionalize to get this port working OK. Can we do this through a "Pull request" on github? I see both a fare/asdf and a rpgoldman/asdf repositories that look like the head of ASDF evolution which one should I fork, merge with and then send the pull? Cheers, JCB

3 5

Re: [asdf-devel] Advanced Configuration
by FAU 08 Apr '15

08 Apr '15

I corrected it to your advice accordingly. (defmethod output-files ((operation compile-op) (component foo-file)) (multiple-value-bind (pathnames translatep) (call-next-method) (values (mapcar #'(lambda (p) (make-pathname* :directory (append (pathname-directory p) (list (cond ((featurep :foo1.0) "1.0") ((featurep :foo1.1) "1.1") (t (error "No foo feature found."))))) :defaults p)) pathnames) translatep))) On Sat, 2013-11-16 at 17:34 -0500, Faré wrote: > On Sat, Nov 16, 2013 at 5:21 PM, FAU <fau(a)riseup.net> wrote: > > (defmethod output-files ((operation compile-op) (component foo-file)) > > (let ((l (multiple-value-list (call-next-method)))) > > (apply #'values (mapcar #'(lambda (p) > > (make-pathname* :directory (append (pathname-directory p) (list # > > +foo1.0 "1.0" #+foo1.1 "1.1")) :defaults p)) > > (car l)) > > (cdr l)))) > > > Inasmuch as I think that runtime conditionals should be used rather than > compile-time conditionals wherever performance permits (see also featurep), > your general scheme is valid. However, you can should be using > (multiple-value-bind (pathnames translatedp) ... > (values ...)) > There are only two values returned in this protocol. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > When my contradictors' ideas aren't an incoherent mess I can easily disprove, > I call them for the ideologists they are; but they are so dogmatic, > they don't change their mind after I insult them. >

1 0

[asdf-devel] Ready to release?
by Faré 08 Apr '15

08 Apr '15

I tweaked the upgrade to punt more on abcl, and it looks like it's working. cmucl, on the other hand, is desperately borking on upgrade, with or without punt. Apart from that, asdf 3.0.2.28 passes all tests for me on linux, including upgrade tests (except on cmucl), for ccl clisp sbcl cmucl allegro allegromodern abcl I also ran tests (but not upgrade tests yet) successfully for: ecl ecl_bytecodes lispworks xcl A few minor patches ago, I also tested that it can be compiled and run correctly on genera. I admit I'm growing impatient for a release 3.0.3 of ASDF. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org He who refuses to do arithmetic is doomed to talk nonsense. — John McCarthy, in his webpage on Progress and Sustainability

2 10

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