From ben2004uk at googlemail.com  Thu Jan  1 12:48:13 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Thu, 1 Jan 2009 17:48:13 +0000
Subject: [Ironruby-core] Xml Processing in IronRuby - Help me improve the
	wrapper
Message-ID: <a04554c00901010948u58ff069ct698d6eff6715dd5d@mail.gmail.com>

Hello,

I've just been playing around with IronRuby and processing some XML
from a REST service.  I've created this wrapper:
require 'mscorlib'
require 'System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
include System
require 'System.Xml, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
include System::Xml

#Wrapper around .Net XMLDocument to make it easier to query with -
more like REXML
class Document
  def initialize(xml)
    @document = XmlDocument.new
    @document.load_xml xml
  end

  def get(xpath)   #.collect - I want to pass the block in, not have
to use it on the outside.
    @document.SelectNodes(xpath)
  end
end

class XmlNodeList
  def get(name)
    list.select {|e| e.Name == name}
  end
end

class XmlElement
  def get(name)
      if has_attribute name
        get_attribute name
      else
        get_elements_by_tag_name name
      end
  end

  def text
     inner_text
  end
end

My first problem is that I'm getting XmlElement object instead of
XmlNode from an XmlNodeList.  If I had XmlNode, then I could do
e['n'].text - which is what I want.  As a result, my code to access
the N element looks like this:

require 'xml'
@document = Document.new('<x><x1><n>test</n><z>aaa</z></x1></x>')
@document.get('x').collect {|n| puts n.text}
>> testaaa

>>> @document.get('x/x1').collect {|e| e.get('n').collect {|n| puts n.text}}
test

Why am I getting a XmlElement object? How can I access my xml in a
cleaner fashion?


My second problem, I wanted to be able to pass in a block

  def get(xpath)
    @document.SelectNodes(xpath).collect {yield}
  end

In this case, I get the following error:
>>> @document.get('x') {|n| puts n.text}
:1: undefined method `text' for nil:NilClass (NoMethodError)
        from xml.rb:27:in `get'

I changed it to  {|n| yield}, but I get the same error.  The object is
always nil. What am I doing wrong?

Hope this all makes sense.

Thanks

Ben

From ivan at flanders.co.nz  Thu Jan  1 13:01:55 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 1 Jan 2009 19:01:55 +0100
Subject: [Ironruby-core] Xml Processing in IronRuby - Help me improve
	the wrapper
In-Reply-To: <a04554c00901010948u58ff069ct698d6eff6715dd5d@mail.gmail.com>
References: <a04554c00901010948u58ff069ct698d6eff6715dd5d@mail.gmail.com>
Message-ID: <b1c6aabb0901011001q49bc905dv4b6de5f01f154155@mail.gmail.com>

I wrote something similar a while ago

http://github.com/casualjim/ironnails/tree/master/IronNails/vendor/iron_nails/lib/iron_xml.rb

statuses = []
IronXml.parse('friends_timeline.xml', :document) do |doc|
  doc.elements('statuses') do |status|
    st = Status.new
    st.id = status.element('id').value
    st.created_at = status.element('created_at').value
    st.text = status.element('text').value
    st.source = status.element('source').value
    st.truncated = status.element('truncated').value
    st.in_reply_to_status_id = status.element('in_reply_to_status_id').value
    st.in_reply_to_user_id = status.element('in_reply_to_user_id').value
    st.favorited = status.element('favorited').value
    status.elements('user') do |user|
      # process user here
    end

    statuses << st
  end
end

or

statuses = []
IronXml.parse('friends_timeline.xml', :document) do |doc|
  doc.statuses do |status|
    st = Status.new
    st.id = status.id
    st.created_at = status.created_at
    st.text = status.text
    st.source = status.source
    st.truncated = status.truncated
    st.in_reply_to_status_id = status.in_reply_to_status_id
    st.in_reply_to_user_id = status.in_reply_to_user_id
    st.favorited = status.favorited
    status.user do |user|
      # process user here
    end

    statuses << st
  end
end


You can maybe look there for inspiration :)

On Thu, Jan 1, 2009 at 6:48 PM, Ben Hall <ben2004uk at googlemail.com> wrote:

> Hello,
>
> I've just been playing around with IronRuby and processing some XML
> from a REST service.  I've created this wrapper:
> require 'mscorlib'
> require 'System, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089'
> include System
> require 'System.Xml, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089'
> include System::Xml
>
> #Wrapper around .Net XMLDocument to make it easier to query with -
> more like REXML
> class Document
>  def initialize(xml)
>    @document = XmlDocument.new
>    @document.load_xml xml
>  end
>
>  def get(xpath)   #.collect - I want to pass the block in, not have
> to use it on the outside.
>    @document.SelectNodes(xpath)
>  end
> end
>
> class XmlNodeList
>  def get(name)
>    list.select {|e| e.Name == name}
>  end
> end
>
> class XmlElement
>  def get(name)
>      if has_attribute name
>        get_attribute name
>      else
>        get_elements_by_tag_name name
>      end
>  end
>
>  def text
>     inner_text
>  end
> end
>
> My first problem is that I'm getting XmlElement object instead of
> XmlNode from an XmlNodeList.  If I had XmlNode, then I could do
> e['n'].text - which is what I want.  As a result, my code to access
> the N element looks like this:
>
> require 'xml'
> @document = Document.new('<x><x1><n>test</n><z>aaa</z></x1></x>')
> @document.get('x').collect {|n| puts n.text}
> >> testaaa
>
> >>> @document.get('x/x1').collect {|e| e.get('n').collect {|n| puts
> n.text}}
> test
>
> Why am I getting a XmlElement object? How can I access my xml in a
> cleaner fashion?
>
>
> My second problem, I wanted to be able to pass in a block
>
>  def get(xpath)
>    @document.SelectNodes(xpath).collect {yield}
>  end
>
> In this case, I get the following error:
> >>> @document.get('x') {|n| puts n.text}
> :1: undefined method `text' for nil:NilClass (NoMethodError)
>        from xml.rb:27:in `get'
>
> I changed it to  {|n| yield}, but I get the same error.  The object is
> always nil. What am I doing wrong?
>
> Hope this all makes sense.
>
> Thanks
>
> Ben
> _______________________________________________
> 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/20090101/e1f92717/attachment-0001.html>

From ben2004uk at googlemail.com  Thu Jan  1 13:35:16 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Thu, 1 Jan 2009 18:35:16 +0000
Subject: [Ironruby-core] Xml Processing in IronRuby - Help me improve
	the wrapper
In-Reply-To: <b1c6aabb0901011001q49bc905dv4b6de5f01f154155@mail.gmail.com>
References: <a04554c00901010948u58ff069ct698d6eff6715dd5d@mail.gmail.com>
	<b1c6aabb0901011001q49bc905dv4b6de5f01f154155@mail.gmail.com>
Message-ID: <a04554c00901011035u1d70e6e8p1e2d2a780ed4abbb@mail.gmail.com>

Excellent!! Thank you.  I was missing select_single_node and &b ;)

Wrapper is now sorted, and I can do:
require 'xml'
@document = Document.new('<x><x1><z>test</z><y><q>abc</q></y></x1><x1><z>tester</z><a>testeraaa</a></x1></x>')

@document.elements('x/x1') do |e|
   puts e.get('z')
   e.node('y') {|y| puts y.get('q')}
end

Thanks
Ben


On Thu, Jan 1, 2009 at 6:01 PM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:
> I wrote something similar a while ago
>
> http://github.com/casualjim/ironnails/tree/master/IronNails/vendor/iron_nails/lib/iron_xml.rb
>
> statuses = []
> IronXml.parse('friends_timeline.xml', :document) do |doc|
>   doc.elements('statuses') do |status|
>     st = Status.new
>     st.id = status.element('id').value
>     st.created_at = status.element('created_at').value
>     st.text = status.element('text').value
>     st.source = status.element('source').value
>     st.truncated = status.element('truncated').value
>     st.in_reply_to_status_id = status.element('in_reply_to_status_id').value
>     st.in_reply_to_user_id = status.element('in_reply_to_user_id').value
>     st.favorited = status.element('favorited').value
>     status.elements('user') do |user|
>       # process user here
>     end
>
>     statuses << st
>   end
> end
>
> or
>
> statuses = []
> IronXml.parse('friends_timeline.xml', :document) do |doc|
>   doc.statuses do |status|
>     st = Status.new
>     st.id = status.id
>     st.created_at = status.created_at
>     st.text = status.text
>     st.source = status.source
>     st.truncated = status.truncated
>     st.in_reply_to_status_id = status.in_reply_to_status_id
>     st.in_reply_to_user_id = status.in_reply_to_user_id
>     st.favorited = status.favorited
>     status.user do |user|
>       # process user here
>     end
>
>     statuses << st
>   end
> end
>
>
> You can maybe look there for inspiration :)
>
> On Thu, Jan 1, 2009 at 6:48 PM, Ben Hall <ben2004uk at googlemail.com> wrote:
>>
>> Hello,
>>
>> I've just been playing around with IronRuby and processing some XML
>> from a REST service.  I've created this wrapper:
>> require 'mscorlib'
>> require 'System, Version=2.0.0.0, Culture=neutral,
>> PublicKeyToken=b77a5c561934e089'
>> include System
>> require 'System.Xml, Version=2.0.0.0, Culture=neutral,
>> PublicKeyToken=b77a5c561934e089'
>> include System::Xml
>>
>> #Wrapper around .Net XMLDocument to make it easier to query with -
>> more like REXML
>> class Document
>>  def initialize(xml)
>>    @document = XmlDocument.new
>>    @document.load_xml xml
>>  end
>>
>>  def get(xpath)   #.collect - I want to pass the block in, not have
>> to use it on the outside.
>>    @document.SelectNodes(xpath)
>>  end
>> end
>>
>> class XmlNodeList
>>  def get(name)
>>    list.select {|e| e.Name == name}
>>  end
>> end
>>
>> class XmlElement
>>  def get(name)
>>      if has_attribute name
>>        get_attribute name
>>      else
>>        get_elements_by_tag_name name
>>      end
>>  end
>>
>>  def text
>>     inner_text
>>  end
>> end
>>
>> My first problem is that I'm getting XmlElement object instead of
>> XmlNode from an XmlNodeList.  If I had XmlNode, then I could do
>> e['n'].text - which is what I want.  As a result, my code to access
>> the N element looks like this:
>>
>> require 'xml'
>> @document = Document.new('<x><x1><n>test</n><z>aaa</z></x1></x>')
>> @document.get('x').collect {|n| puts n.text}
>> >> testaaa
>>
>> >>> @document.get('x/x1').collect {|e| e.get('n').collect {|n| puts
>> >>> n.text}}
>> test
>>
>> Why am I getting a XmlElement object? How can I access my xml in a
>> cleaner fashion?
>>
>>
>> My second problem, I wanted to be able to pass in a block
>>
>>  def get(xpath)
>>    @document.SelectNodes(xpath).collect {yield}
>>  end
>>
>> In this case, I get the following error:
>> >>> @document.get('x') {|n| puts n.text}
>> :1: undefined method `text' for nil:NilClass (NoMethodError)
>>        from xml.rb:27:in `get'
>>
>> I changed it to  {|n| yield}, but I get the same error.  The object is
>> always nil. What am I doing wrong?
>>
>> Hope this all makes sense.
>>
>> Thanks
>>
>> Ben
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>

From lists at ruby-forum.com  Fri Jan  2 00:10:32 2009
From: lists at ruby-forum.com (Benjamin van der Veen)
Date: Fri, 2 Jan 2009 06:10:32 +0100
Subject: [Ironruby-core] Determining line number of runtime errors
In-Reply-To: <e34ef3099203c48accee8731fe71ce23@ruby-forum.com>
References: <5a305d9a21a3e6adcf805107b91ef71e@ruby-forum.com>
	<ef5222770812110715q672a9392k242c1f1a5d8e2433@mail.gmail.com>
	<cd6277152d659602989a58935779b07d@ruby-forum.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB3526E69@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED152564D329DA@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<290bd8fbdc893366df7f9dbf0e2b3c61@ruby-forum.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256A572407@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<e34ef3099203c48accee8731fe71ce23@ruby-forum.com>
Message-ID: <7e64dcbd5f1574054ceb5e320ed3dd00@ruby-forum.com>

Hello all,

I hate to bump posts, but here I am doing so. I find it surprising that 
no one knows how to determine the line numbers of runtime errors. Curt's 
suggestion to investigate RubyExceptionData.GetInstance() seemed 
promising, but the information in it's Backtrace property was not 
correct. Anyone know why this might be the case and how I could go about 
fixing it?

Thanks,
benjamin

p.s.: I'm not sure if this is a mailing list as well as a message board; 
if this message has no context where you're reading it, see 
http://www.ruby-forum.com/topic/173123
-- 
Posted via http://www.ruby-forum.com/.

From suppakilla at gmail.com  Fri Jan  2 07:35:15 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Fri, 2 Jan 2009 13:35:15 +0100
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable under
	IronRuby
Message-ID: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>

Hello,

I was playing with threads under IronRuby but it seems like I have
stumbled on problems with Mutex and ConditionVariable. At first I
thought the problem was related to my code even if it actually worked
flawlessy for months under MRI 1.8.6 and it runs fine under the latest
JRuby, so I tried to run the most basic example of using these two
classes (a classic one:
http://www.rubycentral.com/pickaxe/tut_threads.html#UF) but the
problems still persist.

At first I thought it was some kind of deadlock given that the output
obtained by running the code with ir.exe is as follows:

C:\Sviluppo\ironruby\SVN\trunk\build\debug>ir T002.rb
A: I have critical section, but will wait for cv
(Later, back at the ranch...)
B: Now I am critical, but am done with cv

(note that the process remains stuck there)

So I went debugging with Visual Studio and this is what I got in the
output window:
http://gist.github.com/raw/42514/8d38b629e8ae62d9c4bece398a4041b036d28f12

To make it short, the reported exception is thrown when the ruby code
calls ConditionVariable#signal and IronRuby internally calls
Monitor.Pulse on the Mutex instance:

[RubyMethod("signal")]
public static RubyConditionVariable/*!*/
Signal(RubyConditionVariable/*!*/ self) {
    RubyMutex m = self._mutex;
    if (m != null) {
        Monitor.Pulse(m);
    }
    return self;
}

It seems like the Monitor is not aware of being in a synchronized
block of code (or is not in a critical section at all). Any clues?

Thanks,

Daniele

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From curth at microsoft.com  Fri Jan  2 11:56:31 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Fri, 2 Jan 2009 08:56:31 -0800
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable
	under	IronRuby
In-Reply-To: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>
References: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88747@NA-EXMSG-C118.redmond.corp.microsoft.com>

It looks like ConditionVariable.wait isn't implemented in a way that's consistent with the spec. Please file a bug report on RubyForge.

I'm a bit surprised by the semantics of this class.  It doesn't appear possible to use it safely unless there's at least one additional level of locking.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri
Sent: Friday, January 02, 2009 4:35 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable under IronRuby

Hello,

I was playing with threads under IronRuby but it seems like I have
stumbled on problems with Mutex and ConditionVariable. At first I
thought the problem was related to my code even if it actually worked
flawlessy for months under MRI 1.8.6 and it runs fine under the latest
JRuby, so I tried to run the most basic example of using these two
classes (a classic one:
http://www.rubycentral.com/pickaxe/tut_threads.html#UF) but the
problems still persist.

At first I thought it was some kind of deadlock given that the output
obtained by running the code with ir.exe is as follows:

C:\Sviluppo\ironruby\SVN\trunk\build\debug>ir T002.rb
A: I have critical section, but will wait for cv
(Later, back at the ranch...)
B: Now I am critical, but am done with cv

(note that the process remains stuck there)

So I went debugging with Visual Studio and this is what I got in the
output window:
http://gist.github.com/raw/42514/8d38b629e8ae62d9c4bece398a4041b036d28f12

To make it short, the reported exception is thrown when the ruby code
calls ConditionVariable#signal and IronRuby internally calls
Monitor.Pulse on the Mutex instance:

[RubyMethod("signal")]
public static RubyConditionVariable/*!*/
Signal(RubyConditionVariable/*!*/ self) {
    RubyMutex m = self._mutex;
    if (m != null) {
        Monitor.Pulse(m);
    }
    return self;
}

It seems like the Monitor is not aware of being in a synchronized
block of code (or is not in a critical section at all). Any clues?

Thanks,

Daniele

--
Daniele Alessandri
http://www.clorophilla.net/blog/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From suppakilla at gmail.com  Fri Jan  2 14:39:48 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Fri, 2 Jan 2009 20:39:48 +0100
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable under
	IronRuby
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88747@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88747@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <3bf20550901021139i32acf5edqfe1cea55b48cb590@mail.gmail.com>

On Fri, Jan 2, 2009 at 17:56, Curt Hagenlocher <curth at microsoft.com> wrote:

> It looks like ConditionVariable.wait isn't implemented in a way that's consistent with the spec. Please file a bug report on RubyForge.

Bug report filed.

While I was at it, I filed another bug report about potential
multithreading issues when modules are initialized by IronRuby. See:
http://rubyforge.org/tracker/index.php?func=detail&aid=23408&group_id=4359&atid=16798

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From curth at microsoft.com  Fri Jan  2 15:03:32 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Fri, 2 Jan 2009 12:03:32 -0800
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable
	under	IronRuby
In-Reply-To: <3bf20550901021139i32acf5edqfe1cea55b48cb590@mail.gmail.com>
References: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88747@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<3bf20550901021139i32acf5edqfe1cea55b48cb590@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88847@NA-EXMSG-C118.redmond.corp.microsoft.com>

Thanks for a very detailed bug report!

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri
Sent: Friday, January 02, 2009 11:40 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problems with Mutex and ConditionVariable under IronRuby

On Fri, Jan 2, 2009 at 17:56, Curt Hagenlocher <curth at microsoft.com> wrote:

> It looks like ConditionVariable.wait isn't implemented in a way that's consistent with the spec. Please file a bug report on RubyForge.

Bug report filed.

While I was at it, I filed another bug report about potential
multithreading issues when modules are initialized by IronRuby. See:
http://rubyforge.org/tracker/index.php?func=detail&aid=23408&group_id=4359&atid=16798

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From jdeville at microsoft.com  Fri Jan  2 15:07:53 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 2 Jan 2009 12:07:53 -0800
Subject: [Ironruby-core] Code Review: rakecrossplatform
In-Reply-To: <ef5222770812312022m1ad09732y4f327d202e8fcd00@mail.gmail.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55B2E4E@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8855F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55B2E7B@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<ef5222770812312022m1ad09732y4f327d202e8fcd00@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55B2F87@NA-EXMSG-C112.redmond.corp.microsoft.com>

Committing with Michael's suggestion.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Wednesday, December 31, 2008 8:23 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Code Review: rakecrossplatform

By the by, forward slashes are acceptable as path separators in windows as well as under unix.  This /may/ be more acceptable as it's clearer, IMHO.
On Wed, Dec 31, 2008 at 4:29 PM, Jim Deville <jdeville at microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I'm going to directly commit this since it doesn't affect tests.

JD

-----Original Message-----
From: Curt Hagenlocher
Sent: Wednesday, December 31, 2008 1:17 PM
To: Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: RE: Code Review: rakecrossplatform

Looks good!

-----Original Message-----
From: Jim Deville
Sent: Wednesday, December 31, 2008 12:21 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Code Review: rakecrossplatform

 tfpt review "/shelveset:rakecrossplatform;REDMOND\jdeville"
 Comment  :
 Fixes the imports to reference the files in a platform agnostic way.


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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From suppakilla at gmail.com  Sat Jan  3 06:10:14 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Sat, 3 Jan 2009 12:10:14 +0100
Subject: [Ironruby-core] Problems with Mutex and ConditionVariable under
	IronRuby
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88847@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <3bf20550901020435k103fe64ah15076691ab2888a1@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88747@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<3bf20550901021139i32acf5edqfe1cea55b48cb590@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88847@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <3bf20550901030310h73080dd6sd511b36dc6033b73@mail.gmail.com>

On Fri, Jan 2, 2009 at 21:03, Curt Hagenlocher <curth at microsoft.com> wrote:

> Thanks for a very detailed bug report!

I just filed another bug :-)

"A Fixnum fails to grow to a Bignum when using the left shift operator"
http://rubyforge.org/tracker/index.php?func=detail&aid=23414&group_id=4359&atid=16798

I tackled this bug when I noticed strange behaviours/errors under
IronRuby while using ruby's IPAddr class.

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From Tomas.Matousek at microsoft.com  Sat Jan  3 14:52:03 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 3 Jan 2009 11:52:03 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>

I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.

Tomas

-----Original Message-----
From: Curt Hagenlocher
Sent: Tuesday, December 30, 2008 10:05 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Thread#raise

Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.

Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html

-----Original Message-----
From: Shri Borde
Sent: Monday, December 29, 2008 3:00 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Thread#raise

  tfpt review "/shelveset:raise;REDMOND\sborde"
  Comment  :
  Implements Thread#raise using Thread.Abort, and added tests for it
  Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
  Enabled test for timeout as well
  Remaining work (not high pri for now)
   - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
   - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
   - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException

  RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example



From ben2004uk at googlemail.com  Sun Jan  4 08:41:44 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Sun, 4 Jan 2009 13:41:44 +0000
Subject: [Ironruby-core] IronRuby and VS2010
Message-ID: <a04554c00901040541u488f5f9fgb37b900aace2acc2@mail.gmail.com>

Hello,

I've just been playing around with IronRuby and VS2010.  If I
understand the situation correctly, Microsoft.Scripting.Core has been
integrated into .Net 4.0, leaving Microsoft.Scripting to hold the Ast
and the Hosting API?

Because of this, you can only use a particular build of IronPython
(http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448).
 As a result, you can't use IronRuby yet because there isn't an
assiocated build using the same DLR engine?

This seems quite a strong dependency between .Net and the DLR.  Only
allowing particular builds of the langauge to work against a
particular version of the framework sounds like it will be a nightmare
to manage. Are we going to be in the position where we have a
Community\Bleeding Edge Build and .Net framework build?

Is this going to change in the next beta \ CTP?

Thanks

Ben

From curth at microsoft.com  Sun Jan  4 11:50:29 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Sun, 4 Jan 2009 08:50:29 -0800
Subject: [Ironruby-core] IronRuby and VS2010
In-Reply-To: <a04554c00901040541u488f5f9fgb37b900aace2acc2@mail.gmail.com>
References: <a04554c00901040541u488f5f9fgb37b900aace2acc2@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88A40@NA-EXMSG-C118.redmond.corp.microsoft.com>

Your understanding of the situation is basically correct.

Internally, we call the parts of the DLR that are in Microsoft.Scripting.Core.dll the "inner ring" and the parts that are in Microsoft.Scripting.dll the "outer ring".  The bits in the inner ring are pretty stable; its functionality was defined some time ago and is relatively nailed down now.  There have been bug fixes and small changes, but for the most part we're pretty happy with the specific features that it contains.  There will undoubtedly continue to be small changes between now and the time that CLR4 is released.

Given that we will want people to be able to play with the dynamic features in C# and VB, I'm sure we'll release builds of the languages that correspond with subsequent CTPs and betas of CLR4/VS2010.  But we may again have to use slightly older versions of the sources.  The reason there was no build of IronRuby for the first CTP was that its snapshot was taken at the end of August, when IronRuby didn't yet support IDynamicObject.

"DLR 1.0" is expected to contain the finalized bits from CLR4.  This means that language source which builds against DLR 1.0 (for CLR2) will also build against CLR4.  Everything should be sync'd up and happy.

It's too early to speculate on a post-DLR-1.0 world, but it's reasonable to assume that we'll have similar issues as more functionality migrates from the outer ring to the inner ring of the DLR.  But I expect that the CLR2+DLR1/CLR4 platform ought to be a stable base to build languages from for some time.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
Sent: Sunday, January 04, 2009 5:42 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby and VS2010

Hello,

I've just been playing around with IronRuby and VS2010.  If I
understand the situation correctly, Microsoft.Scripting.Core has been
integrated into .Net 4.0, leaving Microsoft.Scripting to hold the Ast
and the Hosting API?

Because of this, you can only use a particular build of IronPython
(http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448).
 As a result, you can't use IronRuby yet because there isn't an
assiocated build using the same DLR engine?

This seems quite a strong dependency between .Net and the DLR.  Only
allowing particular builds of the langauge to work against a
particular version of the framework sounds like it will be a nightmare
to manage. Are we going to be in the position where we have a
Community\Bleeding Edge Build and .Net framework build?

Is this going to change in the next beta \ CTP?

Thanks

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


From ben2004uk at googlemail.com  Sun Jan  4 12:13:24 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Sun, 4 Jan 2009 17:13:24 +0000
Subject: [Ironruby-core] IronRuby and VS2010
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88A40@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <a04554c00901040541u488f5f9fgb37b900aace2acc2@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC88A40@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <a04554c00901040913t100c14e9p5d21ac8f45944e50@mail.gmail.com>

Hi Curt,

Thanks for the reply, seems to make sense. So it sounds like once CLR4
is RTM, it won't be so much of a problem which is good....  For now,
I'll just use IronPython :)

Cheers

Ben




On Sun, Jan 4, 2009 at 4:50 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
> Your understanding of the situation is basically correct.
>
> Internally, we call the parts of the DLR that are in Microsoft.Scripting.Core.dll the "inner ring" and the parts that are in Microsoft.Scripting.dll the "outer ring".  The bits in the inner ring are pretty stable; its functionality was defined some time ago and is relatively nailed down now.  There have been bug fixes and small changes, but for the most part we're pretty happy with the specific features that it contains.  There will undoubtedly continue to be small changes between now and the time that CLR4 is released.
>
> Given that we will want people to be able to play with the dynamic features in C# and VB, I'm sure we'll release builds of the languages that correspond with subsequent CTPs and betas of CLR4/VS2010.  But we may again have to use slightly older versions of the sources.  The reason there was no build of IronRuby for the first CTP was that its snapshot was taken at the end of August, when IronRuby didn't yet support IDynamicObject.
>
> "DLR 1.0" is expected to contain the finalized bits from CLR4.  This means that language source which builds against DLR 1.0 (for CLR2) will also build against CLR4.  Everything should be sync'd up and happy.
>
> It's too early to speculate on a post-DLR-1.0 world, but it's reasonable to assume that we'll have similar issues as more functionality migrates from the outer ring to the inner ring of the DLR.  But I expect that the CLR2+DLR1/CLR4 platform ought to be a stable base to build languages from for some time.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Sunday, January 04, 2009 5:42 AM
> To: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] IronRuby and VS2010
>
> Hello,
>
> I've just been playing around with IronRuby and VS2010.  If I
> understand the situation correctly, Microsoft.Scripting.Core has been
> integrated into .Net 4.0, leaving Microsoft.Scripting to hold the Ast
> and the Hosting API?
>
> Because of this, you can only use a particular build of IronPython
> (http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448).
>  As a result, you can't use IronRuby yet because there isn't an
> assiocated build using the same DLR engine?
>
> This seems quite a strong dependency between .Net and the DLR.  Only
> allowing particular builds of the langauge to work against a
> particular version of the framework sounds like it will be a nightmare
> to manage. Are we going to be in the position where we have a
> Community\Bleeding Edge Build and .Net framework build?
>
> Is this going to change in the next beta \ CTP?
>
> Thanks
>
> Ben
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From lists at ruby-forum.com  Mon Jan  5 05:47:22 2009
From: lists at ruby-forum.com (Colin Jack)
Date: Mon, 5 Jan 2009 11:47:22 +0100
Subject: [Ironruby-core] Error retrieving from github
Message-ID: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>

Hi,

I've been trying to get IronRuby from GIT using the steps in Ben's blog
(http://blog.benhall.me.uk/2008/12/downloading-ironruby-from-github.html)
but keep getting this error:

github.com[0: 65.74.177.129]: errno=Invalid argument
fatal: unable to connect a socket (Invalid argument)

I was wondering if anyone else has seen this or could point me in the
right direction?

Thanks,

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

From ben2004uk at googlemail.com  Mon Jan  5 05:51:25 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Mon, 5 Jan 2009 10:51:25 +0000
Subject: [Ironruby-core] Loading Assemblies
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED152564BCB4EA@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <a04554c00812091014y1bcaee9did573e09e91261bc@mail.gmail.com>
	<4a68b8cf0812091145g3326132dr8cabb095f1239b2b@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2287D717@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a04554c00812100112x57b17105w93cae38547b4dca4@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED152564BCB4EA@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <a04554c00901050251v39842c21u118561c79c9eabb1@mail.gmail.com>

I'm back in the office so decided to give this another go.  The
problem is, it appears to keep attempting to load a particular
assembly, resulting in a stackoverflowexception. The method
Assembly.load_from(path) never appears to return.

I've tried to put a (if already saw then don't load) but I get an
error "Expected System.Reflection.Assembly, got System.Dynamic.Null"
This is because i do return nil, but i'm sure that's what I did in C#.

This works in IronPython, but I can't find the code where its
implemented within the codebase :(

Anyone for any ideas on this?

Thanks

Ben

On Wed, Dec 10, 2008 at 3:30 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
> CurrentDomain is a static method, not a class -- so you want
> System::AppDomain.current_domain
>
> The AssemblyResolve event comes with its own set of odd side effects that may bite, but it is how IronPython deals with the issue.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Wednesday, December 10, 2008 1:12 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Loading Assemblies
>
> Thanks for the responses.
>
> Tomas is right, the appdomain didn't work (plus, it feels as dirty as
> copying all the assemblies).
>
> I wanted to hook into the AssemblyResolve event on the AppDomain,
> however it appears as if I don't have access to the appdomain!  When I
> try System::AppDomain::CurrentDomain.methods, I get a NameError again.
> Disappointing :(
>
> I'll see if I can come up with some hacky way, its a shame that I
> can't manualy load in all the assemblies and you attempt to load them
> from the AppDomain first (then I would have a require 'sdk.rb' file
> with all the dependencies loaded in order)
>
>
> Thanks
>
> Ben
>
> On Tue, Dec 9, 2008 at 9:46 PM, Tomas Matousek
> <Tomas.Matousek at microsoft.com> wrote:
>> No. You need to set it in App.config. But I think the probe path could only be a subdirectory of the app. That means a subdirectory of a path where ir.exe is.
>>
>> We are working on improving assembly loading for IronRuby.
>>
>> Tomas
>>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
>> Sent: Tuesday, December 09, 2008 11:46 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] Loading Assemblies
>>
>>> require 'C:\Program Files\SDK\a.dll'
>>> require 'C:\Program Files\SDK\b.dll'
>>> require 'C:\Program Files\SDK\c.dll'
>>
>> Never tried that with IronRuby, but would the following work ?
>>
>> $LOAD_PATH << 'C:\Program Files\SDK\'
>>
>> -- Thibaut
>>
>>>
>>> B has a dependency on a.  a loads file, but when loading b.dll an
>>> exception is thrown within LoadTypesFromAssembly because it cannot
>>> find a.dll.
>>>
>>> This is a serious problem, without copying all the assemblies into my
>>> IronRuby directory I'm not sure how to load the types and use our SDK?
>>> Installing into the GAC isn't an option.
>>>
>>> Please help!
>>>
>>> Thanks
>>>
>>> Ben
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From jirapong.nanta at gmail.com  Mon Jan  5 06:12:47 2009
From: jirapong.nanta at gmail.com (jirapong.nanta at gmail.com)
Date: Mon, 5 Jan 2009 18:12:47 +0700
Subject: [Ironruby-core] Error retrieving from github
In-Reply-To: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>
References: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>
Message-ID: <9AEF8155-9798-4F26-AF11-1F9000813630@gmail.com>

Hi Colin,
	You might want to check with this guide http://github.com/guides/getting-a-copy-of-your-github-repo 
   first.

Hope this helps,
-Jirapong


On Jan 5, 2009, at 5:47 PM, Colin Jack wrote:

> Hi,
>
> I've been trying to get IronRuby from GIT using the steps in Ben's  
> blog
> (http://blog.benhall.me.uk/2008/12/downloading-ironruby-from-github.html 
> )
> but keep getting this error:
>
> github.com[0: 65.74.177.129]: errno=Invalid argument
> fatal: unable to connect a socket (Invalid argument)
>
> I was wondering if anyone else has seen this or could point me in the
> right direction?
>
> Thanks,
>
> Colin
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From charles.nutter at Sun.COM  Mon Jan  5 09:26:08 2009
From: charles.nutter at Sun.COM (Charles Oliver Nutter)
Date: Mon, 05 Jan 2009 14:26:08 +0000
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <49621880.9070306@sun.com>

kill and raise might be a bit of a bother if you add warnings, since 
they're used in several libraries without any good replacement other 
than reimpl (usually to interrupt stuck IO operations). But yeah, I'd be 
on board with an across-the-board Thread.critical= warning in both JRuby 
and IronRuby.

Tomas Matousek wrote:
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
> 
> Tomas
> 
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
> 
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
> 
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
> 
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
> 
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
> 
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From lists at ruby-forum.com  Mon Jan  5 10:13:57 2009
From: lists at ruby-forum.com (Colin Jack)
Date: Mon, 5 Jan 2009 16:13:57 +0100
Subject: [Ironruby-core] Error retrieving from github
In-Reply-To: <9AEF8155-9798-4F26-AF11-1F9000813630@gmail.com>
References: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>
	<9AEF8155-9798-4F26-AF11-1F9000813630@gmail.com>
Message-ID: <799e831a0ca6120f011c31615a699407@ruby-forum.com>

Jirapong Nanta wrote:
> Hi Colin,
>   You might want to check with this guide 
> http://github.com/guides/getting-a-copy-of-your-github-repo
>    first.
> 
> Hope this helps,
> -Jirapong


Ta for the link, done all that now but same error. However "ssh -v 
git at github.com" failed so I'm guessing it must be a firewall/proxy error 
but can't get that config to work either and using HTTP just brings 
other errors (http://github.com/blog/92-http-cloning).

Guess its just a little less friendly that I would have hoped, will keep 
trying anyway.

Ta,

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

From michael.letterle at gmail.com  Mon Jan  5 10:48:21 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Mon, 5 Jan 2009 10:48:21 -0500
Subject: [Ironruby-core] Error retrieving from github
In-Reply-To: <799e831a0ca6120f011c31615a699407@ruby-forum.com>
References: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>
	<9AEF8155-9798-4F26-AF11-1F9000813630@gmail.com>
	<799e831a0ca6120f011c31615a699407@ruby-forum.com>
Message-ID: <ef5222770901050748y382251b6w51bf7f50c4e8c54e@mail.gmail.com>

To just do a clone, you shouldn't need ssh or any special firewall rules try
using http instead:  git clone http://github.com/ironruby/ironruby.git

On Mon, Jan 5, 2009 at 10:13 AM, Colin Jack <lists at ruby-forum.com> wrote:

> Jirapong Nanta wrote:
> > Hi Colin,
> >   You might want to check with this guide
> > http://github.com/guides/getting-a-copy-of-your-github-repo
> >    first.
> >
> > Hope this helps,
> > -Jirapong
>
>
> Ta for the link, done all that now but same error. However "ssh -v
> git at github.com" failed so I'm guessing it must be a firewall/proxy error
> but can't get that config to work either and using HTTP just brings
> other errors (http://github.com/blog/92-http-cloning).
>
> Guess its just a little less friendly that I would have hoped, will keep
> trying anyway.
>
> Ta,
>
> Colin
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090105/73ab5c6c/attachment.html>

From lists at ruby-forum.com  Mon Jan  5 10:56:06 2009
From: lists at ruby-forum.com (Colin Jack)
Date: Mon, 5 Jan 2009 16:56:06 +0100
Subject: [Ironruby-core] Error retrieving from github
In-Reply-To: <ef5222770901050748y382251b6w51bf7f50c4e8c54e@mail.gmail.com>
References: <31ef2446365ffcdc3dccc48648a2fb63@ruby-forum.com>
	<9AEF8155-9798-4F26-AF11-1F9000813630@gmail.com>
	<799e831a0ca6120f011c31615a699407@ruby-forum.com>
	<ef5222770901050748y382251b6w51bf7f50c4e8c54e@mail.gmail.com>
Message-ID: <9d5117c68482d0f3afffae665ffbad2a@ruby-forum.com>

Michael Letterle wrote:
> To just do a clone, you shouldn't need ssh or any special firewall rules 
> try
> using http instead:  git clone http://github.com/ironruby/ironruby.git

Hi,

Yeah I tried that but got other errors ("Cannot get remote repository 
information"). I'm guessing its proxy relate but I feel like I've wasted 
way too much time chasing my tail with so I must admit I gave up and 
just download the zip from github.

Ta to you Jirapong for the help, I guess I need to learn to use git at 
some point.

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

From Shri.Borde at microsoft.com  Mon Jan  5 13:03:29 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 5 Jan 2009 10:03:29 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>

Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.

Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.

Thanks,
Shri


-----Original Message-----
From: Tomas Matousek
Sent: Saturday, January 03, 2009 11:52 AM
To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Thread#raise

I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.

Tomas

-----Original Message-----
From: Curt Hagenlocher
Sent: Tuesday, December 30, 2008 10:05 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Thread#raise

Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.

Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html

-----Original Message-----
From: Shri Borde
Sent: Monday, December 29, 2008 3:00 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Thread#raise

  tfpt review "/shelveset:raise;REDMOND\sborde"
  Comment  :
  Implements Thread#raise using Thread.Abort, and added tests for it
  Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
  Enabled test for timeout as well
  Remaining work (not high pri for now)
   - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
   - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
   - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException

  RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example



From Shri.Borde at microsoft.com  Mon Jan  5 13:18:17 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 5 Jan 2009 10:18:17 -0800
Subject: [Ironruby-core] Code Review: Thread.critical
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>


  tfpt review "/shelveset:critical;REDMOND\sborde"

Microsoft.Scripting.dll: 

  Fix to interpreter to get better stack trace even when call-site caching kicks in. The try-catch needs to be added to all code that can throw an exception in the interpreter (or preferably in one function like Interpreter.Interpret), but I have not done that here.

IronRuby:

  Implements Thread.critical= by using Monitor.Enter/Exit. This will work for 90% or more of scenarios IMO. MRI does not schedule other threads while Thread.critical is true (while IronRuby will), but this is more an implementation detail that falls out with the green threads scheduler, than something that should be by spec. In fact, other threads do get scheduled anyway if the critical thread does Thread.pass etc (added tests to show this behavior if you want to play with it).
  Added tests
  Added irtests.bat to run all IronRuby tests with a single command, in four processes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: critical.diff
Type: application/octet-stream
Size: 3002 bytes
Desc: critical.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090105/c2f8acd4/attachment-0001.obj>

From Shri.Borde at microsoft.com  Mon Jan  5 13:22:50 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 5 Jan 2009 10:22:50 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <49621880.9070306@sun.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<49621880.9070306@sun.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB0FD@NA-EXMSG-C104.redmond.corp.microsoft.com>

I replied before seeing this...

Taking a sampling of a few gems, I think it should actually be the other way. Mongrel and webbrick do use Thread#kill to kill a background thread, but other gems do not. Thread#raise was also used in just a couple of places to raise a timeout error. And it is very hard, if not impossible, to use these APIs safely since you do not know what the other thread is doing. 

OTOH, Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used way more widely, and a warning for this will cause lot of false alarms.

Thanks,
Shri


-----Original Message-----
From: Charles.O.Nutter at sun.com [mailto:Charles.O.Nutter at sun.com] On Behalf Of Charles Oliver Nutter
Sent: Monday, January 05, 2009 6:26 AM
To: ironruby-core at rubyforge.org
Cc: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
Subject: Re: [Ironruby-core] Code Review: Thread#raise

kill and raise might be a bit of a bother if you add warnings, since
they're used in several libraries without any good replacement other
than reimpl (usually to interrupt stuck IO operations). But yeah, I'd be
on board with an across-the-board Thread.critical= warning in both JRuby
and IronRuby.

Tomas Matousek wrote:
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>
> Tomas
>
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
>
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core



From jdeville at microsoft.com  Mon Jan  5 13:57:55 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Mon, 5 Jan 2009 10:57:55 -0800
Subject: [Ironruby-core] Code Review: Thread.critical
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55B3295@NA-EXMSG-C112.redmond.corp.microsoft.com>

I'd rather see the functionality in irtest.bat in IronRuby's run.bat. That way it runs with run 0. 

The specs will probably need to be cleaned up to meet RubySpec style guidelines, and to get Brian to approve them. Go ahead and commit them, and I can clean them up, or we can work on them together later.

For future reference, style guidelines are here: http://rubyspec.org/wiki/rubyspec/Style_Guide

JD

-----Original Message-----
From: Shri Borde 
Sent: Monday, January 05, 2009 10:18 AM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Thread.critical


  tfpt review "/shelveset:critical;REDMOND\sborde"

Microsoft.Scripting.dll: 

  Fix to interpreter to get better stack trace even when call-site caching kicks in. The try-catch needs to be added to all code that can throw an exception in the interpreter (or preferably in one function like Interpreter.Interpret), but I have not done that here.

IronRuby:

  Implements Thread.critical= by using Monitor.Enter/Exit. This will work for 90% or more of scenarios IMO. MRI does not schedule other threads while Thread.critical is true (while IronRuby will), but this is more an implementation detail that falls out with the green threads scheduler, than something that should be by spec. In fact, other threads do get scheduled anyway if the critical thread does Thread.pass etc (added tests to show this behavior if you want to play with it).
  Added tests
  Added irtests.bat to run all IronRuby tests with a single command, in four processes



From ivan at flanders.co.nz  Mon Jan  5 14:44:45 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Mon, 5 Jan 2009 20:44:45 +0100
Subject: [Ironruby-core] ASP.NET integration ?
Message-ID: <b1c6aabb0901051144x69e57c70pe24207ed46e73df9@mail.gmail.com>

As my chapter on Rails is coming to an end I'd like to find out how things
are going for ASP.NET webforms or asp.net MVC integration.
Do you guys have an idea as to when we could expect something like this?

---
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/20090105/a3a01737/attachment.html>

From curth at microsoft.com  Mon Jan  5 16:22:00 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Mon, 5 Jan 2009 13:22:00 -0800
Subject: [Ironruby-core] Loading Assemblies
In-Reply-To: <a04554c00901050251v39842c21u118561c79c9eabb1@mail.gmail.com>
References: <a04554c00812091014y1bcaee9did573e09e91261bc@mail.gmail.com>
	<4a68b8cf0812091145g3326132dr8cabb095f1239b2b@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2287D717@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a04554c00812100112x57b17105w93cae38547b4dca4@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED152564BCB4EA@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<a04554c00901050251v39842c21u118561c79c9eabb1@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8903C@NA-EXMSG-C118.redmond.corp.microsoft.com>

The IronPython assembly resolver is in PythonContext.cs.  It's definitely worth reviewing.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
Sent: Monday, January 05, 2009 2:51 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Loading Assemblies

I'm back in the office so decided to give this another go.  The
problem is, it appears to keep attempting to load a particular
assembly, resulting in a stackoverflowexception. The method
Assembly.load_from(path) never appears to return.

I've tried to put a (if already saw then don't load) but I get an
error "Expected System.Reflection.Assembly, got System.Dynamic.Null"
This is because i do return nil, but i'm sure that's what I did in C#.

This works in IronPython, but I can't find the code where its
implemented within the codebase :(

Anyone for any ideas on this?

Thanks

Ben

On Wed, Dec 10, 2008 at 3:30 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
> CurrentDomain is a static method, not a class -- so you want
> System::AppDomain.current_domain
>
> The AssemblyResolve event comes with its own set of odd side effects that may bite, but it is how IronPython deals with the issue.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Wednesday, December 10, 2008 1:12 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Loading Assemblies
>
> Thanks for the responses.
>
> Tomas is right, the appdomain didn't work (plus, it feels as dirty as
> copying all the assemblies).
>
> I wanted to hook into the AssemblyResolve event on the AppDomain,
> however it appears as if I don't have access to the appdomain!  When I
> try System::AppDomain::CurrentDomain.methods, I get a NameError again.
> Disappointing :(
>
> I'll see if I can come up with some hacky way, its a shame that I
> can't manualy load in all the assemblies and you attempt to load them
> from the AppDomain first (then I would have a require 'sdk.rb' file
> with all the dependencies loaded in order)
>
>
> Thanks
>
> Ben
>
> On Tue, Dec 9, 2008 at 9:46 PM, Tomas Matousek
> <Tomas.Matousek at microsoft.com> wrote:
>> No. You need to set it in App.config. But I think the probe path could only be a subdirectory of the app. That means a subdirectory of a path where ir.exe is.
>>
>> We are working on improving assembly loading for IronRuby.
>>
>> Tomas
>>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
>> Sent: Tuesday, December 09, 2008 11:46 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] Loading Assemblies
>>
>>> require 'C:\Program Files\SDK\a.dll'
>>> require 'C:\Program Files\SDK\b.dll'
>>> require 'C:\Program Files\SDK\c.dll'
>>
>> Never tried that with IronRuby, but would the following work ?
>>
>> $LOAD_PATH << 'C:\Program Files\SDK\'
>>
>> -- Thibaut
>>
>>>
>>> B has a dependency on a.  a loads file, but when loading b.dll an
>>> exception is thrown within LoadTypesFromAssembly because it cannot
>>> find a.dll.
>>>
>>> This is a serious problem, without copying all the assemblies into my
>>> IronRuby directory I'm not sure how to load the types and use our SDK?
>>> Installing into the GAC isn't an option.
>>>
>>> Please help!
>>>
>>> Thanks
>>>
>>> Ben
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From curth at microsoft.com  Mon Jan  5 16:32:56 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Mon, 5 Jan 2009 13:32:56 -0800
Subject: [Ironruby-core] Code Review: Thread.critical
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC89061@NA-EXMSG-C118.redmond.corp.microsoft.com>

The implementation of ThreadOps._CriticalMonitor and ThreadOps._IsInCriticalRegion as class-level fields will cause state information to leak between ScriptRuntimes.  These should probably be put on the RubyContext, which can either be done directly or by using        RubyContext.GetOrCreateLibraryData to create it dynamically.

Looks good otherwise.

-----Original Message-----
From: Shri Borde
Sent: Monday, January 05, 2009 10:18 AM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Thread.critical


  tfpt review "/shelveset:critical;REDMOND\sborde"

Microsoft.Scripting.dll:

  Fix to interpreter to get better stack trace even when call-site caching kicks in. The try-catch needs to be added to all code that can throw an exception in the interpreter (or preferably in one function like Interpreter.Interpret), but I have not done that here.

IronRuby:

  Implements Thread.critical= by using Monitor.Enter/Exit. This will work for 90% or more of scenarios IMO. MRI does not schedule other threads while Thread.critical is true (while IronRuby will), but this is more an implementation detail that falls out with the green threads scheduler, than something that should be by spec. In fact, other threads do get scheduled anyway if the critical thread does Thread.pass etc (added tests to show this behavior if you want to play with it).
  Added tests
  Added irtests.bat to run all IronRuby tests with a single command, in four processes



From Jimmy.Schementi at microsoft.com  Mon Jan  5 17:50:31 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Mon, 5 Jan 2009 14:50:31 -0800
Subject: [Ironruby-core] ASP.NET integration ?
In-Reply-To: <b1c6aabb0901051144x69e57c70pe24207ed46e73df9@mail.gmail.com>
References: <b1c6aabb0901051144x69e57c70pe24207ed46e73df9@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDEF6D117@NA-EXMSG-C116.redmond.corp.microsoft.com>

Phil Haack and I were working on a ASP.NET MVC integration. I have a older snapshot here: http://github.com/jschementi/ironrubymvc. He was working on filter support, and I haven't synced up with him yet, but I'm planning on it shortly.

For webforms, there's a rough integration that Tomas made a while ago, and I'm playing with it now. That code will be on http://codeplex.com/aspnet the next time the Dynamic Language bits are updated ... which will be soon to update everything for IronPython 2.0.

~js

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Monday, January 05, 2009 11:45 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] ASP.NET integration ?


As my chapter on Rails is coming to an end I'd like to find out how things are going for ASP.NET<http://ASP.NET> webforms or asp.net<http://asp.net> MVC integration.
Do you guys have an idea as to when we could expect something like this?

---
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/20090105/40f1be79/attachment-0001.html>

From Shri.Borde at microsoft.com  Mon Jan  5 18:49:01 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 5 Jan 2009 15:49:01 -0800
Subject: [Ironruby-core] Thread.key failure
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55B34A5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD02CB454@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55B34A5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB45F@NA-EXMSG-C104.redmond.corp.microsoft.com>

OK, atleast I know its not me.

From: Jim Deville
Sent: Monday, January 05, 2009 3:47 PM
To: Shri Borde
Subject: RE: Thread.key failure

Fails for me on CRuby 186p287

JD

From: Shri Borde
Sent: Monday, January 05, 2009 3:45 PM
To: Jim Deville
Subject: Thread.key failure

Could you try running this command:

runrspec -ruby thread\key_spec.rb

It is failing for me. It works with IronRuby (without the -ruby option), and also if I try it out by hand in irb.

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Tue Jan  6 00:50:02 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 5 Jan 2009 21:50:02 -0800
Subject: [Ironruby-core] Code Review: Thread.critical
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC89061@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD02CB0E2@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC89061@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB56A@NA-EXMSG-C104.redmond.corp.microsoft.com>

Good catch. I have fixed the issue. Also updated the tests according to Jim's suggestions. Also, the last test using Thread.kill was wrong but seemed to succeed since "flunk" fails silently when used on the non-main thread. New patch included if you want to take a look. Will go ahead and submit to Snap.

-----Original Message-----
From: Curt Hagenlocher 
Sent: Monday, January 05, 2009 1:33 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Thread.critical

The implementation of ThreadOps._CriticalMonitor and ThreadOps._IsInCriticalRegion as class-level fields will cause state information to leak between ScriptRuntimes.  These should probably be put on the RubyContext, which can either be done directly or by using        RubyContext.GetOrCreateLibraryData to create it dynamically.

Looks good otherwise.

-----Original Message-----
From: Shri Borde 
Sent: Monday, January 05, 2009 10:18 AM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Thread.critical


  tfpt review "/shelveset:critical;REDMOND\sborde"

Microsoft.Scripting.dll: 

  Fix to interpreter to get better stack trace even when call-site caching kicks in. The try-catch needs to be added to all code that can throw an exception in the interpreter (or preferably in one function like Interpreter.Interpret), but I have not done that here.

IronRuby:

  Implements Thread.critical= by using Monitor.Enter/Exit. This will work for 90% or more of scenarios IMO. MRI does not schedule other threads while Thread.critical is true (while IronRuby will), but this is more an implementation detail that falls out with the green threads scheduler, than something that should be by spec. In fact, other threads do get scheduled anyway if the critical thread does Thread.pass etc (added tests to show this behavior if you want to play with it).
  Added tests
  Added irtests.bat to run all IronRuby tests with a single command, in four processes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: critical.diff
Type: application/octet-stream
Size: 6524 bytes
Desc: critical.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090105/9f1d4778/attachment.obj>

From suppakilla at gmail.com  Tue Jan  6 10:38:55 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Tue, 6 Jan 2009 16:38:55 +0100
Subject: [Ironruby-core] Kernel#puts and Kernel#print with NaN and Infinity
	values
Message-ID: <3bf20550901060738v753fae1bg64a99948d16e15a3@mail.gmail.com>

Hello,

while I was filing a bug report regarding a different behaviour of
Math#hypot compared to the one verified under MRI 1.8.6 (see
http://is.gd/eGHa), I noticed that when a Float instance holds the
values NaN or Infinity then both Kernel#puts and Kernel#print emit
strings localized according to the language settings of the underlying
system. See below, returned strings are in Italian:


IronRuby (SVN r181)
>>> 0.0 / 0
=> NaN
>>> printf("%s", 0.0 / 0)
NaN=> nil
>>> puts 0.0 / 0
Non un numero reale
=> nil
>>> 1.0 / 0
=> Infinity
>>> printf("%s", 1.0 / 0)
Infinity=> nil
>>> puts 1.0 / 0
+Infinito
=> nil


MRI 1.8.6
irb(main):001:0> 0.0 / 0
=> NaN
irb(main):002:0> printf("%s", 0.0 / 0)
NaN=> nil
irb(main):003:0> puts 0.0 / 0
NaN
=> nil
irb(main):004:0> 1.0 / 0
=> Infinity
irb(main):005:0> printf("%s", 1.0 / 0)
Infinity=> nil
irb(main):006:0> puts 1.0 / 0
Infinity


Should this be considered a bug?

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From Tomas.Matousek at microsoft.com  Tue Jan  6 11:07:44 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 6 Jan 2009 08:07:44 -0800
Subject: [Ironruby-core] Kernel#puts and Kernel#print with NaN and
 Infinity	values
In-Reply-To: <3bf20550901060738v753fae1bg64a99948d16e15a3@mail.gmail.com>
References: <3bf20550901060738v753fae1bg64a99948d16e15a3@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C78A9@NA-EXMSG-C112.redmond.corp.microsoft.com>

Yes, could you please file it?

Thanks,
Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri
Sent: Tuesday, January 06, 2009 7:39 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Kernel#puts and Kernel#print with NaN and Infinity values

Hello,

while I was filing a bug report regarding a different behaviour of
Math#hypot compared to the one verified under MRI 1.8.6 (see
http://is.gd/eGHa), I noticed that when a Float instance holds the
values NaN or Infinity then both Kernel#puts and Kernel#print emit
strings localized according to the language settings of the underlying
system. See below, returned strings are in Italian:


IronRuby (SVN r181)
>>> 0.0 / 0
=> NaN
>>> printf("%s", 0.0 / 0)
NaN=> nil
>>> puts 0.0 / 0
Non un numero reale
=> nil
>>> 1.0 / 0
=> Infinity
>>> printf("%s", 1.0 / 0)
Infinity=> nil
>>> puts 1.0 / 0
+Infinito
=> nil


MRI 1.8.6
irb(main):001:0> 0.0 / 0
=> NaN
irb(main):002:0> printf("%s", 0.0 / 0)
NaN=> nil
irb(main):003:0> puts 0.0 / 0
NaN
=> nil
irb(main):004:0> 1.0 / 0
=> Infinity
irb(main):005:0> printf("%s", 1.0 / 0)
Infinity=> nil
irb(main):006:0> puts 1.0 / 0
Infinity


Should this be considered a bug?

--
Daniele Alessandri
http://www.clorophilla.net/blog/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From suppakilla at gmail.com  Tue Jan  6 11:47:24 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Tue, 6 Jan 2009 17:47:24 +0100
Subject: [Ironruby-core] Kernel#puts and Kernel#print with NaN and
	Infinity values
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C78A9@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <3bf20550901060738v753fae1bg64a99948d16e15a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B248C78A9@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <3bf20550901060847w2248d3f1p2c6467f6282321c8@mail.gmail.com>

On Tue, Jan 6, 2009 at 17:07, Tomas Matousek
<Tomas.Matousek at microsoft.com> wrote:

> Yes, could you please file it?

Ok, just filed it.

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From charles.nutter at sun.com  Tue Jan  6 13:53:17 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Tue, 06 Jan 2009 18:53:17 +0000
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <4963A89D.80206@sun.com>

I think the implications of critical= in MRI are more complicated than 
just a local lock. It actually stops normal thread scheduling, so other 
threads freeze what they're doing. That's vastly more intrusive than 
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3; 
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving 
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is 
extremely easy, and of course it's nearly impossible to emulate right 
with real parallel threads since you can't easily stop them whenever you 
want.

#kill and #raise are also very tricky and dangerous, but they're at 
least localized. They can be defined in terms of a message passed from 
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
> 
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
> 
> Thanks,
> Shri
> 
> 
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
> 
> Tomas
> 
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
> 
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
> 
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
> 
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
> 
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
> 
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From Tomas.Matousek at microsoft.com  Tue Jan  6 14:16:53 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 6 Jan 2009 11:16:53 -0800
Subject: [Ironruby-core] Code Review: InitAndScopes6
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C79F6@NA-EXMSG-C112.redmond.corp.microsoft.com>

tfpt review "/shelveset:InitAndScopes6;REDMOND\tomat"



Outer-ring DLR changes (Hosting API implementation):



  Any code compilation/execution without explicitly given scope should eventually call SourceUnit.Compile overload that creates a new scope for the execution, so that a) the creation of an implicit empty scope is implemented on a single place and b) the language can adjust compilation based upon whether the code is executed against a scope or not (different overloads of LanguageContext.GetCompilerOptions are called).



  Adds SourceUnit.Execute overload taking ErrorSink parameter to match Compile overloads.



Ruby changes:



  Enables sharing of Ruby top-level binding across multiple executions against the same DLR Scope, which enables local variables in a console implemented via DLR Hosting API.



  Refactors control flow handling in rules:

  -   Methods that build rules are of two kinds: BuildXxxNoFlow and BuildXxx, where the former produces a rule w/o control flow and optionally stores a control flow builder delegate on MetaObjectBuilder if CF handling is needed. The latter calls the former and if there has been a CF builder registered applies it on the resulting meta object. This allows to compose rules w/o CF and then apply CF handling once on the final result.

  -   Fixes IO#open not to dynamically dispatch to "new". The implementation requires the above rule composition.



  Scope cleanup:

  -   Renames GlobalScopeExtension to RubyGlobalScope.

  -   Removes unnecessary dependencies on RubyScope where RubyContext is sufficient.

  -   Replaces uses of Scope where RubyGlobalScope is more suitable.

  -   Removes RubyContext.DefaultGlobalScope and adds Ruby.RequireFile taking a ScriptScope.



  Replaces Booleans on RubyCompilerOptions with an enum.

  Fixes method definition in module_eval or define_method.

  Adds /py option to unit test driver, which enables tests dependent on IronPython.



Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/8e3efb20/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: InitAndScopes6.diff
Type: application/octet-stream
Size: 140799 bytes
Desc: InitAndScopes6.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/8e3efb20/attachment-0001.obj>

From Shri.Borde at microsoft.com  Tue Jan  6 14:49:36 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 6 Jan 2009 11:49:36 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <4963A89D.80206@sun.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than 
just a local lock. It actually stops normal thread scheduling, so other 
threads freeze what they're doing. That's vastly more intrusive than 
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3; 
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving 
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is 
extremely easy, and of course it's nearly impossible to emulate right 
with real parallel threads since you can't easily stop them whenever you 
want.

#kill and #raise are also very tricky and dangerous, but they're at 
least localized. They can be defined in terms of a message passed from 
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
> 
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
> 
> Thanks,
> Shri
> 
> 
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
> 
> Tomas
> 
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
> 
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
> 
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
> 
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
> 
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
> 
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From jdeville at microsoft.com  Tue Jan  6 15:17:29 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 6 Jan 2009 12:17:29 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>

-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed. 

From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.

Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect? 

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:50 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than 
just a local lock. It actually stops normal thread scheduling, so other 
threads freeze what they're doing. That's vastly more intrusive than 
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3; 
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving 
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is 
extremely easy, and of course it's nearly impossible to emulate right 
with real parallel threads since you can't easily stop them whenever you 
want.

#kill and #raise are also very tricky and dangerous, but they're at 
least localized. They can be defined in terms of a message passed from 
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
> 
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
> 
> Thanks,
> Shri
> 
> 
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
> 
> Tomas
> 
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
> 
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
> 
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
> 
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
> 
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
> 
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
> 
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From Shri.Borde at microsoft.com  Tue Jan  6 15:25:17 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 6 Jan 2009 12:25:17 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>

Is there a way to get the warning printed just the first time it was executed in the process? Uses like the get_unique_cookie example below would be called multiple times, and it would be extremely annoying to print the warning everytime the dangerous API was called.

We could build some internal infrastructure to implement this, but does Ruby have built-in support we could leverage?

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 06, 2009 12:17 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.

From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.

Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect?

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:50 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That's vastly more intrusive than
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3;
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is
extremely easy, and of course it's nearly impossible to emulate right
with real parallel threads since you can't easily stop them whenever you
want.

#kill and #raise are also very tricky and dangerous, but they're at
least localized. They can be defined in terms of a message passed from
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>
> Tomas
>
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
>
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From jdeville at microsoft.com  Tue Jan  6 15:42:04 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 6 Jan 2009 12:42:04 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F8C3@NA-EXMSG-C112.redmond.corp.microsoft.com>

Um... other than meta programming (use an if $VERBOSE block to warn, then redefine the current method to remove the $VERBOSE block)

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 12:25 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

Is there a way to get the warning printed just the first time it was executed in the process? Uses like the get_unique_cookie example below would be called multiple times, and it would be extremely annoying to print the warning everytime the dangerous API was called.

We could build some internal infrastructure to implement this, but does Ruby have built-in support we could leverage?

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 06, 2009 12:17 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.

From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.

Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect?

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:50 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That's vastly more intrusive than
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3;
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is
extremely easy, and of course it's nearly impossible to emulate right
with real parallel threads since you can't easily stop them whenever you
want.

#kill and #raise are also very tricky and dangerous, but they're at
least localized. They can be defined in terms of a message passed from
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>
> Tomas
>
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
>
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From jdeville at microsoft.com  Tue Jan  6 15:53:17 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 6 Jan 2009 12:53:17 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F8C3@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F8C3@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F8E2@NA-EXMSG-C112.redmond.corp.microsoft.com>

Nice, that made very little sense.

I was trying to say that I don't know of a way other than redefining the method after the first run.

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 06, 2009 12:42 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

Um... other than meta programming (use an if $VERBOSE block to warn, then redefine the current method to remove the $VERBOSE block)

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 12:25 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

Is there a way to get the warning printed just the first time it was executed in the process? Uses like the get_unique_cookie example below would be called multiple times, and it would be extremely annoying to print the warning everytime the dangerous API was called.

We could build some internal infrastructure to implement this, but does Ruby have built-in support we could leverage?

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 06, 2009 12:17 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.

From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.

Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect?

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:50 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That's vastly more intrusive than
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3;
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is
extremely easy, and of course it's nearly impossible to emulate right
with real parallel threads since you can't easily stop them whenever you
want.

#kill and #raise are also very tricky and dangerous, but they're at
least localized. They can be defined in terms of a message passed from
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>
> Tomas
>
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
>
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From Tomas.Matousek at microsoft.com  Tue Jan  6 16:09:15 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 6 Jan 2009 13:09:15 -0800
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C7AF7@NA-EXMSG-C112.redmond.corp.microsoft.com>

No, Ruby doesn't have any such warning filter. You can place a flag on RubyContext (via GetOrCreateLibraryData) that remembers for the current runtime that the warning has already been reported.

Tomas

-----Original Message-----
From: Shri Borde
Sent: Tuesday, January 06, 2009 12:25 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: RE: [Ironruby-core] Code Review: Thread#raise

Is there a way to get the warning printed just the first time it was executed in the process? Uses like the get_unique_cookie example below would be called multiple times, and it would be extremely annoying to print the warning everytime the dangerous API was called.

We could build some internal infrastructure to implement this, but does Ruby have built-in support we could leverage?

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 06, 2009 12:17 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.

From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.

Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect?

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:50 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.

def get_unique_cookie()
  begin
    Thread.critical = true
    cookie = @@counter
    @@counter += 1
  ensure
    Thread.critical = false
  end
  cookie
end

I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.

Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core at rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That's vastly more intrusive than
just a lock or critical section:

? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3;
Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving
critical'; Thread.critical = false; sleep 3"
Tue Jan 06 18:50:34 +0000 2009
Tue Jan 06 18:50:35 +0000 2009
critical
leaving critical
Tue Jan 06 18:50:39 +0000 2009
Tue Jan 06 18:50:40 +0000 2009
Tue Jan 06 18:50:41 +0000 2009

If those other threads are holding locks or resources, deadlock is
extremely easy, and of course it's nearly impossible to emulate right
with real parallel threads since you can't easily stop them whenever you
want.

#kill and #raise are also very tricky and dangerous, but they're at
least localized. They can be defined in terms of a message passed from
one thread to another plus a periodic message checkpoint.

I still believe critical= is much more in need of a warning.

Shri Borde wrote:
> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>
> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: Tomas Matousek
> Sent: Saturday, January 03, 2009 11:52 AM
> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>
> Tomas
>
> -----Original Message-----
> From: Curt Hagenlocher
> Sent: Tuesday, December 30, 2008 10:05 PM
> To: Shri Borde; IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: RE: Code Review: Thread#raise
>
> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>
> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>
> -----Original Message-----
> From: Shri Borde
> Sent: Monday, December 29, 2008 3:00 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: Code Review: Thread#raise
>
>   tfpt review "/shelveset:raise;REDMOND\sborde"
>   Comment  :
>   Implements Thread#raise using Thread.Abort, and added tests for it
>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>   Enabled test for timeout as well
>   Remaining work (not high pri for now)
>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>
>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From curth at microsoft.com  Tue Jan  6 16:41:02 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Tue, 6 Jan 2009 13:41:02 -0800
Subject: [Ironruby-core] Code Review: InitAndScopes6
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C79F6@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B248C79F6@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AD8C430@NA-EXMSG-C118.redmond.corp.microsoft.com>

Awesome!  Ruby changes are good (other than a typo "bidning" in a comment in HostingTests.cs :)).

From: Tomas Matousek
Sent: Tuesday, January 06, 2009 11:17 AM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: InitAndScopes6


tfpt review "/shelveset:InitAndScopes6;REDMOND\tomat"



Outer-ring DLR changes (Hosting API implementation):



  Any code compilation/execution without explicitly given scope should eventually call SourceUnit.Compile overload that creates a new scope for the execution, so that a) the creation of an implicit empty scope is implemented on a single place and b) the language can adjust compilation based upon whether the code is executed against a scope or not (different overloads of LanguageContext.GetCompilerOptions are called).



  Adds SourceUnit.Execute overload taking ErrorSink parameter to match Compile overloads.



Ruby changes:



  Enables sharing of Ruby top-level binding across multiple executions against the same DLR Scope, which enables local variables in a console implemented via DLR Hosting API.



  Refactors control flow handling in rules:

  -   Methods that build rules are of two kinds: BuildXxxNoFlow and BuildXxx, where the former produces a rule w/o control flow and optionally stores a control flow builder delegate on MetaObjectBuilder if CF handling is needed. The latter calls the former and if there has been a CF builder registered applies it on the resulting meta object. This allows to compose rules w/o CF and then apply CF handling once on the final result.

  -   Fixes IO#open not to dynamically dispatch to "new". The implementation requires the above rule composition.



  Scope cleanup:

  -   Renames GlobalScopeExtension to RubyGlobalScope.

  -   Removes unnecessary dependencies on RubyScope where RubyContext is sufficient.

  -   Replaces uses of Scope where RubyGlobalScope is more suitable.

  -   Removes RubyContext.DefaultGlobalScope and adds Ruby.RequireFile taking a ScriptScope.



  Replaces Booleans on RubyCompilerOptions with an enum.

  Fixes method definition in module_eval or define_method.

  Adds /py option to unit test driver, which enables tests dependent on IronPython.



Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/9620d8aa/attachment.html>

From jomes at microsoft.com  Tue Jan  6 16:50:15 2009
From: jomes at microsoft.com (John Messerly)
Date: Tue, 6 Jan 2009 13:50:15 -0800
Subject: [Ironruby-core] Code Review: InitAndScopes6
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AD8C430@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B248C79F6@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AD8C430@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <918705E903F4714CB713D89AB5F1857D883224C907@NA-EXMSG-C116.redmond.corp.microsoft.com>

DLR changes look good too.

From: Curt Hagenlocher
Sent: Tuesday, January 06, 2009 1:41 PM
To: Tomas Matousek; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: InitAndScopes6

Awesome!  Ruby changes are good (other than a typo "bidning" in a comment in HostingTests.cs :)).

From: Tomas Matousek
Sent: Tuesday, January 06, 2009 11:17 AM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: InitAndScopes6


tfpt review "/shelveset:InitAndScopes6;REDMOND\tomat"



Outer-ring DLR changes (Hosting API implementation):



  Any code compilation/execution without explicitly given scope should eventually call SourceUnit.Compile overload that creates a new scope for the execution, so that a) the creation of an implicit empty scope is implemented on a single place and b) the language can adjust compilation based upon whether the code is executed against a scope or not (different overloads of LanguageContext.GetCompilerOptions are called).



  Adds SourceUnit.Execute overload taking ErrorSink parameter to match Compile overloads.



Ruby changes:



  Enables sharing of Ruby top-level binding across multiple executions against the same DLR Scope, which enables local variables in a console implemented via DLR Hosting API.



  Refactors control flow handling in rules:

  -   Methods that build rules are of two kinds: BuildXxxNoFlow and BuildXxx, where the former produces a rule w/o control flow and optionally stores a control flow builder delegate on MetaObjectBuilder if CF handling is needed. The latter calls the former and if there has been a CF builder registered applies it on the resulting meta object. This allows to compose rules w/o CF and then apply CF handling once on the final result.

  -   Fixes IO#open not to dynamically dispatch to "new". The implementation requires the above rule composition.



  Scope cleanup:

  -   Renames GlobalScopeExtension to RubyGlobalScope.

  -   Removes unnecessary dependencies on RubyScope where RubyContext is sufficient.

  -   Replaces uses of Scope where RubyGlobalScope is more suitable.

  -   Removes RubyContext.DefaultGlobalScope and adds Ruby.RequireFile taking a ScriptScope.



  Replaces Booleans on RubyCompilerOptions with an enum.

  Fixes method definition in module_eval or define_method.

  Adds /py option to unit test driver, which enables tests dependent on IronPython.



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

From jdeville at microsoft.com  Tue Jan  6 18:22:22 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 6 Jan 2009 15:22:22 -0800
Subject: [Ironruby-core] SVN revision
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F9F7@NA-EXMSG-C112.redmond.corp.microsoft.com>

I've just committed a new SVN revision (182). I won't be doing a Git commit because I'm trying to get some internal changes fixed. I hope to get those changes done tonight, so I can push a new commit tomorrow.

JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/8ecc6f2e/attachment-0001.html>

From jdeville at microsoft.com  Tue Jan  6 18:32:24 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 6 Jan 2009 15:32:24 -0800
Subject: [Ironruby-core] Code Review: compilefix
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FA00@NA-EXMSG-C112.redmond.corp.microsoft.com>

FYI code review. I'm going to direct commit this, and it is already in SVN.

  tfpt review "/shelveset:compilefix;REDMOND\jdeville"
  Comment  : 
  Fix to allow rake to compile.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compilefix.diff
Type: application/octet-stream
Size: 1840 bytes
Desc: compilefix.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/bcf96d12/attachment.obj>

From Shri.Borde at microsoft.com  Wed Jan  7 02:40:40 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 6 Jan 2009 23:40:40 -0800
Subject: [Ironruby-core] Comments in the RubySpec tag files
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>

I added a few comments to critical_tags.txt like this:

fails("need to track which thread owns critical lock"):Thread.critical defers exit

This will help the next person who tries to fix the bug, and also as just documentation. However, I realized that Jim regenerates the tag files whenever he pulls down new RubySpec tests. So such comments will get lost. Jim, is that correct? If so, I will just not add such comments until we change the process so that the tags are not periodically regenerated from scratch.

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

From Shri.Borde at microsoft.com  Wed Jan  7 02:49:08 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 6 Jan 2009 23:49:08 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  : 
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: hangs.diff
Type: application/octet-stream
Size: 14893 bytes
Desc: hangs.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090106/da87d8e2/attachment-0001.obj>

From Shri.Borde at microsoft.com  Wed Jan  7 03:26:08 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 00:26:08 -0800
Subject: [Ironruby-core] compliant_on(:ruby) in RubySpecs
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B69C@NA-EXMSG-C104.redmond.corp.microsoft.com>

I noticed that besides not_compliant_on to disable tests on specific Ruby implementations, there is also compliant_on to enable tests only on selected implementations. There are ~120 such instances. To make IronRuby compliant, we not only have to reduce the number of *_tags.txt files, we also have to add ":ir" to all uses of compliant_on.

However, this seems backwards. Shouldn't we try to remove most uses of compliant_on, and instead add tags for the implementations where the test does not work? There may be a few valid uses of compliant_on for tests which only work on, say, JRuby. However, only a handful of the occurrences are of this kind. The vast majoriy include :ruby which means it should be the standard.

Should it be a goal to change compliant_on so that it does not allow :ruby?

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 03:32:14 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 00:32:14 -0800
Subject: [Ironruby-core] ScratchPad versus Channel in RubySpec
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B69D@NA-EXMSG-C104.redmond.corp.microsoft.com>

Many tests use Channel to collect data that needs to be tested. For example, the following in inspect_spec.rb.

  compliant_on(:ruby) do
    it "reports aborting on a killed thread" do
      c = Channel.new
      t = Thread.new { c << Thread.current.inspect; Thread.stop }
      c.receive.should include('run')
      t.inspect.should include('sleep')
      Thread.critical = true
      t.kill
      t.inspect.should include('aborting')
      Thread.critical = false
    end
  end

However, there is also ScratchPad which serves the same purpose. Why are there two ways of doing this, and which is the preferred one?

Also, (as we were discussing before), why does every test have to call ScratchPad.clear before using it. Shouldn't MSpec be doing this automatically?

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 03:42:52 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 00:42:52 -0800
Subject: [Ironruby-core] Thread status tests
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B69E@NA-EXMSG-C104.redmond.corp.microsoft.com>

There are four ways to check the status of threads, Thread#status, Thread#inspect, Thread#alive?, and Thread#stop?. Any objection to adding a single shared file which checks the result of all the four APIs? It won't follow the standard pattern of it_behaves_like for aliases since these are all different APIs and not aliases. However, it will help check all of them consistently. I wanted to check  if this idea made sense before pushing in that direction.

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 03:48:31 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 00:48:31 -0800
Subject: [Ironruby-core] should equal in RubySpecs
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B69F@NA-EXMSG-C104.redmond.corp.microsoft.com>

I noticed this in core\thread\current_spec.rb.

  it "returns the current thread" do
    t = Thread.new { Thread.current }
    t.value.should equal(t)
    Thread.current.should_not equal(t.value)
  end

Is this any different than writing "t.value.should == t"? Is either of them the recommended way? Seems odd to support two ways of writing the exact same thing.

Thanks,
Shri

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

From ivan at flanders.co.nz  Wed Jan  7 06:39:55 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Wed, 7 Jan 2009 12:39:55 +0100
Subject: [Ironruby-core] more gem trouble but different now
Message-ID: <b1c6aabb0901070339p55a6f8daibde320d1d9e64606@mail.gmail.com>

Hi
I got the latest svn revision for ironruby (r. 182).

I tried upgrading rubygems to version 1.3.1 (rails 2.2.2 needs it)
And it has a similar problem with the path name.
it fails with a directory not found exception

because it created a folder structure like this for generating the bin
folder
C:\External\languages\ruby\ruby-1.8.6\lib\ironruby\s\1.8\s\rubys-update-1.3.1

While the correct path should be.
C:\External\languages\ruby\ruby-1.8.6\lib\ironruby\gems\1.8\gems\rubygems-update-1.3.1

Below you can find what I submitted as a bug report to install the rails
gem.

+ C:\tools\ironruby
? igem install rake --verbose --debug
HEAD 200 OK: http://gems.rubyforge.org/latest_specs.4.8
GET 200 OK:
http://gems.rubyforge.org/quick/Marshal.4.8/rake-0.8.3.gemspec.rz
ERROR:  While executing gem ... (TypeError)
    allocator undefined for Zlib::Inflate
        c:\tools\ironruby\src\IronRuby.Libraries\zlib\zlib.cs:517:in
`inflate'
        rubygems.rb:395:in `inflate'
        spec_fetcher.rb:77:in `fetch_spec'
        spec_fetcher.rb:64:in `fetch'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'

 c:\tools\ironruby\src\IronRuby.Libraries\Builtins\Enumerable.cs:88:in `map'
        spec_fetcher.rb:61:in `fetch'
        dependency_installer.rb:75:in `find_gems_with_sources'
        dependency_installer.rb:162:in `find_spec_by_name_and_version'
        dependency_installer.rb:206:in `install'
        install_command.rb:70:in `execute'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        install_command.rb:45:in `execute'
        command.rb:129:in `invoke'
        command_manager.rb:86:in `process_args'
        command_manager.rb:74:in `run'
        gem_runner.rb:25:in `run'
        :0

When I try to install rake remotely obviously it fails.
But I then took the .gem files for rake and rails and proceeded with: igem
install --debug --local rails-2.2.2.gem
When they mean verbose they actually mean it ;)

The first time I executed the command it wasn't happy halfway through the
install process of rake; failing with a DirectoryNotFound exception. It
fails because it is looking for a bin folder that should have been created
in gems/rake-0.8.3/ folder but instead it gets created in a gems/-0.8.3
folder. Somehow it forgets which gem it is installing when it is creating
the folder.

The error
? igem install --debug --local --verbose rails-2.2.2.gem
Installing gem rake-0.8.3
Using local gem
C:/tools/ironruby/lib/IronRuby/../../../../External/languages/ruby/ruby-1.8.6//lib/ironruby/gems/1.8/cache/rake-0.8.3.gem
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/install.rb
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/CHANGES
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/MIT-LICENSE
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/Rakefile
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/README
C:/External/languages/ruby/ruby-1.8.6/lib/ironruby/gems/1.8/gems/rake-0.8.3/TODO
ERROR:  While executing gem ... (System::IO::DirectoryNotFoundException)
    Could not find a part of the path
'C:\External\languages\ruby\ruby-1.8.6\lib\ironruby\gems\1.8\gems\rake-0.8.3\bin\rake'.
        mscorlib:0:in `WinIOError'
        mscorlib:0:in `Init'
        mscorlib:0:in `.ctor'
        c:\tools\ironruby\src\IronRuby.Libraries\Builtins\FileOps.cs:402:in
`open'
        installer.rb:443:in `extract_files'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        installer.rb:438:in `extract_files'
        installer.rb:104:in `install'
        dependency_installer.rb:217:in `install'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        dependency_installer.rb:206:in `install'
        install_command.rb:70:in `execute'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        install_command.rb:45:in `execute'
        command.rb:129:in `invoke'
        command_manager.rb:86:in `process_args'
        command_manager.rb:74:in `run'
        gem_runner.rb:25:in `run'
        :0

This is fine.. I create a bin folder in the rake-0.8.3 folder and proceed
with: igem install --debug --local rake-0.8.3.gem
That actually installs the gem but fails during the rdoc generation.

ERROR:  While executing gem ... (TypeError)
    can't convert Array into String
        c:\tools\ironruby\src\IronRuby.Libraries\Builtins\FileOps.cs:288:in
`join'
        html_generator.rb:612:in `http_url'
        html_generator.rb:590:in `initialize'
        html_generator.rb:1264:in `build_class_list'
        html_generator.rb:1259:in `build_indices'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        html_generator.rb:1253:in `build_indices'
        html_generator.rb:1189:in `generate'
        rdoc.rb:249:in `document'
        doc_manager.rb:99:in `run_rdoc'
        doc_manager.rb:81:in `install_rdoc'
        doc_manager.rb:50:in `generate_rdoc'
        install_command.rb:112:in `execute'

 c:\tools\ironruby\src\IronRuby.Libraries\Extensions\IListOps.cs:700:in
`each'
        install_command.rb:45:in `execute'
        command.rb:129:in `invoke'
        command_manager.rb:86:in `process_args'
        command_manager.rb:74:in `run'
        gem_runner.rb:25:in `run'
        :0

Ok back to rails :)  igem install --debug --local --verbose rails-2.2.2.gem

so far so good rails seems to install. at least it's generating docs for
everything

next trying to run the irails -v command that fails initially because it
can't find a file gems/-2.2.2/lib/ruby_version_check
So I proceeed with copying the contents of rails-2.2.2 to -2.2.2 hoping that
that will fix my issue.

success
? irails -v
Rails 2.2.2

ok now for it to generate a rails application that fails again.

? irails ironruby-test
tried to create Proc object without a block

Cheers
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090107/d6395da0/attachment.html>

From charles.nutter at sun.com  Wed Jan  7 08:07:05 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 07 Jan 2009 13:07:05 +0000
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4964A8F9.9030700@sun.com>

Jim Deville wrote:
> -W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed. 
> 
> From what I can gather, -v, --version, -w and -W (-W with no level) are equivalent and all set $VERBOSE to true.
> 
> Charlie or Tomas, can you expand on that, or correct me if my understanding is incorrect? 

Correct.

From charles.nutter at sun.com  Wed Jan  7 08:08:17 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 07 Jan 2009 13:08:17 +0000
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C7AF7@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575F89F@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8E6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C7AF7@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4964A941.7040604@sun.com>

Tomas Matousek wrote:
> No, Ruby doesn't have any such warning filter. You can place a flag on RubyContext (via GetOrCreateLibraryData) that remembers for the current runtime that the warning has already been reported.

I'd expect to do the same in JRuby; it would be a one-time warning for 
sure. Basically advice on first use of critical= that "you shouldn't be 
doing that, but I'll let you".

- Charlie

From charles.nutter at sun.com  Wed Jan  7 08:12:12 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 07 Jan 2009 13:12:12 +0000
Subject: [Ironruby-core] Code Review: Thread#raise
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <4964AA2C.6080504@sun.com>

I think I'm coming around to your side. My position is current the 
following:

1. If critical officially remains specified as its current behavior in 
MRI, we should be warning people not to use it and should have a warning 
emitted at least once.
2. If we can get ruby-core to agree that critical should be expected to 
be no more than a global mutex and not necessarily deschedule threads, 
I'd be willing to make the same change in JRuby and omit the warning.

I definitely think we need to talk to ruby-core and open it up to the 
community, however, to see if there are cases where people depend on 
critical= actually descheduling. Shri: can you propose making the 
"global mutex" definition of critical the official one?

- Charlie

Shri Borde wrote:
> I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.
> 
> def get_unique_cookie()
>   begin
>     Thread.critical = true
>     cookie = @@counter
>     @@counter += 1
>   ensure
>     Thread.critical = false
>   end
>   cookie
> end
> 
> I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.
> 
> Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.
> 
> Thanks,
> Shri
> 
> 
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
> Sent: Tuesday, January 06, 2009 10:53 AM
> To: ironruby-core at rubyforge.org
> Cc: IronRuby External Code Reviewers; Tomas Matousek
> Subject: Re: [Ironruby-core] Code Review: Thread#raise
> 
> I think the implications of critical= in MRI are more complicated than 
> just a local lock. It actually stops normal thread scheduling, so other 
> threads freeze what they're doing. That's vastly more intrusive than 
> just a lock or critical section:
> 
> ? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3; 
> Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving 
> critical'; Thread.critical = false; sleep 3"
> Tue Jan 06 18:50:34 +0000 2009
> Tue Jan 06 18:50:35 +0000 2009
> critical
> leaving critical
> Tue Jan 06 18:50:39 +0000 2009
> Tue Jan 06 18:50:40 +0000 2009
> Tue Jan 06 18:50:41 +0000 2009
> 
> If those other threads are holding locks or resources, deadlock is 
> extremely easy, and of course it's nearly impossible to emulate right 
> with real parallel threads since you can't easily stop them whenever you 
> want.
> 
> #kill and #raise are also very tricky and dangerous, but they're at 
> least localized. They can be defined in terms of a message passed from 
> one thread to another plus a periodic message checkpoint.
> 
> I still believe critical= is much more in need of a warning.
> 
> Shri Borde wrote:
>> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>>
>> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>>
>> Thanks,
>> Shri
>>
>>
>> -----Original Message-----
>> From: Tomas Matousek
>> Sent: Saturday, January 03, 2009 11:52 AM
>> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: RE: Code Review: Thread#raise
>>
>> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>>
>> Tomas
>>
>> -----Original Message-----
>> From: Curt Hagenlocher
>> Sent: Tuesday, December 30, 2008 10:05 PM
>> To: Shri Borde; IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: RE: Code Review: Thread#raise
>>
>> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
>> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>>
>> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>>
>> -----Original Message-----
>> From: Shri Borde
>> Sent: Monday, December 29, 2008 3:00 PM
>> To: IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: Code Review: Thread#raise
>>
>>   tfpt review "/shelveset:raise;REDMOND\sborde"
>>   Comment  :
>>   Implements Thread#raise using Thread.Abort, and added tests for it
>>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>>   Enabled test for timeout as well
>>   Remaining work (not high pri for now)
>>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>>
>>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From Shri.Borde at microsoft.com  Wed Jan  7 13:07:08 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 10:07:08 -0800
Subject: [Ironruby-core] Behavior for Thread.critical=
In-Reply-To: <4964AA2C.6080504@sun.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4964AA2C.6080504@sun.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B86E@NA-EXMSG-C104.redmond.corp.microsoft.com>

I asked ruby-core whether descheduling other threads is by spec, but no one other than you replied. Any suggestions on how to nudge others to consider it? If you want to reply to that thread and provide JRuby's vote of confidence for the idea, that might help.

We should nail the complete behavior before taking it to ruby-core. I have written up a draft at http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx. Please take a look and comment on whether it works for JRuby. We can move it to some wiki if we need to iterate on it...

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Wednesday, January 07, 2009 5:12 AM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise

I think I'm coming around to your side. My position is current the
following:

1. If critical officially remains specified as its current behavior in
MRI, we should be warning people not to use it and should have a warning
emitted at least once.
2. If we can get ruby-core to agree that critical should be expected to
be no more than a global mutex and not necessarily deschedule threads,
I'd be willing to make the same change in JRuby and omit the warning.

I definitely think we need to talk to ruby-core and open it up to the
community, however, to see if there are cases where people depend on
critical= actually descheduling. Shri: can you propose making the
"global mutex" definition of critical the official one?

- Charlie

Shri Borde wrote:
> I agree that critical= can cause problems, and should go away. However, it can also be used in a reasonably safe way. Something like this. Such usages do not rely on other threads being frozen. Most uses seem to use such a pattern.
>
> def get_unique_cookie()
>   begin
>     Thread.critical = true
>     cookie = @@counter
>     @@counter += 1
>   ensure
>     Thread.critical = false
>   end
>   cookie
> end
>
> I am suggesting not adding a warning purely from a pragmatic perspective. The patter above is used in a lots of of places, and a warning could irritate users if they see it too often when using their favorite gems.
>
> Is there a way for Ruby devs to control the warning level? If so, it will be a question of what level to put the warning under, not whether to add it or not.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
> Sent: Tuesday, January 06, 2009 10:53 AM
> To: ironruby-core at rubyforge.org
> Cc: IronRuby External Code Reviewers; Tomas Matousek
> Subject: Re: [Ironruby-core] Code Review: Thread#raise
>
> I think the implications of critical= in MRI are more complicated than
> just a local lock. It actually stops normal thread scheduling, so other
> threads freeze what they're doing. That's vastly more intrusive than
> just a lock or critical section:
>
> ? ruby -e "Thread.new { sleep 1; puts Time.now; redo }; sleep 3;
> Thread.critical = true; puts 'critical'; sleep 3; puts 'leaving
> critical'; Thread.critical = false; sleep 3"
> Tue Jan 06 18:50:34 +0000 2009
> Tue Jan 06 18:50:35 +0000 2009
> critical
> leaving critical
> Tue Jan 06 18:50:39 +0000 2009
> Tue Jan 06 18:50:40 +0000 2009
> Tue Jan 06 18:50:41 +0000 2009
>
> If those other threads are holding locks or resources, deadlock is
> extremely easy, and of course it's nearly impossible to emulate right
> with real parallel threads since you can't easily stop them whenever you
> want.
>
> #kill and #raise are also very tricky and dangerous, but they're at
> least localized. They can be defined in terms of a message passed from
> one thread to another plus a periodic message checkpoint.
>
> I still believe critical= is much more in need of a warning.
>
> Shri Borde wrote:
>> Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and webbrick do use Thread#kill to kill a background thread.
>>
>> Thread.critical= can actually be used in a sane way for simple synchronization, like the lock keyword in C#. This is used much more widely, and a warning for this will cause lot of false alarms.
>>
>> Thanks,
>> Shri
>>
>>
>> -----Original Message-----
>> From: Tomas Matousek
>> Sent: Saturday, January 03, 2009 11:52 AM
>> To: Curt Hagenlocher; Shri Borde; IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: RE: Code Review: Thread#raise
>>
>> I think we should at least report a warning when Thread#kill, Thread#raise or Thread#critical= is called if not eliminating them as Charlie proposed on his blog.
>>
>> Tomas
>>
>> -----Original Message-----
>> From: Curt Hagenlocher
>> Sent: Tuesday, December 30, 2008 10:05 PM
>> To: Shri Borde; IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: RE: Code Review: Thread#raise
>>
>> Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
>> I think that Thread.raise with no arguments should just inject a RuntimeError with no message as if $! were nil; this makes more sense than failing.  Trying to reference a "current exception" in another thread is a scary operation even if that's what MRI is doing.
>>
>> Other than that, changes look really nice.  But anyone thinking of using this functionality should read Charlie's excellent piece from earlier in the year: http://blog.headius.com/2008/02/rubys-threadraise-threadkill-timeoutrb.html
>>
>> -----Original Message-----
>> From: Shri Borde
>> Sent: Monday, December 29, 2008 3:00 PM
>> To: IronRuby External Code Reviewers
>> Cc: ironruby-core at rubyforge.org
>> Subject: Code Review: Thread#raise
>>
>>   tfpt review "/shelveset:raise;REDMOND\sborde"
>>   Comment  :
>>   Implements Thread#raise using Thread.Abort, and added tests for it
>>   Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found more issues. Fixed most but not all
>>   Enabled test for timeout as well
>>   Remaining work (not high pri for now)
>>    - Thread#raise without Exception parameters is not supported as it needs to access the active exception of the target thread. This is stored as a thread-local static, and so cannot be accessed from other threads. Can be fixed by not using ThreadStaticAttribute.
>>    - Adding probes (in generated code, in C# library code, etc) will help to raise the exception quicker as Thread.Abort can be delayed indefinitely. Ideally, we need both approaches. For now, using Thread.Abort goes a long way.
>>    - Ideally, we would add a try-catch to the IDynamicObject/MetaObject code paths so that when other languages called into Ruby code, they would get the expected user exception rather than a ThreadAbortException
>>
>>   RunRSpec: supports -ruby to run with MRI. Its much faster than doing "rake ruby why_regression". Added support for -e to run a specific example
>>
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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

From jdeville at microsoft.com  Wed Jan  7 13:50:41 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 10:50:41 -0800
Subject: [Ironruby-core] Comments in the RubySpec tag files
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC37@NA-EXMSG-C112.redmond.corp.microsoft.com>

 That is correct. The next time I sync up, I will look into the tools for tags that Brian has in Rubyspec.

JD

From: Shri Borde
Sent: Tuesday, January 06, 2009 11:41 PM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: Comments in the RubySpec tag files

I added a few comments to critical_tags.txt like this:

fails("need to track which thread owns critical lock"):Thread.critical defers exit

This will help the next person who tries to fix the bug, and also as just documentation. However, I realized that Jim regenerates the tag files whenever he pulls down new RubySpec tests. So such comments will get lost. Jim, is that correct? If so, I will just not add such comments until we change the process so that the tags are not periodically regenerated from scratch.

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

From Shri.Borde at microsoft.com  Wed Jan  7 13:50:30 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 10:50:30 -0800
Subject: [Ironruby-core] Ruby version at ruby-doc.org
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B8E0@NA-EXMSG-C104.redmond.corp.microsoft.com>

What Ruby version does ruby-doc.org refer to? The main page has links to 1.8.6, 1.8.7, and 1.9. Following 1.8.6 for Thread takes me to
http://www.ruby-doc.org/core/classes/Thread.html which lists Thread.exclusive as an api. However, MRI 1.8.6 does not have such an api. There are no RubySpecs for it either.

Thanks,
Shri

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

From jdeville at microsoft.com  Wed Jan  7 13:57:02 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 10:57:02 -0800
Subject: [Ironruby-core] compliant_on(:ruby) in RubySpecs
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B69C@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69C@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC41@NA-EXMSG-C112.redmond.corp.microsoft.com>

I can check with Brian, but my understanding is as follows. The spec's are meant to be a complete packaged spec. Tag files are a convenience for using the spec's as a regression test. I feel, and I would guess this to be Brian's feelings, that when an implementation is complete (as in everything is implemented), there should not be a set of tag files for that implementation.

The other goal of the spec's is to be a spec. To that goal, you shouldn't have to go outside of the spec's to find out compliance information. Including the information into the file makes it easier to see what a specific implementation of Ruby supports. Keeping the code DRY in tests isn't as important as conveying information in those tests.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 12:26 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: compliant_on(:ruby) in RubySpecs

I noticed that besides not_compliant_on to disable tests on specific Ruby implementations, there is also compliant_on to enable tests only on selected implementations. There are ~120 such instances. To make IronRuby compliant, we not only have to reduce the number of *_tags.txt files, we also have to add ":ir" to all uses of compliant_on.

However, this seems backwards. Shouldn't we try to remove most uses of compliant_on, and instead add tags for the implementations where the test does not work? There may be a few valid uses of compliant_on for tests which only work on, say, JRuby. However, only a handful of the occurrences are of this kind. The vast majoriy include :ruby which means it should be the standard.

Should it be a goal to change compliant_on so that it does not allow :ruby?

Thanks,
Shri

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

From michael.letterle at gmail.com  Wed Jan  7 14:02:16 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Wed, 7 Jan 2009 14:02:16 -0500
Subject: [Ironruby-core] Comments in the RubySpec tag files
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <ef5222770901071102q758bc78ah74db3848999074a8@mail.gmail.com>

If you're adding value to the RubySpec tests, the rubyspec guys are pretty
good about giving commit access... spread the wealth!

On Wed, Jan 7, 2009 at 2:40 AM, Shri Borde <Shri.Borde at microsoft.com> wrote:

>  I added a few comments to critical_tags.txt like this:
>
>
>
> fails*("need to track which thread owns critical lock")*:Thread.critical
> defers exit
>
>
>
> This will help the next person who tries to fix the bug, and also as just
> documentation. However, I realized that Jim regenerates the tag files
> whenever he pulls down new RubySpec tests. So such comments will get lost.
> Jim, is that correct? If so, I will just not add such comments until we
> change the process so that the tags are not periodically regenerated from
> scratch.
>
>
>
> Shri
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090107/117af0c8/attachment.html>

From michael.letterle at gmail.com  Wed Jan  7 14:26:11 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Wed, 7 Jan 2009 14:26:11 -0500
Subject: [Ironruby-core] should equal in RubySpecs
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B69F@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69F@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <ef5222770901071126l55acea9al2486f5cf5e10385a@mail.gmail.com>

require 'mspec'
describe "equals" do
  it "compares objects not values" do

    a = "a"
    b = "a"
    c = a

    a.should equal(c)
    a.should_not equal(b)
    a.should == b

  end
end


On Wed, Jan 7, 2009 at 3:48 AM, Shri Borde <Shri.Borde at microsoft.com> wrote:

>  I noticed this in core\thread\current_spec.rb.
>
>
>
>   it "returns the current thread" do
>
>     t = Thread.new { Thread.current }
>
>     t.value.should equal(t)
>
>     Thread.current.should_not equal(t.value)
>
>   end
>
>
>
> Is this any different than writing "t.value.should == t"? Is either of them
> the recommended way? Seems odd to support two ways of writing the exact same
> thing.
>
>
>
> Thanks,
>
> Shri
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090107/a2d83321/attachment.html>

From jdeville at microsoft.com  Wed Jan  7 14:25:28 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 11:25:28 -0800
Subject: [Ironruby-core] Thread status tests
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B69E@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69E@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC7B@NA-EXMSG-C112.redmond.corp.microsoft.com>

I would rather implement them all separately. They all act differently. Status returns a simple string, inspect returns an inspection string, and alive and stop are Boolean. I would leave the shared pattern for the way it is now. You can probably take advantage of sharing methods in the fixtures.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 12:43 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: Thread status tests

There are four ways to check the status of threads, Thread#status, Thread#inspect, Thread#alive?, and Thread#stop?. Any objection to adding a single shared file which checks the result of all the four APIs? It won't follow the standard pattern of it_behaves_like for aliases since these are all different APIs and not aliases. However, it will help check all of them consistently. I wanted to check  if this idea made sense before pushing in that direction.

Thanks,
Shri

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

From jdeville at microsoft.com  Wed Jan  7 14:32:23 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 11:32:23 -0800
Subject: [Ironruby-core] should equal in RubySpecs
In-Reply-To: <ef5222770901071126l55acea9al2486f5cf5e10385a@mail.gmail.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<ef5222770901071126l55acea9al2486f5cf5e10385a@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC8B@NA-EXMSG-C112.redmond.corp.microsoft.com>

Along those lines, you have to remember that Ruby has 4 distinct ways to define equality. #eql?, #equal?, #== and #===.  This post covers it: http://probablycorey.wordpress.com/2008/02/26/ruby-equality-equal-eql-and/

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Wednesday, January 07, 2009 11:26 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] should equal in RubySpecs

require 'mspec'
describe "equals" do
  it "compares objects not values" do

    a = "a"
    b = "a"
    c = a

    a.should equal(c)
    a.should_not equal(b)
    a.should == b

  end
end

On Wed, Jan 7, 2009 at 3:48 AM, Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> wrote:

I noticed this in core\thread\current_spec.rb.



  it "returns the current thread" do

    t = Thread.new { Thread.current }

    t.value.should equal(t)

    Thread.current.should_not equal(t.value)

  end



Is this any different than writing "t.value.should == t"? Is either of them the recommended way? Seems odd to support two ways of writing the exact same thing.



Thanks,

Shri



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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From Shri.Borde at microsoft.com  Wed Jan  7 14:38:40 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 11:38:40 -0800
Subject: [Ironruby-core] compliant_on(:ruby) in RubySpecs
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC41@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69C@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC41@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B951@NA-EXMSG-C104.redmond.corp.microsoft.com>

I see the point of having all the information within the specs. It is useful to read a spec and to be able to know how other implementations behave (assuming the implementation is solid enough as to not cause a huge number of usages of not_compliant_on in the test code base).

However, I think compliant_on(:ruby, :ir) for example should be replaced with not_compliant_on(:jruby, :rubinius). That is, only opt-out should be supported, not opt-in. Otherwise, other implementations may not run the test even if they support that functionality.

From: Jim Deville
Sent: Wednesday, January 07, 2009 10:57 AM
To: Shri Borde
Cc: ironruby-core at rubyforge.org
Subject: RE: compliant_on(:ruby) in RubySpecs

I can check with Brian, but my understanding is as follows. The spec's are meant to be a complete packaged spec. Tag files are a convenience for using the spec's as a regression test. I feel, and I would guess this to be Brian's feelings, that when an implementation is complete (as in everything is implemented), there should not be a set of tag files for that implementation.

The other goal of the spec's is to be a spec. To that goal, you shouldn't have to go outside of the spec's to find out compliance information. Including the information into the file makes it easier to see what a specific implementation of Ruby supports. Keeping the code DRY in tests isn't as important as conveying information in those tests.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 12:26 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: compliant_on(:ruby) in RubySpecs

I noticed that besides not_compliant_on to disable tests on specific Ruby implementations, there is also compliant_on to enable tests only on selected implementations. There are ~120 such instances. To make IronRuby compliant, we not only have to reduce the number of *_tags.txt files, we also have to add ":ir" to all uses of compliant_on.

However, this seems backwards. Shouldn't we try to remove most uses of compliant_on, and instead add tags for the implementations where the test does not work? There may be a few valid uses of compliant_on for tests which only work on, say, JRuby. However, only a handful of the occurrences are of this kind. The vast majoriy include :ruby which means it should be the standard.

Should it be a goal to change compliant_on so that it does not allow :ruby?

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 14:39:52 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 11:39:52 -0800
Subject: [Ironruby-core] should equal in RubySpecs
In-Reply-To: <ef5222770901071126l55acea9al2486f5cf5e10385a@mail.gmail.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<ef5222770901071126l55acea9al2486f5cf5e10385a@mail.gmail.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B952@NA-EXMSG-C104.redmond.corp.microsoft.com>

I see. should== is value equality, and should+equal is reference equality.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Wednesday, January 07, 2009 11:26 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] should equal in RubySpecs

require 'mspec'
describe "equals" do
  it "compares objects not values" do

    a = "a"
    b = "a"
    c = a

    a.should equal(c)
    a.should_not equal(b)
    a.should == b

  end
end

On Wed, Jan 7, 2009 at 3:48 AM, Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> wrote:

I noticed this in core\thread\current_spec.rb.



  it "returns the current thread" do

    t = Thread.new { Thread.current }

    t.value.should equal(t)

    Thread.current.should_not equal(t.value)

  end



Is this any different than writing "t.value.should == t"? Is either of them the recommended way? Seems odd to support two ways of writing the exact same thing.



Thanks,

Shri



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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From Shri.Borde at microsoft.com  Wed Jan  7 14:40:54 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 11:40:54 -0800
Subject: [Ironruby-core] Thread status tests
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC7B@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69E@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC7B@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B956@NA-EXMSG-C104.redmond.corp.microsoft.com>

Yeah, I can probably unify the fixtures but leave the expectations in the individual spec files.

From: Jim Deville
Sent: Wednesday, January 07, 2009 11:25 AM
To: Shri Borde
Cc: ironruby-core at rubyforge.org
Subject: RE: Thread status tests

I would rather implement them all separately. They all act differently. Status returns a simple string, inspect returns an inspection string, and alive and stop are Boolean. I would leave the shared pattern for the way it is now. You can probably take advantage of sharing methods in the fixtures.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 12:43 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: Thread status tests

There are four ways to check the status of threads, Thread#status, Thread#inspect, Thread#alive?, and Thread#stop?. Any objection to adding a single shared file which checks the result of all the four APIs? It won't follow the standard pattern of it_behaves_like for aliases since these are all different APIs and not aliases. However, it will help check all of them consistently. I wanted to check  if this idea made sense before pushing in that direction.

Thanks,
Shri

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

From jdeville at microsoft.com  Wed Jan  7 14:51:37 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 11:51:37 -0800
Subject: [Ironruby-core] Ruby version at ruby-doc.org
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B8E0@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B8E0@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FCB2@NA-EXMSG-C112.redmond.corp.microsoft.com>

I have no clue where that comes from. You should probably email James Britt at Ruby-doc and ask what is up with that.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 10:51 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: Ruby version at ruby-doc.org

What Ruby version does ruby-doc.org refer to? The main page has links to 1.8.6, 1.8.7, and 1.9. Following 1.8.6 for Thread takes me to
http://www.ruby-doc.org/core/classes/Thread.html which lists Thread.exclusive as an api. However, MRI 1.8.6 does not have such an api. There are no RubySpecs for it either.

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 15:13:40 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 12:13:40 -0800
Subject: [Ironruby-core] Comments in the RubySpec tag files
In-Reply-To: <ef5222770901071102q758bc78ah74db3848999074a8@mail.gmail.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B679@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<ef5222770901071102q758bc78ah74db3848999074a8@mail.gmail.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049B9B1@NA-EXMSG-C104.redmond.corp.microsoft.com>

Jim has commit access and does provide patches to improve the framework. This thread is about the ironruby tags though, and it would not help anyone other than IronRuby.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Wednesday, January 07, 2009 11:02 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Comments in the RubySpec tag files

If you're adding value to the RubySpec tests, the rubyspec guys are pretty good about giving commit access... spread the wealth!
On Wed, Jan 7, 2009 at 2:40 AM, Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> wrote:

I added a few comments to critical_tags.txt like this:



fails("need to track which thread owns critical lock"):Thread.critical defers exit



This will help the next person who tries to fix the bug, and also as just documentation. However, I realized that Jim regenerates the tag files whenever he pulls down new RubySpec tests. So such comments will get lost. Jim, is that correct? If so, I will just not add such comments until we change the process so that the tags are not periodically regenerated from scratch.



Shri

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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From jdeville at microsoft.com  Wed Jan  7 15:17:00 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 12:17:00 -0800
Subject: [Ironruby-core] compliant_on(:ruby) in RubySpecs
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B951@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69C@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB575FC41@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049B951@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FCE5@NA-EXMSG-C112.redmond.corp.microsoft.com>

http://rubyspec.org/wiki/rubyspec/Guards

If you scroll to the compliant portion of the page, you'll see that they actually have different meanings, and they are based on the reference implementation (CRuby). I had forgotten this until just now.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 11:39 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: RE: compliant_on(:ruby) in RubySpecs

I see the point of having all the information within the specs. It is useful to read a spec and to be able to know how other implementations behave (assuming the implementation is solid enough as to not cause a huge number of usages of not_compliant_on in the test code base).

However, I think compliant_on(:ruby, :ir) for example should be replaced with not_compliant_on(:jruby, :rubinius). That is, only opt-out should be supported, not opt-in. Otherwise, other implementations may not run the test even if they support that functionality.

From: Jim Deville
Sent: Wednesday, January 07, 2009 10:57 AM
To: Shri Borde
Cc: ironruby-core at rubyforge.org
Subject: RE: compliant_on(:ruby) in RubySpecs

I can check with Brian, but my understanding is as follows. The spec's are meant to be a complete packaged spec. Tag files are a convenience for using the spec's as a regression test. I feel, and I would guess this to be Brian's feelings, that when an implementation is complete (as in everything is implemented), there should not be a set of tag files for that implementation.

The other goal of the spec's is to be a spec. To that goal, you shouldn't have to go outside of the spec's to find out compliance information. Including the information into the file makes it easier to see what a specific implementation of Ruby supports. Keeping the code DRY in tests isn't as important as conveying information in those tests.

JD

From: Shri Borde
Sent: Wednesday, January 07, 2009 12:26 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: compliant_on(:ruby) in RubySpecs

I noticed that besides not_compliant_on to disable tests on specific Ruby implementations, there is also compliant_on to enable tests only on selected implementations. There are ~120 such instances. To make IronRuby compliant, we not only have to reduce the number of *_tags.txt files, we also have to add ":ir" to all uses of compliant_on.

However, this seems backwards. Shouldn't we try to remove most uses of compliant_on, and instead add tags for the implementations where the test does not work? There may be a few valid uses of compliant_on for tests which only work on, say, JRuby. However, only a handful of the occurrences are of this kind. The vast majoriy include :ruby which means it should be the standard.

Should it be a goal to change compliant_on so that it does not allow :ruby?

Thanks,
Shri

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

From jdeville at microsoft.com  Wed Jan  7 15:07:32 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Wed, 7 Jan 2009 12:07:32 -0800
Subject: [Ironruby-core] ScratchPad versus Channel in RubySpec
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B69D@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B69D@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FCD4@NA-EXMSG-C112.redmond.corp.microsoft.com>

K, ScratchPad clear: MSpec doesn't provide any contracts. It is up to the user to clear his own state. This also allows for a test to use ScratchPad across multiple examples. ScratchPad is only meant to be a formalized global variable.

Channel is actually a part of Rubinius's standard library (IIRC). Ideally, the tests don't rely on anything more than basic language features, so we should try to keep usage of Standard Library to a minimum. I only use stdlib's that are required for MSpec's runner, such as FileUtils.

JD
From: Shri Borde
Sent: Wednesday, January 07, 2009 12:32 AM
To: Jim Deville
Cc: ironruby-core at rubyforge.org
Subject: ScratchPad versus Channel in RubySpec

Many tests use Channel to collect data that needs to be tested. For example, the following in inspect_spec.rb.

  compliant_on(:ruby) do
    it "reports aborting on a killed thread" do
      c = Channel.new
      t = Thread.new { c << Thread.current.inspect; Thread.stop }
      c.receive.should include('run')
      t.inspect.should include('sleep')
      Thread.critical = true
      t.kill
      t.inspect.should include('aborting')
      Thread.critical = false
    end
  end

However, there is also ScratchPad which serves the same purpose. Why are there two ways of doing this, and which is the preferred one?

Also, (as we were discussing before), why does every test have to call ScratchPad.clear before using it. Shouldn't MSpec be doing this automatically?

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Wed Jan  7 17:17:39 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 7 Jan 2009 14:17:39 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>

Since no one has reviewed this yet, I have updated the change to factor out the tests for alive?, inspect, status and stop?

Another product change was that Thread#value should return false if the thread was killed. Only a thread with an uncaught exception should return nil.

Thanks,
Shri

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:49 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: hangs in core\thread

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  : 
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: hangs.diff
Type: application/octet-stream
Size: 26816 bytes
Desc: hangs.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090107/19b136cd/attachment-0001.obj>

From Tomas.Matousek at microsoft.com  Wed Jan  7 17:36:37 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 7 Jan 2009 14:36:37 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8050@NA-EXMSG-C112.redmond.corp.microsoft.com>

I would prefer using a field rather than a private auto-property for IsSleeping.
Other than that, changes in ThreadOps look good.

Tomas

-----Original Message-----
From: Shri Borde 
Sent: Wednesday, January 07, 2009 2:18 PM
To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Since no one has reviewed this yet, I have updated the change to factor out the tests for alive?, inspect, status and stop?

Another product change was that Thread#value should return false if the thread was killed. Only a thread with an uncaught exception should return nil.

Thanks,
Shri

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:49 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: hangs in core\thread

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  : 
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.



From lists at ruby-forum.com  Wed Jan  7 19:36:33 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 01:36:33 +0100
Subject: [Ironruby-core] Enumerate CLR methods
Message-ID: <cb4f86fecb98d70ff48668431af30908@ruby-forum.com>

Hello,

How to enumerate the CLR object methods?

I whould like to write some thing like this:

  - - -
  require 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
  include System::Windows::Forms
  p Form.new.methods.sort
  - - -

and to see methods like: show, show_dialog, ...

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

From lists at ruby-forum.com  Wed Jan  7 20:24:56 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 02:24:56 +0100
Subject: [Ironruby-core] Problem calling CLR method
Message-ID: <86d86496d276a69dcbee2e8948b48e32@ruby-forum.com>

Hello,

I can't call the object's method, thought it exists.

My ruby script:

- - - - -
# Let's dump .Net methods
far.get_type.get_methods.each { |m| p m.name }

# Try to call 'RegisterTool' method
begin
  far.register_tool
rescue => err
  p err
end

begin
  far.RegisterTool
rescue => err
  p err
end
- - - - -

I get such output:

- - - - -
 ...
"RegisterFiler"
"RegisterTool"
 ...

#<NoMethodError: undefined method `register_tool' for
#<FarNet::Far:0x000005c>>
#<NoMethodError: undefined method `RegisterTool' for
#<FarNet::Far:0x000005c>>
- - - - -

Not sure if this matters, but 'far' variable is set by the script host
  scope.SetVariable("far", Far);

Thanks,
  - Alex
-- 
Posted via http://www.ruby-forum.com/.

From ivan at flanders.co.nz  Thu Jan  8 02:34:38 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 8 Jan 2009 08:34:38 +0100
Subject: [Ironruby-core] Enumerate CLR methods
In-Reply-To: <cb4f86fecb98d70ff48668431af30908@ruby-forum.com>
References: <cb4f86fecb98d70ff48668431af30908@ruby-forum.com>
Message-ID: <b1c6aabb0901072334t7b3888fau7ee7669c8c403f91@mail.gmail.com>

instance.class.to_clr_type.get_methods.collect { |m| m.name.to_s
}.uniq.sort.each { |m| p m }

or Form.to_clr_type.get_methods.collect { |m| m.name.to_s }.uniq.sort.each {
|m| p m }


On Thu, Jan 8, 2009 at 1:36 AM, Alex 2k8 <lists at ruby-forum.com> wrote:

> Hello,
>
> How to enumerate the CLR object methods?
>
> I whould like to write some thing like this:
>
>  - - -
>  require 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089'
>  include System::Windows::Forms
>  p Form.new.methods.sort
>  - - -
>
> and to see methods like: show, show_dialog, ...
>
> - Alex
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> 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/20090108/a6ea82b9/attachment.html>

From lists at ruby-forum.com  Thu Jan  8 05:25:18 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 11:25:18 +0100
Subject: [Ironruby-core] Problem calling explicit interface methods
Message-ID: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>

Hello,

I am trying to call explicitly implemented interface method, but get
such error
  undefined method `bar' for #<App::Cls:0x000005c>

C# code:

    public interface IFoo
    {
        void Bar();
    }

    public class Cls : IFoo
    {
        void IFoo.Bar() { }
    }

Ruby code:
    x = App::Cls.new
    x.bar


But this one works fine:

    public class Cls : IFoo
    {
        public void Bar() { }
    }

What is wrong?

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

From Tomas.Matousek at microsoft.com  Thu Jan  8 10:52:51 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 07:52:51 -0800
Subject: [Ironruby-core] Enumerate CLR methods
In-Reply-To: <b1c6aabb0901072334t7b3888fau7ee7669c8c403f91@mail.gmail.com>
References: <cb4f86fecb98d70ff48668431af30908@ruby-forum.com>
	<b1c6aabb0901072334t7b3888fau7ee7669c8c403f91@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8243@NA-EXMSG-C112.redmond.corp.microsoft.com>

Module#methods doesn?t return .NET members right now. It should. Filed a bug #23493.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Wednesday, January 07, 2009 11:35 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Enumerate CLR methods

instance.class.to_clr_type.get_methods.collect { |m| m.name.to_s }.uniq.sort.each { |m| p m }

or Form.to_clr_type.get_methods.collect { |m| m.name.to_s }.uniq.sort.each { |m| p m }
On Thu, Jan 8, 2009 at 1:36 AM, Alex 2k8 <lists at ruby-forum.com<mailto:lists at ruby-forum.com>> wrote:
Hello,

How to enumerate the CLR object methods?

I whould like to write some thing like this:

 - - -
 require 'System.Windows.Forms, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'
 include System::Windows::Forms
 p Form.new.methods.sort
 - - -

and to see methods like: show, show_dialog, ...

- Alex
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
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/20090108/9a680510/attachment.html>

From Tomas.Matousek at microsoft.com  Thu Jan  8 10:54:12 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 07:54:12 -0800
Subject: [Ironruby-core] Problem calling CLR method
In-Reply-To: <86d86496d276a69dcbee2e8948b48e32@ruby-forum.com>
References: <86d86496d276a69dcbee2e8948b48e32@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8246@NA-EXMSG-C112.redmond.corp.microsoft.com>

Could you sent source code for FarNet class (RegisterTool method declaration)?

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Wednesday, January 07, 2009 5:25 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problem calling CLR method

Hello,

I can't call the object's method, thought it exists.

My ruby script:

- - - - -
# Let's dump .Net methods
far.get_type.get_methods.each { |m| p m.name }

# Try to call 'RegisterTool' method
begin
  far.register_tool
rescue => err
  p err
end

begin
  far.RegisterTool
rescue => err
  p err
end
- - - - -

I get such output:

- - - - -
 ...
"RegisterFiler"
"RegisterTool"
 ...

#<NoMethodError: undefined method `register_tool' for
#<FarNet::Far:0x000005c>>
#<NoMethodError: undefined method `RegisterTool' for
#<FarNet::Far:0x000005c>>
- - - - -

Not sure if this matters, but 'far' variable is set by the script host
  scope.SetVariable("far", Far);

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


From Tomas.Matousek at microsoft.com  Thu Jan  8 10:56:13 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 07:56:13 -0800
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>

Filed bug #23494.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 2:25 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problem calling explicit interface methods

Hello,

I am trying to call explicitly implemented interface method, but get
such error
  undefined method `bar' for #<App::Cls:0x000005c>

C# code:

    public interface IFoo
    {
        void Bar();
    }

    public class Cls : IFoo
    {
        void IFoo.Bar() { }
    }

Ruby code:
    x = App::Cls.new
    x.bar


But this one works fine:

    public class Cls : IFoo
    {
        public void Bar() { }
    }

What is wrong?

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


From curth at microsoft.com  Thu Jan  8 11:04:47 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Thu, 8 Jan 2009 08:04:47 -0800
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>

I'm not convinced this is exactly a bug.  There is no public 'bar' method on Cls after all.  I think IronPython would require you to say something like App::IFoo::bar(App::Cls.new()) in order to make the interface call explicit.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Thursday, January 08, 2009 7:56 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

Filed bug #23494.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 2:25 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problem calling explicit interface methods

Hello,

I am trying to call explicitly implemented interface method, but get
such error
  undefined method `bar' for #<App::Cls:0x000005c>

C# code:

    public interface IFoo
    {
        void Bar();
    }

    public class Cls : IFoo
    {
        void IFoo.Bar() { }
    }

Ruby code:
    x = App::Cls.new
    x.bar


But this one works fine:

    public class Cls : IFoo
    {
        public void Bar() { }
    }

What is wrong?

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

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


From lists at ruby-forum.com  Thu Jan  8 11:49:41 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 17:49:41 +0100
Subject: [Ironruby-core] Problem calling CLR method
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8246@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <86d86496d276a69dcbee2e8948b48e32@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8246@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <f361d10b795939ddf44b52992d82ef4b@ruby-forum.com>

> Could you sent source code for FarNet class (RegisterTool method 
> declaration)?

http://code.google.com/p/farnet/source/browse/trunk/FarNet/FarNetIntf/Far.cs
http://code.google.com/p/farnet/source/browse/trunk/FarNet/FarNetPlugin/Far.h
http://code.google.com/p/farnet/source/browse/trunk/FarNet/FarNetPlugin/Far.cpp

Probably this is some how related to 
http://www.ruby-forum.com/topic/175168 ?
-- 
Posted via http://www.ruby-forum.com/.

From Tomas.Matousek at microsoft.com  Thu Jan  8 11:50:29 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 08:50:29 -0800
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8274@NA-EXMSG-C112.redmond.corp.microsoft.com>

Fair enough, it could be called a feature :) There needs to be some way how to call the method.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
Sent: Thursday, January 08, 2009 8:05 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

I'm not convinced this is exactly a bug.  There is no public 'bar' method on Cls after all.  I think IronPython would require you to say something like App::IFoo::bar(App::Cls.new()) in order to make the interface call explicit.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Thursday, January 08, 2009 7:56 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

Filed bug #23494.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 2:25 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problem calling explicit interface methods

Hello,

I am trying to call explicitly implemented interface method, but get
such error
  undefined method `bar' for #<App::Cls:0x000005c>

C# code:

    public interface IFoo
    {
        void Bar();
    }

    public class Cls : IFoo
    {
        void IFoo.Bar() { }
    }

Ruby code:
    x = App::Cls.new
    x.bar


But this one works fine:

    public class Cls : IFoo
    {
        public void Bar() { }
    }

What is wrong?

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

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

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


From lists at ruby-forum.com  Thu Jan  8 11:53:31 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 17:53:31 +0100
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <a09189dd3f6d03be40bfbd39b7c459c4@ruby-forum.com>

Curious, how it is expected to work (or nobody thinked it over yet?)

Example to consider:

    - - - -
    public interface IFoo1
    {
        void Bar();
    }

    public interface IFoo2
    {
        void Bar();
    }

    public class Cls : IFoo1, IFoo2
    {
        void IFoo1.Bar() {}
        void IFoo2.Bar() {}
        public void Bar() {}
    }
    - - - -

C# approach:
    - - - -
    Cls obj = new Cls();
    obj.Bar();
    ((IFoo1)obj).Bar();
    ((IFoo2)obj).Bar();
    - - - -

What is for IronRuby?

Thanks,
 - Alex
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Thu Jan  8 12:06:39 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Thu, 8 Jan 2009 18:06:39 +0100
Subject: [Ironruby-core] Problem calling CLR method
In-Reply-To: <f361d10b795939ddf44b52992d82ef4b@ruby-forum.com>
References: <86d86496d276a69dcbee2e8948b48e32@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8246@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<f361d10b795939ddf44b52992d82ef4b@ruby-forum.com>
Message-ID: <4fd0d92be0537b20f2f9582665fec16b@ruby-forum.com>

Btw, IronPython can call same method:

http://farnet.googlecode.com/files/IronPythonFar.1.0.35.rar
 IronPythonFar\Scripts\calc.py

- - -
far.RegisterTool(ipy, "IronPython calculator", calc, 
FarManager.ToolOptions.F11Menus)
- - -
-- 
Posted via http://www.ruby-forum.com/.

From Tomas.Matousek at microsoft.com  Thu Jan  8 12:48:29 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 09:48:29 -0800
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <a09189dd3f6d03be40bfbd39b7c459c4@ruby-forum.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<a09189dd3f6d03be40bfbd39b7c459c4@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C82B6@NA-EXMSG-C112.redmond.corp.microsoft.com>

Not yet.

obj.as(IFoo1).Bar() might be one option.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 8:54 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

Curious, how it is expected to work (or nobody thinked it over yet?)

Example to consider:

    - - - -
    public interface IFoo1
    {
        void Bar();
    }

    public interface IFoo2
    {
        void Bar();
    }

    public class Cls : IFoo1, IFoo2
    {
        void IFoo1.Bar() {}
        void IFoo2.Bar() {}
        public void Bar() {}
    }
    - - - -

C# approach:
    - - - -
    Cls obj = new Cls();
    obj.Bar();
    ((IFoo1)obj).Bar();
    ((IFoo2)obj).Bar();
    - - - -

What is for IronRuby?

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


From Shri.Borde at microsoft.com  Thu Jan  8 12:57:31 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 8 Jan 2009 09:57:31 -0800
Subject: [Ironruby-core] Problem calling explicit interface methods
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8274@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <3f00a466c32ac552d747a51bf95fea0a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8248@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1D452@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8274@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049BED0@NA-EXMSG-C104.redmond.corp.microsoft.com>

In IronPython, we went back and forth over this. On the one hand, the API author might have chosen to make it harder to access the method, requiring a cast like this:
  App::Cls cls = new App::Cls();
  cls.bar(); // syntax error
  IFoo ifoo = (IFoo)cls;
  ifoo.bar(); // works
OTOH, dynamic languages have no type for variables, and so you don't know if it should be an error or not. ie. How would IronRuby know if the programmer expects a variable to be of type App::Cls or of type IFoo.

IronPython ended up allowing it as long as there was no clash. If there is a clash, you have to use App::IFoo(cls).bar().

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Thursday, January 08, 2009 8:50 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

Fair enough, it could be called a feature :) There needs to be some way how to call the method.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
Sent: Thursday, January 08, 2009 8:05 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

I'm not convinced this is exactly a bug.  There is no public 'bar' method on Cls after all.  I think IronPython would require you to say something like App::IFoo::bar(App::Cls.new()) in order to make the interface call explicit.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Thursday, January 08, 2009 7:56 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Problem calling explicit interface methods

Filed bug #23494.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 2:25 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Problem calling explicit interface methods

Hello,

I am trying to call explicitly implemented interface method, but get
such error
  undefined method `bar' for #<App::Cls:0x000005c>

C# code:

    public interface IFoo
    {
        void Bar();
    }

    public class Cls : IFoo
    {
        void IFoo.Bar() { }
    }

Ruby code:
    x = App::Cls.new
    x.bar


But this one works fine:

    public class Cls : IFoo
    {
        public void Bar() { }
    }

What is wrong?

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

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

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

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


From jdeville at microsoft.com  Thu Jan  8 12:58:01 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 09:58:01 -0800
Subject: [Ironruby-core] Spec Coverage
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FFC1@NA-EXMSG-C112.redmond.corp.microsoft.com>

Just to let people know where we are:

ruby core
1118 files, 4850 examples, 18036 expectations, 82 failures, 219 errors
1118 files, 4731 examples, 15341 expectations, 520 failures, 724 errors

14097/18063 = 78.0


ruby lang
47 files, 652 examples, 1725 expectations, 2 failures, 0 errors
ir
47 files, 644 examples, 1643 expectations, 14 failures, 1 error

1628/1725 = 94.4

ruby lib
1323 files, 3524 examples, 10663 expectations, 34 failures, 73 errors
1323 files, 3507 examples, 11129 expectations, 362 failures, 491 errors

10276/10663 = 96.4

Libs is probably wrong. There is no valid reason for IronRuby to have more expectations than Ruby. I'll track that down and report again when I find the issue.

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

From Shri.Borde at microsoft.com  Thu Jan  8 13:11:33 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 8 Jan 2009 10:11:33 -0800
Subject: [Ironruby-core] Resolving a bug on RubyForge
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049BEF8@NA-EXMSG-C104.redmond.corp.microsoft.com>

What is the process for resolving a fixed bug? If I mark it as closed, Jim, will you get a chance to verify that it is actually fixed and to ensure that there is sufficient test coverage for the immediate issue as well as the larger general area?

Thanks,
Shri

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

From jdeville at microsoft.com  Thu Jan  8 13:18:11 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 10:18:11 -0800
Subject: [Ironruby-core] Resolving a bug on RubyForge
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049BEF8@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049BEF8@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB575FFDD@NA-EXMSG-C112.redmond.corp.microsoft.com>

Don't close it. Just assign it to me, I'll verify and close it. It would be nice to have a "Resolved" status, but I can't see a way to do it.

JD



From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:12 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Resolving a bug on RubyForge

What is the process for resolving a fixed bug? If I mark it as closed, Jim, will you get a chance to verify that it is actually fixed and to ensure that there is sufficient test coverage for the immediate issue as well as the larger general area?

Thanks,
Shri

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

From Tomas.Matousek at microsoft.com  Thu Jan  8 13:22:32 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 10:22:32 -0800
Subject: [Ironruby-core] Resolving a bug on RubyForge
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049BEF8@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049BEF8@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C82EA@NA-EXMSG-C112.redmond.corp.microsoft.com>

Just assign it to Jim. He'll mark it closed.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:12 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Resolving a bug on RubyForge

What is the process for resolving a fixed bug? If I mark it as closed, Jim, will you get a chance to verify that it is actually fixed and to ensure that there is sufficient test coverage for the immediate issue as well as the larger general area?

Thanks,
Shri

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

From lists at ruby-forum.com  Thu Jan  8 13:46:26 2009
From: lists at ruby-forum.com (Sam Malone)
Date: Thu, 8 Jan 2009 19:46:26 +0100
Subject: [Ironruby-core] require my assembly
Message-ID: <e4abb6763211274f991eab2f631d0a90@ruby-forum.com>

Hi,

  I'm new to IronRuby. I'm trying to require a .net assembly but I have
the following error message. Any help will be very much appreciated.

Note :
------

MyApp.Application.dll references MyApp.Core.dll and both are in the same
folder C:\MyApp\Trunk\Bin\

Code :
------

require 'C:\MyApp\Trunk\Bin\MyApp.Application.dll'
include MyApp::Application

def main
  print ZlibCompression.Decompress(ZlibCompression.Compress("toto"))
end

if __FILE__ == $0
  main()
end

Error message:
--------------

Unhandled exception:
mscorlib:0:in `ResolveType': Could not load file or assembly
'MyApp.Core, Version=1.0.278.0, Culture=neutral, Public
KeyToken=null' or one of its dependencies. The system cannot find the
file specified. (System::IO::FileNotFoundException
)
        from mscorlib:0:in `ResolveTypeHandle'
-- 
Posted via http://www.ruby-forum.com/.

From michael.letterle at gmail.com  Thu Jan  8 13:51:54 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Thu, 8 Jan 2009 13:51:54 -0500
Subject: [Ironruby-core] require my assembly
In-Reply-To: <e4abb6763211274f991eab2f631d0a90@ruby-forum.com>
References: <e4abb6763211274f991eab2f631d0a90@ruby-forum.com>
Message-ID: <ef5222770901081051u431b7574wf40785315d6cca6a@mail.gmail.com>

currently, you have to copy MyApp.Core.dll to the location where ir.exe is
located.

On Thu, Jan 8, 2009 at 1:46 PM, Sam Malone <lists at ruby-forum.com> wrote:

> Hi,
>
>  I'm new to IronRuby. I'm trying to require a .net assembly but I have
> the following error message. Any help will be very much appreciated.
>
> Note :
> ------
>
> MyApp.Application.dll references MyApp.Core.dll and both are in the same
> folder C:\MyApp\Trunk\Bin\
>
> Code :
> ------
>
> require 'C:\MyApp\Trunk\Bin\MyApp.Application.dll'
> include MyApp::Application
>
> def main
>  print ZlibCompression.Decompress(ZlibCompression.Compress("toto"))
> end
>
> if __FILE__ == $0
>  main()
> end
>
> Error message:
> --------------
>
> Unhandled exception:
> mscorlib:0:in `ResolveType': Could not load file or assembly
> 'MyApp.Core, Version=1.0.278.0, Culture=neutral, Public
> KeyToken=null' or one of its dependencies. The system cannot find the
> file specified. (System::IO::FileNotFoundException
> )
>        from mscorlib:0:in `ResolveTypeHandle'
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090108/c7bde04d/attachment.html>

From ivan at flanders.co.nz  Thu Jan  8 14:06:35 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 8 Jan 2009 20:06:35 +0100
Subject: [Ironruby-core] require my assembly
In-Reply-To: <ef5222770901081051u431b7574wf40785315d6cca6a@mail.gmail.com>
References: <e4abb6763211274f991eab2f631d0a90@ruby-forum.com>
	<ef5222770901081051u431b7574wf40785315d6cca6a@mail.gmail.com>
Message-ID: <b1c6aabb0901081106y77e95c86ub612fc6ca7050b03@mail.gmail.com>

For me it works with a path too

http://code.google.com/p/ironruby-dbi/source/browse/trunk/src/ironruby-dbi/dbd-adonet/ADONET.rb

But I do use forward slashes

It does have some weirdness though, because sometimes I have to actually
copy the assembly to the directory where ir.exe lives. I'm not sure as to
when exactly that needs to happen.


On Thu, Jan 8, 2009 at 7:51 PM, Michael Letterle <michael.letterle at gmail.com
> wrote:

> currently, you have to copy MyApp.Core.dll to the location where ir.exe is
> located.
>
>
> On Thu, Jan 8, 2009 at 1:46 PM, Sam Malone <lists at ruby-forum.com> wrote:
>
>> Hi,
>>
>>  I'm new to IronRuby. I'm trying to require a .net assembly but I have
>> the following error message. Any help will be very much appreciated.
>>
>> Note :
>> ------
>>
>> MyApp.Application.dll references MyApp.Core.dll and both are in the same
>> folder C:\MyApp\Trunk\Bin\
>>
>> Code :
>> ------
>>
>> require 'C:\MyApp\Trunk\Bin\MyApp.Application.dll'
>> include MyApp::Application
>>
>> def main
>>  print ZlibCompression.Decompress(ZlibCompression.Compress("toto"))
>> end
>>
>> if __FILE__ == $0
>>  main()
>> end
>>
>> Error message:
>> --------------
>>
>> Unhandled exception:
>> mscorlib:0:in `ResolveType': Could not load file or assembly
>> 'MyApp.Core, Version=1.0.278.0, Culture=neutral, Public
>> KeyToken=null' or one of its dependencies. The system cannot find the
>> file specified. (System::IO::FileNotFoundException
>> )
>>        from mscorlib:0:in `ResolveTypeHandle'
>> --
>> Posted via http://www.ruby-forum.com/.
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>
>
>
> --
> Michael Letterle
> [Polymath Prokrammer]
> http://blog.prokrams.com
>
>
>
> _______________________________________________
> 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/20090108/5825671c/attachment-0001.html>

From jdeville at microsoft.com  Thu Jan  8 14:12:45 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 11:12:45 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8050@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8050@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760049@NA-EXMSG-C112.redmond.corp.microsoft.com>

Test Review:
classes.rb:
* can you change the get_status_... methods to status_... methods? The extra get isn't really used in Ruby.
* Did you want to have possibly stale information in the Status class?
* for running thread, why not just do:
def status_of_running_thread
  t = Thread.new {loop {}}
  Thread.pass until t.status == "run"
  status = Status.new t
  t.kill
  status
end
* critical_should_be_false should use ScratchPad instead of should's in the method. I would suggest trying to always keep shoulds in the spec itself.
* Can you modify method names and variables to be snake_case instead of CamelCase?

Alive_spec.rb:
* (new thing I'm going to start doing with new guards) What's the justification for the compliant_on(:ruby) guard. Why isn't it a tag?


Critical_spec.rb:
* add a before(:each) block and move the ScratchPad.clear to there, then you can add ScratchPad without thinking about it.
* Extra comment (#end) on line 49

Exit.rb:
* lines 11 and 23: I don't see a reason for checking the value of the threads. You are already checking the ScratchPad, so you know the execution ran.

Raise_spec.rb:
* You might need to remove the " raises an exception on running thread" tag. I think I added one when doing dates.

Wakeup.rb:
* Line 38 has an unused Channel
* 1000 times for the deadlock test might be too long for a test. In principle it's nice for the stress portion, but it seems too long. I'd also like to find another way than 1.should == 1, but you can check that in and I'll find a way.


JD
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 07, 2009 2:37 PM
To: Shri Borde; ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: Re: [Ironruby-core] Code Review: hangs in core\thread

I would prefer using a field rather than a private auto-property for IsSleeping.
Other than that, changes in ThreadOps look good.

Tomas

-----Original Message-----
From: Shri Borde
Sent: Wednesday, January 07, 2009 2:18 PM
To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Since no one has reviewed this yet, I have updated the change to factor out the tests for alive?, inspect, status and stop?

Another product change was that Thread#value should return false if the thread was killed. Only a thread with an uncaught exception should return nil.

Thanks,
Shri

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:49 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: hangs in core\thread

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  :
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.


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


From Shri.Borde at microsoft.com  Thu Jan  8 14:38:59 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 8 Jan 2009 11:38:59 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760049@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8050@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB5760049@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD049BFF0@NA-EXMSG-C104.redmond.corp.microsoft.com>

Inline..

Everything has been addressesd except I am not sure what you meant by " Did you want to have possibly stale information in the Status class? ". The shelveset has been updated.

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Thursday, January 08, 2009 11:13 AM
To: ironruby-core at rubyforge.org; Shri Borde; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Test Review:
classes.rb:
* can you change the get_status_... methods to status_... methods? The extra get isn't really used in Ruby.
[Shri Borde] Done


* Did you want to have possibly stale information in the Status class?
[Shri Borde] What do you mean by this? It should capture the state of the thread whenever Status.new was called.

* for running thread, why not just do:
def status_of_running_thread
  t = Thread.new {loop {}}
  Thread.pass until t.status == "run"
  status = Status.new t
  t.kill
  status
end
[Shri Borde] Done


* critical_should_be_false should use ScratchPad instead of should's in the method. I would suggest trying to always keep shoulds in the spec itself.
[Shri Borde] Done

* Can you modify method names and variables to be snake_case instead of CamelCase?
[Shri Borde] Done

Alive_spec.rb:
* (new thing I'm going to start doing with new guards) What's the justification for the compliant_on(:ruby) guard. Why isn't it a tag?
[Shri Borde] I copied it from inspect_spec.rb. Until we understand how all the guards are supposed to work (you are following up about that), I don't know how to clean this up. So I keeping the status quo.

Critical_spec.rb:
* add a before(:each) block and move the ScratchPad.clear to there, then you can add ScratchPad without thinking about it.
[Shri Borde] Done. I think MSpec should be doing this, but oh well.

* Extra comment (#end) on line 49
[Shri Borde] Removed

Exit.rb:
* lines 11 and 23: I don't see a reason for checking the value of the threads. You are already checking the ScratchPad, so you know the execution ran.
[Shri Borde] Removed it. I had already added a separate test for Thread#value. No point having the same test in two places.

Raise_spec.rb:
* You might need to remove the " raises an exception on running thread" tag. I think I added one when doing dates.
[Shri Borde] Done

Wakeup.rb:
* Line 38 has an unused Channel
[Shri Borde] Removed

* 1000 times for the deadlock test might be too long for a test. In principle it's nice for the stress portion, but it seems too long. I'd also like to find another way than 1.should == 1, but you can check that in and I'll find a way.
[Shri Borde] This test existed in wakeup_spec.rb and you said was removed from RubySpec. I am actually tempted to remove it completely. I will check it in as is and will let you figure out what to do when you pull in the new RubySpecs.


JD
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 07, 2009 2:37 PM
To: Shri Borde; ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: Re: [Ironruby-core] Code Review: hangs in core\thread

I would prefer using a field rather than a private auto-property for IsSleeping.
Other than that, changes in ThreadOps look good.

Tomas

-----Original Message-----
From: Shri Borde
Sent: Wednesday, January 07, 2009 2:18 PM
To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Since no one has reviewed this yet, I have updated the change to factor out the tests for alive?, inspect, status and stop?

Another product change was that Thread#value should return false if the thread was killed. Only a thread with an uncaught exception should return nil.

Thanks,
Shri

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:49 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: hangs in core\thread

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  :
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.


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


From jdeville at microsoft.com  Thu Jan  8 14:42:17 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 11:42:17 -0800
Subject: [Ironruby-core] Code Review: hangs in core\thread
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049BFF0@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD049B67F@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049BAAC@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8050@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB5760049@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049BFF0@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB576007D@NA-EXMSG-C112.redmond.corp.microsoft.com>

I meant that the status of the thread might change after you call Status.new, however, it looks like you meant for that to happen:

" It should capture the state of the thread whenever Status.new was called."

I just wanted to be 100% sure this was the case. Everything else looks good.

JD


-----Original Message-----
From: Shri Borde
Sent: Thursday, January 08, 2009 11:39 AM
To: Jim Deville; ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Inline..

Everything has been addressesd except I am not sure what you meant by " Did you want to have possibly stale information in the Status class? ". The shelveset has been updated.

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Thursday, January 08, 2009 11:13 AM
To: ironruby-core at rubyforge.org; Shri Borde; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Test Review:
classes.rb:
* can you change the get_status_... methods to status_... methods? The extra get isn't really used in Ruby.
[Shri Borde] Done


* Did you want to have possibly stale information in the Status class?
[Shri Borde] What do you mean by this? It should capture the state of the thread whenever Status.new was called.

* for running thread, why not just do:
def status_of_running_thread
  t = Thread.new {loop {}}
  Thread.pass until t.status == "run"
  status = Status.new t
  t.kill
  status
end
[Shri Borde] Done


* critical_should_be_false should use ScratchPad instead of should's in the method. I would suggest trying to always keep shoulds in the spec itself.
[Shri Borde] Done

* Can you modify method names and variables to be snake_case instead of CamelCase?
[Shri Borde] Done

Alive_spec.rb:
* (new thing I'm going to start doing with new guards) What's the justification for the compliant_on(:ruby) guard. Why isn't it a tag?
[Shri Borde] I copied it from inspect_spec.rb. Until we understand how all the guards are supposed to work (you are following up about that), I don't know how to clean this up. So I keeping the status quo.

Critical_spec.rb:
* add a before(:each) block and move the ScratchPad.clear to there, then you can add ScratchPad without thinking about it.
[Shri Borde] Done. I think MSpec should be doing this, but oh well.

* Extra comment (#end) on line 49
[Shri Borde] Removed

Exit.rb:
* lines 11 and 23: I don't see a reason for checking the value of the threads. You are already checking the ScratchPad, so you know the execution ran.
[Shri Borde] Removed it. I had already added a separate test for Thread#value. No point having the same test in two places.

Raise_spec.rb:
* You might need to remove the " raises an exception on running thread" tag. I think I added one when doing dates.
[Shri Borde] Done

Wakeup.rb:
* Line 38 has an unused Channel
[Shri Borde] Removed

* 1000 times for the deadlock test might be too long for a test. In principle it's nice for the stress portion, but it seems too long. I'd also like to find another way than 1.should == 1, but you can check that in and I'll find a way.
[Shri Borde] This test existed in wakeup_spec.rb and you said was removed from RubySpec. I am actually tempted to remove it completely. I will check it in as is and will let you figure out what to do when you pull in the new RubySpecs.


JD
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 07, 2009 2:37 PM
To: Shri Borde; ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: Re: [Ironruby-core] Code Review: hangs in core\thread

I would prefer using a field rather than a private auto-property for IsSleeping.
Other than that, changes in ThreadOps look good.

Tomas

-----Original Message-----
From: Shri Borde
Sent: Wednesday, January 07, 2009 2:18 PM
To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: RE: Code Review: hangs in core\thread

Since no one has reviewed this yet, I have updated the change to factor out the tests for alive?, inspect, status and stop?

Another product change was that Thread#value should return false if the thread was killed. Only a thread with an uncaught exception should return nil.

Thanks,
Shri

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 06, 2009 11:49 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: hangs in core\thread

  tfpt review "/shelveset:hangs;REDMOND\sborde"

  Comment  :
  Non-deterministic fixes. I ran all the core\thread specs in a loop in multiple processes and ran into a few non-deterministic failures. This change fixes everything I ran into. The only product change is that Thread#wakeup is not queued up if the target thread is not sleeping. This is the MRI behavior.

 Also started using comments in the tag files like this - fails("reason why"):test name. I will undo this if Jim says that he will be regenerating the tags file periodically.


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


From jdeville at microsoft.com  Thu Jan  8 16:17:04 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 13:17:04 -0800
Subject: [Ironruby-core] Code Review: rakefixes
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB576011E@NA-EXMSG-C112.redmond.corp.microsoft.com>

FYI. Going in as a direct commit.

  tfpt review "/shelveset:rakefixes;REDMOND\jdeville"
  Comment  : 
  fixes some versioning and file ignores for Git integration


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rakefixes.diff
Type: application/octet-stream
Size: 1491 bytes
Desc: rakefixes.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090108/03330398/attachment.obj>

From lists at ruby-forum.com  Thu Jan  8 19:53:05 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 01:53:05 +0100
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
Message-ID: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>

Hello,


Ruby:

  irb(main):001:0> foo = 3
  => 3
  irb(main):002:0> foo
  => 3

IronRuby:

  >>> foo = 3
  => 3
  >>> foo
  :0: undefined method `foo' for main:Object (NoMethodError)


Any idea, why this error thrown by IronRuby?

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

From Tomas.Matousek at microsoft.com  Thu Jan  8 20:28:03 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 17:28:03 -0800
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
In-Reply-To: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
References: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>

I fixed this a couple days ago. Don't know whether it has already been pushed out. Jim?

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 4:53 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?

Hello,


Ruby:

  irb(main):001:0> foo = 3
  => 3
  irb(main):002:0> foo
  => 3

IronRuby:

  >>> foo = 3
  => 3
  >>> foo
  :0: undefined method `foo' for main:Object (NoMethodError)


Any idea, why this error thrown by IronRuby?

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


From jdeville at microsoft.com  Thu Jan  8 20:50:10 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 17:50:10 -0800
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B2@NA-EXMSG-C112.redmond.corp.microsoft.com>

I'll be pushing it out tonight.

JD

-----Original Message-----
From: Tomas Matousek <Tomas.Matousek at microsoft.com>
Sent: January 08, 2009 5:28 PM
To: ironruby-core at rubyforge.org <ironruby-core at rubyforge.org>
Cc: Jim Deville <jdeville at microsoft.com>
Subject: RE: [Ironruby-core] local variables: Ruby vs. IronRuby difference?


I fixed this a couple days ago. Don't know whether it has already been pushed out. Jim?

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 4:53 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?

Hello,


Ruby:

  irb(main):001:0> foo = 3
  => 3
  irb(main):002:0> foo
  => 3

IronRuby:

  >>> foo = 3
  => 3
  >>> foo
  :0: undefined method `foo' for main:Object (NoMethodError)


Any idea, why this error thrown by IronRuby?

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


From lists at ruby-forum.com  Thu Jan  8 21:50:42 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 03:50:42 +0100
Subject: [Ironruby-core] IronRuby hosting: self becomes nil
Message-ID: <3c0ab782f5d70a784748a4e8ad9098e8@ruby-forum.com>

Hello,

I get very odd results with attached code:

- - -
#<System::Windows::Forms::Form:0x000005c>
nil
#<System::Windows::Forms::Form:0x000005e>
- - -

While was expected
- - -
#<System::Windows::Forms::Form:0x000005c>
#<System::Windows::Forms::Form:0x000005c>
#<System::Windows::Forms::Form:0x000005e>
- - -

The 'nil' is printed by this expression:
  form = form.test

and the test method definition is:

  class Object
    def test
      p self
    end
  end

The hint: 'form' variable was set by the script host (SetVariable).

I am using DLR-0.9.

Thanks,
- Alex

Attachments:
http://www.ruby-forum.com/attachment/3138/snippet.txt

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

From michael.letterle at gmail.com  Fri Jan  9 01:25:37 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Fri, 9 Jan 2009 01:25:37 -0500
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>

wait.... wait... Does this mean... we're getting LOCAL variables in the ir
REPL!?!?!?

On Thu, Jan 8, 2009 at 8:28 PM, Tomas Matousek <Tomas.Matousek at microsoft.com
> wrote:

> I fixed this a couple days ago. Don't know whether it has already been
> pushed out. Jim?
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
> Sent: Thursday, January 08, 2009 4:53 PM
> To: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
>
> Hello,
>
>
> Ruby:
>
>  irb(main):001:0> foo = 3
>  => 3
>  irb(main):002:0> foo
>  => 3
>
> IronRuby:
>
>  >>> foo = 3
>  => 3
>  >>> foo
>  :0: undefined method `foo' for main:Object (NoMethodError)
>
>
> Any idea, why this error thrown by IronRuby?
>
> - Alex
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/4ddaf2b0/attachment.html>

From Shri.Borde at microsoft.com  Fri Jan  9 01:58:12 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 8 Jan 2009 22:58:12 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:



myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:



myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C971E2.93B1F230]












________________________________
















_______________________________________________

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:image001.jpg at 01C971E2.93B1F230]










________________________________










_______________________________________________

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:image001.jpg at 01C971E2.93B1F230]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090108/e76156ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090108/e76156ff/attachment-0001.jpg>

From jdeville at microsoft.com  Fri Jan  9 02:15:39 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 23:15:39 -0800
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
In-Reply-To: <ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>
References: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB576027F@NA-EXMSG-C112.redmond.corp.microsoft.com>

y.e.s.

:)

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Thursday, January 08, 2009 10:26 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] local variables: Ruby vs. IronRuby difference?

wait.... wait... Does this mean... we're getting LOCAL variables in the ir REPL!?!?!?
On Thu, Jan 8, 2009 at 8:28 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:
I fixed this a couple days ago. Don't know whether it has already been pushed out. Jim?

Tomas

-----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>] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 4:53 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
Hello,


Ruby:

 irb(main):001:0> foo = 3
 => 3
 irb(main):002:0> foo
 => 3

IronRuby:

 >>> foo = 3
 => 3
 >>> foo
 :0: undefined method `foo' for main:Object (NoMethodError)


Any idea, why this error thrown by IronRuby?

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

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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From jdeville at microsoft.com  Fri Jan  9 02:27:50 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 8 Jan 2009 23:27:50 -0800
Subject: [Ironruby-core] Code Review: rakefix2
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760280@NA-EXMSG-C112.redmond.corp.microsoft.com>

FYI, Going in via direct commit

  tfpt review "/shelveset:rakefix2;REDMOND\jdeville"
  Comment  : 
  More changes for git


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rakefix2.diff
Type: application/octet-stream
Size: 848 bytes
Desc: rakefix2.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090108/6e2de1f4/attachment.obj>

From Tomas.Matousek at microsoft.com  Fri Jan  9 02:37:52 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 8 Jan 2009 23:37:52 -0800
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
In-Reply-To: <ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>
References: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8664@NA-EXMSG-C112.redmond.corp.microsoft.com>

Yep. See also my blog post - http://blog.tomasm.net.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Thursday, January 08, 2009 10:26 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] local variables: Ruby vs. IronRuby difference?

wait.... wait... Does this mean... we're getting LOCAL variables in the ir REPL!?!?!?
On Thu, Jan 8, 2009 at 8:28 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:
I fixed this a couple days ago. Don't know whether it has already been pushed out. Jim?

Tomas

-----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>] On Behalf Of Alex 2k8
Sent: Thursday, January 08, 2009 4:53 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
Hello,


Ruby:

 irb(main):001:0> foo = 3
 => 3
 irb(main):002:0> foo
 => 3

IronRuby:

 >>> foo = 3
 => 3
 >>> foo
 :0: undefined method `foo' for main:Object (NoMethodError)


Any idea, why this error thrown by IronRuby?

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

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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From Tomas.Matousek at microsoft.com  Fri Jan  9 03:15:51 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 00:15:51 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:


myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:


myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C971EC.010A69D0]
















________________________________




















_______________________________________________

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:image001.jpg at 01C971EC.010A69D0]














________________________________














_______________________________________________

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:image001.jpg at 01C971EC.010A69D0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/73d3abf5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/73d3abf5/attachment-0001.jpg>

From jdeville at microsoft.com  Fri Jan  9 03:48:38 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 9 Jan 2009 00:48:38 -0800
Subject: [Ironruby-core] SVN __AND__ Git revisions pushed
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760281@NA-EXMSG-C112.redmond.corp.microsoft.com>

My changes went in this morning, so I have pushed SVN 183 and Git revision 69815c7.

Two things:

1)      Git may be in a bad state due to CRLF issues and casing. Can I get a confirmation that it compiles and runs?

2)      This release includes support for local variables in the ir console. Enjoy :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/aaa36843/attachment.html>

From thibaut.barrere at gmail.com  Fri Jan  9 04:30:46 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 9 Jan 2009 10:30:46 +0100
Subject: [Ironruby-core] SVN __AND__ Git revisions pushed
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760281@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760281@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4a68b8cf0901090130q76a5f09ft755f76db42863540@mail.gmail.com>

>       This release includes support for local variables in the ir console. Enjoy J

That's a great thing!

thanks for your work

-- Thibaut

From jirapong.nanta at gmail.com  Fri Jan  9 05:05:35 2009
From: jirapong.nanta at gmail.com (jirapong.nanta at gmail.com)
Date: Fri, 9 Jan 2009 17:05:35 +0700
Subject: [Ironruby-core] SVN __AND__ Git revisions pushed
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760281@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5760281@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <D604DD1D-E1D9-451A-90F0-B2506200706A@gmail.com>

I get svn.exe error...on Mac + Mono

Macintosh-2:Ruby Jirapong$ rake compile mono=1 --trace
(in /Users/Jirapong/ironruby/merlin/main/Languages/Ruby)
** Invoke compile (first_time)
** Invoke happy (first_time)
** Execute happy
Cannot find svn.exe on system path.

***** Missing commands! You must have the .NET redist and the SDK
***** (for resgen.exe) installed. If you are synchronizing source
***** trees *inside* Microsoft, you must have both tfs.exe and
***** svn.exe on your path.
Macintosh-2:Ruby Jirapong$ vim

believe that need to fix  line#107 in rake/misc.rake

104 task :happy do
105   IronRuby.source_context do
106     commands = !mono? ? ['resgen.exe', 'csc.exe'] : ['resgen',  
'gmcs']
107     commands += ['svn.exe'] if IronRuby.is_merlin? and !mono?


On Jan 9, 2009, at 3:48 PM, Jim Deville wrote:

> My changes went in this morning, so I have pushed SVN 183 and Git  
> revision 69815c7.
>
> Two things:
> 1)      Git may be in a bad state due to CRLF issues and casing. Can  
> I get a confirmation that it compiles and runs?
> 2)      This release includes support for local variables in the ir  
> console. Enjoy J
> _______________________________________________
> 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/20090109/f52ba4cb/attachment.html>

From thibaut.barrere at gmail.com  Fri Jan  9 05:33:46 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 9 Jan 2009 11:33:46 +0100
Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
Message-ID: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>

Hello,
I'm starting to integrate IronRuby files into a VisualStudio C# project,
mainly to write easy-to-maintain GUI builders.

As I don't want to have .rb files lying around this deployment, I had that
idea about embedding all the files inside an assembly, loading them at run
time through resource manager and passing them to the IronRuby host I would
start from C#.

While that would work, it would be even simplier to have these .rb files
compiled to some assembly.

Is there a trick to compile a bunch of .rb files to an assembly today ?

thanks!

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

From lists at ruby-forum.com  Fri Jan  9 06:22:49 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 12:22:49 +0100
Subject: [Ironruby-core] local variables: Ruby vs. IronRuby difference?
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8664@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <ef1c56cc35e3215c8e43f3fbc0496a31@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C85C9@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<ef5222770901082225l3c4eff42l554940af1805388a@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8664@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4bd9b2805c0d5c61ac51f4b32590de6b@ruby-forum.com>

Thanks, http://www.ruby-forum.com/topic/175284 fixed it.
-- 
Posted via http://www.ruby-forum.com/.

From lists at ruby-forum.com  Fri Jan  9 10:55:26 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 16:55:26 +0100
Subject: [Ironruby-core] Misleading error message calling private method
Message-ID: <e42712afae498a98d7da7ca27f4c3c4a@ruby-forum.com>

Hello,

IronRuby throws misleading error message, when I call private method of
the C# class.

- - - -
C#
  public class Cls {
      private void private_method() {}
  }

Ruby:
  Cls.new.private_method

Output:
  #<ArgumentError: wrong number or type of arguments for
`private_method'>
- - - -


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

From lists at ruby-forum.com  Fri Jan  9 11:16:58 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 17:16:58 +0100
Subject: [Ironruby-core] Calling overloaded methods
Message-ID: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>

Hello,

C#
    public class Cls {
        public void foo(object a) {
            Console.WriteLine("foo #1");
        }
        public void foo(object[] a) {
            Console.WriteLine("foo #2");
        }
    }

Ruby:

    Cls.new.foo(7)
    Cls.new.foo([3, 4])

Output:
    foo #1
    foo #1  <-- Calling foo(object a) again


So how can I call foo(object[] a)?

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

From curth at microsoft.com  Fri Jan  9 11:48:11 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Fri, 9 Jan 2009 08:48:11 -0800
Subject: [Ironruby-core] Calling overloaded methods
In-Reply-To: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>
References: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AE1DD65@NA-EXMSG-C118.redmond.corp.microsoft.com>

You'll need to build a CLR array rather than a Ruby array.

require 'mscorlib'
System::Array.create_instance(System::Object.to_clr_type, 2)
o = System::Array.create_instance(System::Object.to_clr_type, 2)
>>> o[0] = 3
>>> o[1] = 4

You can monkey-patch Array and add this as a helper:

class Array
  def to_clr_ary
    o = System::Array.create_instance(System::Object.to_clr_type, length)
    each_with_index { |obj, i| o[i] = obj }
    o
  end
end

CLR arrays and Ruby arrays are totally different; Ruby arrays are much more similar to "List<object>" than to "object[]".  So it's unlikely that IronRuby would ever do this conversion automatically for you.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Friday, January 09, 2009 8:17 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Calling overloaded methods

Hello,

C#
    public class Cls {
        public void foo(object a) {
            Console.WriteLine("foo #1");
        }
        public void foo(object[] a) {
            Console.WriteLine("foo #2");
        }
    }

Ruby:

    Cls.new.foo(7)
    Cls.new.foo([3, 4])

Output:
    foo #1
    foo #1  <-- Calling foo(object a) again


So how can I call foo(object[] a)?

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


From Tomas.Matousek at microsoft.com  Fri Jan  9 12:07:45 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 09:07:45 -0800
Subject: [Ironruby-core] Misleading error message calling private method
In-Reply-To: <e42712afae498a98d7da7ca27f4c3c4a@ruby-forum.com>
References: <e42712afae498a98d7da7ca27f4c3c4a@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C8704@NA-EXMSG-C112.redmond.corp.microsoft.com>

Could you file a bug @ http://rubyforge.org/projects/ironruby/?

Thanks,
Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Friday, January 09, 2009 7:55 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Misleading error message calling private method

Hello,

IronRuby throws misleading error message, when I call private method of
the C# class.

- - - -
C#
  public class Cls {
      private void private_method() {}
  }

Ruby:
  Cls.new.private_method

Output:
  #<ArgumentError: wrong number or type of arguments for
`private_method'>
- - - -


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


From Tomas.Matousek at microsoft.com  Fri Jan  9 12:17:40 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 09:17:40 -0800
Subject: [Ironruby-core] Calling overloaded methods
In-Reply-To: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>
References: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B248C870B@NA-EXMSG-C112.redmond.corp.microsoft.com>

[3,4] is not an array of objects. It's a RubyArray. 

You can create a CLR array like this:

v = System::Array.of(Object).new(3)
[1,2,3].each_with_index { |x,i| v[i] = x }

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Friday, January 09, 2009 8:17 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Calling overloaded methods

Hello,

C#
    public class Cls {
        public void foo(object a) {
            Console.WriteLine("foo #1");
        }
        public void foo(object[] a) {
            Console.WriteLine("foo #2");
        }
    }

Ruby:

    Cls.new.foo(7)
    Cls.new.foo([3, 4])

Output:
    foo #1
    foo #1  <-- Calling foo(object a) again


So how can I call foo(object[] a)?

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


From Shri.Borde at microsoft.com  Fri Jan  9 12:58:19 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 9 Jan 2009 09:58:19 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C97240.CC8E21B0]




















________________________________
























_______________________________________________

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:image001.jpg at 01C97240.CC8E21B0]


















________________________________


















_______________________________________________

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:image001.jpg at 01C97240.CC8E21B0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/63280183/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/63280183/attachment-0001.jpg>

From Jimmy.Schementi at microsoft.com  Fri Jan  9 14:42:36 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 9 Jan 2009 11:42:36 -0800
Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
In-Reply-To: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>
References: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>

Embedding the files as resources would be your best bet, as we don't have compilation to an assembly working today.

Basically (compiled with outlook ...):

var assembly = Assembly.GetExecutingAssembly();
var textStreamReader = new StreamReader(assembly.GetManifestResourceStream("foo.rb"));
var code = textStreamReader.ReadToEnd();
textStreamReader.Close();

var runtime = new ScriptRuntime();
var ruby = IronRuby.Ruby.GetEngine(runtime);
var source = ruby.CreateScriptSourceFromString(code);
var result = source.Execute();

Compilation is something we want to support though.

~js

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
> Sent: Friday, January 09, 2009 2:34 AM
> To: ironruby-core
> Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting
> ?
>
> Hello,
>
> I'm starting to integrate IronRuby files into a VisualStudio C#
> project, mainly to write easy-to-maintain GUI builders.
>
> As I don't want to have .rb files lying around this deployment, I had
> that idea about embedding all the files inside an assembly, loading
> them at run time through resource manager and passing them to the
> IronRuby host I would start from C#.
>
> While that would work, it would be even simplier to have these .rb
> files compiled to some assembly.
>
> Is there a trick to compile a bunch of .rb files to an assembly today ?
>
> thanks!
>
> -- Thibaut

From lists at ruby-forum.com  Fri Jan  9 15:12:03 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 21:12:03 +0100
Subject: [Ironruby-core] Calling overloaded methods
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C870B@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <7fd7651c495104bff67e0259ac4ae570@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C870B@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <7952d6c6eb4808f15082c44e3e588896@ruby-forum.com>

Thank you!
-- 
Posted via http://www.ruby-forum.com/.

From thibaut.barrere at gmail.com  Fri Jan  9 15:16:07 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 9 Jan 2009 21:16:07 +0100
Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <4a68b8cf0901091216p70ea6ee3q404b986f0cc8945f@mail.gmail.com>

Hi Jimmy,

thanks for the feedback (and the outlook snippet :-)!

I'll try that.

cheers

-- Thibaut

From Jimmy.Schementi at microsoft.com  Fri Jan  9 16:12:22 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 9 Jan 2009 13:12:22 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>

Here are the ideas that stand out to me:

I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:

content.load of(Texture2D), "mytexture"

Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...

content.load_of(Texture2D).call "mytexture"

How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.

content.of(Texture2D).load "mytexture"

Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
~js


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 09, 2009 9:58 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C9725A.DCFA15D0]
























________________________________




























_______________________________________________

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:image001.jpg at 01C9725A.DCFA15D0]






















________________________________






















_______________________________________________

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:image001.jpg at 01C9725A.DCFA15D0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/03d0b904/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/03d0b904/attachment-0001.jpg>

From lists at ruby-forum.com  Fri Jan  9 16:25:20 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Fri, 9 Jan 2009 22:25:20 +0100
Subject: [Ironruby-core] Misleading error message calling private method
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B248C8704@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <e42712afae498a98d7da7ca27f4c3c4a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8704@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <8b0da2b382ae25818c9edd6a451ecf33@ruby-forum.com>

Hi, Tomas

I submitted it as bug # 23508, thought did no assignments.

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

From Shri.Borde at microsoft.com  Fri Jan  9 16:28:09 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 9 Jan 2009 13:28:09 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058B95F@NA-EXMSG-C104.redmond.corp.microsoft.com>

Orion mentioned below the idea of adding "of" to the class. Here is how it would read. These calls actually read reasonably well since they are all static methods. I would be curious to see examples of instance  methods, and how this scheme would read in that case. Anyone know of real world examples of generic instance methods?

Array.of(Fixnum, String).convert_all data, lambda {|x|x.to_s }
Content.of(Texture2d).load "mytexture"
System::Activator.of(String).create_instance
System::Linq::Enumerable.of(String).count string_array


Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 1:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Here are the ideas that stand out to me:

I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:

content.load of(Texture2D), "mytexture"

Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...

content.load_of(Texture2D).call "mytexture"

How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.

content.of(Texture2D).load "mytexture"

Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
~js


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 09, 2009 9:58 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C9725E.1CD23400]




























________________________________
































_______________________________________________

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:image001.jpg at 01C9725E.1CD23400]


























________________________________


























_______________________________________________

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:image001.jpg at 01C9725E.1CD23400]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/3aff4afa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/3aff4afa/attachment-0001.jpg>

From Tomas.Matousek at microsoft.com  Fri Jan  9 16:30:17 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 13:30:17 -0800
Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAD88@NA-EXMSG-C112.redmond.corp.microsoft.com>

The last 4 lines of the snippet could be slightly simplified:

var engine = IronRuby.Ruby.CreateEngine();
engine.Execute(code);

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 11:43 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?

Embedding the files as resources would be your best bet, as we don't have compilation to an assembly working today.

Basically (compiled with outlook ...):

var assembly = Assembly.GetExecutingAssembly();
var textStreamReader = new StreamReader(assembly.GetManifestResourceStream("foo.rb"));
var code = textStreamReader.ReadToEnd();
textStreamReader.Close();

var runtime = new ScriptRuntime();
var ruby = IronRuby.Ruby.GetEngine(runtime);
var source = ruby.CreateScriptSourceFromString(code);
var result = source.Execute();

Compilation is something we want to support though.

~js

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
> Sent: Friday, January 09, 2009 2:34 AM
> To: ironruby-core
> Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting
> ?
>
> Hello,
>
> I'm starting to integrate IronRuby files into a VisualStudio C#
> project, mainly to write easy-to-maintain GUI builders.
>
> As I don't want to have .rb files lying around this deployment, I had
> that idea about embedding all the files inside an assembly, loading
> them at run time through resource manager and passing them to the
> IronRuby host I would start from C#.
>
> While that would work, it would be even simplier to have these .rb
> files compiled to some assembly.
>
> Is there a trick to compile a bunch of .rb files to an assembly today ?
>
> thanks!
>
> -- Thibaut
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From Tomas.Matousek at microsoft.com  Fri Jan  9 16:45:53 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 13:45:53 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>

Mine has also an issue that just occurred to me. If you do:

class C
  content.load of(Texture2D), "foo"
end

"of" resolves to Module#of which would return a C<Texture2D> if C was a generic type or throws an exception.
So that's not good either. We would need a different method name for generic method constructor than for generic type. Maybe "method_of"?

As for your idea:
content.of(T).load

is looks backwards. The content is not of T... the load is. I think this would be confusing.

Until we figure out some nice clean solution that works in 100% cases, I would implement the following as the first step for generic method support:

content.method(:load).of(Texture2D).call("mytexture")

(Note, you can do the same in Ruby for regular methods: "foo".method(:center).call(100))

anything else is just a convenience and anyone could define it via standard Ruby means.

Tomas


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 1:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Here are the ideas that stand out to me:

I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:

content.load of(Texture2D), "mytexture"

Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...

content.load_of(Texture2D).call "mytexture"

How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.

content.of(Texture2D).load "mytexture"

Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
~js


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 09, 2009 9:58 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C9725F.575F6920]




























________________________________
































_______________________________________________

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:image001.jpg at 01C9725F.575F6920]


























________________________________


























_______________________________________________

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:image001.jpg at 01C9725F.575F6920]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/18327db8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/18327db8/attachment-0001.jpg>

From ryan.riley at panesofglass.org  Fri Jan  9 16:51:19 2009
From: ryan.riley at panesofglass.org (Ryan Riley)
Date: Fri, 9 Jan 2009 15:51:19 -0600
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <a880efe10901091351y7e3b744eo7ef1454602c54457@mail.gmail.com>

I like Tomas's idea the best. Generics are not native to Ruby, so most
people using them will likely have a C#/VB background, which means Tomas's
syntax would be more familiar.

The "_of" syntax isn't bad, but forcing a ".do" or ".call" at the end isn't
ideal, even if it does have a bit of a Ruby flavor.

Adding a ".of()" to the class is okay, but many classes may have generic
methods even when the class itself is not a generic. (I'm thinking primarily
of static and extension method classes here.)

Passing the generic types as the first parameters seems the most explicit
and understandable translation to me.

~ Ryan

On Fri, Jan 9, 2009 at 3:12 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

>  Here are the ideas that stand out to me:
>
>
>
> I like Tomas's idea, since it reads like C#/VB, but adding an argument to
> the front urks me:
>
>
>
> content.load of(Texture2D), "mytexture"
>
>
>
> Shri, having the "_of" appended to a generic method name and requiring a
> ".do" after it is how you would work with lambdas (except you do ".call"),
> but since we're talking about .NET methods, not .NET delegates. So, I'd like
> the syntax to look more like a method call. Also, as Tomas says, mangling
> gets more complicated ...
>
>
>
> content.load_of(Texture2D).call "mytexture"
>
>
>
> How about adding an "of" method to the class/object, to put the class in a
> generic "mode"? The method probably shouldn't be called "of", but you get
> the idea. It reads different than C#, but seems the most Rubyesk without
> changing the arguments.
>
>
>
> content.of(Texture2D).load "mytexture"
>
>
>
> Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
>
> ~js
>

-- 
Ryan Riley
ryan.riley at panesofglass.org
http://panesofglass.org/
http://wizardsofsmart.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/0d05b8b8/attachment.html>

From Jimmy.Schementi at microsoft.com  Fri Jan  9 17:03:15 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 9 Jan 2009 14:03:15 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D898A@NA-EXMSG-C116.redmond.corp.microsoft.com>

Cool, implement the basic support and we can play around with the syntax. Thanks Tomas!

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 1:46 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Mine has also an issue that just occurred to me. If you do:

class C
  content.load of(Texture2D), "foo"
end

"of" resolves to Module#of which would return a C<Texture2D> if C was a generic type or throws an exception.
So that's not good either. We would need a different method name for generic method constructor than for generic type. Maybe "method_of"?

As for your idea:
content.of(T).load

is looks backwards. The content is not of T... the load is. I think this would be confusing.

Until we figure out some nice clean solution that works in 100% cases, I would implement the following as the first step for generic method support:

content.method(:load).of(Texture2D).call("mytexture")

(Note, you can do the same in Ruby for regular methods: "foo".method(:center).call(100))

anything else is just a convenience and anyone could define it via standard Ruby means.

Tomas


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 1:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Here are the ideas that stand out to me:

I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:

content.load of(Texture2D), "mytexture"

Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...

content.load_of(Texture2D).call "mytexture"

How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.

content.of(Texture2D).load "mytexture"

Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
~js


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 09, 2009 9:58 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C97263.04385820]
































________________________________




































_______________________________________________

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:image001.jpg at 01C97263.04385820]






























________________________________






























_______________________________________________

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:image001.jpg at 01C97263.04385820]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/c88f368f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/c88f368f/attachment-0001.jpg>

From Tomas.Matousek at microsoft.com  Fri Jan  9 17:29:21 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 14:29:21 -0800
Subject: [Ironruby-core] Misleading error message calling private method
In-Reply-To: <8b0da2b382ae25818c9edd6a451ecf33@ruby-forum.com>
References: <e42712afae498a98d7da7ca27f4c3c4a@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8704@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<8b0da2b382ae25818c9edd6a451ecf33@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DADF5@NA-EXMSG-C112.redmond.corp.microsoft.com>

That's the right way :)

Thanks,
Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Friday, January 09, 2009 1:25 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Misleading error message calling private method

Hi, Tomas

I submitted it as bug # 23508, thought did no assignments.

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


From ryan.riley at panesofglass.org  Fri Jan  9 17:32:57 2009
From: ryan.riley at panesofglass.org (Ryan Riley)
Date: Fri, 9 Jan 2009 16:32:57 -0600
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>

How would this look for instantiating a generic object?

my_object = Foo.method(:new).of(Bar).call

That seems strange. Perhaps we need to possibilities: the above for generic
methods and the following for generic classes:

my_object = Foo.of(Bar).new
# where Foo would be defined as Foo<T> in C#

my_clone = my_object.clone
# where clone would have a C# signature of T Clone<T>()

or should that be:

my_clone = my_object.method(:clone).of(Bar).call?
# and allow my_object.clone to have an overloaded
# C# signature of object Clone()?

~Ryan

On Fri, Jan 9, 2009 at 3:45 PM, Tomas Matousek <Tomas.Matousek at microsoft.com
> wrote:

>  Mine has also an issue that just occurred to me. If you do:
>
>
>
> class C
>
>   content.load of(Texture2D), "foo"
>
> end
>
>
>
> "of" resolves to Module#of which would return a C<Texture2D> if C was a
> generic type or throws an exception.
>
> So that's not good either. We would need a different method name for
> generic method constructor than for generic type. Maybe "method_of"?
>
>
>
> As for your idea:
>
> content.of(T).load
>
>
>
> is looks backwards. The content is not of T? the load is. I think this
> would be confusing.
>
>
>
> Until we figure out some nice clean solution that works in 100% cases, I
> would implement the following as the first step for generic method support:
>
>
>
> content.method(:load).of(Texture2D).call("mytexture")
>
>
>
> (Note, you can do the same in Ruby for regular methods:
> "foo".method(:center).call(100))
>
>
>
> anything else is just a convenience and anyone could define it via standard
> Ruby means.
>
>
>
> Tomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/b11e7cdf/attachment.html>

From jdeville at microsoft.com  Fri Jan  9 17:38:23 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 9 Jan 2009 14:38:23 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D898A@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<372109E149E8084D8E6C7D9CFD82E0633711E86455@NA-EXMSG-C115.redmond.corp.microsoft.com>
	<a40ebe370811261048h463bfaa6m4c91307b3f3752a3@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D7AF@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DB38E.9020204@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D898A@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB57605A4@NA-EXMSG-C112.redmond.corp.microsoft.com>

Agreed. Once we find what works, we can consider pulling it into the interpreter, but we may not even need to.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 2:03 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Cool, implement the basic support and we can play around with the syntax. Thanks Tomas!

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 1:46 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Mine has also an issue that just occurred to me. If you do:

class C
  content.load of(Texture2D), "foo"
end

"of" resolves to Module#of which would return a C<Texture2D> if C was a generic type or throws an exception.
So that's not good either. We would need a different method name for generic method constructor than for generic type. Maybe "method_of"?

As for your idea:
content.of(T).load

is looks backwards. The content is not of T... the load is. I think this would be confusing.

Until we figure out some nice clean solution that works in 100% cases, I would implement the following as the first step for generic method support:

content.method(:load).of(Texture2D).call("mytexture")

(Note, you can do the same in Ruby for regular methods: "foo".method(:center).call(100))

anything else is just a convenience and anyone could define it via standard Ruby means.

Tomas


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 09, 2009 1:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Here are the ideas that stand out to me:

I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:

content.load of(Texture2D), "mytexture"

Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...

content.load_of(Texture2D).call "mytexture"

How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.

content.of(Texture2D).load "mytexture"

Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.
~js


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 09, 2009 9:58 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

Yup, it can theoretically cause an ambiguity, but in reality, I doubt we will ever run into a case of a class having both Foo<T> and FooOf. We can scan all of .NET 3.5 to see if there is any clash of this form. And as you say, if we really cared, we could define some priortization scheme to deal with it and/or have some other scheme like using Kernel#send to be able to get to the lower priority case. We have to deal with this in other cases too where Ruby keyword names clash with .NET api names, right? I think we should optimize for the 99.9% case (there will be no clashes) rather than chosing a suboptimal syntax that can handle the 0.1% case.

Yes, we should probably do the "Of" suffix as well if we do "_of".

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Friday, January 09, 2009 12:16 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

That might also work. There might be ambiguities however (as with any name prefixes/suffixes). What if there are methods, for example, GetClass<T>() and GetClassOf(object)? What would get_class_of(String) mean? Maybe we could define a priority. But that is IMO too magical.

Also, the mangling works in two steps:

1)      the method name is tried as written (thus you can use Array.ConvertAll(...))

2)      mangled name is tried if 1) fails.

Hence we might need to handle -Of suffix as well to be consistent, if the PascalCase style is preferred by the user. And that would lead to more ambiguities.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 08, 2009 10:58 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Generic method synxtax

Another suggestion is to use name mangling to append "_of" to the method name. This could return an object with a method called "do", "call", or something like that. Since we already do name mangling from PascalCase to under_scores, this could work out. It avoids having to pass the type parameter along with the other arguments.

Array.convert_all_of(Fixnum, String).do data, lambda {|x|x.to_s }
Content.load_of(Texture2d).do "mytexture"
System.Activator.create_instance_of(String).do
System.Linq.Enumerable.count_of(String).do string_array

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Wednesday, November 26, 2008 4:12 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

For the record: I really like the chaining idea. I don't know if it would work, but I like it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 4:10 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

Ah I see. Completely agree with the reasoning behind 'stuff appears when you require mscorlib' too.

Possible idea - make 'of' a proc rather than a method, so it uses square brackets instead of round ones.

d = Dictionary.of[String, String]

t = Load of[Texture2d], "sometexture"   # awesome, but only because 'Load' is a conveniently nice name


IMHO the [] "looks more like templates" than if it used () - but I'm biased on account of having never written a line of VB.net in my life.
The VB coders will probably have the exact opposite reaction to me :-)

Even so, I'm not entirely sure that copying VB is neccessarily the right thing...
Examples for thought:

data = [1,2,3,4]

Array.convert_all of[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all of(Fixnum, String), data, lambda{ |x| x.to_s }

Array.convert_all T[Fixnum, String], data, lambda{ |x| x.to_s }

Array.convert_all T(Fixnum, String), data, lambda{ |x| x.to_s }


I guess that any of these will be fine once one becomes used to them...
Here's one from left-field which probably won't work, but how about using a proxy like andand does

Array.with(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

Array.T(Fixnum, String).convert_all data, lambda{ |x| x.to_s }

T(Texture2d).load "sometexture"

Tomas Matousek wrote:
It's like:

    Sub Foo(Of T)(ByVal a As T)
    End Sub

    Sub Main()
        Foo(Of Integer)(1)
    End Sub

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 3:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

That makes sense.

Dictionary.of(T1, T2) looks good, but how do they handle invoking generic methods?
I don't have VB.net installed, and all the samples I can find all rely on type inference rather than explicitly specifying the type

Do they do Load( of(Texture2d), "blah" ) ??

Thanks.

Tomas Matousek wrote:
VB.NET has (Of T) syntax for generic parameters, so it would be familiar to VB programmers :)
I don't see a strong connection between "of" and "typeof".

"T" is interesting, though we already use "of" for generic types (e.g. Dictionary.of(String, String)) so it might be better to stick with one concept for all generic parameters.

We don't want to extend Ruby syntax. Adding new methods is safe since it could always be implemented as monkey patching and could be done conditionally, for example after you require 'mscorlib' the new methods appear. If you don't use CLR no IronRuby/CLR specific methods should be available (it currently doesn't work that way, but that's the plan).

Tomas

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Orion Edwards
Sent: Wednesday, November 26, 2008 12:38 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics

While I can certainly see the elegance of the 'of' suggestion, it can't help but to trip my "code smell" warning, because 'of' implies 'typeof', and it treats the types as method arguments.

I can't help but think that every new programmer, seeing this:

myTexture = content.load( of(Texture2D), "mytexture" )
is going to wrongly infer that it's calling this CLR method

content.Load( typeof(Texture2D), "mytexture" )
The relative lack of such counter-intuitive assumptions is IMHO one of the best things about ruby. I'd really like to see IronRuby keep this up

Perhaps it would be more clear if 'of' was 'T' ?? -  eg:

myTexture = content.load( T(Texture2D), "mytexture" )
But that doesn't really solve the 'types aren't method arguments' problem

How about this:

myTexture = content.load[Texture2D]( "mytexture" )

myTexture = content.load[Texture2D] "mytexture"
Both of these produce a syntax error in MRI, which IMHO is a good thing as it means IronRuby is not breaking any existing functionality.
MRI is never going to have to call generics, and as far as I can tell there won't be any overlaps with existing ruby syntax  (eg Proc#[], etc), so it seems safe.
It also is consistent with the existing syntax for instantiating generic classes.

The deal-breaker I guess would be how hard (or possible) this syntax is to implement with the IronRuby parser, etc.



Tomas Matousek wrote:

I'm thinking of something like:



myTexture = content.load of(Texture2D), "mytexture"



I.e. we would add Kernel#of method that takes a list of classes/modules and returns a special object representing generic parameters that binder would use for selecting the right method.



We are open for more ideas.



Tomas



-----Original Message-----

From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dudu Bai?o

Sent: Wednesday, November 26, 2008 10:49 AM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: Re: [Ironruby-core] IronRuby and XNA. Super and Generics



Thanks John!



I will do that.



Just for curiosity, what will be the syntax to call generic methods? :)





2008/11/26 John Lam (IRONRUBY) <jflam at microsoft.com><mailto:jflam at microsoft.com>:



We can't consume generic methods today. It's on the list of things to do though.



You can work around this by defining a concrete method in C# that calls the appropriate generic method and call the concrete method from IronRuby.



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] On Behalf Of Dudu Bai?o

Sent: Tuesday, November 25, 2008 6:26 PM

To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>

Subject: [Ironruby-core] IronRuby and XNA. Super and Generics



Hi guys!



Im playing with XNA trying to run the simplest xna example: To show a

SpriteBatch on screen.



After some tests I found some problems:



1- The "Microsoft::Xna::Framework::Game" expects that we implement

some methods like "Update", "Drawn" etc, and inside the method we have

to call the base class (super) actual method passing some parameters.



If I try to do this:



   def update(game_time)

     super(game_time)

   end



I get this error:



my_game.rb:23:in `update': wrong number or type of arguments for

`update' (ArgumentError)

   from Snippets.scripting:0:in `Update'

   from Microsoft.Xna.Framework.Game:0:in `Run'

   from program.rb:23:in `main'

   from :0



2- XNA uses generic functions to load the game contents. How can I

convert the code above to IronRuby?



// This is a texture we can render.

Texture2D myTexture;



protected override void LoadContent()

{

   myTexture = Content.Load<Texture2D>("mytexture");

}



Can IronRuby consume generics?



Thanks!

_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core





_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core



_______________________________________________

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:image001.jpg at 01C97267.EC66D550]




































________________________________








































_______________________________________________

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:image001.jpg at 01C97267.EC66D550]


































________________________________


































_______________________________________________

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:image001.jpg at 01C97267.EC66D550]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/a1d06577/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 8147 bytes
Desc: image001.jpg
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/a1d06577/attachment-0001.jpg>

From Jimmy.Schementi at microsoft.com  Fri Jan  9 17:49:48 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 9 Jan 2009 14:49:48 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <a880efe10901091351y7e3b744eo7ef1454602c54457@mail.gmail.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8A4@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a880efe10901091351y7e3b744eo7ef1454602c54457@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D89E6@NA-EXMSG-C116.redmond.corp.microsoft.com>

Let's let Tomas implement content.method(:load).of(Texture2D).call(?mytexture?) ... and then we can play around with the different syntax in context. Then it's pick-the-syntax-you-want =)

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Friday, January 09, 2009 1:51 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

I like Tomas's idea the best. Generics are not native to Ruby, so most people using them will likely have a C#/VB background, which means Tomas's syntax would be more familiar.

The "_of" syntax isn't bad, but forcing a ".do" or ".call" at the end isn't ideal, even if it does have a bit of a Ruby flavor.

Adding a ".of()" to the class is okay, but many classes may have generic methods even when the class itself is not a generic. (I'm thinking primarily of static and extension method classes here.)

Passing the generic types as the first parameters seems the most explicit and understandable translation to me.

~ Ryan
On Fri, Jan 9, 2009 at 3:12 PM, Jimmy Schementi <Jimmy.Schementi at microsoft.com<mailto:Jimmy.Schementi at microsoft.com>> wrote:

Here are the ideas that stand out to me:



I like Tomas's idea, since it reads like C#/VB, but adding an argument to the front urks me:



content.load of(Texture2D), "mytexture"



Shri, having the "_of" appended to a generic method name and requiring a ".do" after it is how you would work with lambdas (except you do ".call"), but since we're talking about .NET methods, not .NET delegates. So, I'd like the syntax to look more like a method call. Also, as Tomas says, mangling gets more complicated ...



content.load_of(Texture2D).call "mytexture"



How about adding an "of" method to the class/object, to put the class in a generic "mode"? The method probably shouldn't be called "of", but you get the idea. It reads different than C#, but seems the most Rubyesk without changing the arguments.



content.of(Texture2D).load "mytexture"



Thoughts? If no one likes my idea, I think Tomas's is a fine compromise.

~js

--
Ryan Riley
ryan.riley at panesofglass.org<mailto:ryan.riley at panesofglass.org>
http://panesofglass.org/
http://wizardsofsmart.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/d14aacab/attachment.html>

From Shri.Borde at microsoft.com  Fri Jan  9 18:32:32 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 9 Jan 2009 15:32:32 -0800
Subject: [Ironruby-core] Code Review: Issues with Thread#kill and raising
 exception from ensure clause
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058BA52@NA-EXMSG-C104.redmond.corp.microsoft.com>

  tfpt review "/shelveset:kill;REDMOND\sborde"

  Comment  : 
  Added more tests for Thread#kill, and fixed bugs that were exposed. Throwing an exception from the ensure clause exposes new code paths.
  
  Ruby allows Thread#kill to be completely subverted (not just deferred as an infinite loop in an ensure clause would do) by raising an exception from a ensure clause. I have not matched that behavior, and left it as a IronRuby bug for now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: kill.diff
Type: application/octet-stream
Size: 26250 bytes
Desc: kill.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/ad193ad5/attachment-0001.obj>

From Jimmy.Schementi at microsoft.com  Fri Jan  9 18:37:09 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 9 Jan 2009 15:37:09 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8A36@NA-EXMSG-C116.redmond.corp.microsoft.com>

Foo.of(Bar).new works today ? since it's about instantiating generic types ? this discussion was only about generic methods.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Friday, January 09, 2009 2:33 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

How would this look for instantiating a generic object?

my_object = Foo.method(:new).of(Bar).call

That seems strange. Perhaps we need to possibilities: the above for generic methods and the following for generic classes:

my_object = Foo.of(Bar).new
# where Foo would be defined as Foo<T> in C#

my_clone = my_object.clone
# where clone would have a C# signature of T Clone<T>()

or should that be:

my_clone = my_object.method(:clone).of(Bar).call?
# and allow my_object.clone to have an overloaded
# C# signature of object Clone()?

~Ryan
On Fri, Jan 9, 2009 at 3:45 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:

Mine has also an issue that just occurred to me. If you do:



class C

  content.load of(Texture2D), "foo"

end



"of" resolves to Module#of which would return a C<Texture2D> if C was a generic type or throws an exception.

So that's not good either. We would need a different method name for generic method constructor than for generic type. Maybe "method_of"?



As for your idea:

content.of(T).load



is looks backwards. The content is not of T? the load is. I think this would be confusing.



Until we figure out some nice clean solution that works in 100% cases, I would implement the following as the first step for generic method support:



content.method(:load).of(Texture2D).call("mytexture")



(Note, you can do the same in Ruby for regular methods: "foo".method(:center).call(100))



anything else is just a convenience and anyone could define it via standard Ruby means.



Tomas


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

From Tomas.Matousek at microsoft.com  Fri Jan  9 18:38:06 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 15:38:06 -0800
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<492DDB40.8030301@open2view.com>
	<F58FE69873E2D5459B72C347DE1582412B2216D8AD@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAE65@NA-EXMSG-C112.redmond.corp.microsoft.com>

Generic types already work:

List = List.of(Object).new

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ryan Riley
Sent: Friday, January 09, 2009 2:33 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Generic method synxtax

How would this look for instantiating a generic object?

my_object = Foo.method(:new).of(Bar).call

That seems strange. Perhaps we need to possibilities: the above for generic methods and the following for generic classes:

my_object = Foo.of(Bar).new
# where Foo would be defined as Foo<T> in C#

my_clone = my_object.clone
# where clone would have a C# signature of T Clone<T>()

or should that be:

my_clone = my_object.method(:clone).of(Bar).call?
# and allow my_object.clone to have an overloaded
# C# signature of object Clone()?

~Ryan
On Fri, Jan 9, 2009 at 3:45 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote:

Mine has also an issue that just occurred to me. If you do:



class C

  content.load of(Texture2D), "foo"

end



"of" resolves to Module#of which would return a C<Texture2D> if C was a generic type or throws an exception.

So that's not good either. We would need a different method name for generic method constructor than for generic type. Maybe "method_of"?



As for your idea:

content.of(T).load



is looks backwards. The content is not of T? the load is. I think this would be confusing.



Until we figure out some nice clean solution that works in 100% cases, I would implement the following as the first step for generic method support:



content.method(:load).of(Texture2D).call("mytexture")



(Note, you can do the same in Ruby for regular methods: "foo".method(:center).call(100))



anything else is just a convenience and anyone could define it via standard Ruby means.



Tomas


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

From lists at ruby-forum.com  Fri Jan  9 18:59:43 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Sat, 10 Jan 2009 00:59:43 +0100
Subject: [Ironruby-core] IronRuby hosting: self becomes nil
In-Reply-To: <3c0ab782f5d70a784748a4e8ad9098e8@ruby-forum.com>
References: <3c0ab782f5d70a784748a4e8ad9098e8@ruby-forum.com>
Message-ID: <011bf94e57a73d700b7756fa7df7d5f8@ruby-forum.com>

Hello,

Should I report this as IronRuby bug?

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

From Tomas.Matousek at microsoft.com  Fri Jan  9 19:07:58 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 16:07:58 -0800
Subject: [Ironruby-core] Code Review: CompositeConversions3
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>

tfpt review "/shelveset:CompositeConversions3;REDMOND\tomat"

DLR change (interpreter)

Fixes interpretation of UnaryExpresion cast with a custom method.

Ruby changes

1)
Implements composite conversions and defines default composite protocol conversions. A composite conversion is basically a combination of at least 2 protocol conversions. For example, some methods convert to an integer using "to_int" if available and if not "to_i" is tried. Other methods try "to_str" first and "to_int" then or vice versa to convert to String or Fixnum.

For example, File#new's first parameter performs to_str-to_int conversion. To declare such a parameter a library function uses a parameter of type Union<T1, T2> marked by [DefaultProtocol]:

public static RubyFile/*!*/ CreateFile(RubyClass/*!*/ self,
  [DefaultProtocol]Union<int, MutableString> descriptorOrPath, [Optional, DefaultProtocol]MutableString mode, [Optional]int permission) {

  if (descriptorOrPath.IsFixnum()) { ... } else { ... }
}

This says that default protocol for Int32 and for MutableString should be performed in the order specified by the type parameters.

2)
Some methods use CastToInteger protocol. This protocol calls to_int, similarly to CastToFixnum, but the result could be both Fixnum or Bignum. This is not a composite conversion since only one conversion is called (to_int) however the type of the result could be either Int32 or BigInteger. There are also other places where we need to pass around a union of Int32 and BigInteger. IntegerValue struct serves this purpose. A default protocol for IntegerValue is CastToInteger. An example of use is Bignum#<<:

[RubyMethod("<<")]
public static object/*!*/ LeftShift(RubyContext/*!*/ context, BigInteger/*!*/ self, [DefaultProtocol]IntegerValue other) {
  return other.IsFixnum ? LeftShift(self, other.Fixnum) : LeftShift(self, other.Bignum);
}

3)
Refactors protocol conversion classes.

4)
Fixes File#open, IO#open, IO#for_fd.
Fixes String#to_i and Kernel#Integer.
Tokenizer now returns whitespace tokens in verbatim mode.

5)
Changes format mode in runrspec to "dotted". It doesn't produce so much noise.

Tomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/48ef670d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CompositeConversions3.diff
Type: application/octet-stream
Size: 230366 bytes
Desc: CompositeConversions3.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/48ef670d/attachment-0001.obj>

From Tomas.Matousek at microsoft.com  Fri Jan  9 19:33:41 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 16:33:41 -0800
Subject: [Ironruby-core] Code Review: Issues with Thread#kill and
 raising exception from ensure clause
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD058BA52@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD058BA52@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAEC1@NA-EXMSG-C112.redmond.corp.microsoft.com>

Are any methods in RubyOps Exceptions #region (including those added by this shelveset) emitted to IL? If not they should rather be in RubyUtils class.

On the other hand, SourceUnitTree.CheckForAsyncRaiseViaThreadAbortshould should be marked as [Emitted], be in RubyOps.cs and SourceUnitTree.GenerateCheckForAsyncException should use Methods.CheckForAsyncRaiseViaThreadAbort to get the method.

Could we add a public helper that calls thread.Abort(new ThreadExitMarker()); move the private ThreadExitMarker class and IsRubyThreadExit to RubyUtils? Then we won't need to duplicate the marker class in ThreadOps?

Other than that, looks good.

Tomas

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 09, 2009 3:33 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Issues with Thread#kill and raising exception from ensure clause

  tfpt review "/shelveset:kill;REDMOND\sborde"

  Comment  : 
  Added more tests for Thread#kill, and fixed bugs that were exposed. Throwing an exception from the ensure clause exposes new code paths.
  
  Ruby allows Thread#kill to be completely subverted (not just deferred as an infinite loop in an ensure clause would do) by raising an exception from a ensure clause. I have not matched that behavior, and left it as a IronRuby bug for now.



From Tomas.Matousek at microsoft.com  Fri Jan  9 19:34:30 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 9 Jan 2009 16:34:30 -0800
Subject: [Ironruby-core] IronRuby hosting: self becomes nil
In-Reply-To: <011bf94e57a73d700b7756fa7df7d5f8@ruby-forum.com>
References: <3c0ab782f5d70a784748a4e8ad9098e8@ruby-forum.com>
	<011bf94e57a73d700b7756fa7df7d5f8@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAEC4@NA-EXMSG-C112.redmond.corp.microsoft.com>

Yes, please.

Thanks,
Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Alex 2k8
Sent: Friday, January 09, 2009 4:00 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby hosting: self becomes nil

Hello,

Should I report this as IronRuby bug?

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


From jomes at microsoft.com  Fri Jan  9 19:37:48 2009
From: jomes at microsoft.com (John Messerly)
Date: Fri, 9 Jan 2009 16:37:48 -0800
Subject: [Ironruby-core] Code Review: CompositeConversions3
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <918705E903F4714CB713D89AB5F1857D88324B699B@NA-EXMSG-C116.redmond.corp.microsoft.com>

Interpreter change looks good.

From: Tomas Matousek
Sent: Friday, January 09, 2009 4:08 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: CompositeConversions3


tfpt review "/shelveset:CompositeConversions3;REDMOND\tomat"

DLR change (interpreter)

Fixes interpretation of UnaryExpresion cast with a custom method.

Ruby changes

1)
Implements composite conversions and defines default composite protocol conversions. A composite conversion is basically a combination of at least 2 protocol conversions. For example, some methods convert to an integer using "to_int" if available and if not "to_i" is tried. Other methods try "to_str" first and "to_int" then or vice versa to convert to String or Fixnum.

For example, File#new's first parameter performs to_str-to_int conversion. To declare such a parameter a library function uses a parameter of type Union<T1, T2> marked by [DefaultProtocol]:

public static RubyFile/*!*/ CreateFile(RubyClass/*!*/ self,
  [DefaultProtocol]Union<int, MutableString> descriptorOrPath, [Optional, DefaultProtocol]MutableString mode, [Optional]int permission) {

  if (descriptorOrPath.IsFixnum()) { ... } else { ... }
}

This says that default protocol for Int32 and for MutableString should be performed in the order specified by the type parameters.

2)
Some methods use CastToInteger protocol. This protocol calls to_int, similarly to CastToFixnum, but the result could be both Fixnum or Bignum. This is not a composite conversion since only one conversion is called (to_int) however the type of the result could be either Int32 or BigInteger. There are also other places where we need to pass around a union of Int32 and BigInteger. IntegerValue struct serves this purpose. A default protocol for IntegerValue is CastToInteger. An example of use is Bignum#<<:

[RubyMethod("<<")]
public static object/*!*/ LeftShift(RubyContext/*!*/ context, BigInteger/*!*/ self, [DefaultProtocol]IntegerValue other) {
  return other.IsFixnum ? LeftShift(self, other.Fixnum) : LeftShift(self, other.Bignum);
}

3)
Refactors protocol conversion classes.

4)
Fixes File#open, IO#open, IO#for_fd.
Fixes String#to_i and Kernel#Integer.
Tokenizer now returns whitespace tokens in verbatim mode.

5)
Changes format mode in runrspec to "dotted". It doesn't produce so much noise.

Tomas


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

From Martin.Maly at microsoft.com  Fri Jan  9 20:51:02 2009
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Fri, 9 Jan 2009 17:51:02 -0800
Subject: [Ironruby-core] Code Review: CompositeConversions3
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <CEAEB698B9ADF94BB94C1D027970E6B74C4E12211E@NA-EXMSG-C102.redmond.corp.microsoft.com>

Outer ring looks good.

From: Tomas Matousek
Sent: Friday, January 09, 2009 4:08 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: CompositeConversions3


tfpt review "/shelveset:CompositeConversions3;REDMOND\tomat"

DLR change (interpreter)

Fixes interpretation of UnaryExpresion cast with a custom method.

Ruby changes

1)
Implements composite conversions and defines default composite protocol conversions. A composite conversion is basically a combination of at least 2 protocol conversions. For example, some methods convert to an integer using "to_int" if available and if not "to_i" is tried. Other methods try "to_str" first and "to_int" then or vice versa to convert to String or Fixnum.

For example, File#new's first parameter performs to_str-to_int conversion. To declare such a parameter a library function uses a parameter of type Union<T1, T2> marked by [DefaultProtocol]:

public static RubyFile/*!*/ CreateFile(RubyClass/*!*/ self,
  [DefaultProtocol]Union<int, MutableString> descriptorOrPath, [Optional, DefaultProtocol]MutableString mode, [Optional]int permission) {

  if (descriptorOrPath.IsFixnum()) { ... } else { ... }
}

This says that default protocol for Int32 and for MutableString should be performed in the order specified by the type parameters.

2)
Some methods use CastToInteger protocol. This protocol calls to_int, similarly to CastToFixnum, but the result could be both Fixnum or Bignum. This is not a composite conversion since only one conversion is called (to_int) however the type of the result could be either Int32 or BigInteger. There are also other places where we need to pass around a union of Int32 and BigInteger. IntegerValue struct serves this purpose. A default protocol for IntegerValue is CastToInteger. An example of use is Bignum#<<:

[RubyMethod("<<")]
public static object/*!*/ LeftShift(RubyContext/*!*/ context, BigInteger/*!*/ self, [DefaultProtocol]IntegerValue other) {
  return other.IsFixnum ? LeftShift(self, other.Fixnum) : LeftShift(self, other.Bignum);
}

3)
Refactors protocol conversion classes.

4)
Fixes File#open, IO#open, IO#for_fd.
Fixes String#to_i and Kernel#Integer.
Tokenizer now returns whitespace tokens in verbatim mode.

5)
Changes format mode in runrspec to "dotted". It doesn't produce so much noise.

Tomas


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

From ryan.riley at panesofglass.org  Fri Jan  9 22:30:53 2009
From: ryan.riley at panesofglass.org (Ryan Riley)
Date: Fri, 9 Jan 2009 21:30:53 -0600
Subject: [Ironruby-core] Generic method synxtax
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8A36@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <a40ebe370811251825v1ebc6304w3456d47d3bd63d96@mail.gmail.com>
	<492DE555.70003@open2view.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9A36D@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B5F9@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B248C8667@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD058B774@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8923@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DADA8@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a880efe10901091432h480e497dx5b1bbf535402ef0f@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D8A36@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <a880efe10901091930t355a1ea1t40f1d5dd3df7e40d@mail.gmail.com>

Oops! Sorry for being a bit behind!

On Fri, Jan 9, 2009 at 5:37 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

>  Foo.of(Bar).new works today ? since it's about instantiating generic
> types ? this discussion was only about generic methods.
>
>
>
> *From:* ironruby-core-bounces at rubyforge.org [mailto:
> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Ryan Riley
> *Sent:* Friday, January 09, 2009 2:33 PM
> *To:* ironruby-core at rubyforge.org
> *Subject:* Re: [Ironruby-core] Generic method synxtax
>
>
>
> How would this look for instantiating a generic object?
>
>
> my_object = Foo.method(:new).of(Bar).call
>
> That seems strange. Perhaps we need to possibilities: the above for generic
> methods and the following for generic classes:
>
> my_object = Foo.of(Bar).new
> # where Foo would be defined as Foo<T> in C#
>
> my_clone = my_object.clone
> # where clone would have a C# signature of T Clone<T>()
>
> or should that be:
>
> my_clone = my_object.method(:clone).of(Bar).call?
> # and allow my_object.clone to have an overloaded
> # C# signature of object Clone()?
>
> ~Ryan
>
> On Fri, Jan 9, 2009 at 3:45 PM, Tomas Matousek <
> Tomas.Matousek at microsoft.com> wrote:
>
> Mine has also an issue that just occurred to me. If you do:
>
>
>
> class C
>
>   content.load of(Texture2D), "foo"
>
> end
>
>
>
> "of" resolves to Module#of which would return a C<Texture2D> if C was a
> generic type or throws an exception.
>
> So that's not good either. We would need a different method name for
> generic method constructor than for generic type. Maybe "method_of"?
>
>
>
> As for your idea:
>
> content.of(T).load
>
>
>
> is looks backwards. The content is not of T? the load is. I think this
> would be confusing.
>
>
>
> Until we figure out some nice clean solution that works in 100% cases, I
> would implement the following as the first step for generic method support:
>
>
>
> content.method(:load).of(Texture2D).call("mytexture")
>
>
>
> (Note, you can do the same in Ruby for regular methods:
> "foo".method(:center).call(100))
>
>
>
> anything else is just a convenience and anyone could define it via standard
> Ruby means.
>
>
>
> Tomas
>
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Ryan Riley
ryan.riley at panesofglass.org
http://panesofglass.org/
http://wizardsofsmart.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090109/21c6754b/attachment.html>

From Shri.Borde at microsoft.com  Sat Jan 10 00:54:48 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 9 Jan 2009 21:54:48 -0800
Subject: [Ironruby-core] Code Review: Issues with Thread#kill and
 raising exception from ensure clause
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAEC1@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD058BA52@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DAEC1@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058BB3A@NA-EXMSG-C104.redmond.corp.microsoft.com>

Inline...

-----Original Message-----
From: Tomas Matousek 
Sent: Friday, January 09, 2009 4:34 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Issues with Thread#kill and raising exception from ensure clause

Are any methods in RubyOps Exceptions #region (including those added by this shelveset) emitted to IL? If not they should rather be in RubyUtils class.
[Shri Borde] They are not emitted to IL. Moved it to RubyUtils...

On the other hand, SourceUnitTree.CheckForAsyncRaiseViaThreadAbortshould should be marked as [Emitted], be in RubyOps.cs and SourceUnitTree.GenerateCheckForAsyncException should use Methods.CheckForAsyncRaiseViaThreadAbort to get the method.
[Shri Borde] Done

Could we add a public helper that calls thread.Abort(new ThreadExitMarker()); move the private ThreadExitMarker class and IsRubyThreadExit to RubyUtils? Then we won't need to duplicate the marker class in ThreadOps?
[Shri Borde] Its not duplicated. I already moved it out of ThreadOps.

Other than that, looks good.

Tomas

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 09, 2009 3:33 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Issues with Thread#kill and raising exception from ensure clause

  tfpt review "/shelveset:kill;REDMOND\sborde"

  Comment  : 
  Added more tests for Thread#kill, and fixed bugs that were exposed. Throwing an exception from the ensure clause exposes new code paths.
  
  Ruby allows Thread#kill to be completely subverted (not just deferred as an infinite loop in an ensure clause would do) by raising an exception from a ensure clause. I have not matched that behavior, and left it as a IronRuby bug for now.



From jdeville at microsoft.com  Sat Jan 10 03:47:49 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sat, 10 Jan 2009 00:47:49 -0800
Subject: [Ironruby-core] Git changes
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>

I've gone through and renamed files in Git. I've also rm'd the extra files. The renames will probably break builds on Mono, but I don't have the head of Mono built. I'll push today's changes tomorrow.



JD

From lists at ruby-forum.com  Sat Jan 10 04:24:59 2009
From: lists at ruby-forum.com (Alex 2k8)
Date: Sat, 10 Jan 2009 10:24:59 +0100
Subject: [Ironruby-core] IronRuby hosting: self becomes nil
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAEC4@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <3c0ab782f5d70a784748a4e8ad9098e8@ruby-forum.com>
	<011bf94e57a73d700b7756fa7df7d5f8@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B249DAEC4@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <2d7486eb119fcadc545ece60160e9aa8@ruby-forum.com>

Submitted as Bug # 23512.

http://rubyforge.org/tracker/index.php?func=detail&aid=23512&group_id=4359&atid=16798

BTW, Tomas, thank you for your responses!

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

From suppakilla at gmail.com  Sat Jan 10 08:06:28 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Sat, 10 Jan 2009 14:06:28 +0100
Subject: [Ironruby-core] Issues with Method#to_proc
Message-ID: <3bf20550901100506p4a10236co47220610b2314227@mail.gmail.com>

Hello,

Today I was writing some code which uses Method#to_proc but I've
encountered a few issues. The following line throws a
NotImplementedException:

proc = 0.method(:to_s).to_proc

I took a look at the source code of the ToProc method of MethodOps and
there's a comment which states that creating Procs out of CLR methods
is basically not yet supported. OK, so it seems reasonable given that,
as far as I understand, built-in library methods actually are CLR
methods internally.

Now, what if I try to create procs out of methods defined in ruby?

class Fixnum
    alias :__to_s :to_s
    def to_s
        self.__to_s
    end
end

proc = 0.method(:to_s).to_proc

The original Fixnum#to_s has been aliased and Fixnum#to_s now responds
to a method defined at runtime in ruby, but then I get the following
InvalidCastException:

C:\Sviluppo\ironruby\SVN\trunk\src\IronRuby.Libraries\Builtins\MethodOps.cs:63:in
`to_proc': Unable to cast object of type
'System.Func`3[System.Object,IronRuby.Builtins.Proc,System.Object]' to
type 'IronRuby.Runtime.Calls.BlockCallTarget0'.
(System::InvalidCastException)
        from :0

This exception is raised in the Create method of BlockDispatcher.

Should I file a bug? Or is this totally expected to happen because
Method#to_proc is still incomplete / in its early stages (if so, the
reported issue could fall into this bug report http://is.gd/fazo)?

-- 
Daniele Alessandri
http://www.clorophilla.net/blog/

From bacondarwin at googlemail.com  Sat Jan 10 08:52:12 2009
From: bacondarwin at googlemail.com (Pete Bacon Darwin)
Date: Sat, 10 Jan 2009 13:52:12 -0000
Subject: [Ironruby-core] Git changes
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <013f01c9732a$a4832a90$ed897fb0$@com>

Just in case anyone is getting stuck with this too:
- You need rake 0.8.3 to compile IronRuby.  (It doesn't like the
parameterized tasks in git.rake with 0.8.1.)
- Also gems.rubyforge.org is no longer compatible with gem 1.1 so you have
to manually upgrade gem before you can do gem update rake.
Phew!

Now my rake compile is failing on building dlr_core:
- It can't find the file
"merlin\main\languages\ruby\src\microsoft.scripting.core"
Since it doesn't exist...
Trace from rake is below.
Pete

D:\dev\ruby\ironruby\git_ironruby\merlin\main\Languages\Ruby>rake compile
--trace
(in D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby)
** Invoke compile (first_time)
** Invoke happy (first_time)
** Execute happy
** Invoke clean_build (first_time)
** Invoke happy
** Execute clean_build
** Invoke compile_dlr (first_time)
** Invoke compile_extension_attributes (first_time)
** Invoke clean_build
** Execute compile_extension_attributes
----------------------------------------------------------------------------
---
dlr_core
----------------------------------------------------------------------------
---
rake aborted!
No such file or directory -
d:\dev\ruby\ironruby\git_ironruby\merlin\main\languages\ruby\src\micr
./context.rb:532:in `chdir'
./context.rb:532:in `compile'
D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/compile.ra
ke:28
./context.rb:712:in `instance_eval'
./context.rb:712:in `source_context'
D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/compile.ra
ke:27
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
`standard_exception_handling'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
`standard_exception_handling'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
d:/ruby/bin/rake:19:in `load'
d:/ruby/bin/rake:19



From Tomas.Matousek at microsoft.com  Sat Jan 10 12:24:14 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 10 Jan 2009 09:24:14 -0800
Subject: [Ironruby-core] Issues with Method#to_proc
In-Reply-To: <3bf20550901100506p4a10236co47220610b2314227@mail.gmail.com>
References: <3bf20550901100506p4a10236co47220610b2314227@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DAF4D@NA-EXMSG-C112.redmond.corp.microsoft.com>

Could you please add your comment to bug #20297?

Thanks,
Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri
Sent: Saturday, January 10, 2009 5:06 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Issues with Method#to_proc

Hello,

Today I was writing some code which uses Method#to_proc but I've
encountered a few issues. The following line throws a
NotImplementedException:

proc = 0.method(:to_s).to_proc

I took a look at the source code of the ToProc method of MethodOps and
there's a comment which states that creating Procs out of CLR methods
is basically not yet supported. OK, so it seems reasonable given that,
as far as I understand, built-in library methods actually are CLR
methods internally.

Now, what if I try to create procs out of methods defined in ruby?

class Fixnum
    alias :__to_s :to_s
    def to_s
        self.__to_s
    end
end

proc = 0.method(:to_s).to_proc

The original Fixnum#to_s has been aliased and Fixnum#to_s now responds
to a method defined at runtime in ruby, but then I get the following
InvalidCastException:

C:\Sviluppo\ironruby\SVN\trunk\src\IronRuby.Libraries\Builtins\MethodOps.cs:63:in
`to_proc': Unable to cast object of type
'System.Func`3[System.Object,IronRuby.Builtins.Proc,System.Object]' to
type 'IronRuby.Runtime.Calls.BlockCallTarget0'.
(System::InvalidCastException)
        from :0

This exception is raised in the Create method of BlockDispatcher.

Should I file a bug? Or is this totally expected to happen because
Method#to_proc is still incomplete / in its early stages (if so, the
reported issue could fall into this bug report http://is.gd/fazo)?

--
Daniele Alessandri
http://www.clorophilla.net/blog/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From jdeville at microsoft.com  Sat Jan 10 14:52:41 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sat, 10 Jan 2009 11:52:41 -0800
Subject: [Ironruby-core] Git changes
In-Reply-To: <013f01c9732a$a4832a90$ed897fb0$@com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>,
	<013f01c9732a$a4832a90$ed897fb0$@com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>

Pete,

Do you have MERLIN_ROOT set in your env vars? It needs to be set to D:\dev\ruby\ironruby\git_ironruby\Merlin\Main

This is going to be a requirement until we close the SVN repo and start pulling out the supporting code.

JD
________________________________________
From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of Pete Bacon Darwin [bacondarwin at googlemail.com]
Sent: Saturday, January 10, 2009 5:52 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Git changes

Just in case anyone is getting stuck with this too:
- You need rake 0.8.3 to compile IronRuby.  (It doesn't like the
parameterized tasks in git.rake with 0.8.1.)
- Also gems.rubyforge.org is no longer compatible with gem 1.1 so you have
to manually upgrade gem before you can do gem update rake.
Phew!

Now my rake compile is failing on building dlr_core:
- It can't find the file
"merlin\main\languages\ruby\src\microsoft.scripting.core"
Since it doesn't exist...
Trace from rake is below.
Pete

D:\dev\ruby\ironruby\git_ironruby\merlin\main\Languages\Ruby>rake compile
--trace
(in D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby)
** Invoke compile (first_time)
** Invoke happy (first_time)
** Execute happy
** Invoke clean_build (first_time)
** Invoke happy
** Execute clean_build
** Invoke compile_dlr (first_time)
** Invoke compile_extension_attributes (first_time)
** Invoke clean_build
** Execute compile_extension_attributes
----------------------------------------------------------------------------
---
dlr_core
----------------------------------------------------------------------------
---
rake aborted!
No such file or directory -
d:\dev\ruby\ironruby\git_ironruby\merlin\main\languages\ruby\src\micr
./context.rb:532:in `chdir'
./context.rb:532:in `compile'
D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/compile.ra
ke:28
./context.rb:712:in `instance_eval'
./context.rb:712:in `source_context'
D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/compile.ra
ke:27
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
`invoke_prerequisites'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
`invoke_with_call_chain'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
`standard_exception_handling'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
`standard_exception_handling'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
d:/ruby/bin/rake:19:in `load'
d:/ruby/bin/rake:19


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


From michael.letterle at gmail.com  Sat Jan 10 22:19:12 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Sat, 10 Jan 2009 22:19:12 -0500
Subject: [Ironruby-core] Git changes
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <AQHJcwBJkkPA1BSdjU6Hz2kOKFGbXA==>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <ef5222770901101919l716d2f13m90a2b00d2ba2e0f6@mail.gmail.com>

linux/mono branch updated with new push:
http://github.com/TheProkrammer/ironruby/tree/linux

I also fixed the issue with not being able to run an rb file from the
command line (simple fix really).

Note too, that for some strange reason the REPL doesn't output the result of
the current line, haven't investigated yet, but it's not a show stopper.

TestRunner isn't compiled either due to some extension method weirdness.
I'm going to get specs running.

On Sat, Jan 10, 2009 at 3:47 AM, Jim Deville <jdeville at microsoft.com> wrote:

> I've gone through and renamed files in Git. I've also rm'd the extra files.
> The renames will probably break builds on Mono, but I don't have the head of
> Mono built. I'll push today's changes tomorrow.
>
>
>
> JD
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090110/ef7cd9ca/attachment.html>

From bacondarwin at googlemail.com  Sun Jan 11 03:47:46 2009
From: bacondarwin at googlemail.com (Pete Bacon Darwin)
Date: Sun, 11 Jan 2009 08:47:46 -0000
Subject: [Ironruby-core] Git changes
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>,
	<013f01c9732a$a4832a90$ed897fb0$@com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <015d01c973c9$472d9480$d588bd80$@com>

Oops sorry.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Saturday,10 January 10, 2009 19:53
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Git changes

Pete,

Do you have MERLIN_ROOT set in your env vars? It needs to be set to
D:\dev\ruby\ironruby\git_ironruby\Merlin\Main

This is going to be a requirement until we close the SVN repo and start
pulling out the supporting code.

JD


From jdeville at microsoft.com  Sun Jan 11 05:19:34 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sun, 11 Jan 2009 02:19:34 -0800
Subject: [Ironruby-core] Git changes
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B6@NA-EXMSG-C112.redmond.corp.microsoft.com>

No prob

JD

-----Original Message-----
From: Pete Bacon Darwin <bacondarwin at googlemail.com>
Sent: January 11, 2009 12:58 AM
To: ironruby-core at rubyforge.org <ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] Git changes


Oops sorry.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Saturday,10 January 10, 2009 19:53
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Git changes

Pete,

Do you have MERLIN_ROOT set in your env vars? It needs to be set to
D:\dev\ruby\ironruby\git_ironruby\Merlin\Main

This is going to be a requirement until we close the SVN repo and start
pulling out the supporting code.

JD

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


From lists at ruby-forum.com  Sun Jan 11 11:11:50 2009
From: lists at ruby-forum.com (Carl Graff)
Date: Sun, 11 Jan 2009 17:11:50 +0100
Subject: [Ironruby-core] Active Record Or LINQ with IronRuby...?
In-Reply-To: <372109E149E8084D8E6C7D9CFD82E0632D91A03805@NA-EXMSG-C115.redmond.corp.microsoft.com>
References: <8d1cdd550f1874b6f6b2891c6effe330@ruby-forum.com>
	<BLU126-DS1592BE869C38E9321BA72CE0A0@phx.gbl>
	<79788c05deb66febf9323bedc6193974@ruby-forum.com>
	<372109E149E8084D8E6C7D9CFD82E0632D91A03805@NA-EXMSG-C115.redmond.corp.microsoft.com>
Message-ID: <b54eac52ebbf4fe6b102e7e873466f62@ruby-forum.com>

John Lam (DLR) wrote:
> Softmind Technology:
> 
>> I still have my doubts about smooth functioning of SQL Server 2005 with
>> Active Record.
>>
>> I have heard several complains about SQL Driver 2005 not efficient as
>> it should be. MySql/Sqlite etc are working great with Active Record.
> 
> The SQL Server team is investigating providing support for SQL Server 
> via ActiveRecord and other ORMs. To be clear, *they* will be driving 
> this once we get ActiveRecord to the point where they can start 
> investigating how they will provide support for SQL Server.
> 
> Thanks,
> -John

Hi,

I have been using Ruby to integrate with large complex legacy SQLServer 
databases for over 2 years now and it isn't that hard.

1. Use Dr Nic's compositekeys http://compositekeys.rubyforge.org/
2. Use Rahoul Baruah's sql_server.rb for stored procedure support

Now that I have dabbled with IronPython and LInQ I too am curious about 
the best approach for data_access/ORM with so many possibilities opening 
up.


Linq2ActiveRecord provider
  or
Add XML and collection mapping to ActiveRecord
   (I think XML can be fudged with a couple of pseudo tables related)
  or
List Comprehension or Generators

If a Linq2ActiveRecord provider is possible that might be the best of 
all worlds (if performance doesn't rear it's ugly head). Dr. Nic also 
has something called Magic Modes to reverse engineer an entire database 
into ActiveRecord models and other cool stuff.

There must be some synergy possible here.

Best,
    Carl












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

From jirapong.nanta at gmail.com  Sun Jan 11 13:21:36 2009
From: jirapong.nanta at gmail.com (jirapong.nanta at gmail.com)
Date: Mon, 12 Jan 2009 01:21:36 +0700
Subject: [Ironruby-core] Git changes
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>,
	<013f01c9732a$a4832a90$ed897fb0$@com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <6B9780D5-FF69-4986-8B84-BC8A62E7BBED@gmail.com>

Hi all,
	on windows. I found that rake-0.7.3 (installed on  Ruby One-click   
installer) give following error.  should it be require like the  
"pathname2"?

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>rake compile
(in C:/dotNET/ironruby/Merlin/Main/Languages/Ruby)
rake aborted!
wrong number of arguments (2 for 1)
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1944:in  
`raw_load_rakefile'
(See full trace by running task with --trace)

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>gem update rake
Updating installed gems
Updating rake
Successfully installed rake-0.8.3
Gems updated: rake

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>rake compile
(in C:/dotNET/ironruby/Merlin/Main/Languages/Ruby)
c:\dotnet\ironruby\merlin\main\languages\ruby
c:\dotnet\ironruby\merlin\main\languages\ruby
-------------------------------------------------------------------------------
dlr_core
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
dlr_core
-------------------------------------------------------------------------------

                                                                                            
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
, 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3;0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0-h:mm:ss tt:000AMPMM/d/yyyy

On Jan 11, 2009, at 2:52 AM, Jim Deville wrote:

> Pete,
>
> Do you have MERLIN_ROOT set in your env vars? It needs to be set to  
> D:\dev\ruby\ironruby\git_ironruby\Merlin\Main
>
> This is going to be a requirement until we close the SVN repo and  
> start pulling out the supporting code.
>
> JD
> ________________________________________
> From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org 
> ] On Behalf Of Pete Bacon Darwin [bacondarwin at googlemail.com]
> Sent: Saturday, January 10, 2009 5:52 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Git changes
>
> Just in case anyone is getting stuck with this too:
> - You need rake 0.8.3 to compile IronRuby.  (It doesn't like the
> parameterized tasks in git.rake with 0.8.1.)
> - Also gems.rubyforge.org is no longer compatible with gem 1.1 so  
> you have
> to manually upgrade gem before you can do gem update rake.
> Phew!
>
> Now my rake compile is failing on building dlr_core:
> - It can't find the file
> "merlin\main\languages\ruby\src\microsoft.scripting.core"
> Since it doesn't exist...
> Trace from rake is below.
> Pete
>
> D:\dev\ruby\ironruby\git_ironruby\merlin\main\Languages\Ruby>rake  
> compile
> --trace
> (in D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby)
> ** Invoke compile (first_time)
> ** Invoke happy (first_time)
> ** Execute happy
> ** Invoke clean_build (first_time)
> ** Invoke happy
> ** Execute clean_build
> ** Invoke compile_dlr (first_time)
> ** Invoke compile_extension_attributes (first_time)
> ** Invoke clean_build
> ** Execute compile_extension_attributes
> ----------------------------------------------------------------------------
> ---
> dlr_core
> ----------------------------------------------------------------------------
> ---
> rake aborted!
> No such file or directory -
> d:\dev\ruby\ironruby\git_ironruby\merlin\main\languages\ruby\src\micr
> ./context.rb:532:in `chdir'
> ./context.rb:532:in `compile'
> D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/ 
> compile.ra
> ke:28
> ./context.rb:712:in `instance_eval'
> ./context.rb:712:in `source_context'
> D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/ 
> compile.ra
> ke:27
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in  
> `invoke_task'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
> `standard_exception_handling'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
> `standard_exception_handling'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
> d:/ruby/bin/rake:19:in `load'
> d:/ruby/bin/rake:19
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From jdeville at microsoft.com  Sun Jan 11 19:49:20 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sun, 11 Jan 2009 16:49:20 -0800
Subject: [Ironruby-core] Git changes
In-Reply-To: <6B9780D5-FF69-4986-8B84-BC8A62E7BBED@gmail.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B4@NA-EXMSG-C112.redmond.corp.microsoft.com>,
	<013f01c9732a$a4832a90$ed897fb0$@com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB55622B5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<6B9780D5-FF69-4986-8B84-BC8A62E7BBED@gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB57606D0@NA-EXMSG-C112.redmond.corp.microsoft.com>

Rake happy is supposed to require rake 0.8.3. Unfortunately, that won't work because rake is already running. I'm looking into different solutions for this and I'll try to find something that gives a better error for rake version mismatch.

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of jirapong.nanta at gmail.com
Sent: Sunday, January 11, 2009 10:22 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Git changes

Hi all,
	on windows. I found that rake-0.7.3 (installed on  Ruby One-click   
installer) give following error.  should it be require like the  
"pathname2"?

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>rake compile
(in C:/dotNET/ironruby/Merlin/Main/Languages/Ruby)
rake aborted!
wrong number of arguments (2 for 1)
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1944:in  
`raw_load_rakefile'
(See full trace by running task with --trace)

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>gem update rake
Updating installed gems
Updating rake
Successfully installed rake-0.8.3
Gems updated: rake

C:\dotNET\ironruby\Merlin\Main\Languages\Ruby>rake compile
(in C:/dotNET/ironruby/Merlin/Main/Languages/Ruby)
c:\dotnet\ironruby\merlin\main\languages\ruby
c:\dotnet\ironruby\merlin\main\languages\ruby
-------------------------------------------------------------------------------
dlr_core
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
dlr_core
-------------------------------------------------------------------------------

                                                                                            
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
, 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
3;0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
0-h:mm:ss tt:000AM
On Jan 11, 2009, at 2:52 AM, Jim Deville wrote:

> Pete,
>
> Do you have MERLIN_ROOT set in your env vars? It needs to be set to  
> D:\dev\ruby\ironruby\git_ironruby\Merlin\Main
>
> This is going to be a requirement until we close the SVN repo and  
> start pulling out the supporting code.
>
> JD
> ________________________________________
> From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org 
> ] On Behalf Of Pete Bacon Darwin [bacondarwin at googlemail.com]
> Sent: Saturday, January 10, 2009 5:52 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Git changes
>
> Just in case anyone is getting stuck with this too:
> - You need rake 0.8.3 to compile IronRuby.  (It doesn't like the
> parameterized tasks in git.rake with 0.8.1.)
> - Also gems.rubyforge.org is no longer compatible with gem 1.1 so  
> you have
> to manually upgrade gem before you can do gem update rake.
> Phew!
>
> Now my rake compile is failing on building dlr_core:
> - It can't find the file
> "merlin\main\languages\ruby\src\microsoft.scripting.core"
> Since it doesn't exist...
> Trace from rake is below.
> Pete
>
> D:\dev\ruby\ironruby\git_ironruby\merlin\main\Languages\Ruby>rake  
> compile
> --trace
> (in D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby)
> ** Invoke compile (first_time)
> ** Invoke happy (first_time)
> ** Execute happy
> ** Invoke clean_build (first_time)
> ** Invoke happy
> ** Execute clean_build
> ** Invoke compile_dlr (first_time)
> ** Invoke compile_extension_attributes (first_time)
> ** Invoke clean_build
> ** Execute compile_extension_attributes
> ----------------------------------------------------------------------------
> ---
> dlr_core
> ----------------------------------------------------------------------------
> ---
> rake aborted!
> No such file or directory -
> d:\dev\ruby\ironruby\git_ironruby\merlin\main\languages\ruby\src\micr
> ./context.rb:532:in `chdir'
> ./context.rb:532:in `compile'
> D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/ 
> compile.ra
> ke:28
> ./context.rb:712:in `instance_eval'
> ./context.rb:712:in `source_context'
> D:/dev/ruby/ironruby/git_ironruby/merlin/main/Languages/Ruby/rake/ 
> compile.ra
> ke:27
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in
> `invoke_prerequisites'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/1.8/monitor.rb:238:in `synchronize'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in
> `invoke_with_call_chain'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in  
> `invoke_task'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
> `standard_exception_handling'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in  
> `top_level'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in
> `standard_exception_handling'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
> d:/ruby/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
> d:/ruby/bin/rake:19:in `load'
> d:/ruby/bin/rake:19
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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


From lists at ruby-forum.com  Sun Jan 11 23:14:49 2009
From: lists at ruby-forum.com (Timothy Moriarty)
Date: Mon, 12 Jan 2009 05:14:49 +0100
Subject: [Ironruby-core] General setup questions
Message-ID: <34b3dfcc2265d06b36d85ff036841503@ruby-forum.com>

Hello all,

I am venturing into the wide world of Ruby and IronRuby.  I have the
IronRuby source code setup and building thanks to Ben Hall and some
clarifications from this forum.  I am building via Visual Studio.
Currently, I am able to do some .Net interop.  Right now, I am a little
confused on how or if Ruby interacts with IronRuby.  Do I need to
install Ruby in a specific location?  Are there any settings I need to
set?  And if so which ones and where?  And finally, I want to verify
whether there are issues with Windows Ruby and Ruby install via cygwin?

Thanks,

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

From colinjack at hotmail.com  Mon Jan 12 06:16:50 2009
From: colinjack at hotmail.com (Colin Jack)
Date: Mon, 12 Jan 2009 11:16:50 +0000
Subject: [Ironruby-core] ETA for Visual Studio Support
Message-ID: <BLU140-W49A78F8FD25AA345663C5CABD80@phx.gbl>


Hi,

I was wondering whether there is an ETA for IronRuby being inside Visual Studio (with, for example, code highlighting and/or intellisense)?

Thanks,

Colin Jack

_________________________________________________________________
Are you a PC?? Upload your PC story and show the world
http://clk.atdmt.com/UKM/go/122465942/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090112/346afe34/attachment.html>

From ben2004uk at googlemail.com  Mon Jan 12 06:30:27 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Mon, 12 Jan 2009 11:30:27 +0000
Subject: [Ironruby-core] Loading Assemblies
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8903C@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <a04554c00812091014y1bcaee9did573e09e91261bc@mail.gmail.com>
	<4a68b8cf0812091145g3326132dr8cabb095f1239b2b@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B2287D717@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a04554c00812100112x57b17105w93cae38547b4dca4@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED152564BCB4EA@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<a04554c00901050251v39842c21u118561c79c9eabb1@mail.gmail.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8903C@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <a04554c00901120330s7f813383x50afe825a40727d@mail.gmail.com>

Hi Curt,

I finally got this working. Sadly, looking into the AssemblyResolve
event within IronRuby always caused a stackoverflow, certain
assemblies would keep attempting to load themselves. I was using
AssemblyResolve and Assembly.LoadFrom and LoadPath, but nothing
helped.

Last night, I looked into the AssemblyResolve event from within
RubyContext and everything works just as expected. No errors, no stack
overflows.

I then used the GetSearchPaths() methods as possible locations to load
assemblies from, this means I can add paths from IronRuby to use when
loading assemblies via the $: variable. Appears to work well - bit
annoying I can't submit the patch :P


Thanks

Ben


On Mon, Jan 5, 2009 at 9:22 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
> The IronPython assembly resolver is in PythonContext.cs.  It's definitely worth reviewing.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Monday, January 05, 2009 2:51 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Loading Assemblies
>
> I'm back in the office so decided to give this another go.  The
> problem is, it appears to keep attempting to load a particular
> assembly, resulting in a stackoverflowexception. The method
> Assembly.load_from(path) never appears to return.
>
> I've tried to put a (if already saw then don't load) but I get an
> error "Expected System.Reflection.Assembly, got System.Dynamic.Null"
> This is because i do return nil, but i'm sure that's what I did in C#.
>
> This works in IronPython, but I can't find the code where its
> implemented within the codebase :(
>
> Anyone for any ideas on this?
>
> Thanks
>
> Ben
>
> On Wed, Dec 10, 2008 at 3:30 PM, Curt Hagenlocher <curth at microsoft.com> wrote:
>> CurrentDomain is a static method, not a class -- so you want
>> System::AppDomain.current_domain
>>
>> The AssemblyResolve event comes with its own set of odd side effects that may bite, but it is how IronPython deals with the issue.
>>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ben Hall
>> Sent: Wednesday, December 10, 2008 1:12 AM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] Loading Assemblies
>>
>> Thanks for the responses.
>>
>> Tomas is right, the appdomain didn't work (plus, it feels as dirty as
>> copying all the assemblies).
>>
>> I wanted to hook into the AssemblyResolve event on the AppDomain,
>> however it appears as if I don't have access to the appdomain!  When I
>> try System::AppDomain::CurrentDomain.methods, I get a NameError again.
>> Disappointing :(
>>
>> I'll see if I can come up with some hacky way, its a shame that I
>> can't manualy load in all the assemblies and you attempt to load them
>> from the AppDomain first (then I would have a require 'sdk.rb' file
>> with all the dependencies loaded in order)
>>
>>
>> Thanks
>>
>> Ben
>>
>> On Tue, Dec 9, 2008 at 9:46 PM, Tomas Matousek
>> <Tomas.Matousek at microsoft.com> wrote:
>>> No. You need to set it in App.config. But I think the probe path could only be a subdirectory of the app. That means a subdirectory of a path where ir.exe is.
>>>
>>> We are working on improving assembly loading for IronRuby.
>>>
>>> Tomas
>>>
>>> -----Original Message-----
>>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
>>> Sent: Tuesday, December 09, 2008 11:46 AM
>>> To: ironruby-core at rubyforge.org
>>> Subject: Re: [Ironruby-core] Loading Assemblies
>>>
>>>> require 'C:\Program Files\SDK\a.dll'
>>>> require 'C:\Program Files\SDK\b.dll'
>>>> require 'C:\Program Files\SDK\c.dll'
>>>
>>> Never tried that with IronRuby, but would the following work ?
>>>
>>> $LOAD_PATH << 'C:\Program Files\SDK\'
>>>
>>> -- Thibaut
>>>
>>>>
>>>> B has a dependency on a.  a loads file, but when loading b.dll an
>>>> exception is thrown within LoadTypesFromAssembly because it cannot
>>>> find a.dll.
>>>>
>>>> This is a serious problem, without copying all the assemblies into my
>>>> IronRuby directory I'm not sure how to load the types and use our SDK?
>>>> Installing into the GAC isn't an option.
>>>>
>>>> Please help!
>>>>
>>>> Thanks
>>>>
>>>> Ben
>>>> _______________________________________________
>>>> Ironruby-core mailing list
>>>> Ironruby-core at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From michael.letterle at gmail.com  Mon Jan 12 09:26:22 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Mon, 12 Jan 2009 09:26:22 -0500
Subject: [Ironruby-core] General setup questions
In-Reply-To: <34b3dfcc2265d06b36d85ff036841503@ruby-forum.com>
References: <34b3dfcc2265d06b36d85ff036841503@ruby-forum.com>
Message-ID: <ef5222770901120626p5af9ba89i864b8a7887192dec@mail.gmail.com>

Tim,

IronRuby itself is (or will be) a complete ruby implementation.  You do not
need to have CRuby installed.  You can use an existing ruby installation to
build IronRuby using rake, as you are building via Visual Studio you do not
require this.

As for the last part, I'm not sure what issues you are referring to, I do
most of my day to day ruby via cygwin, I also have win32 Ruby (via the
one-click installer) for testing the rakefile for IronRuby..

On Sun, Jan 11, 2009 at 11:14 PM, Timothy Moriarty <lists at ruby-forum.com>wrote:

> Hello all,
>
> I am venturing into the wide world of Ruby and IronRuby.  I have the
> IronRuby source code setup and building thanks to Ben Hall and some
> clarifications from this forum.  I am building via Visual Studio.
> Currently, I am able to do some .Net interop.  Right now, I am a little
> confused on how or if Ruby interacts with IronRuby.  Do I need to
> install Ruby in a specific location?  Are there any settings I need to
> set?  And if so which ones and where?  And finally, I want to verify
> whether there are issues with Windows Ruby and Ruby install via cygwin?
>
> Thanks,
>
> Tim
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090112/a60d73d9/attachment-0001.html>

From charles.nutter at sun.com  Mon Jan 12 10:54:49 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 12 Jan 2009 09:54:49 -0600
Subject: [Ironruby-core] Behavior for Thread.critical=
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD049B86E@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4964AA2C.6080504@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049B86E@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <496B67C9.4040806@sun.com>

I missed you saying we should nail it first...I already responded on 
ruby-core.

But I think I agree with everything except for a couple details:

* I think Thread.stop should release the lock as it does now. That's a 
pretty minor expectation, and since it's already there (and I know at 
least one library depends on it) it should remain.
* I'm dubious about the lock being reentrant. In JRuby I've implemented 
it using a ReentrantLock, which should count up and count down, but it's 
not necessarily a requirement. However I think it would be bad if a 
thread could block by setting critical=true when it's already critical.
* I think setting critical=false should only release the lock iff it is 
held by the current thread, and do nothing otherwise.

I also agree that a thread terminating while critical is undefined 
behavior. But I think most of these questions could be answered by 
treating critical= as a globally-shared reentrant mutex.

Thoughts?

Shri Borde wrote:
> I asked ruby-core whether descheduling other threads is by spec, but no one other than you replied. Any suggestions on how to nudge others to consider it? If you want to reply to that thread and provide JRuby's vote of confidence for the idea, that might help.
> 
> We should nail the complete behavior before taking it to ruby-core. I have written up a draft at http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx. Please take a look and comment on whether it works for JRuby. We can move it to some wiki if we need to iterate on it...

From Shri.Borde at microsoft.com  Mon Jan 12 13:08:06 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 12 Jan 2009 10:08:06 -0800
Subject: [Ironruby-core] Behavior for Thread.critical=
In-Reply-To: <496B67C9.4040806@sun.com>
References: <710DF26F214D2B4BB94287123FFE980A2DCFCDFD50@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AC8820F@NA-EXMSG-C118.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B246C6EA5@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB0BF@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4963A89D.80206@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD02CB8A6@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4964AA2C.6080504@sun.com>
	<710DF26F214D2B4BB94287123FFE980A2DD049B86E@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<496B67C9.4040806@sun.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058BDEB@NA-EXMSG-C104.redmond.corp.microsoft.com>

Thanks for continuing the thread on ruby-core. Let's see how it goes.


There are couple of minor issues with Thread.stop releasing the lock:
* The code will be hard to read as most people probably don't realize that Kernel#stop releases the lock.
* Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop.
* If the programmer wants to release the lock before stopping the thread, its trivial for the programmer to call Thread.critical=false
It's mostly a question of aesthetics and simplicity. The more Thread.critical= can be locked down, the more understandable it will be. But none of these are deal breakers, so I don't feel too strongly.


About reentrancy, I am proposing that it *not* be reentrant (unless an implementation choses to support that behavior). So I think we are on the same page. Reentrancy would normally have been a good thing, but since it looks like an assignment, it would read very weirdly in the case below.
  Thread.critical=true
  Thread.critical=true # if Thread.critical= was reentrant, this would increment the counter to 2
  Thread.critical=false
  puts Thread.critical # would be weird if this printed true
  Thread.critical=false


Allowing an arbitraty thread to do Thread.critical=false has the same issue as reentrancy. If Thread.critical stayed true after some thread did Thread.critical=false, it would be very misleading. Since the thread cannot actually set Thread.critical to false, it should be an error.


About thread terminating while critical is undefined, some implementations may be able to know if the dying thread still holds the lock, but some may not. Especially in the hosted case where some program is using Ruby as a scripting engine, the hosting app may have created the thread and run some Ruby snippet on it which entered the global critical section, but forgot to leave it. In that case, it would be too burdensome to require that the Ruby implementation deal with this case. Hence, the proposal of leaving this undefined.

Thanks,
Shri


-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Monday, January 12, 2009 7:55 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Behavior for Thread.critical=

I missed you saying we should nail it first...I already responded on
ruby-core.

But I think I agree with everything except for a couple details:

* I think Thread.stop should release the lock as it does now. That's a
pretty minor expectation, and since it's already there (and I know at
least one library depends on it) it should remain.
[Shri Borde] There are couple of issues with allowing this:
Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop.
If the programmer wants to release the lock before

* I'm dubious about the lock being reentrant. In JRuby I've implemented
it using a ReentrantLock, which should count up and count down, but it's
not necessarily a requirement. However I think it would be bad if a
thread could block by setting critical=true when it's already critical.
* I think setting critical=false should only release the lock iff it is
held by the current thread, and do nothing otherwise.

I also agree that a thread terminating while critical is undefined
behavior. But I think most of these questions could be answered by
treating critical= as a globally-shared reentrant mutex.

Thoughts?

Shri Borde wrote:
> I asked ruby-core whether descheduling other threads is by spec, but no one other than you replied. Any suggestions on how to nudge others to consider it? If you want to reply to that thread and provide JRuby's vote of confidence for the idea, that might help.
>
> We should nail the complete behavior before taking it to ruby-core. I have written up a draft at http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx. Please take a look and comment on whether it works for JRuby. We can move it to some wiki if we need to iterate on it...
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From lists at ruby-forum.com  Mon Jan 12 14:48:53 2009
From: lists at ruby-forum.com (Timothy Moriarty)
Date: Mon, 12 Jan 2009 20:48:53 +0100
Subject: [Ironruby-core] General setup questions
In-Reply-To: <ef5222770901120626p5af9ba89i864b8a7887192dec@mail.gmail.com>
References: <34b3dfcc2265d06b36d85ff036841503@ruby-forum.com>
	<ef5222770901120626p5af9ba89i864b8a7887192dec@mail.gmail.com>
Message-ID: <4802055c399e72a206447dda4fcefebf@ruby-forum.com>

Thanks for the response.  I was refering to the following post:

http://blog.mmediasys.com/2008/10/27/handy-tip-dont-mix-one-click-installer-with-cygwin/

Also, I am using the e-text editor, which uses cygwin ruby, and when I 
install the one click, I get ruby load errors when running cygwin ruby.
-- 
Posted via http://www.ruby-forum.com/.

From Shri.Borde at microsoft.com  Mon Jan 12 15:32:23 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 12 Jan 2009 12:32:23 -0800
Subject: [Ironruby-core] MRI 1.8.6 bug - exit is ignored if ensure clause
 throws exception which is caught by outer rescue
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058BFB1@NA-EXMSG-C104.redmond.corp.microsoft.com>

The following code snippet does print "after foo" when using MRI 1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts on whether this is by design, a known bug, or a new issue? If it's the latter, should I open a bug for it?

def foo
  begin
    begin
      begin
        exit
      rescue
        puts "We never reach here"
      end
    ensure
      raise "exception from ensure"
    end
  rescue
    puts "We do reach here, which is unexpected"
  end
end

foo
print "after foo"

Thanks,
Shri

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

From michael.letterle at gmail.com  Mon Jan 12 15:35:52 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Mon, 12 Jan 2009 15:35:52 -0500
Subject: [Ironruby-core] General setup questions
In-Reply-To: <4802055c399e72a206447dda4fcefebf@ruby-forum.com>
References: <34b3dfcc2265d06b36d85ff036841503@ruby-forum.com>
	<ef5222770901120626p5af9ba89i864b8a7887192dec@mail.gmail.com>
	<4802055c399e72a206447dda4fcefebf@ruby-forum.com>
Message-ID: <ef5222770901121235oc94581fi63c59d52e6bd8282@mail.gmail.com>

You can run both, the issue can occur when GEM_HOME points to the others
directory, i.e. you're in cygwin and GEM_HOME points to the one click
installer's gem repository.

On Mon, Jan 12, 2009 at 2:48 PM, Timothy Moriarty <lists at ruby-forum.com>wrote:

> Thanks for the response.  I was refering to the following post:
>
>
> http://blog.mmediasys.com/2008/10/27/handy-tip-dont-mix-one-click-installer-with-cygwin/
>
> Also, I am using the e-text editor, which uses cygwin ruby, and when I
> install the one click, I get ruby load errors when running cygwin ruby.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090112/bb450ef1/attachment.html>

From curth at microsoft.com  Mon Jan 12 16:11:58 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Mon, 12 Jan 2009 13:11:58 -0800
Subject: [Ironruby-core] Code Review: CompositeConversions3
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DAE94@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AEC52CB@NA-EXMSG-C118.redmond.corp.microsoft.com>

Ruby changes look good.

From: Tomas Matousek
Sent: Friday, January 09, 2009 4:08 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: CompositeConversions3


tfpt review "/shelveset:CompositeConversions3;REDMOND\tomat"

DLR change (interpreter)

Fixes interpretation of UnaryExpresion cast with a custom method.

Ruby changes

1)
Implements composite conversions and defines default composite protocol conversions. A composite conversion is basically a combination of at least 2 protocol conversions. For example, some methods convert to an integer using "to_int" if available and if not "to_i" is tried. Other methods try "to_str" first and "to_int" then or vice versa to convert to String or Fixnum.

For example, File#new's first parameter performs to_str-to_int conversion. To declare such a parameter a library function uses a parameter of type Union<T1, T2> marked by [DefaultProtocol]:

public static RubyFile/*!*/ CreateFile(RubyClass/*!*/ self,
  [DefaultProtocol]Union<int, MutableString> descriptorOrPath, [Optional, DefaultProtocol]MutableString mode, [Optional]int permission) {

  if (descriptorOrPath.IsFixnum()) { ... } else { ... }
}

This says that default protocol for Int32 and for MutableString should be performed in the order specified by the type parameters.

2)
Some methods use CastToInteger protocol. This protocol calls to_int, similarly to CastToFixnum, but the result could be both Fixnum or Bignum. This is not a composite conversion since only one conversion is called (to_int) however the type of the result could be either Int32 or BigInteger. There are also other places where we need to pass around a union of Int32 and BigInteger. IntegerValue struct serves this purpose. A default protocol for IntegerValue is CastToInteger. An example of use is Bignum#<<:

[RubyMethod("<<")]
public static object/*!*/ LeftShift(RubyContext/*!*/ context, BigInteger/*!*/ self, [DefaultProtocol]IntegerValue other) {
  return other.IsFixnum ? LeftShift(self, other.Fixnum) : LeftShift(self, other.Bignum);
}

3)
Refactors protocol conversion classes.

4)
Fixes File#open, IO#open, IO#for_fd.
Fixes String#to_i and Kernel#Integer.
Tokenizer now returns whitespace tokens in verbatim mode.

5)
Changes format mode in runrspec to "dotted". It doesn't produce so much noise.

Tomas


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

From lists at ruby-forum.com  Mon Jan 12 16:29:54 2009
From: lists at ruby-forum.com (Huw Collingbourne)
Date: Mon, 12 Jan 2009 22:29:54 +0100
Subject: [Ironruby-core] ETA for Visual Studio Support
In-Reply-To: <BLU140-W49A78F8FD25AA345663C5CABD80@phx.gbl>
References: <BLU140-W49A78F8FD25AA345663C5CABD80@phx.gbl>
Message-ID: <472c52c24cae652cb72c9711817ddcf9@ruby-forum.com>

Colin Jack wrote:
> Hi,
> 
> I was wondering whether there is an ETA for IronRuby being inside Visual 
> Studio (with, for example, code highlighting and/or intellisense)?
> 


We released a free IronRuby IDE with code highlighting and a form 
designer almost a year ago. it's still available and it's free.

http://www.sapphiresteel.com/Ruby-In-Steel-For-IronRuby

best wishes
Huw
-- 
Posted via http://www.ruby-forum.com/.

From Tomas.Matousek at microsoft.com  Mon Jan 12 16:33:03 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Mon, 12 Jan 2009 13:33:03 -0800
Subject: [Ironruby-core] MRI 1.8.6 bug - exit is ignored if ensure
 clause throws exception which is caught by outer rescue
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD058BFB1@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD058BFB1@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DB304@NA-EXMSG-C112.redmond.corp.microsoft.com>

I believe this is by design. Exit throws an exception (SystemExit). The exception is not rescued by a default rescue clause because it doesn't derive from StandardError. Thus the raise in ensure gets called and it raises RuntimeError which gets caught in the outer rescue because RuntimeError <: StandardError.

Tomas

From: Shri Borde [mailto:Shri.Borde at microsoft.com]
Sent: Monday, January 12, 2009 12:32 PM
To: ironruby-core at rubyforge.org; ruby-core at ruby-lang.org
Subject: [ruby-core:21289] MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue

The following code snippet does print "after foo" when using MRI 1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts on whether this is by design, a known bug, or a new issue? If it's the latter, should I open a bug for it?

def foo
  begin
    begin
      begin
        exit
      rescue
        puts "We never reach here"
      end
    ensure
      raise "exception from ensure"
    end
  rescue
    puts "We do reach here, which is unexpected"
  end
end

foo
print "after foo"

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Mon Jan 12 17:09:54 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 12 Jan 2009 14:09:54 -0800
Subject: [Ironruby-core] [ruby-core:21290] Re: MRI 1.8.6 bug - exit is
 ignored if ensure clause throws exception which is caught by outer rescue
In-Reply-To: <5B6C63F3-34E1-43E0-964E-048B58955C21@fallingsnow.net>
References: <710DF26F214D2B4BB94287123FFE980A2DD058BFB1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5B6C63F3-34E1-43E0-964E-048B58955C21@fallingsnow.net>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058C0B8@NA-EXMSG-C104.redmond.corp.microsoft.com>

OK, I have added a RSpec test, and  have already tagged it as an IronRuby bug.

For reference, .NET allows the equivalent ThreadAbortException to be caught, but automatically rethrows it at the end of the catch/rescue block. The programmer is required to take a separate action (calling Thread.ResetAbort<http://msdn.microsoft.com/en-us/library/system.threading.thread.resetabort.aspx>) to complete cancel the abort operation. This prevents situations where one component triggers the abort, and another cancels it unintentially. In theory, you should always do "rescue SomeSpecificExceptionType", but a lot of people do use just "rescue".

From: Evan Phoenix [mailto:evan at fallingsnow.net]
Sent: Monday, January 12, 2009 1:01 PM
To: ruby-core at ruby-lang.org
Subject: [ruby-core:21290] Re: MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue


On Jan 12, 2009, at 12:31 PM, Shri Borde wrote:


The following code snippet does print "after foo" when using MRI 1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts on whether this is by design, a known bug, or a new issue? If it's the latter, should I open a bug for it?

No, this is by design. Kernel#exit raises SystemExit, which the toplevel rescues and performs the actual exit. If you raise a new exception in the ensure. the SystemExit exception is never seen by the toplevel, and thus you don't get the exit.

This is used in a few places to cause exit to be ignored, or to allow a library to convert a SystemExit exception into something else (perhaps an IllegalOperation or something).

 - Evan Phoenix



def foo
  begin
    begin
      begin
        exit
      rescue
        puts "We never reach here"
      end
    ensure
      raise "exception from ensure"
    end
  rescue
    puts "We do reach here, which is unexpected"
  end
end

foo
print "after foo"

Thanks,
Shri


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

From Jimmy.Schementi at microsoft.com  Mon Jan 12 17:32:21 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Mon, 12 Jan 2009 14:32:21 -0800
Subject: [Ironruby-core] Congratulations to IronRuby MVPs: Peter Bacon
 Darwin and Michael Letterle
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>

All,

I want to congratulate two new "Microsoft Most Valuable Professionals" (MVP), Michael Letterle and Peter Bacon Darwin! They are IronRuby MVPs, though officially it says "Visual C#". =P 

Thanks for your hard work!

While you're waiting for a build, or just need some mindless activity, here's some information about the MVP program: https://mvp.support.microsoft.com

~Jimmy

From Tomas.Matousek at microsoft.com  Mon Jan 12 17:34:07 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Mon, 12 Jan 2009 14:34:07 -0800
Subject: [Ironruby-core] Code Review: GenericMethodsAndOverloads
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DB367@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:GenericMethodsAndOverloads;REDMOND\tomat"

    Implements generic methods parameters binding and explicit overload selection. Adds methods Method/UnboundMethod#of and Method/UnboundMethod#overloads. Method#of takes a list of Ruby classes or CLR types and returns a Method instance that has bound generic parameters to these classes/types. Method#overloads takes a list of Ruby classes or CLR types and returns a Method instance that includes only those CLR methods grouped in the Method object whose parameters are of the given types.

Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericMethodsAndOverloads.diff
Type: application/octet-stream
Size: 37452 bytes
Desc: GenericMethodsAndOverloads.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090112/60c72113/attachment-0001.obj>

From Shri.Borde at microsoft.com  Mon Jan 12 18:02:17 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 12 Jan 2009 15:02:17 -0800
Subject: [Ironruby-core] [ruby-core:21290] Re: MRI 1.8.6 bug - exit is
 ignored if ensure clause throws exception which is caught by outer rescue
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD058C0B8@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD058BFB1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<5B6C63F3-34E1-43E0-964E-048B58955C21@fallingsnow.net>
	<710DF26F214D2B4BB94287123FFE980A2DD058C0B8@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD058C121@NA-EXMSG-C104.redmond.corp.microsoft.com>

I was assuming that exit and Thread.current.kill do the same thing, but Tomas pointed out that they are different. Would you expect that "after foo" would get printed even if you replace exit with Thread.current.kill?

Thanks,
Shri

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Monday, January 12, 2009 2:10 PM
To: ruby-core at ruby-lang.org; ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] [ruby-core:21290] Re: MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue

OK, I have added a RSpec test, and  have already tagged it as an IronRuby bug.

For reference, .NET allows the equivalent ThreadAbortException to be caught, but automatically rethrows it at the end of the catch/rescue block. The programmer is required to take a separate action (calling Thread.ResetAbort<http://msdn.microsoft.com/en-us/library/system.threading.thread.resetabort.aspx>) to complete cancel the abort operation. This prevents situations where one component triggers the abort, and another cancels it unintentially. In theory, you should always do "rescue SomeSpecificExceptionType", but a lot of people do use just "rescue".

From: Evan Phoenix [mailto:evan at fallingsnow.net]
Sent: Monday, January 12, 2009 1:01 PM
To: ruby-core at ruby-lang.org
Subject: [ruby-core:21290] Re: MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue


On Jan 12, 2009, at 12:31 PM, Shri Borde wrote:

The following code snippet does print "after foo" when using MRI 1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts on whether this is by design, a known bug, or a new issue? If it's the latter, should I open a bug for it?

No, this is by design. Kernel#exit raises SystemExit, which the toplevel rescues and performs the actual exit. If you raise a new exception in the ensure. the SystemExit exception is never seen by the toplevel, and thus you don't get the exit.

This is used in a few places to cause exit to be ignored, or to allow a library to convert a SystemExit exception into something else (perhaps an IllegalOperation or something).

 - Evan Phoenix


def foo
  begin
    begin
      begin
        exit
      rescue
        puts "We never reach here"
      end
    ensure
      raise "exception from ensure"
    end
  rescue
    puts "We do reach here, which is unexpected"
  end
end

foo
print "after foo"

Thanks,
Shri


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

From blowmage at gmail.com  Mon Jan 12 18:02:24 2009
From: blowmage at gmail.com (Mike Moore)
Date: Mon, 12 Jan 2009 16:02:24 -0700
Subject: [Ironruby-core] Congratulations to IronRuby MVPs: Peter Bacon
	Darwin and Michael Letterle
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <f5bedd150901121502k515f70c2y7d69e74c061f2df6@mail.gmail.com>

Good job guys!

On Mon, Jan 12, 2009 at 3:32 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

> All,
>
> I want to congratulate two new "Microsoft Most Valuable Professionals"
> (MVP), Michael Letterle and Peter Bacon Darwin! They are IronRuby MVPs,
> though officially it says "Visual C#". =P
>
> Thanks for your hard work!
>
> While you're waiting for a build, or just need some mindless activity,
> here's some information about the MVP program:
> https://mvp.support.microsoft.com
>
> ~Jimmy
> _______________________________________________
> 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/20090112/eeb14969/attachment.html>

From jdeville at microsoft.com  Mon Jan 12 18:32:14 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Mon, 12 Jan 2009 15:32:14 -0800
Subject: [Ironruby-core] New Revisions
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB584368F@NA-EXMSG-C112.redmond.corp.microsoft.com>

First, new revisions of Git and SVN have been pushed.

Second, I haven't seen much activity on the list that involves SVN, so I think it is time to stop updating it, and time to stop allowing commits to it. This Friday will be my last push to SVN. After that I will be removing commit access, and I will start ripping code out of the Rakefiles. If you have any changes against SVN outstanding, please speak up so we can get them in or get them migrated.

Thanks

JD

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

From jdeville at microsoft.com  Mon Jan 12 20:18:22 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Mon, 12 Jan 2009 17:18:22 -0800
Subject: [Ironruby-core] FYI Code Review: gitrakefix
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB58436EE@NA-EXMSG-C112.redmond.corp.microsoft.com>

FYI: Going in via direct commit

  tfpt review "/shelveset:gitrakefix;REDMOND\jdeville"
  Comment  :
  Refactor's Thread#raise spec's to take into account suggestions from RubySpec IRC channel.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gitrakefix.diff
Type: application/octet-stream
Size: 741 bytes
Desc: gitrakefix.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090112/6dc1118e/attachment-0001.obj>

From jirapong.nanta at gmail.com  Mon Jan 12 21:22:46 2009
From: jirapong.nanta at gmail.com (jirapong.nanta at gmail.com)
Date: Tue, 13 Jan 2009 09:22:46 +0700
Subject: [Ironruby-core] Congratulations to IronRuby MVPs: Peter Bacon
	Darwin and Michael Letterle
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <3A764FC2-C40B-4EC0-9F65-8DC05F8392E9@gmail.com>

Congratulation guys!

On Jan 13, 2009, at 5:32 AM, Jimmy Schementi wrote:

> All,
>
> I want to congratulate two new "Microsoft Most Valuable  
> Professionals" (MVP), Michael Letterle and Peter Bacon Darwin! They  
> are IronRuby MVPs, though officially it says "Visual C#". =P
>
> Thanks for your hard work!
>
> While you're waiting for a build, or just need some mindless  
> activity, here's some information about the MVP program: https://mvp.support.microsoft.com
>
> ~Jimmy
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From ben2004uk at googlemail.com  Tue Jan 13 06:44:31 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Tue, 13 Jan 2009 11:44:31 +0000
Subject: [Ironruby-core] Congratulations to IronRuby MVPs: Peter Bacon
	Darwin and Michael Letterle
In-Reply-To: <3A764FC2-C40B-4EC0-9F65-8DC05F8392E9@gmail.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<3A764FC2-C40B-4EC0-9F65-8DC05F8392E9@gmail.com>
Message-ID: <a04554c00901130344m7d1aa5d7pa3e7479e628f99a5@mail.gmail.com>

Excellent work guys!

On Tue, Jan 13, 2009 at 2:22 AM, jirapong.nanta at gmail.com
<jirapong.nanta at gmail.com> wrote:
> Congratulation guys!
>
> On Jan 13, 2009, at 5:32 AM, Jimmy Schementi wrote:
>
>> All,
>>
>> I want to congratulate two new "Microsoft Most Valuable Professionals"
>> (MVP), Michael Letterle and Peter Bacon Darwin! They are IronRuby MVPs,
>> though officially it says "Visual C#". =P
>>
>> Thanks for your hard work!
>>
>> While you're waiting for a build, or just need some mindless activity,
>> here's some information about the MVP program:
>> https://mvp.support.microsoft.com
>>
>> ~Jimmy
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From michael.letterle at gmail.com  Tue Jan 13 09:25:05 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Tue, 13 Jan 2009 09:25:05 -0500
Subject: [Ironruby-core] Congratulations to IronRuby MVPs: Peter Bacon
	Darwin and Michael Letterle
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B472F@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <ef5222770901130625q6a909e91r6858512ec41e78c8@mail.gmail.com>

I just want to let you guys know how humbled and honored I am.  It's a
recognition I don't take lightly.

On Mon, Jan 12, 2009 at 5:32 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

> All,
>
> I want to congratulate two new "Microsoft Most Valuable Professionals"
> (MVP), Michael Letterle and Peter Bacon Darwin! They are IronRuby MVPs,
> though officially it says "Visual C#". =P
>
> Thanks for your hard work!
>
> While you're waiting for a build, or just need some mindless activity,
> here's some information about the MVP program:
> https://mvp.support.microsoft.com
>
> ~Jimmy
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/f6c79f12/attachment.html>

From Jimmy.Schementi at microsoft.com  Tue Jan 13 14:31:37 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 13 Jan 2009 11:31:37 -0800
Subject: [Ironruby-core] IronRuby 1.0 Roadmap
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>

http://ironruby.net/Roadmap

Here is a rough roadmap (aka, what's left to do) before IronRuby 1.0. More information, especially for the libraries, is coming soon, along with links to tickets tracking these features, etc.

Tomas, feel free to make corrections or add to this.

Questions, comments, concerns?

~js
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/83e383f1/attachment.html>

From michael.letterle at gmail.com  Tue Jan 13 15:03:48 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Tue, 13 Jan 2009 15:03:48 -0500
Subject: [Ironruby-core] IronRuby 1.0 Roadmap
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <ef5222770901131203r299866d6iab1fb7d39e47a12c@mail.gmail.com>

In regards to Zlib, Dan Berger put out a bounty for a pure ruby Zlib
encoding implementation, and two people came through:
http://www.ruby-forum.com/topic/173471

It looks like Charles library (which uses the zliby decompression code)
would work.  I can certainly port it to C# for performance purposes.  But
just wanted to update.

On Tue, Jan 13, 2009 at 2:31 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

>  http://ironruby.net/Roadmap
>
>
>
> Here is a rough roadmap (aka, what's left to do) before IronRuby 1.0. More
> information, especially for the libraries, is coming soon, along with links
> to tickets tracking these features, etc.
>
>
>
> Tomas, feel free to make corrections or add to this.
>
>
>
> Questions, comments, concerns?
>
>
>
> ~js
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/87a0d36a/attachment.html>

From Shri.Borde at microsoft.com  Tue Jan 13 15:38:19 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 13 Jan 2009 12:38:19 -0800
Subject: [Ironruby-core] IronRuby 1.0 Roadmap
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD06C89C2@NA-EXMSG-C104.redmond.corp.microsoft.com>

I removed "Thread" from the library list as our threading support is quite complete now.

Btw, hitting save added empty lines to the "Core" section which I did not even touch. I went back in and removed them, but we might need to watch out for formatting issues.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Tuesday, January 13, 2009 11:32 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby 1.0 Roadmap

http://ironruby.net/Roadmap

Here is a rough roadmap (aka, what's left to do) before IronRuby 1.0. More information, especially for the libraries, is coming soon, along with links to tickets tracking these features, etc.

Tomas, feel free to make corrections or add to this.

Questions, comments, concerns?

~js
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/c8cfd5e8/attachment-0001.html>

From Jimmy.Schementi at microsoft.com  Tue Jan 13 16:18:20 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 13 Jan 2009 13:18:20 -0800
Subject: [Ironruby-core] IronRuby 1.0 Roadmap
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD06C89C2@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4AEE@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD06C89C2@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF1B4BB2@NA-EXMSG-C116.redmond.corp.microsoft.com>

Thanks Shri, I'll keep an eye out on the formatting.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Tuesday, January 13, 2009 12:38 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby 1.0 Roadmap

I removed "Thread" from the library list as our threading support is quite complete now.

Btw, hitting save added empty lines to the "Core" section which I did not even touch. I went back in and removed them, but we might need to watch out for formatting issues.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Tuesday, January 13, 2009 11:32 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] IronRuby 1.0 Roadmap

http://ironruby.net/Roadmap

Here is a rough roadmap (aka, what's left to do) before IronRuby 1.0. More information, especially for the libraries, is coming soon, along with links to tickets tracking these features, etc.

Tomas, feel free to make corrections or add to this.

Questions, comments, concerns?

~js
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/68540755/attachment.html>

From jdeville at microsoft.com  Tue Jan 13 18:27:42 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 13 Jan 2009 15:27:42 -0800
Subject: [Ironruby-core] SVN and Git updated
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB5843B16@NA-EXMSG-C112.redmond.corp.microsoft.com>

SVN and Git have been updated to the latest files. Just a reminder, I will stop updating SVN on Friday.

The exciting addition this time is Generic method support and support for explicit overload selection. Here is the commit message:


Implements generic methods parameters binding and explicit overload selection. Adds methods Method/UnboundMethod#of and Method/UnboundMethod#overloads. Method#of takes a list of Ruby classes or CLR types and returns a Method instance that has bound generic parameters to these classes/types. Method#overloads takes a list of Ruby classes or CLR types and returns a Method instance that includes only those CLR methods grouped in the Method object whose parameters are of the given types.

For examples look at the ClrGenericMethods1 and ClrOverloadSelection1 tests in ClrTests.cs

For SVN, that file is in \trunk\utils\IronRuby.Tests\runtime

For Git, that file is in \Merlin\Main\Languages\Ruby\IronRuby\IronRuby.Tests\Runtime

Enjoy!

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

From curth at microsoft.com  Tue Jan 13 19:34:10 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Tue, 13 Jan 2009 16:34:10 -0800
Subject: [Ironruby-core] Code Review: GenericMethodsAndOverloads
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DB367@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DB367@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AF868AF@NA-EXMSG-C118.redmond.corp.microsoft.com>

Changes look good overall.

In RubyMethodGroupInfo.TryBindGenericParameters, an empty set of types will return all methods in MethodBases whether or not they're generic.  What's the reason for this behavior?

There's a chunk of code that was added to Utils.cs that's indented too far.

-----Original Message-----
From: Tomas Matousek 
Sent: Monday, January 12, 2009 2:34 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: GenericMethodsAndOverloads

  tfpt review "/shelveset:GenericMethodsAndOverloads;REDMOND\tomat"

    Implements generic methods parameters binding and explicit overload selection. Adds methods Method/UnboundMethod#of and Method/UnboundMethod#overloads. Method#of takes a list of Ruby classes or CLR types and returns a Method instance that has bound generic parameters to these classes/types. Method#overloads takes a list of Ruby classes or CLR types and returns a Method instance that includes only those CLR methods grouped in the Method object whose parameters are of the given types.

Tomas

From curth at microsoft.com  Tue Jan 13 19:42:08 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Tue, 13 Jan 2009 16:42:08 -0800
Subject: [Ironruby-core] Code Review: Indexers2
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DB981@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DB981@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AF868C6@NA-EXMSG-C118.redmond.corp.microsoft.com>

Okay, the indentation problem in Utils.cs is fixed. :)

Changes are good.

-----Original Message-----
From: Tomas Matousek
Sent: Tuesday, January 13, 2009 4:36 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Indexers2

  tfpt review "/shelveset:Indexers2;REDMOND\tomat"

  Implements default indexer access: a call to [] and []= on an instance of a CLR class marked by DefaultMember(<member-name>) attribute is translated to get_<member-name> and set_<member-name>, respectively.

  Also includes some minor refactoring.

Tomas



From Tomas.Matousek at microsoft.com  Tue Jan 13 19:44:18 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 13 Jan 2009 16:44:18 -0800
Subject: [Ironruby-core] Code Review: GenericMethodsAndOverloads
In-Reply-To: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AF868AF@NA-EXMSG-C118.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DB367@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<B47F8D37BAA6DC4DAA41CA69D8FBED15256AF868AF@NA-EXMSG-C118.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DB98C@NA-EXMSG-C112.redmond.corp.microsoft.com>

TryBindGenericParameters should look like:

            foreach (var method in MethodBases) {
                if (method.IsGenericMethodDefinition) {
                    if (typeArguments.Length == method.GetGenericArguments().Length) {
                        Debug.Assert(!(method is ConstructorInfo));
                        boundMethods.Add(((MethodInfo)method).MakeGenericMethod(typeArguments));
                    }
                } else if (typeArguments.Length == 0) {
                    boundMethods.Add(method);
                }
            }

Will include this fix in Indexers2 shelveset.

Tomas

-----Original Message-----
From: Curt Hagenlocher 
Sent: Tuesday, January 13, 2009 4:34 PM
To: Tomas Matousek; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: GenericMethodsAndOverloads

Changes look good overall.

In RubyMethodGroupInfo.TryBindGenericParameters, an empty set of types will return all methods in MethodBases whether or not they're generic.  What's the reason for this behavior?

There's a chunk of code that was added to Utils.cs that's indented too far.

-----Original Message-----
From: Tomas Matousek 
Sent: Monday, January 12, 2009 2:34 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: GenericMethodsAndOverloads

  tfpt review "/shelveset:GenericMethodsAndOverloads;REDMOND\tomat"

    Implements generic methods parameters binding and explicit overload selection. Adds methods Method/UnboundMethod#of and Method/UnboundMethod#overloads. Method#of takes a list of Ruby classes or CLR types and returns a Method instance that has bound generic parameters to these classes/types. Method#overloads takes a list of Ruby classes or CLR types and returns a Method instance that includes only those CLR methods grouped in the Method object whose parameters are of the given types.

Tomas

From Tomas.Matousek at microsoft.com  Tue Jan 13 19:35:45 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Tue, 13 Jan 2009 16:35:45 -0800
Subject: [Ironruby-core] Code Review: Indexers2
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DB981@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:Indexers2;REDMOND\tomat"

  Implements default indexer access: a call to [] and []= on an instance of a CLR class marked by DefaultMember(<member-name>) attribute is translated to get_<member-name> and set_<member-name>, respectively.

  Also includes some minor refactoring.

Tomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Indexers2.diff
Type: application/octet-stream
Size: 25542 bytes
Desc: Indexers2.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090113/8e720ec9/attachment-0001.obj>

From Tomas.Matousek at microsoft.com  Wed Jan 14 15:12:24 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 14 Jan 2009 12:12:24 -0800
Subject: [Ironruby-core] Code Review: MethodGroups2
Message-ID: <F58FE69873E2D5459B72C347DE1582412B249DBC95@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:MethodGroups2;REDMOND\tomat"

  Method goups refactoring. Splits RubyMethodGroupInfo into RubyLibraryMethodInfo, RubyMethodGroupInfo <: RubyMethodGroupBase.

Tomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MethodGroups2.diff
Type: application/octet-stream
Size: 81443 bytes
Desc: MethodGroups2.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090114/5834d8be/attachment-0001.obj>

From curth at microsoft.com  Wed Jan 14 17:32:57 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Wed, 14 Jan 2009 14:32:57 -0800
Subject: [Ironruby-core] Code Review: MethodGroups2
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DBC95@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B249DBC95@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED15256AF870DA@NA-EXMSG-C118.redmond.corp.microsoft.com>

Changes look good.  The xmldoc summaries on RubyMethodGroupInfo, RubyLibraryMethodInfo and RubyMethodGroupBase need to be updated to reflect the refactoring.

-----Original Message-----
From: Tomas Matousek
Sent: Wednesday, January 14, 2009 12:12 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: MethodGroups2

  tfpt review "/shelveset:MethodGroups2;REDMOND\tomat"

  Method goups refactoring. Splits RubyMethodGroupInfo into RubyLibraryMethodInfo, RubyMethodGroupInfo <: RubyMethodGroupBase.

Tomas


From jdeville at microsoft.com  Thu Jan 15 20:12:45 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 15 Jan 2009 17:12:45 -0800
Subject: [Ironruby-core] Git and SVN push
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB58443F7@NA-EXMSG-C112.redmond.corp.microsoft.com>

Git and SVN have been pushed. Reminder, tomorrow is the last time SVN will be updated!

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

From jdeville at microsoft.com  Fri Jan 16 17:52:54 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 16 Jan 2009 14:52:54 -0800
Subject: [Ironruby-core] SVN and Git pushes
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB590F46A@NA-EXMSG-C112.redmond.corp.microsoft.com>

I've pushed SVN revision 185, and Git revision 13dd51f. This is the final push to SVN.

JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090116/32bd8a34/attachment.html>

From Jimmy.Schementi at microsoft.com  Fri Jan 16 20:03:50 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 16 Jan 2009 17:03:50 -0800
Subject: [Ironruby-core] http://ironruby.net get's a facelift
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF2DD41B@NA-EXMSG-C116.redmond.corp.microsoft.com>

All,

http://ironruby.net should look completely different, and that's a good thing. I spent today moving stuff around, deleting, consolidating, etc. The site is more focused on getting and using IronRuby, but don't fear, all the info related to contributing to IronRuby is now on the Github wiki: http://wiki.github.com/ironruby/ironruby.

There are still a bunch of pages out of date, like the library status, and general project status, but those are next to update. A detailed list describing the status of each library will make it much more straight-forward to jump in and start working on one.

Let me know what you think.
~Jimmy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090116/6a0cb09f/attachment.html>

From Shri.Borde at microsoft.com  Wed Jan 21 19:47:29 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 21 Jan 2009 16:47:29 -0800
Subject: [Ironruby-core] TypeError maps to System.InvalidOperationException?
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>

We map Ruby's TypeError to System.InvalidOperationException. This surprised me. I would have expected TypeError to map to System.InvalidCastException. Wouldn't that be preferable?

In general, it would be good to document on http://www.ironruby.net/Documentation/CLR_Interop/Specification the exact mapping of the entire Ruby exception hierarchy to the equivalent .NET exception types. This will be useful documentation, especially for apps that host IronRuby scripts, and we can also do a brief review and potentially tweak the mapping. I have added a table at the bottom of the page which is half filled in.

Thanks,
Shri

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

From Tomas.Matousek at microsoft.com  Wed Jan 21 21:35:38 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 21 Jan 2009 18:35:38 -0800
Subject: [Ironruby-core] TypeError maps to
	System.InvalidOperationException?
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24C365CA@NA-EXMSG-C112.redmond.corp.microsoft.com>

If you search for "RubyExceptions.CreateTypeError" in libraries you'll get lines including the following (apart from type conversion errors). So it's not always a cast or conversion that fails. On the other hand, a conversion to a wrong type is an invalid operation. The exception mapping is attached.

  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\MutableString.cs(244):                throw RubyExceptions.CreateTypeError("can't modify frozen object");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(171):                throw RubyExceptions.CreateTypeError("can't copy singleton class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(183):                throw RubyExceptions.CreateTypeError("already initialized class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(510):                        throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(592):            throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyModule.cs(355):                throw RubyExceptions.CreateTypeError("can't modify frozen Module");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\Globals\SpecialGlobalVariableInfo.cs(239):                throw RubyExceptions.CreateTypeError(String.Format("${0} must have write method, {1} given",    C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1321):                throw RubyExceptions.CreateTypeError("assigning non-exception to $!");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1345):                throw RubyExceptions.CreateTypeError("backtrace must be Array of String");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyExceptions.cs(127):            return RubyExceptions.CreateTypeError(String.Format("{0} can't be coerced into {1}", selfClass, otherClass));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyOps.cs(503):                    throw RubyExceptions.CreateTypeError("can't define singleton method for literals");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(224):                throw RubyExceptions.CreateTypeError("unable to marshal time");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(260):                throw RubyExceptions.CreateTypeError("marshaled time format differ");

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 4:47 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] TypeError maps to System.InvalidOperationException?

We map Ruby's TypeError to System.InvalidOperationException. This surprised me. I would have expected TypeError to map to System.InvalidCastException. Wouldn't that be preferable?

In general, it would be good to document on http://www.ironruby.net/Documentation/CLR_Interop/Specification the exact mapping of the entire Ruby exception hierarchy to the equivalent .NET exception types. This will be useful documentation, especially for apps that host IronRuby scripts, and we can also do a brief review and potentially tweak the mapping. I have added a table at the bottom of the page which is half filled in.

Thanks,
Shri

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090121/19cde5aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExceptionHierarchy.png
Type: image/png
Size: 56331 bytes
Desc: ExceptionHierarchy.png
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090121/19cde5aa/attachment-0001.png>

From Shri.Borde at microsoft.com  Thu Jan 22 01:04:21 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 21 Jan 2009 22:04:21 -0800
Subject: [Ironruby-core] TypeError maps
	to	System.InvalidOperationException?
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B24C365CA@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24C365CA@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD0886A21@NA-EXMSG-C104.redmond.corp.microsoft.com>

All exceptions are invalid operations of some sort, and you could potentially want to use InvalidOperationException for any Ruby exception which did not map well to a CLR exception. I think picking either InvalidCastException or TypeLoadException would be better as it would be a bit more specific. And an InvalidCastException caused in C# code would be displayed as a TypeError in Ruby which would be nice. But given that neither InvalidCastException or TypeLoadException are a perfect match for TypeError, I won't push on this if everyone is OK with the current mapping.

Btw, the image is cool. I have attached it to http://www.ironruby.net/Documentation/CLR_Interop/Specification.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 21, 2009 6:36 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

If you search for "RubyExceptions.CreateTypeError" in libraries you'll get lines including the following (apart from type conversion errors). So it's not always a cast or conversion that fails. On the other hand, a conversion to a wrong type is an invalid operation. The exception mapping is attached.

  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\MutableString.cs(244):                throw RubyExceptions.CreateTypeError("can't modify frozen object");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(171):                throw RubyExceptions.CreateTypeError("can't copy singleton class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(183):                throw RubyExceptions.CreateTypeError("already initialized class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(510):                        throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(592):            throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyModule.cs(355):                throw RubyExceptions.CreateTypeError("can't modify frozen Module");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\Globals\SpecialGlobalVariableInfo.cs(239):                throw RubyExceptions.CreateTypeError(String.Format("${0} must have write method, {1} given",    C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1321):                throw RubyExceptions.CreateTypeError("assigning non-exception to $!");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1345):                throw RubyExceptions.CreateTypeError("backtrace must be Array of String");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyExceptions.cs(127):            return RubyExceptions.CreateTypeError(String.Format("{0} can't be coerced into {1}", selfClass, otherClass));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyOps.cs(503):                    throw RubyExceptions.CreateTypeError("can't define singleton method for literals");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(224):                throw RubyExceptions.CreateTypeError("unable to marshal time");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(260):                throw RubyExceptions.CreateTypeError("marshaled time format differ");

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 4:47 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] TypeError maps to System.InvalidOperationException?

We map Ruby's TypeError to System.InvalidOperationException. This surprised me. I would have expected TypeError to map to System.InvalidCastException. Wouldn't that be preferable?

In general, it would be good to document on http://www.ironruby.net/Documentation/CLR_Interop/Specification the exact mapping of the entire Ruby exception hierarchy to the equivalent .NET exception types. This will be useful documentation, especially for apps that host IronRuby scripts, and we can also do a brief review and potentially tweak the mapping. I have added a table at the bottom of the page which is half filled in.

Thanks,
Shri

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

From lists at ruby-forum.com  Thu Jan 22 01:24:26 2009
From: lists at ruby-forum.com (Benjamin van der Veen)
Date: Thu, 22 Jan 2009 07:24:26 +0100
Subject: [Ironruby-core] http://ironruby.net get's a facelift
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF2DD41B@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF2DD41B@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <aa72e4a3ee5beb8b16f885e8b667518d@ruby-forum.com>

Hi Jimmy,

The new site looks great, truly an improvement over the old one. The 
homepage is definitely more approachable. I might suggest making it more 
clear that the Contribute link goes to github, i.e., mention it in the 
subtext. Also would be nice to have a link to the mailing list on the 
homepage. Which, by the way: is this a mailing list or a message board? 
I'm viewing it at http://ruby-forum.com/forum/34 ? is there a regular 
list this interface is reading and posting to? Might be worth clarifying 
that on the site, too.

Also, it seems like the 0.2 Alpha download is a bit broken. On calls to 
ScriptSource.Execute([some code]) I get an exception complaining about 
it being unable to find Microsoft.Scripting.dll v1.0.0.5000. The bundled 
Microsoft.Scripting.dll is 1.0.0.5001. Has anyone else had similar 
problems?

Benjamin


Jimmy Schementi wrote:
> All,
> 
> http://ironruby.net should look completely different, and that's a good 
> thing. I spent today moving stuff around, deleting, consolidating, etc. 
> The site is more focused on getting and using IronRuby, but don't fear, 
> all the info related to contributing to IronRuby is now on the Github 
> wiki: http://wiki.github.com/ironruby/ironruby.
> 
> There are still a bunch of pages out of date, like the library status, 
> and general project status, but those are next to update. A detailed 
> list describing the status of each library will make it much more 
> straight-forward to jump in and start working on one.
> 
> Let me know what you think.
> ~Jimmy

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

From Shri.Borde at microsoft.com  Thu Jan 22 14:09:38 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 22 Jan 2009 11:09:38 -0800
Subject: [Ironruby-core] TypeError
	maps	to	System.InvalidOperationException?
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD0886A21@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24C365CA@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD0886A21@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094B613@NA-EXMSG-C104.redmond.corp.microsoft.com>

Btw, one more consideration is that if a .NET method throws InvalidOperationException, IronRuby will map it to TypeError even though the .NET method was not doing anything at all with the type system. This will be confusing to users. So it would be preferable to map TypeError to InvalidCastException or TypeLoadException, or create a new IronRuby.Builtins.TypeError exception type.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 10:04 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

All exceptions are invalid operations of some sort, and you could potentially want to use InvalidOperationException for any Ruby exception which did not map well to a CLR exception. I think picking either InvalidCastException or TypeLoadException would be better as it would be a bit more specific. And an InvalidCastException caused in C# code would be displayed as a TypeError in Ruby which would be nice. But given that neither InvalidCastException or TypeLoadException are a perfect match for TypeError, I won't push on this if everyone is OK with the current mapping.

Btw, the image is cool. I have attached it to http://www.ironruby.net/Documentation/CLR_Interop/Specification.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 21, 2009 6:36 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

If you search for "RubyExceptions.CreateTypeError" in libraries you'll get lines including the following (apart from type conversion errors). So it's not always a cast or conversion that fails. On the other hand, a conversion to a wrong type is an invalid operation. The exception mapping is attached.

  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\MutableString.cs(244):                throw RubyExceptions.CreateTypeError("can't modify frozen object");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(171):                throw RubyExceptions.CreateTypeError("can't copy singleton class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(183):                throw RubyExceptions.CreateTypeError("already initialized class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(510):                        throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(592):            throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyModule.cs(355):                throw RubyExceptions.CreateTypeError("can't modify frozen Module");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\Globals\SpecialGlobalVariableInfo.cs(239):                throw RubyExceptions.CreateTypeError(String.Format("${0} must have write method, {1} given",    C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1321):                throw RubyExceptions.CreateTypeError("assigning non-exception to $!");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1345):                throw RubyExceptions.CreateTypeError("backtrace must be Array of String");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyExceptions.cs(127):            return RubyExceptions.CreateTypeError(String.Format("{0} can't be coerced into {1}", selfClass, otherClass));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyOps.cs(503):                    throw RubyExceptions.CreateTypeError("can't define singleton method for literals");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(224):                throw RubyExceptions.CreateTypeError("unable to marshal time");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(260):                throw RubyExceptions.CreateTypeError("marshaled time format differ");

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 4:47 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] TypeError maps to System.InvalidOperationException?

We map Ruby's TypeError to System.InvalidOperationException. This surprised me. I would have expected TypeError to map to System.InvalidCastException. Wouldn't that be preferable?

In general, it would be good to document on http://www.ironruby.net/Documentation/CLR_Interop/Specification the exact mapping of the entire Ruby exception hierarchy to the equivalent .NET exception types. This will be useful documentation, especially for apps that host IronRuby scripts, and we can also do a brief review and potentially tweak the mapping. I have added a table at the bottom of the page which is half filled in.

Thanks,
Shri

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

From Tomas.Matousek at microsoft.com  Thu Jan 22 14:25:23 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 22 Jan 2009 11:25:23 -0800
Subject: [Ironruby-core]
	TypeError	maps	to	System.InvalidOperationException?
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094B613@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD0886944@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24C365CA@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD0886A21@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094B613@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24C367BC@NA-EXMSG-C112.redmond.corp.microsoft.com>

Makes sense. I think we can map it to InvalidCastException. The core implementations of built-in classes such as Hash, RubyArray, etc. could still throw InvalidOperationException if there is a problem with the object state and the library wrappers can rethrow it as InvalidCast (TypeError) to match Ruby error type. C# apps using Ruby built-in classes will get InvalidOperation, which is what they would expect.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Thursday, January 22, 2009 11:10 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

Btw, one more consideration is that if a .NET method throws InvalidOperationException, IronRuby will map it to TypeError even though the .NET method was not doing anything at all with the type system. This will be confusing to users. So it would be preferable to map TypeError to InvalidCastException or TypeLoadException, or create a new IronRuby.Builtins.TypeError exception type.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 10:04 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

All exceptions are invalid operations of some sort, and you could potentially want to use InvalidOperationException for any Ruby exception which did not map well to a CLR exception. I think picking either InvalidCastException or TypeLoadException would be better as it would be a bit more specific. And an InvalidCastException caused in C# code would be displayed as a TypeError in Ruby which would be nice. But given that neither InvalidCastException or TypeLoadException are a perfect match for TypeError, I won't push on this if everyone is OK with the current mapping.

Btw, the image is cool. I have attached it to http://www.ironruby.net/Documentation/CLR_Interop/Specification.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek
Sent: Wednesday, January 21, 2009 6:36 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] TypeError maps to System.InvalidOperationException?

If you search for "RubyExceptions.CreateTypeError" in libraries you'll get lines including the following (apart from type conversion errors). So it's not always a cast or conversion that fails. On the other hand, a conversion to a wrong type is an invalid operation. The exception mapping is attached.

  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\MutableString.cs(244):                throw RubyExceptions.CreateTypeError("can't modify frozen object");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(171):                throw RubyExceptions.CreateTypeError("can't copy singleton class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(183):                throw RubyExceptions.CreateTypeError("already initialized class");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(510):                        throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyClass.cs(592):            throw RubyExceptions.CreateTypeError(String.Format("allocator undefined for {0}", Name));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Builtins\RubyModule.cs(355):                throw RubyExceptions.CreateTypeError("can't modify frozen Module");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\Globals\SpecialGlobalVariableInfo.cs(239):                throw RubyExceptions.CreateTypeError(String.Format("${0} must have write method, {1} given",    C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1321):                throw RubyExceptions.CreateTypeError("assigning non-exception to $!");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyContext.cs(1345):                throw RubyExceptions.CreateTypeError("backtrace must be Array of String");
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyExceptions.cs(127):            return RubyExceptions.CreateTypeError(String.Format("{0} can't be coerced into {1}", selfClass, otherClass));
  C:\M0\Merlin\Main\Languages\Ruby\Ruby\Runtime\RubyOps.cs(503):                    throw RubyExceptions.CreateTypeError("can't define singleton method for literals");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(224):                throw RubyExceptions.CreateTypeError("unable to marshal time");
  C:\M0\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\TimeOps.cs(260):                throw RubyExceptions.CreateTypeError("marshaled time format differ");

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, January 21, 2009 4:47 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] TypeError maps to System.InvalidOperationException?

We map Ruby's TypeError to System.InvalidOperationException. This surprised me. I would have expected TypeError to map to System.InvalidCastException. Wouldn't that be preferable?

In general, it would be good to document on http://www.ironruby.net/Documentation/CLR_Interop/Specification the exact mapping of the entire Ruby exception hierarchy to the equivalent .NET exception types. This will be useful documentation, especially for apps that host IronRuby scripts, and we can also do a brief review and potentially tweak the mapping. I have added a table at the bottom of the page which is half filled in.

Thanks,
Shri

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

From ivan at flanders.co.nz  Thu Jan 22 15:19:48 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 22 Jan 2009 21:19:48 +0100
Subject: [Ironruby-core] Zlib::Inflate error when installing gems
Message-ID: <b1c6aabb0901221219x3fe37b2dv3d1f4ff61026777d@mail.gmail.com>

I think you are aware of the error.. but I'd like to mention on the list
that you can get around it by first installing the gem in MRI that seems to
make it go away.

? igem install bacon
ERROR:  While executing gem ... (TypeError)
    allocator undefined for Zlib::Inflate
+ C:\Users\Ivan Porto Carrero
? gem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
+ C:\Users\Ivan Porto Carrero
? igem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
ERROR:  While executing gem ... (TypeError)
    can't convert Array into String

To install the rails gem there is only one issue remaining and that has to
do with a file in the actionmailer test fixtures. The name of the file ends
in a ~ and apparently ironruby doesn't like that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/79dbe447/attachment.html>

From michael.letterle at gmail.com  Thu Jan 22 16:32:09 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Thu, 22 Jan 2009 16:32:09 -0500
Subject: [Ironruby-core] Zlib::Inflate error when installing gems
In-Reply-To: <b1c6aabb0901221219x3fe37b2dv3d1f4ff61026777d@mail.gmail.com>
References: <b1c6aabb0901221219x3fe37b2dv3d1f4ff61026777d@mail.gmail.com>
Message-ID: <ef5222770901221332u74901c45rbe2a877c6eb468c9@mail.gmail.com>

/USUALLY/ filenames ending in ~ are backup files.. are you sure the file
causes issues is a critical file?

On Thu, Jan 22, 2009 at 3:19 PM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote:

> I think you are aware of the error.. but I'd like to mention on the list
> that you can get around it by first installing the gem in MRI that seems to
> make it go away.
>
> ? igem install bacon
> ERROR:  While executing gem ... (TypeError)
>     allocator undefined for Zlib::Inflate
> + C:\Users\Ivan Porto Carrero
> ? gem install bacon
> Successfully installed bacon-1.1.0
> 1 gem installed
> Installing ri documentation for bacon-1.1.0...
> Installing RDoc documentation for bacon-1.1.0...
> + C:\Users\Ivan Porto Carrero
> ? igem install bacon
> Successfully installed bacon-1.1.0
> 1 gem installed
> Installing ri documentation for bacon-1.1.0...
> Installing RDoc documentation for bacon-1.1.0...
> ERROR:  While executing gem ... (TypeError)
>     can't convert Array into String
>
> To install the rails gem there is only one issue remaining and that has to
> do with a file in the actionmailer test fixtures. The name of the file ends
> in a ~ and apparently ironruby doesn't like that.
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/40380b0c/attachment-0001.html>

From jdeville at microsoft.com  Thu Jan 22 16:58:44 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 22 Jan 2009 13:58:44 -0800
Subject: [Ironruby-core] Zlib::Inflate error when installing gems
In-Reply-To: <ef5222770901221332u74901c45rbe2a877c6eb468c9@mail.gmail.com>
References: <b1c6aabb0901221219x3fe37b2dv3d1f4ff61026777d@mail.gmail.com>
	<ef5222770901221332u74901c45rbe2a877c6eb468c9@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDCDA@NA-EXMSG-C112.redmond.corp.microsoft.com>

The file may be an accidental checkin, but the bug is real. I should be able to handle a file with ~ in the filename.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Thursday, January 22, 2009 1:32 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Zlib::Inflate error when installing gems

/USUALLY/ filenames ending in ~ are backup files.. are you sure the file causes issues is a critical file?
On Thu, Jan 22, 2009 at 3:19 PM, Ivan Porto Carrero <ivan at flanders.co.nz<mailto:ivan at flanders.co.nz>> wrote:
I think you are aware of the error.. but I'd like to mention on the list that you can get around it by first installing the gem in MRI that seems to make it go away.

> igem install bacon
ERROR:  While executing gem ... (TypeError)
    allocator undefined for Zlib::Inflate
+ C:\Users\Ivan Porto Carrero
> gem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
+ C:\Users\Ivan Porto Carrero
> igem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
ERROR:  While executing gem ... (TypeError)
    can't convert Array into String

To install the rails gem there is only one issue remaining and that has to do with a file in the actionmailer test fixtures. The name of the file ends in a ~ and apparently ironruby doesn't like that.


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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From Jimmy.Schementi at microsoft.com  Thu Jan 22 17:42:09 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Thu, 22 Jan 2009 14:42:09 -0800
Subject: [Ironruby-core] Zlib::Inflate error when installing gems
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDCDA@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <b1c6aabb0901221219x3fe37b2dv3d1f4ff61026777d@mail.gmail.com>
	<ef5222770901221332u74901c45rbe2a877c6eb468c9@mail.gmail.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDCDA@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF3E219C@NA-EXMSG-C116.redmond.corp.microsoft.com>

Please open a bug in rubyforge against me, I'll take a look at it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Thursday, January 22, 2009 1:59 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Zlib::Inflate error when installing gems

The file may be an accidental checkin, but the bug is real. I should be able to handle a file with ~ in the filename.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Thursday, January 22, 2009 1:32 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Zlib::Inflate error when installing gems

/USUALLY/ filenames ending in ~ are backup files.. are you sure the file causes issues is a critical file?
On Thu, Jan 22, 2009 at 3:19 PM, Ivan Porto Carrero <ivan at flanders.co.nz<mailto:ivan at flanders.co.nz>> wrote:
I think you are aware of the error.. but I'd like to mention on the list that you can get around it by first installing the gem in MRI that seems to make it go away.

> igem install bacon
ERROR:  While executing gem ... (TypeError)
    allocator undefined for Zlib::Inflate
+ C:\Users\Ivan Porto Carrero
> gem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
+ C:\Users\Ivan Porto Carrero
> igem install bacon
Successfully installed bacon-1.1.0
1 gem installed
Installing ri documentation for bacon-1.1.0...
Installing RDoc documentation for bacon-1.1.0...
ERROR:  While executing gem ... (TypeError)
    can't convert Array into String

To install the rails gem there is only one issue remaining and that has to do with a file in the actionmailer test fixtures. The name of the file ends in a ~ and apparently ironruby doesn't like that.


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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/f45a461f/attachment.html>

From jgbailey at gmail.com  Thu Jan 22 19:45:08 2009
From: jgbailey at gmail.com (Justin Bailey)
Date: Thu, 22 Jan 2009 16:45:08 -0800
Subject: [Ironruby-core] Building IronRuby
Message-ID: <a45dff840901221645s3121098fwe2be12c6b5158c3d@mail.gmail.com>

I've just gotten the latest ironruby bits from github and cannot
build. Using Merlin\Main\Languagues\Ruby\IronRuby.sln:

  * Can't open the Microsoft.Scripting project because it imports from
"Merlin\Main\Support\SpecSharp.targets" which is not in the repo.
  * Cryptographic failures when building because
"Support\MSSharedLibKey.snk" does not exist.

Removing the import statement from
"Merlin\Main\Runtime\Microsoft.Scripting\Microsoft.Scripting.csproj"
and creating a fake SNK file in the appropriate directory lets me get
further, but I still can't build:

  * 'IronRuby.Compiler.Methods' is inaccessible due to its protection
leve Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs	29	77

  * 'IronRuby.Runtime.Calls.BlockDispatcher' does not contain a
definition for 'MaxBlockArity'	Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs	102	59

Basically a bunch of internal definitions look like they should be
public. Am I missing something or did a bad commit slip through?

Justin

From jdeville at microsoft.com  Thu Jan 22 19:57:27 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 22 Jan 2009 16:57:27 -0800
Subject: [Ironruby-core] Git push
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDC1@NA-EXMSG-C112.redmond.corp.microsoft.com>

I've been doing daily pushes, but I forgot to send the emails. Sorry about that. I've just pushed a new Git Revision.

Enjoy

JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/1957b316/attachment-0001.html>

From jdeville at microsoft.com  Thu Jan 22 20:30:10 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 22 Jan 2009 17:30:10 -0800
Subject: [Ironruby-core] Building IronRuby
In-Reply-To: <a45dff840901221645s3121098fwe2be12c6b5158c3d@mail.gmail.com>
References: <a45dff840901221645s3121098fwe2be12c6b5158c3d@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDD5@NA-EXMSG-C112.redmond.corp.microsoft.com>

Can you try command line? From Merlin\Main\Languages\Ruby, run "set MERLIN_ROOT=Path\To\Merlin\Main", then run "rake compile". I will try to have SpecSharp.targets moved in the next couple of pushes.

Tomas: Do we still need the second copy of SpecSharp.targets in Merlin/Main/Languages/Ruby? Also, can I delete IronRuby.sln (leaving only Ruby.sln). If we don't need the SpecSharp.targets, I'll move it from Support back to Main, delete the one in Ruby and update references.

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Justin Bailey
Sent: Thursday, January 22, 2009 4:45 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Building IronRuby

I've just gotten the latest ironruby bits from github and cannot
build. Using Merlin\Main\Languagues\Ruby\IronRuby.sln:

  * Can't open the Microsoft.Scripting project because it imports from
"Merlin\Main\Support\SpecSharp.targets" which is not in the repo.
  * Cryptographic failures when building because
"Support\MSSharedLibKey.snk" does not exist.

Removing the import statement from
"Merlin\Main\Runtime\Microsoft.Scripting\Microsoft.Scripting.csproj"
and creating a fake SNK file in the appropriate directory lets me get
further, but I still can't build:

  * 'IronRuby.Compiler.Methods' is inaccessible due to its protection
leve Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs  29      77

  * 'IronRuby.Runtime.Calls.BlockDispatcher' does not contain a
definition for 'MaxBlockArity'  Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs       102     59

Basically a bunch of internal definitions look like they should be
public. Am I missing something or did a bad commit slip through?

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


From michael.letterle at gmail.com  Thu Jan 22 20:47:48 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Thu, 22 Jan 2009 20:47:48 -0500
Subject: [Ironruby-core] Git push
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDC1@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDC1@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <ef5222770901221747j3af77923pd1b68ff298497309@mail.gmail.com>

Now that github is the primary external repo, how about those of us who are
really interested (like me ;)) just subscribe to the rss feed?
http://github.com/feeds/ironruby/commits/ironruby/master

On Thu, Jan 22, 2009 at 7:57 PM, Jim Deville <jdeville at microsoft.com> wrote:

>  I've been doing daily pushes, but I forgot to send the emails. Sorry
> about that. I've just pushed a new Git Revision.
>
>
>
> Enjoy
>
>
>
> JD
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/ce7bcea2/attachment.html>

From jdeville at microsoft.com  Thu Jan 22 20:50:38 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 22 Jan 2009 17:50:38 -0800
Subject: [Ironruby-core] Git push
In-Reply-To: <ef5222770901221747j3af77923pd1b68ff298497309@mail.gmail.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDC1@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<ef5222770901221747j3af77923pd1b68ff298497309@mail.gmail.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDEA@NA-EXMSG-C112.redmond.corp.microsoft.com>

What, you don't like my emails?

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Thursday, January 22, 2009 5:48 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Git push

Now that github is the primary external repo, how about those of us who are really interested (like me ;)) just subscribe to the rss feed? http://github.com/feeds/ironruby/commits/ironruby/master
On Thu, Jan 22, 2009 at 7:57 PM, Jim Deville <jdeville at microsoft.com<mailto:jdeville at microsoft.com>> wrote:

I've been doing daily pushes, but I forgot to send the emails. Sorry about that. I've just pushed a new Git Revision.



Enjoy



JD

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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From Jimmy.Schementi at microsoft.com  Thu Jan 22 22:12:49 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Thu, 22 Jan 2009 19:12:49 -0800
Subject: [Ironruby-core] Building IronRuby
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDD5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a45dff840901221645s3121098fwe2be12c6b5158c3d@mail.gmail.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDD5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497A82@NA-EXMSG-C116.redmond.corp.microsoft.com>

FYI, Jim (I believe) and I are starting to work out of Git primarily, so we'll be forced to iron out these kinks. Also, preserving commit information between git and tfs is a goal, so no more of the "sync with tfs" commits ... you'll see the actual msg/author ... and we'll have to get a reliable continuous integration server.

Just a heads up that though it's painful now, it's going to get much better soon, and everyone to be on the same playing field.

~js

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Thursday, January 22, 2009 5:30 PM
To: ironruby-core at rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Building IronRuby

Can you try command line? From Merlin\Main\Languages\Ruby, run "set MERLIN_ROOT=Path\To\Merlin\Main", then run "rake compile". I will try to have SpecSharp.targets moved in the next couple of pushes.

Tomas: Do we still need the second copy of SpecSharp.targets in Merlin/Main/Languages/Ruby? Also, can I delete IronRuby.sln (leaving only Ruby.sln). If we don't need the SpecSharp.targets, I'll move it from Support back to Main, delete the one in Ruby and update references.

JD

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Justin Bailey
Sent: Thursday, January 22, 2009 4:45 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Building IronRuby

I've just gotten the latest ironruby bits from github and cannot
build. Using Merlin\Main\Languagues\Ruby\IronRuby.sln:

  * Can't open the Microsoft.Scripting project because it imports from
"Merlin\Main\Support\SpecSharp.targets" which is not in the repo.
  * Cryptographic failures when building because
"Support\MSSharedLibKey.snk" does not exist.

Removing the import statement from
"Merlin\Main\Runtime\Microsoft.Scripting\Microsoft.Scripting.csproj"
and creating a fake SNK file in the appropriate directory lets me get
further, but I still can't build:

  * 'IronRuby.Compiler.Methods' is inaccessible due to its protection
leve Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs  29      77

  * 'IronRuby.Runtime.Calls.BlockDispatcher' does not contain a
definition for 'MaxBlockArity'  Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs       102     59

Basically a bunch of internal definitions look like they should be
public. Am I missing something or did a bad commit slip through?

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

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


From Jimmy.Schementi at microsoft.com  Fri Jan 23 00:30:06 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Thu, 22 Jan 2009 21:30:06 -0800
Subject: [Ironruby-core] http://ironruby.net get's a facelift
In-Reply-To: <aa72e4a3ee5beb8b16f885e8b667518d@ruby-forum.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF2DD41B@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<aa72e4a3ee5beb8b16f885e8b667518d@ruby-forum.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AB3@NA-EXMSG-C116.redmond.corp.microsoft.com>

Benjamin van der Veen wrote:
> The new site looks great, truly an improvement over the old one.

Thanks =)

> Also would be nice to have a link to the mailing list on the
> homepage. Which, by the way: is this a mailing list or a message board?
> I'm viewing it at http://ruby-forum.com/forum/34 ? is there a regular
> list this interface is reading and posting to? Might be worth
> clarifying that on the site, too.

I changed the "Media" link to "Support", and have links to the RubyForge bug/feature trackers, as well as the mailing list there.

This is a mailing list, but http://ruby-forum.com provides a web-interface for all Ruby/Rails related mailing lists.

From Jimmy.Schementi at microsoft.com  Fri Jan 23 01:05:14 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Thu, 22 Jan 2009 22:05:14 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>

In case this is new to anyone ... Harry Pierson recently built a daily-build site for the IronPython and DLR Codeplex sites. Good news for IronRuby is it's included in the DLR Codeplex source repository (since IronRuby shares a source repository with DLR and IronPython, and the DLR Codeplex site is a daily-updated mirror of that repository).

Here's the DLR Daily Build RSS Feed:
http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr

Pick your poison (debug/release/silverlight debug/silverlight release) and you'll get a build of IronRuby, IronPython, and the DLR in one package. Soon we'll have a continuous integration server which produces daily builds out of the git repository, but until then this may ease the pain in getting builds.

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

From jdeville at microsoft.com  Fri Jan 23 01:17:37 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Thu, 22 Jan 2009 22:17:37 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDE46@NA-EXMSG-C112.redmond.corp.microsoft.com>

He's also working on adding IronRuby from the Git repo.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Thursday, January 22, 2009 10:05 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)

In case this is new to anyone ... Harry Pierson recently built a daily-build site for the IronPython and DLR Codeplex sites. Good news for IronRuby is it's included in the DLR Codeplex source repository (since IronRuby shares a source repository with DLR and IronPython, and the DLR Codeplex site is a daily-updated mirror of that repository).

Here's the DLR Daily Build RSS Feed:
http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr

Pick your poison (debug/release/silverlight debug/silverlight release) and you'll get a build of IronRuby, IronPython, and the DLR in one package. Soon we'll have a continuous integration server which produces daily builds out of the git repository, but until then this may ease the pain in getting builds.

~js
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090122/b94ed06e/attachment.html>

From michael.letterle at gmail.com  Fri Jan 23 09:02:09 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Fri, 23 Jan 2009 09:02:09 -0500
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>

I assume this is a Window/.NET build? :)

On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

>  In case this is new to anyone ? Harry Pierson recently built a
> daily-build site for the IronPython and DLR Codeplex sites. Good news for
> IronRuby is it's included in the DLR Codeplex source repository (since
> IronRuby shares a source repository with DLR and IronPython, and the DLR
> Codeplex site is a daily-updated mirror of that repository).
>
>
>
> Here's the DLR Daily Build RSS Feed:
>
> http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
>
>
>
> Pick your poison (debug/release/silverlight debug/silverlight release) and
> you'll get a build of IronRuby, IronPython, and the DLR in one package. Soon
> we'll have a continuous integration server which produces daily builds out
> of the git repository, but until then this may ease the pain in getting
> builds.
>
>
>
> ~js
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090123/86672f6b/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Jan 23 09:07:00 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 23 Jan 2009 14:07:00 +0000
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
Message-ID: <4979CF04.9080006@voidspace.org.uk>

Michael Letterle wrote:
> I assume this is a Window/.NET build? :)
Certainly as far as IronPython goes, binaries compiled on Windows work 
on Mono (modulo any Mono bugs).

Michael

>
> On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi 
> <Jimmy.Schementi at microsoft.com <mailto:Jimmy.Schementi at microsoft.com>> 
> wrote:
>
>     In case this is new to anyone ? Harry Pierson recently built a
>     daily-build site for the IronPython and DLR Codeplex sites. Good
>     news for IronRuby is it's included in the DLR Codeplex source
>     repository (since IronRuby shares a source repository with DLR and
>     IronPython, and the DLR Codeplex site is a daily-updated mirror of
>     that repository).
>
>      
>
>     Here's the DLR Daily Build RSS Feed:
>
>     http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
>
>      
>
>     Pick your poison (debug/release/silverlight debug/silverlight
>     release) and you'll get a build of IronRuby, IronPython, and the
>     DLR in one package. Soon we'll have a continuous integration
>     server which produces daily builds out of the git repository, but
>     until then this may ease the pain in getting builds.
>
>      
>
>     ~js
>
>
>     _______________________________________________
>     Ironruby-core mailing list
>     Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> -- 
> Michael Letterle
> [Polymath Prokrammer]
> http://blog.prokrams.com
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>   


From michael.letterle at gmail.com  Fri Jan 23 10:07:58 2009
From: michael.letterle at gmail.com (Michael Letterle)
Date: Fri, 23 Jan 2009 10:07:58 -0500
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <4979CF04.9080006@voidspace.org.uk>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
Message-ID: <ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>

Indeed, but it doesn't regression test building on mono (or under linux).
Just wanted to confirm this wasn't happening since that's what I've been
working on and don't want to duplicate efforts.

On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Michael Letterle wrote:
>
>> I assume this is a Window/.NET build? :)
>>
> Certainly as far as IronPython goes, binaries compiled on Windows work on
> Mono (modulo any Mono bugs).
>
> Michael
>
>
>> On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi <
>> Jimmy.Schementi at microsoft.com <mailto:Jimmy.Schementi at microsoft.com>>
>> wrote:
>>
>>    In case this is new to anyone ? Harry Pierson recently built a
>>    daily-build site for the IronPython and DLR Codeplex sites. Good
>>    news for IronRuby is it's included in the DLR Codeplex source
>>    repository (since IronRuby shares a source repository with DLR and
>>    IronPython, and the DLR Codeplex site is a daily-updated mirror of
>>    that repository).
>>
>>
>>    Here's the DLR Daily Build RSS Feed:
>>
>>    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
>>
>>
>>    Pick your poison (debug/release/silverlight debug/silverlight
>>    release) and you'll get a build of IronRuby, IronPython, and the
>>    DLR in one package. Soon we'll have a continuous integration
>>    server which produces daily builds out of the git repository, but
>>    until then this may ease the pain in getting builds.
>>
>>
>>    ~js
>>
>>
>>    _______________________________________________
>>    Ironruby-core mailing list
>>    Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
>>    http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>>
>>
>> --
>> Michael Letterle
>> [Polymath Prokrammer]
>> http://blog.prokrams.com
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>



-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090123/1ad08c6b/attachment.html>

From Jimmy.Schementi at microsoft.com  Fri Jan 23 10:19:53 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 23 Jan 2009 07:19:53 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>

It's not a CI server, or does a build in mono. It runs on his Windows box in his office, and uploads the builds to Azure.  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx. So, Letterle ... keep doing what you're doing. =) But Foord is correct, that the builds should work in Mono just fine.

~js

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
Sent: Friday, January 23, 2009 7:08 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)

Indeed, but it doesn't regression test building on mono (or under linux).  Just wanted to confirm this wasn't happening since that's what I've been working on and don't want to duplicate efforts.
On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord <fuzzyman at voidspace.org.uk<mailto:fuzzyman at voidspace.org.uk>> wrote:
Michael Letterle wrote:
I assume this is a Window/.NET build? :)
Certainly as far as IronPython goes, binaries compiled on Windows work on Mono (modulo any Mono bugs).

Michael

On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi <Jimmy.Schementi at microsoft.com<mailto:Jimmy.Schementi at microsoft.com> <mailto:Jimmy.Schementi at microsoft.com<mailto:Jimmy.Schementi at microsoft.com>>> wrote:

   In case this is new to anyone ... Harry Pierson recently built a
   daily-build site for the IronPython and DLR Codeplex sites. Good
   news for IronRuby is it's included in the DLR Codeplex source
   repository (since IronRuby shares a source repository with DLR and
   IronPython, and the DLR Codeplex site is a daily-updated mirror of
   that repository).


   Here's the DLR Daily Build RSS Feed:

   http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr


   Pick your poison (debug/release/silverlight debug/silverlight
   release) and you'll get a build of IronRuby, IronPython, and the
   DLR in one package. Soon we'll have a continuous integration
   server which produces daily builds out of the git repository, but
   until then this may ease the pain in getting builds.


   ~js


   _______________________________________________
   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




--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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


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


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



--
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

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

From jgbailey at gmail.com  Fri Jan 23 12:35:58 2009
From: jgbailey at gmail.com (Justin Bailey)
Date: Fri, 23 Jan 2009 09:35:58 -0800
Subject: [Ironruby-core] Building IronRuby
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDD5@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <a45dff840901221645s3121098fwe2be12c6b5158c3d@mail.gmail.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FDDD5@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <a45dff840901230935oe85ae9as825d2027bfea366e@mail.gmail.com>

Thanks for the hint - I am able to build from the command line.

On Thu, Jan 22, 2009 at 5:30 PM, Jim Deville <jdeville at microsoft.com> wrote:
> Can you try command line? From Merlin\Main\Languages\Ruby, run "set MERLIN_ROOT=Path\To\Merlin\Main", then run "rake compile". I will try to have SpecSharp.targets moved in the next couple of pushes.
>
> Tomas: Do we still need the second copy of SpecSharp.targets in Merlin/Main/Languages/Ruby? Also, can I delete IronRuby.sln (leaving only Ruby.sln). If we don't need the SpecSharp.targets, I'll move it from Support back to Main, delete the one in Ruby and update references.
>
> JD
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Justin Bailey
> Sent: Thursday, January 22, 2009 4:45 PM
> To: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] Building IronRuby
>
> I've just gotten the latest ironruby bits from github and cannot
> build. Using Merlin\Main\Languagues\Ruby\IronRuby.sln:
>
>  * Can't open the Microsoft.Scripting project because it imports from
> "Merlin\Main\Support\SpecSharp.targets" which is not in the repo.
>  * Cryptographic failures when building because
> "Support\MSSharedLibKey.snk" does not exist.
>
> Removing the import statement from
> "Merlin\Main\Runtime\Microsoft.Scripting\Microsoft.Scripting.csproj"
> and creating a fake SNK file in the appropriate directory lets me get
> further, but I still can't build:
>
>  * 'IronRuby.Compiler.Methods' is inaccessible due to its protection
> leve Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs  29      77
>
>  * 'IronRuby.Runtime.Calls.BlockDispatcher' does not contain a
> definition for 'MaxBlockArity'  Merlin\Main\Languages\Ruby\ClassInitGenerator\ReflectionCacheGenerator.cs       102     59
>
> Basically a bunch of internal definitions look like they should be
> public. Am I missing something or did a bad commit slip through?
>
> Justin
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From Shri.Borde at microsoft.com  Fri Jan 23 14:15:28 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 23 Jan 2009 11:15:28 -0800
Subject: [Ironruby-core] Failure in library/ftools/makedirs_spec.rb
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094BD30@NA-EXMSG-C104.redmond.corp.microsoft.com>

This test fails the second time I run it. I have to then manually delete the makedirs_test folder that is created. The test tries to do system("rmdir makedirs_test/second_dir"), but that fails since "/" is used. How come its not failing in Snap? What is a platform-independent way of deleting a folder hierarchy?

c:\vsl\Merlin\External\Languages\IronRuby\mspec\rubyspec\library\ftools>runrspec -ruby ../library/ftools/makedirs_spec.rb

c:\vsl\Merlin\External\Languages\IronRuby\mspec\rubyspec\library\ftools>pushd c:\vsl\Merlin\Main\..\External\Languages\IronRuby\mspec

c:\vsl\Merlin\External\Languages\IronRuby\mspec>c:\vsl\Merlin\Main\..\External\Languages\Ruby\ruby-1.8.6\bin\ruby.exe mspec\bin\mspec-run -fd --verbose   --config default.mspec rubyspec/core/../library/ftools/makedirs_spec.rb

rubyspec/core/../library/ftools/makedirs_spec.rb
Parameter format not correct - "second_dir".
The directory is not empty.
F

1)
File.makedirs creates the dirs from arg FAILED
Expected true
 to equal false

./rubyspec/core/../library/ftools/makedirs_spec.rb:14
./rubyspec/core/../library/ftools/makedirs_spec.rb:2:in `all?'
./rubyspec/core/../library/ftools/makedirs_spec.rb:4
mspec/bin/mspec-run:8

Finished in 0.082000 seconds

1 file, 1 example, 1 expectation, 1 failure, 0 errors

Thanks,
Shri

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

From jdeville at microsoft.com  Fri Jan 23 14:41:33 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 23 Jan 2009 11:41:33 -0800
Subject: [Ironruby-core] Failure in library/ftools/makedirs_spec.rb
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094BD30@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BD30@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE04E@NA-EXMSG-C112.redmond.corp.microsoft.com>

FileUtils.rm_rf("target") is a platform independent way. It is also ok, because FileUtils is used by MSpec itself. It doesn't fail in SNAP because SNAP does a tfpt treeclean -delete between each run.

JD

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde
Sent: Friday, January 23, 2009 11:15 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Failure in library/ftools/makedirs_spec.rb

This test fails the second time I run it. I have to then manually delete the makedirs_test folder that is created. The test tries to do system("rmdir makedirs_test/second_dir"), but that fails since "/" is used. How come its not failing in Snap? What is a platform-independent way of deleting a folder hierarchy?

c:\vsl\Merlin\External\Languages\IronRuby\mspec\rubyspec\library\ftools>runrspec -ruby ../library/ftools/makedirs_spec.rb

c:\vsl\Merlin\External\Languages\IronRuby\mspec\rubyspec\library\ftools>pushd c:\vsl\Merlin\Main\..\External\Languages\IronRuby\mspec

c:\vsl\Merlin\External\Languages\IronRuby\mspec>c:\vsl\Merlin\Main\..\External\Languages\Ruby\ruby-1.8.6\bin\ruby.exe mspec\bin\mspec-run -fd --verbose   --config default.mspec rubyspec/core/../library/ftools/makedirs_spec.rb

rubyspec/core/../library/ftools/makedirs_spec.rb
Parameter format not correct - "second_dir".
The directory is not empty.
F

1)
File.makedirs creates the dirs from arg FAILED
Expected true
 to equal false

./rubyspec/core/../library/ftools/makedirs_spec.rb:14
./rubyspec/core/../library/ftools/makedirs_spec.rb:2:in `all?'
./rubyspec/core/../library/ftools/makedirs_spec.rb:4
mspec/bin/mspec-run:8

Finished in 0.082000 seconds

1 file, 1 example, 1 expectation, 1 failure, 0 errors

Thanks,
Shri

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

From Shri.Borde at microsoft.com  Fri Jan 23 17:04:04 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 23 Jan 2009 14:04:04 -0800
Subject: [Ironruby-core] Code Review: Better error messages
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:

  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.

  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.

  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.

  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.diff
Type: application/octet-stream
Size: 76269 bytes
Desc: error.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090123/fa79af49/attachment-0001.obj>

From ben2004uk at googlemail.com  Fri Jan 23 17:31:40 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Fri, 23 Jan 2009 22:31:40 +0000
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>

I just tried 10216 release on my OSX (just brought a MacBook Air).
IronPython works, however IronRuby throws the following exception:

Pretty:Release Ben$ mono ir.exe

Unhandled Exception: System.ArgumentException: Language name should
not be null, empty or duplicated between languages
Parameter name: names
  at Microsoft.Scripting.Utils.ContractUtils.Requires (Boolean
precondition, System.String paramName, System.String message)
[0x00000]
  at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
(System.String languageTypeName, System.String displayName, IList`1
names, IList`1 fileExtensions, IDictionary`2 options, System.String
paramName) [0x00000]
  at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
(System.String languageTypeName, System.String displayName, IList`1
names, IList`1 fileExtensions, IDictionary`2 options) [0x00000]
  at Microsoft.Scripting.Hosting.ScriptRuntimeSetup.ToConfiguration ()
[0x00000]
  at Microsoft.Scripting.Hosting.ScriptRuntime..ctor
(Microsoft.Scripting.Hosting.ScriptRuntimeSetup setup) [0x00000]
  at (wrapper remoting-invoke-with-check)
Microsoft.Scripting.Hosting.ScriptRuntime:.ctor
(Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
  at Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run
(System.String[] args) [0x00000]
  at RubyConsoleHost.Main (System.String[] args) [0x00000]






On Fri, Jan 23, 2009 at 3:19 PM, Jimmy Schementi
<Jimmy.Schementi at microsoft.com> wrote:
> It's not a CI server, or does a build in mono. It runs on his Windows box in
> his office, and uploads the builds to Azure.
>  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx. So,
> Letterle ? keep doing what you're doing. =) But Foord is correct, that the
> builds should work in Mono just fine.
>
>
>
> ~js
>
>
>
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle
> Sent: Friday, January 23, 2009 7:08 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
>
>
>
> Indeed, but it doesn't regression test building on mono (or under linux).
> Just wanted to confirm this wasn't happening since that's what I've been
> working on and don't want to duplicate efforts.
>
> On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord <fuzzyman at voidspace.org.uk>
> wrote:
>
> Michael Letterle wrote:
>
> I assume this is a Window/.NET build? :)
>
> Certainly as far as IronPython goes, binaries compiled on Windows work on
> Mono (modulo any Mono bugs).
>
> Michael
>
> On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi
> <Jimmy.Schementi at microsoft.com <mailto:Jimmy.Schementi at microsoft.com>>
> wrote:
>
>    In case this is new to anyone ? Harry Pierson recently built a
>    daily-build site for the IronPython and DLR Codeplex sites. Good
>    news for IronRuby is it's included in the DLR Codeplex source
>    repository (since IronRuby shares a source repository with DLR and
>    IronPython, and the DLR Codeplex site is a daily-updated mirror of
>    that repository).
>
>
>    Here's the DLR Daily Build RSS Feed:
>
>    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
>
>
>    Pick your poison (debug/release/silverlight debug/silverlight
>    release) and you'll get a build of IronRuby, IronPython, and the
>    DLR in one package. Soon we'll have a continuous integration
>    server which produces daily builds out of the git repository, but
>    until then this may ease the pain in getting builds.
>
>
>    ~js
>
>
>    _______________________________________________
>    Ironruby-core mailing list
>
>    Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
>
>    http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> --
> Michael Letterle
> [Polymath Prokrammer]
> http://blog.prokrams.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> --
> Michael Letterle
> [Polymath Prokrammer]
> http://blog.prokrams.com
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>

From Jimmy.Schementi at microsoft.com  Fri Jan 23 17:36:02 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 23 Jan 2009 14:36:02 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>

Mmm, the Air is nice =) which build of Mono is that?

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Friday, January 23, 2009 2:32 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
> 
> I just tried 10216 release on my OSX (just brought a MacBook Air).
> IronPython works, however IronRuby throws the following exception:
> 
> Pretty:Release Ben$ mono ir.exe
> 
> Unhandled Exception: System.ArgumentException: Language name should
> not be null, empty or duplicated between languages
> Parameter name: names
>   at Microsoft.Scripting.Utils.ContractUtils.Requires (Boolean
> precondition, System.String paramName, System.String message)
> [0x00000]
>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> (System.String languageTypeName, System.String displayName, IList`1
> names, IList`1 fileExtensions, IDictionary`2 options, System.String
> paramName) [0x00000]
>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> (System.String languageTypeName, System.String displayName, IList`1
> names, IList`1 fileExtensions, IDictionary`2 options) [0x00000]
>   at Microsoft.Scripting.Hosting.ScriptRuntimeSetup.ToConfiguration ()
> [0x00000]
>   at Microsoft.Scripting.Hosting.ScriptRuntime..ctor
> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup setup) [0x00000]
>   at (wrapper remoting-invoke-with-check)
> Microsoft.Scripting.Hosting.ScriptRuntime:.ctor
> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
>   at Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run
> (System.String[] args) [0x00000]
>   at RubyConsoleHost.Main (System.String[] args) [0x00000]
> 
> 
> 
> 
> 
> 
> On Fri, Jan 23, 2009 at 3:19 PM, Jimmy Schementi
> <Jimmy.Schementi at microsoft.com> wrote:
> > It's not a CI server, or does a build in mono. It runs on his Windows
> box in
> > his office, and uploads the builds to Azure.
> >  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx.
> So,
> > Letterle ... keep doing what you're doing. =) But Foord is correct,
> that the
> > builds should work in Mono just fine.
> >
> >
> >
> > ~js
> >
> >
> >
> > From: ironruby-core-bounces at rubyforge.org
> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael
> Letterle
> > Sent: Friday, January 23, 2009 7:08 AM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
> >
> >
> >
> > Indeed, but it doesn't regression test building on mono (or under
> linux).
> > Just wanted to confirm this wasn't happening since that's what I've
> been
> > working on and don't want to duplicate efforts.
> >
> > On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord
> <fuzzyman at voidspace.org.uk>
> > wrote:
> >
> > Michael Letterle wrote:
> >
> > I assume this is a Window/.NET build? :)
> >
> > Certainly as far as IronPython goes, binaries compiled on Windows
> work on
> > Mono (modulo any Mono bugs).
> >
> > Michael
> >
> > On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi
> > <Jimmy.Schementi at microsoft.com
> <mailto:Jimmy.Schementi at microsoft.com>>
> > wrote:
> >
> >    In case this is new to anyone ... Harry Pierson recently built a
> >    daily-build site for the IronPython and DLR Codeplex sites. Good
> >    news for IronRuby is it's included in the DLR Codeplex source
> >    repository (since IronRuby shares a source repository with DLR and
> >    IronPython, and the DLR Codeplex site is a daily-updated mirror of
> >    that repository).
> >
> >
> >    Here's the DLR Daily Build RSS Feed:
> >
> >    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
> >
> >
> >    Pick your poison (debug/release/silverlight debug/silverlight
> >    release) and you'll get a build of IronRuby, IronPython, and the
> >    DLR in one package. Soon we'll have a continuous integration
> >    server which produces daily builds out of the git repository, but
> >    until then this may ease the pain in getting builds.
> >
> >
> >    ~js
> >
> >
> >    _______________________________________________
> >    Ironruby-core mailing list
> >
> >    Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
> >
> >    http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> >
> >
> > --
> > Michael Letterle
> > [Polymath Prokrammer]
> > http://blog.prokrams.com
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> > --
> > Michael Letterle
> > [Polymath Prokrammer]
> > http://blog.prokrams.com
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From Tomas.Matousek at microsoft.com  Fri Jan 23 17:42:07 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 23 Jan 2009 14:42:07 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24D4F980@NA-EXMSG-C112.redmond.corp.microsoft.com>

This might be a problem with signing. Is your IronRuby assembly delay-signed?

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
Sent: Friday, January 23, 2009 2:36 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)

Mmm, the Air is nice =) which build of Mono is that?

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Friday, January 23, 2009 2:32 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
>
> I just tried 10216 release on my OSX (just brought a MacBook Air).
> IronPython works, however IronRuby throws the following exception:
>
> Pretty:Release Ben$ mono ir.exe
>
> Unhandled Exception: System.ArgumentException: Language name should
> not be null, empty or duplicated between languages
> Parameter name: names
>   at Microsoft.Scripting.Utils.ContractUtils.Requires (Boolean
> precondition, System.String paramName, System.String message)
> [0x00000]
>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> (System.String languageTypeName, System.String displayName, IList`1
> names, IList`1 fileExtensions, IDictionary`2 options, System.String
> paramName) [0x00000]
>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> (System.String languageTypeName, System.String displayName, IList`1
> names, IList`1 fileExtensions, IDictionary`2 options) [0x00000]
>   at Microsoft.Scripting.Hosting.ScriptRuntimeSetup.ToConfiguration ()
> [0x00000]
>   at Microsoft.Scripting.Hosting.ScriptRuntime..ctor
> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup setup) [0x00000]
>   at (wrapper remoting-invoke-with-check)
> Microsoft.Scripting.Hosting.ScriptRuntime:.ctor
> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
>   at Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run
> (System.String[] args) [0x00000]
>   at RubyConsoleHost.Main (System.String[] args) [0x00000]
>
>
>
>
>
>
> On Fri, Jan 23, 2009 at 3:19 PM, Jimmy Schementi
> <Jimmy.Schementi at microsoft.com> wrote:
> > It's not a CI server, or does a build in mono. It runs on his Windows
> box in
> > his office, and uploads the builds to Azure.
> >  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx.
> So,
> > Letterle ... keep doing what you're doing. =) But Foord is correct,
> that the
> > builds should work in Mono just fine.
> >
> >
> >
> > ~js
> >
> >
> >
> > From: ironruby-core-bounces at rubyforge.org
> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael
> Letterle
> > Sent: Friday, January 23, 2009 7:08 AM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
> >
> >
> >
> > Indeed, but it doesn't regression test building on mono (or under
> linux).
> > Just wanted to confirm this wasn't happening since that's what I've
> been
> > working on and don't want to duplicate efforts.
> >
> > On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord
> <fuzzyman at voidspace.org.uk>
> > wrote:
> >
> > Michael Letterle wrote:
> >
> > I assume this is a Window/.NET build? :)
> >
> > Certainly as far as IronPython goes, binaries compiled on Windows
> work on
> > Mono (modulo any Mono bugs).
> >
> > Michael
> >
> > On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi
> > <Jimmy.Schementi at microsoft.com
> <mailto:Jimmy.Schementi at microsoft.com>>
> > wrote:
> >
> >    In case this is new to anyone ... Harry Pierson recently built a
> >    daily-build site for the IronPython and DLR Codeplex sites. Good
> >    news for IronRuby is it's included in the DLR Codeplex source
> >    repository (since IronRuby shares a source repository with DLR and
> >    IronPython, and the DLR Codeplex site is a daily-updated mirror of
> >    that repository).
> >
> >
> >    Here's the DLR Daily Build RSS Feed:
> >
> >    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
> >
> >
> >    Pick your poison (debug/release/silverlight debug/silverlight
> >    release) and you'll get a build of IronRuby, IronPython, and the
> >    DLR in one package. Soon we'll have a continuous integration
> >    server which produces daily builds out of the git repository, but
> >    until then this may ease the pain in getting builds.
> >
> >
> >    ~js
> >
> >
> >    _______________________________________________
> >    Ironruby-core mailing list
> >
> >    Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
> >
> >    http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> >
> >
> > --
> > Michael Letterle
> > [Polymath Prokrammer]
> > http://blog.prokrams.com
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> > --
> > Michael Letterle
> > [Polymath Prokrammer]
> > http://blog.prokrams.com
> >
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

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


From ben2004uk at googlemail.com  Fri Jan 23 17:52:51 2009
From: ben2004uk at googlemail.com (Ben Hall)
Date: Fri, 23 Jan 2009 22:52:51 +0000
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <a04554c00901231452q1deabe6ekbe8b01530d50d0f3@mail.gmail.com>

The mono build is the latest one available from their main website for OSX....

Pretty:~ Ben$ mono --version
Mono JIT compiler version 2.2 (tarball Fri Jan  9 10:45:07 MST 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
	TLS:           normal
	GC:            Included Boehm (with typed GC)
	SIGSEGV:       normal
	Notification:  Thread + polling
	Architecture:  x86
	Disabled:      none


On Fri, Jan 23, 2009 at 10:36 PM, Jimmy Schementi
<Jimmy.Schementi at microsoft.com> wrote:
> Mmm, the Air is nice =) which build of Mono is that?
>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
>> bounces at rubyforge.org] On Behalf Of Ben Hall
>> Sent: Friday, January 23, 2009 2:32 PM
>> To: ironruby-core at rubyforge.org
>> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
>>
>> I just tried 10216 release on my OSX (just brought a MacBook Air).
>> IronPython works, however IronRuby throws the following exception:
>>
>> Pretty:Release Ben$ mono ir.exe
>>
>> Unhandled Exception: System.ArgumentException: Language name should
>> not be null, empty or duplicated between languages
>> Parameter name: names
>>   at Microsoft.Scripting.Utils.ContractUtils.Requires (Boolean
>> precondition, System.String paramName, System.String message)
>> [0x00000]
>>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
>> (System.String languageTypeName, System.String displayName, IList`1
>> names, IList`1 fileExtensions, IDictionary`2 options, System.String
>> paramName) [0x00000]
>>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
>> (System.String languageTypeName, System.String displayName, IList`1
>> names, IList`1 fileExtensions, IDictionary`2 options) [0x00000]
>>   at Microsoft.Scripting.Hosting.ScriptRuntimeSetup.ToConfiguration ()
>> [0x00000]
>>   at Microsoft.Scripting.Hosting.ScriptRuntime..ctor
>> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup setup) [0x00000]
>>   at (wrapper remoting-invoke-with-check)
>> Microsoft.Scripting.Hosting.ScriptRuntime:.ctor
>> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
>>   at Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run
>> (System.String[] args) [0x00000]
>>   at RubyConsoleHost.Main (System.String[] args) [0x00000]
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 23, 2009 at 3:19 PM, Jimmy Schementi
>> <Jimmy.Schementi at microsoft.com> wrote:
>> > It's not a CI server, or does a build in mono. It runs on his Windows
>> box in
>> > his office, and uploads the builds to Azure.
>> >  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx.
>> So,
>> > Letterle ... keep doing what you're doing. =) But Foord is correct,
>> that the
>> > builds should work in Mono just fine.
>> >
>> >
>> >
>> > ~js
>> >
>> >
>> >
>> > From: ironruby-core-bounces at rubyforge.org
>> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael
>> Letterle
>> > Sent: Friday, January 23, 2009 7:08 AM
>> > To: ironruby-core at rubyforge.org
>> > Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
>> >
>> >
>> >
>> > Indeed, but it doesn't regression test building on mono (or under
>> linux).
>> > Just wanted to confirm this wasn't happening since that's what I've
>> been
>> > working on and don't want to duplicate efforts.
>> >
>> > On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk>
>> > wrote:
>> >
>> > Michael Letterle wrote:
>> >
>> > I assume this is a Window/.NET build? :)
>> >
>> > Certainly as far as IronPython goes, binaries compiled on Windows
>> work on
>> > Mono (modulo any Mono bugs).
>> >
>> > Michael
>> >
>> > On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi
>> > <Jimmy.Schementi at microsoft.com
>> <mailto:Jimmy.Schementi at microsoft.com>>
>> > wrote:
>> >
>> >    In case this is new to anyone ... Harry Pierson recently built a
>> >    daily-build site for the IronPython and DLR Codeplex sites. Good
>> >    news for IronRuby is it's included in the DLR Codeplex source
>> >    repository (since IronRuby shares a source repository with DLR and
>> >    IronPython, and the DLR Codeplex site is a daily-updated mirror of
>> >    that repository).
>> >
>> >
>> >    Here's the DLR Daily Build RSS Feed:
>> >
>> >    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
>> >
>> >
>> >    Pick your poison (debug/release/silverlight debug/silverlight
>> >    release) and you'll get a build of IronRuby, IronPython, and the
>> >    DLR in one package. Soon we'll have a continuous integration
>> >    server which produces daily builds out of the git repository, but
>> >    until then this may ease the pain in getting builds.
>> >
>> >
>> >    ~js
>> >
>> >
>> >    _______________________________________________
>> >    Ironruby-core mailing list
>> >
>> >    Ironruby-core at rubyforge.org <mailto:Ironruby-core at rubyforge.org>
>> >
>> >    http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>> >
>> >
>> > --
>> > Michael Letterle
>> > [Polymath Prokrammer]
>> > http://blog.prokrams.com
>> >
>> > ---------------------------------------------------------------------
>> ---
>> >
>> > _______________________________________________
>> > Ironruby-core mailing list
>> > Ironruby-core at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>> > _______________________________________________
>> > Ironruby-core mailing list
>> > Ironruby-core at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>> > --
>> > Michael Letterle
>> > [Polymath Prokrammer]
>> > http://blog.prokrams.com
>> >
>> >
>> > _______________________________________________
>> > Ironruby-core mailing list
>> > Ironruby-core at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/ironruby-core
>> >
>> >
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From jdeville at microsoft.com  Fri Jan 23 18:04:37 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 23 Jan 2009 15:04:37 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>

it "coerces string argument with Float() without calling singleton to_f" do    
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
  
  it "coerces string argument with Float() without calling String#to_f" do    
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes. 

it "coerces string argument with Float() without calling singleton to_f" do    
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
   
  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:
  
  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.
  
  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.
  
  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.
  
  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From Jimmy.Schementi at microsoft.com  Fri Jan 23 18:11:25 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 23 Jan 2009 15:11:25 -0800
Subject: [Ironruby-core] DLR Daily Builds (including IronRuby)
In-Reply-To: <a04554c00901231452q1deabe6ekbe8b01530d50d0f3@mail.gmail.com>
References: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497AC4@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<ef5222770901230602qfc392e6i20ca6a21ac1f2e8c@mail.gmail.com>
	<4979CF04.9080006@voidspace.org.uk>
	<ef5222770901230707o74581432ic27967d3d8d72aa@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497B52@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a04554c00901231431i1a5a1053m66e4f9263adfc707@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497E7A@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<a04554c00901231452q1deabe6ekbe8b01530d50d0f3@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BDF497EA9@NA-EXMSG-C116.redmond.corp.microsoft.com>

Oy, something's slightly messed up. The ir.exe.config file that is created is for a signed-version of ir.exe, but the DLR codeplex build produces unsigned binaries. We're going to be delay-signing everything, but I'm not sure why IPy is fine and IR isn't.

Make your ir.exe.config file the following, and it'll work (I just set PublicKeyToken=null anywhere it was PublicKeyToken=3..., and removed the Python/JS <language> nodes). And update your "LibraryPaths" to point to the IronRuby libraries on your machine.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="microsoft.scripting" type="Microsoft.Scripting.Hosting.Configuration.Section, Microsoft.Scripting, Version=1.0.0.5000, Culture=neutral, PublicKeyToken=null" requirePermission="false" />
  </configSections>

  <microsoft.scripting>
    <languages>
      <language names="IronRuby;Ruby;rb" extensions=".rb" displayName="IronRuby 1.0 Alpha" type="IronRuby.Runtime.RubyContext, IronRuby, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </languages>
    <options>
      <set language="Ruby" option="LibraryPaths" value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\1.8\" />
    </options>
  </microsoft.scripting>
</configuration>

~js

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Ben Hall
> Sent: Friday, January 23, 2009 2:53 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
>
> The mono build is the latest one available from their main website for
> OSX....
>
> Pretty:~ Ben$ mono --version
> Mono JIT compiler version 2.2 (tarball Fri Jan  9 10:45:07 MST 2009)
> Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-
> project.com
>         TLS:           normal
>         GC:            Included Boehm (with typed GC)
>         SIGSEGV:       normal
>         Notification:  Thread + polling
>         Architecture:  x86
>         Disabled:      none
>
>
> On Fri, Jan 23, 2009 at 10:36 PM, Jimmy Schementi
> <Jimmy.Schementi at microsoft.com> wrote:
> > Mmm, the Air is nice =) which build of Mono is that?
> >
> >> -----Original Message-----
> >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> >> bounces at rubyforge.org] On Behalf Of Ben Hall
> >> Sent: Friday, January 23, 2009 2:32 PM
> >> To: ironruby-core at rubyforge.org
> >> Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
> >>
> >> I just tried 10216 release on my OSX (just brought a MacBook Air).
> >> IronPython works, however IronRuby throws the following exception:
> >>
> >> Pretty:Release Ben$ mono ir.exe
> >>
> >> Unhandled Exception: System.ArgumentException: Language name should
> >> not be null, empty or duplicated between languages
> >> Parameter name: names
> >>   at Microsoft.Scripting.Utils.ContractUtils.Requires (Boolean
> >> precondition, System.String paramName, System.String message)
> >> [0x00000]
> >>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> >> (System.String languageTypeName, System.String displayName, IList`1
> >> names, IList`1 fileExtensions, IDictionary`2 options, System.String
> >> paramName) [0x00000]
> >>   at Microsoft.Scripting.Runtime.DlrConfiguration.AddLanguage
> >> (System.String languageTypeName, System.String displayName, IList`1
> >> names, IList`1 fileExtensions, IDictionary`2 options) [0x00000]
> >>   at Microsoft.Scripting.Hosting.ScriptRuntimeSetup.ToConfiguration
> ()
> >> [0x00000]
> >>   at Microsoft.Scripting.Hosting.ScriptRuntime..ctor
> >> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup setup) [0x00000]
> >>   at (wrapper remoting-invoke-with-check)
> >> Microsoft.Scripting.Hosting.ScriptRuntime:.ctor
> >> (Microsoft.Scripting.Hosting.ScriptRuntimeSetup)
> >>   at Microsoft.Scripting.Hosting.Shell.ConsoleHost.Run
> >> (System.String[] args) [0x00000]
> >>   at RubyConsoleHost.Main (System.String[] args) [0x00000]
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Jan 23, 2009 at 3:19 PM, Jimmy Schementi
> >> <Jimmy.Schementi at microsoft.com> wrote:
> >> > It's not a CI server, or does a build in mono. It runs on his
> Windows
> >> box in
> >> > his office, and uploads the builds to Azure.
> >> >  http://devhawk.net/2009/01/07/Nightly+Builds+Technical+Info.aspx.
> >> So,
> >> > Letterle ... keep doing what you're doing. =) But Foord is
> correct,
> >> that the
> >> > builds should work in Mono just fine.
> >> >
> >> >
> >> >
> >> > ~js
> >> >
> >> >
> >> >
> >> > From: ironruby-core-bounces at rubyforge.org
> >> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael
> >> Letterle
> >> > Sent: Friday, January 23, 2009 7:08 AM
> >> > To: ironruby-core at rubyforge.org
> >> > Subject: Re: [Ironruby-core] DLR Daily Builds (including IronRuby)
> >> >
> >> >
> >> >
> >> > Indeed, but it doesn't regression test building on mono (or under
> >> linux).
> >> > Just wanted to confirm this wasn't happening since that's what
> I've
> >> been
> >> > working on and don't want to duplicate efforts.
> >> >
> >> > On Fri, Jan 23, 2009 at 9:07 AM, Michael Foord
> >> <fuzzyman at voidspace.org.uk>
> >> > wrote:
> >> >
> >> > Michael Letterle wrote:
> >> >
> >> > I assume this is a Window/.NET build? :)
> >> >
> >> > Certainly as far as IronPython goes, binaries compiled on Windows
> >> work on
> >> > Mono (modulo any Mono bugs).
> >> >
> >> > Michael
> >> >
> >> > On Fri, Jan 23, 2009 at 1:05 AM, Jimmy Schementi
> >> > <Jimmy.Schementi at microsoft.com
> >> <mailto:Jimmy.Schementi at microsoft.com>>
> >> > wrote:
> >> >
> >> >    In case this is new to anyone ... Harry Pierson recently built
> a
> >> >    daily-build site for the IronPython and DLR Codeplex sites.
> Good
> >> >    news for IronRuby is it's included in the DLR Codeplex source
> >> >    repository (since IronRuby shares a source repository with DLR
> and
> >> >    IronPython, and the DLR Codeplex site is a daily-updated mirror
> of
> >> >    that repository).
> >> >
> >> >
> >> >    Here's the DLR Daily Build RSS Feed:
> >> >
> >> >    http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
> >> >
> >> >
> >> >    Pick your poison (debug/release/silverlight debug/silverlight
> >> >    release) and you'll get a build of IronRuby, IronPython, and
> the
> >> >    DLR in one package. Soon we'll have a continuous integration
> >> >    server which produces daily builds out of the git repository,
> but
> >> >    until then this may ease the pain in getting builds.
> >> >
> >> >
> >> >    ~js
> >> >
> >> >
> >> >    _______________________________________________
> >> >    Ironruby-core mailing list
> >> >
> >> >    Ironruby-core at rubyforge.org <mailto:Ironruby-
> core at rubyforge.org>
> >> >
> >> >    http://rubyforge.org/mailman/listinfo/ironruby-core
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Michael Letterle
> >> > [Polymath Prokrammer]
> >> > http://blog.prokrams.com
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> ---
> >> >
> >> > _______________________________________________
> >> > Ironruby-core mailing list
> >> > Ironruby-core at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >> >
> >> >
> >> > _______________________________________________
> >> > Ironruby-core mailing list
> >> > Ironruby-core at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >> >
> >> >
> >> > --
> >> > Michael Letterle
> >> > [Polymath Prokrammer]
> >> > http://blog.prokrams.com
> >> >
> >> >
> >> > _______________________________________________
> >> > Ironruby-core mailing list
> >> > Ironruby-core at rubyforge.org
> >> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >> >
> >> >
> >> _______________________________________________
> >> Ironruby-core mailing list
> >> Ironruby-core at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From jdeville at microsoft.com  Fri Jan 23 18:11:20 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 23 Jan 2009 15:11:20 -0800
Subject: [Ironruby-core] Code Review: compilefix
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE178@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:compilefix;REDMOND\jdeville"
  Comment  :
  This shelveset removes the project transforms from the Ruby rakefiles. This means that there is no longer a need to set MERLIN_ROOT for external contributors.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compilefix.diff
Type: application/octet-stream
Size: 67750 bytes
Desc: compilefix.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090123/ccc257dc/attachment-0001.obj>

From Tomas.Matousek at microsoft.com  Sat Jan 24 02:44:12 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 23 Jan 2009 23:44:12 -0800
Subject: [Ironruby-core] Code Review: ThreadSafety7
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24D4FA92@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:ThreadSafety7;REDMOND\tomat"
  Comment  : 
    Makes operations on class hierarchy thread-safe. A class-hierarchy lock is defined on RubyContext. The lock should be acquired by any reader or writer that accesses the mutable state on hierarchy (such as method and constant tables on modules/classes, mixin lists, etc.).
    
    Fixes implementation of private/public/protected/module_function that take a list of symbols. These methods define a stub method in the current module that has given visibility and forwards any call to it to super class (as if "super" was used). Implements this behavior via RubyMemberInfo with SuperForwarder flag set.
    
    Improves generated initializers to generate more efficient code.
    
    Fixes bugs:
    [ ironruby-Bugs-23510 ] Methods are being cloned  when they are private in subclasses
    [ ironruby-Bugs-22362 ] module_function

Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThreadSafety7.diff
Type: application/octet-stream
Size: 1396693 bytes
Desc: ThreadSafety7.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090123/4b333409/attachment-0001.obj>

From Shri.Borde at microsoft.com  Sat Jan 24 17:35:45 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Sat, 24 Jan 2009 14:35:45 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>

Jim, using should_not_receive sounds like a good idea. Will do the change.

But we still need all those specs including the one using hijack_String_to_f. It is not testing method dispatch. Ruby method dispatch only controls which method body will be called. It does not do argument conversions. That is handled by the target method which is free to use to_f to convert the argument to a float, but is not required to. The specs below will ensure that the library method does follow the right convention/protocol for converting the argument to a float. Does that make sense?



Also, I had this comment:

/// <summary>
/// An overload with a block should get precedence. However, Microsoft.Scripting.Action.Calls.MethodBinder
/// gives precedence to overloads with a matching number of arguments as the actual arguments. Consider Object#eval
/// which effectively has the following two overloads in the Ruby sense.
///     obj.instance_eval(string [, filename [, lineno]] ) => obj
///     obj.instance_eval {| | block } => obj
/// Consider this call:
///     obj.instance_eval(2, 3) { }
/// This should match with the second Ruby overload, and report an ArgumentError because of the mismatch in the number of arguments.
/// However, the MethodBinder will prefer the first Ruby overload as it has a matching number of arguments, and will report
/// a type-mismatch instead.
/// Filterting down the overload list upfront yields better errors.
/// </summary>

Tomas pointed out that this filtering was incorrect. Tomas, it did cause test failures (My last test pass had this filtering done in error-handling after the MethodBinder did its stuff).

However, overloads do get precedence in some cases like the instance_eval example in the comment above, and also with Array#fill as shown below. There is a RubySpec test for Array#fill, but we have a tag because we get it wrong. I agree with Tomas that this will need to be handled more carefully, and we might need to have an attribute on the library methods indicating whether the block gets precedence, or whether the argument count gets precedence in selecting the method overload. I will undo my change for now.

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "coerces string argument with Float() without calling String#to_f" do
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes.

it "coerces string argument with Float() without calling singleton to_f" do
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:

  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.

  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.

  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.

  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From Tomas.Matousek at microsoft.com  Sat Jan 24 18:03:14 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 24 Jan 2009 15:03:14 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24D4FACB@NA-EXMSG-C112.redmond.corp.microsoft.com>

The question is whether we need to copy the exact error reporting for argument mismatch, or whether best effort approach isn't good enough. The advantage of the current behavior is a simpler binder. We can certainly add attributes that will prioritize some overloads but it would make the binder more complicated. I don't see a scenario where it makes sense for an app to catch ArgumentErrors and depend on it. Array#fill behavior might also be considered a bug in MRI.

Tomas

-----Original Message-----

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "coerces string argument with Float() without calling String#to_f" do
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes.

it "coerces string argument with Float() without calling singleton to_f" do
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:

  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.

  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.

  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.

  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From Shri.Borde at microsoft.com  Sat Jan 24 18:10:41 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Sat, 24 Jan 2009 15:10:41 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B24D4FACB@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24D4FACB@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094C072@NA-EXMSG-C104.redmond.corp.microsoft.com>

Agreed, this is a negative scenario and exact error reporting is not a priority in such contrived scenarios.

-----Original Message-----
From: Tomas Matousek 
Sent: Saturday, January 24, 2009 3:03 PM
To: Shri Borde; Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

The question is whether we need to copy the exact error reporting for argument mismatch, or whether best effort approach isn't good enough. The advantage of the current behavior is a simpler binder. We can certainly add attributes that will prioritize some overloads but it would make the binder more complicated. I don't see a scenario where it makes sense for an app to catch ArgumentErrors and depend on it. Array#fill behavior might also be considered a bug in MRI.

Tomas

-----Original Message-----

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville 
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do    
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
  
  it "coerces string argument with Float() without calling String#to_f" do    
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes. 

it "coerces string argument with Float() without calling singleton to_f" do    
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
   
  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:
  
  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.
  
  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.
  
  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.
  
  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From jdeville at microsoft.com  Sat Jan 24 19:25:50 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sat, 24 Jan 2009 16:25:50 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE224@NA-EXMSG-C112.redmond.corp.microsoft.com>

Tomas, correct me if I'm wrong, but Ruby uses a message based method dispatch. When to_f is called, the message to_f gets sent to the object, and then normal method resolution occurs. There is no way to bypass that resolution. You can't call String#to_f instead of the singleton class's to_f. You call to_f on the object, and it sends the message. That is why I argue those tests are the same. If we have the ability, or the possibility of something different, then something is wrong with our method dispatch an method resolution. That should be exposed in the method tests in Language specs. This spec doesn't need both the case of a classes instance method and a singleton instance method.

JD

-----Original Message-----
From: Shri Borde
Sent: Saturday, January 24, 2009 2:36 PM
To: Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Jim, using should_not_receive sounds like a good idea. Will do the change.

But we still need all those specs including the one using hijack_String_to_f. It is not testing method dispatch. Ruby method dispatch only controls which method body will be called. It does not do argument conversions. That is handled by the target method which is free to use to_f to convert the argument to a float, but is not required to. The specs below will ensure that the library method does follow the right convention/protocol for converting the argument to a float. Does that make sense?



Also, I had this comment:

/// <summary>
/// An overload with a block should get precedence. However, Microsoft.Scripting.Action.Calls.MethodBinder
/// gives precedence to overloads with a matching number of arguments as the actual arguments. Consider Object#eval
/// which effectively has the following two overloads in the Ruby sense.
///     obj.instance_eval(string [, filename [, lineno]] ) => obj
///     obj.instance_eval {| | block } => obj
/// Consider this call:
///     obj.instance_eval(2, 3) { }
/// This should match with the second Ruby overload, and report an ArgumentError because of the mismatch in the number of arguments.
/// However, the MethodBinder will prefer the first Ruby overload as it has a matching number of arguments, and will report
/// a type-mismatch instead.
/// Filterting down the overload list upfront yields better errors.
/// </summary>

Tomas pointed out that this filtering was incorrect. Tomas, it did cause test failures (My last test pass had this filtering done in error-handling after the MethodBinder did its stuff).

However, overloads do get precedence in some cases like the instance_eval example in the comment above, and also with Array#fill as shown below. There is a RubySpec test for Array#fill, but we have a tag because we get it wrong. I agree with Tomas that this will need to be handled more carefully, and we might need to have an attribute on the library methods indicating whether the block gets precedence, or whether the argument count gets precedence in selecting the method overload. I will undo my change for now.

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "coerces string argument with Float() without calling String#to_f" do
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes.

it "coerces string argument with Float() without calling singleton to_f" do
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:

  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.

  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.

  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.

  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From Tomas.Matousek at microsoft.com  Sun Jan 25 01:57:39 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 24 Jan 2009 22:57:39 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE224@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE224@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B24D4FAE8@NA-EXMSG-C112.redmond.corp.microsoft.com>

I believe Jim is right. Library methods performing conversions (or other operations) do so either by calling internal C methods or using regular Ruby method dispatch. The former can't be detected from Ruby except for using a tracing proc (set_trace_func). Method dispatch goes to the singleton of the object first and then to its class. So the use of should_not_receive ensures that to_f is not invoked on the given object. 

Tomas

-----Original Message-----
From: Jim Deville 
Sent: Saturday, January 24, 2009 4:26 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Tomas, correct me if I'm wrong, but Ruby uses a message based method dispatch. When to_f is called, the message to_f gets sent to the object, and then normal method resolution occurs. There is no way to bypass that resolution. You can't call String#to_f instead of the singleton class's to_f. You call to_f on the object, and it sends the message. That is why I argue those tests are the same. If we have the ability, or the possibility of something different, then something is wrong with our method dispatch an method resolution. That should be exposed in the method tests in Language specs. This spec doesn't need both the case of a classes instance method and a singleton instance method.

JD

-----Original Message-----
From: Shri Borde 
Sent: Saturday, January 24, 2009 2:36 PM
To: Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Jim, using should_not_receive sounds like a good idea. Will do the change.

But we still need all those specs including the one using hijack_String_to_f. It is not testing method dispatch. Ruby method dispatch only controls which method body will be called. It does not do argument conversions. That is handled by the target method which is free to use to_f to convert the argument to a float, but is not required to. The specs below will ensure that the library method does follow the right convention/protocol for converting the argument to a float. Does that make sense?



Also, I had this comment:

/// <summary>
/// An overload with a block should get precedence. However, Microsoft.Scripting.Action.Calls.MethodBinder
/// gives precedence to overloads with a matching number of arguments as the actual arguments. Consider Object#eval
/// which effectively has the following two overloads in the Ruby sense.
///     obj.instance_eval(string [, filename [, lineno]] ) => obj
///     obj.instance_eval {| | block } => obj
/// Consider this call:
///     obj.instance_eval(2, 3) { }
/// This should match with the second Ruby overload, and report an ArgumentError because of the mismatch in the number of arguments.
/// However, the MethodBinder will prefer the first Ruby overload as it has a matching number of arguments, and will report
/// a type-mismatch instead. 
/// Filterting down the overload list upfront yields better errors.
/// </summary> 

Tomas pointed out that this filtering was incorrect. Tomas, it did cause test failures (My last test pass had this filtering done in error-handling after the MethodBinder did its stuff). 

However, overloads do get precedence in some cases like the instance_eval example in the comment above, and also with Array#fill as shown below. There is a RubySpec test for Array#fill, but we have a tag because we get it wrong. I agree with Tomas that this will need to be handled more carefully, and we might need to have an attribute on the library methods indicating whether the block gets precedence, or whether the argument count gets precedence in selecting the method overload. I will undo my change for now.

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville 
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do    
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
  
  it "coerces string argument with Float() without calling String#to_f" do    
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes. 

it "coerces string argument with Float() without calling singleton to_f" do    
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
   
  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:
  
  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.
  
  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.
  
  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.
  
  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From Shri.Borde at microsoft.com  Sun Jan 25 02:21:19 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Sat, 24 Jan 2009 23:21:19 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B24D4FAE8@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE224@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24D4FAE8@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD094C09B@NA-EXMSG-C104.redmond.corp.microsoft.com>

The test below actually shows that the singleton to_f is not called. Similarly, a string like "1.0" gets converted to a Float even after undef-ing String#to_f. So the library methods are *not* calling to_f on strings at all, but are directly converting the string contents to a Float value.

The question is not whether should_not_receive ensures that to_f is not invoked (I agree that we should use this API). The question is whether we need the testing of all these cases for the default protocol for converting Float arguments, or if its redundant with language tests testing method dispatch. The language tests will cover the conversions done in the libraries.

-----Original Message-----
From: Tomas Matousek 
Sent: Saturday, January 24, 2009 10:58 PM
To: Jim Deville; Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

I believe Jim is right. Library methods performing conversions (or other operations) do so either by calling internal C methods or using regular Ruby method dispatch. The former can't be detected from Ruby except for using a tracing proc (set_trace_func). Method dispatch goes to the singleton of the object first and then to its class. So the use of should_not_receive ensures that to_f is not invoked on the given object. 

Tomas

-----Original Message-----
From: Jim Deville 
Sent: Saturday, January 24, 2009 4:26 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Tomas, correct me if I'm wrong, but Ruby uses a message based method dispatch. When to_f is called, the message to_f gets sent to the object, and then normal method resolution occurs. There is no way to bypass that resolution. You can't call String#to_f instead of the singleton class's to_f. You call to_f on the object, and it sends the message. That is why I argue those tests are the same. If we have the ability, or the possibility of something different, then something is wrong with our method dispatch an method resolution. That should be exposed in the method tests in Language specs. This spec doesn't need both the case of a classes instance method and a singleton instance method.

JD

-----Original Message-----
From: Shri Borde 
Sent: Saturday, January 24, 2009 2:36 PM
To: Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Jim, using should_not_receive sounds like a good idea. Will do the change.

But we still need all those specs including the one using hijack_String_to_f. It is not testing method dispatch. Ruby method dispatch only controls which method body will be called. It does not do argument conversions. That is handled by the target method which is free to use to_f to convert the argument to a float, but is not required to. The specs below will ensure that the library method does follow the right convention/protocol for converting the argument to a float. Does that make sense?



Also, I had this comment:

/// <summary>
/// An overload with a block should get precedence. However, Microsoft.Scripting.Action.Calls.MethodBinder
/// gives precedence to overloads with a matching number of arguments as the actual arguments. Consider Object#eval
/// which effectively has the following two overloads in the Ruby sense.
///     obj.instance_eval(string [, filename [, lineno]] ) => obj
///     obj.instance_eval {| | block } => obj
/// Consider this call:
///     obj.instance_eval(2, 3) { }
/// This should match with the second Ruby overload, and report an ArgumentError because of the mismatch in the number of arguments.
/// However, the MethodBinder will prefer the first Ruby overload as it has a matching number of arguments, and will report
/// a type-mismatch instead. 
/// Filterting down the overload list upfront yields better errors.
/// </summary> 

Tomas pointed out that this filtering was incorrect. Tomas, it did cause test failures (My last test pass had this filtering done in error-handling after the MethodBinder did its stuff). 

However, overloads do get precedence in some cases like the instance_eval example in the comment above, and also with Array#fill as shown below. There is a RubySpec test for Array#fill, but we have a tag because we get it wrong. I agree with Tomas that this will need to be handled more carefully, and we might need to have an attribute on the library methods indicating whether the block gets precedence, or whether the argument count gets precedence in selecting the method overload. I will undo my change for now.

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville 
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do    
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
  
  it "coerces string argument with Float() without calling String#to_f" do    
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes. 

it "coerces string argument with Float() without calling singleton to_f" do    
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end
   
  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde 
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:
  
  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.
  
  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.
  
  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.
  
  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From jdeville at microsoft.com  Sun Jan 25 17:38:46 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Sun, 25 Jan 2009 14:38:46 -0800
Subject: [Ironruby-core] Code Review: Better error messages
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD094C09B@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <710DF26F214D2B4BB94287123FFE980A2DD094BED1@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE172@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C06A@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE224@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B24D4FAE8@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<710DF26F214D2B4BB94287123FFE980A2DD094C09B@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE24F@NA-EXMSG-C112.redmond.corp.microsoft.com>

I feel that it is redundant.

JD

-----Original Message-----
From: Shri Borde
Sent: Saturday, January 24, 2009 11:21 PM
To: Tomas Matousek; Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

The test below actually shows that the singleton to_f is not called. Similarly, a string like "1.0" gets converted to a Float even after undef-ing String#to_f. So the library methods are *not* calling to_f on strings at all, but are directly converting the string contents to a Float value.

The question is not whether should_not_receive ensures that to_f is not invoked (I agree that we should use this API). The question is whether we need the testing of all these cases for the default protocol for converting Float arguments, or if its redundant with language tests testing method dispatch. The language tests will cover the conversions done in the libraries.

-----Original Message-----
From: Tomas Matousek
Sent: Saturday, January 24, 2009 10:58 PM
To: Jim Deville; Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

I believe Jim is right. Library methods performing conversions (or other operations) do so either by calling internal C methods or using regular Ruby method dispatch. The former can't be detected from Ruby except for using a tracing proc (set_trace_func). Method dispatch goes to the singleton of the object first and then to its class. So the use of should_not_receive ensures that to_f is not invoked on the given object.

Tomas

-----Original Message-----
From: Jim Deville
Sent: Saturday, January 24, 2009 4:26 PM
To: Shri Borde; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Tomas, correct me if I'm wrong, but Ruby uses a message based method dispatch. When to_f is called, the message to_f gets sent to the object, and then normal method resolution occurs. There is no way to bypass that resolution. You can't call String#to_f instead of the singleton class's to_f. You call to_f on the object, and it sends the message. That is why I argue those tests are the same. If we have the ability, or the possibility of something different, then something is wrong with our method dispatch an method resolution. That should be exposed in the method tests in Language specs. This spec doesn't need both the case of a classes instance method and a singleton instance method.

JD

-----Original Message-----
From: Shri Borde
Sent: Saturday, January 24, 2009 2:36 PM
To: Jim Deville; IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

Jim, using should_not_receive sounds like a good idea. Will do the change.

But we still need all those specs including the one using hijack_String_to_f. It is not testing method dispatch. Ruby method dispatch only controls which method body will be called. It does not do argument conversions. That is handled by the target method which is free to use to_f to convert the argument to a float, but is not required to. The specs below will ensure that the library method does follow the right convention/protocol for converting the argument to a float. Does that make sense?



Also, I had this comment:

/// <summary>
/// An overload with a block should get precedence. However, Microsoft.Scripting.Action.Calls.MethodBinder
/// gives precedence to overloads with a matching number of arguments as the actual arguments. Consider Object#eval
/// which effectively has the following two overloads in the Ruby sense.
///     obj.instance_eval(string [, filename [, lineno]] ) => obj
///     obj.instance_eval {| | block } => obj
/// Consider this call:
///     obj.instance_eval(2, 3) { }
/// This should match with the second Ruby overload, and report an ArgumentError because of the mismatch in the number of arguments.
/// However, the MethodBinder will prefer the first Ruby overload as it has a matching number of arguments, and will report
/// a type-mismatch instead.
/// Filterting down the overload list upfront yields better errors.
/// </summary>

Tomas pointed out that this filtering was incorrect. Tomas, it did cause test failures (My last test pass had this filtering done in error-handling after the MethodBinder did its stuff).

However, overloads do get precedence in some cases like the instance_eval example in the comment above, and also with Array#fill as shown below. There is a RubySpec test for Array#fill, but we have a tag because we get it wrong. I agree with Tomas that this will need to be handled more carefully, and we might need to have an attribute on the library methods indicating whether the block gets precedence, or whether the argument count gets precedence in selecting the method overload. I will undo my change for now.

http://ruby-doc.org/core/classes/Array.html
array.fill(obj) ? array
array.fill(obj, start [, length]) ? array
array.fill(obj, range ) ? array
array.fill {|index| block } ? array
array.fill(start [, length] ) {|index| block } ? array
array.fill(range) {|index| block } ? array

MRI
irb(main):005:0> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
ArgumentError: wrong number of arguments (3 for 2)

IronRuby
>>> [1,2].fill(1,1,2) {|i| puts "index=#{i}" }
=> [1, 1, 1]

Thanks,
Shri


-----Original Message-----
From: Jim Deville
Sent: Friday, January 23, 2009 3:05 PM
To: Shri Borde; IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: RE: Code Review: Better error messages

it "coerces string argument with Float() without calling singleton to_f" do
    s = MathSpecs.string_with_singleton_to_f("0.5", 0.5)
    Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "coerces string argument with Float() without calling String#to_f" do
    MathSpecs.hijack_String_to_f
    begin
      Math.acos("0.5").should be_close(Math.acos(0.5), TOLERANCE)
    ensure
      MathSpecs.reset_String_to_f
    end
  end

These can be rewritten with mocks instead of specialized classes.

it "coerces string argument with Float() without calling singleton to_f" do
  s = "0.5"
  s.should_not_receive(:to_f)
  Math.acos(s).should be_close(Math.acos(0.5), TOLERANCE)
End

The second spec is really testing method dispatch, and otherwise is the same thing as this one. Same with:

  it "raises an ArgumentError if the singleton string cannot be directly coerced with Float()" do
    s = MathSpecs.string_with_singleton_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  end

  it "raises an ArgumentError if the string subclass cannot be directly coerced with Float()" do
    s = MathSpecs.string_subclass_with_to_f("test", 0.5)
    lambda { Math.acos(s) }.should raise_error(ArgumentError)
    ScratchPad.recorded.should == nil # to_f should not be called
  End

JD

-----Original Message-----
From: Shri Borde
Sent: Friday, January 23, 2009 2:04 PM
To: IronRuby External Code Reviewers; DLR Code Reviews
Cc: ironruby-core at rubyforge.org
Subject: Code Review: Better error messages

  tfpt review "/shelveset:error;REDMOND\sborde"

Microsoft.Scripting:

  Change in DefaultBinder is to make the binder exception processing logic be extensible so that languages can customize the type of exception thrown.

IronRuby:

  Improves error reporting in IronRuby by checking the results of the bind failure. This allowed many Math tests to be enabled.

  Also, added a DefaultProtocol for to_f. This allowed more Math tests to be enabled as you can now pass the string "1.0" to a function expecting a "Float". I have added test cases for the Float conversion rules in core\math\acos_spec.rb. I have not copied this to the other specs as that would be hard to maintain. We will look at factoring such conversion checks into a utility library so that they will be much easier to use.

  Fixes some String bugs - String.#inspect on string subtype should return a string, and passing wrong argument types to Strings#[]= should cause TypeError instead of ArgumentError. This is where I started and it put me in the direction of the fixes above.

  Tomas: In RubyBinder.GetTypeName, is there a better way to get to RubyContext?



From curth at microsoft.com  Mon Jan 26 13:31:23 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Mon, 26 Jan 2009 10:31:23 -0800
Subject: [Ironruby-core] Code Review: ThreadSafety7
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B24D4FA92@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <F58FE69873E2D5459B72C347DE1582412B24D4FA92@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED1528BD3D5D99@NA-EXMSG-C118.redmond.corp.microsoft.com>

Wow, that's a lot of changes...  looks good!

-----Original Message-----
From: Tomas Matousek
Sent: Friday, January 23, 2009 11:44 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: Code Review: ThreadSafety7

  tfpt review "/shelveset:ThreadSafety7;REDMOND\tomat"
  Comment  :
    Makes operations on class hierarchy thread-safe. A class-hierarchy lock is defined on RubyContext. The lock should be acquired by any reader or writer that accesses the mutable state on hierarchy (such as method and constant tables on modules/classes, mixin lists, etc.).

    Fixes implementation of private/public/protected/module_function that take a list of symbols. These methods define a stub method in the current module that has given visibility and forwards any call to it to super class (as if "super" was used). Implements this behavior via RubyMemberInfo with SuperForwarder flag set.

    Improves generated initializers to generate more efficient code.

    Fixes bugs:
    [ ironruby-Bugs-23510 ] Methods are being cloned  when they are private in subclasses
    [ ironruby-Bugs-22362 ] module_function

Tomas

From jdeville at microsoft.com  Mon Jan 26 16:03:12 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Mon, 26 Jan 2009 13:03:12 -0800
Subject: [Ironruby-core] Code Review: netinterop1
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>

  tfpt review "/shelveset:netinterop1;REDMOND\jdeville"
  Comment  :
  More tests for .net interop. This is taking advantage of the IronRuby selfhosting that Tomas blogged about in order to maintain isolation as I run different styles of requiring files. If you add Merlin/External/Languages/IronRuby/mspec/mspec/bin to your path, you should be able to run these with "mspec -fs /path/to/Interop/Load"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: netinterop1.diff
Type: application/octet-stream
Size: 27353 bytes
Desc: netinterop1.diff
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090126/f206b591/attachment-0001.obj>

From jgbailey at gmail.com  Mon Jan 26 17:23:39 2009
From: jgbailey at gmail.com (Justin Bailey)
Date: Mon, 26 Jan 2009 14:23:39 -0800
Subject: [Ironruby-core] Code Review: netinterop1
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <a45dff840901261423k29ab684td6400591cd2c62c3@mail.gmail.com>

On Mon, Jan 26, 2009 at 1:03 PM, Jim Deville <jdeville at microsoft.com> wrote:
>  tfpt review "/shelveset:netinterop1;REDMOND\jdeville"
>  Comment  :
>  More tests for .net interop. This is taking advantage of the IronRuby selfhosting that Tomas blogged about in order to maintain

Where can I find Tomas' blog? I'd like to subscribe but I didn't see
it on the IronRuby "people" page:

http://ironruby.net/About/People

Justin

From jgbailey at gmail.com  Mon Jan 26 17:27:05 2009
From: jgbailey at gmail.com (Justin Bailey)
Date: Mon, 26 Jan 2009 14:27:05 -0800
Subject: [Ironruby-core] Code Review: netinterop1
In-Reply-To: <a45dff840901261423k29ab684td6400591cd2c62c3@mail.gmail.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a45dff840901261423k29ab684td6400591cd2c62c3@mail.gmail.com>
Message-ID: <a45dff840901261427v75a58058w16836c6e49cbfb4a@mail.gmail.com>

The best way to answer your own question - post to a mailing list! I
found a nice blogroll post by Oleg:

  http://www.tkachenko.com/blog/archives/000747.html

Maybe someone can update the people page? I would but I haven't
created an account and am pressed for time as it is ...

Justin

On Mon, Jan 26, 2009 at 2:23 PM, Justin Bailey <jgbailey at gmail.com> wrote:
> On Mon, Jan 26, 2009 at 1:03 PM, Jim Deville <jdeville at microsoft.com> wrote:
>>  tfpt review "/shelveset:netinterop1;REDMOND\jdeville"
>>  Comment  :
>>  More tests for .net interop. This is taking advantage of the IronRuby selfhosting that Tomas blogged about in order to maintain
>
> Where can I find Tomas' blog? I'd like to subscribe but I didn't see
> it on the IronRuby "people" page:
>
> http://ironruby.net/About/People
>
> Justin
>

From Tomas.Matousek at microsoft.com  Mon Jan 26 17:49:23 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Mon, 26 Jan 2009 14:49:23 -0800
Subject: [Ironruby-core] Code Review: netinterop1
In-Reply-To: <a45dff840901261423k29ab684td6400591cd2c62c3@mail.gmail.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<a45dff840901261423k29ab684td6400591cd2c62c3@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B25573582@NA-EXMSG-C112.redmond.corp.microsoft.com>

Fixed :)

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Justin Bailey
Sent: Monday, January 26, 2009 2:24 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Code Review: netinterop1

On Mon, Jan 26, 2009 at 1:03 PM, Jim Deville <jdeville at microsoft.com> wrote:
>  tfpt review "/shelveset:netinterop1;REDMOND\jdeville"
>  Comment  :
>  More tests for .net interop. This is taking advantage of the IronRuby selfhosting that Tomas blogged about in order to maintain

Where can I find Tomas' blog? I'd like to subscribe but I didn't see
it on the IronRuby "people" page:

http://ironruby.net/About/People

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


From jdeville at microsoft.com  Tue Jan 27 17:56:44 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 27 Jan 2009 14:56:44 -0800
Subject: [Ironruby-core] Git push
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B79D6@NA-EXMSG-C112.redmond.corp.microsoft.com>

As you may have seen via the RSS feed, I have pushed a new IronRuby revision out. This still requires the MERLIN_ROOT variable and the CSPROJ has load issues due to SpecSharp.targets, but both of those are being phased out. I'm waiting on a code review for the shelveset that will get rid of MERLIN_ROOT checking, and I'm working on the changes for SpecSharp.

Enjoy!

JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090127/4f89b08d/attachment.html>

From Jimmy.Schementi at microsoft.com  Tue Jan 27 18:26:03 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 27 Jan 2009 15:26:03 -0800
Subject: [Ironruby-core] Git push
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B79D6@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B79D6@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE22D@NA-EXMSG-C116.redmond.corp.microsoft.com>

Looking at it now ... =P

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Tuesday, January 27, 2009 2:57 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Git push

As you may have seen via the RSS feed, I have pushed a new IronRuby revision out. This still requires the MERLIN_ROOT variable and the CSPROJ has load issues due to SpecSharp.targets, but both of those are being phased out. I'm waiting on a code review for the shelveset that will get rid of MERLIN_ROOT checking, and I'm working on the changes for SpecSharp.

Enjoy!

JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090127/89f182fb/attachment.html>

From Jimmy.Schementi at microsoft.com  Tue Jan 27 19:13:32 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 27 Jan 2009 16:13:32 -0800
Subject: [Ironruby-core] Code Review: compilefix
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE178@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE178@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE296@NA-EXMSG-C116.redmond.corp.microsoft.com>

Ah deleting code, I love it. And goodbye IronRuby.source_context ... =)

Looks good.
~js

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Jim Deville
> Sent: Friday, January 23, 2009 3:11 PM
> To: IronRuby External Code Reviewers
> Cc: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] Code Review: compilefix
>
>   tfpt review "/shelveset:compilefix;REDMOND\jdeville"
>   Comment  :
>   This shelveset removes the project transforms from the Ruby
> rakefiles. This means that there is no longer a need to set MERLIN_ROOT
> for external contributors.
>


From jdeville at microsoft.com  Tue Jan 27 19:17:33 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Tue, 27 Jan 2009 16:17:33 -0800
Subject: [Ironruby-core] Code Review: compilefix
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE296@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB59FE178@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE296@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B7A3D@NA-EXMSG-C112.redmond.corp.microsoft.com>

Sweet, going in as direct commit, followed by a push for external ;)

JD

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Tuesday, January 27, 2009 4:14 PM
> To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
> Subject: Re: [Ironruby-core] Code Review: compilefix
> 
> Ah deleting code, I love it. And goodbye IronRuby.source_context ... =)
> 
> Looks good.
> ~js
> 
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> > bounces at rubyforge.org] On Behalf Of Jim Deville
> > Sent: Friday, January 23, 2009 3:11 PM
> > To: IronRuby External Code Reviewers
> > Cc: ironruby-core at rubyforge.org
> > Subject: [Ironruby-core] Code Review: compilefix
> >
> >   tfpt review "/shelveset:compilefix;REDMOND\jdeville"
> >   Comment  :
> >   This shelveset removes the project transforms from the Ruby
> > rakefiles. This means that there is no longer a need to set
> MERLIN_ROOT
> > for external contributors.
> >
> 
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From lists at ruby-forum.com  Tue Jan 27 23:17:15 2009
From: lists at ruby-forum.com (Web Reservoir)
Date: Wed, 28 Jan 2009 05:17:15 +0100
Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?
Message-ID: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>

Hello..

-------------------------------------------------------------------------
Hi Phil,

Great News shared.

I am dying to work with IronRuby and Asp.Net MVC since ages, but no good
news are seen nearby.

Can you kindly make it clear for once and all that should i leave all
the hopes to work with IronRuby and Asp.Net MVC or i can still keep on
dreaming with this.

No news are bad news.. and thats really frustrating.

Thanks
---------------------------------------------------------------------------

I also feel the same.

I have just seen this post on web and i though i would repost it here,
since the progress of IronRuby is going dead slow since its announcement
in Mix 2007 and now since Mix 2009 is round the corner, i see no good
news of Version 1.0 and its support with Asp.Net MVC.

I have also seen the same frustration on twitter too.

Can any one come ahead with a final answer for this....?

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

From Jimmy.Schementi at microsoft.com  Wed Jan 28 02:31:24 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 27 Jan 2009 23:31:24 -0800
Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?
In-Reply-To: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
References: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE3C3@NA-EXMSG-C116.redmond.corp.microsoft.com>

== Short Answer

http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html
http://github.com/jschementi/ironrubymvc

We've always been clear on an expected 1.0 date ... sometime in 2009. =) The schedule to 1.0 will be more apparent in the next coming months. Check out http://ironruby.net, lots of new information about the project up there, and like I said, more to come.

IronRuby is open-source. ASP.NET MVC source-code is available. If you want it to work so badly, why not work on it yourself? The source code for the initial integration is available too, so I don't see the problem. We're a small team, so we can only focus on the language, and could use the help with these types of integration projects. So, please help!

== Long Answer

IronRuby has a very small, full-time development team at Microsoft. We are focusing on the language and libraries, full-time; IronRuby 1.0 is our priority. Other integration with .NET frameworks is usually from broader DLR-integration efforts that IronRuby gets for free/minimal effort, like my work on Silverlight before working on IronRuby.

So, again, we're the IronRuby team working on the Ruby language. If you'd like to voice your opinion about integration with ASP.NET MVC, I'm sure the ASP.NET MVC team would want to hear.

That being said, I've been the person on working most closely with the ASP.NET team, only on my free time, to make steps towards a better DLR integration with ASP.NET. Cause I care =P And in late September we made a first step by releasing an updated integration between IronPython and ASP.NET. http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html. Also, Phil Haack and I have been working on an IronRuby MVC integration
http://github.com/jschementi/ironrubymvc. Phil was last working on filters, but we haven't merged that code back into my github account. The current state of the repo may be a little wacky, since the sample app uses ActiveSupport, which loads way too slowly, but it works.

Phil and I are only two people. With other full-time job responsibilities, and other side projects. If anyone is interested in seeing ASP.NET (MVC) integration, please feel free to get the available code and start building upon it. If you want to contribute, we can move the projects to ironruby-contrib and gladly accept patches.

If no one helps us with this, things will move slow ... it will eventually happen, but slow. So, if you want it so badly, I encourage you to prove it and help. If you don't, and the IronRuby team has to do the work, then 1.0 will be that much further away.

~Jimmy

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Web Reservoir
> Sent: Tuesday, January 27, 2009 8:17 PM
> To: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or
> not...?
>
> Hello..
>
> -----------------------------------------------------------------------
> --
> Hi Phil,
>
> Great News shared.
>
> I am dying to work with IronRuby and Asp.Net MVC since ages, but no
> good
> news are seen nearby.
>
> Can you kindly make it clear for once and all that should i leave all
> the hopes to work with IronRuby and Asp.Net MVC or i can still keep on
> dreaming with this.
>
> No news are bad news.. and thats really frustrating.
>
> Thanks
> -----------------------------------------------------------------------
> ----
>
> I also feel the same.
>
> I have just seen this post on web and i though i would repost it here,
> since the progress of IronRuby is going dead slow since its
> announcement
> in Mix 2007 and now since Mix 2009 is round the corner, i see no good
> news of Version 1.0 and its support with Asp.Net MVC.
>
> I have also seen the same frustration on twitter too.
>
> Can any one come ahead with a final answer for this....?
>
> Thanks
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core


From ivan at flanders.co.nz  Wed Jan 28 03:42:21 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Wed, 28 Jan 2009 09:42:21 +0100
Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE3C3@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE3C3@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <b1c6aabb0901280042p6c2bec38p86d6f9293f728870@mail.gmail.com>

I definitely want to help with the integration of mvc and IronRuby. But I
was also waiting for it to go to 1.0 before actually spending a serious
amount of time on it.


On Wed, Jan 28, 2009 at 8:31 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

> == Short Answer
>
>
> http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html
> http://github.com/jschementi/ironrubymvc
>
> We've always been clear on an expected 1.0 date ... sometime in 2009. =)
> The schedule to 1.0 will be more apparent in the next coming months. Check
> out http://ironruby.net, lots of new information about the project up
> there, and like I said, more to come.
>
> IronRuby is open-source. ASP.NET <http://asp.net/> MVC source-code is
> available. If you want it to work so badly, why not work on it yourself? The
> source code for the initial integration is available too, so I don't see the
> problem. We're a small team, so we can only focus on the language, and could
> use the help with these types of integration projects. So, please help!
>
> == Long Answer
>
> IronRuby has a very small, full-time development team at Microsoft. We are
> focusing on the language and libraries, full-time; IronRuby 1.0 is our
> priority. Other integration with .NET frameworks is usually from broader
> DLR-integration efforts that IronRuby gets for free/minimal effort, like my
> work on Silverlight before working on IronRuby.
>
> So, again, we're the IronRuby team working on the Ruby language. If you'd
> like to voice your opinion about integration with ASP.NET<http://asp.net/>MVC, I'm sure the
> ASP.NET <http://asp.net/> MVC team would want to hear.
>
> That being said, I've been the person on working most closely with the
> ASP.NET <http://asp.net/> team, only on my free time, to make steps
> towards a better DLR integration with ASP.NET <http://asp.net/>. Cause I
> care =P And in late September we made a first step by releasing an updated
> integration between IronPython and ASP.NET <http://asp.net/>.
> http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html.
> Also, Phil Haack and I have been working on an IronRuby MVC integration
> http://github.com/jschementi/ironrubymvc. Phil was last working on
> filters, but we haven't merged that code back into my github account. The
> current state of the repo may be a little wacky, since the sample app uses
> ActiveSupport, which loads way too slowly, but it works.
>
> Phil and I are only two people. With other full-time job responsibilities,
> and other side projects. If anyone is interested in seeing ASP.NET<http://asp.net/>(MVC) integration, please feel free to get the available code and start
> building upon it. If you want to contribute, we can move the projects to
> ironruby-contrib and gladly accept patches.
>
> If no one helps us with this, things will move slow ... it will eventually
> happen, but slow. So, if you want it so badly, I encourage you to prove it
> and help. If you don't, and the IronRuby team has to do the work, then 1.0
> will be that much further away.
>
> ~Jimmy
>
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> > bounces at rubyforge.org] On Behalf Of Web Reservoir
> > Sent: Tuesday, January 27, 2009 8:17 PM
> > To: ironruby-core at rubyforge.org
> > Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or
> > not...?
> >
> > Hello..
> >
> > -----------------------------------------------------------------------
> > --
> > Hi Phil,
> >
> > Great News shared.
> >
> > I am dying to work with IronRuby and Asp.Net MVC since ages, but no
> > good
> > news are seen nearby.
> >
> > Can you kindly make it clear for once and all that should i leave all
> > the hopes to work with IronRuby and Asp.Net MVC or i can still keep on
> > dreaming with this.
> >
> > No news are bad news.. and thats really frustrating.
> >
> > Thanks
> > -----------------------------------------------------------------------
> > ----
> >
> > I also feel the same.
> >
> > I have just seen this post on web and i though i would repost it here,
> > since the progress of IronRuby is going dead slow since its
> > announcement
> > in Mix 2007 and now since Mix 2009 is round the corner, i see no good
> > news of Version 1.0 and its support with Asp.Net MVC.
> >
> > I have also seen the same frustration on twitter too.
> >
> > Can any one come ahead with a final answer for this....?
> >
> > Thanks
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090128/1de15dfe/attachment.html>

From Jimmy.Schementi at microsoft.com  Wed Jan 28 04:23:34 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Wed, 28 Jan 2009 01:23:34 -0800
Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?
In-Reply-To: <b1c6aabb0901280042p6c2bec38p86d6f9293f728870@mail.gmail.com>
References: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE3C3@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<b1c6aabb0901280042p6c2bec38p86d6f9293f728870@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BE64EE3CD@NA-EXMSG-C116.redmond.corp.microsoft.com>

::nods:: 1.0 doesn?t need to be the magical time to start looking at things. Especially since you?ve been an ?early-adopter? for quite a while Ivan. =) 1.0 is a good time for MRI code to run on IronRuby reliably, but depending on .NET interop is doable even now. Sure, there are some rough edges, but nothing majorly blocking something like ASP.NET. And it?d be nice to know of any major .NET interop pain-points earlier than later.

~js

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Wednesday, January 28, 2009 12:42 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?

I definitely want to help with the integration of mvc and IronRuby. But I was also waiting for it to go to 1.0 before actually spending a serious amount of time on it.
On Wed, Jan 28, 2009 at 8:31 AM, Jimmy Schementi <Jimmy.Schementi at microsoft.com<mailto:Jimmy.Schementi at microsoft.com>> wrote:
== Short Answer

http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html
http://github.com/jschementi/ironrubymvc

We've always been clear on an expected 1.0 date ... sometime in 2009. =) The schedule to 1.0 will be more apparent in the next coming months. Check out http://ironruby.net<http://ironruby.net/>, lots of new information about the project up there, and like I said, more to come.

IronRuby is open-source. ASP.NET<http://asp.net/> MVC source-code is available. If you want it to work so badly, why not work on it yourself? The source code for the initial integration is available too, so I don't see the problem. We're a small team, so we can only focus on the language, and could use the help with these types of integration projects. So, please help!

== Long Answer

IronRuby has a very small, full-time development team at Microsoft. We are focusing on the language and libraries, full-time; IronRuby 1.0 is our priority. Other integration with .NET frameworks is usually from broader DLR-integration efforts that IronRuby gets for free/minimal effort, like my work on Silverlight before working on IronRuby.

So, again, we're the IronRuby team working on the Ruby language. If you'd like to voice your opinion about integration with ASP.NET<http://asp.net/> MVC, I'm sure the ASP.NET<http://asp.net/> MVC team would want to hear.

That being said, I've been the person on working most closely with the ASP.NET<http://asp.net/> team, only on my free time, to make steps towards a better DLR integration with ASP.NET<http://asp.net/>. Cause I care =P And in late September we made a first step by releasing an updated integration between IronPython and ASP.NET<http://asp.net/>. http://blog.jimmy.schementi.com/2008/09/aspnet-dynamic-language-support.html. Also, Phil Haack and I have been working on an IronRuby MVC integration
http://github.com/jschementi/ironrubymvc. Phil was last working on filters, but we haven't merged that code back into my github account. The current state of the repo may be a little wacky, since the sample app uses ActiveSupport, which loads way too slowly, but it works.

Phil and I are only two people. With other full-time job responsibilities, and other side projects. If anyone is interested in seeing ASP.NET<http://asp.net/> (MVC) integration, please feel free to get the available code and start building upon it. If you want to contribute, we can move the projects to ironruby-contrib and gladly accept patches.

If no one helps us with this, things will move slow ... it will eventually happen, but slow. So, if you want it so badly, I encourage you to prove it and help. If you don't, and the IronRuby team has to do the work, then 1.0 will be that much further away.

~Jimmy

> -----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 Web Reservoir
> Sent: Tuesday, January 27, 2009 8:17 PM
> To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
> Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or
> not...?
>
> Hello..
>
> -----------------------------------------------------------------------
> --
> Hi Phil,
>
> Great News shared.
>
> I am dying to work with IronRuby and Asp.Net MVC since ages, but no
> good
> news are seen nearby.
>
> Can you kindly make it clear for once and all that should i leave all
> the hopes to work with IronRuby and Asp.Net MVC or i can still keep on
> dreaming with this.
>
> No news are bad news.. and thats really frustrating.
>
> Thanks
> -----------------------------------------------------------------------
> ----
>
> I also feel the same.
>
> I have just seen this post on web and i though i would repost it here,
> since the progress of IronRuby is going dead slow since its
> announcement
> in Mix 2007 and now since Mix 2009 is round the corner, i see no good
> news of Version 1.0 and its support with Asp.Net MVC.
>
> I have also seen the same frustration on twitter too.
>
> Can any one come ahead with a final answer for this....?
>
> Thanks
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
> http://rubyforge.org/mailman/listinfo/ironruby-core

_______________________________________________
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/20090128/663e43bc/attachment-0001.html>

From bacondarwin at googlemail.com  Wed Jan 28 09:14:46 2009
From: bacondarwin at googlemail.com (Pete Bacon Darwin)
Date: Wed, 28 Jan 2009 14:14:46 -0000
Subject: [Ironruby-core] IronRuby with Asp.Net MVC is possible or not...?
In-Reply-To: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
References: <6baaccb351de0a289b3f838e0a3abea7@ruby-forum.com>
Message-ID: <001b01c98152$c8370480$58a50d80$@com>

I would be fascinated to see some of the sites you are working on at the
moment, Web Reservoir.  Perhaps this would help in defining the direction
that IronRuby takes going forward.
Keep up the good work IR team!
Pete


From ivan at flanders.co.nz  Thu Jan 29 16:43:09 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 29 Jan 2009 22:43:09 +0100
Subject: [Ironruby-core] question on some code from ironrubymvc
Message-ID: <b1c6aabb0901291343l7dcf3babh6b884c7b3ac25059@mail.gmail.com>

Hi
While working on the code for a ironrubymvc i came across the following code

controllerRubyClass.EnumerateMethods((_, symbolId, __) =>
                                                         {
                                                             if
(String.Equals(symbolId, actionName,

  StringComparison.OrdinalIgnoreCase))
                                                             {

controllerRubyMethodName = symbolId;
                                                                 return
true;
                                                             }
                                                             return false;
                                                         });

The tidbit I find interesting is the _ and the __ in the lambda. Is that an
equivalent for null or does it something else?
---
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/20090129/b9dd6f50/attachment.html>

From lists at ruby-forum.com  Thu Jan 29 17:01:23 2009
From: lists at ruby-forum.com (Paul Wheeler)
Date: Thu, 29 Jan 2009 23:01:23 +0100
Subject: [Ironruby-core] ERB
Message-ID: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>

I playing with using ERB in IronRuby and having a little problem. The
code below works fine with Ruby:

require 'erb'
puts ERB.new('hello world').result

but in IronRuby I get this error:

IronRuby.Libraries:0:in `require': no such file to load -- erb
(LoadError)
        from :0

Now if I change the require to this it works:

require 'C:\ruby\lib\ruby\1.8\erb.rb'
puts ERB.new('hello world').result

I assume my IronRuby config is wrong but how do I fix it?
-- 
Posted via http://www.ruby-forum.com/.

From andrew at mindscape.co.nz  Thu Jan 29 17:06:01 2009
From: andrew at mindscape.co.nz (Andrew Peters)
Date: Thu, 29 Jan 2009 14:06:01 -0800
Subject: [Ironruby-core] question on some code from ironrubymvc
In-Reply-To: <b1c6aabb0901291343l7dcf3babh6b884c7b3ac25059@mail.gmail.com>
References: <b1c6aabb0901291343l7dcf3babh6b884c7b3ac25059@mail.gmail.com>
Message-ID: <771cfe010901291406n76e8c033rea23c7de80b88b6d@mail.gmail.com>

Cool! I didn't know you could do this.

It's just a placeholder when you don't care about that arg. Very functional.

On Thu, Jan 29, 2009 at 1:43 PM, Ivan Porto Carrero <ivan at flanders.co.nz>wrote:

> Hi
> While working on the code for a ironrubymvc i came across the following
> code
>
>  controllerRubyClass.EnumerateMethods((_, symbolId, __) =>
>                                                          {
>                                                              if
> (String.Equals(symbolId, actionName,
>
>     StringComparison.OrdinalIgnoreCase))
>                                                              {
>
> controllerRubyMethodName = symbolId;
>                                                                  return
> true;
>                                                              }
>                                                              return false;
>                                                          });
>
> The tidbit I find interesting is the _ and the __ in the lambda. Is that an
> equivalent for null or does it something else?
> ---
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090129/bc901206/attachment.html>

From Tomas.Matousek at microsoft.com  Thu Jan 29 18:32:28 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 29 Jan 2009 15:32:28 -0800
Subject: [Ironruby-core] question on some code from ironrubymvc
In-Reply-To: <771cfe010901291406n76e8c033rea23c7de80b88b6d@mail.gmail.com>
References: <b1c6aabb0901291343l7dcf3babh6b884c7b3ac25059@mail.gmail.com>
	<771cfe010901291406n76e8c033rea23c7de80b88b6d@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B27AD5432@NA-EXMSG-C112.redmond.corp.microsoft.com>

_ and __ are just normal local variables (parameters) scoped to the lambda.

Tomas

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Andrew Peters
Sent: Thursday, January 29, 2009 2:06 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] question on some code from ironrubymvc

Cool! I didn't know you could do this.

It's just a placeholder when you don't care about that arg. Very functional.
On Thu, Jan 29, 2009 at 1:43 PM, Ivan Porto Carrero <ivan at flanders.co.nz<mailto:ivan at flanders.co.nz>> wrote:
Hi

While working on the code for a ironrubymvc i came across the following code

controllerRubyClass.EnumerateMethods((_, symbolId, __) =>
                                                         {
                                                             if (String.Equals(symbolId, actionName,
                                                                               StringComparison.OrdinalIgnoreCase))
                                                             {
                                                                 controllerRubyMethodName = symbolId;
                                                                 return true;
                                                             }
                                                             return false;
                                                         });

The tidbit I find interesting is the _ and the __ in the lambda. Is that an equivalent for null or does it something else?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz<http://flanders.co.nz/>
Twitter: http://twitter.com/casualjim

_______________________________________________
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/20090129/d88f2c46/attachment-0001.html>

From Tomas.Matousek at microsoft.com  Thu Jan 29 18:37:10 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Thu, 29 Jan 2009 15:37:10 -0800
Subject: [Ironruby-core] ERB
In-Reply-To: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
References: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>

There should be a line in ir.exe.config that says something like:

      <set language="Ruby" option="LibraryPaths" value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\1.8\" />

These paths need to point to your MRI installation.

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Paul Wheeler
Sent: Thursday, January 29, 2009 2:01 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] ERB

I playing with using ERB in IronRuby and having a little problem. The
code below works fine with Ruby:

require 'erb'
puts ERB.new('hello world').result

but in IronRuby I get this error:

IronRuby.Libraries:0:in `require': no such file to load -- erb
(LoadError)
        from :0

Now if I change the require to this it works:

require 'C:\ruby\lib\ruby\1.8\erb.rb'
puts ERB.new('hello world').result

I assume my IronRuby config is wrong but how do I fix it?
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core


From thibaut.barrere at gmail.com  Fri Jan 30 03:11:31 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 30 Jan 2009 09:11:31 +0100
Subject: [Ironruby-core] ERB
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4a68b8cf0901300011v657f3686td78d0ee5f1823191@mail.gmail.com>

Hello,

> There should be a line in ir.exe.config that says something like:
>
>      <set language="Ruby" option="LibraryPaths" value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\1.8\" />
>
> These paths need to point to your MRI installation.

just curious (ie. I don't need this yet): is there currently a way to
set this programmatically, maybe while instantiating the IronRuby host
?

-- Thibaut

From thibaut.barrere at gmail.com  Fri Jan 30 03:13:22 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 30 Jan 2009 09:13:22 +0100
Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B249DAD88@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <4a68b8cf0901090233r53eac775n6d43af6e926a8604@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BDF0D886E@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412B249DAD88@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4a68b8cf0901300013o59001454vcfb01f6a67147e0e@mail.gmail.com>

Hi,

just some words of feedback: it works perfectly :)

I'm beginning to start using an embedded IronRuby engine to create my
windows forms programmatically inside a C# application, rather than
from the designer.

thanks, I'll keep you guys posted on my findings!

Thibaut


On Fri, Jan 9, 2009 at 10:30 PM, Tomas Matousek
<Tomas.Matousek at microsoft.com> wrote:
> The last 4 lines of the snippet could be slightly simplified:
>
> var engine = IronRuby.Ruby.CreateEngine();
> engine.Execute(code);
>
> Tomas
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Friday, January 09, 2009 11:43 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Compiling .rb files vs. embedding and hosting ?
>
> Embedding the files as resources would be your best bet, as we don't have compilation to an assembly working today.
>
> Basically (compiled with outlook ...):
>
> var assembly = Assembly.GetExecutingAssembly();
> var textStreamReader = new StreamReader(assembly.GetManifestResourceStream("foo.rb"));
> var code = textStreamReader.ReadToEnd();
> textStreamReader.Close();
>
> var runtime = new ScriptRuntime();
> var ruby = IronRuby.Ruby.GetEngine(runtime);
> var source = ruby.CreateScriptSourceFromString(code);
> var result = source.Execute();
>
> Compilation is something we want to support though.
>
> ~js
>
>> -----Original Message-----
>> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
>> bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
>> Sent: Friday, January 09, 2009 2:34 AM
>> To: ironruby-core
>> Subject: [Ironruby-core] Compiling .rb files vs. embedding and hosting
>> ?
>>
>> Hello,
>>
>> I'm starting to integrate IronRuby files into a VisualStudio C#
>> project, mainly to write easy-to-maintain GUI builders.
>>
>> As I don't want to have .rb files lying around this deployment, I had
>> that idea about embedding all the files inside an assembly, loading
>> them at run time through resource manager and passing them to the
>> IronRuby host I would start from C#.
>>
>> While that would work, it would be even simplier to have these .rb
>> files compiled to some assembly.
>>
>> Is there a trick to compile a bunch of .rb files to an assembly today ?
>>
>> thanks!
>>
>> -- Thibaut
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>

From Tomas.Matousek at microsoft.com  Fri Jan 30 03:48:24 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 30 Jan 2009 00:48:24 -0800
Subject: [Ironruby-core] ERB
In-Reply-To: <4a68b8cf0901300011v657f3686td78d0ee5f1823191@mail.gmail.com>
References: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<4a68b8cf0901300011v657f3686td78d0ee5f1823191@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B27AD5573@NA-EXMSG-C112.redmond.corp.microsoft.com>

Yes. Something like this should do:

var engine = IronRuby.Ruby.CreateEngine((setup) => { setup.Options["LibraryPaths"] = "..." });

engine.Execute(code);

Tomas

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re
Sent: Friday, January 30, 2009 12:12 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] ERB

Hello,

> There should be a line in ir.exe.config that says something like:
>
>      <set language="Ruby" option="LibraryPaths" value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\1.8\" />
>
> These paths need to point to your MRI installation.

just curious (ie. I don't need this yet): is there currently a way to
set this programmatically, maybe while instantiating the IronRuby host
?

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


From thibaut.barrere at gmail.com  Fri Jan 30 04:07:37 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 30 Jan 2009 10:07:37 +0100
Subject: [Ironruby-core] ERB
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B27AD5573@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<4a68b8cf0901300011v657f3686td78d0ee5f1823191@mail.gmail.com>
	<F58FE69873E2D5459B72C347DE1582412B27AD5573@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4a68b8cf0901300107r5f2310edx6f2a5806f37dfd08@mail.gmail.com>

> var engine = IronRuby.Ruby.CreateEngine((setup) => { setup.Options["LibraryPaths"] = "..." });

easy - great!

Thanks,

Thibaut

From ivan at flanders.co.nz  Fri Jan 30 06:17:35 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Fri, 30 Jan 2009 12:17:35 +0100
Subject: [Ironruby-core] progress on ironrubymvc :)
Message-ID: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>

Hi
I think I can have a very basic version of ironruby mvc going over the
weekend.. that will probably be without support for things like filters etc.
yet.. but you should be able to define a controller and actions in
ironruby.
I haven't looked at the view engine yet and I'm unclear as to which strategy
to use because if ERB works properly then that seem like a great fit to me
or should I keep the view engine that is in the current repository and
improve on that one iteratively

If there are more people interested in using ironruby with asp.net mvc I do
have a good idea of what work is involved and how hard it is. There is a
fair amount of work involved that means I would need a couple of spikes to
get it all going. To make the controllers work etc. I think I will have to
define new descriptors that use the the ironruby infrastructure.
Does anybody know if the descriptors in the asp.net mvc framework are
currently set in stone or if they are still pretty volatile, that is the
biggest risk for the controller implementation IMHO?

Also there is a conflict between 2 types in the System namespace.
System.Func is defined in 2 places. I aliased the System.Core assembly and
am using the type from System.Core. This does give some weird results
because apparently System.Func<>, System.Core,..,... and System.Func<>,
System.Core aren't the same when the mvc framework checks for the types of
the parameter. Any tips to get around this? Am I doing something wrong?

I'll integrate Andrew Peters' inflector to take care of pascal casing, snake
casing and pluralisations etc. unless there are objections.

It would be good to get some kind of indication/document of what is
important from the asp.net, asp.net mvc and the ironruby teams so that I can
take that into account when I'm coding this thing up.

Cheers
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/92d4741d/attachment.html>

From ivan at flanders.co.nz  Fri Jan 30 07:46:56 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Fri, 30 Jan 2009 13:46:56 +0100
Subject: [Ironruby-core] DLR hosting
Message-ID: <b1c6aabb0901300446l7281190x78d712860e106d58@mail.gmail.com>

it will show that so far I've been working with instead of on IronRuby :)
And then I've been focussed on using the Ruby language and .NET from Ruby
instead of using C# to host Ironruby.
I'm using a debug build from IronRuby and the weird thing is that I have to
add ClassHierarchyLocker.

            var controllerRubyClass =
ScriptRuntime.Globals.GetVariable<RubyModule>(controllerRubyClassName);
            string controllerRubyMethodName = null;
            using (rubyContext.ClassHierarchyLocker())
            {
                controllerRubyClass.EnumerateMethods((_, symbolId, __) =>
                                                         {
                                                             if
(String.Equals(symbolId, actionName,

StringComparison.OrdinalIgnoreCase))
                                                             {

controllerRubyMethodName = symbolId;
                                                                 return
true;
                                                             }
                                                             return false;
                                                         });
            }

The question I have here is: Why do I need the ClassHierarchyLocker ?

Cheers Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/954c5d15/attachment-0001.html>

From thibaut.barrere at gmail.com  Fri Jan 30 07:50:33 2009
From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=)
Date: Fri, 30 Jan 2009 13:50:33 +0100
Subject: [Ironruby-core] progress on ironrubymvc :)
In-Reply-To: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
References: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
Message-ID: <4a68b8cf0901300450u5e36338bwbdfc27e714ff443@mail.gmail.com>

Hi Ivan,

will you share this on github ? That's something I will try using at some point.

cheers,

Thibaut


On Fri, Jan 30, 2009 at 12:17 PM, Ivan Porto Carrero
<ivan at flanders.co.nz> wrote:
> Hi
> I think I can have a very basic version of ironruby mvc going over the
> weekend.. that will probably be without support for things like filters etc.
> yet.. but you should be able to define a controller and actions in
> ironruby.
> I haven't looked at the view engine yet and I'm unclear as to which strategy
> to use because if ERB works properly then that seem like a great fit to me
> or should I keep the view engine that is in the current repository and
> improve on that one iteratively
> If there are more people interested in using ironruby with asp.net mvc I do
> have a good idea of what work is involved and how hard it is. There is a
> fair amount of work involved that means I would need a couple of spikes to
> get it all going. To make the controllers work etc. I think I will have to
> define new descriptors that use the the ironruby infrastructure.
> Does anybody know if the descriptors in the asp.net mvc framework are
> currently set in stone or if they are still pretty volatile, that is the
> biggest risk for the controller implementation IMHO?
>
> Also there is a conflict between 2 types in the System namespace.
> System.Func is defined in 2 places. I aliased the System.Core assembly and
> am using the type from System.Core. This does give some weird results
> because apparently System.Func<>, System.Core,..,... and System.Func<>,
> System.Core aren't the same when the mvc framework checks for the types of
> the parameter. Any tips to get around this? Am I doing something wrong?
> I'll integrate Andrew Peters' inflector to take care of pascal casing, snake
> casing and pluralisations etc. unless there are objections.
> It would be good to get some kind of indication/document of what is
> important from the asp.net, asp.net mvc and the ironruby teams so that I can
> take that into account when I'm coding this thing up.
> Cheers
> Ivan
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>

From curth at microsoft.com  Fri Jan 30 08:22:43 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Fri, 30 Jan 2009 05:22:43 -0800
Subject: [Ironruby-core] DLR hosting
In-Reply-To: <b1c6aabb0901300446l7281190x78d712860e106d58@mail.gmail.com>
References: <b1c6aabb0901300446l7281190x78d712860e106d58@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED1528C81A5EA9@NA-EXMSG-C118.redmond.corp.microsoft.com>

It's part of Tomas' thread-safety work.  To enumerate the methods safely, you need to ensure that another thread isn't modifying the method list.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Friday, January 30, 2009 4:47 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] DLR hosting

it will show that so far I've been working with instead of on IronRuby :) And then I've been focussed on using the Ruby language and .NET from Ruby instead of using C# to host Ironruby.

I'm using a debug build from IronRuby and the weird thing is that I have to add ClassHierarchyLocker.

            var controllerRubyClass = ScriptRuntime.Globals.GetVariable<RubyModule>(controllerRubyClassName);
            string controllerRubyMethodName = null;
            using (rubyContext.ClassHierarchyLocker())
            {
                controllerRubyClass.EnumerateMethods((_, symbolId, __) =>
                                                         {
                                                             if (String.Equals(symbolId, actionName,
                                                                               StringComparison.OrdinalIgnoreCase))
                                                             {
                                                                 controllerRubyMethodName = symbolId;
                                                                 return true;
                                                             }
                                                             return false;
                                                         });
            }

The question I have here is: Why do I need the ClassHierarchyLocker ?

Cheers Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/4255cc3b/attachment.html>

From lists at ruby-forum.com  Fri Jan 30 08:51:05 2009
From: lists at ruby-forum.com (Paul Wheeler)
Date: Fri, 30 Jan 2009 14:51:05 +0100
Subject: [Ironruby-core] ERB
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <1682210ab1bcd56daac455ebad4b538e@ruby-forum.com>
	<F58FE69873E2D5459B72C347DE1582412B27AD5436@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <73d022df6da0543fb2b81fea27c9e3ee@ruby-forum.com>

Tomas Matousek wrote:
> There should be a line in ir.exe.config that says something like:
> 
>       <set language="Ruby" option="LibraryPaths" 
> value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ruby\1.8\" 
> />
> 
> These paths need to point to your MRI installation.
> 
> Tomas

That worked great! All I had to do is copy the App.Config in the 
\Codeplex-DLR-0.9\ folder over to ir.exe.config and add my path. Thanks!
-- 
Posted via http://www.ruby-forum.com/.

From curth at microsoft.com  Fri Jan 30 08:51:59 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Fri, 30 Jan 2009 05:51:59 -0800
Subject: [Ironruby-core] progress on ironrubymvc :)
In-Reply-To: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
References: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED1528C81A5EBB@NA-EXMSG-C118.redmond.corp.microsoft.com>

Microsoft.Scripting.Core.dll is effectively a subset of .NET 4.0's System.Core.dll, which is why there's so much overlap in the types.  For IronPython, we've worked around this by creating an automated process to rename all the types from System.* to Microsoft.*.  But this doesn't work as well for Ruby because Ruby allows for outside contributions.  Improving this situation is of definite interest to us.

This problem goes away once .NET 4.0 ships, provided IronRuby is built against it.

From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Friday, January 30, 2009 3:18 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] progress on ironrubymvc :)

<snip>

Also there is a conflict between 2 types in the System namespace. System.Func is defined in 2 places. I aliased the System.Core assembly and am using the type from System.Core. This does give some weird results because apparently System.Func<>, System.Core,..,... and System.Func<>, System.Core aren't the same when the mvc framework checks for the types of the parameter. Any tips to get around this? Am I doing something wrong?

<snip>

Cheers
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/472b806f/attachment-0001.html>

From ivan at flanders.co.nz  Fri Jan 30 10:12:37 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Fri, 30 Jan 2009 16:12:37 +0100
Subject: [Ironruby-core] progress on ironrubymvc :)
In-Reply-To: <4a68b8cf0901300450u5e36338bwbdfc27e714ff443@mail.gmail.com>
References: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
	<4a68b8cf0901300450u5e36338bwbdfc27e714ff443@mail.gmail.com>
Message-ID: <b1c6aabb0901300712h4ce925f3yee61df6b40bb4a67@mail.gmail.com>

I will as soon as there is something to show ;).. if you want to help.. you
can contact me on IM and I'll start pushing my commits.

For GTalk you can use this email address
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim



On Fri, Jan 30, 2009 at 1:50 PM, Thibaut Barr?re
<thibaut.barrere at gmail.com>wrote:

> Hi Ivan,
>
> will you share this on github ? That's something I will try using at some
> point.
>
> cheers,
>
> Thibaut
>
>
> On Fri, Jan 30, 2009 at 12:17 PM, Ivan Porto Carrero
> <ivan at flanders.co.nz> wrote:
> > Hi
> > I think I can have a very basic version of ironruby mvc going over the
> > weekend.. that will probably be without support for things like filters
> etc.
> > yet.. but you should be able to define a controller and actions in
> > ironruby.
> > I haven't looked at the view engine yet and I'm unclear as to which
> strategy
> > to use because if ERB works properly then that seem like a great fit to
> me
> > or should I keep the view engine that is in the current repository and
> > improve on that one iteratively
> > If there are more people interested in using ironruby with asp.net mvc I
> do
> > have a good idea of what work is involved and how hard it is. There is a
> > fair amount of work involved that means I would need a couple of spikes
> to
> > get it all going. To make the controllers work etc. I think I will have
> to
> > define new descriptors that use the the ironruby infrastructure.
> > Does anybody know if the descriptors in the asp.net mvc framework are
> > currently set in stone or if they are still pretty volatile, that is the
> > biggest risk for the controller implementation IMHO?
> >
> > Also there is a conflict between 2 types in the System namespace.
> > System.Func is defined in 2 places. I aliased the System.Core assembly
> and
> > am using the type from System.Core. This does give some weird results
> > because apparently System.Func<>, System.Core,..,... and System.Func<>,
> > System.Core aren't the same when the mvc framework checks for the types
> of
> > the parameter. Any tips to get around this? Am I doing something wrong?
> > I'll integrate Andrew Peters' inflector to take care of pascal casing,
> snake
> > casing and pluralisations etc. unless there are objections.
> > It would be good to get some kind of indication/document of what is
> > important from the asp.net, asp.net mvc and the ironruby teams so that I
> can
> > take that into account when I'm coding this thing up.
> > Cheers
> > Ivan
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/9feb22d9/attachment.html>

From ivan at flanders.co.nz  Fri Jan 30 10:23:38 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Fri, 30 Jan 2009 16:23:38 +0100
Subject: [Ironruby-core] building on mono
Message-ID: <b1c6aabb0901300723g63086d03v97529e817c821f65@mail.gmail.com>

I updated my mono branch with the sources from ironruby git.
I disabled the build of dlr_com and testhost.

I wanted to verify.. COM programming AFAIK is windows specific or am I
wrong.
I don't quite remember the issue I had with the testhost, I didn't spend
much time on it to make it all work. I figured that most people would be
primarily interested in running ironruby and not finding out which specs
fail.

---
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/20090130/9d56689c/attachment.html>

From Jimmy.Schementi at microsoft.com  Fri Jan 30 12:37:01 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 30 Jan 2009 09:37:01 -0800
Subject: [Ironruby-core] progress on ironrubymvc :)
In-Reply-To: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
References: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
Message-ID: <1F955E12-E5ED-4F0F-8887-77BD2224ED17@microsoft.com>

Did you fork my ironrubymvc project? If so, i'd love to pull any changes you made into it. However, it sounds like you got it to the state it was in before, just updating the ironruby bits? That System.Func/Action<http://System.Func/Action> clash is a known issue; my suggested work-around for now is to not have ironrubymvc depend on system.core.

I'll get on phil to merge his changes as well, and then well have a up-to-date mvc integration :)

~Jimmy
Sent from my phone

On Jan 30, 2009, at 3:55 AM, "Ivan Porto Carrero" <ivan at flanders.co.nz<mailto:ivan at flanders.co.nz>> wrote:

Hi

I think I can have a very basic version of ironruby mvc going over the weekend.. that will probably be without support for things like filters etc. yet.. but you should be able to define a controller and actions in ironruby.
I haven't looked at the view engine yet and I'm unclear as to which strategy to use because if ERB works properly then that seem like a great fit to me or should I keep the view engine that is in the current repository and improve on that one iteratively

If there are more people interested in using ironruby with asp.net<http://asp.net> mvc I do have a good idea of what work is involved and how hard it is. There is a fair amount of work involved that means I would need a couple of spikes to get it all going. To make the controllers work etc. I think I will have to define new descriptors that use the the ironruby infrastructure.
Does anybody know if the descriptors in the asp.net<http://asp.net> mvc framework are currently set in stone or if they are still pretty volatile, that is the biggest risk for the controller implementation IMHO?

Also there is a conflict between 2 types in the System namespace. System.Func is defined in 2 places. I aliased the System.Core assembly and am using the type from System.Core. This does give some weird results because apparently System.Func<>, System.Core,..,... and System.Func<>, System.Core aren't the same when the mvc framework checks for the types of the parameter. Any tips to get around this? Am I doing something wrong?

I'll integrate Andrew Peters' inflector to take care of pascal casing, snake casing and pluralisations etc. unless there are objections.

It would be good to get some kind of indication/document of what is important from the asp.net<http://asp.net>, asp.net<http://asp.net> mvc and the ironruby teams so that I can take that into account when I'm coding this thing up.

Cheers
Ivan
_______________________________________________
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/20090130/c60c4127/attachment.html>

From ivan at flanders.co.nz  Fri Jan 30 13:30:56 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Fri, 30 Jan 2009 19:30:56 +0100
Subject: [Ironruby-core] progress on ironrubymvc :)
In-Reply-To: <1F955E12-E5ED-4F0F-8887-77BD2224ED17@microsoft.com>
References: <b1c6aabb0901300317l6ce92c27g38c03933d48cb842@mail.gmail.com>
	<1F955E12-E5ED-4F0F-8887-77BD2224ED17@microsoft.com>
Message-ID: <b1c6aabb0901301030m66b6af9cpee5c040b6a9461e0@mail.gmail.com>

Yep I forked your project. I don't have it running yet.. and i did get the
source code of the asp.net mvc RC1.
Indeed my first goal was to take it to the state it was before.. i think
that is the most basic implementation possible. When that works I did want
to flesh it out so that it knows how to handle urls with other characters
than just alphanumeric.

I'm also thinking to replace the custom attributes with class methods like I
rails uses for filters etc.

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim



On Fri, Jan 30, 2009 at 6:37 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

> Did you fork my ironrubymvc project? If so, i'd love to pull any changes
> you made into it. However, it sounds like you got it to the state it was in
> before, just updating the ironruby bits? That System.Func/Action clash is
> a known issue; my suggested work-around for now is to not have ironrubymvc
> depend on system.core.
>
> I'll get on phil to merge his changes as well, and then well have a
> up-to-date mvc integration :)
>
> ~JimmySent from my phone
>
> On Jan 30, 2009, at 3:55 AM, "Ivan Porto Carrero" <ivan at flanders.co.nz>
> wrote:
>
> Hi
> I think I can have a very basic version of ironruby mvc going over the
> weekend.. that will probably be without support for things like filters etc.
> yet.. but you should be able to define a controller and actions in
> ironruby.
> I haven't looked at the view engine yet and I'm unclear as to which
> strategy to use because if ERB works properly then that seem like a great
> fit to me or should I keep the view engine that is in the current repository
> and improve on that one iteratively
>
> If there are more people interested in using ironruby with asp.net mvc I
> do have a good idea of what work is involved and how hard it is. There is a
> fair amount of work involved that means I would need a couple of spikes to
> get it all going. To make the controllers work etc. I think I will have to
> define new descriptors that use the the ironruby infrastructure.
> Does anybody know if the descriptors in the asp.net mvc framework are
> currently set in stone or if they are still pretty volatile, that is the
> biggest risk for the controller implementation IMHO?
>
> Also there is a conflict between 2 types in the System namespace.
> System.Func is defined in 2 places. I aliased the System.Core assembly and
> am using the type from System.Core. This does give some weird results
> because apparently System.Func<>, System.Core,..,... and System.Func<>,
> System.Core aren't the same when the mvc framework checks for the types of
> the parameter. Any tips to get around this? Am I doing something wrong?
>
> I'll integrate Andrew Peters' inflector to take care of pascal casing,
> snake casing and pluralisations etc. unless there are objections.
>
> It would be good to get some kind of indication/document of what is
> important from the asp.net, asp.net mvc and the ironruby teams so that I
> can take that into account when I'm coding this thing up.
>
> Cheers
> Ivan
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/dfa5be03/attachment-0001.html>

From jdeville at microsoft.com  Fri Jan 30 16:48:21 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 30 Jan 2009 13:48:21 -0800
Subject: [Ironruby-core] Git push
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB8481450@NA-EXMSG-C112.redmond.corp.microsoft.com>

Sorry for missing the past couple of days, but I have finally pushed a new revision to Github. As of this change (1ee05cdd), MERLIN_ROOT is no longer required. You can now download it, get into a VS Command prompt, and run rake compile from Merlin/Main/Languages/Ruby. Let me know if you have problems.

Enjoy!
JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090130/de146a87/attachment.html>

From orion.edwards at gmail.com  Fri Jan 30 18:52:23 2009
From: orion.edwards at gmail.com (Orion Edwards)
Date: Sat, 31 Jan 2009 12:52:23 +1300
Subject: [Ironruby-core] Ruby 1.9.1 stable released
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB8481450@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB8481450@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <E592D353-2A5B-4617-B3A3-644E2B3A1E00@gmail.com>

The goalposts just got moved...

http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/

Apologies if this is old news.

This begs the question, is IronRuby eventually going to target 1.9?  
Any ideas on when or if this might happen?

From jdeville at microsoft.com  Sat Jan 31 01:19:44 2009
From: jdeville at microsoft.com (Jim Deville)
Date: Fri, 30 Jan 2009 22:19:44 -0800
Subject: [Ironruby-core] Code Review: netinterop1
In-Reply-To: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <B8A3C6EE027AF84086DD3A049CF34A4A2FB62B745B@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <B8A3C6EE027AF84086DD3A049CF34A4A2FB8481597@NA-EXMSG-C112.redmond.corp.microsoft.com>

Srivatsn,

Can you take a look?

JD

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Jim Deville
> Sent: Monday, January 26, 2009 1:03 PM
> To: IronRuby External Code Reviewers; Srivatsn Narayanan
> Cc: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] Code Review: netinterop1
>
>   tfpt review "/shelveset:netinterop1;REDMOND\jdeville"
>   Comment  :
>   More tests for .net interop. This is taking advantage of the IronRuby
> selfhosting that Tomas blogged about in order to maintain isolation as
> I run different styles of requiring files. If you add
> Merlin/External/Languages/IronRuby/mspec/mspec/bin to your path, you
> should be able to run these with "mspec -fs /path/to/Interop/Load"
>


From jirapong.nanta at gmail.com  Sat Jan 31 02:30:10 2009
From: jirapong.nanta at gmail.com (jirapong.nanta at gmail.com)
Date: Sat, 31 Jan 2009 14:30:10 +0700
Subject: [Ironruby-core] igem.bat
Message-ID: <ADA3A48A-894E-4137-BABB-91E985CE4AFB@gmail.com>

How can i get igem.bat work correctly? right now, I get following error.

C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts\bin>SET  
GEM_PATH=C:\ruby\lib\ruby\gems\1.8

C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts\bin>set  
path=%path%;C:\dotNET\ironruby\ironruby\Merlin\Ma
in\bin\debug;C:\ruby\lib\ruby\gems\1.8

C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts 
\bin>igem.bat list
c:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby 
\Libraries.LCA_RESTRICTED\Builtins\KernelOps.cs:406:in `require':
no such file to load -- rubygems (LoadError)
         from :0

Use latest version from GitHub (1ee05cdd)

Thank you,
-Jirapong

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

From ivan at flanders.co.nz  Sat Jan 31 03:16:25 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Sat, 31 Jan 2009 09:16:25 +0100
Subject: [Ironruby-core] igem.bat
In-Reply-To: <ADA3A48A-894E-4137-BABB-91E985CE4AFB@gmail.com>
References: <ADA3A48A-894E-4137-BABB-91E985CE4AFB@gmail.com>
Message-ID: <b1c6aabb0901310016g73e5d805xf1c56c85e2dcffcc@mail.gmail.com>

You have to edit ir.exe.config and change the paths to reflect your
installation.
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim



On Sat, Jan 31, 2009 at 8:30 AM, jirapong.nanta at gmail.com <
jirapong.nanta at gmail.com> wrote:

> How can i get igem.bat work correctly? right now, I get following error.
> C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts\bin>SET
> GEM_PATH=C:\ruby\lib\ruby\gems\1.8
>
> C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts\bin>set
> path=%path%;C:\dotNET\ironruby\ironruby\Merlin\Ma
> in\bin\debug;C:\ruby\lib\ruby\gems\1.8
>
> C:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Scripts\bin>igem.bat
> list
> c:\dotNET\ironruby\ironruby\Merlin\Main\Languages\Ruby\Libraries.LCA_RESTRICTED\Builtins\KernelOps.cs:406:in
> `require':
> no such file to load -- rubygems (LoadError)
>         from :0
>
> Use latest version from GitHub (1ee05cdd)
>
> Thank you,
> -Jirapong
>
>
> _______________________________________________
> 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/20090131/379baa48/attachment.html>

From suppakilla at gmail.com  Sat Jan 31 13:35:11 2009
From: suppakilla at gmail.com (Daniele Alessandri)
Date: Sat, 31 Jan 2009 19:35:11 +0100
Subject: [Ironruby-core] Extending modules defined in a ruby library via C#
Message-ID: <3bf20550901311035k6eab669ancec4f5aa89b0107d@mail.gmail.com>

Hi,

I think I've stumbled on a bug of IronRuby, but I would like to hear
your thoughts about this before filing a report on the bug tracker as
I might be missing something or doing something wrong.

I have a ruby library in which is defined a module and this module
holds a few classes and constants. Then I wrote a library in C# where
the same module is defined to add more classes other than the ones
defined on the ruby side. Now if I load the assembly first and then i
require my ruby library everything works fine, but if I require the
ruby library first and then load the assembly, the module defined by
the ruby lib gets totally wiped off leaving there only what was
defined in the assembly.

Given that in similar scenarios we obviously can't use Extends =
typeof(...) in the RubyModuleAttribute, shouldn't modules previously
defined in ruby code be automatically extended instead of being
erased/redefined (which is definitely broken)? Right below here you
can find the code to reproduce and verify the reported behaviour (for
convenience I also made an attachment to this mail).



# =========== foo.rb ===========
def test(a)
  a.each{ |s| puts "#{s} is #{begin eval(s); rescue NameError;
'undefined' end}"}
end

module Foo
  class Bar; end
  VERSION = 1
end


/* ======== Nrk.Foo.Test.cs ======== */
namespace Nrk.Foo.Test {
    [RubyModule]
    public static class Foo {
        [RubyClass]
        public static class Hoge {
            [RubyMethod("piyo?", RubyMethodAttributes.PublicSingleton)]
            public static bool Piyo(Object self) {
                return true;
            }
        }
    }
}


# =========== test_assembly_first.rb ===========
load_assembly 'Nrk.Foo.Test', 'Nrk.Foo.Test'
require 'foo.rb'

test ['Foo', 'Foo::Bar', 'Foo::VERSION', 'Foo::Hoge', 'Foo::Hoge.piyo?']


# =========== test_ruby_first.rb ===========
require 'foo.rb'
load_assembly 'Nrk.Foo.Test', 'Nrk.Foo.Test'

test ['Foo', 'Foo::Bar', 'Foo::VERSION', 'Foo::Hoge', 'Foo::Hoge.piyo?']


# =========== OUTPUT #1 ===========
Foo is Foo
Foo::Bar is Foo::Bar
Foo::VERSION is 1
Foo::Hoge is Foo::Hoge
Foo::Hoge.piyo? is true

# =========== OUTPUT #2 ===========
Foo is Foo
Foo::Bar is undefined
Foo::VERSION is undefined
Foo::Hoge is Foo::Hoge
Foo::Hoge.piyo? is true


-- 
Daniele Alessandri
http://www.clorophilla.net/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IR_TestCode.zip
Type: application/zip
Size: 1232 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090131/bf397af2/attachment.zip>

From curth at microsoft.com  Sat Jan 31 18:31:02 2009
From: curth at microsoft.com (Curt Hagenlocher)
Date: Sat, 31 Jan 2009 15:31:02 -0800
Subject: [Ironruby-core] Extending modules defined in a ruby library via
 C#
In-Reply-To: <3bf20550901311035k6eab669ancec4f5aa89b0107d@mail.gmail.com>
References: <3bf20550901311035k6eab669ancec4f5aa89b0107d@mail.gmail.com>
Message-ID: <B47F8D37BAA6DC4DAA41CA69D8FBED1528C82EB251@NA-EXMSG-C118.redmond.corp.microsoft.com>

.NET types can never be 100% compatible with Ruby classes; the semantics are simply too different.  What would you expect to happen, for instance, if you were to say the following:

module System::IDisposable; end
class System::Collections::ArrayList; include System::IDisposable; end;
x = System::Collections::ArrayList.new
require 'mscorlib'

Clearly, the "real" System::Collections::ArrayList can't implement IDisposable because the type is immutable.  And the type we created to represent the variable x can't be a "real" ArrayList because we didn't know about that class when x was allocated.

So this leaves us with two possibilities:
1) Always overwrite the previously defined constants with the newly imported CLR types
2) Fail to load the redefined types

...and we're currently doing the first.  While it seems reasonable to fail, it raises questions about what to do if 40 types can be loaded successfully but one can't be.  Do we raise an exception even though there were 40 successes?  Or do we fail to load any types at all?

Monkey-patching CLR types is never going to be able to work identically to monkey-patching pure Ruby types.

-----Original Message-----
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele Alessandri
Sent: Saturday, January 31, 2009 10:35 AM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Extending modules defined in a ruby library via C#

Hi,

I think I've stumbled on a bug of IronRuby, but I would like to hear your thoughts about this before filing a report on the bug tracker as I might be missing something or doing something wrong.

I have a ruby library in which is defined a module and this module holds a few classes and constants. Then I wrote a library in C# where the same module is defined to add more classes other than the ones defined on the ruby side. Now if I load the assembly first and then i require my ruby library everything works fine, but if I require the ruby library first and then load the assembly, the module defined by the ruby lib gets totally wiped off leaving there only what was defined in the assembly.

Given that in similar scenarios we obviously can't use Extends =
typeof(...) in the RubyModuleAttribute, shouldn't modules previously defined in ruby code be automatically extended instead of being erased/redefined (which is definitely broken)? Right below here you can find the code to reproduce and verify the reported behaviour (for convenience I also made an attachment to this mail).



# =========== foo.rb ===========
def test(a)
  a.each{ |s| puts "#{s} is #{begin eval(s); rescue NameError; 'undefined' end}"} end

module Foo
  class Bar; end
  VERSION = 1
end


/* ======== Nrk.Foo.Test.cs ======== */
namespace Nrk.Foo.Test {
    [RubyModule]
    public static class Foo {
        [RubyClass]
        public static class Hoge {
            [RubyMethod("piyo?", RubyMethodAttributes.PublicSingleton)]
            public static bool Piyo(Object self) {
                return true;
            }
        }
    }
}


# =========== test_assembly_first.rb =========== load_assembly 'Nrk.Foo.Test', 'Nrk.Foo.Test'
require 'foo.rb'

test ['Foo', 'Foo::Bar', 'Foo::VERSION', 'Foo::Hoge', 'Foo::Hoge.piyo?']


# =========== test_ruby_first.rb =========== require 'foo.rb'
load_assembly 'Nrk.Foo.Test', 'Nrk.Foo.Test'

test ['Foo', 'Foo::Bar', 'Foo::VERSION', 'Foo::Hoge', 'Foo::Hoge.piyo?']


# =========== OUTPUT #1 ===========
Foo is Foo
Foo::Bar is Foo::Bar
Foo::VERSION is 1
Foo::Hoge is Foo::Hoge
Foo::Hoge.piyo? is true

# =========== OUTPUT #2 ===========
Foo is Foo
Foo::Bar is undefined
Foo::VERSION is undefined
Foo::Hoge is Foo::Hoge
Foo::Hoge.piyo? is true


--
Daniele Alessandri
http://www.clorophilla.net/blog/