Having banged my head against D's rampant inconsistency and almost but
not quite total dissimilarity to awk,
I think even acid's intemperate lingo is preferable.
OTOH, the idea of chucking ANY language interpreter into a kernel
seems wrong too.
Yes, dtrace dtrace/D provide great capabilities (trust me: I
administer hairy systems and dtrace has definitely helped us),
and some of the ideas are good, but the whole thing is a mess.
Maybe I'm missing something,
but wouldn't be slightly nicer to have something like a set of dynamic
probes
which queue up blobs of data up for userland code to do the hairy
lifting on?
Also, you don't want a debugger, you want a data analyser: awk, maybe?
Dave.
On 28 Oct 2009, at 02:38, Jeff Sickel wrote:
Yes please. I'd hate to see the Plan 9 ideas turned into subjecting
some unfortunate programmer(s) with having to write hundreds of
thousands of probes instead of following the more acid based approach.
dtrace has it's place. And as you've said, eye candy wins. But I
still think there's a way to use acid and the linker to provide the
kinds of hooks you want for debugging.
-jas
On Oct 27, 2009, at 9:23 PM, ron minnich wrote:
One other thought on this line. The dtrace tools include a kernel
module which understands the dtrace language. Maybe an alternative
plan 9 approach is a kernel driver which understands acid.
ron
