[PATCH] Re: Bug 68015: Variables/Watch Window closes on first view

Vladimir Prus ghost at cs.msu.su
Tue Jun 7 08:49:06 UTC 2005


On Monday 06 June 2005 21:22, Richard Dale wrote:

> > Ok, I've found 'ruby' installed here and tried the debugger with this
> > program:
> >
> > threads = []
> > 6.times { |i|
> >   threads << Thread.new(i) {
> >     raise "Boom!" if i == 3
> >     puts i
> >   }
> > }
> > threads.each {|t| t.join }
> >
> > I set breakpoint on the "raise" line and run it. The framestack widget
> > shows some threads, one is opened and others are closed. When I click on
> > a "+" near closed thread, the framestack windows disappears and the first
> > frame of the selected thread appears to be selected. That's behaviour my
> > patch is trying to fix for C++ debugger.
>
> Ok - interesting! But welcome to ruby, even if it's only to help with
> improving C++ support..

Thanks :-)

> I spent about 3 months on the ruby debugger - 1 month adding ruby support,
> 1 month fixing problems with the debugger logic and another month improving
> the introspection of the ruby bindings. It seemed to me that jbb had done a
> really good job with the original implementation, but subsequent
> maintainers didn't understand the code as well as he did and the code has
> suffered from some half assed fixes. Certainly some of the code in the 
> variables widget is much too complicated. 

Probably so. 

> If I personally was trying to 
> improve gdb support, I would do it by just porting the ruby debugger code
> back to gdb. Even if you don't do this, you can use the ruby debugger as a
> reference implementation for behaviour as you've done above.

The problem with "just porting to ruby" debugger is that there are also 
ruby-specific parts that would have to be removed. I think I'd rather
look at ruby code as reference. 

- Volodya









More information about the KDevelop-devel mailing list