By the way, if anyone is depending on IronRuby.Ruby.GetExecutionContex,
your code will break when built/run against the HEAD of the sources. As
a work-around, here’s the implementation of GetExecutionContext which
you can just use in your own code:
using Microsoft.Scripting.Hosting;
using Microsoft.Scripting.Utils;
using IronRuby.Runtime;
// ...
public static RubyContext GetExecutionContext(ScriptEngine
engine) {
ContractUtils.RequiresNotNull(engine, “engine”);
var context =
Microsoft.Scripting.Hosting.Providers.HostingHelpers.GetLanguageContext(engine)
as RubyContext;
if (context == null) {
throw new InvalidOperationException(“Given engine is not
a Ruby engine”);
}
return context;
}
public static RubyContext GetExecutionContext(ScriptRuntime
runtime) {
ContractUtils.RequiresNotNull(runtime, “runtime”);
return GetExecutionContext(Ruby.GetEngine(runtime));
}
Let us know if you use this, and what you use it for, so we can figure
out whether removing it is the right call.
~Jimmy
From: [email protected]
[mailto:[email protected]] On Behalf Of Jimmy
Schementi
Sent: Monday, March 08, 2010 2:27 AM
To: Tomas M.
Cc: ‘[email protected]’
Subject: Re: [Ironruby-core] IronRuby.Ruby.GetExecutionContext removed
Tomas,
What reasons did we have for removing this in the first place? It also
affects anyone writing code that uses our Ruby types/library methods in
their own code (for providing the correct types to Ruby code);
IronRuby.Rack does this.
As a work-around, are we really expecting people to use
Microsoft.Scripting.Hosting.Providers.HostinHelpers.GetLanguageContext
directly?
~Jimmy
From: Jimmy S.
Sent: Thursday, March 04, 2010 5:32 PM
To: Tomas M.
Cc: [email protected]
Subject: IronRuby.Ruby.GetExecutionContext removed
including the mailing list as people might run into this …
Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is
there any other way to get to the instance of IronRuby.Ruby.RubyContext?
I’d presume anyone hosting IronRuby and define ruby global variables was
using DefineGlobalVariable; so they’d run into this. Looks like
ScriptEngine.LanguageContext is now internal as well …
I specifically found this while updating DLRConsole, and simply removed
the places where I was using ruby global variables.