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
