From Orion.Edwards at gallagher.co  Mon Oct  3 15:57:52 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Tue, 4 Oct 2011 08:57:52 +1300
Subject: [Ironruby-core] Pull requests
Message-ID: <OFCAEB428D.5EEBAE91-ONCC25791E.006D0ED7-CC25791E.006DAB4A@gallagher.local>

I've had an open pull request which resolves a deadlock in IronRuby itself 
sitting on github for over a month now. 
There are also two other pull requests which improve visual studio 
integration.

While I can understand perhaps why the core ironruby committers might not 
know about the visual studio integration and hence put off merging those, 
surely the patch to resolve the deadlock is useful?
I currently have all the developers in my organization working off my fork 
of IronRuby , as the deadlock issue is impossible to ignore for us. It is 
somewhat embarrassing to say "oh, don't install the official ironruby, 
install my custom one from over here"

Is there any intention to merge any of these pull requests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111004/2dc9f019/attachment-0001.html>

From doug.blank at gmail.com  Mon Oct  3 16:22:12 2011
From: doug.blank at gmail.com (Doug Blank)
Date: Mon, 3 Oct 2011 16:22:12 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
Message-ID: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>

FYI,

When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm
getting a failure:

% git clone https://github.com/IronLanguages/main.git IronLanguages
% cd IronLanguages
% xbuild Solutions/Ruby.sln /p:Configuration="v2Release"
...
Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly convert
type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
to `System.Collections.Generic.IEnumerable<object>'. An explicit
conversion exists (are you missing a cast?)

Building for the regular configuration is fine.

-Doug

From Tomas.Matousek at microsoft.com  Mon Oct  3 21:34:10 2011
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 4 Oct 2011 01:34:10 +0000
Subject: [Ironruby-core] Pull requests
In-Reply-To: <OFCAEB428D.5EEBAE91-ONCC25791E.006D0ED7-CC25791E.006DAB4A@gallagher.local>
References: <OFCAEB428D.5EEBAE91-ONCC25791E.006D0ED7-CC25791E.006DAB4A@gallagher.local>
Message-ID: <9597F4A19BFDB342B6E90963100C330829E865D3@CH1PRD0302MB132.namprd03.prod.outlook.com>

Yes, sorry about the delay. I just didn't have time to look at it yet - I was out last two weekends.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Monday, October 03, 2011 12:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Pull requests

I've had an open pull request which resolves a deadlock in IronRuby itself sitting on github for over a month now.
There are also two other pull requests which improve visual studio integration.

While I can understand perhaps why the core ironruby committers might not know about the visual studio integration and hence put off merging those, surely the patch to resolve the deadlock is useful?
I currently have all the developers in my organization working off my fork of IronRuby , as the deadlock issue is impossible to ignore for us. It is somewhat embarrassing to say "oh, don't install the official ironruby, install my custom one from over here"

Is there any intention to merge any of these pull requests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111004/3da7b1a3/attachment.html>

From doug.blank at gmail.com  Wed Oct  5 11:10:22 2011
From: doug.blank at gmail.com (Doug Blank)
Date: Wed, 5 Oct 2011 11:10:22 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
Message-ID: <CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>

Reported as:
http://ironruby.codeplex.com/workitem/6523

-Doug

On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
> FYI,
>
> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm
> getting a failure:
>
> % git clone https://github.com/IronLanguages/main.git IronLanguages
> % cd IronLanguages
> % xbuild Solutions/Ruby.sln /p:Configuration="v2Release"
> ...
> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly convert
> type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
> to `System.Collections.Generic.IEnumerable<object>'. An explicit
> conversion exists (are you missing a cast?)
>
> Building for the regular configuration is fine.
>
> -Doug
>

From jschementi at gmail.com  Wed Oct  5 11:15:16 2011
From: jschementi at gmail.com (Jimmy Schementi)
Date: Wed, 5 Oct 2011 11:15:16 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
Message-ID: <18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>

Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.

Please let the list know if you want to take this on, 

~js

On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:

> Reported as:
> http://ironruby.codeplex.com/workitem/6523
> 
> -Doug
> 
> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>> FYI,
>> 
>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm
>> getting a failure:
>> 
>> % git clone https://github.com/IronLanguages/main.git IronLanguages
>> % cd IronLanguages
>> % xbuild Solutions/Ruby.sln /p:Configuration="v2Release"
>> ...
>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly convert
>> type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>> to `System.Collections.Generic.IEnumerable<object>'. An explicit
>> conversion exists (are you missing a cast?)
>> 
>> Building for the regular configuration is fine.
>> 
>> -Doug
>> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From curth at microsoft.com  Wed Oct  5 11:17:58 2011
From: curth at microsoft.com (Curt Hagenlocher)
Date: Wed, 5 Oct 2011 15:17:58 +0000
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
Message-ID: <9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>

Is "v2Release" intended to target CLRv2? If so, this error is because that version of C# and the BCL don't support covariance for IEnumerable.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Wednesday, October 05, 2011 8:15 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing

Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.

Please let the list know if you want to take this on, 

~js

On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:

> Reported as:
> http://ironruby.codeplex.com/workitem/6523
> 
> -Doug
> 
> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>> FYI,
>> 
>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm 
>> getting a failure:
>> 
>> % git clone https://github.com/IronLanguages/main.git IronLanguages % 
>> cd IronLanguages % xbuild Solutions/Ruby.sln 
>> /p:Configuration="v2Release"
>> ...
>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly convert 
>> type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>> to `System.Collections.Generic.IEnumerable<object>'. An explicit 
>> conversion exists (are you missing a cast?)
>> 
>> Building for the regular configuration is fine.
>> 
>> -Doug
>> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core





From doug.blank at gmail.com  Wed Oct  5 13:48:10 2011
From: doug.blank at gmail.com (Doug Blank)
Date: Wed, 5 Oct 2011 13:48:10 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
Message-ID: <CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>

On Wed, Oct 5, 2011 at 11:17 AM, Curt Hagenlocher <curth at microsoft.com> wrote:
> Is "v2Release" intended to target CLRv2? If so, this error is because that version of C# and the BCL don't support covariance for IEnumerable.

I believe that "v2Release" targets the 3.5 framework (is that the same
as CLRv2?), but someone can correct me if I am wrong.

I'm currently running a previous version of IronRuby built for
"v2Release", so perhaps there is at least a patch that we can apply
(will a simple cast be sufficient?).

I'm trying to build the latest versions of IronRuby and IronPython for
inclusion into the next version of Ubuntu. The versions built on
dlr-0.9 were just removed. However, I must admit that I don't know if
people will really need v2Releases... I just thought I'd build them if
I could.

-Doug

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Wednesday, October 05, 2011 8:15 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
>
> Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.
>
> Please let the list know if you want to take this on,
>
> ~js
>
> On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:
>
>> Reported as:
>> http://ironruby.codeplex.com/workitem/6523
>>
>> -Doug
>>
>> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>> FYI,
>>>
>>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm
>>> getting a failure:
>>>
>>> % git clone https://github.com/IronLanguages/main.git IronLanguages %
>>> cd IronLanguages % xbuild Solutions/Ruby.sln
>>> /p:Configuration="v2Release"
>>> ...
>>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly convert
>>> type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>>> to `System.Collections.Generic.IEnumerable<object>'. An explicit
>>> conversion exists (are you missing a cast?)
>>>
>>> Building for the regular configuration is fine.
>>>
>>> -Doug
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From curth at microsoft.com  Wed Oct  5 14:35:50 2011
From: curth at microsoft.com (Curt Hagenlocher)
Date: Wed, 5 Oct 2011 18:35:50 +0000
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
	<CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>
Message-ID: <9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>

Yep, .NET 2.0, 3.0 and 3.5 all share the same fundamental CLR and the BCL bits are strictly additive. A simple cast is not sufficient; the code will need modification. One approach would be to insert a 3.5-only adapter function which does something like this:

IEnumerable<object> Convert(IEnumerable<MutableString> collection) {
    foreach (var item in collection) {
        yield return item;
    }
}

(I'd need to refer to the context of the code to make any other suggestions.)

Is downlevel-framework support still a goal for IronRuby? I seem to recall that IronPython 2.7 is .NET 4.0-only.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Doug Blank
Sent: Wednesday, October 05, 2011 10:48 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing

On Wed, Oct 5, 2011 at 11:17 AM, Curt Hagenlocher <curth at microsoft.com> wrote:
> Is "v2Release" intended to target CLRv2? If so, this error is because that version of C# and the BCL don't support covariance for IEnumerable.

I believe that "v2Release" targets the 3.5 framework (is that the same as CLRv2?), but someone can correct me if I am wrong.

I'm currently running a previous version of IronRuby built for "v2Release", so perhaps there is at least a patch that we can apply (will a simple cast be sufficient?).

I'm trying to build the latest versions of IronRuby and IronPython for inclusion into the next version of Ubuntu. The versions built on
dlr-0.9 were just removed. However, I must admit that I don't know if people will really need v2Releases... I just thought I'd build them if I could.

-Doug

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org 
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy 
> Schementi
> Sent: Wednesday, October 05, 2011 8:15 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
>
> Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.
>
> Please let the list know if you want to take this on,
>
> ~js
>
> On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:
>
>> Reported as:
>> http://ironruby.codeplex.com/workitem/6523
>>
>> -Doug
>>
>> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>> FYI,
>>>
>>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm 
>>> getting a failure:
>>>
>>> % git clone https://github.com/IronLanguages/main.git IronLanguages 
>>> % cd IronLanguages % xbuild Solutions/Ruby.sln 
>>> /p:Configuration="v2Release"
>>> ...
>>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly 
>>> convert type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>>> to `System.Collections.Generic.IEnumerable<object>'. An explicit 
>>> conversion exists (are you missing a cast?)
>>>
>>> Building for the regular configuration is fine.
>>>
>>> -Doug
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core





