Re: [RDT-Dev] Problems selecting interpreter in nightly build

2007-01-26 Thread Christopher Williams
murphee, On 1/26/07, Werner Schuster (murphee) <[EMAIL PROTECTED]> 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/l

Re: [RDT-Dev] Problems selecting interpreter in nightly build

2007-01-26 Thread Werner Schuster (murphee)
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

Re: [RDT-Dev] Problems selecting interpreter in nightly build

2007-01-26 Thread Christopher Williams
Lane, 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. The dialog should give text at the top which illuminates this a little... Thanks, Chris On 1/26

Re: [RDT-Dev] Problems selecting interpreter in nightly build

2007-01-26 Thread Werner Schuster (murphee)
Lane Schwartz wrote: > I go to the Add RubyVM dialog in the preferences, and try to put > /usr/bin in > the RubyVM home directory field. The only option under RubyVM type is > Standard VM. Try using /usr for Ruby VM home dir. If that doesn't work, check where your Ruby installation is located (f

[RDT-Dev] Problems selecting interpreter in nightly build

2007-01-26 Thread Lane Schwartz
Hi, I'm trying out the nightly build (0.8.0.701261527NGT), and I can't seem to figure out how to select the ruby executable. I go to the Add RubyVM dialog in the preferences, and try to put /usr/bin in the RubyVM home directory field. The only option under RubyVM type is Standard VM. Am I missi

Re: [RDT-Dev] State of RDT

2007-01-26 Thread Christopher Williams
murphe, all, On 1/25/07, Werner Schuster (murphee) <[EMAIL PROTECTED]> wrote: Another issue: I'm not quite sure how the lookup system for different VMs works - it seems like it tries to lookup some VM configuration based on the project, and if it can't find anything there, it falls back to the

Re: [RDT-Dev] AST from Editor

2007-01-26 Thread Christopher Williams
murphee, There's no shortcut right now to grab the root AST node from an editor. You can grab the IRubyScript from an editor, and then traverse the IRubyElement model hierarchy. You can also provide the root AST to findNode on Members (fields, methods, classes, modules) and get the corresponding

Re: [RDT-Dev] Remote Debug project

2007-01-26 Thread Markus Barchfeld
> > 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. > > That might be. I started on eclipseDebug.rb in 2002 on sta

Re: [RDT-Dev] Remote Debug project

2007-01-26 Thread Martin Krauskopf
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_ClassicDebuggerCommunicationTes

Re: [RDT-Dev] Remote Debug project

2007-01-26 Thread Markus Barchfeld
> 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

Re: [RDT-Dev] Remote Debug project

2007-01-26 Thread Martin Krauskopf
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 i