Green paper on IronRuby

Ruby IronRuby
1

Manning just published my green paper on ironruby.

2

Why “green paper”? (Just curious.)

Wikipedia has to say of the term:

In Britain, other similar Commonwealth jurisdictions (e.g. Australia),
and
the Republic of Ireland, a green paper is a tentative government
report of
a proposal without any commitment to action; the first step in changing
the
law. Green papers may result in the production of a white
paperhttp://en.wikipedia.org/wiki/White_paper
.

2008/8/22 Ivan Porto C. [email protected]

3

Downloading it now. :slight_smile:

2008/8/22 Ivan Porto C. [email protected]

4

Dunno ask Manning. Probably the answer will be marketing.
It’s a white paper AFAICT.

and I would like to clarify for those that downloaded the paper there is
an
error on the first page. The year rails was released this is 2005 and
obviously not 1994. It will be changed shortly.

5

Hi Ivan,

I thought I’d give a few quick comments on your paper:

  • re: Duck Typing - I wouldn’t characterize Ruby as not caring, or
    “caring less” about its type hierarchy. Ruby does depend on the type
    hierarchy (which includes mixins) to determine the method resolution
    order when dispatching method calls.

  • re: implicit type conversions - while it’s true that Ruby does not
    perform implicit type conversions by default for the case of 1 + “1”,
    programmers are free to (and have done) overloads of the “+” method to
    do exactly this kind of thing.

  • I think it would be better to simply describe the typing models
    (static/dynamic, weak/strong) by example in different exemplar languages
    followed by some examples in Ruby that characterizes it as a
    strong/dynamic language.

  • In the case of your conversion argument, "Ruby won’t allow you however
    to change the type of an integer object without an explicit conversion
    step … ". The conversion step actually creates a new object - it
    doesn’t change the type of an existing object. This is an important
    distinction since “changing the type of an object” would infer somehow
    changing the ‘shape’ of the object. This can be accomplished in Ruby by
    adding / removing / changing mixins, adding / removing / changing
    methods etc. In other languages like Python, you can change the ‘shape’
    of a class by redefining what its base class is. This, to me, is the
    essence of what makes a language ‘dynamically typed’ - you can change
    types at runtime vs. baking them at compile time.

  • re: closures - blocks also capture their containing lexical scope.
    Lambdas are required to turn blocks into first-class entities (assigning
    to variables).

  • re: continuations - I would cut out the section on continuations
    entirely since it is an esoteric construct that is not consistently
    supported across all Ruby implementations.

  • re: example of overloading System::String: You introduce global
    variables in your example without explaining what they are. I would
    rewrite this using only local variables since we have the artificial
    limitation of not supporting locals yet in our console.

  • re: WPF example. There’s a lot of magic included in the require ‘wpf’
    line of code. While this is early in the book, I would definitely call
    out the magic in require ‘wpf’, or at least make a goal of explaining
    how that magic works in a subsequent chapter that you can forward ref
    from the example.

Thanks,
-John

6

Speaking of continuations, what is the status of continuations for
IronRuby?
Is it in or out? If it’s in, then I would think you should leave it.

7