From jschementi at gmail.com  Wed Oct  5 15:15:06 2011
From: jschementi at gmail.com (Jimmy Schementi)
Date: Wed, 5 Oct 2011 15:15:06 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
	<CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
Message-ID: <B4A93C44-2139-4D62-A747-61AA29EF2942@gmail.com>

> Is downlevel-framework support still a goal for IronRuby? I seem to recall that IronPython 2.7 is .NET 4.0-only.

We were keeping around < 4.0 support for Windows Phone. It's always up for discussion whether we continue doing that; I vote yes.

On Oct 5, 2011, at 2:35 PM, Curt Hagenlocher wrote:

> Yep, .NET 2.0, 3.0 and 3.5 all share the same fundamental CLR and the BCL bits are strictly additive. A simple cast is not sufficient; the code will need modification. One approach would be to insert a 3.5-only adapter function which does something like this:
> 
> IEnumerable<object> Convert(IEnumerable<MutableString> collection) {
>    foreach (var item in collection) {
>        yield return item;
>    }
> }
> 
> (I'd need to refer to the context of the code to make any other suggestions.)
> 
> Is downlevel-framework support still a goal for IronRuby? I seem to recall that IronPython 2.7 is .NET 4.0-only.
> 
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Doug Blank
> Sent: Wednesday, October 05, 2011 10:48 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
> 
> On Wed, Oct 5, 2011 at 11:17 AM, Curt Hagenlocher <curth at microsoft.com> wrote:
>> Is "v2Release" intended to target CLRv2? If so, this error is because that version of C# and the BCL don't support covariance for IEnumerable.
> 
> I believe that "v2Release" targets the 3.5 framework (is that the same as CLRv2?), but someone can correct me if I am wrong.
> 
> I'm currently running a previous version of IronRuby built for "v2Release", so perhaps there is at least a patch that we can apply (will a simple cast be sufficient?).
> 
> I'm trying to build the latest versions of IronRuby and IronPython for inclusion into the next version of Ubuntu. The versions built on
> dlr-0.9 were just removed. However, I must admit that I don't know if people will really need v2Releases... I just thought I'd build them if I could.
> 
> -Doug
> 
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org 
>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy 
>> Schementi
>> Sent: Wednesday, October 05, 2011 8:15 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
>> 
>> Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.
>> 
>> Please let the list know if you want to take this on,
>> 
>> ~js
>> 
>> On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:
>> 
>>> Reported as:
>>> http://ironruby.codeplex.com/workitem/6523
>>> 
>>> -Doug
>>> 
>>> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>>> FYI,
>>>> 
>>>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm 
>>>> getting a failure:
>>>> 
>>>> % git clone https://github.com/IronLanguages/main.git IronLanguages 
>>>> % cd IronLanguages % xbuild Solutions/Ruby.sln 
>>>> /p:Configuration="v2Release"
>>>> ...
>>>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly 
>>>> convert type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>>>> to `System.Collections.Generic.IEnumerable<object>'. An explicit 
>>>> conversion exists (are you missing a cast?)
>>>> 
>>>> Building for the regular configuration is fine.
>>>> 
>>>> -Doug
>>>> 
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> 
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> 
> 
> 
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From doug.blank at gmail.com  Wed Oct  5 16:23:21 2011
From: doug.blank at gmail.com (Doug Blank)
Date: Wed, 5 Oct 2011 16:23:21 -0400
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
	<CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
Message-ID: <CAAusYCg-WV=0G6itC9HfoA_5c-P-hj1Jf_wU62NzsUpHKhKRww@mail.gmail.com>

On Wed, Oct 5, 2011 at 2:35 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
> Yep, .NET 2.0, 3.0 and 3.5 all share the same fundamental CLR and the BCL bits are strictly additive. A simple cast is not sufficient; the code will need modification. One approach would be to insert a 3.5-only adapter function which does something like this:
>
> IEnumerable<object> Convert(IEnumerable<MutableString> collection) {
> ? ?foreach (var item in collection) {
> ? ? ? ?yield return item;
> ? ?}
> }
>
> (I'd need to refer to the context of the code to make any other suggestions.)

Ok, thanks.

> Is downlevel-framework support still a goal for IronRuby? I seem to recall that IronPython 2.7 is .NET 4.0-only.

There are many systems still using Mono 2.6.7 which is CLRv2. However,
I think that this may change sooner than later as distros like Ubuntu
are moving on up.

-Doug

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Doug Blank
> Sent: Wednesday, October 05, 2011 10:48 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
>
> On Wed, Oct 5, 2011 at 11:17 AM, Curt Hagenlocher <curth at microsoft.com> wrote:
>> Is "v2Release" intended to target CLRv2? If so, this error is because that version of C# and the BCL don't support covariance for IEnumerable.
>
> I believe that "v2Release" targets the 3.5 framework (is that the same as CLRv2?), but someone can correct me if I am wrong.
>
> I'm currently running a previous version of IronRuby built for "v2Release", so perhaps there is at least a patch that we can apply (will a simple cast be sufficient?).
>
> I'm trying to build the latest versions of IronRuby and IronPython for inclusion into the next version of Ubuntu. The versions built on
> dlr-0.9 were just removed. However, I must admit that I don't know if people will really need v2Releases... I just thought I'd build them if I could.
>
> -Doug
>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org
>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
>> Schementi
>> Sent: Wednesday, October 05, 2011 8:15 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] IronRuby v2Release xbuild is failing
>>
>> Can someone sign up to looking into this? After confirming this builds in .NET and not Mono, I'd first find out if this is a known Mono bug, and then provide a patch to IronRuby to work-around this.
>>
>> Please let the list know if you want to take this on,
>>
>> ~js
>>
>> On Oct 5, 2011, at 11:10 AM, Doug Blank wrote:
>>
>>> Reported as:
>>> http://ironruby.codeplex.com/workitem/6523
>>>
>>> -Doug
>>>
>>> On Mon, Oct 3, 2011 at 4:22 PM, Doug Blank <doug.blank at gmail.com> wrote:
>>>> FYI,
>>>>
>>>> When trying to build IronRuby for a v2Release under Mono 2.10.2, I'm
>>>> getting a failure:
>>>>
>>>> % git clone https://github.com/IronLanguages/main.git IronLanguages
>>>> % cd IronLanguages % xbuild Solutions/Ruby.sln
>>>> /p:Configuration="v2Release"
>>>> ...
>>>> Builtins/RangeOps.cs(307,17): error CS0266: Cannot implicitly
>>>> convert type `System.Collections.Generic.IEnumerable<IronRuby.Builtins.MutableString>'
>>>> to `System.Collections.Generic.IEnumerable<object>'. An explicit
>>>> conversion exists (are you missing a cast?)
>>>>
>>>> Building for the regular configuration is fine.
>>>>
>>>> -Doug
>>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From jdhardy at gmail.com  Wed Oct  5 18:06:45 2011
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 5 Oct 2011 15:06:45 -0700
Subject: [Ironruby-core] IronRuby v2Release xbuild is failing
In-Reply-To: <9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
References: <CAAusYCgGX=YSeinkBdSEsSWLMxCxs4vsGUJxE35_EJxnPfNB3w@mail.gmail.com>
	<CAAusYChcqq+OdV8GMcrnSUy2L1QM1kMXOYFQq3_j5d27DBrW_A@mail.gmail.com>
	<18AEF788-C712-48FD-86DD-CCB9641552E2@gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02CD1E@CH1PRD0302MB127.namprd03.prod.outlook.com>
	<CAAusYCh+zgmzch6FceBvCDuD8gAPOaOYdn6jHtNf69=Jx-uTRA@mail.gmail.com>
	<9424DD7C6CEBFF4A8955DC2B879DABAC02E0E7@CH1PRD0302MB127.namprd03.prod.outlook.com>
Message-ID: <CAF7AXFEW0zLLqMidnELv+XLKSvwucf9KJ1_ZyuHm6Ni31+Tw4g@mail.gmail.com>

On Wed, Oct 5, 2011 at 11:35 AM, Curt Hagenlocher <curth at microsoft.com> wrote:
> Is downlevel-framework support still a goal for IronRuby? I seem to recall that IronPython 2.7 is .NET 4.0-only.

IronPython only 'officially' supports 4, but we occasionally make sure
that it compiles for 3.5 as well (usually when someone points out that
it's broken).

There are a couple of embedders that haven't moved their host apps to
4 yet, but are fine to build IronPython themselves for 3.5.

- Jeff

From kibiz0r at gmail.com  Mon Oct 17 18:59:53 2011
From: kibiz0r at gmail.com (Kibiz0r)
Date: Mon, 17 Oct 2011 18:59:53 -0400
Subject: [Ironruby-core] Help setting up environment on Mono 2.10.2 OS X 10.7
Message-ID: <CALZfoDJ4Om6OwOcgtCL7BveRioSN+taJGBQ7gbhrritxcpwwAQ@mail.gmail.com>

Goal: Equip my C# project with a sane, useful IronRuby testing environment
that is consistent across OS X and Windows. To that end, I hope to use RVM,
Bundler (with binstubs), Rake, RR, and RSpec.

Background:
Per http://www.mono-project.com/Release_Notes_Mono_2.10#Languages:
"Starting with Mono 2.10, we are bundling the open source F# compilers and
tools, and the IronRuby <http://ironruby.net/> and
IronPython<http://ironpython.net/> systems
in our Linux packages as well as in our Mac installer."
So, my /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/
contains: bin with all /compiled/ IronRuby assemblies and configs (not
including important stuff like gem, etc.), and Lib with a regular ol Ruby
standard library with IronRuby goodies mixed in.

Problems:
- RVM doesn't support IronRuby at all, and all patches or forks that I found
have gone stale.
- requirement.rb patch is necessary to even begin using rubygems:
http://www.ruby-forum.com/topic/1864531
- Mono's IronRuby distribution doesn't include gem/igem, so I ganked it from
the Github repo @v1.1.3, but executing something like "ir
IronLanguages/Languages/Ruby/Scripts/bin/gem install bundler --backtrace"
produces this output:
ERROR:  Loading command: install (IndexError)
    Array index is out of range.
mscorlib:0:in `GetChars'
mscorlib:0:in `GetChars'
 mscorlib:0:in `GetChars'
mscorlib:0:in `ReadBuffer'
mscorlib:0:in `Read'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
mscorlib:0:in `require'
 mscorlib:0:in `CallSite.Target'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 mscorlib:0:in `require'
mscorlib:0:in `invoke_object__this___Func`5<CallSite, RubyScope, object,
object, object>_CallSite_RubyScope_object_object'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::Commands::InstallCommand
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:164:in
`const_missing'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:164:in
`load_and_instantiate'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:90:in
`[]'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:146:in
`find_command'
 /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:133:in
`process_args'
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/command_manager.rb:104:in
`run'
- Using standard Ruby, I can "gem install bundler
--install-dir /Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1"
and
"bundle install --binstubs", but then running ir bin/rspec spec/pong_spec.rb
produces:
mscorlib:0:in `invoke_object__this___Func`4<object, Proc, object,
object>_object_Proc_object': undefined method `realpath' for File:Class
(NoMethodError)
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/pathname.rb:446:in
`realpath'

I can get around this by editing the binstubs to just use __FILE__ instead
of Pathname.new(__FILE__).realpath, which gives me:

$
GEM_PATH=/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1
ir bin/rspec spec/pong_spec.rb
mscorlib:0:in `invoke_object__this___Func`4<object, Proc, object,
object>_object_Proc_object': can't convert Pathname into String (TypeError)
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/settings.rb:5:in
`initialize'
 from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:185:in
`settings'
 from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:261:in
`configure_gem_home_and_path'
 from mscorlib:0:in `invoke_object__this___Func`4<object, Proc, object,
object>_object_Proc_object'
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:82:in
`configure'
 from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:136:in
`definition'
 from mscorlib:0:in `invoke_object__this___Func`4<object, Proc, object,
object>_object_Proc_object'
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:126:in
`load'
 from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:110:in
`setup'
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
 from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/bin/../Lib/ruby/1.9.1/rubygems/custom_require.rb:28:in
`require'
from
/Library/Frameworks/Mono.framework/Versions/2.10.2/lib/ironruby/Lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/setup.rb:17

Current workarounds:
Steal gem from IronLanguages, patch requirement.rb, don't use RVM, don't use
Bundler, use standard Ruby to install gems to IronRuby's gems dir.

Plea for help:
The lack of RVM+Bundler support and all the manual mucking around is
definitely sub-optimal; is anyone working on this problem, or does anyone
have suggestions on where to start trying to fix it? I really want to show
my OS X Ruby brethren all the cool stuff that's possible with IronRuby, but
there's no way I can make them go through this.

-- 
Michael Harrington | Rock Star from Mars
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111017/4aa3a8b1/attachment-0001.html>

From lists at ruby-forum.com  Tue Oct 18 06:26:07 2011
From: lists at ruby-forum.com (luis jesus c.)
Date: Tue, 18 Oct 2011 12:26:07 +0200
Subject: [Ironruby-core] Help! spec/story (LoadError)
Message-ID: <b7cb4c3a70d11895c8b6ab60be9db03b@ruby-forum.com>

someone can help me.
I am a rookie, I'm trying to run this code in IronRuby:
require 'rubygems'
require 'spec/story'

-The problem is that I always get this error:

C:/Program Files(x86)/IronRuby
1.1/lib/ruby/1.9.1/rubygems/custom_require.rb:
29:in `require': no such file to load -- spec/story (LoadError)
        from C:/Program Files(x86)/IronRuby
1.1/lib/ruby/1.9.1/rubygems/custom_require.rb:in 'require'
       from (ir):1

-I saw a post with a case like mine
(http://www.ruby-forum.com/topic/525838), I followed your steps and have
done well, but I still leave the same error.

someone knows how to fix it?

-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Wed Oct 19 11:24:29 2011
From: lists at ruby-forum.com (Lewis L.)
Date: Wed, 19 Oct 2011 17:24:29 +0200
Subject: [Ironruby-core] override method_missing()
Message-ID: <67116cb21fcbd6b076ffc5eaca5b8ad9@ruby-forum.com>

Hi,
Is there a way to override the method_missing method and keep the
SetVariable lookup behavior from ScriptScope?
For example,

in C#
aScriptScope.SetVariable("a", "some_value")

in Ruby
p a
=> "some_value"

But if I do,

class << self
  def method_missing(sym, *args, &block)
    case (sym)
    when :some_case
       do_something
    else
       super #try to fallback to the original
    end
  end
end

or

class << self
  alias :old_method_missing :method_missing
  def method_missing(sym, *args, &block)
    case (sym)
    when :some_case
       do_something
    else
       old_method_missing(sym, *args, &block) #try to fallback to the
original
    end
  end
end

p a
=> NameError: undefined local variable or method 'a' for main:Object

-- 
Posted via http://www.ruby-forum.com/.

From Tomas.Matousek at microsoft.com  Wed Oct 19 12:11:02 2011
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 19 Oct 2011 16:11:02 +0000
Subject: [Ironruby-core] override method_missing()
In-Reply-To: <67116cb21fcbd6b076ffc5eaca5b8ad9@ruby-forum.com>
References: <67116cb21fcbd6b076ffc5eaca5b8ad9@ruby-forum.com>
Message-ID: <9597F4A19BFDB342B6E90963100C33082E432ABA@CH1PRD0302MB132.namprd03.prod.outlook.com>

Might be a bug.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Lewis L.
Sent: Wednesday, October 19, 2011 8:24 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] override method_missing()

Hi,
Is there a way to override the method_missing method and keep the SetVariable lookup behavior from ScriptScope?
For example,

in C#
aScriptScope.SetVariable("a", "some_value")

in Ruby
p a
=> "some_value"

But if I do,

class << self
  def method_missing(sym, *args, &block)
    case (sym)
    when :some_case
       do_something
    else
       super #try to fallback to the original
    end
  end
end

or

class << self
  alias :old_method_missing :method_missing
  def method_missing(sym, *args, &block)
    case (sym)
    when :some_case
       do_something
    else
       old_method_missing(sym, *args, &block) #try to fallback to the original
    end
  end
end

p a
=> NameError: undefined local variable or method 'a' for main:Object

--
Posted via http://www.ruby-forum.com/.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core





From lists at ruby-forum.com  Wed Oct 19 13:00:09 2011
From: lists at ruby-forum.com (Lewis L.)
Date: Wed, 19 Oct 2011 19:00:09 +0200
Subject: [Ironruby-core] override method_missing()
In-Reply-To: <67116cb21fcbd6b076ffc5eaca5b8ad9@ruby-forum.com>
References: <67116cb21fcbd6b076ffc5eaca5b8ad9@ruby-forum.com>
Message-ID: <e7b2ea06faabc41ce7ab35982e8aed1d@ruby-forum.com>

Thanks a lot. At least I won't be killing myself trying to figure out 
what I missed. FYI, I tested on version 1.1 and 1.1.3 and they seem to 
have the same issue.
Since we are on the subject, I wonder if you can spare some of your time 
help me understand this:

As far as I understand, the global environment is actually a singleton 
'main' Object. The function defined in the global scope should be 
translated to private method of Object class which is what it shows in 
iirb.bat. Not sure why ir.exe as well as the code in the ScriptEngine 
does not behave that way.

c:\Program Files\IronRuby 1.1\bin>ir
IronRuby 1.1.3.0 on .NET 4.0.30319.225
Copyright (c) Microsoft Corporation. All rights reserved.

>>> def global_hi
... puts 'hi'
... end
=> nil
>>> class A
...   def hi
...     global_hi
...   end
... end
=> nil
>>> A.new.hi
(ir):3:in `hi': undefined method `global_hi' for #<A:0x0000056> 
(NoMethodError)
        from (ir):1

>>> self.method(:global_hi)
=> #<Method: Object(#<Class:#<Object:0x0000058>>)#global_hi>
>>> exit

---------------------------------------------------------------------

c:\Program Files\IronRuby 1.1\bin>iirb
irb(main):001:0> def global_hi
irb(main):002:1>   puts 'hi'
irb(main):003:1> end
=> nil
irb(main):004:0> class A
irb(main):005:1>   def hi
irb(main):006:2>     global_hi
irb(main):007:2>   end
irb(main):008:1> end
=> nil
irb(main):009:0> A.new.hi
hi
=> nil
irb(main):010:0> self.method(:global_hi)
=> #<Method: Object#global_hi>
irb(main):011:0>

-- 
Posted via http://www.ruby-forum.com/.

From Orion.Edwards at gallagher.co  Tue Oct 25 21:21:44 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Wed, 26 Oct 2011 14:21:44 +1300
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR types,
 or ruby types backed by a CLR type
Message-ID: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>

Backstory: I'm trying to use DRb for some in-house utility code. DRb 
itself seems to work fine, but I found that when I misspelled a method 
name, instead of reporting back a NoMethodError, the IronRuby process 
crashed immediately to the console.

This is using a relatively recent build of IronRuby from Github

Steps to repro:

e = RuntimeError.new 'xyz'
dumped = Marshal.dump e
e2 = Marshal.load dumped

I would expect e2 to be equivalent to e, but instead the process crashes 
with this exception

mscorlib:0:in `_InvokeConstructor': Exception has been thrown by the 
target of an invocation. (System::Reflection::TargetInvocationException)
        from mscorlib:0:in `InvokeConstructor'
        from mscorlib:0:in `Invoke'
        from (ir):1:in `load'
        from (ir):1


Note: This also happens with any CLR type eg System::DateTime.

I looked through IronRuby's marshalling code, and it appears that the 
behaviour of Marshal.dump and Marshal.load don't align properly.

Marshal.dump is it's own self-contained set of code which essentially 
writes data to a BinaryStream. 
For ruby types, it ends up writing a series of values in a format that 
looks a lot like what I remember CRuby's marshal writing.
For CLR types, this just writes the Type name and no instance data (clr 
objects don't have ruby instance variables after all)

Marshal.load does 2 things:
1. Reads any ruby instance variables out into an Attributes dictionary
2. Uses reflection to find any non-public Constructor(SerializationInfo, 
StreamingContext) and invoke it.


For ruby types, this finds the protected RubyClass(SerializationInfo, 
StreamingContext) ctor, which calls RubyOps.DeserializeObject, which in 
turn reads the attributes dictionary and it's all fine.
For CLR types, this finds whatever constructor might exist for the CLR 
object, which does whatever it does for that type.

Unfortunately because the data that is getting passed into the CLR 
deserialization constructor came from Marshal.dump which has no knowledge 
whatsoever of CLR serialization, the whole thing crashes.

I'm no expert on CLR serialization, so I'd really appreciate some comments 
on this, as I'm not sure what to do here.

As far as I can guess however, I can see two solutions:

1. Implement Marshal.dump on top of the CLR serialization code so it 
matches Marshal.load and should therefore be able to handle CLR types too.

2. Don't allow marshalling of CLR types, and put some special-case code 
into any Ruby types that are backed by CLR types (such as Exception) so 
these at least can be serialized?

I'm going to have a crack at #1, but I'm not sure how successful this is.

Again, any feedback would be greatly appreciated.

Thanks, Orion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111026/c516d14f/attachment.html>

From Tomas.Matousek at microsoft.com  Tue Oct 25 22:13:05 2011
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 26 Oct 2011 02:13:05 +0000
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR
 types, or ruby types backed by a CLR type
In-Reply-To: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>
References: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>
Message-ID: <9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>

I think we should NOT serialize non-Ruby types for now. The implementation isn't quite working so I'd prefer we delete all code that deals with ISerializable, clean up the marshaller and if .NET serialization is needed in future implement it fully and correctly.

Marshal.dump has to output exactly the same data as CRuby implementation (for Ruby objects). Otherwise you won't be able to read data serialized by CRuby in IronRuby and vice versa.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, October 25, 2011 6:22 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR types, or ruby types backed by a CLR type

Backstory: I'm trying to use DRb for some in-house utility code. DRb itself seems to work fine, but I found that when I misspelled a method name, instead of reporting back a NoMethodError, the IronRuby process crashed immediately to the console.

This is using a relatively recent build of IronRuby from Github

Steps to repro:

e = RuntimeError.new 'xyz'
dumped = Marshal.dump e
e2 = Marshal.load dumped

I would expect e2 to be equivalent to e, but instead the process crashes with this exception

mscorlib:0:in `_InvokeConstructor': Exception has been thrown by the target of an invocation. (System::Reflection::TargetInvocationException)
        from mscorlib:0:in `InvokeConstructor'
        from mscorlib:0:in `Invoke'
        from (ir):1:in `load'
        from (ir):1


Note: This also happens with any CLR type eg System::DateTime.

I looked through IronRuby's marshalling code, and it appears that the behaviour of Marshal.dump and Marshal.load don't align properly.

Marshal.dump is it's own self-contained set of code which essentially writes data to a BinaryStream.
For ruby types, it ends up writing a series of values in a format that looks a lot like what I remember CRuby's marshal writing.
For CLR types, this just writes the Type name and no instance data (clr objects don't have ruby instance variables after all)

Marshal.load does 2 things:
1. Reads any ruby instance variables out into an Attributes dictionary
2. Uses reflection to find any non-public Constructor(SerializationInfo, StreamingContext) and invoke it.


For ruby types, this finds the protected RubyClass(SerializationInfo, StreamingContext) ctor, which calls RubyOps.DeserializeObject, which in turn reads the attributes dictionary and it's all fine.
For CLR types, this finds whatever constructor might exist for the CLR object, which does whatever it does for that type.

Unfortunately because the data that is getting passed into the CLR deserialization constructor came from Marshal.dump which has no knowledge whatsoever of CLR serialization, the whole thing crashes.

I'm no expert on CLR serialization, so I'd really appreciate some comments on this, as I'm not sure what to do here.

As far as I can guess however, I can see two solutions:

1. Implement Marshal.dump on top of the CLR serialization code so it matches Marshal.load and should therefore be able to handle CLR types too.

2. Don't allow marshalling of CLR types, and put some special-case code into any Ruby types that are backed by CLR types (such as Exception) so these at least can be serialized?

I'm going to have a crack at #1, but I'm not sure how successful this is.

Again, any feedback would be greatly appreciated.

Thanks, Orion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111026/f252b080/attachment-0001.html>

From Orion.Edwards at gallagher.co  Tue Oct 25 22:58:12 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Wed, 26 Oct 2011 15:58:12 +1300
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR
 types, or ruby types backed by a CLR type
In-Reply-To: <9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
References: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>
	<9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
Message-ID: <OF939405F1.3A8BDE0C-ONCC257935.000F0376-CC257935.0010504C@gallagher.local>

For dealing with Clr-backed objects such as Exception should we just 
create special cases in the Marshal to dump and load them? Is there any 
way I can find out what other ruby objects are actually CLR objects other 
than Exception types and the basic int, double, float types?

My experiments with extending the marshal to dump CLR types were 
interesting.
I can dump and load pure CLR types such as System::DateTime, and in theory 
it should also work seamlessly for CLR classes that have been "extended" 
by ruby.
The code is quite simple, it just extends the marshaller and add a few 
extra nonstandard type codes for CLR primitive types such as System::Int64 
that can't be dealt with by the ruby marshaller.

You wouldn't be able to unmarshal a Pure or extended CLR object from CRuby 
as it wouldn't understand these extra type codes but that doesn't make any 
sense anyway.

Because the marshal extensions preserve all the CLR information for 
exceptions, an IronRuby Exception won't be able to be loaded by CRuby, so 
to keep compatibility there would have to be special cases for Exceptions 
(and any other builtin CLR objects that masquerade as ruby objects) 
whether the ISerializable code stays or goes.

Are there any unit tests or specs for the marshalling? There doesn't seem 
to be any mention of it in IronRuby.Tests.csproj, but I haven't looked 
through all the rubyspec stuff yet.




From:   Tomas Matousek <Tomas.Matousek at microsoft.com>
To:     "ironruby-core at rubyforge.org" <ironruby-core at rubyforge.org>
Date:   26/10/2011 03:42 p.m.
Subject:        Re: [Ironruby-core] IronRuby's Marshal.dump doesn't work 
with CLR types, or ruby types backed by a CLR type
Sent by:        ironruby-core-bounces at rubyforge.org



I think we should NOT serialize non-Ruby types for now. The implementation 
isn?t quite working so I?d prefer we delete all code that deals with 
ISerializable, clean up the marshaller and if .NET serialization is needed 
in future implement it fully and correctly.
 
Marshal.dump has to output exactly the same data as CRuby implementation 
(for Ruby objects). Otherwise you won?t be able to read data serialized by 
CRuby in IronRuby and vice versa.
 
Tomas
 
From: ironruby-core-bounces at rubyforge.org [
mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, October 25, 2011 6:22 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR 
types, or ruby types backed by a CLR type
 
Backstory: I'm trying to use DRb for some in-house utility code. DRb 
itself seems to work fine, but I found that when I misspelled a method 
name, instead of reporting back a NoMethodError, the IronRuby process 
crashed immediately to the console. 

This is using a relatively recent build of IronRuby from Github 

Steps to repro: 

e = RuntimeError.new 'xyz' 
dumped = Marshal.dump e 
e2 = Marshal.load dumped 

I would expect e2 to be equivalent to e, but instead the process crashes 
with this exception 

mscorlib:0:in `_InvokeConstructor': Exception has been thrown by the 
target of an invocation. (System::Reflection::TargetInvocationException) 
        from mscorlib:0:in `InvokeConstructor' 
        from mscorlib:0:in `Invoke' 
        from (ir):1:in `load' 
        from (ir):1 


Note: This also happens with any CLR type eg System::DateTime. 

I looked through IronRuby's marshalling code, and it appears that the 
behaviour of Marshal.dump and Marshal.load don't align properly. 

Marshal.dump is it's own self-contained set of code which essentially 
writes data to a BinaryStream. 
For ruby types, it ends up writing a series of values in a format that 
looks a lot like what I remember CRuby's marshal writing. 
For CLR types, this just writes the Type name and no instance data (clr 
objects don't have ruby instance variables after all) 

Marshal.load does 2 things: 
1. Reads any ruby instance variables out into an Attributes dictionary 
2. Uses reflection to find any non-public Constructor(SerializationInfo, 
StreamingContext) and invoke it. 


For ruby types, this finds the protected RubyClass(SerializationInfo, 
StreamingContext) ctor, which calls RubyOps.DeserializeObject, which in 
turn reads the attributes dictionary and it's all fine. 
For CLR types, this finds whatever constructor might exist for the CLR 
object, which does whatever it does for that type. 

Unfortunately because the data that is getting passed into the CLR 
deserialization constructor came from Marshal.dump which has no knowledge 
whatsoever of CLR serialization, the whole thing crashes. 

I'm no expert on CLR serialization, so I'd really appreciate some comments 
on this, as I'm not sure what to do here. 

As far as I can guess however, I can see two solutions: 

1. Implement Marshal.dump on top of the CLR serialization code so it 
matches Marshal.load and should therefore be able to handle CLR types too. 


2. Don't allow marshalling of CLR types, and put some special-case code 
into any Ruby types that are backed by CLR types (such as Exception) so 
these at least can be serialized? 

I'm going to have a crack at #1, but I'm not sure how successful this is. 

Again, any feedback would be greatly appreciated. 

Thanks, Orion_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111026/ad885a36/attachment.html>

From Orion.Edwards at gallagher.co  Thu Oct 27 22:46:48 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Fri, 28 Oct 2011 15:46:48 +1300
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR
 types, or ruby types backed by a CLR type
In-Reply-To: <9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
References: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>
	<9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
Message-ID: <OF0CE9EDD8.2F7BB0E2-ONCC257937.000D7AEB-CC257937.000F4542@gallagher.local>

I've made some changes and have a pull request on Github:

https://github.com/IronLanguages/main/pull/47

The changeset is 

https://github.com/gglresearchanddevelopment/ironlanguages-main/commit/630995eca293b5b0531e821b76bab7e15c4506f6

What I did:

1. Ran load_spec and dump_spec under 
Languages\Ruby\Tests\mspec\rubyspec\core\marshal
  - Lots and lots of things failed

2. Fixed all the failures (except for one, which I can't quite figure 
out).
  - The majority of this work was around writing string encodings when 
marshalling. IronRuby now writes string encodings as per MRI 1.9.2
      - I didn't make Marshal.Read understand string encodings yet though. 
The dump-with-encoding loads the string with no error, it just won't pick 
up the encoding

  - IronRuby didn't handle loading of self-referential arrays, hashes and 
objects. I added some specs for these and fixed the Marshal.Load code
  - It appears the behaviour of calling Marshal.load passing a proc 
changed between ruby 1.8 and 1.9. It now does what MRI 1.9.2 does

3. Removed the code path from Marshal.load that was using .NET 
serialization.
 - Most things worked fine, except the ruby Range CLR class which was 
using the .NET serialization interface. 
 - As the Ruby range class is immutable we can't rely on instance variable 
setting, and unfortunately range just gets dumped as Object (no special 
token) so it doesn't really fit into the Marshal.load structure :-(
 - I added a new interface: IRubySpecialMarshalling. the range CLR class 
implements this, and Marshal.load checks for it as an alternative way of 
setting instance data.
     - This has the bonus of letting us dump subclasses of  Range. 
Previously this did not work.

4. Added code and specs for basic marshalling of Exception types. 
Currently only Exception.message and Exception.backtrace are supported, 
but this covers the majority of use cases for me.
   - Added a special case in Marshal.Write to write the exception data
   - As Exception is like Range (can't set instance variables, can't use 
.NET serialization) It uses IRubySpecialMarshalling through a proxy 
object. The proxy object is required because I can't change the CLR 
exception class to include my interface -:-(

Some notes:

- I'm not particularly happy with the way IRubySpecialMarshalling is 
working, but I'm not sure of a better way to do it. 
- Using reflection to set Exception.message sucks, but the requirement to 
unmarshal self-referential objects basically means you cannot Marshal.load 
an object's attributes an object before you create the object itself. This 
is probably no big deal in CRuby :-(
- The single failing marshal test is "loads an Array with proc". I can't 
figure out what the logic behind calling the proc is as it gets really 
complicated with lots of nested types. If anyone could shed some light on 
it that would be great.
- Where encodings have aliases, IronRuby selects a string's encoding by 
asking windows what to use based on a Codepage number. Because MRI uses a 
different bit of logic, MRI and IronRuby can abitrarily select different 
aliases. EG:

s = "foo"
s.force_encoding "cp850" 
s.force_encoding "ibm850"  # alternative which has the same effect
puts s.encoding => "CP850" in MRI, "ibm850" in IronRuby

I don't suppose this matters much, but it did make the specs harder to 
write :-(

Anyway, any feedback would be much appreciated. Thanks, Orion



From:   Tomas Matousek <Tomas.Matousek at microsoft.com>
To:     "ironruby-core at rubyforge.org" <ironruby-core at rubyforge.org>
Date:   26/10/2011 03:42 p.m.
Subject:        Re: [Ironruby-core] IronRuby's Marshal.dump doesn't work 
with CLR types, or ruby types backed by a CLR type
Sent by:        ironruby-core-bounces at rubyforge.org



I think we should NOT serialize non-Ruby types for now. The implementation 
isn?t quite working so I?d prefer we delete all code that deals with 
ISerializable, clean up the marshaller and if .NET serialization is needed 
in future implement it fully and correctly.
 
Marshal.dump has to output exactly the same data as CRuby implementation 
(for Ruby objects). Otherwise you won?t be able to read data serialized by 
CRuby in IronRuby and vice versa.
 
Tomas
 
From: ironruby-core-bounces at rubyforge.org [
mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, October 25, 2011 6:22 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR 
types, or ruby types backed by a CLR type
 
Backstory: I'm trying to use DRb for some in-house utility code. DRb 
itself seems to work fine, but I found that when I misspelled a method 
name, instead of reporting back a NoMethodError, the IronRuby process 
crashed immediately to the console. 

This is using a relatively recent build of IronRuby from Github 

Steps to repro: 

e = RuntimeError.new 'xyz' 
dumped = Marshal.dump e 
e2 = Marshal.load dumped 

I would expect e2 to be equivalent to e, but instead the process crashes 
with this exception 

mscorlib:0:in `_InvokeConstructor': Exception has been thrown by the 
target of an invocation. (System::Reflection::TargetInvocationException) 
        from mscorlib:0:in `InvokeConstructor' 
        from mscorlib:0:in `Invoke' 
        from (ir):1:in `load' 
        from (ir):1 


Note: This also happens with any CLR type eg System::DateTime. 

I looked through IronRuby's marshalling code, and it appears that the 
behaviour of Marshal.dump and Marshal.load don't align properly. 

Marshal.dump is it's own self-contained set of code which essentially 
writes data to a BinaryStream. 
For ruby types, it ends up writing a series of values in a format that 
looks a lot like what I remember CRuby's marshal writing. 
For CLR types, this just writes the Type name and no instance data (clr 
objects don't have ruby instance variables after all) 

Marshal.load does 2 things: 
1. Reads any ruby instance variables out into an Attributes dictionary 
2. Uses reflection to find any non-public Constructor(SerializationInfo, 
StreamingContext) and invoke it. 


For ruby types, this finds the protected RubyClass(SerializationInfo, 
StreamingContext) ctor, which calls RubyOps.DeserializeObject, which in 
turn reads the attributes dictionary and it's all fine. 
For CLR types, this finds whatever constructor might exist for the CLR 
object, which does whatever it does for that type. 

Unfortunately because the data that is getting passed into the CLR 
deserialization constructor came from Marshal.dump which has no knowledge 
whatsoever of CLR serialization, the whole thing crashes. 

I'm no expert on CLR serialization, so I'd really appreciate some comments 
on this, as I'm not sure what to do here. 

As far as I can guess however, I can see two solutions: 

1. Implement Marshal.dump on top of the CLR serialization code so it 
matches Marshal.load and should therefore be able to handle CLR types too. 


2. Don't allow marshalling of CLR types, and put some special-case code 
into any Ruby types that are backed by CLR types (such as Exception) so 
these at least can be serialized? 

I'm going to have a crack at #1, but I'm not sure how successful this is. 

Again, any feedback would be greatly appreciated. 

Thanks, Orion_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111028/b7ff542b/attachment-0001.html>

From Orion.Edwards at gallagher.co  Sun Oct 30 23:34:12 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Mon, 31 Oct 2011 16:34:12 +1300
Subject: [Ironruby-core] [ironlanguages-main] Ruby 1.9 marshalling
	compatibility. (630995e)
In-Reply-To: <gglresearchanddevelopment/ironlanguages-main/commit/630995eca293b5b0531e821b76bab7e15c4506f6/683915@github.com>
References: <gglresearchanddevelopment/ironlanguages-main/commit/630995eca293b5b0531e821b76bab7e15c4506f6@github.com>
	<gglresearchanddevelopment/ironlanguages-main/commit/630995eca293b5b0531e821b76bab7e15c4506f6/683915@github.com>
Message-ID: <OF0D95F940.16184A0F-ONCC25793A.0013480B-CC25793A.00139CC6@gallagher.local>

Hi Tomas (and other IronRuby devs). I'm trying to implement this, but I'm 
not sure quite how to go about dynamically invoking the 'message' and 
'backtrace' methods on the other objects.

It looks like the other methods all have a UnaryOpStorage or other kind of 
'storage' that they use to invoke other dynamic methods
 - how do I know what kind of Storage object I need to invoke methods on 
other objects?
 - I'm not sure where I get these storage objects from? It appears that in 
this case the language runtime will pass them in as needed, but if I need 
to call a ruby method from another location (eg inside Marshal.cs), how do 
I go about getting the storage object?

Thanks, Orion



From:   Tomas Matousek 
<reply+c-683915-ae54ce679190ef3de090cba9240521883afb62af at reply.github.com>
To:     Gallagher Group R&D Department <orione at gallagher.co.nz>
Date:   31/10/2011 06:55 a.m.
Subject:        Re: [ironlanguages-main] Ruby 1.9 marshalling 
compatibility. (630995e)



This doesn't seem to be quite right.
Unfortunately Ruby's exception object might be a bit messed up. Message 
might not be a string, backtrace is always an array (or nil) but it might 
not containg strings. It seems that Ruby calls "==" on the message object 
and then on each item of the backtrace. 

It doesn't look like Ruby is comparing exception classes.

Also an exception can be compared with any object that has "message" and 
"backtrace" methods.

---

class C
  def message
    "hello"
  end
 
  def backtrace
    ["1","2","3"]
  end
end

class D 
  def ==(other)
    p "=="
    true
  end
end

c = C.new
m = D.new
e = Exception.new(m)
a = ["1","2","3"]
e.set_backtrace(a)
a[1] = D.new

p e == c

p e.backtrace.inspect, e.message
p c.backtrace.inspect, c.message

p IOError.new("1") == Exception.new("1")

-- 
Reply to this email directly or view it on GitHub:
https://github.com/gglresearchanddevelopment/ironlanguages-main/commit/630995eca293b5b0531e821b76bab7e15c4506f6#commitcomment-683915


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111031/b6b41463/attachment.html>

From Orion.Edwards at gallagher.co  Mon Oct 31 16:19:12 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Tue, 1 Nov 2011 09:19:12 +1300
Subject: [Ironruby-core] RubySpecs
Message-ID: <OF949CA64A.2ECAAB74-ONCC25793A.006EC0A8-CC25793A.006F9F43@gallagher.local>

I've just run mspec under the Languages\Ruby\Tests\mspec\rubyspec\core 
folder against MRI 1.9.2p0 (which is checked into the ironlanguages-main 
git repo), and it crashes with a segfault in putc_spec.rb

I then tried running against MRI 1.9.2p290 and I get the following:

       1518 files, 9618 examples, 28229 expectations, 339 failures, 256 
errors

Running against the dev build of IronRuby stalls running tests in the 
array subfolder, so I can't even complete the run.

I'd like to try fixing some of the spec failures that IronRuby has, but 
these results raise several questions:

1. Are the specs in the mspec\rubyspec folder up to date? How would 
someone find this out and/or update them?
  - Also, I added a few specs the other day for the marshalling code. Do 
these need to somehow get pushed upstream into some "master" rubyspec 
repository??

2. Shouldn't we check the latest build of MRI into the ironlangauges 
git-repo? Either the latest 1.9.2 or the just-released 1.9.3 instead?

3. Isn't MRI the "definitive" ruby? How can the specs be failing against 
MRI?

4. If I update some IronRuby code to pass the specs, how do I know that 
the specs are even correct?

Thanks, Orion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111101/387fc854/attachment.html>

From Tomas.Matousek at microsoft.com  Mon Oct 31 16:57:59 2011
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Mon, 31 Oct 2011 20:57:59 +0000
Subject: [Ironruby-core] RubySpecs
In-Reply-To: <OF949CA64A.2ECAAB74-ONCC25793A.006EC0A8-CC25793A.006F9F43@gallagher.local>
References: <OF949CA64A.2ECAAB74-ONCC25793A.006EC0A8-CC25793A.006F9F43@gallagher.local>
Message-ID: <9597F4A19BFDB342B6E90963100C33082E45AC33@CH1PRD0302MB132.namprd03.prod.outlook.com>

1) Partly. We are in progress of updating them. Since we've added more specs and sometimes corrected existing ones this needs to be done with care. The current progress is captured here:

https://gist.github.com/1159998

After we are done with this process of bringing the specs up to date we can submit a path to RubySpec containing the changed we made. The plan is also to make the RubySpec dir a submodule so that merging with RubySpec is easier.

2) Or maybe we should just remove MRI completely? You can always use one on your system. I need to check if we need CRuby for anything in the infrastructure.

3) Well, that would be a question for RubySpec maintainers. I found some specs be failures Windows specific, which means the specs are not properly written. Feel free to contribute to RubySpecs git repo - I bet they are happy to accept fixes.

4) Well, you need to figure out if the behavior makes sense. If it doesn't feel free to file a bug on CRuby and let them decide if the behavior is intentional or not. Then CRuby might get fixed, specs might get fixed, or IronRuby might get fixed.


Which specs particularly are you working on? Is it marshal related?

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Monday, October 31, 2011 1:19 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] RubySpecs

I've just run mspec under the Languages\Ruby\Tests\mspec\rubyspec\core folder against MRI 1.9.2p0 (which is checked into the ironlanguages-main git repo), and it crashes with a segfault in putc_spec.rb

I then tried running against MRI 1.9.2p290 and I get the following:

       1518 files, 9618 examples, 28229 expectations, 339 failures, 256 errors

Running against the dev build of IronRuby stalls running tests in the array subfolder, so I can't even complete the run.

I'd like to try fixing some of the spec failures that IronRuby has, but these results raise several questions:

1. Are the specs in the mspec\rubyspec folder up to date? How would someone find this out and/or update them?
  - Also, I added a few specs the other day for the marshalling code. Do these need to somehow get pushed upstream into some "master" rubyspec repository??

2. Shouldn't we check the latest build of MRI into the ironlangauges git-repo? Either the latest 1.9.2 or the just-released 1.9.3 instead?

3. Isn't MRI the "definitive" ruby? How can the specs be failing against MRI?

4. If I update some IronRuby code to pass the specs, how do I know that the specs are even correct?

Thanks, Orion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111031/71acd004/attachment.html>

From Orion.Edwards at gallagher.co  Mon Oct 31 19:40:18 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Tue, 1 Nov 2011 12:40:18 +1300
Subject: [Ironruby-core] RubySpecs
In-Reply-To: <9597F4A19BFDB342B6E90963100C33082E45AC33@CH1PRD0302MB132.namprd03.prod.outlook.com>
References: <OF949CA64A.2ECAAB74-ONCC25793A.006EC0A8-CC25793A.006F9F43@gallagher.local>
	<9597F4A19BFDB342B6E90963100C33082E45AC33@CH1PRD0302MB132.namprd03.prod.outlook.com>
Message-ID: <OFA4968C06.FC6A4803-ONCC25793A.00817BBC-CC25793A.00820893@gallagher.local>

Thanks for that.

After the code review comments about Exception#== I was running the 
Exception specs. 3 fail against ruby 1.9.2p290 (2011-07-09) [i386-mingw32]

I don't have access to a linux/mac system at work to check if they pass on 
non-windows platforms, but it doesn't look like there's anything platform 
related in those errors, so I'd doubt it.

Random comment:
It appears that there's a lot more work to be done in IronRuby 
particularly relating to Errno and SystemCallErrors - I could do this 
work, but there's a blocking problem:
 - Various bits of IronRuby core code call helper methods such as 
RubyExceptions.CreateEINVAL, RubyExceptions.CreateEEXIST, etc, etc. These 
are supposed to return Errno::EINVAL, but they can't, because the Errno 
classes are defined in IronRuby.Libraries and the RubyExceptions.CreateXYZ 
methods are defined in IronRuby.dll. We'd have to move the Errno stuff out 
of Libraries and into IronRuby.dll I think



From:   Tomas Matousek <Tomas.Matousek at microsoft.com>
To:     "ironruby-core at rubyforge.org" <ironruby-core at rubyforge.org>
Date:   01/11/2011 10:16 a.m.
Subject:        Re: [Ironruby-core] RubySpecs
Sent by:        ironruby-core-bounces at rubyforge.org



1) Partly. We are in progress of updating them. Since we?ve added more 
specs and sometimes corrected existing ones this needs to be done with 
care. The current progress is captured here:
 
https://gist.github.com/1159998
 
After we are done with this process of bringing the specs up to date we 
can submit a path to RubySpec containing the changed we made. The plan is 
also to make the RubySpec dir a submodule so that merging with RubySpec is 
easier.
 
2) Or maybe we should just remove MRI completely? You can always use one 
on your system. I need to check if we need CRuby for anything in the 
infrastructure.
 
3) Well, that would be a question for RubySpec maintainers. I found some 
specs be failures Windows specific, which means the specs are not properly 
written. Feel free to contribute to RubySpecs git repo ? I bet they are 
happy to accept fixes.
 
4) Well, you need to figure out if the behavior makes sense. If it doesn?t 
feel free to file a bug on CRuby and let them decide if the behavior is 
intentional or not. Then CRuby might get fixed, specs might get fixed, or 
IronRuby might get fixed.
 
 
Which specs particularly are you working on? Is it marshal related? 
 
Tomas
 
From: ironruby-core-bounces at rubyforge.org [
mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Monday, October 31, 2011 1:19 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] RubySpecs
 
I've just run mspec under the Languages\Ruby\Tests\mspec\rubyspec\core 
folder against MRI 1.9.2p0 (which is checked into the ironlanguages-main 
git repo), and it crashes with a segfault in putc_spec.rb 

I then tried running against MRI 1.9.2p290 and I get the following: 

       1518 files, 9618 examples, 28229 expectations, 339 failures, 256 
errors 

Running against the dev build of IronRuby stalls running tests in the 
array subfolder, so I can't even complete the run. 

I'd like to try fixing some of the spec failures that IronRuby has, but 
these results raise several questions: 

1. Are the specs in the mspec\rubyspec folder up to date? How would 
someone find this out and/or update them? 
  - Also, I added a few specs the other day for the marshalling code. Do 
these need to somehow get pushed upstream into some "master" rubyspec 
repository?? 

2. Shouldn't we check the latest build of MRI into the ironlangauges 
git-repo? Either the latest 1.9.2 or the just-released 1.9.3 instead? 

3. Isn't MRI the "definitive" ruby? How can the specs be failing against 
MRI? 

4. If I update some IronRuby code to pass the specs, how do I know that 
the specs are even correct? 

Thanks, Orion_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111101/22983831/attachment-0001.html>

From Tomas.Matousek at microsoft.com  Mon Oct 31 20:10:22 2011
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 1 Nov 2011 00:10:22 +0000
Subject: [Ironruby-core] RubySpecs
In-Reply-To: <OFA4968C06.FC6A4803-ONCC25793A.00817BBC-CC25793A.00820893@gallagher.local>
References: <OF949CA64A.2ECAAB74-ONCC25793A.006EC0A8-CC25793A.006F9F43@gallagher.local>
	<9597F4A19BFDB342B6E90963100C33082E45AC33@CH1PRD0302MB132.namprd03.prod.outlook.com>
	<OFA4968C06.FC6A4803-ONCC25793A.00817BBC-CC25793A.00820893@gallagher.local>
Message-ID: <9597F4A19BFDB342B6E90963100C33082E45AE27@CH1PRD0302MB132.namprd03.prod.outlook.com>

There is a lot of work to do around exceptions in general. I wouldn't start digging into it if I were you :). I'm thinking of some core changes in how we map Ruby to .NET exceptions... it will take me some time to get to it though. I would not worry about all these Errno exceptions for now unless your application is blocked by some specific bug. Certainly not if a few specs fail here and there (we have thousands of specs failing, which might be more important to fix).

Time to file a bug on CRuby to get some input from MRI guys what they think the behavior should really be if it doesn't make sense. Or RubySpec guys if the MRI behavior is reasonable.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Monday, October 31, 2011 4:40 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] RubySpecs

Thanks for that.

After the code review comments about Exception#== I was running the Exception specs. 3 fail against ruby 1.9.2p290 (2011-07-09) [i386-mingw32]

I don't have access to a linux/mac system at work to check if they pass on non-windows platforms, but it doesn't look like there's anything platform related in those errors, so I'd doubt it.

Random comment:
It appears that there's a lot more work to be done in IronRuby particularly relating to Errno and SystemCallErrors - I could do this work, but there's a blocking problem:
 - Various bits of IronRuby core code call helper methods such as RubyExceptions.CreateEINVAL, RubyExceptions.CreateEEXIST, etc, etc. These are supposed to return Errno::EINVAL, but they can't, because the Errno classes are defined in IronRuby.Libraries and the RubyExceptions.CreateXYZ methods are defined in IronRuby.dll. We'd have to move the Errno stuff out of Libraries and into IronRuby.dll I think



From:        Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>>
To:        "ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>" <ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>>
Date:        01/11/2011 10:16 a.m.
Subject:        Re: [Ironruby-core] RubySpecs
Sent by:        ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>
________________________________



1) Partly. We are in progress of updating them. Since we've added more specs and sometimes corrected existing ones this needs to be done with care. The current progress is captured here:

