asdf-devel October 2009

asdf-devel@common-lisp.net

14 participants
22 discussions

[asdf-devel] Two questions
by Nick Levine 17 Nov '09

17 Nov '09

1. Problems with the :feature feature. (asdf:defsystem foo :components ((:file "pkg") (:file "code") (:file "foo" :depends-on ((:feature :frob))))) If :frob is not on *features*, load-system gives me: Error: Bad dependency (FEATURE FROB). Dependencies must be (:version <version>), (:feature <feature>), or a name If :frob is a *feature* I get a different error: Error: Error component :FROB not found, required by #<CL-SOURCE-FILE "foo" #x8B7A3E6> Did I misunderstand something? 2. Suppose I would like some code to run at compile-time / load-time to determine where the fasls should live (e.g. hypothetically, in a subdirectory named after a timestamp, or according to what patches I have loaded). How do I express this? (I'm using version 1.363) Thanks. - nick

8 16

[asdf-devel] recursiveness of :FORCE
by Tobias C. Rittweiler 09 Nov '09

09 Nov '09

When I use :FORCE, in most cases I do want to recompile solely the specified system, not all its dependencies. In my ideal world, :FORCE T would recompile the specified system only, and :FORCE :ALL would recompile it along its dependencies. Of course that would be backwards-incompatible, so perhaps better stick with the current behaviour for :FORCE T, but add :FORCE :SYSTEM, or :FORCE :SHALLOW, or similiar. -T.

2 5

Re: [asdf-devel] ASDF test-op question
by Juan Jose Garcia-Ripoll 09 Nov '09

09 Nov '09

Hi Robert, I hope you do not mind I CC this email to the list, because I think you made pretty good points and I think I also have some valid answers to them. 2009/10/19 Robert Goldman <rpgoldman(a)sift.info>: > Yes, that's right. You /do/ need to run through all of ASDF's code. I > have been going through that code. I am trying to tell the list what I > found there. And I thank you for that. I probably never got as far as understanding TRAVERSE and the way it works and this is one of the reasons why I feel my design of the ASDF-ECL extensions might be very fragile. > ASDF invokes TRAVERSE to make a /plan/ for performing an operation. A > plan is an ordered list of operation . component pairs. After traverse > returns this plan, OPERATE loops over the ordered list, calling PERFORM > on each pair. Understood. However note one thing: these are ASDF internals. They are not "exposed" to the users and not fixed by the manual. ASDF might work equally well if one changes the way OPERATE uses the output of TRAVERSE, or if we fix an order for TRAVERSE, or if we dispense the plan-and-then-execute setup. > This means that the return values of PERFORM are /discarded/. Not necesseraly. > It also means that it's not obvious to find which are the component > operations that are done for some operation X. That is, if you do (OP1 > . A) (OP2 . B) and (OP3 . C) in order to do (OP . X) all you know is > that the first three will appear /somewhere/ before (OP . X) in the plan > --- you have no stronger guarantee about where they are. In particular, > there is no top-level function call to do OP X that will be on the stack > when the three subsidiary operations are done. Understood as well. However, this also does not prevent ASDF from exposing a history of what it has done so far and let later operations use that. I attach a simple extension to ASDF's OPERATE that creates a log. The log is a list of objects, each one containing the operation that was performed, whether it failed, and the output of PERFORM. With that log it is easy to build a TEST function that parses only the log entries related to tests. * (multiple-value-setq (op log) (asdf:operate 'asdf:load-op 'cl-unicode)) [...] ;;; Computing Hangul syllable names #<ASDF:LOAD-OP NIL {12229E41}> * (mapc #'asdf::print-log-entry log) ;;; Log entry: ;;; #<LOAD-OP NIL {12229E41}> on #<SYSTEM "cl-unicode" {11A88DF9}> ;;; No return values [...] * (describe (first log)) #<ASDF:LOG-ENTRY {12E80A69}> is an instance of class #<STANDARD-CLASS ASDF:LOG-ENTRY>. The following slots have :INSTANCE allocation: COMPONENT #<ASDF:SYSTEM "cl-unicode" {11A88DF9}> OPERATION #<ASDF:LOAD-OP NIL {12229E41}> FAILED-P NIL RETURN-VALUES NIL Could we agree that this is a valid starting point? It is really compatible with previous uses of ASDF and it only asks one thing: PERFORM, applied on TEST-OP should return two values, success-p and a list of objects containing the tests, so that we can analyze the log. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 2

[asdf-devel] DOC-OP
by Tobias C. Rittweiler 09 Nov '09

09 Nov '09

I think GwKing uses automatically generated documentation for his libraries. Gary, do you use some hook into ASDF for that? In my experience, you always have to toggle a few switches for each project (name, version number, download url, etc), and I'd like to have a general interface that hides the details, say (ASDF:OOS 'ASDF:DOC-OP :TARGET-DIR #P"...") -T.

