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 DefaultVM (which is the one checked in the Ruby Interpreter Prefs).
This means:
- I have a C/Ruby Interpreter set as the Default VM
- I have JRuby Interpreter set up
- when I do a Launch and tell it to use JRuby, this lookup system will
fail and just return the Default VM;
It should prefer the project's specified interpreter and fall back to the
default VM if that fails (as far as I know). I'd be interested to know
exactly how its failing when you try to use the project specific VM.
If you want to see how additional VMs behave in the GUI or interact with
the VM system, my JRuby stuff is available at:
:pserver:[EMAIL PROTECTED]:/var/cvs/rdt-jruby
Great;
Just for the record: a Standard C/Ruby needs to be used for the RI and
Rdoc features;
I once set a JRuby installation as my default Ruby Interpreter, and the
Ri/RDoc features broke (seems like Ri doesn't work in JRuby) and there
were frequent 100% CPU usage periods, which came from the TextHover
launching JRuby (heavyweight...) and trying to get the Ri for some code.
Ah, ok yeah that would be bad. With the changes in Jruby we can now get
comments straight from the AST. I'd love for someone to try out an
experiment and cache all that info corresponding to every IRubyElement and
then we can do quick lookups for hovers (rarther than invoke an RI process
on-demand).
Question:
What timeframe for a release do you have in mind? I'm mostly interested
if you want to add some more stuff before 0.9 or
if the current state == 0.9 (of course, after the changes had some time
to settle down);
I'd like to add some small extension points (QuickAssists/QuickFixes and
an Extension point that might allow to add more "Compilers" to the
Builder process).
These could go into 1.0, if the 0.9 release is too close, but they
shouldn't interact badly with the RDT features.
Personally, I'd like to harden what we have and get 0.9.0 out the door.
It's be forever since a real release happened. Specifically, we need to be
sure the debugging, launching and code completion stuff is working well
enough for a release. (i.e. it works and there's no showstopping bugs coming
up). On Trac I set the release date for 0.9.0 as February 15th.
Thanks,
Chris
--
http://cwilliams.textdriven.com
-------------------------------------------------------------------------
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.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
