I will set RUBY_PLATFORM to “.net” and RbConfig::CONFIG[“arch”] to “universal-.net-2.0” (or “universal-.net-4.0” for the .NET 4 builds)
From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Ivan Porto Carrero Sent: Wednesday, March 03, 2010 10:38 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems we need to update rbconfig. it should also detect the runtime correctly --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Web: http://whiterabbitconsulting.eu - http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) Microsoft IronRuby/C# MVP On Wed, Mar 3, 2010 at 7:18 PM, Will Green <w...@hotgazpacho.org<mailto:w...@hotgazpacho.org>> wrote: It does seem to. Ruby Gems maintains a list of platform mappings. See lib\ruby\site_ruby\1.8\rubygems\platform.rb in the initialize method. Whatever initializes Gem::Platform seems to look at RUBY_PLATFORM C:\IronRuby\bin>ir IronRuby 0.9.4.0 on .NET 2.0.50727.4927 Copyright (c) Microsoft Corporation. All rights reserved. >>> require 'rubygems' => true >>> Gem::Platform.local() => #<Gem::Platform:0x1ec @cpu="x86", @os="mswin32", @version="60"> >>> RUBY_PLATFORM => "i386-mswin32" >>> p = Gem::Platform.new('universal-.net-3.5') => #<Gem::Platform:0x1ee @cpu="universal", @os=".net", @version="3.5"> -- Will Green http://hotgazpacho.org/ On Wed, Mar 3, 2010 at 1:10 PM, Jim Deville <jdevi...@microsoft.com<mailto:jdevi...@microsoft.com>> wrote: Isn't that just keying off of RUBY_PLATFORM and other constants? ________________________________ From: Shri Borde <shri.bo...@microsoft.com<mailto:shri.bo...@microsoft.com>> Sent: Wednesday, March 03, 2010 9:55 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> <ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>> Subject: Re: [Ironruby-core] IronRuby version of existing gems It does seem like there isn’t a way to distinguish between IronRuby and MRI. C:\> ir.exe >>> require "rubygems" => true >>> Gem::Platform.local() => #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60"> JRuby otoh does seem to do something different C:\> jruby.exe irb(main):001:0> require "rubygems" => true irb(main):002:0> Gem::Platform.local() => #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6"> From: ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org> [mailto:ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org>] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. Currently, it reports i386-mswin32. -- Will Green http://hotgazpacho.org/ On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdevi...@microsoft.com<mailto:jdevi...@microsoft.com>> wrote: I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == “ironruby”, (or .net, do we need to differentiate .net and mono?), but accept others. JD From: ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org> [mailto:ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org>] On Behalf Of Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: [Ironruby-core] IronRuby version of existing gems This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (“win32console” in this case), and specify platform==”ironruby”. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==”ironruby”, and MRI will use the one with platform==”mswin32”. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org> [mailto:ironruby-core-boun...@rubyforge.org<mailto:ironruby-core-boun...@rubyforge.org>] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 7:47 AM To: ironruby-core Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first. Please let me know if you still have trouble installing it from Rubygems.org. Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI. -- Will Green http://hotgazpacho.org/ _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