https://gist.github.com/1159998

After we are done with this process of bringing the specs up to date we can submit a path to RubySpec containing the changed we made. The plan is also to make the RubySpec dir a submodule so that merging with RubySpec is easier.

2) Or maybe we should just remove MRI completely? You can always use one on your system. I need to check if we need CRuby for anything in the infrastructure.

3) Well, that would be a question for RubySpec maintainers. I found some specs be failures Windows specific, which means the specs are not properly written. Feel free to contribute to RubySpecs git repo - I bet they are happy to accept fixes.

4) Well, you need to figure out if the behavior makes sense. If it doesn't feel free to file a bug on CRuby and let them decide if the behavior is intentional or not. Then CRuby might get fixed, specs might get fixed, or IronRuby might get fixed.


Which specs particularly are you working on? Is it marshal related?

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Monday, October 31, 2011 1:19 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] RubySpecs

I've just run mspec under the Languages\Ruby\Tests\mspec\rubyspec\core folder against MRI 1.9.2p0 (which is checked into the ironlanguages-main git repo), and it crashes with a segfault in putc_spec.rb

I then tried running against MRI 1.9.2p290 and I get the following:

      1518 files, 9618 examples, 28229 expectations, 339 failures, 256 errors

Running against the dev build of IronRuby stalls running tests in the array subfolder, so I can't even complete the run.