Continuations are not supported.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Ryan R.
Sent: Saturday, August 23, 2008 1:45 PM
To: [email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

Speaking of continuations, what is the status of continuations for
IronRuby? Is it in or out? If it’s in, then I would think you should
leave it.
On Sat, Aug 23, 2008 at 9:44 AM, John L. (IRONRUBY)
<[email protected]mailto:[email protected]> wrote:
Hi Ivan,

I thought I’d give a few quick comments on your paper:

  • re: Duck Typing - I wouldn’t characterize Ruby as not caring, or
    “caring less” about its type hierarchy. Ruby does depend on the type
    hierarchy (which includes mixins) to determine the method resolution
    order when dispatching method calls.

  • re: implicit type conversions - while it’s true that Ruby does not
    perform implicit type conversions by default for the case of 1 + “1”,
    programmers are free to (and have done) overloads of the “+” method to
    do exactly this kind of thing.

  • I think it would be better to simply describe the typing models
    (static/dynamic, weak/strong) by example in different exemplar languages
    followed by some examples in Ruby that characterizes it as a
    strong/dynamic language.

  • In the case of your conversion argument, "Ruby won’t allow you however
    to change the type of an integer object without an explicit conversion
    step … ". The conversion step actually creates a new object - it
    doesn’t change the type of an existing object. This is an important
    distinction since “changing the type of an object” would infer somehow
    changing the ‘shape’ of the object. This can be accomplished in Ruby by
    adding / removing / changing mixins, adding / removing / changing
    methods etc. In other languages like Python, you can change the ‘shape’
    of a class by redefining what its base class is. This, to me, is the
    essence of what makes a language ‘dynamically typed’ - you can change
    types at runtime vs. baking them at compile time.

  • re: closures - blocks also capture their containing lexical scope.
    Lambdas are required to turn blocks into first-class entities (assigning
    to variables).

  • re: continuations - I would cut out the section on continuations
    entirely since it is an esoteric construct that is not consistently
    supported across all Ruby implementations.

  • re: example of overloading System::String: You introduce global
    variables in your example without explaining what they are. I would
    rewrite this using only local variables since we have the artificial
    limitation of not supporting locals yet in our console.

  • re: WPF example. There’s a lot of magic included in the require ‘wpf’
    line of code. While this is early in the book, I would definitely call
    out the magic in require ‘wpf’, or at least make a goal of explaining
    how that magic works in a subsequent chapter that you can forward ref
    from the example.

Thanks,
-John

8

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

9

I’d actually disagree that Ruby doesn’t do implicit type conversions.
#to_int is implicitly called in the example John gave (well, kinda
called, I think #coerce is called, which tries #to_int), it just happens
that String doesn’t have to_int defined. This is the basis of the entire
coercion protocols, which I only barely understand.

JD

From: [email protected]
[[email protected]] On Behalf Of Tomas M.
[[email protected]]
Sent: Saturday, August 23, 2008 3:12 PM
To: [email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

Continuations are not supported.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Ryan R.
Sent: Saturday, August 23, 2008 1:45 PM
To: [email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

Speaking of continuations, what is the status of continuations for
IronRuby? Is it in or out? If it’s in, then I would think you should
leave it.
On Sat, Aug 23, 2008 at 9:44 AM, John L. (IRONRUBY)
<[email protected]mailto:[email protected]> wrote:
Hi Ivan,

I thought I’d give a few quick comments on your paper:

  • re: Duck Typing - I wouldn’t characterize Ruby as not caring, or
    “caring less” about its type hierarchy. Ruby does depend on the type
    hierarchy (which includes mixins) to determine the method resolution
    order when dispatching method calls.

  • re: implicit type conversions - while it’s true that Ruby does not
    perform implicit type conversions by default for the case of 1 + “1”,
    programmers are free to (and have done) overloads of the “+” method to
    do exactly this kind of thing.

  • I think it would be better to simply describe the typing models
    (static/dynamic, weak/strong) by example in different exemplar languages
    followed by some examples in Ruby that characterizes it as a
    strong/dynamic language.

  • In the case of your conversion argument, "Ruby won’t allow you however
    to change the type of an integer object without an explicit conversion
    step … ". The conversion step actually creates a new object - it
    doesn’t change the type of an existing object. This is an important
    distinction since “changing the type of an object” would infer somehow
    changing the ‘shape’ of the object. This can be accomplished in Ruby by
    adding / removing / changing mixins, adding / removing / changing
    methods etc. In other languages like Python, you can change the ‘shape’
    of a class by redefining what its base class is. This, to me, is the
    essence of what makes a language ‘dynamically typed’ - you can change
    types at runtime vs. baking them at compile time.

  • re: closures - blocks also capture their containing lexical scope.
    Lambdas are required to turn blocks into first-class entities (assigning
    to variables).

  • re: continuations - I would cut out the section on continuations
    entirely since it is an esoteric construct that is not consistently
    supported across all Ruby implementations.

  • re: example of overloading System::String: You introduce global
    variables in your example without explaining what they are. I would
    rewrite this using only local variables since we have the artificial
    limitation of not supporting locals yet in our console.

  • re: WPF example. There’s a lot of magic included in the require ‘wpf’
    line of code. While this is early in the book, I would definitely call
    out the magic in require ‘wpf’, or at least make a goal of explaining
    how that magic works in a subsequent chapter that you can forward ref
    from the example.

Thanks,
-John

-----Original Message-----
From: [email protected]mailto:[email protected] [mailto:ironruby-core-mailto:ironruby-core-
[email protected]mailto:[email protected]] On Behalf Of Ivan Porto C.
Sent: Friday, August 22, 2008 12:31 PM
To: [email protected]mailto:[email protected]
Subject: [Ironruby-core] Green paper on IronRuby

Manning just published my green paper on ironruby.
Manning - Free Content Center

Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Ryan R.
[email protected]mailto:[email protected]
http://www.panesofglass.org/

10

I’m arguing that it’s implicit due to 2 things. One, the programmer
doesn’t have to call the conversion. Two, it’s done implicitly as
opposed to explicitly (#to_s and #to_i for example).

I think I get your drift, but implicit doesn’t seem like the right word
for what you’re describing. Perhaps automatic, or automagic?

JD

From: [email protected]
[[email protected]] On Behalf Of Orion E.
[[email protected]]
Sent: Sunday, August 24, 2008 3:45 PM
To: [email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

I’d argue against that.
The fact that methods are called, and you can intercept or override them
is enough for me to make it not ‘implicit.’ Perhaps implicit is not the
right word, but yeah.

Contrast this with C, where some bits are just rammed into some
containers, or PHP, which decides completely by itself what to do with
your variables based on however it feels that day.

Jim D. wrote:

I’d actually disagree that Ruby doesn’t do implicit type conversions.
#to_int is implicitly called in the example John gave (well, kinda
called, I think #coerce is called, which tries #to_int), it just happens
that String doesn’t have to_int defined. This is the basis of the entire
coercion protocols, which I only barely understand.

JD

From:
[email protected]mailto:[email protected]
[[email protected]mailto:[email protected]]
On Behalf Of Tomas M.
[[email protected]mailto:[email protected]]
Sent: Saturday, August 23, 2008 3:12 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

Continuations are not supported.

Tomas

From:
[email protected]mailto:[email protected]
[mailto:[email protected]] On Behalf Of Ryan R.
Sent: Saturday, August 23, 2008 1:45 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] Green paper on IronRuby

Speaking of continuations, what is the status of continuations for
IronRuby? Is it in or out? If it’s in, then I would think you should
leave it.
On Sat, Aug 23, 2008 at 9:44 AM, John L. (IRONRUBY)
<[email protected]mailto:[email protected]mailto:[email protected]mailto:[email protected]>
wrote:
Hi Ivan,

I thought I’d give a few quick comments on your paper:

  • re: Duck Typing - I wouldn’t characterize Ruby as not caring, or
    “caring less” about its type hierarchy. Ruby does depend on the type
    hierarchy (which includes mixins) to determine the method resolution
    order when dispatching method calls.

  • re: implicit type conversions - while it’s true that Ruby does not
    perform implicit type conversions by default for the case of 1 + “1”,
    programmers are free to (and have done) overloads of the “+” method to
    do exactly this kind of thing.

  • I think it would be better to simply describe the typing models
    (static/dynamic, weak/strong) by example in different exemplar languages
    followed by some examples in Ruby that characterizes it as a
    strong/dynamic language.

  • In the case of your conversion argument, "Ruby won’t allow you however
    to change the type of an integer object without an explicit conversion
    step … ". The conversion step actually creates a new object - it
    doesn’t change the type of an existing object. This is an important
    distinction since “changing the type of an object” would infer somehow
    changing the ‘shape’ of the object. This can be accomplished in Ruby by
    adding / removing / changing mixins, adding / removing / changing
    methods etc. In other languages like Python, you can change the ‘shape’
    of a class by redefining what its base class is. This, to me, is the
    essence of what makes a language ‘dynamically typed’ - you can change
    types at runtime vs. baking them at compile time.

  • re: closures - blocks also capture their containing lexical scope.
    Lambdas are required to turn blocks into first-class entities (assigning
    to variables).

  • re: continuations - I would cut out the section on continuations
    entirely since it is an esoteric construct that is not consistently
    supported across all Ruby implementations.

  • re: example of overloading System::String: You introduce global
    variables in your example without explaining what they are. I would
    rewrite this using only local variables since we have the artificial
    limitation of not supporting locals yet in our console.

  • re: WPF example. There’s a lot of magic included in the require ‘wpf’
    line of code. While this is early in the book, I would definitely call
    out the magic in require ‘wpf’, or at least make a goal of explaining
    how that magic works in a subsequent chapter that you can forward ref
    from the example.

Thanks,
-John

11

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

12

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

13

I am getting compilation errors in IronRuby.Libraries project with the
latest IR SVN 154 version when compiling with Visual Studio 2008:

------ Build started: Project: Microsoft.Scripting.Core, Configuration:
Debug Any CPU ------
Microsoft.Scripting.Core ->
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll
------ Build started: Project: Microsoft.Scripting, Configuration: Debug
Any CPU ------
Microsoft.Scripting ->
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll
------ Build started: Project: Ruby, Configuration: Debug Any CPU ------
Ruby -> C:\programs\IronRuby\trunk\build\debug\IronRuby.dll
------ Build started: Project: IronRuby.Libraries, Configuration: Debug
Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll’
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6813,17): error CS0123: No overload for ‘Add’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,object,object,object>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\BigDecimal\BigDecimalO
ps.cs(352,30): (Related location)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6822,17): error CS0123: No overload for ‘Coerce’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,double,IronRuby.Builtins.RubyArray>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
…

Compile complete – 8 errors, 1 warnings

…

========== Build: 5 succeeded or up-to-date, 3 failed, 0 skipped

14

Reverting back to IR SVN 153, I was getting it compiled.

However, when switching to use the the SVN 153 compiled binaries
(upgrading from SVN 141) in my IronRuby-embedding app, I get following
compilation errors:

------ Build started: Project: gui, Configuration: Debug Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\avn153\Microsoft.Scripting.Core.
dll’
…
warning CS1685: The predefined type
‘System.Linq.Expressions.ElementInit’ is defined in multiple assemblies
in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\avn153\Microsoft.Scripting.Core.
dll’
error CS0656: Missing compiler required member
‘System.Runtime.CompilerServices.ExtensionAttribute…ctor’
error CS0656: Missing compiler required member
‘System.Runtime.CompilerServices.ExtensionAttribute…ctor’
error CS0656: Missing compiler required member
‘System.Runtime.CompilerServices.ExtensionAttribute…ctor’
error CS0656: Missing compiler required member
‘System.Runtime.CompilerServices.ExtensionAttribute…ctor’

Robert B.
Software architect
Napa Ltd
Tammasaarenkatu 3, Helsinki FI-00180
P.O.Box 470, Helsinki FI-00181

Tel. +358 9 22 813 1
Direct. +358 9 22 813 611
GSM +358 45 11 456 02
Fax. +358 9 22 813 800

Email: [email protected]

15

You define extension methods in your hosting app, right? We’re still
working out the details of our second attempt to fix this problem. In
the short term, the workaround is to define your own private copy of
ExtensionAttribute in any hosting project that defines extension
methods. That requires the following 4 lines of code:

namespace System.Runtime.CompilerServices {
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class |
AttributeTargets.Assembly)]
sealed class ExtensionAttribute : Attribute { }
}

