Ned Konz wrote:
> Michael Neumann wrote:

> >> One of the reasons that resume semantics are interesting in Smalltalk is
> >> that you can (for instance) pop up a debugger on an exception, interact
> >> with the system, and then resume execution of the program.
> > 
> > That should be possible with Ruby, too.
> 
> How would that be possible with no resume? Imagine wrapping a whole program 
> that lacks explicit rescue clauses inside a single exception handler that 
> brings up a debugger. If the stack contexts have already been thrown away 
> by the unwind mechanism, how are you going to do anything but retry the 
> _whole program_?

You can define a tracing method (set_trace_func), that gets called after each 
line, method call ....
A better way is to use AspectR (AOP) that lets you easily wrap all methods. Here 
you can surround the method by a rescue class and popup a windows if it fails, call the 
same method a second/third... time. No code has to be changed!


> But this very model works (well) in Smalltalk -- by default the global 
> exception handler pops up a window that allows you to enter a debugger, 
> retry, or abort the thread.
> 
> >> I guess that Ruby isn't yet aimed at the kind of long-running and
> >> interactive systems that Smalltalk excels at. For instance, I used to
> >> write factory machine control software in Smalltalk. Without stopping the
> >> machine, we could load new versions of methods into the system, stop
> >> threads, debug them, and resume them, and otherwise maintain the system
> >> without bringing it down.
> > 
> > Possible with Ruby, too.
> 
> Even pausing/single-stepping/resuming arbitrary threads? How?

Should be doable with class Thread. Don't know exactly.
Having a look at debug.rb shows that it must be possible.
There is e.g. "stop", "resume", "suspend"...

> > Smalltalk runs a debugger by default (I guess). Ruby do not.
> > That's because Smalltalk is mostly an IDE + language, where Ruby is just
> > an interpreter.
> 
> I understand that. But given Ruby's reflection and GUI abilities, why 
> wouldn't a native Ruby IDE be a good thing to have?

I agree with you, that it would be nice to have.


> > But it should be possible to load a debugger at runtime. Just call
> > anywhere in a Ruby program "require debug.rb". That should do it.
> 
> Good, I'll try that. How does the debugger actually set breakpoints? 

As far as I know it uses set_trace_func.

> Does it wrap the method in question, is there a method that you can call for a 
> breakpoint (as in Smalltalk), or is there some flag that the interpreter 
> has to check for every instruction (as is the case in Perl)?

The latter one.
set_trace_func gets called on every line, method call...

> In Perl, running with the debugger has a signficant performance penalty 
> because of the check for breakpoints. Given Ruby's ability to wrap methods, 
> I could imagine that a Ruby debugger wouldn't need to slow down any.

Ruby's debugger is slow, too. Probably even slower than Perls.
Maybe there are some improvements in Ruby 1.8.


Regards,

  Michael

-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de