asdf-devel

asdf-devel@common-lisp.net

1 participants
1378 discussions

[asdf-devel] TEST-OP made useful by declarative options
by Juan Jose Garcia-Ripoll 18 Apr '10

18 Apr '10

The attached patch adds a new option to DEFSYSTEM. This option is :TESTS test-list test-list = (:system system-name) | function-name system-name = keyword | string function-name = symbol | string The function name is a string designator that denotes a function with no arguments to be called. This string will be read using the standard I/O syntax only when the test is executed. This ensures that the mechanism works once the appropriate dependencies are loaded. The system name denotes a system that will be loaded when the TEST-OP operation is invoked. The patch can be improved with some tests done when executing DEFSYTEM instead of what it does now, which is to signal an error once the test is performed. The usual example follows. foo.asd: (defsystem :foo :tests ((:system "faa")) :components ((:file "foo"))) faa.asd: (defsystem :faa :tests ("faa::run-tests") :components ((:file "faa"))) foo.lisp: (defpackage "FOO") (in-package "FOO") (defun my-cos (a) (cos a)) faa.lisp: (defpackage "FAA") (in-package "FAA") (defun run-tests () (format t "~&;;;~%;;; MY-COS signals errors: ~A~%;;;" (handler-case (progn (foo::my-cos 'a) 'no) (error (c) 'yes)))) -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

2 6

[asdf-devel] Simplification of load operations
by Juan Jose Garcia-Ripoll 17 Apr '10

17 Apr '10

Right now we have a situation in which load-source-op is a second class citizen, rarely used, and for which nobody provides explicit dependencies. More precisely * Some compilers out there are just efficient compiling and loading source files. The operation is the same. * LOAD-OP can be viewed as a slightly more efficient version of an operation that loads sources. * Some users out there do not like compile-before-load procedure. * ASDF makes no promise that load-source-op will behave similarly as load-op. * Users define methods for load-op and not for load-source-op. * In practice the dependencies *must* be the same, for the philosophy of CL is that compiled and not compiled files behave similarly. * The only differences should be enforced to lay just in the compilation process. I attach a patch which merges both operations, leaving a trace of compatibility. * There is only one class, LOAD-OP. * The class has the promise that it will use the same dependencies when loading sources and binaries. * When imposing that one does compile the source before, the class issues an additional dependency on a compile-op, which may pull additional dependencies itself. * A global flag, *compile-before-loading* determines the overall behavior * A new function ASDF:LOAD-SOURCE-SYSTEM forces no compilation * The function LOAD-SYSTEM gets a flag, :compile that sets *compile-before-loading* * With these changes it is easy to get a sorted list of the components that make up a program. Furthermore, this list is guaranteed to work because we are using the same operation that we will use to load the files. (pprint (loop with asdf::*compile-before-loading* = nil for (op . component) in (asdf::traverse (make-instance 'load-op) (find-system "chunga")) collect (list (type-of op) (type-of component) (asdf::component-name component)))) * With this mechanism I can reimplement the fasl concatenation mechanism *without* using classes at all. Same goes for ECL's extensions. The patch is still not fully tested, but I submit it for discussion, so that ugly corners can be polished. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

1 1

[asdf-devel] :in-order-to
by Juan Jose Garcia-Ripoll 16 Apr '10

16 Apr '10

Who uses it? Out of 291 packages, the only uses seem to be - Defining TEST-OP operations (greate majority) - In a few tests, it solves a wrong ordering of files - In two, it deactivates operations by using FEATURE (obscure way to do it) The "paradigmatic" example of McClim cited here http://common-lisp.net/project/asdf/asdf.html#Common-attributes-of-componen… does not have a single occurrence of this word. The question is thus, is it really needed? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

3 7

[asdf-devel] ASDF 1.700
by Faré 16 Apr '10

16 Apr '10

I did a big rewrite of TRAVERSE and a bunch of other fixes. Can you try out ASDF 1.700 ? Note that this breaks POIU. I don't understand what POIU does to TRAVERSE and PARSE-COMPONENT-FORM. I will have to fix it since the reason why I'm interested in fixing TRAVERSE is to be able to use POIU to speed things up instead of having it waste 2 minutes just for TRAVERSE... [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Thinking is the hardest work there is, which is probably the reason why so few engage in it. — Henry Ford

2 3

[asdf-devel] Added a new test
by Robert Goldman 15 Apr '10

15 Apr '10

I originally thought that ASDF might not notice if a source file was lost, as long as a fasl was left around. In fact, it /does/ notice, which is what I had hoped. I just added a test to verify this, just in case. Please try and run this when you get a chance, just to make sure it's truly portable. I'm particularly curious about whether it will work on Windows. thanks, r

1 0

[asdf-devel] (Somewhat urgent) ASDF manual link broken
by Juan Jose Garcia-Ripoll 15 Apr '10

15 Apr '10

The link in Google for the ASDF manual points to http://common-lisp.net/project/asdf/manual.html This is so because I convinced the person with the highest page rank in that query to place a link to this page. However the previous link has been arbitrarily changed to become http://common-lisp.net/project/asdf/asdf.html In order to preserve the ranking I advise to set up .htaccess to redirect to the new location. Either that or simply place a soft link in the server. I would do it myself but my account in common-lisp.net (jgarcia) does not have the right permissions. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com

2 3

[asdf-devel] ASDF2 committed to ABCL trunk
by Mark Evenson 15 Apr '10

15 Apr '10

We [committed ASDF 1.679 to the ABCL trunk today][1], so barring some real problems that show up in testing, ASDF2 will be the stock version in ABCL with 0.20 due at the end of this month. Thanks for all the help! [1]: http://trac.common-lisp.net/armedbear/changeset/12618 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[asdf-devel] Hoist by my own petard: problem with asdf-binary-locations compatibility.
by Robert Goldman 15 Apr '10

15 Apr '10

One of my own systems got blown up by ASDF-OUTPUT-TRANSLATIONS recently, and the case may be an interesting one: I am working on a system that involves taking an ontology from the Protege tool, and interpreting it as CL. So we have a special component type which is "pont" (from Protege ontology). A pont file is /almost/ readable CL, but not quite. So before we can do the compile-op on the pont file, we first do a pont-to-lisp operation on it, which involves calling a perl script to generate a lisp file from the pont file. So..... We have a pont-file which ISA cl-source-file. But there is no .lisp file to begin with. Instead, we have the following chain of operations: pont-file ==== pont-to-lisp ====> lisp file ==== compile-op ====> fasl This works fine in ASDF Classic, even with asdf-binary-locations, because asdf-binary-locations ONLY rewrites the output-files of COMPILE-OP. So, the output of the pont-to-lisp file, the lisp file, gets written into the source directory where the compile-op can find it. Unfortunately, this is not what happens with ASDF-OUTPUT-LOCATIONS, because A-O-L translates /all/ output-files, not just those of compile-op. This means that our lisp file gets dropped somewhere into /var/cache/common-lisp-controller/501/.... [Is this a misconfiguration of A-O-L, btw? My colleague is compiling this code as an ordinary user. I guess I'm surprised that the default is to drop stuff into /var instead of into a userdir. Seems like this is going to create a lot of dark matter in the filesystem, since one will have to look pretty hard to clean up zombie fasls... I would have thought something in the user's homedir would be more likely as a default...] I'm afraid this suggests that we should tweak the asdf-binary-locations compatibility code yet again. I will see if I can suggest a patch. BTW, I discovered this because some ubuntu version seems to be shipping with common-lisp-controller with an ASDF 2 from git's womb untimely ripp'd... So Ubuntu people are unwittingly getting their SBCL served to them with ASDF2 rolled into it. Slightly alarming. Best, r

3 5

[asdf-devel] 1.675 bug
by szergling 15 Apr '10

15 Apr '10

Hi list, I'm having trouble hot-upgrading asdf. My old setup was not checked out of a repository, but does have a file modified date of 2007-06-18. I also use asdf-binary-locations version "0.3.8". To begin with, I have created the following config file (~ is at c:/home) ~/.config/common-lisp/source-registry.conf (:source-registry (:directory "e:/src/ltk-0.90/") (:tree "c:/home/code/lisp/libs/") (:exclude "_darcs") :ignore-inherited-configuration) I then load-file asdf.lisp from Slime. My clisp-2.47 (non-cygwin Windows) is previously already running with asdf, asdf-binary-locations, and many systems loaded (and other random work done). I then tried to load a system that I could previously load just fine, in this case ironclad_0.27. CL-USER> (asdf:load-system :ironclad) ; loading system definition from C:\home\code\lisp\libs\ironclad_0.27\ironclad.asd into #<PACKAGE ASDF0> ;; Loading file C:\home\code\lisp\libs\ironclad_0.27\ironclad.asd ... ; registering #<SYSTEM :IRONCLAD #x26F7286D> as IRONCLAD ; registering #<SYSTEM IRONCLAD-TESTS #x26FE5225> as IRONCLAD-TESTS ;; Loaded file C:\home\code\lisp\libs\ironclad_0.27\ironclad.asd ; No value This gave the following error. TRANSLATE-PATHNAME: replacement pieces (NIL NIL (:DIRECTORY #1="home" #2="code" #3="lisp" #4="libs" #5="ironclad_0.27") "package" "fas" :NEWEST) do not fit into #P"C:\\Documents and Settings\\chewyong\\Local Settings\\Temporary Internet Files\\common-lisp\\**\\*.*" [Condition of type SIMPLE-ERROR] I browsed around in the stack trace (yes clisp stack traces are ugly), and looked deeper into this particular frame: ... 17: <1/1718> #<SYSTEM-FUNCTION TRANSLATE-PATHNAME> [1712] EVAL frame for form (TRANSLATE-PATHNAME (ASDF::DIRECTORIZE-PATHNAME-HOST-DEVICE ASDF::P) ASDF::ABSOLUTE-SOURCE ASDF::DESTINATION) Locals: ASDF::ABSOLUTE-SOURCE = #P"\\**\\*.*" ASDF::ROOT = #P"\\" ASDF::DESTINATION = #P"C:\\Documents and Settings\\chewyong\\Local Settings\\Temporary Internet.. ASDF::SOURCE = T #:LIST-13280 = ((T ..)) ASDF::P = #P"\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas" #:PATTERN-13281 = (T ..) #:TYPECASE-KEY-13279 = #P"C:\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas" #:TYPECASE-KEY-13278 = #P"C:\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas" ASDF::PATH = #P"C:\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas" ... In particular, I'm guessing that this is related to truenamize (has it taken the wrong branch?) with respect to (line 677 on my version of asdf.lisp) (ignore-errors (return (truename p))) Am I close enough? See the following: CL-USER> (truename (merge-pathnames #P"\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas")) ==> TRUENAME: File #1=#P"C:\\home\\code\\lisp\\libs\\ironclad_0.27\\package.fas" does not exist [Condition of type SYSTEM::SIMPLE-FILE-ERROR] My package.fas, due to asdf-binary-locations, has been stored previously in ~/code/lisp/libs/ironclad_0.27/clisp-2.47-win32-i386/package.fas I hope this is useful for fixing asdf + a-b-l hot upgrade. I can restart a new Lisp and give full backtraces or other further info, should that be necessary. Cheers.

2 2

[asdf-devel] TRAVERSE being very slow
by Faré 15 Apr '10

15 Apr '10

On a large flat system (automatically generated by XCVB from QRes), TRAVERSE takes a whole lot of time. More like O(n^2) or O(n^3) than either O(n) or O(n log n). I suspect suboptimal algorithms are used somewhere, either in component lookup or in topological sorting. Sigh. The amount of memory consed suggests it's not just lookup time, but hugely inefficient intermediate data structures. (time (length (asdf::traverse (make-instance 'asdf:load-op) (asdf:find-system :qres-ccl-xne))) ==> took 140,642,274 microseconds (140.642270 seconds) to run with 8 available CPU cores. During that period, 140,484,780 microseconds (140.484790 seconds) were spent in user mode 148,010 microseconds (0.148010 seconds) were spent in system mode 996,129 microseconds (0.996129 seconds) was spent in GC. 8,182,948,112 bytes of memory allocated. 2748 [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Economic illiteracy often leads one to take for wealth creation or cost reduction what is only a forced displacement of activity, with no primary gain, and a lot of secondary costs and negative side-effects. — Faré

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