asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

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

20 May '11

After some unplanned adventures asdf writes and reads fasls from implementation-specific directories. It was simple and the code is in the manual: simply put (:output-translations (:root (:root :**/ :implementation-type :*.*.*)) :inherit-configuration) in ~/.config/common-lisp/asdf-output-translations.conf and it works like magic. As :root is actually mentioned as magic in the manual, you can imagine how glad I am to have offered to contribute tutorial stuff :-) I will go through the code to try to demystify it for myself and try to find the words to explain it. Being a noob with configurations, maybe I should even try to explain this topic in the case of asdf. 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 a 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? Hoping to hear, Kind regards, Ernst

2 1

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

19 May '11

Great, then why not replace ASDF's function user-homedir into this one: (defun* user-homedir () #+mcl (ccl::findfolder #$kuserdomain #$kCurrentUserFolderType) #-mcl (truenamize (pathname-directory-pathname (user-homedir-pathname)))) I've made a patch (in attach), include above new definition and some notes. I hope Faré could merge it. We still love MCL even though it has so much difference from other modern CL platforms. --binghe 在 2011-5-19，07:05， Terje Norderhaug 写道： > On May 17, 2011, at 10:26 PM, Chun Tian (binghe) wrote: >>> Some time ago I can use ASDF with Macintosh Common Lisp, but recently I can't any more. >> >> I found a workaround for myself: >> >> (in-package :asdf) >> >> (defun user-homedir () >> #P"Macintosh HD:Users:binghe:") >> >> with above code loaded as a ASDF patch, I can load other packages well. > > Alternatively, when using ASDF with MCL, bind ccl::*user-homedir-pathname* to the pathname for the ~/ home directory of the current user: > > (ccl::findfolder #$kuserdomain #$kCurrentUserFolderType) > > The ccl::user-homedir-pathname function returns the value of ccl::*user-homedir-pathname* when called with no arguments. > > I have made a note about it in the ASDF section of <http://code.google.com/p/mcl/wiki/Portability>. > > -- Terje Norderhaug > terje(a)in-progress.com > > > > >

2 4

[asdf-devel] Tutorial for asdf?
by Ernst van Waning 18 May '11

18 May '11

Robert, As you see I do follow this thread since some time :-) Thank you for your answer. Tomorrow I will look into the asdf-code again and see what I will discover. I'll keep you informed. Kind regards, Ernst asdf-devel-request(a)common-lisp.net schreef op di 17-05-2011 om 14:40 [-0700]: > Is there a tutorial for asdf?

2 1

Re: [asdf-devel] [Bug 769634] Re: cl file types on asdf2.014.6, SBCL 1.0.29.11.debian and Is there a tutorial for asdf?
by Robert Goldman 17 May '11

17 May '11

On 5/13/11 May 13 -3:56 PM, Ernst van Waning wrote: > Dear Fare, Robert, I am moving this out of the ticket, because it's a general matter of ASDF discussion now, especially since this ticket is fixed.... [I /hope/ this reaches Ernst, but I actually do not have his email address, and I have no way of knowing if he's subscribed to asdf-devel...] > > Thank you very much for your work. Version 2.15 is downloaded and I > intend to use it. > > Please regard what I write below in a positive way. To get up to speed > with asdf2, I would like to read a tutorial. Is there one? If not, can > I help write one? > > As I have Allegro and SBCL now, I would like to get asdf to place and > find the respective FASLs in directories for Allegro resp. SBCL. From > the documentation > (http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-saves-…) > I see that this should be possible. After having read the entire > document several times over the last few weeks, I still have no clear > ideas about how to do this. With due respect, it feels like the > documents I write about my own work :-) When I write about my own work, > I am too deeply involved to write tutorials about it. > > So, if there is a tutorial explaining how to start using asdf > effectively, please point me to it; if not I am willing to help you > write it. It is hard for me to imagine I am the only one having > difficulties here. > > If asdf is (to be) the de-facto standard for defining systems in CL, a > tutorial will help the CL-community understand and use asdf and perhaps > even use CL-software written by others. I might refer you to recent > discussions on c.l.l. about curses of Lisp: imHo, Lisp is far from > cursed, but needs more accessible documentation. If that is not there, > then we will find tricks or roll our own, which is not desirable if we > want to be a prosperous community. I would be reluctant to see us spawn YA document. Instead, I would rather see the manual get fixed. I confess that I myself do not actually know how to do this: I am a longtime user of Gary King's ASDF-BINARY-LOCATIONS (as are my colleagues at work), and I have simply happily moved to (asdf:enable-asdf-binary-locations-compatibility :centralize-lisp-binaries nil) and all is well. So I'm not the right person to write such a tutorial. That said, if you were to provide corrections/extensions to this part of the manual, or a stand-alone FAQ, I would be more than happy to fold that material into the manual. Question: if you aren't fussy about /where/ the binaries go, isn't it enough to simply let ASDF start up, and it will keep your binaries apart, using the output-locations as configured out of the box? I am more used to people having the problem of needing to /disable/ these translations, or use a-b-l compatibility, than people having trouble with the built-in code. best, r

1 0

[asdf-devel] bad interaction with new ASDF 2.015 and Quicklisp
by Nikodemus Siivola 14 May '11

14 May '11

