On 6/7/15 Jun 7 -5:09 AM, Mark Evenson 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.

Yes, the behavior of ASDF has changed a bit within the series of 3.1.4.x pre-release versions. There was a bug in the treatment of XDG configuration directories that we have recently fixed.

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.

I'm afraid I'm not the authority on this. Faré is the authority: I have stayed with *CENTRAL-REGISTRY* precisely because I can control it more, and it's easier to introspect. And I don't have the issues of scale that forced Faré's more efficient implementation.

Here are some thoughts based in inspection of the source:

Perhaps tracing ASDF/SOURCE-REGISTRY:register-asd-directory would help? That seems to do the business inside COMPUTE-SOURCE-REGISTRY.

I note that COMPUTE-SOURCE-REGISTRY iterates over the return value of FLATTEN-SOURCE-REGISTRY. I wonder if it would be appropriate to refactor this code so that it's of the form:

(mapc #'HELPER-FUNCTION (flatten-source-registry parameter))

instead of

(dolist (entry (flatten-source-registry parameter)) yadda yadda yadda)

if we did that, one could trace HELPER-FUNCTION to debug. Right now, since the DOLIST is effectively open-coded, there's no obvious thing to trace.

Similarly, there's a very big LAMBDA passed as an argument to REGISTER-ASD-DIRECTORY. If that was replaced with a named function, one could trace it. Right now it's not easy to debug.

But I'm not sure whether the action occurs there or in FLATTEN-SOURCE-REGISTRY. So perhaps tracing PROCESS-SOURCE-REGISTRY is the important step.... F-S-R seems to do a lot more than I associate with the name "FLATTEN".

More generally, I think ASDF should be enhanced to provide some kind of registry debugging that does *NOT* require the programmer to look into non-exported functions. I.e., some form of VERBOSE behavior that one could turn on in order to see a log of directories traversed. I'm open to suggestions about that (although such surgery probably will have to wait until after 3.1.5 is released). Then one could do something like

(INITIALIZE-SOURCE-REGISTRY NIL ;; ????? :VERBOSE T)

and get more information.

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?

The behavior of the XDG code has changed substantially recently, so it's hard to answer this question without knowing exactly what version of ASDF your client has.

Best, r