Re: [RDT-Dev] debugger: stepReturn fix, next+, step+ support
Werner Schuster (murphee) wrote: Martin Krauskopf wrote: BTW it seems that there will be something like jruby-debug soon. I hope I will have enough time to participate a lot on this piece. Might be another debug-commons child or jruby-extras, does not matter to much. jruby-debug would be good - BTW: yesterday I found out about a problem in JRuby and set_trace_func based debugging: if JRuby's JIT is turned on, this won't work, because the code that the JIT emits doesn't call the trace function. I guess, there's not much to do about this before 1.0, but I guess filing this as a bug would is necessary for post-1.0. If we would be able to come with jruby-debug soon (month, two?) I thing that set_trace_func should be completely deprecated as a technique for debugger implementation. It is quite unusable for any large applications like, yup, rails. But should be supported for other interpreters as a fall-back. Also it seems that DLTK people would join us in the future with debug-commons with DBGp implementation. Future seems quite good for ruby-debugging thanks to your initial contribution Markus! ;) Have they committed to sharing their DBGp implementation? Andrey Platov wrote me that they would. But in the further future. They do not have enough time currently. I think they are quite open-minded folks. CCing Andrey then to talk for him. They have a Ruby version in their CVS but it's not based on the RDT/eclipse-debug code. If there's an interest: I've been working on my own Ruby DBGp implementation (with the RDT code as backend) - it's not complete, and I'm still trying to get it to connect with DLTK, but it's coming along. This is exactly the problem. We are all working on the same again and again. I think we could cooperate and have something we could use all. Then when there is bug, one of us just fix it and everybody has it for free. Then we can concentrate to work on another advanced features wrt. to Ruby debugging. Probably debug-commons could be the place to start? :) And in the future it could become something like Java has in the JPDA, maybe... m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
[RDT-Dev] debugger: stepReturn fix, next+, step+ support
Hi again,
I'm going to merged support of next+ and step+ into ruby-debug-ide (will
be 0.1.3). This is a new feature added by Kent into ruby-debug 0.9.1:
http://www.datanoise.com/articles/2007/4/3/ruby-debug-version-0-9-1-has-been-released
I've also notice that RubyDebugCommandFactory#createStepReturn uses
'next' command. It should use 'finish' command instead I believe. But
maybe I've missed some hidden purpose.
Attaching possible patch containing createStepReturn fix as well as
possible next+/step+ utilization.
So let me know if you commit the fix to createStepReturn into RDT so I
may proceed with next+/step+ merge.
Thanks,
m.
Index: src/org/rubypeople/rdt/internal/debug/core/RubyDebugCommandFactory.java
===
--- src/org/rubypeople/rdt/internal/debug/core/RubyDebugCommandFactory.java
(revision 2389)
+++ src/org/rubypeople/rdt/internal/debug/core/RubyDebugCommandFactory.java
(working copy)
@@ -24,14 +24,22 @@
return frame + frame.getIndex() + ; next ;
}
+ public String createForcedStepOver(RubyStackFrame frame) {
+ return frame + frame.getIndex() + ; next+;
+ }
+
public String createStepReturn(RubyStackFrame frame) {
- return frame + frame.getIndex() + ; next 1 +
(frame.getIndex() + 1) ;
+ return frame + frame.getIndex() + ; finish;
}
public String createStepInto(RubyStackFrame frame) {
return frame + frame.getIndex() + ; step;
}
+ public String createForcedStepInto(RubyStackFrame frame) {
+ return frame + frame.getIndex() + ; step+;
+ }
+
public String createReadThreads() {
return th l;
}
Index: src/org/rubypeople/rdt/internal/debug/core/ICommandFactory.java
===
--- src/org/rubypeople/rdt/internal/debug/core/ICommandFactory.java
(revision 2389)
+++ src/org/rubypeople/rdt/internal/debug/core/ICommandFactory.java
(working copy)
@@ -16,10 +16,14 @@
public String createStepOver(RubyStackFrame stackFrame);
+ public String createForcedStepOver(RubyStackFrame stackFrame);
+
public String createStepReturn(RubyStackFrame stackFrame);
public String createStepInto(RubyStackFrame stackFrame);
+ public String createForcedStepInto(RubyStackFrame stackFrame);
+
public String createReadThreads();
public String createThreadStop(RubyThread thread);
@@ -37,4 +41,4 @@
public String createCatchOn(IBreakpoint breakpoint) throws
CoreException;
public String createLoad(String filename);
-}
\ No newline at end of file
+}
Index:
src/org/rubypeople/rdt/internal/debug/core/ClassicDebuggerCommandFactory.java
===
---
src/org/rubypeople/rdt/internal/debug/core/ClassicDebuggerCommandFactory.java
(revision 2389)
+++
src/org/rubypeople/rdt/internal/debug/core/ClassicDebuggerCommandFactory.java
(working copy)
@@ -24,6 +24,11 @@
return th + ((RubyThread) stackFrame.getThread()).getId() +
; next;
}
+ public String createForcedStepOver(RubyStackFrame stackFrame) {
+ // not supported by Classic Debugger
+ return createStepOver(stackFrame);
+ }
+
public String createStepReturn(RubyStackFrame stackFrame) {
return th + ((RubyThread) stackFrame.getThread()).getId() +
; next + (stackFrame.getLineNumber() + 1);
}
@@ -32,6 +37,11 @@
return th + ((RubyThread) stackFrame.getThread()).getId() +
; step;
}
+ public String createForcedStepInto(RubyStackFrame stackFrame) {
+ // not supported by Classic Debugger
+ return createStepInto(stackFrame);
+ }
+
public String createReadThreads() {
return th l;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] debug-commons established
Martin Krauskopf wrote: Hi, so the project is alive: http://rubyforge.org/projects/debug-commons/ Hi again, sorry for constant disturbing :) But more to set up on. I've started filling tasks and bugs I'm working on directly to debug-commons tracker[1] so we pretend duplicating the effort. I've also committed initial ChangeLog[2] into SVN repository so we know what has changed. I would like to move debugger-related discussion fully to debug-commons development forum[3]. If you are interested, just log into rubyforge and click the link Monitor Forum to be notified by the email. I'll provide classic-debugger migrating patch for RDT as I promised soon (hopefully in 1-7 days). Regarding to various frontend-news I think we may still continue discussions here. Whatever fixes I'll made into the intermediate Java layer I'll also provide patch for RDT. In the future I still believe in the common library sharable between all Java frontend. But that's the future for now, hopefully near :) So next time on debug-commons dev forum. Thanks, m. [1] http://rubyforge.org/tracker/?atid=11903group_id=3085func=browse [2] in a classic form: http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html [3] http://rubyforge.org/forum/forum.php?forum_id=12220 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Ready for debug-commons
Martin Krauskopf wrote: TBD: mainly adding ruby-debug.rb I've just update Kent's ruby-debug and it seems that Markus was successful with propagating his changes directly there into v 0.8, right Markus? Congratulations! :) So there is no need to make it part of debug-commons any more? m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Ready for debug-commons
Markus Barchfeld wrote: Martin Krauskopf wrote: Martin Krauskopf wrote: TBD: mainly adding ruby-debug.rb I've just update Kent's ruby-debug and it seems that Markus was successful with propagating his changes directly there into v 0.8, right Markus? Congratulations! :) So there is no need to make it part of debug-commons any more? Hi Martin! Sorry also from my side for not replying to your other request earlier. But actually there was not much to comment from my side: it sounds good to me and just go for it. I will then move the development of the debugger tests to debug-commons, too (I have got to get a rubyforge account first). Do you have any chance to automate the tests and run them on various ruby versions (and on different platforms)? Yup, this is another task. Currently I'm using fresh Ruby build from ruby_1_8 branch which is the only which works for me. ruby 1.8.5 (2006-12-25 patchlevel 12) - the last official release; doesn't pass the tests. But now it is much easier to catch the culprit. Just one has to run rake (all tests), or better ./kill_debugger; rake if you are on Linux and you will quickly catch the culprit - test_class_variables fails with Segmentation Fault. Than one can play with it repeatedly in standard manner. kill_debugger; cd test; ruby cd_variables_test.rb --name test_class_variables; cd .. I did not have time to look at it yet. Hopefully soon. I had lot of trouble with running the tests as part of the Eclipse JUnit test suite. They took a lot of time and were unstable but it should get better without the Java stuff around. Yes, it's currently very quick process to catch and patch the bug. I've stabilized all active and commented tests so everything passes now. Take a look at the project I've send you if you want. I'll establish project soon. Also there might be some changes which differs from eclipseDebug.rb. I hope I'll able to provide some merging-patch for RDT as well as I wrote (it will be small). I think we should also run the test suite with ruby-debug if it is supposed to be a sort of compatibility test. And I would have to maintain the Test Suite in org.rubypeople.rdt.debug.test. otherwise. Furthermore there are also some extensions to ruby-debug which should be tested, too. I'm not sure about this. Did not know how much protocol of ruby-debug differs from classic-debug after your recent changes. But I think that testbase.rb and reader.rb should be generally useful. Maybe few tweaks/generalization will be needed. I need to take a look at ruby-debug soon anyway so I would write/help_with those test. I would post here before starting to work on them to prevent double-effort. Regarding org.rubypeople.rdt.debug.test, it should probably be trimmed to minimum, needed for testing Java-layer(CommandFactories, DebugProxies, ...), not protocol itself. In the future I would also like to make the Java-layer part of debug-common project. But there are some IDE-dependent stuffs as we talked about probably off-topic for now. m. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Problems selecting interpreter in nightly build
Werner Schuster (murphee) wrote: Christopher Williams wrote: We're having a few people trip over this. We expect the directory which contains bin/ruby and lib underneath it. So for most unix installs, the right directory to choose is /usr or /usr/local. This'll be a usability problem, so how about this: Windows: No problem, I guess (Ruby is probably always installed somewhere in C:\Program Files and users will know to look there); Unix systems with package management: Well, I've used Debian for 6-7 years, and I've no idea where it dumps its files; Solution: the StandardVMInstall could say If os == linux (or something) 1) look for [ /usr/bin/ruby, /usr/lib/ruby ], if that exists - pre-fill the RubyHome with /usr 2) else look for [ /usr/local/bin/ruby, /usr/local/lib/ruby ] if that exists - pre-fill the RubyHome with /usr 3) else: Other usual locations? 4) else: tough luck, user's on their own; Mac OS X: It's also a Unix with package management, but where does it normally stuff Ruby? This location should be pre-filled too. Comments? Maybe, you could also try (as a step 2.5) to analyze output from: ProcessBuilder pb = new ProcessBuilder(ruby, -e, require 'rbconfig'; + puts Config::CONFIG['bindir']; + puts Config::CONFIG['libdir']); or similar. Presumably works if the 'ruby' is on the PATH which is often the case (at least on Unix/Linux-like systems). m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Remote Debug project
Werner Schuster (murphee) wrote: Martin Krauskopf wrote: Yes, this is what I'm beginning to work on. It will be bunch of small -Test::Unit::TestCase-s which will be testing every corner of the protocol, runnable against whatever Ruby implementation. So it will as well catch every incompatibility in JRuby vs. CRuby then. Which is also the case now but little cumbersome since one more Java layer. I'll still be filling bugs into your IssueTracker with minimalistic test-cases. That's a great idea, this should help to fix some of the remaining issues with JRuby's tracing implementation (line numbers, bindings) and show the JRuby work left for compatibility with CRuby. Could you make this stuff (tests, etc) available on the net, over at RubyForge or wherever is convenient. I want to chip in some work for that, but I can't justify too much right now - the JRuby RDT plugin offers to many chances for features. Ok. I'll do so. I also do not promise any schedule yet. I'll let you know here on the mailing list... having also a lot of work on the frontend. Any preferences for the name of the project? Remote Debug? Or Remote Debug Commons? :) BTW is anybody actively working on FTC_ClassicDebuggerCommunicationTest? I've noticed that always when there is a new fix/commit only few test cases (currently three) are enabled. I would stabilize those test and uncomment as much of test cases as possible. I'll also uncomment WasteReader thread in FTC_Abstract... which, if uncommented/enabled, would currently breaks some tests. If anybody also working on this let me know. Thanks, cheers, m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Remote Debug project
Markus Barchfeld wrote: Any preferences for the name of the project? Remote Debug? Or Remote Debug Commons? :) I think commons is important, so Remote Debug Commons or Debugger Commons sounds good. BTW is anybody actively working on FTC_ClassicDebuggerCommunicationTest? I've noticed that always when there is a new fix/commit only few test cases (currently three) are enabled. I would stabilize those test and uncomment as much of test cases as possible. I'll also uncomment WasteReader thread in FTC_Abstract... which, if uncommented/enabled, would currently breaks some tests. If anybody also working on this let me know. Please enable all. I have used the suite method during development and then forgotten to comment it again. Yup, as much as possible. Some of them fails. There seems to be some bugs in eclipseDebug.rb. E.g.: test.rb --- require 'test2.rb' Test2.new.print() # breakpoint - step over (will stop at test2.rb:4) puts 'a' test.rb --- class Test2 def print puts 'XX' puts 'XX' # breakpoint - continue. Should finish[1] end end [1] but it does not. It will stops on test.rb:3. I'll take a look at such cases. BTW on which version of debug.rb is eclipseDebug.rb built on? According to: http://rubyeclipse.mktec.com/cgi-bin/trac.py/ticket/225 it seems quite old. There was not merged fix in debug.rb which was five years old. http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/lib/debug.rb.diff?r1=1.24;r2=1.25 m. PS: not needed to put me on the CC ;) I'm receiving emails twice then. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
[RDT-Dev] Remote Debug project
Hi, I would like to start talk about the topic on this list. We exchanged few emails about it with Chris, Markus and murphee and I see more and more people invoked, like Mirko. I wasn't aware that so much developers contribute just to the debugger. So as we discussed it would be great if debugging backends, currently XML protocol aware debugr.rb - eclipseDebug.rb; and extended ruby-debug from Kent Sibilev would be moved to some project on rubyforge.org where all interested parties could cooperate on further development of the features. With what to start? I could start with writing test in Ruby. Those tests would ensure that backends correspond closely to the specification. Since there is not yet any specification I would also start to writing it in the wiki format on RDT's wiki[1] for now. I would simply write it as it currently correspond to the current implementation and gradually I would switch from specification-by-implementation to implementation-by-specification. I believe it will bring a lot of clearance to the protocol. Those Ruby communication-test will be more pedantic (kind of low-level) than current functional test written in Java. Current Java test suite will be still useful for checking Java parsers functionality. Doesn't this interfere with of anybody's else work? If nobody else I can later found project on rubyforge. murphee talked about joining JRuby extras, but the project is rather ruby-implementation independent. So probably a new Remote Debug? Or joining one of the existing debug-related projects? I'm not yet that knowledgeable about all such projects. Maybe there is already similar effort I'm not aware of. So does above make sense, other ideas, ...? Thanks, m. [1] http://rubyeclipse.mktec.com/cgi-bin/trac.py/wiki - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