Steps to reproduce: 1. Get ASDF 2.015 or .1 2. Install Quicklisp, (ql:quickload "flexi-streams") 3. Install Flexi-Streams outside quicklisp as well. (For the purposes of bug reproduction, putting a copy of flexi-streams.asd into eg ~/tmp is enough.) 4. Go to the directory with the non-Quicklisp copy of flexi-streams.asd. 5. In lisp: (push "./" asdf:*central-registry*) (asdf:load-system "flexi-streams") ...endless recursion that eventually blows either stack or heap. What is happening is approximately this: ASDF starts loading ~/tmp/flexi-streams.asd DEFSYSTEM FLEXI-STREAMS is ok. During processing of DEFYSTEM FLEXI-STREAMS-TEST, FIND-SYSTEM is called for FLEXI-STREAM-TEST -- ironically _after_ it has been registered and its pathname set. Source-registry doesn't find it because there is no file flexi-stream-test.asd, and neither does SYSTEM-FIND-ASDF, but Quicklisp which _does_ find it: ASDF starts loading quicklisp/.../flexi-streams.asd ...you can guess where this leads. But even without the endless recursion this find is bogus. This did not happen with prior versions of ASDF. This is really messing up things for me -- enough so that I'm contemplating reverting the SBCL provided ASDF to 2.014. Cheers, -- Nikodemus

4 10

[asdf-devel] (no subject)
by Sean Bryant 11 May '11

11 May '11

Hello asdf, This is cross posted on the sbcl mailing list (I asked there first since this has to do with an sbcl specific feature.) Project names were changed to protect their identities. I'm a fairly new lisper and I'm running into trouble trying to generate coverage reports (using sb-cover, obviously) for a specific system in my project. I tried to just add the (declaim (optimization sb-cover:store-coverage-data)) after loading the system, but then I realized I made a horrible mistake as sbcl uses that optimization declaration to add tracing data to the compiled code. I then naively decided it would be a good idea to just force a recompile of the system. To my horror, I ended up recompiling everything sbcl touched, cl-sql, bordeaux threads, and more. The good news is that I managed to generate the coverage report but only with tons of external dependencies being included in the report as well. As much as I like knowing these things, it's not exactly useful. The solution I'm trying to come up with is creating a new type of operation in asdf conveniently called cover-op. I haven't had much luck in getting this working (I've only spent an hour on this, so not really surprising given my exposure to asdf). Currently, I like the setup with asdf:test-system and then just specialize perform to run the tests. I would like to do the same thing to generate coverage reports, but the compilation step is proving the be a problem. I'm wondering what other asdf users do to ensure coverage reports are generating for only the "interesting" aspects of your applications? Thanks, Sean

1 0

[asdf-devel] load-source-op broken in 2.015, fixed in 2.015.1
by Faré 09 May '11

09 May '11

Oops. I broke stuff in 2.014.13. Martin Simmons found the bug, I fixed it, but too late for 2.015. I committed 2.015.1, with a regression test. Apparently we weren't testing that functionality before. Is it OK to have load-source-op be broken for that while? If not, should I release 2.016 now, or tell people to use 2.015.1 instead of 2.015? e.g. I could push 2.015.1 to the "release" branch. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Microphones, liberating singers from having to be loud to be heard, gave back to each language a music that matches its own prosody.

1 0

[asdf-devel] asdf 2.015
by Faré 07 May '11

07 May '11

I promoted 2.014.17 as 2.015. Since 2.014, we have the following improvements: * Portability: support cormanlisp, xcl; fixes for cmucl, ecl; tweaks for abcl, allegro, clisp, genera, lispworks. * Feature: un-cerror and fix the :force '(sys1 sys2 sys3) feature, introduced in 2002 and never working before. * Feature: classes asdf:cl-source-file.cl and asdf:cl-source-file.lsp for people who use these file type extensions. * Semantic change: the source-registry eagerly gathers a list of .asd, rather than querying the filesystem over and over again. * API change: exposing function asdf:search-for-system-definition as looking through asdf:*system-definition-search-functions* for either pathnames *or* (new feature) system objects. Should make quicklisp happier. * Better support for asdf upgrading itself, with new function asdf:upgrade-asdf that knows to invalidate old systems when necessary, and is magically invoked before building any system that :depends-on asdf. Make upgrade smoother some cases that were previously broken. * More robust handling of version strings. * Declaring function asdf:system-definition-pathname obsolete, but still supporting it for now, as an alias for asdf:system-source-file. * Various refactorings of internals. Splitting a function asdf::perform-plan out of the default asdf:operate method. asdf::register-system now takes only one argument. * Added tests to prevent the many regressions experienced during this development cycle * Tried and reverted: attempts to make asdf more verbose when it's verbose, but not verbose by default. Thanks for testing. Please update your implementations and distributions to include the latest stable ASDF, currently 2.015. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Eric Schmidt rule of management: always assume that the other person is as intelligent as you are.

1 0

[asdf-devel] Added tests
by Robert Goldman 02 May '11

02 May '11

I added some tests for Faré's new cl-source-file subclasses, cribbing the old tests for changing the source-file-type by hand. And, indeed, I found a typo! Please pull updates and run the tests on your lisps! best, r

1 0

[asdf-devel] 2.015 soon - please test.
by Faré 02 May '11

02 May '11

I would like to release 2.015 this weekend - consider 2.014.13 a release candidate. Please test. A lot. So I don't have to release 2.015.1 next week. I have no current plans to hack more on ASDF, as there are no pending bugs that I think are fixable in 2.0. Hopefully, I can move on to other projects at long last. But I've said it before, and have come back to hacking ASDF and fixing its bugs (including writing new ones). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "I'm not a procrastinator, I'm temporally challenged"

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel