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

:require dependency
by Didier Verna 29 Jun '15

29 Jun '15

Hello, can somebody explain to me what is the :require dependency specification, and how it compares to just a simple-component-name ? Thanks. -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

2 3

Problem with ACL on windows & proposed fix
by Robert Goldman 28 Jun '15

28 Jun '15

Sorry -- I've been traveling, so sat on this bug report for a while. Here's a test failure from Windows ACL. Looks like ACL is somehow not running the windows CWD program helper (which should invoke CMD.EXE), but instead is just taking the command and treating it as its own output. the other expression (ASDF-TEST::GETCWD-FROM-RUN-PROGRAM) yields that: #P"%cd%\\" (:HOST NIL :DEVICE NIL :DIRECTORY (:RELATIVE "%cd%") :NAME NIL :TYPE NIL :VERSION :UNSPECIFIC) This comes from: (defun getcwd-from-run-program () (uiop:parse-native-namestring (nest ;; TODO: fix run-program to use POWERSHELL.EXE rather than CMD, and remove this kluge. #+os-windows (string-trim " ") (run-program (os-cond ((os-unix-p) '("pwd" "-P")) ((os-windows-p) "echo %cd%")) :output '(:string :stripped t))) :ensure-directory t)) RUN-PROGRAM on Allegro invokes RUN-SHELL-COMMAND, about which their documentation says: "This function, originally written and named for Unix machines, is badly misnamed for Windows, because on Windows, you can only run programs. Shell commands, such as dir, are not acceptable as a value of the command argument. See below in this entry for discussion on this point." Looking below, I see: "On Windows the name of the shell is cmd.exe. Here is an example of using run-shell-command on Windows: (run-shell-command "cmd /c start \"c:\\Program Files\\\"") which suggests we should modify %NORMALIZE-COMMAND for Allegro to prepend "CMD /C " to all commands when on windows. I'll test this myself the next time I get into the office, but that might not be till Monday afternoon. Or I might get lucky and find that I can remotely access my windows VM.... Best, r

4 8

Test failures on Windows
by Robert Goldman 24 Jun '15

24 Jun '15

I'm having some real oddities testing on Windows. Attached is a roster of the implementations for which I see test failures -- the Allegro variants and clisp. Two oddities: 1. I do not get verbose output showing what happens when the tests fail. Critical information is missing from the logfiles. I suspect that the test script assumes that standard output is redirectable in some way that it is not on Windows. See allegro-test.txt which is attached. Any idea how to get the lisp output? Any chance that REDIRECT-OUTPUTS function from script-support.lisp does not work on Allegro + Windows? 2. I get fewer failures running one test at a time than running them all in make. Allegro testing reported the following: -#--------------------------------------- Using g:/windows/allegro/32/non-smp/alisp Ran 56 tests: 52 passing and 4 failing failing test(s): test-encodings.script test-program.script test-try-refinding.script test-utilities.script -#--------------------------------------- But when I run the tests individually, only test-program and test-utilities failed. The other two tests succeeded. I have rarely seen something like this before in make on Unix variants due to not cleaning up the filesystem, but never in such a wholesale way. ---- Trying not to be a Unix bigot, but failing.... Best, R

3 5

Fwd: why is usocket.asd without an in-package or package qualifiers?
by Faré 16 Jun '15

16 Jun '15

