asdf-devel

asdf-devel@common-lisp.net

1376 discussions

Fwd: Introspecting source registry
by Faré 08 Jun '15

08 Jun '15

On Sun, Jun 7, 2015 at 6:09 AM, Mark Evenson <evenson(a)panix.com> wrote: > With asdf-3.1.4, how do I introspect the current state of source > registry configuration? I need to debug a remote user's ASDF > configuration on a machine which I don't have access to, so I would like > to have ASDF output the current source registry configuration search > state. Problematically, the behavior documented in section 8.1 doesn't > seem to be working as described on the user's machine. And this > behavior seemingly changes between "patch level" ASDF releases > especially on marginal platforms like Windows, digging up the "correct" > version of the manual isn't so easy either. > > [1]: > https://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searc… > > The contents of ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY* provides a > hashtable of systems that ASDF has located, but doesn't help me figure > out where ASDF *might* have searched for things. For output > translations the return value of (ASDF:INITIALIZE-OUTPUT-TRANSLATIONS) > gives me enough information for output translations, so it would be nice > to have something equivalent for the source registry. Since I suppose > that all of the behavior specified in section 8.1 is not easily > transcribed as a s-expr, my request may not be trivial to implement, but > in lieu of some similar mechanism, I am really having problems with > debugging ASDF behavior in a particular instance. > > Additionally, what is the behavior of ASDF when the $XDG_* environment > variables are not set, as is seemingly the case on a stock Windows > environment? Are these configuration steps just skipped? > 1- Look for asdf::*source-registry-parameter* which will tell you what ultimate overrides were used, if any. 2- Follow the trail of items in asdf::*default-source-registries*. So first, an environment variable CL_SOURCE_REGISTRY, then a configuration file ~/.config/common-lisp/source-registry.conf (beware: may be relocated via XDG, and will be somewhere else on Windows), and the corresponding .conf.d/ directory, then a hierarchy of system directories. It can be somewhat convoluted, so everyone gets a chance to tweak the configuration (lisp implementation packager, system administrator, local administrator, user). But usually, no one uses any of these mechanisms except the user. You're using asdf-3.1.4. Its documentation should be what's online right now, but is also in the release branch of our git repo. NB: are you on Windows? Things suck more on Windows, and are going to change in slightly incompatible ways with asdf 3.1.5 (hopefully making them suck a bit less). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Welfare: when you love strangers so much you're willing to have government steal money from another stranger to help them out.

2 1

Introspecting source registry
by Mark Evenson 07 Jun '15

07 Jun '15

With asdf-3.1.4, how do I introspect the current state of source registry configuration? I need to debug a remote user's ASDF configuration on a machine which I don't have access to, so I would like to have ASDF output the current source registry configuration search state. Problematically, the behavior documented in section 8.1 doesn't seem to be working as described on the user's machine. And this behavior seemingly changes between "patch level" ASDF releases especially on marginal platforms like Windows, digging up the "correct" version of the manual isn't so easy either. [1]: https://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searc… The contents of ASDF/SOURCE-REGISTRY:*SOURCE-REGISTRY* provides a hashtable of systems that ASDF has located, but doesn't help me figure out where ASDF *might* have searched for things. For output translations the return value of (ASDF:INITIALIZE-OUTPUT-TRANSLATIONS) gives me enough information for output translations, so it would be nice to have something equivalent for the source registry. Since I suppose that all of the behavior specified in section 8.1 is not easily transcribed as a s-expr, my request may not be trivial to implement, but in lieu of some similar mechanism, I am really having problems with debugging ASDF behavior in a particular instance. Additionally, what is the behavior of ASDF when the $XDG_* environment variables are not set, as is seemingly the case on a stock Windows environment? Are these configuration steps just skipped? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

program-op is nice!
by Attila Lendvai 06 Jun '15

06 Jun '15

Fare, your asdf/uiop image-dumping machinery is great! with only a few minutes of trying i've already made an exe for the dwim.hu service that seems to just work. i'm very pleasantly surprised, because it gets rid of the entire hu.dwim.build complexity, and is now even platform independent... thank you! :) FTR, the change is here: http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.home;a=commitdiff;h=2… it all seems to just work, but i have a hard time telling asdf where to put the resulting exe. the :build-pathname arg of defsystem errors with absolute paths (which sounds reasonable), but then it's merely the filename of the exe. my problem is that it gets saved into the fasl cache, which i cannot calculate from the shell script side of the build script to mv the file to its final place. is there some doc or test that i have missed? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You think you know when you can learn; are more sure when you can write; even more when you can teach... but certain when you can program.” — Alan Perlis

2 3

[Asdf-devel] Registering preloaded systems for Quicklisp/ASDF
by Dave Cooper 06 Jun '15

