# Iron-term-ansicolor 0.0.2 Released **URL:** \ **Category:** IronRuby\ **Created:** [February 27, 2010, 5:16am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249 "2010-02-27T05:16:45Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 5, 2010, 4:57pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/21 "2010-03-05T16:57:12Z")
We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 5, 2010, 5:13pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/22 "2010-03-05T17:13:37Z")
I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 5, 2010, 7:07pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/23 "2010-03-05T19:07:14Z")
I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 5, 2010, 6:01pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/24 "2010-03-05T18:01:05Z")
The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 2:43am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/25 "2010-03-06T02:43:46Z")
The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 5:44am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/26 "2010-03-06T05:44:39Z")
See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console- mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake- compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 7:59am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/27 "2010-03-06T07:59:17Z")
So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 8:52am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/28 "2010-03-06T08:52:32Z")
rake-compiler does support fat binaries gem ([http://tenderlovemaking.com/2009/05/07/fat-binary-gems-make-the-rockin-world-go-round/](http://tenderlovemaking.com/2009/05/07/fat-binary-gems-make-the-rockin-world-go-round/)) which is a single gem file with binaries for multiple platforms. However, the main reason to do this is to support both Ruby 1.8 and 1.9 which need different extension binaries, but Gem::Platform does not have a way to specify the Ruby version. I don’t see why you would need to use this fat binaries gem solution for supporting IronRuby where Gem::Platform can be used. [GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue.](http://github.com/luislavena/rake-compiler) does show two commands “rake native gem” and “rake java gem” to generate my\_gem-0.1.0-x86-mingw32.gem and my\_gem-0.1.0-java.gem respectively, which seem to be platform-specific gem files. So perhaps it supports both approaches (single fat binaries gem file, and multiple platform-specific gem files) * * * From: removed\_email\_address@domain.invalid [removed\_email\_address@domain.invalid] on behalf of Will G. [removed\_email\_address@domain.invalid] Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 3:03pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/29 "2010-03-06T15:03:33Z")
Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 3:12pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/30 "2010-03-06T15:12:55Z")
my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 6, 2010, 7:31pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/31 "2010-03-06T19:31:01Z")
Will, Tomas and I did discuss setting RUBY\_PLATFORM to something like “x86-mswin32.net”, but decided to keep things simple. If the app needs to check if it is running on IronRuby, it can always look for RUBY\_ENGINE==”ironruby”. For legacy apps, changing RUBY\_PLATFORM does not help, and will probably even hurt in many cases where app does RUBY\_PLATFORM==”x86-win32” to check for Windows. Ivan, Tomas had already fixed RUBY\_PLATFORM to be “i386-linux” for Linux in early January. So you should not need to use ENV[‘OS’] anymore. Jim has pushed the changes for RbConfig::CONFIG[“arch”]. So please do try out the new GIT sources, or the RC3 when it comes out (which should be in a week or so). From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto Carrero Sent: Saturday, March 06, 2010 6:12 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP On Sat, Mar 6, 2010 at 2:50 PM, Will G. \ wrote: Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. \ wrote: So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 12:58am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/32 "2010-03-07T00:58:48Z")
I don’t think that the RUBY\_PLATFORM check would hurt legacy apps considering RUBY\_ENGINE doesn’t exist on those systems. Also, in regards to gem names and platform specific gems: You don’t install foo\_mswin32, you install foo, and gem finds the right one for you. I don’t believe gem has the logic to find a different gem if the one you are looking doesn’t have a more specific version available. JD From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Saturday, March 06, 2010 10:25 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, Tomas and I did discuss setting RUBY\_PLATFORM to something like “x86-mswin32.net”, but decided to keep things simple. If the app needs to check if it is running on IronRuby, it can always look for RUBY\_ENGINE==”ironruby”. For legacy apps, changing RUBY\_PLATFORM does not help, and will probably even hurt in many cases where app does RUBY\_PLATFORM==”x86-win32” to check for Windows. Ivan, Tomas had already fixed RUBY\_PLATFORM to be “i386-linux” for Linux in early January. So you should not need to use ENV[‘OS’] anymore. Jim has pushed the changes for RbConfig::CONFIG[“arch”]. So please do try out the new GIT sources, or the RC3 when it comes out (which should be in a week or so). From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto Carrero Sent: Saturday, March 06, 2010 6:12 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP On Sat, Mar 6, 2010 at 2:50 PM, Will G. \ wrote: Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. \ wrote: So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 12:38am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/33 "2010-03-07T00:38:18Z")
I’ll certainly try it out, but I remain skeptical of this decission. Out of curiosity, what is the value of RUBY\_PLATFORM when running under Mono on OS X and Mono on Linux? FWIW, JRuby 1.4.0 reports RUBY\_PLATFORM as “java”. The underlying OS is set in in the host\_os key in rbconfig: [JRuby 1.4.0] require ‘rbconfig’ Config::CONFIG[‘host\_os’] =\> “mswin32” On OS X, I’m told it returns “darwin”, and on Linux, supposedly “linux”. IMO, this seems like a much better, more accurate way to do OS detection. Think about it this way: when you write extensions for IronRuby, what platform are you targetting? Not Win32 or Darwin or Linux. You’re targetting the .Net platform! I really think that IronRuby should report “.net” for RUBY\_PLATFORM, and include the host OS in the host\_os key in RbConfig. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 4:30am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/34 "2010-03-07T04:30:39Z")
I could not parse your reply fully. If a legacy app is doing the following, it will break if we change RUBY\_PLATFORM: if RUBY\_PLATFORM==’x86-mswin32’ then DoSomeWindowsThing() else DoTheUnixThing() end Let’s get some real world cases where we want RUBY\_PLATFORM to be different, and then we can discuss how exactly to set it. Keeping it the same as MRI for now is the simplest thing we can. We did need to change RbConfig::CONFIG[“arch”] to enable IronRuby-specific gems, but we don’t have any concrete scenario where we need to change RUBY\_PLATFORM. About platform specific gems, I am just pointing out that an IronRuby-specific version of win32console can co-exist side-by-side with the MRI version. They do not need to be merged into a single fat binary gem. From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Jim D. Sent: Saturday, March 06, 2010 3:53 PM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems I don’t think that the RUBY\_PLATFORM check would hurt legacy apps considering RUBY\_ENGINE doesn’t exist on those systems. Also, in regards to gem names and platform specific gems: You don’t install foo\_mswin32, you install foo, and gem finds the right one for you. I don’t believe gem has the logic to find a different gem if the one you are looking doesn’t have a more specific version available. JD From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Saturday, March 06, 2010 10:25 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, Tomas and I did discuss setting RUBY\_PLATFORM to something like “x86-mswin32.net”, but decided to keep things simple. If the app needs to check if it is running on IronRuby, it can always look for RUBY\_ENGINE==”ironruby”. For legacy apps, changing RUBY\_PLATFORM does not help, and will probably even hurt in many cases where app does RUBY\_PLATFORM==”x86-win32” to check for Windows. Ivan, Tomas had already fixed RUBY\_PLATFORM to be “i386-linux” for Linux in early January. So you should not need to use ENV[‘OS’] anymore. Jim has pushed the changes for RbConfig::CONFIG[“arch”]. So please do try out the new GIT sources, or the RC3 when it comes out (which should be in a week or so). From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto Carrero Sent: Saturday, March 06, 2010 6:12 AM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP On Sat, Mar 6, 2010 at 2:50 PM, Will G. \ wrote: Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. \ wrote: So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 4:43am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/35 "2010-03-07T04:43:33Z")
RUBY\_PLATFORM on IronRuby will be the same as the value shown by MRI on that machine. It will be i386-darwin on Mac OS and i386-linux on Linux. The issue is that RUBY\_PLATFORM could be used for multiple purposes. It could be used to decide whether to use fork or not, whether to assume use Etc.rb or not, etc, and is indeed used in this way by many apps. So there is no one right answer. If you are writing a gem for IronRuby, you do set the gem platform to “universal-.net”, and that does work. Any specific scenario you think would still be an issue? From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Saturday, March 06, 2010 3:36 PM To: removed\_email\_address@domain.invalid Subject: Re: [Ironruby-core] IronRuby version of existing gems I’ll certainly try it out, but I remain skeptical of this decission. Out of curiosity, what is the value of RUBY\_PLATFORM when running under Mono on OS X and Mono on Linux? FWIW, JRuby 1.4.0 reports RUBY\_PLATFORM as “java”. The underlying OS is set in in the host\_os key in rbconfig: [JRuby 1.4.0] require ‘rbconfig’ Config::CONFIG[‘host\_os’] =\> “mswin32” On OS X, I’m told it returns “darwin”, and on Linux, supposedly “linux”. IMO, this seems like a much better, more accurate way to do OS detection. Think about it this way: when you write extensions for IronRuby, what platform are you targetting? Not Win32 or Darwin or Linux. You’re targetting the .Net platform! I really think that IronRuby should report “.net” for RUBY\_PLATFORM, and include the host OS in the host\_os key in RbConfig. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:24 PM, Shri B. \ wrote: Will, Tomas and I did discuss setting RUBY\_PLATFORM to something like “x86-mswin32.net”, but decided to keep things simple. If the app needs to check if it is running on IronRuby, it can always look for RUBY\_ENGINE==”ironruby”. For legacy apps, changing RUBY\_PLATFORM does not help, and will probably even hurt in many cases where app does RUBY\_PLATFORM==”x86-win32” to check for Windows. Ivan, Tomas had already fixed RUBY\_PLATFORM to be “i386-linux” for Linux in early January. So you should not need to use ENV[‘OS’] anymore. Jim has pushed the changes for RbConfig::CONFIG[“arch”]. So please do try out the new GIT sources, or the RC3 when it comes out (which should be in a week or so). From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto Carrero Sent: Saturday, March 06, 2010 6:12 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP On Sat, Mar 6, 2010 at 2:50 PM, Will G. \ wrote: Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. \ wrote: So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 7:22am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/36 "2010-03-07T07:22:46Z")
I think you can set the platform to be “universal-.net” and it will work on all .NET versions. From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Saturday, March 06, 2010 9:47 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems With the rbconfig changes made, I now get the expected output when trying to install a gem that has only platform-specific gems available (and is the same as what I get on JRuby): C:\Users\Will\dev\ironruby\>rbx -S gem install win32console ERROR: could not find gem win32console locally or in a repository I’ll be updating iron-term-ansicolor, and I’ll start looking at merging this code with win32console, so that a win32console-universal-.net2.0.gem can be be made. Do I understand it right that IronRuby on .Net 4 will need a win32console-universal-.net4.0.gem? – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Sat, Mar 6, 2010 at 10:33 PM, Shri B. \ wrote: RUBY\_PLATFORM on IronRuby will be the same as the value shown by MRI on that machine. It will be i386-darwin on Mac OS and i386-linux on Linux. The issue is that RUBY\_PLATFORM could be used for multiple purposes. It could be used to decide whether to use fork or not, whether to assume use Etc.rb or not, etc, and is indeed used in this way by many apps. So there is no one right answer. If you are writing a gem for IronRuby, you do set the gem platform to “universal-.net”, and that does work. Any specific scenario you think would still be an issue? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Saturday, March 06, 2010 3:36 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’ll certainly try it out, but I remain skeptical of this decission. Out of curiosity, what is the value of RUBY\_PLATFORM when running under Mono on OS X and Mono on Linux? FWIW, JRuby 1.4.0 reports RUBY\_PLATFORM as “java”. The underlying OS is set in in the host\_os key in rbconfig: [JRuby 1.4.0] require ‘rbconfig’ Config::CONFIG[‘host\_os’] =\> “mswin32” On OS X, I’m told it returns “darwin”, and on Linux, supposedly “linux”. IMO, this seems like a much better, more accurate way to do OS detection. Think about it this way: when you write extensions for IronRuby, what platform are you targetting? Not Win32 or Darwin or Linux. You’re targetting the .Net platform! I really think that IronRuby should report “.net” for RUBY\_PLATFORM, and include the host OS in the host\_os key in RbConfig. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:24 PM, Shri B. \ wrote: Will, Tomas and I did discuss setting RUBY\_PLATFORM to something like [“x86-mswin32.net](http://xn--x86-mswin32-v7a38l8y9v.net)[http://x86-mswin32.net](http://x86-mswin32.net)”, but decided to keep things simple. If the app needs to check if it is running on IronRuby, it can always look for RUBY\_ENGINE==”ironruby”. For legacy apps, changing RUBY\_PLATFORM does not help, and will probably even hurt in many cases where app does RUBY\_PLATFORM==”x86-win32” to check for Windows. Ivan, Tomas had already fixed RUBY\_PLATFORM to be “i386-linux” for Linux in early January. So you should not need to use ENV[‘OS’] anymore. Jim has pushed the changes for RbConfig::CONFIG[“arch”]. So please do try out the new GIT sources, or the RC3 when it comes out (which should be in a week or so). From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Ivan Porto C. Sent: Saturday, March 06, 2010 6:12 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems my vote goes to making the rb config file as much self discoverable as possible. Most of the info can be gotten from the .NET runtime environment I’ve run into this problem a couple of times because I’m trying to run IronRuby on mono pretty often. Until now I’ve resorted to using ENV[‘OS’] == “Windows\_NT” to figure out which OS I’m running on and I’ve also had to patch a few gems to detect the OS and features properly. * * * Met vriendelijke groeten - Best regards - Salutations Ivan Porto C. - Mob: +32.486.787.582 Web: [http://whiterabbitconsulting.eu](http://whiterabbitconsulting.eu) - [http://flanders.co.nz](http://flanders.co.nz) Twitter: [http://twitter.com/casualjim](http://twitter.com/casualjim) Author of IronRuby in Action ([http://manning.com/carrero](http://manning.com/carrero)) Microsoft IronRuby/C# MVP On Sat, Mar 6, 2010 at 2:50 PM, Will G. \ wrote: Yes, that seems to be close to my understanding. Only much more eloquently stated. Thank you! 🙂 Also keep in mind that not everyone using Ruby uses Ruby Gems. In fact, it is considered rude to presume the existance of any library package management system by the consumer. So, RUBY\_PLATFORM is a more important constant to define correctly for platform detection (since this IS present for every Ruby implementation). Now for feature detection, libraries usually do a regex match on RUBY\_PLATFORM, usually RUBY\_PLATFORM =~ /mswin|mingw/ So, we might define RUBY\_PLATFORM as mswin.netX, linux.netX, macosx.netX, etc. (where X is the .Net runtime version). However, I still think we’ll run into libraries that make other assumptions about the Ruby runtime that won’t be true or IronRuby. Such libraries would need to be patched to recognize the extended platform name. I don’t have JRuby installed, and I don’t have a Mac to check on, either, but perhaps it might provide some guidance to see what JRuby defines RUBY\_PLATFORM as on the various OSes. On a side note, thank you Shri, Tomas, and everyone else for taking my impassioned pleas for what they truly are: a desire to make IronRuby an awesome, well-manored Ruby implementation! Keep up the good work! – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 6, 2010, at 1:58 AM, Tomas M. \ wrote: So basically, if I understand it well, there are two variables in question: 1. ``` “native” extension formats supported by particular Ruby VM – ``` that would be MSVC6 compiled PE file/mingw compiled PE file/gcc compiled .so file for MRI, Java class file for JRuby and CLR assembly for IronRuby. Any subsystem that builds/uses “native” extensions needs to use this variable. A particular VM can support multiple formats (JRuby supports Java class files and FFI compatible native extensions). This is what Gem::Platform seems to be used for. 1. ``` The capabilities of the underlying CPU and OS. This is what ``` RUBY\_PLATFORM is used for – behavior of certain APIs like fork, etc, process, files, etc. might be different/unavailable on different platforms. Is that correct? Tomas From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:18 PM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems See [http://docs.rubygems.org/read/chapter/20#platform](http://docs.rubygems.org/read/chapter/20#platform) Basically, most gems contain pure Ruby code. Some gems contain C (or Java, or now possibly C#) code that gets compiled at gem install time. Some gems even include pre-compiled code. You will find that the overwhelming majority of these gems target the mswin32 platform (which is based on the VC6 runtime). The reason that binary gems are distributed is that, unlike on most Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had a license to MSVC 6 to provide binaries of the gems they needed. This is a major reason why development of the mswin32 Ruby has ceased… Very few people have MSVC6, it’s old and slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) can’t get it anymore. This is why the mingw32 version of Ruby is the actively maintained version of C Ruby on Windows: no worries about mingw licensing and distribution, and it’s freely available. This is the reason why it is important that IronRuby report the correct architecture and runtime environment. As I said before, Gems that target mswin32 will not run on IronRuby, because the thing that makes them mswin32 is that they include C extensions that can be, or are, compiled to native, unmanaged code targetting the MSVC6 runtime. So, it is important that IronRuby not identify itself as mswin32, because the gems that target that platform won’t work on IronRuby anyway. What Luis has done with Rake Compiler is allow the gem author to create extensions in C and Java, and permit them to compile platform specific versions of the same gem. I’m sure that he would welcome contributions that would allow us to write extensions in C# and build gems that target IronRuby as a platform, all while keeping the same gem name. That is, win32console-mswin32.gem and win32console-mingw32.gem come from the same source gem, but they are compiled against different runtimes, and target different platforms. With IronRuby identifying itself correctly, and some additions to rake-compiler to generate .Net assemblies, it may be possible to generate a win32console-.net20.gem. Even then, we’d need to provide patches to libraries that use a regex against RUBY\_PLATFORM to determine if we’re running on Windows. But then, what if you’re running IronRuby on Mono on Linux, where any of the win32xxx gems make no sense? My point is that I don’t see a way to just inject IronRuby-specific libraries in place of the mswin32 ones without causing all sorts of headaches with platform juggling. IronRuby is not always on Windows, and thus should not identify itself as running on Windows, and certainly should not identify itself as the MSVC6 version or Ruby. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Mar 5, 2010, at 8:39 PM, Shri B. \ wrote: The gem file name does include the platform information. That would seem to imply that gems for different platforms will live in different gem files. I am not too knowledge about the Gem process as well, so I may be incorrect as well… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 9:46 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I may not fully understand the Gem process here, so please pardon any ignorance. As I understand it, the ability to have separate, per-platform gem files for one Gem name would require that the code for all the platforms is present in the source of the Gem. That way, when you gem install XXX, the XXX library will get compiled locally for your current platform. Or, if the gem author provides them, pre-compiled binaries for your platform. In order to do that, though, I think the source code for multiple platforms needs to be present in the gem source. Luis is very knowledgeable in this area; he also wrote rake-compiler to address this issue with JRuby as well: > **[GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way...](https://github.com/rake-compiler/rake-compiler)** > > Provide a standard and simplified way to build and package Ruby C and Java extensions using Rake as glue. - GitHub - rake-compiler/rake-compiler: Provide a standard and simplified way to build and ... I think it best to get his perspective on the best way to go about this. I am, however, glad that IronRuby is now more truthful about its architecture (since gems compiled for mswin32 WILL NOT WORK on IronRuby). I am certain this will lead to less frustration from end-users going forward. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 12:00 PM, Shri B. \ wrote: The whole point of changing RbConfig::CONFIG[“arch”] was to be able to have two independent gem files. So you should not need to have to modify Luis L.’s code, right? And people installing win32console with MRI should not run any of your code, right? You could certainly drop him a line as a courtesy heads-up… From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 8:11 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems I’d have to talk to Luis L., the current maintainer of win32console. I might also have to make some code changes or test changes to make the .Net specific stuff a no-op on the C version of Ruby (otherwise, it won’t even run). But I’d certainly be open to this. I’ll drop him a line this weekend. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Fri, Mar 5, 2010 at 10:45 AM, Shri B. \ wrote: We should push the change once the dust settles down. Let’s wait until the RTM to make sure that this all actually works as we would like it to. In the meantime, I would encourage all gem authors to play with this and see if there are any issues. “gem build” had the issue mentioned below. Not sure if jeweler etc will have any issues. Will, will you be renaming iron-term-ansicolor to win32console? Its your call whether you want to or not. However, if you do not, we should create a gem with platform=”universal-.net” and with the same name of a native gem, and see what the experience is (does “ir.exe –S gem install” prefer the .NET gem over the native gem?). I did verify that “ir.exe –S gem install win32console” currently does not find any matching gem since the existing win32console is a native gem. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Friday, March 05, 2010 7:08 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: [Ironruby-core] IronRuby version of existing gems Cool beans! I noticed in the latest push that a change was made to Ruby Gems itself: [http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0](http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0) Someone should contribute that change to the Ruby Gems project as well. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Thu, Mar 4, 2010 at 7:36 PM, Shri B. \ wrote: With my last checkin, RbConfig::CONFIG[“arch”] will be “universal-.net2.0” for IronRuby. I created a gemspec as shown below. Doing “gem build” on it will create a gem with filename of Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem build” and you will get a file called Shri-1.2.3-universal-.net.gem. spec = Gem::Specification.new do |s| s.name[http://s.name](http://s.name) = ‘Shri’ s.version = ‘1.2.3’ s.summary = “Shri summary” s.platform = “universal-.net[http://universal-.net](http://universal-.net)” s.description = %{Shri description} s.files = [] s.author = “Shri” s.email = “shri@email” s.homepage = “[http://shri.org](http://shri.org)” end I have updated with [http://ironruby.net/Documentation/Real\_Ruby\_Applications/RubyGems](http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems) with this info: IronRuby-specific gems Gems could specifically target IronRuby. They may contain Ruby code which uses .NET APIs, or they may even include compiled .NET assemblies. In such cases, the Gem specification should set platform [http://rubygems.org/read/chapter/20#platform](http://rubygems.org/read/chapter/20#platform) to “universal-.net[http://universal-.net](http://universal-.net)” (or “universal-.net4.0” to run only on .NET 4), and build the gem using IronRuby (“rbx -S gem build”). Note that if you build the gem with MRI using “gem build”, MRI will not be able to recognize the platform string, and will create a gem file named something like foo-universal-unknown.gem (instead of the expected foo-universal-.net.gem"). To avoid this, build the gem using IronRuby as mentioned above. Talking with Tomas, we will leave RUBY\_PLATFORM set to “x86-mswin32” (on Windows) since many apps check for “mswin32” in RUBY\_PLATFORM to check if they are running on Windows. We considered appending “.net” and setting RUBY\_PLATFORM to “.net-mswin32” or “x86-mswin32/.net” to indicate that it was not MRI, but decided against it as you can always check RUBY\_ENGINE to detect if you are running on IronRuby. From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. Sent: Tuesday, March 02, 2010 11:52 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) On Tue, Mar 2, 2010 at 1:07 PM, Jim D. \ 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: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Shri B. Sent: Tuesday, March 02, 2010 10:02 AM To: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. 1. ``` Create a new gem like iron-term-ansicolor. ``` Any pro or cons to the two? What should the recommendation be in general? From: removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Will G. 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](http://Rubygems.org)[http://Rubygems.org](http://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 G. [http://hotgazpacho.org/](http://hotgazpacho.org/) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) * * * Ironruby-core mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 6:56am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/37 "2010-03-07T06:56:25Z")
With the rbconfig changes made, I now get the expected output when trying to install a gem that has only platform-specific gems available (and is the same as what I get on JRuby): C:\Users\Will\dev\ironruby\>rbx -S gem install win32console ERROR: could not find gem win32console locally or in a repository I’ll be updating iron-term-ansicolor, and I’ll start looking at merging this code with win32console, so that a win32console-universal-.net2.0.gem can be be made. Do I understand it right that IronRuby on .Net 4 will need a win32console-universal-.net4.0.gem? – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 8:31am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/38 "2010-03-07T08:31:14Z")
I just pushed both “universal-.net” and “universal-.net-2.0” versions to > **[RubyGems.org | your community gem host](https://rubygems.org)** I would appreciate if someone running the latest from git would try ir -S gem install iron-term-ansicolor on both the .Net 2 and the .Net 4 runtimes, and let me know which gem gets installed. I don’t have .Net 4 installed, so for me, it selected the more specific version for .Net 2: C:\Users\Will\dev\iron-term-ansicolor\>igem install iron-term-ansicolor Successfully installed iron-term-ansicolor-0.0.3-universal-.net-2.0 1 gem installed ## Thanks! Will G. > **[hotgazpacho](http://hotgazpacho.org/)** ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 10:20am UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/39 "2010-03-07T10:20:04Z")
On Sun, Mar 7, 2010 at 08:07, Will G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I would appreciate if someone running the latest from git would try > ir -S gem install iron-term-ansicolor > on both the .Net 2 and the .Net 4 runtimes, and let me know which gem gets > installed. C:\Users\nrk\Repositories\ironruby\Merlin\Main\bin\Debug\>ir --version IronRuby 0.9.4.0 on .NET 2.0.50727.4200 C:\Users\nrk\Repositories\ironruby\Merlin\Main\bin\Debug\>ir -S gem install iron-term-ansicolor --no-rdoc --no-ri Successfully installed iron-term-ansicolor-0.0.3-universal-.net-2.0 1 gem installed C:\Users\nrk\Repositories\ironruby\Merlin\Main\bin\Debug\>ir --version IronRuby 0.9.4.0 on .NET 4.0.30128.1 C:\Users\nrk\Repositories\ironruby\Merlin\Main\bin\Debug\>ir -S gem install iron-term-ansicolor --no-rdoc --no-ri Successfully installed iron-term-ansicolor-0.0.3 1 gem installed – Daniele A. > **[clorophilla.net](https://clorophilla.net/)** [http://twitter.com/JoL1hAHN](http://twitter.com/JoL1hAHN) ---
**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\ **Post date:** [March 7, 2010, 4:03pm UTC](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249/40 "2010-03-07T16:03:37Z")
Thanks, Daniele! I’ve got three version of iron-term-ansicolor out there on [RubyGems.org](http://RubyGems.org): - iron-term-ansicolor-0.0.3 (gemspec.platform=“ruby”) - iron-term-ansicolor-0.0.3-universal-.net (gemspec.platform=“universal-.net”) - iron-term-ansicolor-0.0.3-universal-.net-2.0 (gemspec.platform=“universal-.net-2.0”) It looks like the .Net 4 runtime selected the non-platform specific gem, while the .Net 2 runtime selected the “universal-.net-2.0” gem. – Will G. [http://hotgazpacho.org/](http://hotgazpacho.org/) [Previous page](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249.md?page=1) [Next page](https://www.ruby-forum.com/t/iron-term-ansicolor-0-0-2-released/184249.md?page=3)