16

I think this problem came from BigDecimal implementation that Peter
recently
committed. Maybe \IronRuby.Libraries\Initializers.Generated.cs should be
regenerated and committed again.

You can revert to revision 152 that compiles just fine.

P.S.: When the recent changes that were posted in the list will get
committed in the public repository?

2008/10/3 Robert B. [email protected]

17

Just committed a fix for the compilation errors.

Thanks,
-John

From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan D.
Sent: Friday, October 03, 2008 8:26 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

I think this problem came from BigDecimal implementation that Peter
recently committed. Maybe \IronRuby.Libraries\Initializers.Generated.cs
should be regenerated and committed again.

You can revert to revision 152 that compiles just fine.

P.S.: When the recent changes that were posted in the list will get
committed in the public repository?

2008/10/3 Robert B.
<[email protected]mailto:[email protected]>
I am getting compilation errors in IronRuby.Libraries project with the
latest IR SVN 154 version when compiling with Visual Studio 2008:

------ Build started: Project: Microsoft.Scripting.Core, Configuration:
Debug Any CPU ------
Microsoft.Scripting.Core →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll
------ Build started: Project: Microsoft.Scripting, Configuration: Debug
Any CPU ------
Microsoft.Scripting →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll
------ Build started: Project: Ruby, Configuration: Debug Any CPU ------
Ruby → C:\programs\IronRuby\trunk\build\debug\IronRuby.dll
------ Build started: Project: IronRuby.Libraries, Configuration: Debug
Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll’
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6813,17): error CS0123: No overload for ‘Add’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,object,object,object>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\BigDecimal\BigDecimalO
ps.cs(352,30): (Related location)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6822,17): error CS0123: No overload for ‘Coerce’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,double,IronRuby.Builtins.RubyArray>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
…

