asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

[asdf-devel] upcoming asdf 2.016
by Faré 30 May '11

30 May '11

Dear ASDF users, I'd like to release ASDF 2.016 next weekend. Can you powerusers test the current ASDF, and tell me if you find anything wrong? Since 2.015, changes include: * Fix to load-source-op (broken in 2.014.13) (thanks to Martin Simmons) * Fix infinite loops in some .asd containing multiple defsystem's and available both in and out of quicklisp. (Thanks to Nikodemus and Zach) * Fixes for ECL and RMCL (thanks to binghe and Terje Norderhaug) * Fixes for configuration under Windows (many thanks to Martin Simmons) * Minor documentation updates. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Success is getting what you want. Happiness is wanting what you get. — Dale Carnegie

1 0

[asdf-devel] MCL issue
by Chun Tian (binghe) 29 May '11

29 May '11

Hi, ASDF developers Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more. I updated to latest ASDF 2 and compile/load it into MCL (my current version is 6.0, but 5.2.1 has the same problem): ? (pushnew #P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:" asdf:*central-registry* :test 'equal) (#P"Macintosh HD:Users:binghe:Lisp:usocket:branches:0.5.x:") ? (asdf:load-system :usocket) > Error: Not an absolute pathname: #4P"home:" > While executing: ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT > Type Command-. to abort. See the Restarts… menu item for further choices. 1 > I don't know what does ASDF::RESOLVE-ABSOLUTE-LOCATION-COMPONENT try to do, but I see a fact that MCL's standard function USER-HOMEDIR-PATHNAME can only return the MCL installation directory but current Mac user's home directory: ? (user-homedir-pathname) #4P"home:" ? (truename *) #P"Macintosh HD:Users:binghe:Lisp:MCL 6.0:" I think above function should return #P"Macintosh HD:Users:binghe:" instead. And I see ASDF depend on USER-HOMEDIR-PATHNAME, so that there's no way to store compiled fasls into "~/.cache/common-lisp" ... Regards, Chun Tian (binghe)

5 25

[asdf-devel] RMCL vs. ASDF
by Pascal Costanza 28 May '11

28 May '11

Hi, Here is what happens in RMCL when the configuration says :inherit-configuration. At startup, I get an error message that says this: ; NOTE: *TERMINAL-IO* was #<CCL::INITIALIZATION-OUTPUT-STREAM #x4453B26>, was reset to #<CCL::TERMINAL-IO #x4A0FE26> . > Error in process Startup: File #4P"home:" does not exist. > While executing: TRUENAME This is triggered by the function user-homedir. While RMCL is still in debug mode for this error, (truename (user-homedir-pathname)) fails. However, afterwards, it returns correctly (for some value of "correct"): ? (truename (user-homedir-pathname)) #P"Macintosh HD:Users:costanza:lisp:RMCL 5.2.1:" My guess is that user-homedir-pathname returns #4P"home:" as a constant value, even before the logical pathname translation for it is defined during startup. The deeper problem is, again, that the notion of a home directory doesn't make sense in RMCL (at least not by default). If ASDF wants to have a notion of a home directory, it should be a configurable parameter of ASDF that in most systems can indeed default to the result of (user-homedir-pathname). But it should be possible to explicitly set it in some way before ASDF decides to go looking for it. (This would make ASDF more robust for potential future CL systems that may not have a notion of a home directory either, however unlikely this may be.) Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

2 2

[asdf-devel] Logical pathnames....
by Robert Goldman 22 May '11

22 May '11

FWIW, I am just working on a project that has some CL people and some non-CL people. The fact that pathnames with underscores (that C programmers, e.g., are fond of) break decoding when they appear in logical pathnames is a real stinker. This alone is almost enough to rule out of court the use of logical pathnames, IMO.... Cheers, r

2 4

Re: [asdf-devel] Tutorial ASDF(?)
by Ernst van Waning 21 May '11

21 May '11

Dear Robert, >> However, I have one question: what is the reason that these >> output translations are apparently not applied to the .asd >> files? The way I understand my output-translations, I have >> globally specified that all fasls are in an >> implementation-specific directory just below my source >> files. For me, .asd files are just source files, so why not >> place them where the other fasls are written? > Not sure I fully understand. As you say, the .asd files are just > source files, and they are never compiled, so there is no need > to do any output translations for them. > I may not have fully followed the question.... concerning the .asd files, I use cl path/to/..asd in the REPL and both sbcl and acl try to find fasls for them. If there is no corresponding fasl, they write one. At present, I do an explicit (load #P"path/to/system.asd") to prevent Lisp from writing fasls. So, the question comes from a habit developed over the years: why aren't defsystem files trated the same way as source files, i.e., treated according to what is specified in asdf-output-translations.conf? Hopefully this explains a bit of the backgrond of my question. Further comments later. Kind regards, good weekend, Ernst asdf-devel-request(a)common-lisp.net schreef op vr 20-05-2011 om 12:00 [-0700]: > Re: Tutorial ASDF(?)

7 10

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel