—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On Mon, Aug 24, 2015 at 3:55 PM, Robert Goldman rpgoldman@sift.net wrote:
On 8/24/15 Aug 24 -2:14 PM, Faré wrote:
On Mon, Aug 24, 2015 at 2:48 PM, Robert Goldman rpgoldman@sift.net wrote:
I have always used ASDF:*CENTRAL-REGISTRY*, with some local code that grovels over source trees.
I'd love to stop maintaining the tree groveler, and move to the DSL, but I have never understood how you debug the DSL when ASDF fails to find your system.
With *CENTRAL-REGISTRY* you pretty much pprint the variable, eyeball it, and it's usually pretty easy to see whether a directory is missing.
But what do you do if you use the DSL? The last time I tried to use the DSL, I found myself using the inspector to grovel over internal-to-ASDF hash tables, which wasn't very pleasant.
Is there a "debugger API" to the new source configuration search? E.g., can we dump the hash-table in a human readable (sorted, formatted way?)? can we trace something to see how ASDF is populating the hash table? *)
You can (alexandria:hash-table-alist asdf/source-registry::*source-registry*)
or for a higher-level view, you can (asdf/source-registry:flatten-source-registry)
Exactly the answer I was looking for!
I will add this to the function index in the ASDF manual.
Maybe add a FAQ that's something like "what do I do if ASDF cannot find a system I think it should?"
For those whose asdf can't locate alexandria, here is another form that you might find more useful, to list all registered .asd file sorted by system name: (sort (loop for p being the hash-values of asdf::*source-registry* collect p) 'string< :key 'pathname-name)
PS: if you have questions like these, that aren't answered by the manual, the right thing to do is to ask on the mailing-list, not to throw hands in frustration.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The secret of change is to focus all of your energy, not on fighting the old, but on building the new. — Dan Millman