Compile complete – 8 errors, 1 warnings

…

========== Build: 5 succeeded or up-to-date, 3 failed, 0 skipped

18

Sorry, I should update initializers.generated.cs when I commit - I
always
shied away from that when posting patches as they would need to be
regenerated anyway. By the way, should there be some kind of code
review
for my commits? Should I post my proposed changes to the list first?

Regards,

Pete

From: [email protected]
[mailto:[email protected]] On Behalf Of John L.
(IRONRUBY)
Sent: Friday,03 October 03, 2008 17:08
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

Just committed a fix for the compilation errors.

Thanks,

-John

From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan D.
Sent: Friday, October 03, 2008 8:26 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

I think this problem came from BigDecimal implementation that Peter
recently
committed. Maybe \IronRuby.Libraries\Initializers.Generated.cs should be
regenerated and committed again.

You can revert to revision 152 that compiles just fine.

P.S.: When the recent changes that were posted in the list will get
committed in the public repository?

2008/10/3 Robert B. [email protected]

I am getting compilation errors in IronRuby.Libraries project with the
latest IR SVN 154 version when compiling with Visual Studio 2008:

------ Build started: Project: Microsoft.Scripting.Core, Configuration:
Debug Any CPU ------
Microsoft.Scripting.Core →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll
------ Build started: Project: Microsoft.Scripting, Configuration: Debug
Any CPU ------
Microsoft.Scripting →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll
------ Build started: Project: Ruby, Configuration: Debug Any CPU ------
Ruby → C:\programs\IronRuby\trunk\build\debug\IronRuby.dll
------ Build started: Project: IronRuby.Libraries, Configuration: Debug
Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll’
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6813,17): error CS0123: No overload for ‘Add’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,object,object,object>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\BigDecimal\BigDecimalO
ps.cs(352,30): (Related location)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6822,17): error CS0123: No overload for ‘Coerce’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,double,IronRuby.Builtins.RubyArray>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
…

