>On Sunday 25 March 2001 13:30, Brian Rice wrote:
>
>>  Can anyone give a good estimate of what it would take to make a simple
>>  tool for this, maybe extending the BlockContext protocol to delegate to an
>>  AudibleDebugger, and maybe stepping down execution speed?
>
>I can't make an estimate, but I'd consider a couple of things:
>
>(1) enqueue sound requests for a separate process to deal with rather than
>making your process wait for the sound to be produced

Yes, that's a good suggestion. I wonder how short of a cycle sound 
requests can get? I suppose it might be possible to have a block run 
on each bytecode as its executed. No wait, that'd be to darn slow, 
obviously requiring InterpreterSimulator.

>(2) you could make wrappers for CompiledMethods by copying them and editing
>the bytecodes so that they could (for instance) make sounds. This way you
>wouldn't have to change the source every time you turned a sound on or off.

I hadn't thought of that, but then again I've been a little wary of 
messing with compiled methods anyway. Does anyone have experience 
with this? Are there dangerous issues in tangling with the VM that 
way?

>Terry Raymond's Crafted Smalltalk Debugger for VisualWorks does this (he
>calls these edited methods "method probes"). I'm sure that there's sample
>code (at least for VW) out there.

Okay, I'll search for something on that. This is definitely a side 
project for me, but it has hobby hacker interest.

>--
>Ned Konz
>currently: Stanwood, WA
>email:     ned at bike-nomad.com
>homepage:  http://bike-nomad.com