Re: [FR-devel] The current status of the FreeRIDE

[NISHIO Mizuho]

> I'm glad you are also paying attention to YARD. I elected myself as the 
> owner of the Debugger Module in FreeRIDE but I definitely welcome a 
> partner in this endeavour. Why don't you add your name next to mine in 
> the Debugger Project at
> http://www.rubyide.org/cgi-bin/wiki.pl?FreeRIDE_Projects
As I said in this ML, I can't continue to contribute to FreeRIDE.
I think that the FreeRIDE's developer who is listed in Wiki's Page 
should spend his/her time on FreeRIDE consistently unlike me.
 
> I have investigated two approaches for the debugger:
> a) wrap the standard debug.rb basically redirecting input and output 
> using Open3 and mimicing keyboard input as well as analyzing debugger output
> 
> b) wrap YARD which is nothing more than a dRuby based version of the 
> standard debug.rb
> 
> b) is much more promising because it is the only way to have a full 
> programmatic access to the internal variables of both the debugger (to 
> access and process frames, list of threads, breakpoints,....) and the 
> running application that is being debugged.
Currently, Ruby's "require" has global effect and we can't 
enclose its effect. As the result of it, the debug-process
must be different from the FreeRIDE's IDE process.

I also hits on a) and b). We should adopts b) as you said.
Because we can't use fork as widely as Socket/dRuby, 
b) is better than a) in terms of multi-platform. And in b),
we can control debug-process more easily.
 
> I talked to Hiroshi NAKAMURA (YARD author) and YARD as it is today 
> doesn't allow much of the things I just mentioned before. The Front 
> class of debuggee.rb has to extended to give access to debuggee.rb 
> internal variables as well as the variables of the application. But it 
> is feasible.
I have just sent the mail about it to the author.
If the author are not willing to rewrite the YARD,
we must rewrite YARD equiped with the functions which we need?

> 1) There are many things we can in FreeRIDE do without FOX. The debugger 
> is a prefect example. Let's have something working and then UI 
> integration won't be a problem.
>
> 2) In my view FreeRIDE is more or less the application that started the 
> discussion about Rouge and the universal Ruby GUI. Because we badly need 
> this unversal GUI in FreeRIDE. The problem is that almost all the active 
> developers in FreeRIDE are also the main actors on the Rouge DL. So my 
> guess is that both project we'll actually make progress side by side.
I agree.
For the time being, I am going to spend my time on
the thing upon which GUI library's influence is small, 
the Debugger and Source Browser.
 
******************************
NISHIO Mizuho 
e-mail address@hidden