Robert, should we export load-asd from asdf? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If Java had true garbage collection, most programs would delete themselves upon execution. — Robert Sewell ---------- Forwarded message ---------- From: Mark H. David <mhd(a)yv.org> Date: Tue, Jun 16, 2015 at 3:05 PM Subject: Re: why is usocket.asd without an in-package or package qualifiers? To: Zach Beane <xach(a)xach.com> Cc: usocket development <usocket-devel(a)common-lisp.net> Well, ASDF doc (here: https://common-lisp.net/project/asdf/asdf/The-defsystem-form.html) is not that clear about this. It shows an example .asd file, which does have an in-package, albeit to package asdf-user, and says of it: The file starts with an in-package form for package asdf-user. Quick summary: just do this, because it helps make interactive development of defsystem forms behave in the same was as when these forms are loaded by ASDF. ... The in-package form will ensure that the system definition is read the same as within ASDF when you load it interactively with cl:load. However, we recommend that you load .asd files through function asdf::load-asd rather than through cl:load, in which case this form is unnecessary. Don't mean to hijack usocket for ASDF complaints, but shouldn't asdf::load-asd be exported? Thanks, Mark ----- Original message ----- From: Zach Beane <xach(a)xach.com> To: "Mark H. David" <mhd(a)yv.org> Cc: usocket development <usocket-devel(a)common-lisp.net> Subject: Re: why is usocket.asd without an in-package or package qualifiers? Date: Tue, 16 Jun 2015 14:54:36 -0400 ASDF establishes a particular environment when using asdf:find-system and asdf:load-system that is not duplicated by a plain CL:LOAD. It has always been this way. You cannot reliably use CL:LOAD to load a system file and have things work. Zach On Tue, Jun 16, 2015 at 2:50 PM, Mark H. David <mhd(a)yv.org> wrote: I notices there's no in-package or qualifiers present in usocket.asd. So you have to, it seems, do (in-package :asdf) or similar before loading this file. Is there any good reason for this? I was thinking of fixing this and doing a pull request. Anyone against? Thanks, Mark

2 1

The dictatorship of versioning
by Didier Verna 16 Jun '15

16 Jun '15

Hi, in general, I don't like the way ASDF tries to force you to comply with its own design choices and policy. This is especially true for component versioning. ASDF complains that it doesn't like my version numbers (which, in fact, are not only numbers ;-), but I'm not ready to give up on them. They're much more informative than ASDF's simplistic 1.2.3. It seems that the only place ASDF uses our version numbers is in VERSION-SATISFIES. There is also a VERSION-COMPATIBLE-P somewhere, but it doesn't seem to be used. Fortunately, VERSION-SATISFIES is a generic function, so I'm thinking I could work around it. Not tested yet: 1. (defclass my-system-subclass (system) ()) 2. (defsystem :foo.bar.baz :class 'my-system-subclass #|...|#) 3. (defmethod version-satisfies ((c my-system-subclass) version) #|my own version handling code|#) Thoughts ? Will this be enough to satisfy ASDF ? In an ideal world, the whole versioning API (version-satisfies, version< etc.) should have been implemented as proper component-based protocols... -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

5 18

Release plan for asdf
by Faré 09 Jun '15

09 Jun '15

Dear Robert, I believe the plan to enable style-warnings for those using deprecated functions or missing useful metadata is great, but 1- justifies moving to version 3.2. 2- requires testing with a 3.2.0.x alpha release series that already have a version >= 3.2, so no magic problem occurs due to the change, as we had with the switch to 3.0.0. 3- is probably many months away at the current rate. 3- suggests releasing what we have now as 3.1.5. What are your blockers to a 3.1.5 release (besides lots of testing and corresponding bug fixes)? I really believe it would be nice to get the current bug fixes and clasp support out of the door before then. Last release 3.1.4 was in October; a lot of small fixes have happened since then, notably fixing default configuration on many systems, and things like chdir on abcl — or making asdf and uiop themselves comply with the latest metadata requirements (note that the test systems don't fulfill them.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It should be a grammatical if not legal offense to ascribe thoughts, opinions and decisions to "we" without a signed power of attorney.

4 9

Fwd: Introspecting source registry
by Faré 08 Jun '15

08 Jun '15

On Sun, Jun 7, 2015 at 6:09 AM, Mark Evenson <evenson(a)panix.com> wrote: > With asdf-3.1.4, how do I introspect the current state of source > registry configuration? I need to debug a remote user's ASDF > configuration on a machine which I don't have access to, so I would like > to have ASDF output the current source registry configuration search > state. Problematically, the behavior documented in section 8.1 doesn't > seem to be working as described on the user's machine. And this > behavior seemingly changes between "patch level" ASDF releases > especially on marginal platforms like Windows, digging up the "correct" > version of the manual isn't so easy either. > > [1]: > https://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searc… > > The contents of ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY* provides a > hashtable of systems that ASDF has located, but doesn't help me figure > out where ASDF *might* have searched for things. For output > translations the return value of (ASDF:INITIALIZE-OUTPUT-TRANSLATIONS) > gives me enough information for output translations, so it would be nice > to have something equivalent for the source registry. Since I suppose > that all of the behavior specified in section 8.1 is not easily > transcribed as a s-expr, my request may not be trivial to implement, but > in lieu of some similar mechanism, I am really having problems with > debugging ASDF behavior in a particular instance. > > Additionally, what is the behavior of ASDF when the $XDG_* environment > variables are not set, as is seemingly the case on a stock Windows > environment? Are these configuration steps just skipped? > 1- Look for asdf::*source-registry-parameter* which will tell you what ultimate overrides were used, if any. 2- Follow the trail of items in asdf::*default-source-registries*. So first, an environment variable CL_SOURCE_REGISTRY, then a configuration file ~/.config/common-lisp/source-registry.conf (beware: may be relocated via XDG, and will be somewhere else on Windows), and the corresponding .conf.d/ directory, then a hierarchy of system directories. It can be somewhat convoluted, so everyone gets a chance to tweak the configuration (lisp implementation packager, system administrator, local administrator, user). But usually, no one uses any of these mechanisms except the user. You're using asdf-3.1.4. Its documentation should be what's online right now, but is also in the release branch of our git repo. NB: are you on Windows? Things suck more on Windows, and are going to change in slightly incompatible ways with asdf 3.1.5 (hopefully making them suck a bit less). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Welfare: when you love strangers so much you're willing to have government steal money from another stranger to help them out.

2 1

Introspecting source registry
by Mark Evenson 07 Jun '15

07 Jun '15

With asdf-3.1.4, how do I introspect the current state of source registry configuration? I need to debug a remote user's ASDF configuration on a machine which I don't have access to, so I would like to have ASDF output the current source registry configuration search state. Problematically, the behavior documented in section 8.1 doesn't seem to be working as described on the user's machine. And this behavior seemingly changes between "patch level" ASDF releases especially on marginal platforms like Windows, digging up the "correct" version of the manual isn't so easy either. [1]: https://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searc… The contents of ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY* provides a hashtable of systems that ASDF has located, but doesn't help me figure out where ASDF *might* have searched for things. For output translations the return value of (ASDF:INITIALIZE-OUTPUT-TRANSLATIONS) gives me enough information for output translations, so it would be nice to have something equivalent for the source registry. Since I suppose that all of the behavior specified in section 8.1 is not easily transcribed as a s-expr, my request may not be trivial to implement, but in lieu of some similar mechanism, I am really having problems with debugging ASDF behavior in a particular instance. Additionally, what is the behavior of ASDF when the $XDG_* environment variables are not set, as is seemingly the case on a stock Windows environment? Are these configuration steps just skipped? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

program-op is nice!
by Attila Lendvai 06 Jun '15

06 Jun '15

Fare, your asdf/uiop image-dumping machinery is great! with only a few minutes of trying i've already made an exe for the dwim.hu service that seems to just work. i'm very pleasantly surprised, because it gets rid of the entire hu.dwim.build complexity, and is now even platform independent... thank you! :) FTR, the change is here: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.home;a=commitdiff;h=2… it all seems to just work, but i have a hard time telling asdf where to put the resulting exe. the :build-pathname arg of defsystem errors with absolute paths (which sounds reasonable), but then it's merely the filename of the exe. my problem is that it gets saved into the fasl cache, which i cannot calculate from the shell script side of the build script to mv the file to its final place. is there some doc or test that i have missed? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You think you know when you can learn; are more sure when you can write; even more when you can teach... but certain when you can program.” — Alan Perlis

2 3

[Asdf-devel] Registering preloaded systems for Quicklisp/ASDF
by Dave Cooper 05 Jun '15

05 Jun '15

Hi, I know this has been discussed, but what is currently the best practice for registering a preloaded system after loading Quicklisp? That is, I have a pre-built image with some Quicklisp/ASDF systems in it, which were loaded through so-called monolithic-fasls (now known as compile-bundles). So the pre-built image doesn’t itself have ASDF or Quicklisp. A downstream user then loads Quicklisp and ASDF (I take steps to ensure that they are loading the matching version of ASDF and Quicklisp as was used to build the image). Now I need to do something to tell Quicklisp and ASDF that certain systems are already loaded in this image, so it won’t try to re-load them as depended-upon systems. In this specific case, I don't want it to try to fetch and reload Gendl when the user does (ql:quickload ...) on an application which :depends-on :gendl (because gendl is already built into this image). asdf/find-system:register-preloaded-system seems like it should be the answer if we’re talking about plain ASDF, because it will prevent ASDF from raising a “missing-component” error for the system in question, if some other system :depends-on it and yet no source code is found. But in my case I can’t guarantee that “no source code is found.” The source might be there in the quicklisp dist directory. So apparently I need something stronger than register-preloaded-system? Or something else? -- My Best, Dave Cooper

3 21