Compile complete – 8 errors, 1 warnings

…

========== Build: 5 succeeded or up-to-date, 3 failed, 0 skipped

19

I think we all should have code review before we commit. It’s something
we do for everything here, and it would probably be useful for everyone
else.

JD

From: [email protected]
[mailto:[email protected]] On Behalf Of Peter Bacon
Darwin
Sent: Friday, October 03, 2008 10:42 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

Sorry, I should update initializers.generated.cs when I commit - I
always shied away from that when posting patches as they would need to
be regenerated anyway. By the way, should there be some kind of code
review for my commits? Should I post my proposed changes to the list
first?
Regards,
Pete

From: [email protected]
[mailto:[email protected]] On Behalf Of John L.
(IRONRUBY)
Sent: Friday,03 October 03, 2008 17:08
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

Just committed a fix for the compilation errors.

Thanks,
-John

From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan D.
Sent: Friday, October 03, 2008 8:26 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

I think this problem came from BigDecimal implementation that Peter
recently committed. Maybe \IronRuby.Libraries\Initializers.Generated.cs
should be regenerated and committed again.

You can revert to revision 152 that compiles just fine.

P.S.: When the recent changes that were posted in the list will get
committed in the public repository?

2008/10/3 Robert B.
<[email protected]mailto:[email protected]>
I am getting compilation errors in IronRuby.Libraries project with the
latest IR SVN 154 version when compiling with Visual Studio 2008:

