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

[asdf-devel] Issue in GETUID (MCL, again) and others
by Chun Tian (binghe) 11 Jun '11

11 Jun '11

Hi, Faré Today I compile latest asdf.lisp in MCL and see two warnings: ? (compile-file #P"Macintosh HD:Users:binghe:Lisp:packages:asdf:asdf.lisp") ;Compiler warnings for "Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.lisp" : ; :LAMBDA compiler warning with args (&OPTIONAL), in WITH-SYSTEM-DEFINITIONS. ;Compiler warnings for "Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.lisp" : ; Undefined function CCL::GETUID, in ASDF::GET-UID. #P"Macintosh HD:users:binghe:Lisp:packages:asdf:asdf.cfsl" T T The warning "Undefined function CCL::GETUID, in ASDF::GET-UID" was caused by #+ccl in following piece of code: #+asdf-unix (progn #+ecl #.(cl:and (cl:< ext:+ecl-version-number+ 100601) '(ffi:clines "#include <sys/types.h>" "#include <unistd.h>")) (defun* get-uid () #+allegro (excl.osi:getuid) #+ccl (ccl::getuid) ... Both Clozure CL and MCL contains the feature :CCL, so the form (ccl::getuid) was wrongly exposed to MCL. I think #+clozure (or legacy #+openmcl) should be used instead, just like other places in asdf.lisp. (if run-shell-command works on MCL, the function GET-UID should also work in MCL) A trivial patch is in attach (there's another #-ccl, don't forget it) P. S. For the first warning, why macro with-system-definitions have a standalone &optional in its parameter list? (defmacro with-system-definitions ((&optional) &body body) `(call-with-system-definitions #'(lambda () ,@body))) Regards, Chun Tian (binghe)

2 1

[asdf-devel] ASDF 2.016 breaks ABCL translations for jar files
by Mark Evenson 10 Jun '11

10 Jun '11

Stellian's [normalization to ANSI semantics of COMPILE-FILE-PATHNAME*][1] has the unfortunate effect of breaking ABCL's translation of systems packaged in jar files. [1]: http://common-lisp.net/gitweb?p=projects/asdf/asdf.git;a=commit;h=ed4cd3293… I have applied the subsequent patch to the asdf-2.016 packaged with ABCL to restore our needed functionality but am unhappy at the necessity of introducing a runtime implementation conditional, as sure a sign as anything that I'm "doing it wrong," and can't really request that ASDF patch itself in this manner. Maybe if I explain things as I have analyzed them, someone else can suggest a better way forward. Recall that ABCL uses the presence of a cons in the DEVICE component to indicate that a Pathname represents an entry in a jar archive. A pathname located within a jar archive is not a writable location, so we introduced ABCL specific ASDF output translation rules which translate such a source location to an appropriately differentiated output location in the ASDF cache hierarchy. This results in ASDF making the following kind of call in preparation of the output file location it will pass to COMPILE-FILE: (compile-file-pathname* <path with a DEVICE> :output-file <path without a DEVICE>) Stellian's patch correctly fixes behavior of COMPILE-FILE-PATHNAME* to use pathname components in input-file if none are specified in output-file. For ABCL systems in a jar, this results in returning an output location within the jar file, which being a non-valid output location because it is not writable causes ASDF to error out in compiling the system. If there were some mechanism to indicate that the invocation of APPLY-OUTPUT-TRANSLATIONS had really "finished" so that no further processing was necessary, we could possibly plausibly short-circuit this call to COMPILE-FILE-PATHAME*. I suppose my recursive invocation of APPLY-OUTPUT-TRANSLATIONS in the ABCL-specific TRANSLATE-JAR-PATHNAME adds the missing TYPE to the pathname which other code paths don't have at this point, which is why the call to COMPILE-FILE-PATHNAME* is necessary. ANSI allows the addition of implementation specific arguments to COMPILE-FILE-PATHNAME, so we could maybe add a :strip-device for ABCL but this seems even less elegant. Any suggestions? @@ -3523,7 +3525,16 @@ --- a/asdf.lisp Thu Jun 09 06:03:20 2011 +0000 +++ b/asdf.lisp Thu Jun 09 15:00:45 2011 +0200 (defun* compile-file-pathname* (input-file &rest keys &key output-file &allow-other-keys) (if (absolute-pathname-p output-file) - (apply 'compile-file-pathname (lispize-pathname input-file) keys) + ;;; If the default ABCL rules for translating from a jar path to + ;;; a non-jar path have been affected, no further computation of + ;;; the output location is necessary. + (if (and (find :abcl *features*) + (pathname-device input-file) ; input-file is in a jar + (not (pathname-device output-file)) ; output-file is not in a jar + (equal (pathname-type input-file) "lisp") + (equal (pathname-type output-file) "abcl")) + output-file + (apply 'compile-file-pathname (lispize-pathname input-file) keys)) (apply-output-translations (apply 'compile-file-pathname (truenamize (lispize-pathname input-file)) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 11

Re: [asdf-devel] Where's the ASDF source for checking for updated files?
by Faré 09 Jun '11

09 Jun '11

A user question: 011 13:28, Erik Winkels <aerique(a)xs4all.nl> wrote: > Hi, > > I'm not sure whether ASDF is the culprit here but I need some help tracking down a problem I'm having: > > I'm developing a program which gets called from the command line so I'm also testing it like that. i.e. I'm using the classic C'ish compile-save-run cycle for development. I am also using ASDF for running the program. > > What happens is that when I make a change in my source files ASDF doesn't seem to pick up the changes when loading the system. This happens when the changes are done within one minute of eachother. > > A workaround is using an interactive Emacs+Slime environment but I am also interested in tracking this bug down. > > Do you have anu suggestions where I should start looking in asdf.lisp? I opened it in Emacs but couldn't find my way around. > > Thanks, Erik > It's hard to debug from such flimsy information. How do you "use ASDF" to run the program in a compile-save-run way? Your problem is likely clock skew, resolution or known race condition. Or it might be (unlikely) a bug in ASDF (or one of its extension, if you're using any). I remember once having to fix an infinite loop when the filesystem server has time skew in the future from the current host. There is infinite loop no more, but time skew is probably still "interesting". Additionally, the resolution of the timestamps is usually one second, which might not be enough to distinguish the need to recompile, if your edit-compile cycle is very short. Finally, and there's an unavoidable race condition if you modify a file while it is being compiled. Oh, and if you disabled asdf output-translations while compiling files with SLIME, the fasls may clash. To debug, you might want to trace asdf:operation-done-p and/or safe-file-write-date and get-universal-time. In the future, XCVB will replace ASDF's timestamp change detection with change detection based on cryptographic digests of file contents. We're almost there — care to help? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Well, the fact is, God does exist and I'm His prophet. And my prophecy is that you shouldn't believe in God, for it would be a blasphemy against His gift of Reason to you. So don't you believe in Him, lest you go to Hell!

