Forum: IronRuby Re: IronRuby version of existing gems

Isn't that just keying off of RUBY_PLATFORM and other constants?



________________________________
From: Shri Borde <Shri.Borde@microsoft.com>
Sent: Wednesday, March 03, 2010 9:55 AM
To: ironruby-core@rubyforge.org <ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems

It does seem like there isn’t a way to distinguish between IronRuby and 
MRI.

C:\> ir.exe
>>> require "rubygems"
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60">

JRuby otoh does seem to do something different

C:\> jruby.exe
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> Gem::Platform.local()
=> #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6">

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

That all depends on how Gem checks the platform.  If it uses the 
RUBY_PLATFORM variable, then IronRuby needs to change what it reports 
here. Currently, it reports i386-mswin32.

--
Will Green
http://hotgazpacho.org/

On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. 
If possible we should prefer platform == “ironruby”, (or .net, do we 
need to differentiate .net and mono?), but accept others.

JD

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems

This brings a question to mind - what should the general approach be for 
porting existing gems to IronRuby? There could be two possible 
approaches:

1.       Create a gem with the same name (“win32console” in this case), 
and specify platform==”ironruby”. That way, dependent gems do not need 
to be updated, and users have to remember just one name. IronRuby will 
use the version with platform==”ironruby”, and MRI will use the one with 
platform==”mswin32”. So there should not be any clashes even if you use 
MRI and IronRuby on the same machine.

2.       Create a new gem like iron-term-ansicolor.

Any pro or cons to the two? What should the recommendation be in 
general?

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released

I released iron-term-ansicolor 0.0.3 last night after testing the gem 
install locally first.

Please let me know if you still have trouble installing it from 
Rubygems.org.

Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it 
can, the same way it tries to use win32console under MRI.

--
Will Green
http://hotgazpacho.org/

It does seem to.

Ruby Gems maintains a list of platform mappings.

See lib\ruby\site_ruby\1.8\rubygems\platform.rb in the initialize 
method.
Whatever initializes Gem::Platform seems to look at RUBY_PLATFORM

C:\IronRuby\bin>ir
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'rubygems'
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1ec @cpu="x86", @os="mswin32", @version="60">
>>> RUBY_PLATFORM
=> "i386-mswin32"
>>> p = Gem::Platform.new('universal-.net-3.5')
=> #<Gem::Platform:0x1ee @cpu="universal", @os=".net", @version="3.5">

--
Will Green
http://hotgazpacho.org/

Digging deeper, it appears that when you require 'rubygems' it looks at
RbConfig, specifically RbConfig::CONFIG['arch']

--
Will Green
http://hotgazpacho.org/

we need to update rbconfig. it should also detect the runtime correctly
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Web: http://whiterabbitconsulting.eu - http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
Microsoft IronRuby/C# MVP

I will set RUBY_PLATFORM to “.net” and RbConfig::CONFIG[“arch”] to 
“universal-.net-2.0” (or “universal-.net-4.0” for the .NET 4 builds)

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto 
Carrero
Sent: Wednesday, March 03, 2010 10:38 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

we need to update rbconfig. it should also detect the runtime correctly
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Web: http://whiterabbitconsulting.eu - http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
Microsoft IronRuby/C# MVP

On Wed, Mar 3, 2010 at 7:18 PM, Will Green 
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote:
It does seem to.

Ruby Gems maintains a list of platform mappings.

See lib\ruby\site_ruby\1.8\rubygems\platform.rb in the initialize 
method. Whatever initializes Gem::Platform seems to look at 
RUBY_PLATFORM

C:\IronRuby\bin>ir
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'rubygems'
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1ec @cpu="x86", @os="mswin32", @version="60">
>>> RUBY_PLATFORM
=> "i386-mswin32"
>>> p = Gem::Platform.new('universal-.net-3.5')
=> #<Gem::Platform:0x1ee @cpu="universal", @os=".net", @version="3.5">

--
Will Green
http://hotgazpacho.org/

On Wed, Mar 3, 2010 at 1:10 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
Isn't that just keying off of RUBY_PLATFORM and other constants?


________________________________
From: Shri Borde 
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>>
Sent: Wednesday, March 03, 2010 9:55 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> 
<ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>>

Subject: Re: [Ironruby-core] IronRuby version of existing gems
It does seem like there isn’t a way to distinguish between IronRuby and 
MRI.

C:\> ir.exe
>>> require "rubygems"
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60">

