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