------ Build started: Project: Microsoft.Scripting.Core, Configuration:
Debug Any CPU ------
Microsoft.Scripting.Core →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll
------ Build started: Project: Microsoft.Scripting, Configuration: Debug
Any CPU ------
Microsoft.Scripting →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll
------ Build started: Project: Ruby, Configuration: Debug Any CPU ------
Ruby → C:\programs\IronRuby\trunk\build\debug\IronRuby.dll
------ Build started: Project: IronRuby.Libraries, Configuration: Debug
Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll’
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6813,17): error CS0123: No overload for ‘Add’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,object,object,object>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\BigDecimal\BigDecimalO
ps.cs(352,30): (Related location)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6822,17): error CS0123: No overload for ‘Coerce’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,double,IronRuby.Builtins.RubyArray>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
…

Compile complete – 8 errors, 1 warnings

…

========== Build: 5 succeeded or up-to-date, 3 failed, 0 skipped

20

OK so I will post the changes to this list first. What are the criteria
for
the code being accepted? What if nobody replies? How long do I wait
before
I commit? Etc etc etc.

Pete

From: [email protected]
[mailto:[email protected]] On Behalf Of Jim D.
Sent: Friday,03 October 03, 2008 18:45
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

I think we all should have code review before we commit. It’s something
we
do for everything here, and it would probably be useful for everyone
else.

JD

From: [email protected]
[mailto:[email protected]] On Behalf Of Peter Bacon
Darwin
Sent: Friday, October 03, 2008 10:42 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

Sorry, I should update initializers.generated.cs when I commit - I
always
shied away from that when posting patches as they would need to be
regenerated anyway. By the way, should there be some kind of code
review
for my commits? Should I post my proposed changes to the list first?

Regards,

Pete

From: [email protected]
[mailto:[email protected]] On Behalf Of John L.
(IRONRUBY)
Sent: Friday,03 October 03, 2008 17:08
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

Just committed a fix for the compilation errors.

Thanks,

-John

From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan D.
Sent: Friday, October 03, 2008 8:26 AM
To: [email protected]
Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154

I think this problem came from BigDecimal implementation that Peter
recently
committed. Maybe \IronRuby.Libraries\Initializers.Generated.cs should be
regenerated and committed again.

You can revert to revision 152 that compiles just fine.

P.S.: When the recent changes that were posted in the list will get
committed in the public repository?

2008/10/3 Robert B. [email protected]

I am getting compilation errors in IronRuby.Libraries project with the
latest IR SVN 154 version when compiling with Visual Studio 2008:

------ Build started: Project: Microsoft.Scripting.Core, Configuration:
Debug Any CPU ------
Microsoft.Scripting.Core →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll
------ Build started: Project: Microsoft.Scripting, Configuration: Debug
Any CPU ------
Microsoft.Scripting →
C:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll
------ Build started: Project: Ruby, Configuration: Debug Any CPU ------
Ruby → C:\programs\IronRuby\trunk\build\debug\IronRuby.dll
------ Build started: Project: IronRuby.Libraries, Configuration: Debug
Any CPU ------
…
warning CS1685: The predefined type
‘System.Runtime.CompilerServices.ExtensionAttribute’ is defined in
multiple assemblies in the global alias; using definition from
‘c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.dll’
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6813,17): error CS0123: No overload for ‘Add’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,object,object,object>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\BigDecimal\BigDecimalO
ps.cs(352,30): (Related location)
C:\programs\IronRuby\trunk\src\IronRuby.Libraries\Initializers.Generated
.cs(6822,17): error CS0123: No overload for ‘Coerce’ matches delegate
‘System.Func<Microsoft.Scripting.Runtime.CodeContext,IronRuby.StandardLi
brary.BigDecimal.BigDecimal,double,IronRuby.Builtins.RubyArray>’
c:\programs\IronRuby\trunk\build\debug\Microsoft.Scripting.Core.dll:
(Related file)
…

Compile complete – 8 errors, 1 warnings

…

========== Build: 5 succeeded or up-to-date, 3 failed, 0 skipped