What I did in IronrubyMVC to allow controller classes etc to be reloaded was look in the globals if a class already exists and if it does remove the constant. That way it will always reload some the class. http://github.com/casualjim/ironrubymvc/blob/79efbd0f5baf52d3fbfe8f21a0349d6343dc994b/IronRubyMvc/Core/RubyEngine.cs#L92
That being said. This a pretty naive way of forcing reloads, I'm sure there is a better way but that one works for me atm. I create scopes per request, so that would be your option #2 I guess --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Sep 2, 2009 at 8:39 AM, Martin Smith <[email protected]>wrote: > Thanks Jimmy! This was quite helpful. > > I've actually decided to go with 1 and 2. Actually, this isn't > strictly speaking true... If I'm running in debug, I recreate the > runtime with every invocation so I can test/run on the fly. Thanks > for your help! > > Best, > Martin > > On Tue, Sep 1, 2009 at 12:39 PM, Jimmy > Schementi<[email protected]> wrote: > > 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 > > > _______________________________________________ > Ironruby-core mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/ironruby-core >
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
