- asdf-devel - mailman3.common-lisp.net

MAKE function documentation -- example of use?
by Robert Goldman 31 Jan '16

31 Jan '16

The make function description in the documentation is not described well. It seems to imply that there is a default operation for each system that the system developer can specify somehow, without saying how. I see that there's a FIXME suggesting that we need to document the BUILD-OPERATION option for DEFSYSTEM. It would be nice to have an example that shows how MAKE is intended to be used. Not a super-detailed example, just a quickie to show that this is not a feature in search of a use.... Anyone used this? thanks, r

2 2

newbie setup question
by Thomas Lynch 19 Jan '16

19 Jan '16

New at this, sure could use a pointer. I'm not able to get the code to build consistently. It works only after a failure. So I have to do it twice to get it to go. Sure would like to know what is wrong here. These are the directories: /home/LE/sbcl/LE.asd ;holds the definition, as shown below /home/LE/sbcl/src ;holds the lisp source files for my project The system is Debian, udpated today. quicklisp is installed. These are the commands I type: (require :asdf) (pushnew (truename ".") asdf:*central-registry* :test #'equal) (asdf:load-system :LE) (require :LE) (use-package 'LE) in a fresh environment this fails, and dumps me in the debugger, asdf:load-system tells me: "Component :LE not found: Then I exit the debugger, and run it a second time and it works. Not sure, may need quotes the first time, a colon the second, i.e. it is quirky. I have tried a lot of variations of the above, pretty much every example I've been able to find, some have "LE" instead of :LE everywhere. Here is the value of asdf:*central-registry* after the push: * asdf:*central-registry* (#P"/home/LE/sbcl/" #P"/home/mordecai/quicklisp/quicklisp/") Here is the asdf file that is located in /home/LE/sbcl: (in-package :asdf-user) (defsystem #:LE :name "LE" :version "0.1" :author "Thomas W. Lynch <thomas.lynch(a)reasoningtechnology.com>" :description "Lynch's extensions" :depends-on ("local-time") ;; :serial t :components((:module "src" :components ( (:file "package") (:file "fundamental" :depends-on ("package")) (:file "test" :depends-on ("fundamental")) (:file "string" :depends-on ("test")) (:file "functions" :depends-on ("test")) (:file "list-0" :depends-on ("functions")) ;; (:file "list-L" :depends-on ("list-0")) ))))

4 6

Re: Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Faré 15 Jan '16

15 Jan '16

[This was my reply that bounced yesterday. I edited it.] On 1/14/16 Jan 14 -1:20 PM, Robert Goldman wrote: > What is the intended behavior when this is bound to :IGNORE? > > I believe that if warnings occur, they should be quashed and > COMPILE-FILE should still return T, although otherwise it would not. > Yes, the intent is that in case of :IGNORE, the compilation should just succeed (assuming an output file was returned). > I'm finding a case where :IGNORE is not enough to make the compile-file > succeed, but I'm grappling with trying to find a minimal test case. So > I was wondering if I was interpreting this variable correctly. > Either no .fasl was created, or you found another bug in UIOP. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The uploaded man cut himself from the world. The optimizer saw the simulation would have no more side-effects and optimized it all away.

1 0

Re: Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Robert Goldman 15 Jan '16

15 Jan '16

[... this message also bounced yesterday...] On 1/14/16 Jan 14 -1:20 PM, Robert Goldman wrote: > What is the intended behavior when this is bound to :IGNORE? > > I believe that if warnings occur, they should be quashed and > COMPILE-FILE should still return T, although otherwise it would not. > > I'm finding a case where :IGNORE is not enough to make the compile-file > succeed, but I'm grappling with trying to find a minimal test case. So > I was wondering if I was interpreting this variable correctly. > > thank you > The relevant bit of the manual describes acceptable values for this variable and COMPILE-FILE-FAILURE-BEHAVIOUR, but does not explain their semantics: ASDF checks for warnings and errors when a file is compiled. The variables *COMPILE-FILE-WARNINGS-BEHAVIOUR* and *COMPILE-FILE-FAILURE-BEHAVIOUR* control the handling of any such events. The valid values for these variables are ':error', ':warn', and ':ignore'.

1 0

Intended behavior of *COMPILE-FILE-WARNINGS-BEHAVIOUR*
by Robert Goldman 15 Jan '16

15 Jan '16

[This message bounced yesterday for some reason] What is the intended behavior when this is bound to :IGNORE? I believe that if warnings occur, they should be quashed and COMPILE-FILE should still return T, although otherwise it would not. I'm finding a case where :IGNORE is not enough to make the compile-file succeed, but I'm grappling with trying to find a minimal test case. So I was wondering if I was interpreting this variable correctly. thank you

1 0

Test
by Erik Huelsmann 15 Jan '16

15 Jan '16

Test

1 0

Where is cl-launch.asd?
by Robert Goldman 12 Jan '16

12 Jan '16

I tried to load the asdf tools interactively, under SLIME, and they fail to launch, although everything seems to run from make. I get this error: Component "cl-launch/dispatch" not found, required by #<PACKAGE-INFERRED-SYSTEM "cl-scripting/commands"> and, indeed: ~/lisp/asdf/ext/cl-launch $ find . -name '*.asd' ~/lisp/asdf/ext/cl-launch $ I see this: ~/lisp/asdf/ext/cl-launch $ git status HEAD detached at 220b8ca nothing to commit, working directory clean ~/lisp/asdf/ext/cl-launch $ Is this another oddity of git submodules? Is the version of cl-launch in our git repo not sufficiently up-to-date? Actually, when I look at xcvb/cl-launch, there is no cl-launch.asd there, either. This is crippling my ability to fix 1532464

4 6

Moving towards resignation
by Robert Goldman 12 Jan '16

12 Jan '16

I am now very unhappy with my role as maintainer. Over my repeated expressions of concern, the minimakefile -- which aims to replace normal shell tools with CL-based scripting facilities -- has been merged with core ASDF. Since then, almost all of my ASDF-related time has gone into wrestling with said scripting facilities. I don't mind if people think it's cool to try to make a CL scripting facility. But it's not my thing. I just want my tools to work. The CL scripting facility is, IMO, at an "alpha" level in which it works acceptably in the developer's environment, but can be expected to hiccup seriously anywhere else. I don't want to fight it any more. So I'm offering the community two choices: 1. I "un-merge" the minimakefile facilities and go back to vanilla CL and the standard Unix toolkit for maintenance. 2. Someone emerges to take over the maintenance of ASDF in its current shape, and I go back to being a simple contributor. I barely have enough time to keep up my responsibilities as maintainer; I simply don't have the time to maintain cl-launch, cl-scripting, yadda yadda yadda, as well as ASDF. Even if I did, I wouldn't want to, because this is not a direction that interests me personally. I don't say it's a wrong direction, just that it's not my thing. Fare likes this structure, and he is still the master of ASDF. Me handing off ASDF is more survivable than driving Fare away. So I believe that finding a maintainer who is intrigued by the new direction, and enjoys moving it forward, is a better choice than going back and ripping out the new framework (in retrospect, we should have *added* the new scripting facilities, rather than *replacing* the old). So consider this a call for my replacement. It's been an interesting ride, and I have learned a lot in the process, but it's probably time for someone else, who's more motivated by the new infrastructure. Best, R

3 2

bug: after erring on undefined component type, system is reported to load successfully
by 73budden . 10 Jan '16

10 Jan '16

Version 3.1.5, Example system definition: (defsystem :s3 :components ((cl-user::cons "file-name-does-not-matter") )) ;; eof I try to load it, it says: "Error while trying to load definition for system s3 from pathname c:/clcon/lp/test/s3.asd: don't recognize component type CONS" Then I try to load it another time, it says: T

2 3

user-homedir-pathname on cmucl
by Raymond Toy 09 Jan '16

09 Jan '16

Not sure how this ever worked with cmucl, but user-homedir-pathname on cmucl returns #p"home:", where "home:" is a search-list. In some cases, it looks like asdf is trying to create the cache directory and end up with a path like P"home:.cache/common-lisp/cmu-21a__21a_unicode_-macosx-x86/**/*.*.~*~" but this confuses other parts of asdf and cmucl when trying to run pathname-match-p. Perhaps the best thing is to make asdf us a custom user-homedir-pathname like what is done with other lisps. An appropriate version would be (defun user-homedir-pathname () (first (ext:search-list (cl:user-homedir-pathname)))) -- Ray

2 13