I'd like to try fixing some of the spec failures that IronRuby has, but these results raise several questions:

1. Are the specs in the mspec\rubyspec folder up to date? How would someone find this out and/or update them?
 - Also, I added a few specs the other day for the marshalling code. Do these need to somehow get pushed upstream into some "master" rubyspec repository??

2. Shouldn't we check the latest build of MRI into the ironlangauges git-repo? Either the latest 1.9.2 or the just-released 1.9.3 instead?

3. Isn't MRI the "definitive" ruby? How can the specs be failing against MRI?

4. If I update some IronRuby code to pass the specs, how do I know that the specs are even correct?

Thanks, Orion_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111101/0d3cabfd/attachment.html>

From Orion.Edwards at gallagher.co  Mon Oct 31 22:04:56 2011
From: Orion.Edwards at gallagher.co (Orion Edwards)
Date: Tue, 1 Nov 2011 15:04:56 +1300
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR
 types, or ruby types backed by a CLR type
In-Reply-To: <9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
References: <OF65D2FB88.1EDAC25C-ONCC257935.0003ADBF-CC257935.00077B5B@gallagher.local>
	<9597F4A19BFDB342B6E90963100C33082E43762E@CH1PRD0302MB132.namprd03.prod.outlook.com>
Message-ID: <OF5FA23B03.E5600195-ONCC25793B.000B2149-CC25793B.000B7064@gallagher.local>

