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.

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.

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.

We removed it for 2 reasons:

  1.  RubyContext is not a supported public API and can change any 
    

time. Hosting APIs on the other hand (i.e. IronRuby.Ruby class) will
remain stable. We’ll try hard not to introduce breaking changes.

  1.  RubyContext is not remoting aware while Hosting APIs are.
    

HostingHelpers.GetLanguageContext can be used as a last resort
workaround, however there is no guarantee we won’t break such usage any
time in future by changing RubyContext.
What methods on RubyContext does IronRuby.Rack need? If there is some
feature that should be exposed via Hosting API we should add it.

Tomas

From: Jimmy S.
Sent: Monday, March 08, 2010 2:27 AM
To: Tomas M.
Cc: ‘[email protected]
Subject: RE: 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.