Introspecting source registry

Robert Goldman rpgoldman at
Sun Jun 7 15:37:29 UTC 2015

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]:

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

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
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


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.


More information about the asdf-devel mailing list