I've updated the pull request as per Tomas' code review comments.

- Removed ISpecialRubyMarshalling interface in favour of keeping the code 
all in the Marshal
- Only implement Exception#==, not === and eql?
- Implement proper Exception comparison logic to match MRI
- Change the Marshal#ReadObject code to special-case Exceptions and Ranges 
so we don't need to use reflection to set Exception.message and range 
values (yay!)
- Minor tweaks to some exception classes to pass a couple more Rubyspecs 
while I was at it

https://github.com/IronLanguages/main/pull/47/files

Thanks, Orion



From:   Tomas Matousek <Tomas.Matousek at microsoft.com>
To:     "ironruby-core at rubyforge.org" <ironruby-core at rubyforge.org>
Date:   26/10/2011 03:42 p.m.
Subject:        Re: [Ironruby-core] IronRuby's Marshal.dump doesn't work 
with CLR types, or ruby types backed by a CLR type
Sent by:        ironruby-core-bounces at rubyforge.org



I think we should NOT serialize non-Ruby types for now. The implementation 
isn?t quite working so I?d prefer we delete all code that deals with 
ISerializable, clean up the marshaller and if .NET serialization is needed 
in future implement it fully and correctly.
 
Marshal.dump has to output exactly the same data as CRuby implementation 
(for Ruby objects). Otherwise you won?t be able to read data serialized by 
CRuby in IronRuby and vice versa.
 
