IR 103 -> IR 107 update broke my program that relies on execution of
"require '...'" strings.
I don't know wether this is bug in IR 107 (or incorrect behaviour on IR
103 and earlier), so I did not file a bug report yet.
I made a simplified version of my program that exposes this difference
with minimal amount of code (this is a fully contained functional
program):
------------------------------------------------------------------------
---
using System;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
using Ruby.Runtime;
class Program
{
static void Main(string[] args) {
try { new Program().Run(); }
catch (Exception ex) { Console.WriteLine(ex.ToString()); }
}
private void Run() {
System.IO.File.WriteAllText("f.rb", @"
module F
def F.hello
puts 'F:Hello'
end
end
");
ExecuteStr("require 'f.rb'");
ExecuteStr("F.hello"); // IR SVN 107 fails here: "uninitialized
constant Object::F"
}
private ScriptRuntime _scriptRuntime;
private ScriptScope _sharedScope;
public ScriptRuntime ScriptRuntime {
get {
if (_scriptRuntime == null)
{
_scriptRuntime = ScriptRuntime.Create();
_scriptRuntime.GlobalOptions.DebugMode = true;
}
return _scriptRuntime;
}
}
public ScriptEngine Engine { get { return
ScriptRuntime.GetEngine(typeof(RubyContext)); } }
public ScriptScope SharedScope {
get {
if (_sharedScope == null) _sharedScope =
Engine.CreateScope();
return _sharedScope;
}
}
public object ExecuteStr(string code) {
return
Engine.CreateScriptSourceFromString(code).Execute(SharedScope);
}
} // class
------------------------------------------------------------------------
---
Program behaves in following way in IR SVN 103 / 107:
SVN 103
F:Hello
Press any key to continue . . .
SVN 107:
System.MemberAccessException: uninitialized constant Object::F
at Ruby.Builtins.ModuleOps.ConstantMissing(RubyModule self, SymbolId
name) in
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Builtins\ModuleOps.cs:
line 642
at _stub_##6(Closure , CallSite , CodeContext , RubyModule , SymbolId
)
at Microsoft.Scripting.Utils.InvokeHelper`6.Invoke(Object arg0,
Object arg1, Object arg2, Object arg3, Object arg4) in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting.Core\Utils\ReflectedC
aller.Generated.cs:line 374
at Microsoft.Scripting.Utils.ReflectedCaller.InvokeInstance(Object
instance, Object[] args) in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting.Core\Utils\ReflectedC
aller.Generated.cs:line 38
...
at Microsoft.Scripting.Hosting.ScriptSource.Execute[T](ScriptScope
scope) in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting\Hosting\ScriptSource.
cs:line153
at IronRubyTest1.Program.ExecuteStr[T](String code, Object[] par) in
C:\DATA\IronRubyTest1\Program.cs:line 92
at IronRubyTest1.Program.ExecuteStr(String code, Object[] par) in
C:\DATA\IronRubyTest1\Program.cs:line 86
at IronRubyTest1.Program.Run() in
C:\DATA\IronRubyTest1\Program.cs:line 40
at IronRubyTest1.Program.Main(String[] args) in
C:\DATA\IronRubyTest1\Program.cs:line 19
Press any key to continue . . .
-------------------
I will continue to use SVN 103 for now. If it turns out that SVN 107
behavior is "as designed" (and SVN 103 behavior that I relied on
faulty), I will change my client code to deal with it.
Robert Brotherus
Software architect
Napa Ltd
Tammasaarenkatu 3, Helsinki FI-00180
P.O.Box 470, Helsinki FI-00181
Tel. +358 9 22 813 1
Direct. +358 9 22 813 611
GSM +358 45 11 456 02
Fax. +358 9 22 813 800
Email: [EMAIL PROTECTED]
www.napa.fi
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