JRuby otoh does seem to do something different

C:\> jruby.exe
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> Gem::Platform.local()
=> #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6">

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems

That all depends on how Gem checks the platform.  If it uses the 
RUBY_PLATFORM variable, then IronRuby needs to change what it reports 
here. Currently, it reports i386-mswin32.

--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. 
If possible we should prefer platform == “ironruby”, (or .net, do we 
need to differentiate .net and mono?), but accept others.

JD

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems

This brings a question to mind - what should the general approach be for 
porting existing gems to IronRuby? There could be two possible 
approaches:

1.       Create a gem with the same name (“win32console” in this case), 
and specify platform==”ironruby”. That way, dependent gems do not need 
to be updated, and users have to remember just one name. IronRuby will 
use the version with platform==”ironruby”, and MRI will use the one with 
platform==”mswin32”. So there should not be any clashes even if you use 
MRI and IronRuby on the same machine.

2.       Create a new gem like iron-term-ansicolor.

Any pro or cons to the two? What should the recommendation be in 
general?

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released

I released iron-term-ansicolor 0.0.3 last night after testing the gem 
install locally first.

Please let me know if you still have trouble installing it from 
Rubygems.org.

Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it 
can, the same way it tries to use win32console under MRI.

--
Will Green
http://hotgazpacho.org/


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


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


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

Does anyone know if this will allow authoring of IronRuby-specific gems? 
Would the same value be used in the gemspec?

After installing win32console, I looked at 
gems\1.8\gems\specifications\win32console-1.2.0-x86-mingw32.gemspec, and 
it had this line:

s.platform = %q{x86-mingw32}

Note that this is different than the value of RbConfig::CONFIG[“arch”] 
in MRI, which is "i386-mingw32". So not sure how exactly this works. 
Perhaps RubyGems has a special case for x86==i386?

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, March 03, 2010 5:05 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

I will set RUBY_PLATFORM to “.net” and RbConfig::CONFIG[“arch”] to 
“universal-.net-2.0” (or “universal-.net-4.0” for the .NET 4 builds)

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto 
Carrero
Sent: Wednesday, March 03, 2010 10:38 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

we need to update rbconfig. it should also detect the runtime correctly
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Web: http://whiterabbitconsulting.eu - http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
Microsoft IronRuby/C# MVP
On Wed, Mar 3, 2010 at 7:18 PM, Will Green 
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote:
It does seem to.

Ruby Gems maintains a list of platform mappings.

See lib\ruby\site_ruby\1.8\rubygems\platform.rb in the initialize 
method. Whatever initializes Gem::Platform seems to look at 
RUBY_PLATFORM

C:\IronRuby\bin>ir
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'rubygems'
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1ec @cpu="x86", @os="mswin32", @version="60">
>>> RUBY_PLATFORM
=> "i386-mswin32"
>>> p = Gem::Platform.new('universal-.net-3.5')
=> #<Gem::Platform:0x1ee @cpu="universal", @os=".net", @version="3.5">

--
Will Green
http://hotgazpacho.org/
On Wed, Mar 3, 2010 at 1:10 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
Isn't that just keying off of RUBY_PLATFORM and other constants?

________________________________
From: Shri Borde 
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>>
Sent: Wednesday, March 03, 2010 9:55 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> 
<ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>>

Subject: Re: [Ironruby-core] IronRuby version of existing gems
It does seem like there isn’t a way to distinguish between IronRuby and 
MRI.

C:\> ir.exe
>>> require "rubygems"
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60">

JRuby otoh does seem to do something different

C:\> jruby.exe
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> Gem::Platform.local()
=> #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6">

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems

That all depends on how Gem checks the platform.  If it uses the 
RUBY_PLATFORM variable, then IronRuby needs to change what it reports 
here. Currently, it reports i386-mswin32.

--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. 
If possible we should prefer platform == “ironruby”, (or .net, do we 
need to differentiate .net and mono?), but accept others.

JD

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems

This brings a question to mind - what should the general approach be for 
porting existing gems to IronRuby? There could be two possible 
approaches:

1.       Create a gem with the same name (“win32console” in this case), 
and specify platform==”ironruby”. That way, dependent gems do not need 
to be updated, and users have to remember just one name. IronRuby will 
use the version with platform==”ironruby”, and MRI will use the one with 
platform==”mswin32”. So there should not be any clashes even if you use 
MRI and IronRuby on the same machine.