Tomas
 
From: ironruby-core-bounces at rubyforge.org [
mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Tuesday, October 25, 2011 6:22 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby's Marshal.dump doesn't work with CLR 
types, or ruby types backed by a CLR type
 
Backstory: I'm trying to use DRb for some in-house utility code. DRb 
itself seems to work fine, but I found that when I misspelled a method 
name, instead of reporting back a NoMethodError, the IronRuby process 
crashed immediately to the console. 

This is using a relatively recent build of IronRuby from Github 

Steps to repro: 

e = RuntimeError.new 'xyz' 
dumped = Marshal.dump e 
e2 = Marshal.load dumped 

I would expect e2 to be equivalent to e, but instead the process crashes 
with this exception 

mscorlib:0:in `_InvokeConstructor': Exception has been thrown by the 
target of an invocation. (System::Reflection::TargetInvocationException) 
        from mscorlib:0:in `InvokeConstructor' 
        from mscorlib:0:in `Invoke' 
        from (ir):1:in `load' 
        from (ir):1 


Note: This also happens with any CLR type eg System::DateTime. 

I looked through IronRuby's marshalling code, and it appears that the 
behaviour of Marshal.dump and Marshal.load don't align properly. 

Marshal.dump is it's own self-contained set of code which essentially 
writes data to a BinaryStream. 
For ruby types, it ends up writing a series of values in a format that 
looks a lot like what I remember CRuby's marshal writing. 
For CLR types, this just writes the Type name and no instance data (clr 
objects don't have ruby instance variables after all) 

Marshal.load does 2 things: 
1. Reads any ruby instance variables out into an Attributes dictionary 
2. Uses reflection to find any non-public Constructor(SerializationInfo, 
StreamingContext) and invoke it. 


For ruby types, this finds the protected RubyClass(SerializationInfo, 
StreamingContext) ctor, which calls RubyOps.DeserializeObject, which in 
turn reads the attributes dictionary and it's all fine. 
For CLR types, this finds whatever constructor might exist for the CLR 
object, which does whatever it does for that type. 

Unfortunately because the data that is getting passed into the CLR 
deserialization constructor came from Marshal.dump which has no knowledge 
whatsoever of CLR serialization, the whole thing crashes. 

I'm no expert on CLR serialization, so I'd really appreciate some comments 
on this, as I'm not sure what to do here. 

As far as I can guess however, I can see two solutions: 

1. Implement Marshal.dump on top of the CLR serialization code so it 
matches Marshal.load and should therefore be able to handle CLR types too. 


2. Don't allow marshalling of CLR types, and put some special-case code 
into any Ruby types that are backed by CLR types (such as Exception) so 
these at least can be serialized? 

I'm going to have a crack at #1, but I'm not sure how successful this is. 

Again, any feedback would be greatly appreciated. 

Thanks, Orion_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20111101/7ec0cdf5/attachment-0001.html>