1 1

Re: [asdf-devel] loading a standalone lisp file
by Faré 29 Oct '09

29 Oct '09

2009/10/28 Robert Goldman <rpgoldman(a)sift.info>: > Faré wrote: >> 2009/10/28 Gary King <gwking(a)metabang.com>: >>>> Speaking of optimization settings, does anyone see any problem with >>>> putting in ASDF something that deterministically (re)sets the >>>> optimization setting before each and any perform operation? Otherwise, >>>> optimization settings will vary wildly depending on what >>>> implementation you use, which files get recompiled, etc. >>> I think we should do this; it's on my list. >>> >> Here's a skeleton of implementation (don't forget a defgeneric). >> >> (defmethod perform :before (operation component) >> (proclaim-optimization-settings-for operation component)) >> >> (defmethod proclaim-optimization-settings-for (op component) >> (declare (ignorable op component)) >> (proclaim `(optimize ,@*default-optimization-settings*))) >> >> Unrelatedly, a slight refactoring patch is attached. It would makes it >> easier for ADG and other ASDF add-ons to reuse in a future-proof way >> the ASDF pathname merging algorithm. > > Do we need a :after method to restore the old settings? I'm not sure > how to do that actually, since I don't believe there's a portable way to > record them. Do you have thoughts about this? > (rpg replied to me in private but I'm Cc'ing back the list) At ITA, we actually use a :around method with (defun call-with-local-compilation-settings (thunk) (let #+clozure ((ccl::*nx-speed* ccl::*nx-speed*) (ccl::*nx-space* ccl::*nx-space*) (ccl::*nx-safety* ccl::*nx-safety*) (ccl::*nx-cspeed* ccl::*nx-cspeed*) (ccl::*nx-debug* ccl::*nx-debug*)) #+sbcl ((sb-c::*policy* sb-c::*policy*)) #-(or clozure sbcl) () (funcall thunk))) (defmacro with-local-compilation-settings (() &body body) `(call-with-local-compilation-settings (lambda () ,@body))) [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The American Republic will endure, until politicians realize they can bribe the people with their own money. -- Alexis de Tocqueville (attributed)

3 3

Re: [asdf-devel] how to query root of a system
by Attila Lendvai 29 Oct '09

29 Oct '09

> Is it a contingent fact about this system that we have an absolute pathname > here, o have we somehow ended up with a function named > foo-relative-pathname that returns absolute pathnames? as far as i read it, 'relative' here refers to 'system' in the meaning: give me a pathname that is relative to this system. -- attila

3 3

[asdf-devel] loading a standalone lisp file
by Tamas Papp 28 Oct '09

28 Oct '09

Hi, If I have an ASDF system that :depends-on various other ones _and_ some other library that does not have and .asd file (eg it is a standalone .lisp file), what is the standard way of loading the latter? I am looking for something that eg automates manually executing (load (compile-file "/path/foo.lisp")) and how to incorporate this into a defsystem. Thanks, Tamas

4 4

[asdf-devel] how to query root of a system
by Tamas Papp 28 Oct '09

28 Oct '09

Hi, Suppose I have a library named MYLIBRARY which was installed in the directory /somewhere/foo/ (eg by ASDF-Install, clbuild or manually by the user). It has a /somewhere/foo/mylibrary.asd definition file, which was duly symlinked to mylibrary.asd in ASDF's central registry. The user can load it the usual way using ASDF. Is it possible to query the root directory somehow using the name? Eg I am looking for (query-system-root :mypackage) ; evaluates to #P"/somewhere/foo/" I could not find how to do this in the manual. Thanks, Tamas

4 4

[asdf-devel] tests failing
by Faré 27 Oct '09

27 Oct '09

I ran the tests for asdf. Out of 17, 5 fail on sbcl and 7 on clisp. Oops. On SBCL, the failures seem related to the pathname redirection of ABL / CLC. test1.script test2.script test3.script test-force.script test-static-and-serial.script On CLISP, the two additional failures are test-module-pathnames.script where clisp reads "foo.cl" as having directory nil instead of (:relative), which I think is legal, and test-retry-loading-component-1.script which seems to have to do with a restart-case retry in do-one-dep, but that's beyond my depth. The good news is most of these failures are only failures of the test themselves. The bad news is someone probably has to fix them and commit a fix. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Intentions are not so much direct descriptions of actual mind processes as Schelling points in the way social animals communicate.

2 4

[asdf-devel] announce: ASDF 1.368
by Gary King 27 Oct '09

27 Oct '09

thanks to Robert Goldman for some extension manual mucking! -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel October 2009