1 0

[asdf-devel] Linkkit
by Faré 08 Jun '11

08 Jun '11

I have a wishlist item for SBCL: it would be self-enclosed application delivery into a single executable that includes not only the Lisp image, but also additional statically compiled C libraries. CLISP has a "linkkit" for that, and ECL can do it, too. If I understand what nyef told me, we might have to have some magic linker script and function annotations to ensure that magic functions are located at an address known to Lisp code despite new code being linked into the .text and .data segments. Typically, we'd either ensure the proper objects files are linked first, or you'd create a magic segment(s) different from .text and/or .data, that starts at a magic address, in which to compile the stuff that the Lisp image will expect to be at a known address. Is some SBCL hacker interested in doing that? Or maybe only add it to the S BCL TODO file? Or maybe someone can explain me WHICH functions and datastructures must be at a fixed address, and then I can try to write the linker script myself using my experience from bootstrapping kernels on a new machine. Thanks a whole lot! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If it doesn't work right, we can always try something else. — John McCarthy

1 0

[asdf-devel] ASDF 2.016 released
by Faré 08 Jun '11

08 Jun '11

Dear CL users, I released ASDF 2.015.12 as 2.016. Please test, and upon success update your implementations and lisp distributions. Since 2.015, we have the following improvements: * Portability: Fixes for ECL, RMCL. Tweaks for CLISP. Improvements to Windows configuration, notably for LispWorks. * Fix to load-source-op (broken in 2.014.13 - oops). * Avoid infinite loops in defsystem in cases of bad interference between quicklisp and your source-registry. * Small fixes regarding upgrade, compile-file* :output-file. * Make defsystem-depends-on actually useful by allowing a system thus depended on to define the class of the system depending on it. The XCVB bridge notably relies on this feature. * Some documentation updates. Notably, for the sake of CLISP, (require "asdf") is the new canonical way to load ASDF, instead of (require :asdf). Sigh. * Better tests, notably wrt hot upgrade. Happy hacking! —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The American diplomat to the Russian: "My country too is free: in the USA too anyone may freely publish the dirty little secrets of president Medvedev!"

1 0

Re: [asdf-devel] Parse a component without loading it
by Robert Goldman 03 Jun '11

03 Jun '11

Possible evil solution: (let ((asdf::*defined-systems-table* (make-defined-systems-table))) (let ((my-system (asdf:find-system "system-to-debianize"))) <code to analyze systems> .... ) Now you just have pushed a duplicate repository, into which you are loading new definitions, and when you leave the dynamic scope of *defined-systems-table*, ASDF will continue to behave normally. This does, of course, cheat on the API, as well, but it doesn't require you to maintain compatibility with parsing, use odd accessors, etc. Best, r

2 1

[asdf-devel] Parse a component without loading it
by Francisco Vides Fernández 03 Jun '11

03 Jun '11

Hi! I'm working on a project to generate deb packages directly from asdf files (if it works, will be published open sourced). I need to parse a component definition form and work with the generated object, so I'm using asdf::parse-component-form for this, but it first searches the component (using asdf::find-component) and if it doesn't exist, then makes a new instance but the desired behaviour in this case is always generate a fresh instance. I've extended it so it can accept an optional parameter, 'reuse-instance to get the desired behaviour (patch attached). Furthermore, IMHO, asdf::parse-component should be exported so it makes easier to develop asdf extensions. Am I missing something? Is the attached patch acceptable? Thank you -- +----------------- | Francisco Vides Fernández <fvides(a)dedaloingenieros.com> | Gerente | Teléfono fijo: 952 60 29 59 | Fax: 952 60 29 59 | Dédalo Ingenieros http://www.dedaloingenieros.com/ | PGP: http://pgp.rediris.es:11371/pks/lookup?op=index&search=0xB1299C15 +------

2 2