Forum: IronRuby IronRuby v2Release xbuild is failing

6036188da38ee062342bd87547878b65?d=identicon&s=25 Doug Blank (Guest)
on 2011-10-03 22:38
(Received via mailing list)
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
6036188da38ee062342bd87547878b65?d=identicon&s=25 Doug Blank (Guest)
on 2011-10-05 17:11
(Received via mailing list)
959b1c9d700abfc065f5f40bf5a966a2?d=identicon&s=25 James Schementi (jschementi)
on 2011-10-05 17:16
(Received via mailing list)
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
F983f0c990cba2fe743ef62a975ec99c?d=identicon&s=25 Curt Hagenlocher (Guest)
on 2011-10-05 18:12
(Received via mailing list)
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.
6036188da38ee062342bd87547878b65?d=identicon&s=25 Doug Blank (Guest)
on 2011-10-05 20:32
(Received via mailing list)
On Wed, Oct 5, 2011 at 11:17 AM, Curt Hagenlocher <curth@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
F983f0c990cba2fe743ef62a975ec99c?d=identicon&s=25 Curt Hagenlocher (Guest)
on 2011-10-05 20:59
(Received via mailing list)
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.
959b1c9d700abfc065f5f40bf5a966a2?d=identicon&s=25 James Schementi (jschementi)
on 2011-10-05 21:45
(Received via mailing list)
> 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.
6036188da38ee062342bd87547878b65?d=identicon&s=25 Doug Blank (Guest)
on 2011-10-05 22:32
(Received via mailing list)
On Wed, Oct 5, 2011 at 2:35 PM, Curt Hagenlocher <curth@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
Ad24799da38da64c3b51b745087d60fd?d=identicon&s=25 Jeff Hardy (Guest)
on 2011-10-06 00:23
(Received via mailing list)
On Wed, Oct 5, 2011 at 11:35 AM, Curt Hagenlocher <curth@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
6036188da38ee062342bd87547878b65?d=identicon&s=25 Doug Blank (Guest)
on 2011-11-13 17:11
(Received via mailing list)
On Wed, Oct 5, 2011 at 11:10 AM, Doug Blank <doug.blank@gmail.com>
wrote:
> Reported as:
> http://ironruby.codeplex.com/workitem/6523

Updated this workitem:

This build issue with Ruby, under Mono, with
/p:Configuration="v2Release" can be fixed with:

change:

#if SILVERLIGHT
                return EachStepString(storage, self,
ConvertStepToInt(storage, step)).Cast<object>();
#else
                return EachStepString(storage, self,
ConvertStepToInt(storage, step));
#endif

to just:

                return EachStepString(storage, self,
ConvertStepToInt(storage, step)).Cast<object>();

This may turn out to be more important than first thought, as having
some trouble using Configuration v4 under Mono (it builds fine, but
having trouble with integration with other DLLs, probably because of
v2 vs v4 issues). Looking into that, but we will need to use v2 for
the time being.

-Doug
This topic is locked and can not be replied to.