What's next?

Hey Guys,

Now that IronRuby 1.0 has shipped (congrats!!), what’s next on the
docket? :slight_smile:
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

On Wed, May 12, 2010 at 10:06 AM, Tomas M. <
[email protected]> 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.

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 M. <

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 M. <

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 G.
http://hotgazpacho.org/

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: [email protected]
[mailto:[email protected]] On Behalf Of David Escobar
Sent: Tuesday, May 11, 2010 5:48 PM
To: [email protected]
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 M.
<[email protected]mailto:[email protected]>
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

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-.NEThttp://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 :slight_smile:

~Jimmy

On May 11, 2010, at 7:15 PM, “Will G.”
<[email protected]mailto:[email protected]> 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 G.
http://hotgazpacho.org/http://hotgazpacho.org/

On Tue, May 11, 2010 at 9:20 PM, David Escobar
<mailto:[email protected][email protected]mailto:[email protected]>
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 M.
<mailto:[email protected][email protected]mailto:[email protected]>
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:[email protected]
[email protected]mailto:[email protected]
[mailto:mailto:[email protected][email protected]mailto:[email protected]]
On Behalf Of David Escobar
Sent: Tuesday, May 11, 2010 5:48 PM

To: mailto:[email protected]
[email protected]mailto:[email protected]
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 M.
<mailto:[email protected][email protected]mailto:[email protected]>
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

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.

I’d be really interested in it. I’ll email you offline to ask a few more
specific questions.

-Zac

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 S. <

I believe the example for embedding the assemblies to create a .exe that
you’re looking for is: GitHub - rifraf/IronRubyEmbeddedApps: This repository shows how to create 'standalone' .Net applications written in Ruby.

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

Personally, I’d like to see integration into VS.

What is everyone using to edit their IronRuby code?

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

Vim :wink:

While it would be nice to have something like the IronPython Tools for
Visual Studio - 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 K. complain about 1.9.1
on
Twitter.


Will G.
http://hotgazpacho.org/

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

Vim ☺

From: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
Sent: Wednesday, May 12, 2010 9:14 AM
To: [email protected]
Subject: Re: [Ironruby-core] What’s next?

Vim :wink:

While it would be nice to have something like the IronPython Tools for
Visual Studio - 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 K. complain about
1.9.1 on Twitter.


Will G.
http://hotgazpacho.org/

On Wed, May 12, 2010 at 10:58 AM, Thomas Gagne
<[email protected]mailto:[email protected]> wrote:
Personally, I’d like to see integration into VS.

What is everyone using to edit their IronRuby code?


Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

vim :slight_smile:


Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
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

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


Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core