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

[asdf-devel] source file encoding
by Anton Vodonosov 16 Apr '12

16 Apr '12

Hello. How to specify source files encoding in ASD2? I.e. what value to pass to the :external-format argument of the compile-file? In the old ASDF I did it by (let ((asdf:*compile-file-external-format* #+:clisp charset:cp1251 #+:sbcl :cp1251)) (asdf:operate 'asdf:load-op :mysystem)) But today the variable asdf:*compile-file-external-format* does not exist. Also, it of course would be better to specify the encoding in the .asd file (the system author knows the files encoding, and should care about this, but not the system user). Could you advise me how to do it? Best regards, - Anton

13 61

[asdf-devel] Package definition for each file in :components?
by Matus Kmit 27 Jun '11

27 Jun '11

Hi i have some basic question: Let's say, i have defined a system where with four files: system.asd, packages.lisp, file1.lisp, file2.lisp, where file1 and file2 share the same package and are split more or less only for better organisation purpose. So in packages.lisp i define only one package and use the respective in-package expression for it in the beginning of the two files. Besides that file1 should be loaded before file2. In my asd file i have something like this: (defsystem "system" :depends-on ("ext-system") :serial t :components ((:file "packages") (:file "file1") (:file "file2"))) Trying to load this system with (ql:quickload "system") i get an error, that there is no package for file1. i discovered that when i define a package for file1, although never use it, things work as i want. Does one have to define a package for each file listed in :components? Is there some other, more suitable way to fulfil my purpose (use the same package in both files? Thanks for any help Matus

2 2

[asdf-devel] Disabling "built-in" output translation
by Mark Evenson 21 Jun '11

21 Jun '11

ASDF contains some specialized code for ABCL that enable the translation of ASDF systems whose source is packaged into jar files to locate the corresponding object files in ASDF's user cache. In trying to figure out the correct mechanism to allow for "binary" ASDF distribution under ABCL that would include both the source and the fasls in the same jar file, I need to disable the jar file translation mechanism. I expected that invoking DISABLE-OUTPUT-TRANSLATIONS would clear this built-in translation mechanism, but it doesn't seem to do this. Only invoking CLEAR-OUTPUT-TRANSLATIONS seems to actually change the output translation map. To wit: ASDF> (disable-output-translations) ((T T) (#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (output-translations) ((#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T T) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (disable-output-translations) ((T T) (#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (output-translations) ((#P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*" T) (#P"/___jar___file___root___/**/*.*" #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*") (#P"jar:file:/**/*.jar!/**/*.*" #<FUNCTION TRANSLATE-JAR-PATHNAME {771931F8}>) (T T) (T #P"/Users/evenson/.cache/common-lisp/abcl-0.26.0-dev-fasl37-macosx-java/**/*.*")) ASDF> (clear-output-translations) ; No value ASDF> (output-translations) NIL ASDF> Should DISABLE-OUTPUT-TRANSLATIONS actually push that (T T) list into the beginning of that (OUTPUT-TRANSLATION) list or does the API expect that the user use it something like ASDF> (setf (output-translations) (disable-output-translations)) Should ASDF under ABCL strip out the jar translation mechanism as well, or should the ASDF API expect that the user would actual issue a (CLEAR-OUTPUT-TRANSLATIONS)? I confess that I am a bit confused when one would ever use DISABLE-OUTPUT-TRANSLATIONS as opposed to CLEAR-OUTPUT-TRANSLATIONS. Once I understand the ASDF API here a bit better, I will work on the necessary ABCL specific ASDF patches if necessary. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 6

Re: [asdf-devel] [Sbcl-devel] Logical pathnames vs ASDF & SBCL
by Zach Beane 17 Jun '11

17 Jun '11

"Scott L. Burson" <Scott(a)sympoiesis.com> writes: > On Mon, Jun 13, 2011 at 6:17 AM, Faré <fahree(a)gmail.com> wrote: >> I don't see why you believe that ASDF 1.x isn't a viable option. > > I'm not among those having trouble with ASDF v2, but I would just > point out that going back to v1 has been made rather unattractive by > the tremendous usefulness of Quicklisp, which AFAIK depends on v2. No, it doesn't. When I started sharing Quicklisp, some implementations didn't ship ASDF at all, so it made sense to bundle a copy and load it if necessary. ASDF2 seemed like the reasonable thing to bundle. The feature of ASDF2 that makes Quicklisp work better is implementation FASL segregation enabled by default. Zach

1 0

[asdf-devel] Logical pathnames vs ASDF & SBCL
by Faré 17 Jun '11

17 Jun '11

TL;DR: ASDF currently doesn't play so well with logical pathnames. I'm seeking advice on how to make things better — or on whether it's worth the trouble. Dear all, Pascal's recent plight with logical pathnames on SBCL once again rises the issue of how much ASDF (or SBCL) should support logical pathname users, and how they should behave to make logical pathname users happy. With case-sensitivity issues, things only get worse! (Note: personally inviting James Anderson to the discussion, since he's the only strong proponent and user of logical pathnames I know.) REMINDER ABOUT LOGICAL PATHNAMES (LPNs) So, the CLHS says LPNs are case-converted to upper-case, portably restricted to such upper-case characters, and get translated to physical pathnames in an implementation-dependent way. On Unix, with its case-sensitive filesystems and lower-case conventions, the useful thing is then downcasing names. At least SBCL and CLISP follow both the standard and the useful pathname mapping convention. SBCL goes on to length to throw an error when non-portable code tries to break the standard restrictions on logical-pathnames; CLISP will let you manually make-pathname a LPN with lower-case or mixed-case characters, but will still downcase them at the end (the latest CLISP 2.49 also seems to not want to create a logical pathname with parse-namestring). CCL tries to make users happy by leaving the logical pathname host case-insensitive (per the standard) but case-preserving, and being case-sensitive in the rest of the pathname (if you want upper-case, you know where to find it). To collect and analyze the behavior of each of 14 implementations is left as an exercise to the logical-pathname loving reader [M20]. To devise, document and get implementations to adopt a common behavior that would be universally accepted by all is left as another exercise [50]. ASDF NAMING OF SYSTEMS Similarly, when naming an ASDF system, to allow to designate systems with symbols (CL legacy), which are case-converted, yet map them to a unixy lower-case name, and still allow systems with all kind of cases, symbols are downcased whereas strings preserved. Then the filesystem is queried with the resulting normalized string name (see function coerce-name). Now with its good old central-registry, ASDF used to query each directory every time a system was requested. This works great with logical pathnames, as it defers all case handling to the last minute, and allows .asd files to be loaded with a LPN as the *load-pathname*. However, this was somewhat slow, and it didn't scale to recursively searching directories, and so came the habit of creating "link farms", single directories with plenty of symlinks to adequate .asd files. Of course, symlinks are both not so portable (not very well supported in Windows, if at all, though later versions of ASDF recognize Windows shortcuts as a substitute), and a maintenance nightmare (unlike Macintosh aliases, they are not automatically updated when a system is installed, moved or deleted). Therefore link farms were not a good interface to end-users. For ASDF 2, I implemented a new way to manage system files: the source-registry. It allows you to specify trees to search recursively as well as single directories. Whether the registry is searched lazily (when a system is requested) or eagerly (one the first time around) or yet something else, was left unspecified. In my first implementation of it, I built upon the previous central-registry, and at initialization time I was looking for which subdirectories in the specified trees did contain .asd files, then saved these in a list that I consulted in the very same way as the central-registry. (Note: the central registry is still there, and consulted first.) However, DIRECTORY returns fully resolved TRUENAMEs, and any portable way of searching inside subdirectories is doomed to squash away logical pathnames. Currently, any use of :tree in source-registry will resolve into physical pathnames (PPNs) on most implementations, and always did. However, entries with :directory used to preserve LPNs. Not so with 2.014.7, where, prompted by a Quicklisp feature request, I implemented eager caching of ASDF systems. So I query DIRECTORY and save the results in a hash-table indexed by pathname-name. The table is case-sensitive, to reflect the case-sensitive names of ASDF. One consequence is that :directory entries do not preserve LPNs anymore. Another more subtle consequence is that things may go wrong if your filesystem is case-insensitive but case-preserving. In the old way of doing things (still available with the central-registry), you'd typically be looking for the file with lower-case name, and you would find it even if named in different cases on disk. With the old way, you'll record the name in its case mix, and will never match it against the (lowercase) name. So some systems that depend on this behavior will disappear. POTENTIAL SOLUTIONS An easy way out is to declare that ASDF from now on shall be case-insensitive, using EQUALP to compare system names and in hash-tables that cache system files. Another way out is to declare that ASDF is still case sensitive, and that the only case allowed is lower-case for physical filenames. Any system that doesn't work with this new interpretation probably didn't work portably with the old one, anyway. A harder way out would be to assume case-sensitivity in the filesystem (since some filesystems are case-sensitive, and any asd file that depends on case-insensitivity is non-portable and deserves to lose), and make extra effort when using DIRECTORY against logical pathnames to always reconstitute LPNs from the PPNs given by directory, and drop the reconstituted results if they don't resolve to the same thing. But is it worth the pain? Finally, I could do nothing, and assume that people who go through the pain of setting up logical pathnames before they run ASDF can just as well setup the *central-registry* and have LPNs be recognized in the good old way. If you use the source-registry, your LPNs will be squashed, and nothing will break in the code since code works fine with PPNs, just like most everyone use it, but your debug information will be stored according to the PPN, not the LPN. Meh. Zach (if you're still reading), do any systems in the wild use anything but lower-case names for system files? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Two members of the Political Police salute a giant portrait of our Great Leader - Comrade, do you think the same as I do? inquires the first one, with a sincere gaze pleeing into his colleagues' eyes. - Comrade, the second one replies and returns the same gaze: yes, I do. - In that case, comrade, you're under arrest! concludes the first one.

7 10

[asdf-devel] pathname case issue ...
by Chun Tian (binghe) 17 Jun '11

17 Jun '11

Hi, ASDF developer Recently I found a strange behaivour in latest ASDF: it internally converts all my pathname namestrings into lower-case, although I'm using a case-insentive HFS on Mac. I have following items in asdf:*central-registry*, these packages are either maintained/modified by me or not yet with Quicklisp: SNMP 14 > asdf:*central-registry* (#P"/Applications/FileMaker Pro 11/fm-plugin-tools-0.2.9/" #P"/Users/binghe/Lisp/packages/trivial-gray-streams/" #P"/Users/binghe/Lisp/packages/lisa/" #P"/Users/binghe/Lisp/packages/elephant/" #P"/Users/binghe/Lisp/packages/cffi/" #P"/Users/binghe/Lisp/packages/cl-base64/" #P"/Users/binghe/Lisp/packages/iolib/src/" #P"/Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/" #P"/Users/binghe/Lisp/usocket/branches/0.5.x/" #P"/Users/binghe/quicklisp/quicklisp/") Notice that all of those pathnames except the first one is started from directory "/Users/binghe", in which the letter "U" is upper-cased. But, when I manually compiled a changed definition in one of above projects (snmp), I got a warning from my Lisp platform: """ Warnings: (DEFUN SNMP-CONNECT) being redefined in /users/binghe/Lisp/cl-net-snmp/snmp/branches/6/session.lisp (previously in /Users/binghe/Lisp/cl-net-snmp/snmp/branches/6/session.lisp). """ See, now ASDF think the Lisp file was in another different directory which started from "/users/binghe/, in which the first letter "u" is lower-cased. I hate this new behaviour, either because I want to keep all my namestring cases in a case-insentive file system, or I doubt that if I'm in a case-sensitive HFS filesystem, ASDF may failed to distinguish /Users and /users or something like this. Please confirm it's a new feature or bug and please consider reverting to previous status. Regards, Chun Tian (binghe)

5 16

[asdf-devel] Force reloading a .asd file without "touch" it
by Chun Tian (binghe) 15 Jun '11

15 Jun '11

Hi, ASDF users Any one know how to reload a .asd file without "touch" it to let it have a newer timestamp? I have a snmp.asd file which contain the content of another file: (defparameter *mib.lisp-expr* (with-open-file (s (merge-pathnames (make-pathname :name "mib" :type "lisp-expr") *load-truename*) :direction :input) (read s))) (defsystem snmp ... :components ( ... (:module "compiled-mibs" :depends-on ("runtime") :components #.*mib.lisp-expr*))) See, the DEFSYSTEM form is actually determined by another file. And I have a function which can update this another file, and after its content change, I want to re-load this snmp.asd to make the new DEFSYSTEM form take effect. Just call (asdf:load-system :snmp) obviously won't help. How can I achieve this goal? Thanks, Chun Tian (binghe)

2 2

[asdf-devel] ASDF 2.016.2
by Faré 13 Jun '11

13 Jun '11

Regarding RMCL and logical pathnames, please test 2.016.2. I introduce some non-trivial pathname changes. On RMCL, ASDF sees strings as "/posix/namestrings/" in its configuration. if you want OS9-style pathnames, they are #p"that:a:way:". You can thus both trivially share your configuration with other implementations, and just as trivially use MCL-specific paths. For logical pathnames, I implemented my "harder way" plan from previous email: > make extra effort when using DIRECTORY against logical pathnames > to always reconstitute LPNs from the PPNs given by directory, and > drop the reconstituted results if they don't resolve to the same thing. In other words, if I compute (directory #p"FOO:CL;BAR;"), and find a file #p"/home/baz/cl/bar/quux.asd", the file will be kept only if (make-pathname :name "quux" :type "asd" :defaults #p"FOO:CL;BAR;") has the previous as its truename. And similarly when walking directories. I believe this restriction is not a problem in practice, and will keep things somewhat sane. And no, it's probably still not a good idea to try mix logical pathnames and mixed-case physical pathnames, as the result is highly non-portable. Also removed *system-cache* and getuid, which were bad ideas that never worked (and if anyone is using either, he'll thank me for making him stop). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I believe in God, only I spell it Nature. — Frank Lloyd Wright

4 7

[asdf-devel] clear-output-translations and saved cores
by Raymond Toy 13 Jun '11

13 Jun '11

Xach brought this to my attention wrt to maxima, but it's not really about maxima and asdf2. My question is if clear-output-translations should always be called before saving a core. Is there a case where you would not want to run c-o-t before saving a core? If c-o-t should always be run, wouldn't it make sense for asdf2 to arrange for that? I'm not familar with how other lisps do this, but cmucl does have *before-save-initializations* which is a list of functions that are run before a core is saved. Perhaps asdf2 should push #'c-o-t onto *before-save-initializations*? Ray

4 6

[asdf-devel] SBCL 1.0.49 / ASDF 2.015.3 doesn't load my asdf systems anymore
by Pascal Costanza 12 Jun '11

12 Jun '11

Hi, See subject line. Here is a trace from the listener: This is SBCL 1.0.49, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (asdf:load-system :closer-mop) debugger invoked on a ASDF:MISSING-COMPONENT: Component "closer-mop" not found Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((LAMBDA ())) 0] :backtrace 0: ((LAMBDA ())) 1: ((LAMBDA ())) 2: (ASDF::CALL-WITH-SYSTEM-DEFINITIONS #<CLOSURE (LAMBDA #) {1003E98CA9}>) 3: ((SB-PCL::FAST-METHOD ASDF:OPERATE (T T)) #<unused argument> #<unused argument> ASDF:LOAD-OP :CLOSER-MOP) 4: ((SB-PCL::EMF ASDF:OPERATE) #<unused argument> #<unused argument> ASDF:LOAD-OP :CLOSER-MOP) 5: (ASDF:LOAD-SYSTEM :CLOSER-MOP) 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:LOAD-SYSTEM :CLOSER-MOP) #<NULL-LEXENV>) 7: (EVAL (ASDF:LOAD-SYSTEM :CLOSER-MOP)) 8: (INTERACTIVE-EVAL (ASDF:LOAD-SYSTEM :CLOSER-MOP) :EVAL NIL) 9: (SB-IMPL::REPL-FUN NIL) 10: ((LAMBDA ())) 11: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA #) {1003E982F9}>) 12: (SB-IMPL::TOPLEVEL-REPL NIL) 13: (SB-IMPL::TOPLEVEL-INIT) 14: ((FLET #:WITHOUT-INTERRUPTS-BODY-[RESTART-LISP]30)) 15: ((LABELS SB-IMPL::RESTART-LISP)) 0] This happens with other systems as well. (I haven't been able to load any system anymore, but I haven't tried all that I have installed.) What information do you need from me to be able to fix this? Best, Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

3 14

[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