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
~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