asdf-devel

asdf-devel@common-lisp.net

1376 discussions

[asdf-devel] Bug in directory-files
by Pascal Costanza 02 Nov '11

02 Nov '11

Hi, There is a problem in the function directory-files (at least for LispWorks). Currently it is defined like this: (defun* directory-files (directory &optional (pattern *wild-file*)) (when (wild-pathname-p directory) (error "Invalid wild in ~S" directory)) (unless (member (pathname-directory pattern) '(() (:relative)) :test 'equal) (error "Invalid file pattern ~S" pattern)) (let ((entries (ignore-errors (directory* (merge-pathnames* pattern directory))))) (filter-logical-directory-results directory entries #'(lambda (f) (make-pathname :defaults directory :version (pathname-version f) :name (pathname-name f) :type (pathname-type f)))))) However, passing (pathname-version f) unchanged makes make-pathname throw errors in most cases in LispWorks. It should rather say something like that: (defun* directory-files (directory &optional (pattern *wild-file*)) (when (wild-pathname-p directory) (error "Invalid wild in ~S" directory)) (unless (member (pathname-directory pattern) '(() (:relative)) :test 'equal) (error "Invalid file pattern ~S" pattern)) (let ((entries (ignore-errors (directory* (merge-pathnames* pattern directory))))) (filter-logical-directory-results directory entries #'(lambda (f) (make-pathname :defaults directory :version (unless (eq (pathname-version f) :unspecific) (pathname-version f)) :name (pathname-name f) :type (pathname-type f)))))) …or something similar. There is also a redundant 'u in the 'and form in filter-logical-directory-results. Best, Pascal -- Pascal Costanza

3 3

[asdf-devel] OS X test results on latest ASDF
by Robert Goldman 23 Oct '11

23 Oct '11

Ran 35 tests: 35 passing and 0 failing all tests apparently successful Using alisp -q -batch Ran 35 tests: 35 passing and 0 failing all tests apparently successful Using mlisp -q -batch Ran 35 tests: 35 passing and 0 failing all tests apparently successful Using /Users/rpg/ccl/dx86cl64 --no-init --quiet --batch Ran 35 tests: 35 passing and 0 failing all tests apparently successful Using clisp -norc -ansi -I -on-error exit Ran 35 tests: 35 passing and 0 failing all tests apparently successful Using ecl -norc -load sys:cmp Ran 35 tests: 34 passing and 1 failing failing test(s): run-shell-command-test.script Using sbcl --noinform --userinit /dev/null --sysinit /dev/null --disable-debugger Ran 35 tests: 35 passing and 0 failing all tests apparently successful I.e., only ECL is failing any of the scripts. That's actually more a bug with my test --- ECL will never be able to capture STDERR. Attached is a proposed test modification. r P.S. I have a dead-simple perl script that cycles through a configurable set of lisp impementations, running all the tests. If I can get it tidied, I will make it publicly available.

3 6

[asdf-devel] run-shell-command
by Robert Goldman 22 Oct '11

22 Oct '11

Question: could we handle this problem with the new asdf contrib idea? Could we distribute an ASDF:RUN-SHELL-COMMAND based in the XCVB code base along with ASDF using a contrib system? I am reluctant to see RUN-SHELL-COMMAND no longer be distributed with ASDF, since it seems to make a hash of our claims that ASDF can manage systems that mix other code with common lisp code. I don't believe that invoking external facilities should rely on additional ASDF system dependencies. But I am sympathetic to the idea that RUN-SHELL-COMMAND is too big to fit in asdf.lisp, if done properly. A second question: can we provide something like autoload for RUN-SHELL-COMMAND, based on ASDF:LOAD-SYSTEM, to minimize dislocation? If we have something like autoload, then people won't have to rejigger their system structures if we deprecate R-S-C away. Indeed, if we give them a better version, then they would just be a step ahead. Finally, if we provide a better R-S-C, how do users differentiate? #+asdf2 is simply too coarse a tool now. #+asdf-run-shell-command ? Cheers, r

2 3

[asdf-devel] Please test ASDF 2.017.22 as release candidate
by Faré 21 Oct '11

21 Oct '11

Dear ASDF users, can you please test ASDF 2.017.22? I'm declaring a feature freeze for ASDF until release, and assuming no bug is found and bugfix committed, the current ASDF will be promoted as 2.018 by the end of the month. The repository is still open for documentation and test updates. On the other hand, for any extensions you might want to publish, (for instance, around hooks for package renamings), I've created a asdf-contrib.git repo, currently empty save for a trival .asd file, next to the asdf.git repo: ssh://common-lisp.net/project/asdf/git/asdf-contrib.git git://common-lisp.net/projects/asdf/asdf-contrib.git Changes since 2.017: * Solved a bug due to ASDF reusing components even when the ASDF definition has changed wildly, leading to bad behavior in incremental compilation and sometimes total failure of compilation of a new version. (Thanks to Xach for reporting and RPGoldman for fixing.) * Bind *default-pathname-defaults* around load-sysdef, to increase chances of successful pathname parsing in defsystem. * Many implementation specific improvements for ECL: merge with the ECL upstream version, support for the bytecode compiler, * Fix an issue with ASDF doing the wrong thing in case of a clock skew, thanks to Andreas Fuchs. * Simplification of the internals of perform-with-restarts and traverse's do-dep, that should fix some corner cases and make it easier to extend or further fix. There scarily doesn't remain any unedited code from Dan Barlow's original ASDF, though much of the interface design is preserved. * Improvements to tests and documentation. * Upgrade code slightly simplified, with a particular fix for CLISP; it is now tested on all supported implementations, not just SBCL. * Fixed run-shell-command on allegro/unix and clisp, documented the function, noted how it mightn't do what you think on Windows, marked it as obsolete, promoted as an official replacement my new xcvb-driver:run-program/process-output-stream * New :around-compile hook so you can control the syntax, optimization, and warning level, rename packages and balance compile-time side-effects, etc., around the compilation of files in your own modules. * Because it is required at least on ABCL, made the Unix vs Windows detection a runtime rather than compile-time distinction No more asdf-unix or asdf-windows feature, but (asdf::os-unix-p) and (asdf::os-windows-p) functions (not exported for now). Also recognize darwin as Unix ECL. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No man would listen to you talk if he didn't know it was his turn next. — Edgar Watson Howe

1 0

[asdf-devel] asdf and windows vs unix on abcl
by Faré 21 Oct '11

21 Oct '11

ABCL is special in that it can run on either Windows or Unix. The problem is that ASDF 2.017 determines which of Windows or Unix at compile-time, which causes confusion when ABCL's builtin ASDF is compiled on Windows and used on Unix or vice-versa. And I can tell your binary was definitely produced on Windows. (I found this issue while testing cl-launch. I also noticed that you fixed your ext:*command-line-argument-list* albeit in a necessarily incompatible way.) I suppose the solution is that the test of unixness vs windowsness should happen at runtime. Crazy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

3 3

[asdf-devel] compile-with-nicknames
by Gábor Balázs 20 Oct '11

20 Oct '11

hY, I would like to propose a kind of an enhancement to the ASDF functionalities. So there is a problem with package nicknames that they have to be unique. So using the :nicknames option in a package definition can cause "uncorrectable" collisions. On the other hand, by not doing so, one has to use fully qualified package names (eg. :com.gigamonkeys.macro-utilities) during library development which makes the code completely unreadable (in my opinion at least). So there would be a possibility in asdf to at least partially handle this problem. It would be nice to define temporary nicknames for the compilation time. At the moment, it is possible by the :perform asdf option. So one can place and remove the nicknames by :perform (compile-op :before ...) and :perform (compile-op :after) options. Often it would be desirable, to do so for every asdf compilation unit, but there is no easy way to do so yet. Note: one has to define the nickname operators for every compilation unit in which it is used, otherwise the exclusive recompilation of this unit will produce an error (which would make development difficult). The other problem with this approach is when a compilation fails, the nicknames won't be cleared. However it is not a big problem for a development process, and otherwise it should not happen. Defining the :perform options for each asdf unit, is pretty ugly. So it is nice to have a script at least which walks over all compilation units and sets the perform options. But there would be a nicer way, and this is the proposal. What about a new asdf option (eg :compile-with-nicknames), which could look like something this? (defsystem my-system :depends-on ("package-1" "package-2" "package-3" ...) :compile-with-nicknames (("package-1" "pckg-1") ("package-3" "pckg-3")) :components (...)) I think this approach nicely works in a "clear" environment for non-parallel compilation when there are no insane nickname requests. The "clear" environment assumption can be relaxed to say that the user hasn't defined any nicknames which causes collisions for any necessary compilations. Or if you know a better way to handle this problem, I would be happy to hear about that... Thanks, `bg`

4 26

Re: [asdf-devel] compile-with-nicknames (a possible compromise?)
by Juan Jose Garcia-Ripoll 18 Oct '11

18 Oct '11

2011/10/17 Gábor Balázs <gabalz(a)gmail.com> > > Hm, I like the idea of having multiple classes for cl-source-file objects. > But I wouldn't do it through CLOS. I tend to agree on this, for CLOS is not declarative. It would become very hard to automatically deciphering defsystem files, and what they do. I also believe that the wrap-around functionality does not have to be that general. In particular this is specifically required only for _compiling_, not for loading. I would not want an :around semantics to exist at all for loading, because that would completely eliminate any possible and future goal of making ASDF ship pre-compiled libraries. Out of the tasks listed here: locally renaming packages binding *readtables* and other syntax-controlling variables handling warnings and other conditions proclaiming optimization settings saving code coverage information maintaining meta-data about compilation timings resetting gensym counters, PRNG seeds, etc., for determinism cheating the source-location and/or timestamping systems checking that some cleanup function was properly called etc. I see nothing that could not exist in :eval-when forms. The problem is thus not that these operations may live in the compiled files, but the fact that we need them to be executed every time the files in the system are compiled. In a sense, it is a _reversed_ dependency. Normally we have that file2 depends on file1 and thus file2 is loaded _after_ file1 is loaded. Couldn't we just add another component to defsystem which is loaded when _any_ file is to be changed? It would be like a prerequisite module or file. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

3 3

[asdf-devel] ASDF system def inspectors
by Gary King 17 Oct '11

17 Oct '11

Hi all, Are there any tools extant that provide a good summary of all of the inter-relations between systems. I use the attached to make a DOT file but wonder if there are others. thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

2 1

Re: [asdf-devel] Fount inconsistency in RUN-SHELL-COMMAND...
by Faré 13 Oct '11

13 Oct '11

> Question: in order to make this consistent, can I take away the call to > ASDF-MESSAGE and just push the output through without prefixing? > Yes. Though again, consistent would be dropping this pretense of respecting *verbose-out* when most implementations don't and can't; at least not without a serious rewrite. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The Military *did* invent computers: computers sprung forth fully armed from a noncom's aching forehead between two barkings of orders at recruits.

1 0

[asdf-devel] Dependency does not trigger recompilation
by Juan Jose Garcia-Ripoll 12 Oct '11

12 Oct '11

I apologize in advance for the stupid newbie question that follows. I have the two systems below. When I change a file in cl-farm, it recompiles it, but when I demand loading of cl-farm-test again, ASDF does not recompile it, even though its dependency has changed. Why? Is this expected. This all is based on the latest ASDF from git, invoked from Slime (but I do not think this makes a difference) Juanjo (defsystem :cl-farm :serial t :components ((:file "package") (:file "machines"))) (defsystem :cl-farm-test :depends-on (:rt :cl-farm) :serial t :components ((:file "tests/package") (:file "tests/files") (:file "tests/run"))) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel