asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Re: [armedbear-devel] Re: cl-test-grid: Testing ABCL-1.2.0-RC
by Faré 08 Apr '15

08 Apr '15

On Tue, Jun 11, 2013 at 1:32 PM, Zach Beane <xach(a)xach.com> wrote: > Faré <fahree(a)gmail.com> writes: > >> Inferior-shell *should* be able to compile with ASDF 2. >> If not, it's a bug. Meh: not as easy for me to test as I'd like. > > It uses the slash/package name thing. I'm not sure when it was > introduced, but my build system doesn't understand it. > Autodetection of foo/bar as meaning "read it from foo.asd" is an asdf3-ism, but systems named like that work on asdf2 (and asdf1) just like any other system defined in a .asd — of which there used to be a lot even before this convention was invented. i.e. once defined asdf can use them, but before the .asd file is loaded asdf1&2 have no idea where to look for them. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Only a fool tests the depth of the water with both feet. — African proverb

2 3

[asdf-devel] 3.0.2.21
by Faré 08 Apr '15

08 Apr '15

This weekend, thanks to Dave Cooper, there was much bug fixing on windows, particularly (but not only) related to run-program (and, unhappily, also unearthing implementation bugs in at least in Allegro and SBCL). PJB also found a bug in with-temporary-file, that was fixed. Because I was remote-debugging and failed to think about sharing a topic branch, this led to many increments in patch number. The test system was made more robust as a result. I also found a bug in test-module-pathnames (failure to specify *test-directory* to merge-pathnames*) that may or may not explain the test failures that Robert was seeing on LispWorks/Mac, and Dave on sbcl/win -- Robert, does your pathname under LispWorks have a non-nil host and/or device? That would explain it. SBCL/win also has massive failures in asdf-pathname-test, which I don't fully understand (I don't understand this janderson-contributed test in general), but every other file write test is a failure. Robert: can I commit this asdf-package-system branch now, before the 3.0.3 release? It's only additive features, modulo a rename of file asdf/defsystem to asdf/parse-defsystem (with a nickname for the old package name) and system asdf/header to asdf/prelude. Maintaining that topic branch is slightly costly, I've been using it for a week and removed a lot of kinks and relative inefficiencies. The new features are the support for the package-system "one package per file" style of quick-build, and some useful :use-reexport and :mix-reexport options of uiop:define-package. I believe it's not affecting anything negatively and is robust, and I'd really like to be able to encourage people to "just use it" without waiting for a few more months until the next release. [I'm using it for lisp-interface-library, but it's more awkward if people have to use the asdf extension asdf-package-system.] —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Panties: not best thing on earth, but next to it.

4 8

