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
Notepad++ or Vim depending on what I’m doing at that moment.
–Alex
I use Emacs :). I’m a rebel!
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
Speed up for performance (as fast as JRuby).
Pre-Compilation for easy transfering ruby components to .net (I like
ActiveRecord!)
Asp.Net MVC Ruby ext as an offical supports.
Regarding perf, do you have a particular scenario that we should speed
up?
Tomas
Ray L. wrote:
- 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).
- 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. =)
- 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 S. wrote:
Ray L. wrote:
- 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).
- 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. =)
- 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
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 M.
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
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.
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: [email protected]
[mailto:[email protected]] On Behalf Of Rodrigo
Kumpera
Sent: Saturday, May 15, 2010 8:05 AM
To: [email protected]
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
<[email protected]mailto:[email protected]> 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 M.
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.
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 S. <
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.
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
On Sat, May 15, 2010 at 7:19 PM, Tomas M. <
+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
Hey Stuart,
Try out rubymine. We use that and it works pretty well even with
IronRuby…
Martin
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:
Any other features people are curious about? Now is definitely the time to voice your opinions
Will G.
On Tue, May 11, 2010 at 6:04 PM, Tomas M. [email protected] wrote:
To: [email protected]
Tomas
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.
Ironruby-core mailing list
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
Stuart E.
[email protected]
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:
Any other features people are curious about? Now is definitely the time to voice your opinions
Will G.
On Tue, May 11, 2010 at 6:04 PM, Tomas M. [email protected] wrote:
To: [email protected]
Tomas
Now that IronRuby 1.0 has shipped (congrats!!), what’s next on the docket?
Ironruby-core mailing list
Stuart E.
[email protected]
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 F. | Microsoft Visual C#/IronRuby MVP | Author of IronRuby
Unleashed | Sela Technology Center
Blog: http://IronShay.com | Twitter: http://twitter.com/ironshay
+1 for rubymine.
On Fri, Jun 4, 2010 at 12:08 AM, Shay F.
[email protected]wrote:
Hey Stuart,
been happy using Ruby without an IDE, but I am fairly certain that myWill, what you are describing is the preferred way of packaging Ruby
As far as the other discussed features go, let me draw a line in the
for Ruby; as in we will not emit both similar types and method bodies as C#.
As far as non-.NET related features, we’ll be targeting Ruby 1.9
On May 11, 2010, at 7:15 PM, “Will G.” [email protected]Will G.
in a static language or for unit testing purposes?
Well, there is a pretty simple way how to package up .rb files into
[email protected]] On Behalf Of David Escobar
statically from C#, then all the better.Now that IronRuby 1.0 has shipped (congrats!!), what’s next on the
[email protected]
[email protected]
[email protected]
Ironruby-core mailing list
–
“The explanation requiring the fewest assumptions is most likely to be
correct.”
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs