On Sun, Jun 7, 2015 at 6:09 AM, Mark Evenson evenson@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.
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.
On 6/7/15 Jun 7 -10:44 AM, Faré wrote:
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.
This might help:
(mapc #'(lambda (x) (eval `(trace ,x))) asdf::*default-source-registries*)
and
(trace asdf/source-registry:flatten-source-registry)
before you do the call to INITIALIZE-SOURCE-REGISTRY.
IIUC, that will show you what configuration elements are where. But it doesn't trace the actual search of the directories.
There's a bunch of collector functions in here, but there's also a lot of unnamed functions and a lot of second-order programming, which makes tracing it pretty complicated.
If I get a chance tomorrow, I'll set up an example and try to figure out how to see ASDF actually probing directories.
Cheers, r