I don't know if I get much of a say, but I would vote for 1.8.7 / 1.9 support and better interop with CLR types. So pretty much what Jimmy said.
--Alex On Wed, May 12, 2010 at 3:24 AM, David Escobar <davidesco...@ieee.org> wrote: > Jimmy, Will, > The suggestions posted on here are all great - I'll definitely give them a > try. For me, I've gotten used to generating .exe's and .dll's using either > compilers or packaging systems like py2exe for CPython and OCRA for MRI, and > it's been fairly straightforward on how to do it. With IronRuby, it wasn't > immediately obvious (to me) and seems to require more steps. That's what > made me wonder if maybe the scope and intention of IronRuby was limited to > being an embedded language for C# and VB, rather than as a language that > stands on its own - where I can write my entire application in IR and then > compile or pack it up to an assembly without any dependencies on C# or VB. > That's what I meant by "first class" - hopefully that clears things up a > bit. Sorry for any confusion. > But anyway, thanks for all the suggestions. That answers my questions. > > > On Tue, May 11, 2010 at 8:24 PM, 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 > > _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
