asdf-devel

asdf-devel@common-lisp.net

5 participants
1375 discussions

[asdf-devel] Question about git
by Robert Goldman 31 Jan '10

31 Jan '10

How are we supposed to be reasoning about the multiple git repositories out there? I have been pulling from the master/public one and then working locally. Fare works on his personal working copy. When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his. How are we supposed to handle this? Thanks, r

5 12

Re: [asdf-devel] asdf v 1.501: doesn't look at /etc/common-lisp/source-registry.conf.d/
by Faré 30 Jan '10

30 Jan '10

Oops, you're right. So here's ASDF 1.502. Also includes a fix to bug 513338 (ccl support in test). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Living your life is a task so difficult, it has never been attempted before. On 30 January 2010 16:14, Peter Van Eynde <pvaneynd(a)debian.org> wrote: > Looking into the code I vaguely think that we are missing a call to > > (process-source-registry (system-source-registry-directory-pathname) > > somewhere, not?

1 0

Re: [asdf-devel] Bug#560781: (require :package) no longer works for CLC-managed packages
by Faré 29 Jan '10

29 Jan '10

2010/1/20 Peter Van Eynde <pvaneynd(a)mailworks.org>: > instead of /etc/common-lisp/source-registry.conf I would like to see > /etc/common-lisp/source-registry.conf.d > > where instead of having one file that you might have to edit in > post-installation scripts we would have a directory where packages can > just drop files into. Just like we have /etc/crontab and /etc/cron.d/* > on Debian. > > This would make my and I suspect others work much easier. > Makes perfect sense. I'll add that on top of my TODO list for ASDF. Would that replace source-registry.conf altogether, or override it, or be overridden by it? >> Since ASDF-BINARY-LOCATIONS is now part of ASDF, I suppose it could be >> similarly configured, and CLC could and should "just" use that. What >> do you think? > > I just noticed this in the manual and need to read it with more > attention later. Ideally I would like it to handle also 'cached' fasl > files from a trusted system user. Would it be able to do this too? > I probably would do it, if we coax it to our will. Definitely possible. I admit I never looked into ABL myself, having only ever used but my own variant (included in cl-launch) that itself is derived from an earlier CLC and works well with CLC. Hopefully, moving ABL into ASDF was a good move, and we should get the configuration of it right. > So load from > /var/cache/common-lisp-controller/cl-builder/<implementation>/... > or > /var/cache/common-lisp-controller/<userid>/<implementation>/... > or compile from /usr/share/common-lisp-controller/source/... to > /var/cache/common-lisp-controller/<userid>/<implementation>/... > Yes. All the while, the default might be something like ~/.cache/common-lisp/<same-tag-as-slime>/... > Related: I might go for a business trip to Boston in the near future and > would love to have a chat! I would love to see you again! [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] He who refuses to do arithmetic is doomed to talk nonsense. — John McCarthy, in his webpage on Progress and Sustainability

2 2

[asdf-devel] subtle bugfix [for clisp on windows]
by dherring＠tentpost.com 28 Jan '10

28 Jan '10

Thank you git-bisect. The attached patch fixes my problems with asdf and clisp on mswinxp32. It fixes what I believe was a typo in commit 2ca055895. Surprisingly, it works on most implementations. - Daniel

2 1

[asdf-devel] asdf.texinfo version 1.375 has errors [resend as ML member]
by Peter Van Eynde 27 Jan '10

27 Jan '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, While trying to build a new Debian package I get the following errors: > $ makeinfo --verbose asdf.texinfo > makeinfo (GNU texinfo) 4.13 > Making info file `asdf.info' from `asdf.texinfo'. > Formatting node Top... > Formatting node Introduction... > Formatting node Using asdf to load systems... > Formatting node Defining systems with defsystem... > Formatting node The defsystem form... > Formatting node A more involved example... > Formatting node The defsystem grammar... > Formatting node Other code in .asd files... > Formatting node The object model of asdf... > Formatting node Operations... > Formatting node Predefined operations of asdf... > Formatting node Creating new operations... > Formatting node Components... > Formatting node Common attributes of components... > Formatting node Pre-defined subclasses of component... > Formatting node Creating new component types... > Formatting node Controlling where ASDF saves compiled files... > Formatting node Error handling... > Formatting node Compilation error and warning handling... > Formatting node Miscellaneous additional functionality... > Formatting node Getting the latest version... > Formatting node FAQ... > Formatting node TODO list... > Formatting node missing bits in implementation... > Formatting node Inspiration... > Formatting node Concept Index... > Formatting node Function and Class Index... > Formatting node Variable Index... > /home/pvaneynd/fakeroot/clean/git/cl-asdf//asdf.texinfo:1301: Prev field of node `FAQ' not pointed to. > /home/pvaneynd/fakeroot/clean/git/cl-asdf//asdf.texinfo:1451: This node (missing bits in implementation) has the bad Next. > /home/pvaneynd/fakeroot/clean/git/cl-asdf//asdf.texinfo:1281: Node `Getting the latest version' lacks menu item for `FAQ' despite being its Up target. > /home/pvaneynd/fakeroot/clean/git/cl-asdf//asdf.texinfo:1281: Next field of node `Getting the latest version' not pointed to (perhaps incorrect sectioning?). > /home/pvaneynd/fakeroot/clean/git/cl-asdf//asdf.texinfo:1301: This node (FAQ) has the bad Prev. This is fixed with the trivial patch: > diff --git a/asdf.texinfo b/asdf.texinfo > index 3d379e4..ddefe01 100644 > --- a/asdf.texinfo > +++ b/asdf.texinfo > @@ -1298,7 +1298,7 @@ You will find the above referenced tags in this repository. > Discussion of ASDF development is conducted on the mailing list > @kbd{asdf-devel@@common-lisp.net}. > > -@node FAQ, TODO list, missing bits in implementation, Getting the latest version, Top > +@node FAQ, TODO list, Getting the latest version, Top > @comment node-name, next, previous, up > @chapter FAQ See also http://git.debian.org/?p=pkg-common-lisp/cl-asdf.git;a=commit;h=ea3aa53b623… Groetjes, Peter - -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJLX9WFAAoJEB4VNT76eIlapncQAI+DYsBLpm9Xh11vNKuSrFJV ZitxL7/MF/u16nC6JAeN/U5mPgd8ZR4osEsupvYWKzmQvmZDvPYZ4LXV9nIWKptq +oKSb7/Gv9ft3KU6r5kgtp62/3Qf8e7oyf4NBnfZFlW+OSpWxywca5gtl7U9KvWd F34s4kK8zRvHTAbKCp06LdkDo9C4UhQwlk21M7q3ZOTuPc3JhEp5oVZXqUfi2qUb q+gx01jL0ArFR/vjuVxwbWmVgldgKzAkdIl3IVcn+PsuJBheTLzqQl2YATNRNYO0 NfMbmNEYgWm4acip+jj3juehoYELL8zCxADFQIo3KDi1fZxZ286x5B4ca0OWM9GX KV3RZIl66zq+oeZZOykI37xPlreCOD8rIdNFMqxCavu82GGRYWjtPdm1w8HGBr8O zGohjN7QZhCI3jJNO20i+ubZ8Bq1AU6TM9MAYT/6byzwOHQKQ5nXcYUqEaB6XEs+ GKXhHS6ee182LUK7AfaVV+WYgsiuubEX8mQm0X/wc+xJquTsoUMA6wxdezMWkUGs RsOuaBR2VSnVTF7RNJQXBJDb39If3jeT5QJfTfhyv9x2jTpx3ssONcfSYibU3ZKU 3N6LNevXjyQlJO/X87rVicDSCSCfX+gibxI+ZMdbksGrPJdCka1vGqKKKwbABOYr XNrBgxc85+sH/Ih7MCPg =Ul83 -----END PGP SIGNATURE-----

1 0

[asdf-devel] dependency bug?
by Robert Brown 26 Jan '10

26 Jan '10

Thanks very much for the suggestions. My example code was a simplification of a more complicated system definition, part of an project where I'm implementing Google's protocol buffers in Lisp. http://github.com/brown/protobuf/blob/master/protobuf.asd Protocol description files (suffix .proto) need to be converted into Lisp source, which is then compiled and loaded. I'm trying to get the dependencies right in one of my COMPONENT-DEPENDS-ON methods. Anyway, back to my simple example. When I use (:cl-source-file "bug2" :depends-on ("bug1")) the ASDF component for bug2 ends up with the following IN-ORDER-TO slot: ((ASDF:LOAD-OP (ASDF:LOAD-OP "bug1")) (ASDF:COMPILE-OP (ASDF:COMPILE-OP "bug1"))) I don't understand this. I believe it should be: ((ASDF:LOAD-OP (ASDF:LOAD-OP "bug1")) (ASDF:COMPILE-OP (ASDF:LOAD-OP "bug1"))) and in fact when do # touch bug1.lisp (asdf:operate 'asdf:compile-op 'bug) component bug1 is loaded (the source is compiled and then the fasl is loaded), not just compiled, before bug2 is compiled. My goal is to understand what the ASDF operations mean. LOAD-OP means "compile and load my code". However, COMPILE-OP seems to have two different meanings. COMPILE-OP means "compile" when it's a goal to perform, but it means "compile and load" when it's a dependency of another goal. Does that sound right? It's confusing me because we already have an operator that functions as "compile and load", namely LOAD-OP. bob ===================== On Fri, Jan 22, 2010 at 9:05 PM, Robert Goldman <rpgoldman(a)sift.info> wrote: > On 1/22/10 Jan 22 -6:20 PM, Robert Brown wrote: >> ASDF is behaving in a way I find mysterious. Maybe I've found a >> bug, but more likely I just don't understand ASDF dependencies. >> >> To demonstrate the problem, create the three files below. >> >> ========== >> bug.asd >> ========== >> >> (cl:in-package #:common-lisp-user) >> >> (defpackage #:bug-system >> (:use #:common-lisp #:asdf)) >> >> (in-package #:bug-system) >> >> (defsystem bug >> :components >> ((:cl-source-file "bug1") >> (:cl-source-file "bug2" >> :in-order-to ((load-op (load-op "bug1")) >> (compile-op (load-op "bug1")))))) >> >> ========== >> bug1.lisp >> ========== >> >> (defun bug1 ()) >> >> ========== >> bug2.lisp >> ========== >> >> (defun bug2()) >> >> ========== >> >> Execute the following: >> >> (load "bug.asd") >> (let ((*load-verbose* t)) (asdf:operate 'asdf:load-op 'bug)) >> >> Next, exit your Lisp session, start up your Lisp environment >> again and execute the two lines above for a second time. ASDF >> recompiles bug2.lisp. I expect it to instead just load >> bug2.fasl. >> >> Can someone explain what's going on? >> >> My example is intended to mirror the situation where you need to >> have some in-line functions or macros loaded into the Lisp system >> before another file can be compiled or loaded. Maybe I should be >> expressing this dependency differently to ASDF. > > Try this with no :in-order-to, just > > (:file "bug2" :depends-on ("bug1")) > > and see if that does what you expect.... If not, get back to us, ok? > > cheers, > r

4 8

[asdf-devel] [patch] markdown documentation tweaks
by Daniel Herring 26 Jan '10

26 Jan '10

The attached patch fixes the markdown files in asdf. Git command to apply it: # git am 0001-markdown-documentation-tweaks.patch Later, Daniel

3 5

[asdf-devel] possible clisp/win32 incompatibility
by Daniel Herring 25 Jan '10

25 Jan '10

Hi all, I'm trying to get ABLE running on mswin and hit multiple issues at once... For one, it appears the a recent version of ASDF broke compatibility with clisp on windows. If *enable-asdf-binary-locations* is t, I get "invalid :directory (clisp-2.48...)"; if it is nil, ASDF is trying to load sources from the wrong location. This could be a configuration issue on my side, but it affects both clisp 2.48 and clisp 2.45, and this configuration works fine with ccl 1.3 and 1.4. Both clisp versions work fine with the same configuration using a ~5 month old version of ASDF... I'm focusing on other bugs now. Later, Daniel

5 9

[asdf-devel] loading platform-dependent code
by Tamas Papp 24 Jan '10

24 Jan '10

Hi, I am the author of the cl-cairo2 library. Cairo itself is a graphics library, and my library provides a Lisp interface. Some of the features (eg drawing in X11, Windows or Quartz) are platform dependent. Currently, the approach of cl-cairo2 is to provide extra system definitions for these, eg an X11 user would load the systems cl-cairo2 and cl-cairo2-x11 manually. I am wondering if there is a better way to do platform-dependent loading. The solution I was thinking of was to try loading the platform dependent shared C libraries using CFFI, and set some flag (or push something to *features*) if they succeed, but if they fail, capture the condition with handler-case and just proceed with a warning. Then I could load platform-dependent code conditionally on this --- but I don't know how to do that in ASDF. Please tell me what is the "right way" to do these things (ie stuff that I put in features). Examples of libraries that load platform-dependent code conditionally with ASDF would also help. Thanks, Tamas

3 2

[asdf-devel] dependency bug?
by Robert Brown 23 Jan '10

23 Jan '10

ASDF is behaving in a way I find mysterious. Maybe I've found a bug, but more likely I just don't understand ASDF dependencies. To demonstrate the problem, create the three files below. ========== bug.asd ========== (cl:in-package #:common-lisp-user) (defpackage #:bug-system (:use #:common-lisp #:asdf)) (in-package #:bug-system) (defsystem bug :components ((:cl-source-file "bug1") (:cl-source-file "bug2" :in-order-to ((load-op (load-op "bug1")) (compile-op (load-op "bug1")))))) ========== bug1.lisp ========== (defun bug1 ()) ========== bug2.lisp ========== (defun bug2()) ========== Execute the following: (load "bug.asd") (let ((*load-verbose* t)) (asdf:operate 'asdf:load-op 'bug)) Next, exit your Lisp session, start up your Lisp environment again and execute the two lines above for a second time. ASDF recompiles bug2.lisp. I expect it to instead just load bug2.fasl. Can someone explain what's going on? My example is intended to mirror the situation where you need to have some in-line functions or macros loaded into the Lisp system before another file can be compiled or loaded. Maybe I should be expressing this dependency differently to ASDF. bob

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

asdf-devel