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?
cheers, r
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)
then again, if you use the newfangled source-registry-cache, you can find ~/common-lisp -name .cl-source-registry.cache
I'm not sure what you want to debug, so it's hard to tell how to help you.
Also, behavior wrt recursing or not into directory symlinks is not consistent from one implementation to the next, so beware.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Year 1917. The granddaughter of a Decembrist hears noise coming from the street and sends a servant to check what's going on. The servant promptly returns, announcing: - It's the revolution, Madam ! - Oh my, the revolution ! My grandfather dreamt of the revolution! And what do those revolutionaries demand? - They ask that there be no more wealthy people, Madam. - That is strange... My grandfather wanted that there be no more poor people!
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?"
cheers, r
—♯ƒ • 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
-
Faré -
Robert Goldman