06 Jun '15

Hi, I know this has been discussed, but what is currently the best practice for registering a preloaded system after loading Quicklisp? That is, I have a pre-built image with some Quicklisp/ASDF systems in it, which were loaded through so-called monolithic-fasls (now known as compile-bundles). So the pre-built image doesn’t itself have ASDF or Quicklisp. A downstream user then loads Quicklisp and ASDF (I take steps to ensure that they are loading the matching version of ASDF and Quicklisp as was used to build the image). Now I need to do something to tell Quicklisp and ASDF that certain systems are already loaded in this image, so it won’t try to re-load them as depended-upon systems. In this specific case, I don't want it to try to fetch and reload Gendl when the user does (ql:quickload ...) on an application which :depends-on :gendl (because gendl is already built into this image). asdf/find-system:register-preloaded-system seems like it should be the answer if we’re talking about plain ASDF, because it will prevent ASDF from raising a “missing-component” error for the system in question, if some other system :depends-on it and yet no source code is found. But in my case I can’t guarantee that “no source code is found.” The source might be there in the quicklisp dist directory. So apparently I need something stronger than register-preloaded-system? Or something else? -- My Best, Dave Cooper

3 21

Re: How would you feel...
by Robert P. Goldman 04 Jun '15

04 Jun '15

Andreas Davour wrote: > On Wed, 27 May 2015, Faré wrote: > > [snip] >>> My SBCL is at 3.1.3. I think 3.1.4 is solid enough that it should be >>> updated there. >>> >> I've bugged SBCL hackers many time since last october, to no avail. > > But remember hwo it looks like from the outside, though. > > You are changing the third number, which will look like a patch to a > minor revision. They probably wont bother with updating (if it's any > amount of work) unless they see 3.2 or 4.0 is my guess. That's how I > would think. Actually, if I was them, I wouldn't bother updating until I saw 3.2.1! ;-) But seriously, waiting until the first bugfixes show up doesn't work well unless *somebody* runs the initial release and tests it in actual day-to-day use. It would be nice to figure out a way that ASDF could work nicely with the implementations so that implementors have an easy option to use the latest ASDF patch version day-to-day and see how well it plays with the latest version of the CL implementation. Cheers, r

2 2

Metadata check [WAS Re: How would you feel...]
by Robert P. Goldman 29 May '15

29 May '15

Faré wrote: >> OTOH, it's probably A Bad Thing if you depend on a system for something >> you are doing, and don't know what license it uses. >> > Well, we haven't codified any format for :license. I suppose we could adopt > the nomenclature used by Debian. Except what in Lisp circles goes by > the name "MIT" > (as notably used by ASDF itself) in Debian-speak is called "Expat". > Also, we don't have a story for multi-licensed code either. > For instance, I have code under LLGPL or bugroff, or BSD or bugroff. I didn't mean that we needed a codified format. I just meant that if you are using a system, and the humans involved don't know if your usage is legal (e.g., are you using pure GPL in a commercial application? are you delivering source for libraries when you deliver your code? etc.), that's a Bad Thing. Given that :LICENSE is currently arbitrary string valued, we can just make a string that indicates multiple possible licenses. We could certainly add some standard values (keywords?) for common licenses, and allow people to specify a list of such values (and an optional string), but I'm not sure what we would gain by this. I don't yet see a use case for machine-introspection on the :license, but I'm open to suggestions. > >> But that's why I created a special class of CONDITION for this case -- >> so you can muffle it if you don't care. It would be nice if there was >> some way to detect the distinction between internal systems (fix them!) >> and external systems (muffle). >> > At ITA, we started with muffling the external systems, but quickly > enough decided to fix them instead; code quality matters for libraries > we depend on, too. But we did have a list of style-warnings to muffle > and some of them were based on dependencies indeed. For now a programmer could match the name of the system in my MISSING-METADATA condition, and use that to make his or her decision about muffling. > >> I'll push my topic branch today. It needs a test script, and I'd like >> to make it skip signaling on "slashy" subordinate systems, but I'd love >> comments in the meantime. >> I pushed this as the QL-metadata-warning topic branch. Best, r

2 1

Re: Metadata check [WAS Re: How would you feel...]
by Robert P. Goldman 28 May '15

28 May '15

