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/>http://hotgazpacho.org/ > > > On Tue, May 11, 2010 at 9:20 PM, David Escobar < <davidesco...@ieee.org> > 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> >> 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> >>> ironruby-core-boun...@rubyforge.org >>> [mailto:<ironruby-core-boun...@rubyforge.org> >>> ironruby-core-boun...@rubyforge.org] *On Behalf Of *David Escobar >>> *Sent:* Tuesday, May 11, 2010 5:48 PM >>> >>> *To:* <ironruby-core@rubyforge.org>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> >>> 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> >>> ironruby-core-boun...@rubyforge.org >>> [mailto:<ironruby-core-boun...@rubyforge.org> >>> ironruby-core-boun...@rubyforge.org] On Behalf Of Martin Smith >>> Sent: Tuesday, May 11, 2010 11:14 AM >>> To: <ironruby-core@rubyforge.org>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>Ironruby-core@rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> <Ironruby-core@rubyforge.org>Ironruby-core@rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> <Ironruby-core@rubyforge.org>Ironruby-core@rubyforge.org >> <http://rubyforge.org/mailman/listinfo/ironruby-core> >> 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
