IronRuby r106 is out

This fixes the DLR Tuple bug #19971. This, along with Tomas’ shelveset
later today should fix most of the reported blocking issues. We should
be able to check in the latest Ruby specs later today as well.

Thanks,
-John

Whoops … some files didn’t actually get committed on the last checkin.
Strange. You’ll need to update to r107 to compile successfully.

Thanks,
-John

From: [email protected]
[mailto:[email protected]] On Behalf Of John L.
(IRONRUBY)
Sent: Wednesday, May 14, 2008 8:44 AM
To: [email protected]
Subject: [Ironruby-core] IronRuby r106 is out

This fixes the DLR Tuple bug #19971. This, along with Tomas’ shelveset
later today should fix most of the reported blocking issues. We should
be able to check in the latest Ruby specs later today as well.

Thanks,
-John

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 B.
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

Hi Robert,

I just tried and it didn’t repro here with 108/109. Can you grab 109 and
see if this repros on your machine? I hope this isn’t some strange
locale thing again …

Thanks,
-John

I believe the problem is that a two engines are being created. One by
the
call to ScriptRuntime.GetEngine(typeof(RubyContext)); inside Robert’s
code
and another one inside Kernel#require.

Pete

I can reproduce this bug on r109.
First I had to remove the SIGNED compilation symbol otherwise the
program
couldn’t load the IronRuby assembly. I wonder if this is relevant and
has
some bearing on why John couldn’t reproduce it?
Pete

Yes, in the previous versions, the external projects had the option of a
build configuration which did not have the SIGNED compilation symbol.
This
seems to have disappeared.
The significance of this is that when you try to create the Ruby runtime
it
tries to look up the assembly for the language. If SIGNED is set then
it
looks them up with fully named assemblies (and so expects the assembly
to be
signed correctly). Obviously we are not provided with the private key
to
sign the assemblies and so the lookup fails.

For some reason the RubyConsole project stills works even with this
compilation symbol set. But if you create your own app then it fails.
All
you have to do is remove this symbol from the build for the
Microsoft.Scripting project and the program will run.

The runtime bug you reported is a bug somehow, although I am not sure if
there is some other way of creating the Engine that stops multiple
engines
from being created. It seems to me that the engine is looked up using
the
language context as a key - in this case a RubyContext object. If you
step
through the code there are two of these objects and they do not have
equivalent HashCodes so that triggers the creation of a new Engine.
Either
the object comparison for these objects needs to be fixed or the use of
multiple RubyContexts needs to be fixed.

Pete

From: Peter Bacon D.

I can reproduce this bug on r109.
First I had to remove the SIGNED compilation symbol otherwise the
program couldn’t load the IronRuby assembly.
I wonder if this is relevant and has some bearing on why John couldn’t
reproduce it?

Yes, I had to remove the ‘SIGNED’ compilation symbols as well. This has
to do with what Wayne K. was already earlier commenting about:

On Tue, May 13, 2008 at 10:47 PM, Wayne K. [email protected]
wrote:

I’m having trouble with strong names in the latest version.
Is IronRuby.dll meant to be strongly named?
The Microsoft.Scripting.Hosting.ScriptRuntimeSetup constructor has a
hard coded dependence to:
IronRuby, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
But building IronRuby.dll using IronRuby.csproj doesn’t seem to
produce a strongly named assembly.
I also note that IronRuby.csproj doesn’t set SIGNED but the other
projects do.

If someone can provide instructions on how to compile the simple program
I sent without removing the SIGNED symbols from the libraries, then I
can see if I get it working. The SIGNED symbols appeared somewhere
around SVN 103 and broke my program as well but at that time removing
the SIGNED allowed working again (even with the ‘require’).

Robert B.
Software architect
Napa Ltd
Email: [email protected]
www.napa.fi

That shouldn’t be the case. There can be at most one engine per language
per ScriptRuntime.

The program seems to work on my machine.

Tomas

When I step through the code, I can see that the Engines dictionary has
3
entries. One is the InvariantLanguage and two are keyed on RubyContext.

It appears that the comparison of the RubyContext object that is already
in
the dictionary and the new one (the one passed in by the Kernel#require
method) are not “equal” and so the code creates a new entry in the
dictionary for the second RubyContext object.

I am not exactly sure what comparison algorithm is being used but
certainly
if you look at the two RubyContext objects they have different
HashCodes. I
did briefly try overriding GetHashCode on RubyContext to see if this
made
any difference but it didn’t appear to.

Pete

Robert B.

If someone can provide instructions on how to compile the simple
program I sent without removing the
SIGNED symbols from the libraries, then I can see if I get it working.
The SIGNED symbols appeared
somewhere around SVN 103 and broke my program as well but at that time
removing the SIGNED allowed
working again (even with the ‘require’).

I must correct myself: The simple program (attached here again) does
COMPILE against all these IR versions but with IR 103+ that are compiled
with the default “SIGNED” symbol, it fails runtime:

Microsoft.Scripting.Runtime.MissingTypeException: Type ‘IronRuby,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35,
Ruby.Runtime.RubyContext’ is missing or cannot be loaded. —>
System.IO.FileLoadException: Could not load file or assembly ‘IronRuby,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or
one of its dependencies. The located assembly’s manifest definition does
not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: ‘IronRuby, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35’
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, Assembly locationHint,
StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
at Microsoft.Scripting.PlatformAdaptationLayer.LoadAssembly(String
name) in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting.Core\PlatformAdaptati
onLayer.cs:line 125
at
Microsoft.Scripting.Runtime.ScriptDomainManager.LanguageRegistration.Loa
dLanguageContext() in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting.Core\Runtime\ScriptDo
mainManager.cs:line 165


at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope
scope) in
C:\programs\IronRuby\trunk\src\Microsoft.Scripting\Hosting\ScriptSource.
cs:line 146

at Program.ExecuteStr(String code) in
C:\DATA\IronRubyTest1\Program.cs:line 49
at Program.Run() in C:\DATA\IronRubyTest1\Program.cs:line 21
at Program.Main(String[] args) in
C:\DATA\IronRubyTest1\Program.cs:line 9
Press any key to continue . . .


When SIGNED is turned off, then the programs works correctly at IR 103,
but fails at IR 107+ to the reported earlier
“System.MemberAccessException: uninitialized constant Object::F”.

I have now submitted bug (20167) about this.

Robert B.
Software architect
Napa Ltd
Email: [email protected]
www.napa.fi

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs