asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

Re: [asdf-devel] Pathname failures on ASDF 2.017.4 on SCL 1.3.9
by Faré 14 Sep '11

14 Sep '11

Dear ASDF developers, there were test failures recently in SCL, and Douglas Crosher found that they were related to the semantics of merge-pathnames*. I'm not sure anymore what merge-pathnames does, how its current behavior differs from SCL's ext:resolve-pathname, and more importantly, what it should be doing, so I'm thinking aloud and maybe one of you will catch something. >>>: Douglas Crosher >>: Fare >: Douglas Crosher >>> The SCL requires slightly different code in merge-pathnames* >>> which seems to have been causing the issue. >>> >>> The issue occurs because pathnames in the test do not have a host etc >>> so are resolved relative to a logical-pathname host: >>> >>> (merge-pathnames* "/home/mod1/file.lisp" #p"ASDFTEST:SRC;") >>> => #p"ASDFTEST:HOME;MOD1;FILE.LISP.NEWEST" >>> >>> Adding the host etc gives the following and corrects the issue: >>> >>> (merge-pathnames* "file://localhost/home/mod1/file.lisp" >>> #p"ASDFTEST:SRC;") >>> => #p"file://localhost/home/mod1/file.lisp" >>> >>> I can't see any reason why a pathname with an absolute directory >>> should be handled specially in merge-pathnames* and the following >>> example seems right for the SCL: >>> >>> (merge-pathnames* "/home/mod1/file.lisp" #p"http://host/") >>> => #p"http://host/home/mod1/file.lisp" >>> >> The reason why merge-pathnames* does this is because >> we want to treat the merging of relative pathnames specially: >> based on defsystem specifications, we have pathnames that are relative >> to wherever the .asd file is; however, at the time the user specifies >> those relative pathnames, and as he does some merging operations on them, >> he has no idea what kind of implementation will be present and what >> host (logical or physical), device, etc., will be used for the pathname. >> Therefore, I needed this abstraction (and accompanying syntax) for >> "pathnames wherein a relative pathname does not specify host or device, >> but an absolute pathname does". >> >> I suppose there's a slight mismatch with scl's ext:resolve-pathname. >> Instead of your first patch, >> maybe merge-pathnames* shouldn't just call that latter function, >> but do some more wrapping around it? > > The SCL's ext:resolve-pathname seems to handle the relative paths just fine, > and works with URLs. > > The problem occurred when the system definition specified a path with an > absolute directory and no host or device. > The SCL's ext:resolve-pathname will resolve such a path relative to the base > host etc which I think is useful. > > Consider a standard CL example of a system definition with a base pathname > which is a logical pathname. In this case it would be reasonable to have a > component pathname with an absolute directory and no host be resolved > relative to the base logical pathname - which is what the SCL's > ext:resolve-pathname will do. The current behaviour of merge-pathname* is > to simply ignore the default host and device for a pathname with an absolute > directory which does not seem useful. Perhaps you could consider modifying > merge-pathname* to merge the host and device for pathname with an absolute > directory rather than ignoring the defaults in this case. > > This issue is hard to describe, but I may be able to come up with a new test > for it. > OK. I think I get it. The issue is that at least *some* CL implementations (for instance clisp) use a NIL pathname-host for normal Unix absolute pathnames. In that case, the host being NIL doesn't mean "host unspecified", but "normal absolute pathname", and it is wrong to replace it with a say logical host from the defaults. Maybe the "right thing" then is to identify, in each implementation, what is the canonical way of representing the possible "absolute pathname referring to some default toplevel filesystem" as opposed to possibly "absolute pathname depending on unspecified host", and keep a NIL in the first case (where that applies) but not the other case. Then, the asdf-pathname-test would have to be updated to do the right thing with those two cases (whichever applies). It seems that your ext:resolve-pathnames might already be doing this "right thing" — except maybe when a relative pathname is specified with a host? NB: to maximize the chances of pathnames being created with the correct host and device, maybe load-sysdef should bind *default-pathname-defaults* to (pathname-directory-pathname pathname) around load? Oh noes, more portability issues with CL pathnames! At that point, I'll just weep. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

1 0

[asdf-devel] ECL tests on the Mac
by Robert Goldman 14 Sep '11

14 Sep '11

I just installed ECL from MacPorts, and when I run the test suite I get a failure. Using ecl -norc Ran 35 tests: 34 passing and 1 failing failing test(s): test-configuration.script Should I expect this? best, r

3 10

Re: [asdf-devel] Unexpected behavior when loading different versions of a system
by Daniel Herring 07 Sep '11

07 Sep '11

On Tue, 6 Sep 2011, Robert P. Goldman wrote: > P.S. I'd be interested in feedback about the use I made of git here. I > *could* have squashed the series of commits that ended up with the patch > you see here, but in the end, I decided that it might be helpful for > people to see in the history the blind alley that I pursued, because it > seemed like a simpler fix to begin with. db16d0..8f5e2d I frequently like my history to show stuff like this. Some people prefer a clean, "always works" history. One approach is to treat the development work as a branch and merge it back into master with the summary message you would use in the squash. I think this caters to both styles. - Daniel

1 0

[asdf-devel] Does anyone still moderate asdf-devel?
by Robert Goldman 06 Sep '11

06 Sep '11

I have multiple email addresses and am increasingly getting bounces as a result. I'd like to fix this, but don't have the foggiest idea how to do so. If a moderator sees this email, please contact me off-list. best, r

1 0

[asdf-devel] Pushed proposed fix for Xach's bug
by Robert Goldman 06 Sep '11

06 Sep '11

Passes all of the unit tests (including the new one based on Xach's test case). Please, all of you, have a peek at the diffs (possibly I should have squashed the changeset to make this easier, sorry), and the commit message, and test it as soon as possible. I have not bumped the version number, as this is still a work in progress subject to review. best, r

2 4

Re: [asdf-devel] Unexpected behavior when loading different versions of a system
by Daniel Herring 03 Sep '11

03 Sep '11

On Fri, 2 Sep 2011, Robert P. Goldman wrote: > I can see that I didn't explain this as well as I might. It is too late for me to try again now, but I will have a whack sometime over the long weekend. The short answer is that Xach's test case actually revealed that the reuse of old component objects could leave ASDF in a very bad state (modified components with some old attributes, components that were obsolete retained, etc.). Don't do the write-up just for me. It looks like you have good reasons for this change, and that other solutions would be unnecessarily complex. Thanks, Daniel

1 0

[asdf-devel] Unexpected behavior when loading different versions of a system
by Zach Beane 03 Sep '11

03 Sep '11

Say I download version 1 of the FOO library and put it in /tmp/foo-1/, so it looks like this: /tmp/foo-1/foo.asd /tmp/foo-1/a.lisp foo.asd has this: (asdf:defsystem #:foo :serial t :components ((:file "a"))) Then I add the path to the central registry and load it: (push #p"/tmp/foo-1/" asdf:*central-registry*) (asdf:load-system "foo") Everything loads fine. Oops, I need to upgrade, I better get version 2 and put it in /tmp/foo-2/, which looks like this: /tmp/foo-2/foo.asd /tmp/foo-2/a.lisp /tmp/foo-2/b.lisp foo.asd looks like this: (asdf:defsystem #:foo :serial t :components ((:file "a") (:file "b"))) Then I add the path to central registry: (push #p"/tmp/foo-2/" asdf:*central-registry*) It seems to find the new system: (asdf:system-source-directory "foo") => #p"/tmp/foo-2/" However, when I try this: (asdf:load-system "foo") I end up with this error, which I don't really understand: failed to find the TRUENAME of /tmp/foo-1/b.lisp: No such file or directory Why does that happen? What's the best way to work around it? I'm using ASDF 2.017 and a very recent SBCL from git. You can reproduce my scenario by unpacking http://xach.com/tmp/foofail.tgz and loading "foofail.lisp". Thanks, Zach

5 7

[asdf-devel] Testing before release 2.017 ?
by Faré 26 Jul '11

26 Jul '11

There hasn't been much change since last month's flamewar. I'd like to release ASDF 2.017 next weekend. Can testers test 2.016.3 as release candidate? Thanks! It passes all my tests, of course, but experience shows they are far from sufficient to guarantee workingness in the field. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

2 4

Re: [asdf-devel] Small ASDF extension to show dependency DAG
by Faré 09 Jul '11

09 Jul '11

On 9 July 2011 15:48, Scott L. Burson <Scott(a)ergy.com> wrote: > Hi Faré! > > Here's a little hack I just wrote because I wanted to see the > dependency DAG for a system I'm working on: > > (in-package :asdf) > > (defun* show-dependencies (system-name &key descriptions?) > (let ((seen (make-hash-table :test #'equal))) > (labels ((rec (system-name depth) > (let ((nm (if (and (listp system-name) (eq (car system-name) ':version)) > (coerce-name (cadr system-name)) > (coerce-name system-name)))) > (if (gethash nm seen) > (format t "~v@T[~A]~%" (* depth 2) nm) > (progn > (let ((sys (cdr (gethash nm *defined-systems*)))) > (if (null sys) > (format t "~v@T~A??~%" (* depth 2) nm) > (progn > (format t "~v@T~A~@[: ~A~]~%" (* depth 2) nm > (and descriptions? > (slot-boundp sys 'description) > (slot-value sys 'description))) > (setf (gethash nm seen) t) > (dolist (dep (component-load-dependencies sys)) > (rec dep (1+ depth))))))))))) > (rec system-name 0)))) > > I thought you might want to include this in asdf.lisp. Sample output > is below. When a name is in brackets, that means the system and its > dependencies have already appeared earlier in the listing. > (Adding asdf-devel as destination.) It is cool. I think it deserves to be published. But I don't think the already way too big asdf.lisp is the right place. Our goal is to keep asdf.lisp itself minimal, and move anything not strictly needed for system bootstrap into extensions. At the same time, we don't yet have an "official" repository for such extensions. Maybe it's time to start one. Any taker? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > -- Scott > > osb > clsql > clsql-postgresql > [clsql] > clsql-uffi > [clsql] > uffi > clsql-postgresql-socket > [clsql] > md5 > [uffi] > sb-bsd-sockets > sb-grovel > weblocks > closer-mop > hunchentoot > chunga > trivial-gray-streams > cl-base64 > cl-fad > sb-posix > [sb-grovel] > cl-ppcre > flexi-streams > [trivial-gray-streams] > cl+ssl > cffi > alexandria > trivial-features > babel > [trivial-features] > [alexandria] > [trivial-gray-streams] > [flexi-streams] > [sb-posix] > [md5] > rfc2388 > trivial-backtrace > usocket > [sb-bsd-sockets] > bordeaux-threads > [alexandria] > puri > cl-json > cl-who > parenscript > [cl-ppcre] > anaphora > [cl-fad] > fare-matcher > fare-utils > cl-cont > [closer-mop] > [alexandria] > metatilities > metatilities-base > moptilities > [closer-mop] > cl-containers > [metatilities-base] > metabang-bind > asdf-system-connections > [cl-ppcre] > [md5] > [anaphora] > f-underscore > [bordeaux-threads] > salza2 > html-template > trivial-timeout > [trivial-backtrace] > weblocks-clsql > [closer-mop] > [metatilities] > [clsql] > [weblocks] > cl-oauth > ironclad > sb-rotate-byte > [cl-base64] > [babel] > [closer-mop] > [alexandria] > [anaphora] > [f-underscore] > split-sequence > trivial-garbage > fiveam > arnesi > drakma > [puri] > [cl-base64] > [chunga] > [flexi-streams] > [usocket] > [cl+ssl] > [puri] > [hunchentoot] > [cl-ppcre] > cl-smtp > [usocket] > [trivial-gray-streams] > [flexi-streams] > [cl-base64] > [cl+ssl] > monkeylib-bcrypt > [cffi] > fset > gmap >

1 0

[asdf-devel] Package definition for each file in :components?
by Matus Kmit 27 Jun '11

27 Jun '11

Hi i have some basic question: Let's say, i have defined a system where with four files: system.asd, packages.lisp, file1.lisp, file2.lisp, where file1 and file2 share the same package and are split more or less only for better organisation purpose. So in packages.lisp i define only one package and use the respective in-package expression for it in the beginning of the two files. Besides that file1 should be loaded before file2. In my asd file i have something like this: (defsystem "system" :depends-on ("ext-system") :serial t :components ((:file "packages") (:file "file1") (:file "file2"))) Trying to load this system with (ql:quickload "system") i get an error, that there is no package for file1. i discovered that when i define a package for file1, although never use it, things work as i want. Does one have to define a package for each file listed in :components? Is there some other, more suitable way to fulfil my purpose (use the same package in both files? Thanks for any help Matus

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel