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
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
