Introspecting source registry

[Robert Goldman]

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.
> 
> [1]:
> https://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searches-for-systems

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