Isn''t that just keying off of RUBY_PLATFORM and other constants? ________________________________ From: Shri Borde <Shri.Borde at microsoft.com> Sent: Wednesday, March 03, 2010 9:55 AM To: ironruby-core at rubyforge.org <ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core at 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 at microsoft.com<mailto:jdeville at 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 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 Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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 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 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/20100303/c4ccaa1c/attachment-0001.html>
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 at microsoft.com> wrote:> Isn''t that just keying off of RUBY_PLATFORM and other constants? > > > > ------------------------------ > From: Shri Borde <Shri.Borde at microsoft.com> > Sent: Wednesday, March 03, 2010 9:55 AM > To: ironruby-core at rubyforge.org <ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 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/20100303/3c9712c3/attachment.html>
Digging deeper, it appears that when you require ''rubygems'' it looks at RbConfig, specifically RbConfig::CONFIG[''arch''] -- Will Green http://hotgazpacho.org/ On Wed, Mar 3, 2010 at 1:18 PM, Will Green <will at 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 at microsoft.com>wrote: > >> Isn''t that just keying off of RUBY_PLATFORM and other constants? >> >> >> >> ------------------------------ >> From: Shri Borde <Shri.Borde at microsoft.com> >> Sent: Wednesday, March 03, 2010 9:55 AM >> To: ironruby-core at rubyforge.org <ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green >> *Sent:* Tuesday, March 02, 2010 11:52 AM >> *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Tuesday, March 02, 2010 10:02 AM >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at 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 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/20100303/c2ea4593/attachment-0001.html>
Ivan Porto Carrero
2010-Mar-03 18:37 UTC
[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 at 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 at microsoft.com>wrote: > >> Isn''t that just keying off of RUBY_PLATFORM and other constants? >> >> >> >> ------------------------------ >> From: Shri Borde <Shri.Borde at microsoft.com> >> Sent: Wednesday, March 03, 2010 9:55 AM >> To: ironruby-core at rubyforge.org <ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green >> *Sent:* Tuesday, March 02, 2010 11:52 AM >> *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Tuesday, March 02, 2010 10:02 AM >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at 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 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100303/1eab587d/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero Sent: Wednesday, March 03, 2010 10:38 AM To: ironruby-core at 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at microsoft.com>> wrote: Isn''t that just keying off of RUBY_PLATFORM and other constants? ________________________________ From: Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> Sent: Wednesday, March 03, 2010 9:55 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> <ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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 Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at microsoft.com<mailto:jdeville at 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 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 Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100304/f1a35791/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Shri Borde
Sent: Wednesday, March 03, 2010 5:05 PM
To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Wednesday, March 03, 2010 10:38 AM
To: ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
Isn''t that just keying off of RUBY_PLATFORM and other constants?
________________________________
From: Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at
microsoft.com>>
Sent: Wednesday, March 03, 2010 9:55 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
<ironruby-core at rubyforge.org<mailto:ironruby-core at
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 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
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:jdeville at 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 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
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100304/91c4f210/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Wednesday, March 03, 2010 6:31 PM To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Wednesday, March 03, 2010 5:05 PM To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero Sent: Wednesday, March 03, 2010 10:38 AM To: ironruby-core at 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at microsoft.com>> wrote: Isn''t that just keying off of RUBY_PLATFORM and other constants? ________________________________ From: Shri Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> Sent: Wednesday, March 03, 2010 9:55 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> <ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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 Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at microsoft.com<mailto:jdeville at 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 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 Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100304/1eecc729/attachment-0001.html>