Forum: IronRuby 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 Schementi
Sent: Thursday, March 04, 2010 5:32 PM
To: Tomas Matousek
Cc: ironruby-core@rubyforge.org
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: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Jimmy 
Schementi
Sent: Monday, March 08, 2010 2:27 AM
To: Tomas Matousek
Cc: 'ironruby-core@rubyforge.org'
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 Schementi
Sent: Thursday, March 04, 2010 5:32 PM
To: Tomas Matousek
Cc: ironruby-core@rubyforge.org
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.

2)      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 Schementi
Sent: Monday, March 08, 2010 2:27 AM
To: Tomas Matousek
Cc: 'ironruby-core@rubyforge.org'
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 Schementi
Sent: Thursday, March 04, 2010 5:32 PM
To: Tomas Matousek
Cc: ironruby-core@rubyforge.org
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.