+1 for rubymine.

On Fri, Jun 4, 2010 at 12:08 AM, Shay Friedman <shay.fried...@gmail.com>wrote:

> I'm using RubyMine for rails and projects with more than 2-3 files.
> Otherwise I'm using SciTE.
>
> By the way, RubyMine is not free.
>
> Shay.
> --------------------------------------------------------
> Shay Friedman | Microsoft Visual C#/IronRuby MVP | Author of IronRuby
> Unleashed | Sela Technology Center
> Blog: http://IronShay.com | Twitter: http://twitter.com/ironshay
>
>
> On Fri, Jun 4, 2010 at 8:51 AM, Stuart Ellis <stu...@stuartellis.eu>wrote:
>
>> Interesting - I tried SharpDevelop and Netbeans, and wasn't happy with
>> them for different reasons, but not RubyMine.
>>
>> Thanks
>>
>> On 3 Jun 2010, at 21:49, Martin Smith wrote:
>>
>> > Hey Stuart,
>> >
>> > Try out rubymine. We use that and it works pretty well even with
>> IronRuby...
>> >
>> > Martin
>> >
>> > On Tue, May 25, 2010 at 12:18 PM, Stuart Ellis <stu...@stuartellis.eu>
>> wrote:
>> >>> From the peanut gallery: the lack of VS integration has definitely
>> held me back from trying to push IronRuby in any capacity at work - I've
>> been happy using Ruby without an IDE, but I am fairly certain that my
>> colleagues would politely and firmly decline any suggestion of switching to
>> text editor and the CLI. You could take that as a complement to the work of
>> the VS team :)
>> >>
>> >> On 25 May 2010, at 12:15, Mark Rendle wrote:
>> >>
>> >>> In terms of MRI compatibility, I'd suggest that 1.9.2 would be a good
>> target. 1.9.1 has various issues and has been largely ignored in favour of
>> 1.8.7, but I'm seeing a lot of people recommending 1.9.2 even in its current
>> pre state.
>> >>>
>> >>> Beyond compatibility, I think VS integration would be sweet, and would
>> help drive adoption among my vi-illiterate colleagues.
>> >>>
>> >>> If my sum workload ever drops below critical mass, I'll start to
>> contribute: honest!
>> >>>
>> >>> Mark
>> >>>
>> >>> On Wed, May 12, 2010 at 4:24 AM, Jimmy Schementi <
>> jimmy.scheme...@microsoft.com> wrote:
>> >>> Will, what you are describing is the preferred way of packaging Ruby
>> code as an exe. Someone should write a sample that shows how to do this; I
>> believe there already is one but I don't have the URL handy.
>> >>>
>> >>> David, the first part of your email sounded reasonable, but the 2nd
>> part (about scope) came from left field. Please indicate why the recipe
>> Tomas and Will explained make IronRuby any less than first-class (whatever
>> that means =P). IronPython is also planning on doing this too, so we think
>> it's the best "self-contained deployment" option, but I'd like to hear why
>> it won't work for you.
>> >>>
>> >>> As far as the other discussed features go, let me draw a line in the
>> sand for the next major release (let's call it vNext for argument's sake):
>> >>>
>> >>> 1.) It is a goal of IronRuby vNext to improve interop with .NETs type
>> system, so we will most likely implement something like IronPython's
>> "clrtype" feature, and provide a library which lets you emit real static
>> types from Ruby code. You could even imagine taking the emitted IL and
>> writing it to a DLL, which could be called directly from a static language,
>> but that's lower priority.
>> >>>
>> >>> 2.) It is not a goal of IronRuby vNext to implement a static compiler
>> for Ruby; as in we will not emit both similar types and method bodies as C#.
>> IronRuby is a dynamic language, and any static compiler features should be
>> part of a .NET backend for Duby (currently only a JVM backend exists).
>> Pre-compilation is different; it involves emitting IL to a DLL that we would
>> have emit at runtime, given every method were called. This would only help
>> startup marginally, as we already have fast startup with the interpreter and
>> NGEN-ing IronRuby's binaries, and most of the time spent is actually running
>> code, not emitting it. Also, pre-compilation doesn't help us CLR type system
>> interop, as it would not produce a CLI-compliant assembly; assemblies
>> generated by pyc cannot be referenced by a C# app.
>> >>>
>> >>> As far as non-.NET related features, we'll be targeting Ruby 1.9
>> support, and running Rails 3 and other libs will focus us on what features
>> to implement first (so 1.8.7 compat might happen despite us wanting to move
>> directly to 1.9). FFI is another possible feature, but only if there are
>> crucial libs that use it, or if someone contributes it.
>> >>>
>> >>> Any other features people are curious about? Now is definitely the
>> time to voice your opinions :)
>> >>>
>> >>> ~Jimmy
>> >>>
>> >>> On May 11, 2010, at 7:15 PM, "Will Green" <w...@hotgazpacho.org>
>> wrote:
>> >>>
>> >>>> Why not create an executable assembly that embeds all the Ruby files
>> as resources in the assembly? Extract them at runtime (you could probably
>> just keep them in a memory stream), fire up a Ruby runtime host & engine,
>> feed it the Ruby file, and away you go.
>> >>>>
>> >>>> Or am I missing something that would make this infeasible?
>> >>>>
>> >>>> --
>> >>>> Will Green
>> >>>> http://hotgazpacho.org/
>> >>>>
>> >>>>
>> >>>> On Tue, May 11, 2010 at 9:20 PM, David Escobar <
>> davidesco...@ieee.org> wrote:
>> >>>> Ok, that's certainly an option to look into. I guess what people want
>> is the ability to distribute applications and libraries in .exe and .dll
>> form, the same way we do with C# or VB. But perhaps it's a question of scope
>> - maybe IronRuby is not intended to be a 1st class .NET language in the same
>> way that C# or VB are, or it's only intended to be a language for embedding
>> in a static language or for unit testing purposes?
>> >>>>
>> >>>> The other reason is that it provides some (small) level of code
>> obfuscation. I realize of course that the assemblies can be reverse
>> engineered, but most users won't bother to do that - they'll just be
>> interested in running the .exe.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Tue, May 11, 2010 at 6:04 PM, Tomas Matousek <
>> tomas.matou...@microsoft.com> wrote:
>> >>>> Well, there is a pretty simple way how to package up .rb files into
>> an .exe file w/o precompiling anything. One option is to build a
>> self-extracting zip file or something like that. That would solve the
>> deployment issue. Improving startup time via pre-compilation is much more
>> work.
>> >>>>
>> >>>>
>> >>>> Tomas
>> >>>>
>> >>>>
>> >>>> From: ironruby-core-boun...@rubyforge.org [mailto:
>> ironruby-core-boun...@rubyforge.org] On Behalf Of David Escobar
>> >>>> Sent: Tuesday, May 11, 2010 5:48 PM
>> >>>>
>> >>>>
>> >>>> To: ironruby-core@rubyforge.org
>> >>>> Subject: Re: [Ironruby-core] What's next?
>> >>>>
>> >>>>
>> >>>> Pre-compiling code would allow us to distribute our programs in .exe
>> and .dll form, rather than .rb files. IronPython allows this with its pyc.py
>> script. And if that means faster startup times and using Ruby code
>> statically from C#, then all the better.
>> >>>>
>> >>>>
>> >>>> On Tue, May 11, 2010 at 3:06 PM, Tomas Matousek <
>> tomas.matou...@microsoft.com> wrote:
>> >>>>
>> >>>> What would you like to achieve by pre-compiling code? Faster startup
>> time? Packaging your code in a dll instead of a bunch of .rb files? Using
>> Ruby code statically from C#?
>> >>>>
>> >>>> Tomas
>> >>>>
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: ironruby-core-boun...@rubyforge.org [mailto:
>> ironruby-core-boun...@rubyforge.org] On Behalf Of Martin Smith
>> >>>> Sent: Tuesday, May 11, 2010 11:14 AM
>> >>>> To: ironruby-core@rubyforge.org
>> >>>> Subject: [Ironruby-core] What's next?
>> >>>>
>> >>>> Hey Guys,
>> >>>>
>> >>>> Now that IronRuby 1.0 has shipped (congrats!!), what's next on the
>> docket? :) I'm not trying to pressure you guys! Just excited about the
>> future.
>> >>>> The feature i'd love to see most would be pre-compilation...
>> >>>>
>> >>>> Thanks for such a great product,
>> >>>> Martin
>> >>>> _______________________________________________
>> >>>> Ironruby-core mailing list
>> >>>> Ironruby-core@rubyforge.org
>> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ironruby-core mailing list
>> >>>> Ironruby-core@rubyforge.org
>> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ironruby-core mailing list
>> >>>> Ironruby-core@rubyforge.org
>> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Ironruby-core mailing list
>> >>>> Ironruby-core@rubyforge.org
>> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>>
>> >>> _______________________________________________
>> >>> Ironruby-core mailing list
>> >>> Ironruby-core@rubyforge.org
>> >>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Ironruby-core mailing list
>> >>> Ironruby-core@rubyforge.org
>> >>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>
>> >> ---
>> >> Stuart Ellis
>> >> stu...@stuartellis.eu
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Ironruby-core mailing list
>> >> Ironruby-core@rubyforge.org
>> >> http://rubyforge.org/mailman/listinfo/ironruby-core
>> >>
>> > _______________________________________________
>> > Ironruby-core mailing list
>> > Ironruby-core@rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> ---
>> Stuart Ellis
>> stu...@stuartellis.eu
>>
>>
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
"The explanation requiring the fewest assumptions is most likely to be
correct."

- Occam’s Razor
http://en.wikipedia.org/wiki/Occam's_Razor
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to