2.       Create a new gem like iron-term-ansicolor.

Any pro or cons to the two? What should the recommendation be in 
general?

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released

I released iron-term-ansicolor 0.0.3 last night after testing the gem 
install locally first.

Please let me know if you still have trouble installing it from 
Rubygems.org.

Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it 
can, the same way it tries to use win32console under MRI.

--
Will Green
http://hotgazpacho.org/


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


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


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

Answering my own question about x86==i386, they are treated as equal:

>>> Gem::Platform.new("i386-mingw32") === Gem::Platform.new("x86-mingw32")
true

http://rubygems.rubyforge.org/rubygems-update/Gem/Platform.html has 
implementations of the different functions (click on the function names)

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, March 03, 2010 6:31 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

Does anyone know if this will allow authoring of IronRuby-specific gems? 
Would the same value be used in the gemspec?

After installing win32console, I looked at 
gems\1.8\gems\specifications\win32console-1.2.0-x86-mingw32.gemspec, and 
it had this line:

s.platform = %q{x86-mingw32}

Note that this is different than the value of RbConfig::CONFIG[“arch”] 
in MRI, which is "i386-mingw32". So not sure how exactly this works. 
Perhaps RubyGems has a special case for x86==i386?

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, March 03, 2010 5:05 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

I will set RUBY_PLATFORM to “.net” and RbConfig::CONFIG[“arch”] to 
“universal-.net-2.0” (or “universal-.net-4.0” for the .NET 4 builds)

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto 
Carrero
Sent: Wednesday, March 03, 2010 10:38 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems

we need to update rbconfig. it should also detect the runtime correctly
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Web: http://whiterabbitconsulting.eu - http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
Microsoft IronRuby/C# MVP
On Wed, Mar 3, 2010 at 7:18 PM, Will Green 
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote:
It does seem to.

Ruby Gems maintains a list of platform mappings.

See lib\ruby\site_ruby\1.8\rubygems\platform.rb in the initialize 
method. Whatever initializes Gem::Platform seems to look at 
RUBY_PLATFORM

C:\IronRuby\bin>ir
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'rubygems'
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1ec @cpu="x86", @os="mswin32", @version="60">
>>> RUBY_PLATFORM
=> "i386-mswin32"
>>> p = Gem::Platform.new('universal-.net-3.5')
=> #<Gem::Platform:0x1ee @cpu="universal", @os=".net", @version="3.5">

--
Will Green
http://hotgazpacho.org/
On Wed, Mar 3, 2010 at 1:10 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
Isn't that just keying off of RUBY_PLATFORM and other constants?
________________________________
From: Shri Borde 
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>>
Sent: Wednesday, March 03, 2010 9:55 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> 
<ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>>

Subject: Re: [Ironruby-core] IronRuby version of existing gems
It does seem like there isn’t a way to distinguish between IronRuby and 
MRI.

C:\> ir.exe
>>> require "rubygems"
=> true
>>> Gem::Platform.local()
=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60">

JRuby otoh does seem to do something different

C:\> jruby.exe
irb(main):001:0> require "rubygems"
=> true
irb(main):002:0> Gem::Platform.local()
=> #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6">

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems

That all depends on how Gem checks the platform.  If it uses the 
RUBY_PLATFORM variable, then IronRuby needs to change what it reports 
here. Currently, it reports i386-mswin32.

--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville 
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. 
If possible we should prefer platform == “ironruby”, (or .net, do we 
need to differentiate .net and mono?), but accept others.

JD

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems

This brings a question to mind - what should the general approach be for 
porting existing gems to IronRuby? There could be two possible 
approaches:

1.       Create a gem with the same name (“win32console” in this case), 
and specify platform==”ironruby”. That way, dependent gems do not need 
to be updated, and users have to remember just one name. IronRuby will 
use the version with platform==”ironruby”, and MRI will use the one with 
platform==”mswin32”. So there should not be any clashes even if you use 
MRI and IronRuby on the same machine.

2.       Create a new gem like iron-term-ansicolor.

Any pro or cons to the two? What should the recommendation be in 
general?

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released

I released iron-term-ansicolor 0.0.3 last night after testing the gem 
install locally first.

Please let me know if you still have trouble installing it from 
Rubygems.org.

Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it 
can, the same way it tries to use win32console under MRI.

--
Will Green
http://hotgazpacho.org/


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


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


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