Martin Smith wrote:

> I'm looking (as you can see in my subject line) for a little guidance on the 
> best
> way to embed IronRuby into my Application.  I've already successfully
> embedded ruby into the application, so these questions are more about the
> nitty gritty details of embedding.  The application is mostly written in C# 
> and
> occasionally calls out to ruby to create UI components that are placed on
> other UI components themselves created in either C# or ruby.  Generally,
> but not always, the C# code will need to call into ruby to do the 
> initialization.
> 
> I can think of a few ways to do this:
> (1) At app startup spawn up a RubyEngine, execute a file that "warms up" the
> engine and "requires" all or most of the ruby files that contain the classes
> that will create the UI components
> (2) At app startup create a new RubyEngine and do nothing.  Then, as
> needed, issue commands to the runtime with a ScriptScope that require and
> initialize UI components.
> (3) Every time I need to execute new ruby code, create a new engine.

Depends on what performance characteristics you want :) The DLR's isolation 
mechanism is a "ScriptRuntime", and actually only creates one ScriptEngine per 
language per ScriptRuntime. So you're option #3 would create a new 
ScriptRuntime to get any type of isolation between ruby-code executions. Option 
#1 and #2 are really no different, other than that #1 will be warmed up and 
just compile the code you give it, which #2 will have to compile dependencies.

> Really, I'm mostly thinking about 1 vs 2.  Are class definitions "shared"
> between script scopes? More specifically, if I require the same file twice in
> different script scopes will they point to the same code or will the runtime
> need to recompile and re-jit the code for each individual script scope?

Ruby constants, which includes classes and modules, are essentially globals, so 
they are stored on the global scope, which means they are accessible anywhere, 
especially between scopes. ScriptScope only isolates top-level locals and 
methods.
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to