Re: [RDT-Dev] Big News
On Wednesday 14 March 2007 08:35, Christopher Williams wrote: Mirko, On 3/14/07, Mirko Stocker [EMAIL PROTECTED] wrote: On Tuesday 13 March 2007 18:52:46 Christopher Williams wrote: We have no ability to employ full-time developers, nor do we really have any donations coming in to support augmentation of our work. Have you considered contacting Aptana? Now that they took over RadRails, they might be interested in keeping RDT alive.. or IBM should donate something, I'm sure they don't want to capitulate before Sun and NetBeans! I haven't contacted Aptana or IBM. Maybe it's because I never approached them, but I do find it a bit unliley IBM will suddenly decide to support us - the project has been around for 4 years now. But Rails Ruby continue to grow in popularity. And, unless someone in just the right spot at IBM loves Ruby and Eclipse, expecting them to contact you is unrealistic. I think you *should* try contacting them. (easy for me to say, but look what Sun has done for JRuby). David - 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] State of RDT
On Monday 08 January 2007 08:36, Christopher Williams wrote: Yes. The default behavior is to set the project as the root source folder, but with these changes we should be able to do more complex project setups like JDT. To expose it to the user we'd need to change our new project wizard and also add menu commands for creating new source folder roots. Consider this a request for such changes Thanks David - 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] State of RDT
On Saturday 06 January 2007 13:24, Christopher Williams wrote: snip Sounds like good news to me. I'm particularly interested in the changes around having 'source folders' (which it sounds like you've added). We've been working around that very awkwardly for years. David - 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] State of RDT
On Sunday 07 January 2007 14:59, Christopher Williams wrote: David, Well I'm not sure specifically what you'd like to know, so here's a little primer... SourceFolderRoot and SourceFolder map one-to-one to JDT's PackageFragmentRoot and PackageFragment (though our name gives a better idea of what they are). SourceFolderRoot is exactly that: the folder in the project whose contents hold ruby scripts. By default this is the project's folder, and this element is tied very closely to loadpaths. It's where RDT should begin traversing the filesystem looking for scripts. Every child folder is a SourceFolder element. Our restrictions on namespacing in Ruby are much different from java's so there shouldn't be any enforcement about type names and their position in the folder hierarchy. An external library could be represented as a SourceFolderRoot linked to an external folder structure (outside the actual project), and this should be how we'd implement linking back to Ruby core/std libraries.(The JDT has JarPackageFragmentRoots, we'd just have ExternalSourceFolderRoots). Well, the real question then, is can I change it so that the root of the project is NOT the a SourceFolder, but another folder is? That's something RDT has 'needed' for a long time... - 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] jruby
On Wednesday 06 December 2006 16:17, Werner Schuster (murphee) wrote: Ricardo Trindade wrote: Hi, I've been following the rdt mailing list for a while, and I'm glad to see that RDT seems to be very active. I'm particularly interested in jruby, since I'm using it and the lack of a debugger is a big pain. So I'm just wondering if we're getting closer to that objective Ricardo, I know, I've been writing some JRuby code in the past few weeks, and debugging with 'puts' is annoying, That's why I looked at the debugger connection of RDT and JRuby; I believe you saw the discussion on jruby-user, and the problems (a deadlock in tracing code) are fixed in the upcoming JRuby 0.9.2. Debugging JRuby with RDT is possible (I got it to work under ... let's say 'lab conditions'). I'm working to bundle this up nicely so it's possible to just run some JRuby code from RDT and have Debugging just work (TM) if you use JRuby 0.9.2. The RDT debugger uses a Ruby debugger implementation that doesn't quite work with JRuby (some regex don't work, and there's some other small stuff). I'm working on a JRuby plugin that adds special support for JRuby to RDT. At the moment I have: - Code Browsing clicking on the org.foo.Bar in include_class org.foo.Bar goes to the right class; - Text Hovers primitive, but docs for fully qualified class names can be shown; - JRuby Launch support This is useful in that I hacked RubyInterpreter and CommandExecutor to use an Extension point; this allows a JRuby CommandExecutor which sets the JAVA_HOME of the Java process, and - if the started Ruby code is inside a JDT Java project - sets the CLASSPATH variable (this means, the launched JRuby process will have the CLASSPATH of the Java project all set up, so all libs will be visible) TODO: - an action that will allow to a) set the Ruby nature and builder on JDT projects and b) set Java nature and builder on Ruby projects; - proper JRuby debugging support; I got a proof of concept for this, but need to figure out how to integrate it properly; - maybe some templates for include_class or similar constructs; - tie a bow around it Some of these things need a few small patches to RDT, but I hope to get this done before the end of the year. Remember, Release early and often is a principle of open source projects. Sounds like you've already got a lot of value... - 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] internal.debug.ui.test Running Junit Plugin tests
On Wednesday 02 August 2006 15:57, designker wrote: Hi, Is it normal that the tests in org.rubypeople.internal.debug.ui.test do not all work? I run TS_DebugUI.java and 5 tests fail. I seem to recall you have to define some system property when you run it. Not sure of the details, but Markus will chime in with the answer I suspect. David - Designker - 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] Eclipse 3.2 Features and backwards Compatibility
On Tuesday 01 August 2006 11:25, zdennis wrote: Markus Barchfeld wrote: I would neglect backward compatibility to 3.1 for the sake of simplicity. I agree with Markus. And on the terms of upgrading, is there an easy way to port plugins of an existing eclipse 3.1.x installation to 3.2 wi/o having to reinstall them all from their own sources? (that is one reason I haven't upgraded to 3.2.. i dont want to manually reinstall my 85 plugins) Zach if you're on 3.1.x (not a 3.2 milestone, just upgrade eclipse with the built-in updater.) If you're siwtching from milestones, I just install new version of eclipse, and then do recursive copies of the various plugin and feature directories. Just leave out the ones that come with eclipse. David - 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] Choosing interpreters?
Ah! Yes.. I was running (or trying to run) unit tests with both cygwin and mswin32 to see if they failed on one or the other. Guess I can't do that from Eclipse. Dumb question - where's that launch config? Run/Run... or Run/Debug - 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] Getting another build of RDT (RemoteTestRunner)
On Thursday 06 April 2006 14:09, Kyle Shank wrote: Did you check this into HEAD? I did. On 4/5/06, David Corbin [EMAIL PROTECTED] wrote: It's fixed. I don't understand why I see it in RDT, and not when using the console test runner, but I think my fix is a good one. And I really don't understand why Test::Unit is adding the 'default_test'. Essentially, TestCase's that have no public method matching /^test./ are ignored. Unfortunately, there is some code duplication between RemoteTestRunner and test/unit, but such is life. David --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Getting another build of RDT (RemoteTestRunner)
On Wednesday 05 April 2006 08:29 pm, David Corbin wrote: On Wednesday 05 April 2006 07:27 pm, David Corbin wrote: On Wednesday 05 April 2006 07:20 pm, David Corbin wrote: On Wednesday 05 April 2006 06:41 pm, you wrote: Exactly what 'parameters' are specified in the test launch? I think this already works right if you just specify files. It's when you specify a class explicitly that things 'get wonky'. Looks like I got that complete backwards. It's fixed. I don't understand why I see it in RDT, and not when using the console test runner, but I think my fix is a good one. And I really don't understand why Test::Unit is adding the 'default_test'. Essentially, TestCase's that have no public method matching /^test./ are ignored. Unfortunately, there is some code duplication between RemoteTestRunner and test/unit, but such is life. David --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
[RDT-Dev] Identifying Ruby files
Did I really see a commit where we listed a bunch of rails specific file names and said that if that's the name it must be a ruby file? I thought RDT was going to remain Rails-free. Why isn't this being done with an extension-point? David --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Rubyeclipse-development mailing list Rubyeclipse-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
Re: [RDT-Dev] Releasing 0.7.0
On Sunday 15 January 2006 06:00 pm, Markus Barchfeld wrote:
Christopher Williams wrote:
Markus and all,
What are the fixes or other steps that everyone thinks we need to
complete before releasing a true 0.7.0 release? The Radrails guys
have been patiently waiting for the release to do their own. I think
we should push to do what we can to get it out for them - they've
been waiting a long time.
I think the useless .. warning is crucial despite the configurable
squiggels. Therefore I've created a new jruby.jar from jruby HEAD.
Thanks to the latest changes from Thomas this fixes bug #67. In order to
fix the useless warning I've applied the crude patch below. Thomas, do
you think there is a chance to add an ID to warnings for the next
release so that we can add preference page for filtering warnings?
Thomas, do you see any obstacles with HEAD of jruby? I've got one
failing test (testDigest) and one error (testRubyRequire) when running
MainTestSuite.
We should NOT release JRuby from HEAD, unless it's been tagged.
Please check 0.7.0.601152327NGT, if it is fine I will release 0.7.0.
Markus
Index: UselessStatementVisitor.java
===
RCS file:
/cvsroot/jruby/jruby/src/org/jruby/ast/visitor/UselessStatementVisitor.java
,v retrieving revision 1.13
diff -u -r1.13 UselessStatementVisitor.java
--- UselessStatementVisitor.java4 Nov 2005 16:12:49 -1.13
+++ UselessStatementVisitor.java15 Jan 2006 22:07:30 -
@@ -78,8 +78,8 @@
}
private void handleUselessWarn(Node node, String useless) {
-warnings.warn(node.getPosition(), Useless use of + useless
-+ in void context.);
+//warnings.warn(node.getPosition(), Useless use of + useless
+//+ in void context.);
}
/**
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Rubyeclipse-development mailing list
Rubyeclipse-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rubyeclipse-development