Erik Huelsmann wrote: > Hi, > > In various occasions I have seen that you plan to make the metadata > arbitrary string or even general values. While I think that's okay, to > provide lists of suggested values so that use of the values gets easier > and if most people use the suggested values, the value system could end > up centralized around those values. In my opinion, that would add value, > especially for machine interpretation. Note that this isn't something that I have planned. It is something that is the de facto current standard. To date, all the metadata are given simply as strings, and they aren't of use for other than human inspection. If someone would suggest a list of keywords for the licenses, we could certainly incorporate that in some fashion. But it would complicate any introspection code. Presumably that code would be taking the metadata and formatting it for the user. So it would now have to consider the possibility of keywords, which should be translated, and probably lists of keywords (per Fare's email), as well as strings. That would complicate the work of anyone trying to make use of the code. Now, if there was something where someone might want to say: (find :gnu-gpl (mapcar #'asdf:component-license my-systems)) [actually, that wouldn't work because of the possibility component-license is list valued] and do something with the results, then it might be worth making such an effort. But I haven't seen any "pull" for such a feature in ASDF. cheers, r > > Regards > > Erik > > On May 27, 2015 8:54 PM, "Robert P. Goldman" <rpgoldman(a)sift.net > <mailto:rpgoldman@sift.net>> wrote: > > Faré wrote: > >> OTOH, it's probably A Bad Thing if you depend on a system for > something > >> you are doing, and don't know what license it uses. > >> > > Well, we haven't codified any format for :license. I suppose we > could adopt > > the nomenclature used by Debian. Except what in Lisp circles goes by > > the name "MIT" > > (as notably used by ASDF itself) in Debian-speak is called "Expat". > > Also, we don't have a story for multi-licensed code either. > > For instance, I have code under LLGPL or bugroff, or BSD or bugroff. > > I didn't mean that we needed a codified format. I just meant that if > you are using a system, and the humans involved don't know if your usage > is legal (e.g., are you using pure GPL in a commercial application? are > you delivering source for libraries when you deliver your code? etc.), > that's a Bad Thing. > > Given that :LICENSE is currently arbitrary string valued, we can just > make a string that indicates multiple possible licenses. > > We could certainly add some standard values (keywords?) for common > licenses, and allow people to specify a list of such values (and an > optional string), but I'm not sure what we would gain by this. > > I don't yet see a use case for machine-introspection on the :license, > but I'm open to suggestions. > > > > >> But that's why I created a special class of CONDITION for this > case -- > >> so you can muffle it if you don't care. It would be nice if > there was > >> some way to detect the distinction between internal systems (fix > them!) > >> and external systems (muffle). > >> > > At ITA, we started with muffling the external systems, but quickly > > enough decided to fix them instead; code quality matters for libraries > > we depend on, too. But we did have a list of style-warnings to muffle > > and some of them were based on dependencies indeed. > > For now a programmer could match the name of the system in my > MISSING-METADATA condition, and use that to make his or her decision > about muffling. > > > >> I'll push my topic branch today. It needs a test script, and I'd > like > >> to make it skip signaling on "slashy" subordinate systems, but > I'd love > >> comments in the meantime. > >> > > I pushed this as the QL-metadata-warning topic branch. > > Best, > r >

2 1

Should we abandon support for IMAGE ops on Lispworks?
by Robert P. Goldman 27 May '15

27 May '15

I'm starting to be inclined to suggest we abandon support for this kind of operation on Lispworks. Lispworks does not provide a portable means to invoke from the command-line, indeed invocation from the command line is *IMPOSSIBLE* unless you pay extra for a Professional license. Also, image-dumping is only possible if you have a Professional license. What's even The Right Thing here? Should we be checking to see if image creation is possible? And how do we capture the fact that some of our stuff requires that the user create a LW image that can be invoked from the command line w/o starting up the IDE? I really wish they would ship with a simple command-line executable... Cheers, r

2 1

How would you feel...
by Robert P. Goldman 27 May '15

27 May '15

About holding the release briefly while I negotiate with Xach about metadata? Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well. I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata. Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly. I'll put in a topic branch for this. cheers, r

2 6

Getting failure on LW 6 and 7 on Mac and Linux on test-run-program
by Robert P. Goldman 27 May '15

27 May '15

Here's the error: TEST ABORTED: Undefined function LISP-INVOCATION/IMPLEMENTATIONS::INVOKE-LISP-VIA-SCRIPT called with arguments (:CROSS-COMPILE NIL :LOAD "/Users/rpg/lisp/asdf/test/make-hello-world.lisp" :EVAL "(asdf-test::make-hello-image)" :RUN-PROGRAM-ARGS (:INPUT NIL :IGNORE-ERROR-STATUS T :OUTPUT (#<Synonym stream to HARLEQUIN-COMMON-LISP:*BACKGROUND-OUTPUT*> :LINEWISE T :PREFIX "stdout: ") :ERROR-OUTPUT (#<Synonym stream to HARLEQUIN-COMMON-LISP:*BACKGROUND-OUTPUT*> :LINEWISE T :PREFIX "stderr: "))). Investigating, but wanted to pass this on for now. Cheers, r

2 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