Manning just published my green paper on ironruby. http://manning.com/free/green_carrero.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080822/ba2498c0/attachment.html>
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 paper<http://en.wikipedia.org/wiki/White_paper> . 2008/8/22 Ivan Porto Carrero <ivan at flanders.co.nz>> Manning just published my green paper on ironruby. > http://manning.com/free/green_carrero.html > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080822/27bcf658/attachment.html>
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. On Fri, Aug 22, 2008 at 9:38 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:> 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 paper<http://en.wikipedia.org/wiki/White_paper> > . > > 2008/8/22 Ivan Porto Carrero <ivan at flanders.co.nz> > >> Manning just published my green paper on ironruby. >> http://manning.com/free/green_carrero.html >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.ironpython.info/ > http://www.resolverhacks.net/ > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero GSM: +32.486.787.582 Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080822/31d092a3/attachment.html>
Downloading it now. :-) 2008/8/22 Ivan Porto Carrero <ivan at flanders.co.nz>> 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. > > > > On Fri, Aug 22, 2008 at 9:38 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote: > >> 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 paper<http://en.wikipedia.org/wiki/White_paper> >> . >> >> 2008/8/22 Ivan Porto Carrero <ivan at flanders.co.nz> >> >>> Manning just published my green paper on ironruby. >>> http://manning.com/free/green_carrero.html >>> >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.ironpython.info/ >> http://www.resolverhacks.net/ >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > > -- > Met vriendelijke groeten - Best regards - Salutations > Ivan Porto Carrero > GSM: +32.486.787.582 > Blog: http://flanders.co.nz > Twitter: http://twitter.com/casualjim > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080822/06ee9845/attachment.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero > Sent: Friday, August 22, 2008 12:31 PM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] Green paper on IronRuby > > Manning just published my green paper on ironruby. > http://manning.com/free/green_carrero.html >
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 Lam (IRONRUBY) <jflam at microsoft.com>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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > > bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero > > Sent: Friday, August 22, 2008 12:31 PM > > To: ironruby-core at rubyforge.org > > Subject: [Ironruby-core] Green paper on IronRuby > > > > Manning just published my green paper on ironruby. > > http://manning.com/free/green_carrero.html > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Ryan Riley ryan.riley at panesofglass.org http://www.panesofglass.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080823/27791275/attachment.html>
Continuations are not supported. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley Sent: Saturday, August 23, 2008 1:45 PM To: ironruby-core at rubyforge.org 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 Lam (IRONRUBY) <jflam at microsoft.com<mailto:jflam at microsoft.com>> 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-<mailto:ironruby-core-> > bounces at rubyforge.org<mailto:bounces at rubyforge.org>] On Behalf Of Ivan Porto Carrero > Sent: Friday, August 22, 2008 12:31 PM > To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> > Subject: [Ironruby-core] Green paper on IronRuby > > Manning just published my green paper on ironruby. > http://manning.com/free/green_carrero.html >_______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -- Ryan Riley ryan.riley at panesofglass.org<mailto:ryan.riley at panesofglass.org> http://www.panesofglass.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080823/40813b99/attachment-0001.html>
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: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek [Tomas.Matousek at microsoft.com] Sent: Saturday, August 23, 2008 3:12 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Green paper on IronRuby Continuations are not supported. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley Sent: Saturday, August 23, 2008 1:45 PM To: ironruby-core at rubyforge.org 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 Lam (IRONRUBY) <jflam at microsoft.com<mailto:jflam at microsoft.com>> 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-<mailto:ironruby-core-> > bounces at rubyforge.org<mailto:bounces at rubyforge.org>] On Behalf Of Ivan Porto Carrero > Sent: Friday, August 22, 2008 12:31 PM > To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> > Subject: [Ironruby-core] Green paper on IronRuby > > Manning just published my green paper on ironruby. > http://manning.com/free/green_carrero.html >_______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -- Ryan Riley ryan.riley at panesofglass.org<mailto:ryan.riley at panesofglass.org> http://www.panesofglass.org/
An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/ff1c0719/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.jpg Type: image/jpeg Size: 8147 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/ff1c0719/attachment.jpg>
John Lam is right but it does depend on your point of view. The Ruby
interpreter itself does not do any automatic type conversions but the
built-in libraries are cleverly written to give the appearance of implicit
conversion. So if you view the libraries as part of the whole then you can
assume that type conversion is implicit.
Pete
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Sunday,24 August 24, 2008 23:45
To: ironruby-core at rubyforge.org
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 Deville 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: ironruby-core-bounces at rubyforge.org
[ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
[Tomas.Matousek at microsoft.com]
Sent: Saturday, August 23, 2008 3:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Green paper on IronRuby
Continuations are not supported.
Tomas
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Saturday, August 23, 2008 1:45 PM
To: ironruby-core at rubyforge.org
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 Lam (IRONRUBY) <jflam at microsoft.com
<mailto:jflam at microsoft.com> <mailto:jflam at microsoft.com>>
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: ironruby-core-bounces at rubyforge.org
<mailto:ironruby-core-bounces at rubyforge.org>
<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-
<mailto:ironruby-core-> <mailto:ironruby-core->
bounces at rubyforge.org <mailto:bounces at rubyforge.org>
<mailto:bounces at rubyforge.org>] On Behalf Of Ivan Porto Carrero
Sent: Friday, August 22, 2008 12:31 PM
To: ironruby-core at rubyforge.org <mailto:ironruby-core at rubyforge.org>
<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] Green paper on IronRuby
Manning just published my green paper on ironruby.
http://manning.com/free/green_carrero.html
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
--
Ryan Riley
ryan.riley at panesofglass.org <mailto:ryan.riley at panesofglass.org>
<mailto:ryan.riley at panesofglass.org>
http://www.panesofglass.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
--
Orion Edwards
Web Application Developer
T: +64 7 859 2120
F: +64 7 859 2320
E: <mailto:orion.edwards at open2view.com> orion.edwards at open2view.com
Open2view.com
The Real Estate Website
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/d7e1ff9c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 8147 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/d7e1ff9c/attachment-0001.jpe>
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: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards [orion.edwards at open2view.com] Sent: Sunday, August 24, 2008 3:45 PM To: ironruby-core at rubyforge.org 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 Deville 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Tomas Matousek [Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>] Sent: Saturday, August 23, 2008 3:12 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] Green paper on IronRuby Continuations are not supported. 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 Ryan Riley Sent: Saturday, August 23, 2008 1:45 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> 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 Lam (IRONRUBY) <jflam at microsoft.com<mailto:jflam at microsoft.com><mailto:jflam at microsoft.com><mailto:jflam at microsoft.com>> 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org><mailto:ironruby-core-bounces at rubyforge.org><mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-<mailto:ironruby-core-><mailto:ironruby-core-> bounces at rubyforge.org<mailto:bounces at rubyforge.org><mailto:bounces at rubyforge.org><mailto:bounces at rubyforge.org>] On Behalf Of Ivan Porto Carrero Sent: Friday, August 22, 2008 12:31 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org><mailto:ironruby-core at rubyforge.org><mailto:ironruby-core at rubyforge.org> Subject: [Ironruby-core] Green paper on IronRuby Manning just published my green paper on ironruby. http://manning.com/free/green_carrero.html _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org><mailto:Ironruby-core at rubyforge.org><mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -- Ryan Riley ryan.riley at panesofglass.org<mailto:ryan.riley at panesofglass.org><mailto:ryan.riley at panesofglass.org><mailto:ryan.riley at panesofglass.org> http://www.panesofglass.org/ _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -- Orion Edwards Web Application Developer T: +64 7 859 2120 F: +64 7 859 2320 E: orion.edwards at open2view.com <mailto:orion.edwards at open2view.com> Open2view.com The Real Estate Website [cid:part1.09090307.05040007 at open2view.com]
Thanks for your remarks guys, this is just a paper my book is available at *shameless plug* http://manning.com/carrero :). I ripped out the part about the continuations, clarified the duck typing a little bit. Replaced the global variables with regular variables. I also explained about blocks and the difference with a lambda, the conversion argument and mention that developers have made that implicit typing work for them in their applications. And I explain the require ''wpf'' and ''wpf_elements'' lines in the example on WPF. I describe these models (static/dynamic, strong/weak) in my book in more detail with C# as the statically typed language. I just wanted to keep that more lengthy discussion out of this paper. I see the paper as an appetizer to go buy the book. I agree on the appearance argument. I will change the word from implicit to automatic (automagic rubs me the wrong way because there is rarely magic involved in programming and I''m pedantic). And I''ll write that off due to not being a native english speaker :) Hopefully they will publish the new version when the people wake up in the time zone where Manning is. Thanks again Ivan On Mon, Aug 25, 2008 at 9:48 AM, Peter Bacon Darwin < bacondarwin at googlemail.com> wrote:> John Lam is right but it does depend on your point of view. The Ruby > interpreter itself does not do any automatic type conversions but the > built-in libraries are cleverly written to give the appearance of implicit > conversion. So if you view the libraries as part of the whole then you can > assume that type conversion is implicit. > > Pete > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Orion Edwards > *Sent:* Sunday,24 August 24, 2008 23:45 > > *To:* ironruby-core at rubyforge.org > *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 Deville 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: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek [Tomas.Matousek at microsoft.com] > > Sent: Saturday, August 23, 2008 3:12 PM > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] Green paper on IronRuby > > > > Continuations are not supported. > > > > Tomas > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org <ironruby-core-bounces at rubyforge.org>] On Behalf Of Ryan Riley > > Sent: Saturday, August 23, 2008 1:45 PM > > To: ironruby-core at rubyforge.org > > 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 Lam (IRONRUBY) <jflam at microsoft.com<mailto:jflam at microsoft.com> <jflam at microsoft.com>> 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> <ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core <ironruby-core>-<mailto:ironruby-core-> <ironruby-core-> > > bounces at rubyforge.org<mailto:bounces at rubyforge.org> <bounces at rubyforge.org>] On Behalf Of Ivan Porto Carrero > > Sent: Friday, August 22, 2008 12:31 PM > > To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> <ironruby-core at rubyforge.org> > > Subject: [Ironruby-core] Green paper on IronRuby > > > > Manning just published my green paper on ironruby. > > http://manning.com/free/green_carrero.html > > > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> <Ironruby-core at rubyforge.org> > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > > > -- > > Ryan Riley > > ryan.riley at panesofglass.org<mailto:ryan.riley at panesofglass.org> <ryan.riley at panesofglass.org> > > http://www.panesofglass.org/ > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > -- > *Orion Edwards * > Web Application Developer > > T: +64 7 859 2120 > F: +64 7 859 2320 > E: orion.edwards at open2view.com > > *Open2view.com * > *The Real Estate Website* > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero GSM: +32.486.787.582 Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/d194984e/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 8147 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080825/d194984e/attachment-0001.jpe>
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 ==========
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 Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi
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 { }
}
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Robert Brotherus
Sent: Friday, October 03, 2008 3:58 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Usage errors with IR SVN 153
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 Brotherus
Software architect
Napa Ltd
Tammasaarenkatu 3, Helsinki FI-00180
P.O.Box 470, Helsinki FI-00181
Tel. +358 9 22 813 1
Direct. +358 9 22 813 611
GSM +358 45 11 456 02
Fax. +358 9 22 813 800
Email: Robert.Brotherus at napa.fi
www.napa.fi
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
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 Brotherus <robert.brotherus at napa.fi>> 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 > =========> _______________________________________________ > 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/20081003/9fd5b65f/attachment.html>
John Lam (IRONRUBY)
2008-Oct-03 16:08 UTC
[Ironruby-core] Compilation errors for IR SVN 154
Just committed a fix for the compilation errors. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Friday, October 03, 2008 8:26 AM To: ironruby-core at rubyforge.org 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 Brotherus <robert.brotherus at napa.fi<mailto:robert.brotherus at napa.fi>> 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 =========_______________________________________________ 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/20081003/cff16207/attachment-0001.html>
Peter Bacon Darwin
2008-Oct-03 17:42 UTC
[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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Friday,03 October 03, 2008 17:08 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154 Just committed a fix for the compilation errors. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Friday, October 03, 2008 8:26 AM To: ironruby-core at rubyforge.org 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 Brotherus <robert.brotherus at napa.fi> 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 =========_______________________________________________ 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/20081003/1d1feadc/attachment.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Friday, October 03, 2008 10:42 AM To: ironruby-core at rubyforge.org 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Friday,03 October 03, 2008 17:08 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154 Just committed a fix for the compilation errors. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Friday, October 03, 2008 8:26 AM To: ironruby-core at rubyforge.org 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 Brotherus <robert.brotherus at napa.fi<mailto:robert.brotherus at napa.fi>> 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 =========_______________________________________________ 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/20081003/f6a12978/attachment-0001.html>
Peter Bacon Darwin
2008-Oct-03 18:06 UTC
[Ironruby-core] Compilation errors for IR SVN 154
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville Sent: Friday,03 October 03, 2008 18:45 To: ironruby-core at rubyforge.org 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Friday, October 03, 2008 10:42 AM To: ironruby-core at rubyforge.org 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Friday,03 October 03, 2008 17:08 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154 Just committed a fix for the compilation errors. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Friday, October 03, 2008 8:26 AM To: ironruby-core at rubyforge.org 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 Brotherus <robert.brotherus at napa.fi> 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 =========_______________________________________________ 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/20081003/e3dbc380/attachment.html>
John Lam (IRONRUBY)
2008-Oct-03 19:57 UTC
[Ironruby-core] Compilation errors for IR SVN 154
We''ll make sure we review your code; if for some reason it falls through the cracks, just ping :) Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Friday, October 03, 2008 11:07 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville Sent: Friday,03 October 03, 2008 18:45 To: ironruby-core at rubyforge.org 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Peter Bacon Darwin Sent: Friday, October 03, 2008 10:42 AM To: ironruby-core at rubyforge.org 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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam (IRONRUBY) Sent: Friday,03 October 03, 2008 17:08 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Compilation errors for IR SVN 154 Just committed a fix for the compilation errors. Thanks, -John From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Stefan Dobrev Sent: Friday, October 03, 2008 8:26 AM To: ironruby-core at rubyforge.org 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 Brotherus <robert.brotherus at napa.fi<mailto:robert.brotherus at napa.fi>> 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 =========_______________________________________________ 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/20081003/9c31b049/attachment-0001.html>
John Lam:> Just committed a fix for the compilation errors.Curt Hagenlocher:> You define extension methods in your hosting app, right? > We''re still working out the details of our second attempt to fix thisproblem.> In the short term, the workaround is to define your own private copyof ExtensionAttribute ... Thanks John and Curt for quick responses, now my hosting up running happily again with IR SVN 155! Robert Brotherus Software architect Napa Ltd Tammasaarenkatu 3, Helsinki FI-00180 P.O.Box 470, Helsinki FI-00181 Tel. +358 9 22 813 1 Direct. +358 9 22 813 611 GSM +358 45 11 456 02 Fax. +358 9 22 813 800 Email: Robert.Brotherus at napa.fi www.napa.fi