3.4 showstopper

[Richard Dale]

On Monday 15 January 2007 21:54, Andreas Pakulat wrote:
> On 15.01.07 23:28:59, Alexander Dymo wrote:
> > Hi! Please postpone 3.4 tagging (which was planned for today).
> > We apparently have a bug in Ruby debugger. Sometimes debugger
> > doesn't stop on breakpoints, sometimes it complains about broken socket
> > connection with KDevelop. Richard and Andreas know more and try
> > to fix that.
>
> So, one problem is that simple ruby projects provide their own dialog
> for setting main app and arguments which doesn't provide. This is a
> problem when requiring another file from the one that is beeing
> debugged. This doesn't affect the special Ruby-Run-Action (that one
> always uses the directory of the .rb file).
>
> For kde-ruby projects the thing is different, it uses Automake project,
> but it needs to use the global run options. This is all pretty messy,
> because the debugger will use the .rb file set in the ruby options, but
> the cwd from the run options. A simple way to solve would be to make the
> debugger not use runDirectory function from project manager, but to read
> the option set in ruby options. Richard wanted to think about this a bit
> more.
I think for kde ruby projects we need two globalcwd config options, one for 
building the C++ stub for finished and installed projects via the project run 
options, and another via the ruby project options for when you are developing 
and debugging a ruby project. I think apaku's patch for adding a globalcwd 
field to the ruby options is a good idea. For both scripting and kde ruby 
projects it should be possible to get the directory from the ruby project 
options as /kdevscriptproject/run/globalcwd from the project dom. So I think 
the code that sets up the command for invoking the ruby script, or a ruby 
script via the debugger shouldn't use project()->runDirectory() and should 
use the kdevscriptproject globalcwd path instead.

The attached patch uses /kdevscriptproject/run/globalcwd  to build the ruby 
script and ruby debugger commands. That should work for both kde ruby 
automake based projects, and for ruby scripting ones. Then when a C++ top 
level stub is built for a kde ruby project, it will use the automake run 
options details instead.

> The other things seem to be problems of the debugger, it wasn't change
> lately.
>
> The rdb toolview vanishes when stopping the debugger, after that I can't
> debug and break on a simple project.
I don't know why this no longer works. When I wrote the debugger two years ago 
it seemed more reliable than it is now, and I'm not exactly sure what has 
changed.

> I need to start the debugger twice in a simple ruby project to stop at a
> breakpoint. The first start just walks through everything and the
> breakpoint indicator gets "activated" (i.e. from grey to red)
>
> Somebody with some knowledge about the ruby debugger needs to look into
> these last two.
Yes, ok but I don't understand why it seems to work and not work at random.

I think the use case for kde ruby projects needs to be considered for 
kdevelop4 even though we will be using cmake, the issues are similar. And I 
would really like the KDE Python guys to be putting some effort into 
KDevelop4 and these issues, so we can have a common approach for non-C++ 
languages. Leaving it up to Eric4 and Detlev Offenbach to sort out single 
handedly just doesn't seem good enough to me.

-- Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rubydebugger.patch
Type: text/x-diff
Size: 11699 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20070116/039f9c50/attachment.bin>