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
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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith Sent: Tuesday, May 11, 2010 11:14 AM To: ironruby-core at 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 at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
On Wed, May 12, 2010 at 10:06 AM, Tomas Matousek < Tomas.Matousek at 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#? >Personally I''m not too fussed about using ruby statically from C# (dynamic in 4.0 solves that problem), but IMHO packaging is the big one. Even if it didn''t run any faster, I''d still use precompilation just for deployment. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/eab3c048/attachment.html>
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.Matousek at 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-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > Sent: Tuesday, May 11, 2010 11:14 AM > To: ironruby-core at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100511/2b03615b/attachment.html>
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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar Sent: Tuesday, May 11, 2010 5:48 PM To: ironruby-core at 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.Matousek at microsoft.com<mailto:Tomas.Matousek at 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-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Martin Smith Sent: Tuesday, May 11, 2010 11:14 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/659f2f44/attachment.html>
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.Matousek at 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-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *David Escobar > *Sent:* Tuesday, May 11, 2010 5:48 PM > > *To:* ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > Sent: Tuesday, May 11, 2010 11:14 AM > To: ironruby-core at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100511/49885319/attachment-0001.html>
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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *David Escobar >> *Sent:* Tuesday, May 11, 2010 5:48 PM >> >> *To:* ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >> Sent: Tuesday, May 11, 2010 11:14 AM >> To: ironruby-core at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100511/a4b87f5f/attachment.html>
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<http://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" <will at hotgazpacho.org<mailto:will at 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 <<mailto:davidescobar at ieee.org>davidescobar at ieee.org<mailto:davidescobar at 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 <<mailto:Tomas.Matousek at microsoft.com>Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at 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: <mailto:ironruby-core-bounces at rubyforge.org> ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:<mailto:ironruby-core-bounces at rubyforge.org>ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of David Escobar Sent: Tuesday, May 11, 2010 5:48 PM To: <mailto:ironruby-core at rubyforge.org> ironruby-core at rubyforge.org<mailto:ironruby-core at 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 <<mailto:Tomas.Matousek at microsoft.com>Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at 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: <mailto:ironruby-core-bounces at rubyforge.org> ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:<mailto:ironruby-core-bounces at rubyforge.org>ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Martin Smith Sent: Tuesday, May 11, 2010 11:14 AM To: <mailto:ironruby-core at rubyforge.org> ironruby-core at rubyforge.org<mailto:ironruby-core at 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 <mailto:Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> <http://rubyforge.org/mailman/listinfo/ironruby-core>http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list <mailto:Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> <http://rubyforge.org/mailman/listinfo/ironruby-core>http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list <mailto:Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> <http://rubyforge.org/mailman/listinfo/ironruby-core>http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/09db72a6/attachment-0001.html>
I believe the example for embedding the assemblies to create a .exe that you''re looking for is: http://github.com/rifraf/IronRubyEmbeddedApps I think my main interests would be 1.9 support and a .NET duby backend which I might need to talk to Charlie about :). -Zac On 5/11/2010 8:24 PM, Jimmy Schementi 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 <http://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" <will at hotgazpacho.org > <mailto:will at 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 <davidescobar at ieee.org >> <mailto:davidescobar at 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.Matousek at microsoft.com >> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org >> <mailto:ironruby-core-bounces at rubyforge.org> >> [mailto:ironruby-core-bounces at rubyforge.org >> <mailto:ironruby-core-bounces at rubyforge.org>] *On Behalf Of >> *David Escobar >> *Sent:* Tuesday, May 11, 2010 5:48 PM >> >> >> *To:* ironruby-core at rubyforge.org >> <mailto:ironruby-core at 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.Matousek at microsoft.com >> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org >> <mailto:ironruby-core-bounces at rubyforge.org> >> [mailto:ironruby-core-bounces at rubyforge.org >> <mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of >> Martin Smith >> Sent: Tuesday, May 11, 2010 11:14 AM >> To: ironruby-core at rubyforge.org >> <mailto:ironruby-core at 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 at rubyforge.org <mailto:Ironruby-core at rubyforge.org> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> >> http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
Charlie is really interested in having a .NET Duby backend; I started one in December but only got a simple helloworld app working. I''d like if someone else take it on, especially if they''ll be committed to it, so let me know if you need any help getting started.> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Zac Brown > Sent: Tuesday, May 11, 2010 9:48 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] What''s next? > > I believe the example for embedding the assemblies to create a .exe that > you''re looking for is: http://github.com/rifraf/IronRubyEmbeddedApps > > I think my main interests would be 1.9 support and a .NET duby backend > which I might need to talk to Charlie about :). > > -Zac > > On 5/11/2010 8:24 PM, Jimmy Schementi 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 <http://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" <will at hotgazpacho.org > > <mailto:will at 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 <davidescobar at ieee.org > >> <mailto:davidescobar at 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.Matousek at microsoft.com > >> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org > >> <mailto:ironruby-core-bounces at rubyforge.org> > >> [mailto:ironruby-core-bounces at rubyforge.org > >> <mailto:ironruby-core-bounces at rubyforge.org>] *On Behalf Of > >> *David Escobar > >> *Sent:* Tuesday, May 11, 2010 5:48 PM > >> > >> > >> *To:* ironruby-core at rubyforge.org > >> <mailto:ironruby-core at 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.Matousek at microsoft.com > >> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org > >> <mailto:ironruby-core-bounces at rubyforge.org> > >> [mailto:ironruby-core-bounces at rubyforge.org > >> <mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of > >> Martin Smith > >> Sent: Tuesday, May 11, 2010 11:14 AM > >> To: ironruby-core at rubyforge.org > >> <mailto:ironruby-core at 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 at rubyforge.org <mailto:Ironruby-core at rubyforge.org> > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > >> > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org> > >> http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
I''d be really interested in it. I''ll email you offline to ask a few more specific questions. -Zac On 5/11/2010 10:02 PM, Jimmy Schementi wrote:> Charlie is really interested in having a .NET Duby backend; I started one in December but only got a simple helloworld app working. I''d like if someone else take it on, especially if they''ll be committed to it, so let me know if you need any help getting started. > > >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- >> bounces at rubyforge.org] On Behalf Of Zac Brown >> Sent: Tuesday, May 11, 2010 9:48 PM >> To: ironruby-core at rubyforge.org >> Subject: Re: [Ironruby-core] What''s next? >> >> I believe the example for embedding the assemblies to create a .exe that >> you''re looking for is: http://github.com/rifraf/IronRubyEmbeddedApps >> >> I think my main interests would be 1.9 support and a .NET duby backend >> which I might need to talk to Charlie about :). >> >> -Zac >> >> On 5/11/2010 8:24 PM, Jimmy Schementi 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<http://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"<will at hotgazpacho.org >>> <mailto:will at 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<davidescobar at ieee.org >>>> <mailto:davidescobar at 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.Matousek at microsoft.com >>>> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org >>>> <mailto:ironruby-core-bounces at rubyforge.org> >>>> [mailto:ironruby-core-bounces at rubyforge.org >>>> <mailto:ironruby-core-bounces at rubyforge.org>] *On Behalf Of >>>> *David Escobar >>>> *Sent:* Tuesday, May 11, 2010 5:48 PM >>>> >>>> >>>> *To:* ironruby-core at rubyforge.org >>>> <mailto:ironruby-core at 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.Matousek at microsoft.com >>>> <mailto:Tomas.Matousek at 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-bounces at rubyforge.org >>>> <mailto:ironruby-core-bounces at rubyforge.org> >>>> [mailto:ironruby-core-bounces at rubyforge.org >>>> <mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of >>>> Martin Smith >>>> Sent: Tuesday, May 11, 2010 11:14 AM >>>> To: ironruby-core at rubyforge.org >>>> <mailto:ironruby-core at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
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.Schementi at 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" <will at 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 < <davidescobar at ieee.org> > davidescobar at 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.Matousek at microsoft.com> >> Tomas.Matousek at 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-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *David Escobar >>> *Sent:* Tuesday, May 11, 2010 5:48 PM >>> >>> *To:* <ironruby-core at rubyforge.org>ironruby-core at 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.Matousek at microsoft.com> >>> Tomas.Matousek at 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-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >>> Sent: Tuesday, May 11, 2010 11:14 AM >>> To: <ironruby-core at rubyforge.org>ironruby-core at 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 at rubyforge.org>Ironruby-core at rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org >> <http://rubyforge.org/mailman/listinfo/ironruby-core> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/36f94c31/attachment.html>
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 <davidescobar at 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.Schementi at 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" <will at 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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org >>>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar >>>> Sent: Tuesday, May 11, 2010 5:48 PM >>>> >>>> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org >>>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >>>> Sent: Tuesday, May 11, 2010 11:14 AM >>>> To: ironruby-core at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >
Personally, I''d like to see integration into VS. What is everyone using to edit their IronRuby code?
Vim ;-) While it would be nice to have something like the IronPython Tools for Visual Studio - http://ironpython.net/tools/ - I''d rather see IronRuby pass more of RubySpec, get more standard libraries, like OpenSSL, implemented (I know, I know, patches are welcome), and fix some critical bugs, like the one that prevents upgrading RubyGems via `gem up --system` (which in turn prevents the easy use of cool libs like Bundler). I personally think that 1.8.7 is a better goal than 1.9.1; I''ve heard some prominent Ruby community members like Yehuda Katz complain about 1.9.1 on Twitter. -- Will Green http://hotgazpacho.org/ On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne at gmail.com> wrote:> Personally, I''d like to see integration into VS. > > What is everyone using to edit their IronRuby code? > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/993b5a29/attachment.html>
You guys have hit the nail on the head for me I actually want it for both reasons: to provide some loose protection for our code and to improve startup times. I was thinking about doing something around packaging like you guys were talking about, but i think then I''d have to redefine Kernel.require to make sure that all the require statements execute properly. For code protection, it only provided small benefits (a determined code stealer would easily circumvent the protections), but if it helped with startup times that would benefit us greatly. The issue is that we use IR for our UI layer so the first time they ask for any dialog it needs to compile quite a bit of code so the first time they load a dialog can take some time. I''ve thought of changing this so we do the compilation at startup but i''m not quite sure if that will work. I''d envision something like this: 1) set compilation threshold to 0 (compile immediately) 2) execute "require ''file''" for each ruby script 3)set compilation threshold to 1 so eval doesn''t compile everything (we semi-extensively use eval) Would something like this be possible? Is the compilation threshold settable dynamically? Thanks in advance, Martin
Note that the DLR''s ScriptHost abilities allow you to redefine what the file system is, so instead of changing require, load, load_assembly, and any other code that might touch files, you can just write a Platform Abstraction Layer. The Silverlight support uses this heavily to allow require ''foo'' to look up foo in the XAP. JD -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith Sent: Wednesday, May 12, 2010 11:27 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] What''s next? You guys have hit the nail on the head for me I actually want it for both reasons: to provide some loose protection for our code and to improve startup times. I was thinking about doing something around packaging like you guys were talking about, but i think then I''d have to redefine Kernel.require to make sure that all the require statements execute properly. For code protection, it only provided small benefits (a determined code stealer would easily circumvent the protections), but if it helped with startup times that would benefit us greatly. The issue is that we use IR for our UI layer so the first time they ask for any dialog it needs to compile quite a bit of code so the first time they load a dialog can take some time. I''ve thought of changing this so we do the compilation at startup but i''m not quite sure if that will work. I''d envision something like this: 1) set compilation threshold to 0 (compile immediately) 2) execute "require ''file''" for each ruby script 3)set compilation threshold to 1 so eval doesn''t compile everything (we semi-extensively use eval) Would something like this be possible? Is the compilation threshold settable dynamically? Thanks in advance, Martin _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Vim ? From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Wednesday, May 12, 2010 9:14 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] What''s next? Vim ;-) While it would be nice to have something like the IronPython Tools for Visual Studio - http://ironpython.net/tools/ - I''d rather see IronRuby pass more of RubySpec, get more standard libraries, like OpenSSL, implemented (I know, I know, patches are welcome), and fix some critical bugs, like the one that prevents upgrading RubyGems via `gem up --system` (which in turn prevents the easy use of cool libs like Bundler). I personally think that 1.8.7 is a better goal than 1.9.1; I''ve heard some prominent Ruby community members like Yehuda Katz complain about 1.9.1 on Twitter. -- Will Green http://hotgazpacho.org/ On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne at gmail.com<mailto:tggagne at gmail.com>> wrote: Personally, I''d like to see integration into VS. What is everyone using to edit their IronRuby code? _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/9b78f951/attachment.html>
vim :) http://github.com/casualjim/dot-files --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Web: http://whiterabbitconsulting.eu - http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) Microsoft IronRuby/C# MVP On Wed, May 12, 2010 at 9:05 PM, Jim Deville <jdeville at microsoft.com> wrote:> Vim J > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Wednesday, May 12, 2010 9:14 AM > > *To:* ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] What''s next? > > > > Vim ;-) > > > > While it would be nice to have something like the IronPython Tools for > Visual Studio - http://ironpython.net/tools/ - I''d rather see IronRuby > pass more of RubySpec, get more standard libraries, like OpenSSL, > implemented (I know, I know, patches are welcome), and fix some critical > bugs, like the one that prevents upgrading RubyGems via `gem up --system` > (which in turn prevents the easy use of cool libs like Bundler). > > > > I personally think that 1.8.7 is a better goal than 1.9.1; I''ve heard some > prominent Ruby community members like Yehuda Katz complain about 1.9.1 on > Twitter. > > > -- > Will Green > http://hotgazpacho.org/ > > On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne at gmail.com> wrote: > > Personally, I''d like to see integration into VS. > > What is everyone using to edit their IronRuby code? > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100512/e659fef7/attachment-0001.html>
How long does it take to require all the files you need? Do you use installed IronRuby v1.0 binaries for .NET 4.0 or do you build IronRuby yourself? Can you be specific about what you''re requiring? Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith Sent: Wednesday, May 12, 2010 11:27 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] What''s next? You guys have hit the nail on the head for me I actually want it for both reasons: to provide some loose protection for our code and to improve startup times. I was thinking about doing something around packaging like you guys were talking about, but i think then I''d have to redefine Kernel.require to make sure that all the require statements execute properly. For code protection, it only provided small benefits (a determined code stealer would easily circumvent the protections), but if it helped with startup times that would benefit us greatly. The issue is that we use IR for our UI layer so the first time they ask for any dialog it needs to compile quite a bit of code so the first time they load a dialog can take some time. I''ve thought of changing this so we do the compilation at startup but i''m not quite sure if that will work. I''d envision something like this: 1) set compilation threshold to 0 (compile immediately) 2) execute "require ''file''" for each ruby script 3)set compilation threshold to 1 so eval doesn''t compile everything (we semi-extensively use eval) Would something like this be possible? Is the compilation threshold settable dynamically? Thanks in advance, Martin _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
I use NotePad++ with the Ruby autocomplete plugin. See: - http://pastebin.com/f4fedbb27 as referenced on SO: - http://stackoverflow.com/questions/997011/enabling-autocomplete-in-notepad-for-api-files On 5/12/2010 1:05 PM, Jim Deville wrote: Vim J From: ironruby-core-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org [mailto:ironruby-core-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org] On Behalf Of Will Green Sent: Wednesday, May 12, 2010 9:14 AM To: ironruby-core-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Subject: Re: [Ironruby-core] What''s next? Vim ;-) While it would be nice to have something like the IronPython Tools for Visual Studio -Â http://ironpython.net/tools/Â - I''d rather see IronRuby pass more of RubySpec, get more standard libraries, like OpenSSL, implemented (I know, I know, patches are welcome), and fix some critical bugs, like the one that prevents upgrading RubyGems via `gem up --system` (which in turn prevents the easy use of cool libs like Bundler). I personally think that 1.8.7 is a better goal than 1.9.1; I''ve heard some prominent Ruby community members like Yehuda Katz complain about 1.9.1 on Twitter. -- Will Green http://hotgazpacho.org/ On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne@gmail.com> wrote: Personally, I''d like to see integration into VS. What is everyone using to edit their IronRuby code? _______________________________________________ Ironruby-core mailing list Ironruby-core-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/ironruby-core
I use Emacs :). I''m a rebel! On 5/12/2010 7:58 AM, Thomas Gagne wrote:> Personally, I''d like to see integration into VS. > > What is everyone using to edit their IronRuby code? > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
Notepad++ or Vim depending on what I''m doing at that moment. --Alex On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne at gmail.com> wrote:> Personally, I''d like to see integration into VS. > > What is everyone using to edit their IronRuby code? > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
Martin Smith wrote:> 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, > Martin1. Speed up for performance (as fast as JRuby). 2. Pre-Compilation for easy transfering ruby components to .net (I like ActiveRecord!) 3. Asp.Net MVC Ruby ext as an offical supports. -- Posted via http://www.ruby-forum.com/.
Regarding perf, do you have a particular scenario that we should speed up? Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ray Linn Sent: Thursday, May 13, 2010 11:00 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] What''s next? Martin Smith wrote:> 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, > Martin1. Speed up for performance (as fast as JRuby). 2. Pre-Compilation for easy transfering ruby components to .net (I like ActiveRecord!) 3. Asp.Net MVC Ruby ext as an offical supports. -- Posted via http://www.ruby-forum.com/. _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Ray Linn wrote:> Martin Smith wrote: > > 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 > > 1. Speed up for performance (as fast as JRuby).According to the ruby-benchmark-suite and other startup performance benchmarks (Rails and such), we''re on par with JRuby performance. Are you using the MSI installer? If not, you''ll have to NGEN the binaries yourself, which increase performance significantly (ngen install DLLS+EXE); the MSI does this for you (as long as you haven''t unchecked the option). If you are NGEN-ing, then please let us know where you see a significant performance difference (as Tomas just said =P).> 2. Pre-Compilation for easy transfering ruby components to .net (I like > ActiveRecord!)I''d like some more clarification on what you need to be easier. Today you can use ActiveRecord from C# with something like this (not entirely accurate at all but you get the idea): // Host IronRuby var ruby = IronRuby.Ruby.CreateEngine(); var scope = ruby.CreateScope(); // Load ActiveRecord and a ActiveRecord Model ruby.RequireFile("rubygems", scope); ruby.Execute("require ''active_record''", scope); ruby.RequireFile("posts", scope); dynamic Post = ruby.Runtime.Globals.MyModel; // Call a very dynamic method =) var val = Post.find_by_title_and_published("My Post", true); Pre-compilation wouldn''t help with this, as any pre-compilation support wouldn''t generate actual CLI-compliant types ... it would just take the IL that we generate at runtime and store it in a DLL. As I mentioned before, we''d only support producing actual CLI types through a clr-type feature, enabling of annotating your Ruby code, and you wouldn''t want to annotate all of ActiveRecord. =)> 3. Asp.Net MVC Ruby ext as an offical supports.You want both MVC *AND* Rails? Geesh =P The be very frank, we''ll need a lot of community help to make IronRuby.AspNetMvc integration really good, as we''re not web-framework experts. So, please contribute -- just like Ivan has. =) I might spend more time on it for a talk here and there, but I''d really like the community to get much more involved, actually being a crucial force in building out parts of IronRuby. ~Jimmy
I know that, technically, pre-compilation does not get you much in terms of functionality, but it gets us very far in terms of deployment and ability to use this professionally. It''s troubling to my employer if I have to tell him that the thousands of hours of work we put in, the customer can just open up and look at. Yes, even compiled code can be reverse engineered, but at least you are not handing it out on a silver platter. It would be great if we can do more about security of source, but since we can''t, this is the least we can ask for. I''m not going to argue about what it gets you, because I know there are not functional gains or any true security gains, but I just wanted to voice my opinion and say that I strongly favor it. thanks, Bassel Jimmy Schementi wrote:> Ray Linn wrote: >> >> 1. Speed up for performance (as fast as JRuby). > > According to the ruby-benchmark-suite and other startup performance > benchmarks (Rails and such), we''re on par with JRuby performance. Are > you using the MSI installer? If not, you''ll have to NGEN the binaries > yourself, which increase performance significantly (ngen install > DLLS+EXE); the MSI does this for you (as long as you haven''t unchecked > the option). If you are NGEN-ing, then please let us know where you see > a significant performance difference (as Tomas just said =P). > >> 2. Pre-Compilation for easy transfering ruby components to .net (I like >> ActiveRecord!) > > I''d like some more clarification on what you need to be easier. Today > you can use ActiveRecord from C# with something like this (not entirely > accurate at all but you get the idea): > > // Host IronRuby > var ruby = IronRuby.Ruby.CreateEngine(); > var scope = ruby.CreateScope(); > > // Load ActiveRecord and a ActiveRecord Model > ruby.RequireFile("rubygems", scope); > ruby.Execute("require ''active_record''", scope); > ruby.RequireFile("posts", scope); > dynamic Post = ruby.Runtime.Globals.MyModel; > > // Call a very dynamic method =) > var val = Post.find_by_title_and_published("My Post", true); > > Pre-compilation wouldn''t help with this, as any pre-compilation support > wouldn''t generate actual CLI-compliant types ... it would just take the > IL that we generate at runtime and store it in a DLL. As I mentioned > before, we''d only support producing actual CLI types through a clr-type > feature, enabling of annotating your Ruby code, and you wouldn''t want to > annotate all of ActiveRecord. =) > >> 3. Asp.Net MVC Ruby ext as an offical supports. > > You want both MVC *AND* Rails? Geesh =P The be very frank, we''ll need a > lot of community help to make IronRuby.AspNetMvc integration really > good, as we''re not web-framework experts. So, please contribute -- just > like Ivan has. =) I might spend more time on it for a talk here and > there, but I''d really like the community to get much more involved, > actually being a crucial force in building out parts of IronRuby. > > > ~Jimmy-- Posted via http://www.ruby-forum.com/.
Hi Tomas, So all of the dialogs in our application are built using IR. The first time any dialog is used there''s probably a second or two delay, then there''s probably a half second (or maybe a bit less) delay each time a new dialog is required for the first time. I''ve thought about doing all of this on a secondary thread at startup, but that would require "unwinding" our code a bit. Presumably we could just require all the dialog ruby code when we fire up the app. This would probably work and would potentially take a few seconds. Right now, our application is deployed via mono on the mac, so we''re using the .net 2.0 sp1 binaries and they''re just sitting there alongside our binaries. We''re still deciding about whether we''ll go with .NET 2.0 sp1 or .NET 4 for our next PC version and will use the IR binary for the framework version we decide on. I would say we''re not "requiring" (in the ruby sense of the word) anything too exotic, just a bunch of ruby files at runtime. We use a small subset of the standard library. Do you know what happens if I change the compilation threshold while running, btw? Seriously, i cant thank you guys enough for the great work you do. Martin On Wed, May 12, 2010 at 1:00 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> How long does it take to require all the files you need? Do you use installed IronRuby v1.0 binaries for .NET 4.0 or do you build IronRuby yourself? > Can you be specific about what you''re requiring? > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > Sent: Wednesday, May 12, 2010 11:27 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] What''s next? > > You guys have hit the nail on the head for me I actually want it for both reasons: to provide some loose protection for our code and to improve startup times. > > I was thinking about doing something around packaging like you guys were talking about, but i think then I''d have to redefine Kernel.require to make sure that all the require statements execute properly. For code protection, it only provided small benefits (a determined code stealer would easily circumvent the protections), but if it helped with startup times that would benefit us greatly. > > The issue is that we use IR for our UI layer so the first time they ask for any dialog it needs to compile quite a bit of code so the first time they load a dialog can take some time. ?I''ve thought of changing this so we do the compilation at startup but i''m not quite sure if that will work. ?I''d envision something like this: > > 1) set compilation threshold to 0 (compile immediately) > 2) execute "require ''file''" for each ruby script > 3)set compilation threshold to 1 so eval doesn''t compile everything (we semi-extensively use eval) > > Would something like this be possible? Is the compilation threshold settable dynamically? > > Thanks in advance, > Martin > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
Well based on what you''re describing it sounds like Duby (or is it Mirah now?) might be a good fit. I''m getting ready to start putting some time into creating a .NET backend for Duby. It''ll be a ways off for you, but something to consider in the future. -Zac On 5/14/2010 1:51 PM, Bassel Samman wrote:> I know that, technically, pre-compilation does not get you much in terms > of functionality, but it gets us very far in terms of deployment and > ability to use this professionally. It''s troubling to my employer if I > have to tell him that the thousands of hours of work we put in, the > customer can just open up and look at. Yes, even compiled code can be > reverse engineered, but at least you are not handing it out on a silver > platter. It would be great if we can do more about security of source, > but since we can''t, this is the least we can ask for. I''m not going to > argue about what it gets you, because I know there are not functional > gains or any true security gains, but I just wanted to voice my opinion > and say that I strongly favor it. > > thanks, > > Bassel > > > Jimmy Schementi wrote: > >> Ray Linn wrote: >> >>> 1. Speed up for performance (as fast as JRuby). >>> >> According to the ruby-benchmark-suite and other startup performance >> benchmarks (Rails and such), we''re on par with JRuby performance. Are >> you using the MSI installer? If not, you''ll have to NGEN the binaries >> yourself, which increase performance significantly (ngen install >> DLLS+EXE); the MSI does this for you (as long as you haven''t unchecked >> the option). If you are NGEN-ing, then please let us know where you see >> a significant performance difference (as Tomas just said =P). >> >> >>> 2. Pre-Compilation for easy transfering ruby components to .net (I like >>> ActiveRecord!) >>> >> I''d like some more clarification on what you need to be easier. Today >> you can use ActiveRecord from C# with something like this (not entirely >> accurate at all but you get the idea): >> >> // Host IronRuby >> var ruby = IronRuby.Ruby.CreateEngine(); >> var scope = ruby.CreateScope(); >> >> // Load ActiveRecord and a ActiveRecord Model >> ruby.RequireFile("rubygems", scope); >> ruby.Execute("require ''active_record''", scope); >> ruby.RequireFile("posts", scope); >> dynamic Post = ruby.Runtime.Globals.MyModel; >> >> // Call a very dynamic method =) >> var val = Post.find_by_title_and_published("My Post", true); >> >> Pre-compilation wouldn''t help with this, as any pre-compilation support >> wouldn''t generate actual CLI-compliant types ... it would just take the >> IL that we generate at runtime and store it in a DLL. As I mentioned >> before, we''d only support producing actual CLI types through a clr-type >> feature, enabling of annotating your Ruby code, and you wouldn''t want to >> annotate all of ActiveRecord. =) >> >> >>> 3. Asp.Net MVC Ruby ext as an offical supports. >>> >> You want both MVC *AND* Rails? Geesh =P The be very frank, we''ll need a >> lot of community help to make IronRuby.AspNetMvc integration really >> good, as we''re not web-framework experts. So, please contribute -- just >> like Ivan has. =) I might spend more time on it for a talk here and >> there, but I''d really like the community to get much more involved, >> actually being a crucial force in building out parts of IronRuby. >> >> >> ~Jimmy >> >
Maybe what you need is background compilation/preparation, which could reduce initial execution by going straight to JIT''d code without having to wait for compilation. On Fri, May 14, 2010 at 10:46 PM, Martin Smith <martin.smith.jr at gmail.com>wrote:> Hi Tomas, > > So all of the dialogs in our application are built using IR. The first > time any dialog is used there''s probably a second or two delay, then > there''s probably a half second (or maybe a bit less) delay each time a > new dialog is required for the first time. I''ve thought about doing > all of this on a secondary thread at startup, but that would require > "unwinding" our code a bit. Presumably we could just require all the > dialog ruby code when we fire up the app. This would probably work > and would potentially take a few seconds. > > Right now, our application is deployed via mono on the mac, so we''re > using the .net 2.0 sp1 binaries and they''re just sitting there > alongside our binaries. We''re still deciding about whether we''ll go > with .NET 2.0 sp1 or .NET 4 for our next PC version and will use the > IR binary for the framework version we decide on. I would say we''re > not "requiring" (in the ruby sense of the word) anything too exotic, > just a bunch of ruby files at runtime. We use a small subset of the > standard library. > > Do you know what happens if I change the compilation threshold while > running, btw? > > Seriously, i cant thank you guys enough for the great work you do. > Martin > > On Wed, May 12, 2010 at 1:00 PM, Tomas Matousek > <Tomas.Matousek at microsoft.com> wrote: > > How long does it take to require all the files you need? Do you use > installed IronRuby v1.0 binaries for .NET 4.0 or do you build IronRuby > yourself? > > Can you be specific about what you''re requiring? > > > > Tomas > > > > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > > Sent: Wednesday, May 12, 2010 11:27 AM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] What''s next? > > > > You guys have hit the nail on the head for me I actually want it for both > reasons: to provide some loose protection for our code and to improve > startup times. > > > > I was thinking about doing something around packaging like you guys were > talking about, but i think then I''d have to redefine Kernel.require to make > sure that all the require statements execute properly. For code protection, > it only provided small benefits (a determined code stealer would easily > circumvent the protections), but if it helped with startup times that would > benefit us greatly. > > > > The issue is that we use IR for our UI layer so the first time they ask > for any dialog it needs to compile quite a bit of code so the first time > they load a dialog can take some time. I''ve thought of changing this so we > do the compilation at startup but i''m not quite sure if that will work. I''d > envision something like this: > > > > 1) set compilation threshold to 0 (compile immediately) > > 2) execute "require ''file''" for each ruby script > > 3)set compilation threshold to 1 so eval doesn''t compile everything (we > semi-extensively use eval) > > > > Would something like this be possible? Is the compilation threshold > settable dynamically? > > > > Thanks in advance, > > Martin > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100515/9ae88481/attachment.html>
We do in fact compile hot code on background thread while interpreting it on main thread. Are IronRuby and DLR binaries NGEN''d (or whatever is ahead-of-time compilation called on Mono)? Could you try it on Windows with .NET4 to see if there is any difference? Compilation threshold is read-only. It''s only meant to be changed for debugging and benchmarking purposes. Not to make some app faster or slower. I can''t help much without seeing the exact code that you are running/requiring. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Rodrigo Kumpera Sent: Saturday, May 15, 2010 8:05 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] What''s next? Maybe what you need is background compilation/preparation, which could reduce initial execution by going straight to JIT''d code without having to wait for compilation. On Fri, May 14, 2010 at 10:46 PM, Martin Smith <martin.smith.jr at gmail.com<mailto:martin.smith.jr at gmail.com>> wrote: Hi Tomas, So all of the dialogs in our application are built using IR. The first time any dialog is used there''s probably a second or two delay, then there''s probably a half second (or maybe a bit less) delay each time a new dialog is required for the first time. I''ve thought about doing all of this on a secondary thread at startup, but that would require "unwinding" our code a bit. Presumably we could just require all the dialog ruby code when we fire up the app. This would probably work and would potentially take a few seconds. Right now, our application is deployed via mono on the mac, so we''re using the .net 2.0 sp1 binaries and they''re just sitting there alongside our binaries. We''re still deciding about whether we''ll go with .NET 2.0 sp1 or .NET 4 for our next PC version and will use the IR binary for the framework version we decide on. I would say we''re not "requiring" (in the ruby sense of the word) anything too exotic, just a bunch of ruby files at runtime. We use a small subset of the standard library. Do you know what happens if I change the compilation threshold while running, btw? Seriously, i cant thank you guys enough for the great work you do. Martin On Wed, May 12, 2010 at 1:00 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:> How long does it take to require all the files you need? Do you use installed IronRuby v1.0 binaries for .NET 4.0 or do you build IronRuby yourself? > Can you be specific about what you''re requiring? > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Martin Smith > Sent: Wednesday, May 12, 2010 11:27 AM > To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> > Subject: Re: [Ironruby-core] What''s next? > > You guys have hit the nail on the head for me I actually want it for both reasons: to provide some loose protection for our code and to improve startup times. > > I was thinking about doing something around packaging like you guys were talking about, but i think then I''d have to redefine Kernel.require to make sure that all the require statements execute properly. For code protection, it only provided small benefits (a determined code stealer would easily circumvent the protections), but if it helped with startup times that would benefit us greatly. > > The issue is that we use IR for our UI layer so the first time they ask for any dialog it needs to compile quite a bit of code so the first time they load a dialog can take some time. I''ve thought of changing this so we do the compilation at startup but i''m not quite sure if that will work. I''d envision something like this: > > 1) set compilation threshold to 0 (compile immediately) > 2) execute "require ''file''" for each ruby script > 3)set compilation threshold to 1 so eval doesn''t compile everything (we semi-extensively use eval) > > Would something like this be possible? Is the compilation threshold settable dynamically? > > Thanks in advance, > Martin > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> > http://rubyforge.org/mailman/listinfo/ironruby-core >_______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100515/1938c179/attachment.html>
For me personally performance isn''t a show stopper. I know I''m working with dynamic language and am willing to pay the lookup tax in exchange for much faster turn-around on applications and libraries. What is a show stopper for me (and is in fact one of the biggest the reasons I''m now using jruby/MRI for our applications instead of ironruby) is the fact that OpenSSL doesn''t work completely and that *nix isn''t supported properly at all, as I tend to favor certificate based auth for internal apps. While I''m very much willing to do some work to make that happen I''m currently mostly interested in meeting my own cut-throat deadlines. So instead of performance my vote definitely goes to much better library support (in particular openssl) and better *nix support. also the proposed ir -S gem doesn''t work properly on a buch of OS''es. Those are things I''d like to see fixed + ruby 1.9 support. --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Web: http://whiterabbitconsulting.eu - http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) Microsoft IronRuby/C# MVP On Sat, May 15, 2010 at 7:19 PM, Tomas Matousek < Tomas.Matousek at microsoft.com> wrote:> We do in fact compile hot code on background thread while interpreting it > on main thread. > > > > Are IronRuby and DLR binaries NGEN?d (or whatever is ahead-of-time > compilation called on Mono)? Could you try it on Windows with .NET4 to see > if there is any difference? > > > > Compilation threshold is read-only. It?s only meant to be changed for > debugging and benchmarking purposes. Not to make some app faster or slower. > > I can?t help much without seeing the exact code that you are > running/requiring. > > > > Tomas > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Rodrigo Kumpera > *Sent:* Saturday, May 15, 2010 8:05 AM > > *To:* ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] What''s next? > > > > Maybe what you need is background compilation/preparation, which could > reduce initial execution by going straight to JIT''d code without having to > wait for compilation. > > > > > > On Fri, May 14, 2010 at 10:46 PM, Martin Smith <martin.smith.jr at gmail.com> > wrote: > > Hi Tomas, > > So all of the dialogs in our application are built using IR. The first > time any dialog is used there''s probably a second or two delay, then > there''s probably a half second (or maybe a bit less) delay each time a > new dialog is required for the first time. I''ve thought about doing > all of this on a secondary thread at startup, but that would require > "unwinding" our code a bit. Presumably we could just require all the > dialog ruby code when we fire up the app. This would probably work > and would potentially take a few seconds. > > Right now, our application is deployed via mono on the mac, so we''re > using the .net 2.0 sp1 binaries and they''re just sitting there > alongside our binaries. We''re still deciding about whether we''ll go > with .NET 2.0 sp1 or .NET 4 for our next PC version and will use the > IR binary for the framework version we decide on. I would say we''re > not "requiring" (in the ruby sense of the word) anything too exotic, > just a bunch of ruby files at runtime. We use a small subset of the > standard library. > > Do you know what happens if I change the compilation threshold while > running, btw? > > Seriously, i cant thank you guys enough for the great work you do. > Martin > > On Wed, May 12, 2010 at 1:00 PM, Tomas Matousek > > <Tomas.Matousek at microsoft.com> wrote: > > > How long does it take to require all the files you need? Do you use > installed IronRuby v1.0 binaries for .NET 4.0 or do you build IronRuby > yourself? > > Can you be specific about what you''re requiring? > > > > Tomas > > > > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > > Sent: Wednesday, May 12, 2010 11:27 AM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] What''s next? > > > > You guys have hit the nail on the head for me I actually want it for both > reasons: to provide some loose protection for our code and to improve > startup times. > > > > I was thinking about doing something around packaging like you guys were > talking about, but i think then I''d have to redefine Kernel.require to make > sure that all the require statements execute properly. For code protection, > it only provided small benefits (a determined code stealer would easily > circumvent the protections), but if it helped with startup times that would > benefit us greatly. > > > > The issue is that we use IR for our UI layer so the first time they ask > for any dialog it needs to compile quite a bit of code so the first time > they load a dialog can take some time. I''ve thought of changing this so we > do the compilation at startup but i''m not quite sure if that will work. I''d > envision something like this: > > > > 1) set compilation threshold to 0 (compile immediately) > > 2) execute "require ''file''" for each ruby script > > 3)set compilation threshold to 1 so eval doesn''t compile everything (we > semi-extensively use eval) > > > > Would something like this be possible? Is the compilation threshold > settable dynamically? > > > > Thanks in advance, > > Martin > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100515/227fdda1/attachment-0001.html>
On 15/05/2010, at 8:51 AM, Bassel Samman wrote:> Yes, even compiled code can be > reverse engineered, but at least you are not handing it out on a silver > platter.Ummm... Yes you are. Have you seen reflector? Unless you''re writing all your code in C++, you''re pretty much shipping the source. Every ignorant manager seems to have this attitude that just because someone can see the source somehow means that you''ll lose your intellectual property or your program will get hacked. This is blatantly false - how many years have we all been using open source software!!?!? yet the opinion still keeps hanging around like a bad smell. </rant> Sorry :-)
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.Schementi at 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" <will at 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 < <davidescobar at ieee.org> > davidescobar at 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.Matousek at microsoft.com> >> Tomas.Matousek at 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-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *David Escobar >>> *Sent:* Tuesday, May 11, 2010 5:48 PM >>> >>> *To:* <ironruby-core at rubyforge.org>ironruby-core at 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.Matousek at microsoft.com> >>> Tomas.Matousek at 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-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> >>> ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >>> Sent: Tuesday, May 11, 2010 11:14 AM >>> To: <ironruby-core at rubyforge.org>ironruby-core at 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 at rubyforge.org>Ironruby-core at rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org >>> <http://rubyforge.org/mailman/listinfo/ironruby-core> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org >> <http://rubyforge.org/mailman/listinfo/ironruby-core> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100525/3379cbd2/attachment.html>
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.Schementi at 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" <will at 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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar >> Sent: Tuesday, May 11, 2010 5:48 PM >> >> >> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >> Sent: Tuesday, May 11, 2010 11:14 AM >> To: ironruby-core at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core--- Stuart Ellis stuart at stuartellis.eu
+1 except for targeting 1.8.7. The Ruby community as a whole is really pushing to get off of 1.8, so the faster IronRuby gets there, the better. Ryan On Wed, May 12, 2010 at 9:14 AM, Will Green <will at hotgazpacho.org> wrote:> Vim ;-) > > While it would be nice to have something like the IronPython Tools for > Visual Studio - http://ironpython.net/tools/ - I''d rather see IronRuby > pass more of RubySpec, get more standard libraries, like OpenSSL, > implemented (I know, I know, patches are welcome), and fix some critical > bugs, like the one that prevents upgrading RubyGems via `gem up --system` > (which in turn prevents the easy use of cool libs like Bundler). > > I personally think that 1.8.7 is a better goal than 1.9.1; I''ve heard some > prominent Ruby community members like Yehuda Katz complain about 1.9.1 on > Twitter. > > -- > Will Green > http://hotgazpacho.org/ > > > On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne <tggagne at gmail.com> wrote: > >> Personally, I''d like to see integration into VS. >> >> What is everyone using to edit their IronRuby code? >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100525/0083fa5f/attachment-0001.html>
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 <stuart at 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.Schementi at 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" <will at 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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar >>> Sent: Tuesday, May 11, 2010 5:48 PM >>> >>> >>> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >>> Sent: Tuesday, May 11, 2010 11:14 AM >>> To: ironruby-core at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > --- > Stuart Ellis > stuart at stuartellis.eu > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
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 <stuart at 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.Schementi at 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" <will at 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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar >>>> Sent: Tuesday, May 11, 2010 5:48 PM >>>> >>>> >>>> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >>>> Sent: Tuesday, May 11, 2010 11:14 AM >>>> To: ironruby-core at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>>> >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> --- >> Stuart Ellis >> stuart at stuartellis.eu >> >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core--- Stuart Ellis stuart at stuartellis.eu
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 <stuart at 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 <stuart at 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.Schementi at 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" <will at 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 <davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar > >>>> Sent: Tuesday, May 11, 2010 5:48 PM > >>>> > >>>> > >>>> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith > >>>> Sent: Tuesday, May 11, 2010 11:14 AM > >>>> To: ironruby-core at 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 at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/ironruby-core > >>>> > >>>> _______________________________________________ > >>>> Ironruby-core mailing list > >>>> Ironruby-core at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/ironruby-core > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ironruby-core mailing list > >>>> Ironruby-core at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/ironruby-core > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ironruby-core mailing list > >>>> Ironruby-core at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/ironruby-core > >>> > >>> _______________________________________________ > >>> Ironruby-core mailing list > >>> Ironruby-core at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/ironruby-core > >>> > >>> > >>> _______________________________________________ > >>> Ironruby-core mailing list > >>> Ironruby-core at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > >> --- > >> Stuart Ellis > >> stuart at stuartellis.eu > >> > >> > >> > >> > >> _______________________________________________ > >> Ironruby-core mailing list > >> Ironruby-core at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/ironruby-core > >> > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > --- > Stuart Ellis > stuart at stuartellis.eu > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100604/68f1ba15/attachment-0001.html>
+1 for rubymine. On Fri, Jun 4, 2010 at 12:08 AM, Shay Friedman <shay.friedman at 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 <stuart at 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 <stuart at 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.Schementi at 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" <will at 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 < >> davidescobar at 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.Matousek at 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-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] On Behalf Of David Escobar >> >>>> Sent: Tuesday, May 11, 2010 5:48 PM >> >>>> >> >>>> >> >>>> To: ironruby-core at 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.Matousek at 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-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] On Behalf Of Martin Smith >> >>>> Sent: Tuesday, May 11, 2010 11:14 AM >> >>>> To: ironruby-core at 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 at rubyforge.org >> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >>>> >> >>>> _______________________________________________ >> >>>> Ironruby-core mailing list >> >>>> Ironruby-core at rubyforge.org >> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ironruby-core mailing list >> >>>> Ironruby-core at rubyforge.org >> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Ironruby-core mailing list >> >>>> Ironruby-core at rubyforge.org >> >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >>> >> >>> _______________________________________________ >> >>> Ironruby-core mailing list >> >>> Ironruby-core at rubyforge.org >> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >>> >> >>> >> >>> _______________________________________________ >> >>> Ironruby-core mailing list >> >>> Ironruby-core at rubyforge.org >> >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> >> --- >> >> Stuart Ellis >> >> stuart at stuartellis.eu >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Ironruby-core mailing list >> >> Ironruby-core at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> > _______________________________________________ >> > Ironruby-core mailing list >> > Ironruby-core at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/ironruby-core >> >> --- >> Stuart Ellis >> stuart at stuartellis.eu >> >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100604/099e9459/attachment-0001.html>