"Solved" (was: Re: [asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25)
by Dave Cooper 08 Apr '15

08 Apr '15

> > > It's not crucial that I release with this latest 3.0.2.32, but I just bring > > up this issue in case it is actually a lurking asdf bug which needs to be > > shaken out before 3.0.3 release... > > > > If something is broken, we definitely want to solve before release. > But I fear the problem is with your configuration somehow. > I "solved" the issue by the following bootstrap procedure: 1. compile/load adsf3 2. (remhash "uiop" asdf::*preloaded-systems* 3. load quicklisp's setup.lisp Without step (2), the preloaded system of uiop occurs first in *system-definition-search-functions*, so the separable project for uiop (in my case, in local-projects), never ends up being found, and therefore ends up missing from the monofasl (I do suspect that the fact that it silently fails to be included in the monofasl can be considered a bug -- this probably should throw an error when trying to build the monofasl and realizing that the uiop.fasl is not showing up to the party, shouldn't it?) So is this a use case which should be more directly supported? Does this call for an unregister-preloaded-system or some such thing? Regards, Dave On Tue, Oct 22, 2013 at 10:57 AM, Faré <fahree(a)gmail.com> wrote: > > So I went ahead and tried > > > > (load (compile-file "quicklisp/asdf.lisp")) > > > > before loading quicklisp/setup.lisp. > > > If you already changed the quicklisp copy and *required-asdf-version* > to something later than your implementation-provided ones, as I > believe you are, this step is redundant. > > > And yes, I copied version.lisp.expr into quicklisp/local-projects/uiop/. > > > Did you use cp -aL with -L to dereference the symlink? > It worked for me. > > > To test that it wasn't ignoring the uiop in local-projects because it is > the > > same version as what is already loaded, I even temporarily bumped the > > version number in that version.lisp-expr to 3.0.2.33. > > > No, I don't think it's magically checking the version against > downgrade, as it is doing for asdf itself. Maybe it should? > > CL_SOURCE_REGISTRY=~/cl/poiu rlwrap sbcl --eval "'(#.(map () 'require > '(:asdf :poiu)) #.(in-package :asdf) #.(load \"~/quicklisp/setup\"))" > * (system-source-directory :uiop) > #P"/home/tunes/quicklisp/local-projects/uiop/" > > I didn't even have to (ql:register-local-projects) in that session — > or maybe its effects were persistent across section? Looking at the > source, it builds an index, so you need to run it once after you > installed the copy of uiop, and thereafter its effects should persist. > > > Still no dice -- I still get > > > > (asdf:system-source-directory :uiop) --> nil > > > > after loading the quicklisp/setup.lisp and (ql:register-local-projects) > > > > Quicklisp works in general after the upgrade. It just can't find the > source > > directory (or any source directory) for :uiop. > > > > > It's not crucial that I release with this latest 3.0.2.32, but I just > bring > > up this issue in case it is actually a lurking asdf bug which needs to be > > shaken out before 3.0.3 release... > > > If something is broken, we definitely want to solve before release. > But I fear the problem is with your configuration somehow. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org > What one person receives without working for, another person must work for > without receiving. — Adrian Rogers > -- 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

3 10

[asdf-devel] New failures on Allegro Windows
by Dave Cooper 08 Apr '15

08 Apr '15

With latest pull (with 3.0.2.22) I'm getting one failure on mlisp windows and two on alisp windows (a few pulls ago, alisp windows was passing all tests and mlisp was unknown but apparently failing several which are apparently all fixed now, because the one mlisp failure does not appear casemode related): =========== mlisp: Above backtrace due to this condition: These two expressions fail comparison with equal: "ok 1" evaluates to "ok 1" (asdf-test::dewindowize (uiop/run-program:run-program "echo ok 1" :output :line)) evaluates to "ok 1" Script failed <The Lisp process exited with status 1 (0x1)> =========== alisp: Above backtrace due to this condition: These two expressions fail comparison with equal: "ok 1" evaluates to "ok 1" (asdf-test::dewindowize (uiop/run-program:run-program "echo ok 1" :output :line)) evaluates to "ok 1" Script failed <The Lisp process exited with status 1 (0x1)> Above backtrace due to this condition: These two expressions fail comparison with EQUAL: (ASDF-TEST::SANITIZE-LOG (ASDF-TEST::RELOAD ASDF/DEFSYSTEM:DEFSYSTEM)) evaluates to ((:COMPILING :SYSTEM)) (QUOTE ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2))) evaluates to ((:COMPILING :SYSTEM) (:COMPILE-TOPLEVEL :FILE1) (:LOAD-TOPLEVEL :FILE1) (:COMPILE-TOPLEVEL :FILE2) (:LOAD-TOPLEVEL :FILE2)) Script failed <The Lisp process exited with status 1 (0x1)>

3 4

[asdf-devel] ASDF testing for 3.1.0.24 begins...
by Dave Cooper 08 Apr '15

08 Apr '15

Running tests against 3.1.0.24. So far we have a failure for abcl on Windows. I plan to put all my asdf test failures here from now on: https://www.dropbox.com/home/Public/asdf-failures I'll try to send notifications when something new lands in there. Will it be useful to post the non-failure test results as well? By the way, as far as I know we can still use some test volunteers for the following commercial platforms: Allegro MacOS LispWorks Windows (Nick L, Fabrice P?) LispWorks Linux Scieneer (all its supported platforms) Genera (all its supported platforms) This is not to discourage additional testers on the platforms we already think we are covering (the more eyes the better). What am I missing? -- My Best, Dave Cooper, Genworks Support david.cooper(a)genworks.com, dave.genworks.com(skype)

1 1

[asdf-devel] New OPERATION subclasses in ASDF 3
by Robert P. Goldman 08 Apr '15

08 Apr '15

Recent experience shows that changes leading to ASDF 3 have changed the way one must specify new operation classes, in a way that is not backward-compatible. Thanks to Faré for helping me diagnose problems in one such system. I will be looking into this, and hope to add at least one new test to ensure that we are probing this important aspect of ASDF going forward. Related to this, does anyone have a good sense of which quicklisp systems might contain new operation and component classes? thanks, R

3 3

[asdf-devel] Detecting non-defsystem dependencies
by Zach Beane 08 Apr '15

08 Apr '15

Some system files look like this: ;;;; myproject.asd (asdf:load-system "some-prerequisite") (defsystem "myproject" ...) Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward? Zach

4 11

Re: [asdf-devel] BUNDLE-OP now working on abcl-1.3.0-dev
by Mark Evenson 08 Apr '15

08 Apr '15

On Feb 12, 2014, at 16:57, Robert Goldman <rpgoldman(a)sift.net> wrote: > > Thank you very much, Mark -- I will get a micro-patch for this installed into ASDF for the new release. ASDF 3.1.0.65 works with ABCL trunk, which has just been committed as [r14626][]. Sorry that it is taking me so long to close out the ABCL issues. Next up: pathname translation (wrt. case). [r14626]: http://abcl.org/trac/changeset/14626 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[asdf-devel] Release notes
by Robert P. Goldman 08 Apr '15

08 Apr '15

Stelian Ionescu wrote: > [...] >> > Every release comes with release notes that mention changes to the API. >> > I haven't announced changes with every commit, because that would be verbose, >> > and people who're interested can already read the git log. > > Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no > such thing, nor the git repository. That's a good point. There is a pretty comprehensive changelog, but it's buried in the debian/ subdirectory. There's always been a release announcement emailed out, but that isn't included in the tarball. I'll try to improve our practice here. Proposal: before releasing I will put release notes into the top ASDF directory. These will be the same as what goes in the email message. I'll also make sure there's a copy of the changelog at the top level, with a cross-reference. Subscribers to ASDF-devel will be urged to review these and suggest improvements, before the release is made official. Does this sound like a reasonable process? cheers, r

3 2

[asdf-devel] SOURCE-FILE-TYPE
by Robert P. Goldman 08 Apr '15

08 Apr '15

I have a note from you requesting that I mark SOURCE-FILE-TYPE as deprecated in code and documentation. I'm not sure I fully understand. The code in component.lisp still uses this, and it's not obvious how to remove it (nor what it means that it can return :DIRECTORY). I *believe* that what you mean is that SOURCE-FILE-TYPE will stay, but that outsiders should no longer make methods on it: instead they should use the :FILE-TYPE slot on FILE-COMPONENT. But maybe not; see my point 3 below. Some follow up: 1. This comment: " ;; SOURCE-FILE-TYPE below is strictly for backward-compatibility with ASDF1. ;; We ought to be able to extract this from the component alone with COMPONENT-TYPE. That's out of date, right? Should refer to extract this from FILE-COMPONENTs along with FILE-TYPE, correct? 2. Why is FILE-TYPE an ACCESSOR instead of a READER? Should anyone be setting this, except as an INITARG? 3. What is the return type of SOURCE-FILE-TYPE, and in particular why does it not return an error when applied to a PARENT-COMPONENT? I think it's because it's not being used only as a FILE type, but is being used as a TYPE argument for ASDF's pathname functions, which have a more expansive notion of :type. I suppose maybe this means that SOURCE-FILE-type is a misnomer, and that's one of the reasons it should die. I'm working my way through the ASDF manual, end-to-end. I will probably commit a marked up PDF to the repo pretty soon, so anyone who is interested can see where I'm going. Thanks, r

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel