Tonight, I released an update to iron-term-ansicolor, a library for IronRuby that provides console colors for apps like RSpec and Cucumber (Cucumber already makes use of this, and I bet it would not be too much trouble to add to RSpec). http://rubygems.org/gems/iron-term-ansicolor <http://rubygems.org/gems/iron-term-ansicolor>igem install iron-term-ansicolor The source is available on github: http://github.com/hotgazpacho/iron-term-ansicolor Big thanks to Danny Coates for devising a much better way to parse the ANSI control codes!
on 2010-02-27 05:16
on 2010-03-01 07:20
Very cool! So if a user runs Cucumber on IronRuby, does Cucumber give the right error message about having to install iron-term-ansicolor? Cucumber used to say that you had to install win32console. Just checking that iron-term-ansicolor will be easily discoverable. From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Friday, February 26, 2010 8:15 PM To: ironruby-core Subject: [Ironruby-core] iron-term-ansicolor 0.0.2 Released Tonight, I released an update to iron-term-ansicolor, a library for IronRuby that provides console colors for apps like RSpec and Cucumber (Cucumber already makes use of this, and I bet it would not be too much trouble to add to RSpec). http://rubygems.org/gems/iron-term-ansicolor igem install iron-term-ansicolor The source is available on github: http://github.com/hotgazpacho/iron-term-ansicolor Big thanks to Danny Coates for devising a much better way to parse the ANSI control codes! -- Will Green http://hotgazpacho.org/
on 2010-03-01 19:07
Having issues installing this with ironruby rc2. Anyone else seeing
that? I tried running:
ir -S gem install cucumber iron-term-ansicolor
Pasted output:
[20] » ir -v -e 'exit'
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
C:\temp
[21] » ir -S gem install cucumber iron-term-ansicolor
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
(::) U P G R A D I N G (::)
Thank you for installing cucumber-0.6.2.
Please be sure to read
http://wiki.github.com/aslakhellesoy/cucumber/upgrading
for important information about this release. Happy cuking!
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
Successfully installed term-ansicolor-1.0.4
Successfully installed polyglot-0.3.0
Successfully installed treetop-1.4.4
Successfully installed builder-2.1.2
Successfully installed diff-lcs-1.1.2
Successfully installed json_pure-1.2.2
Successfully installed cucumber-0.6.2
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[22] » ir -S gem install iron-term-ansicolor
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[23] »
JD
From: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Very cool!
So if a user runs Cucumber on IronRuby, does Cucumber give the right
error message about having to install iron-term-ansicolor? Cucumber used
to say that you had to install win32console. Just checking that
iron-term-ansicolor will be easily discoverable.
From: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, February 26, 2010 8:15 PM
To: ironruby-core
Subject: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Tonight, I released an update to iron-term-ansicolor, a library for
IronRuby that provides console colors for apps like RSpec and Cucumber
(Cucumber already makes use of this, and I bet it would not be too much
trouble to add to RSpec).
http://rubygems.org/gems/iron-term-ansicolor
igem install iron-term-ansicolor
The source is available on github:
http://github.com/hotgazpacho/iron-term-ansicolor
Big thanks to Danny Coates for devising a much better way to parse the
ANSI control codes!
--
Will Green
http://hotgazpacho.org/
on 2010-03-01 19:36
Yes, Aslak accepted a patch to Cucumber from me many months ago when I released 0.0.1. Right near the top of lib/cucumber/formatter/ansicolor.rb<http://github.com/hotgazpacho/cucumber/commit/abeaf62d2e7c9dd576a27365cdaa29aa6067547c#diff-0> <http://github.com/hotgazpacho/cucumber/commit/abeaf62d2e7c9dd576a27365cdaa29aa6067547c#diff-0> -- Will Green http://hotgazpacho.org/
on 2010-03-01 19:38
I am seeing this error, too :-( I can install locally. Perhaps it is a problem with the Gem sources? C:\Users\will.green\dev\iron-term-ansicolor\pkg>ir -S gem install iron-term-ansicolor-0.0.2.gem Successfully installed iron-term-ansicolor-0.0.2 1 gem installed Installing ri documentation for iron-term-ansicolor-0.0.2... unrecognized option `--format' For help on options, try 'rdoc --help' -- Will Green http://hotgazpacho.org/
on 2010-03-01 19:41
C:\Users\jdeville\projects\cucumber
[35] » ir -S gem sources
*** CURRENT SOURCES ***
http://gemcutter.org
http://gems.rubyforge.org/
http://gems.github.com
That’s what I have for sources, fyi. I’ll try to look into it more later
if no one else does.
JD
From: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Monday, March 01, 2010 10:34 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I am seeing this error, too :-(
I can install locally. Perhaps it is a problem with the Gem sources?
C:\Users\will.green\dev\iron-term-ansicolor\pkg>ir -S gem install
iron-term-ansicolor-0.0.2.gem
Successfully installed iron-term-ansicolor-0.0.2
1 gem installed
Installing ri documentation for iron-term-ansicolor-0.0.2...
unrecognized option `--format'
For help on options, try 'rdoc --help'
--
Will Green
http://hotgazpacho.org/
On Mon, Mar 1, 2010 at 1:04 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
Having issues installing this with ironruby rc2. Anyone else seeing
that? I tried running:
ir -S gem install cucumber iron-term-ansicolor
Pasted output:
[20] » ir -v -e 'exit'
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
C:\temp
[21] » ir -S gem install cucumber iron-term-ansicolor
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
(::) U P G R A D I N G (::)
Thank you for installing cucumber-0.6.2.
Please be sure to read
http://wiki.github.com/aslakhellesoy/cucumber/upgrading
for important information about this release. Happy cuking!
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
Successfully installed term-ansicolor-1.0.4
Successfully installed polyglot-0.3.0
Successfully installed treetop-1.4.4
Successfully installed builder-2.1.2
Successfully installed diff-lcs-1.1.2
Successfully installed json_pure-1.2.2
Successfully installed cucumber-0.6.2
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[22] » ir -S gem install iron-term-ansicolor
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[23] »
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Very cool!
So if a user runs Cucumber on IronRuby, does Cucumber give the right
error message about having to install iron-term-ansicolor? Cucumber used
to say that you had to install win32console. Just checking that
iron-term-ansicolor will be easily discoverable.
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, February 26, 2010 8:15 PM
To: ironruby-core
Subject: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Tonight, I released an update to iron-term-ansicolor, a library for
IronRuby that provides console colors for apps like RSpec and Cucumber
(Cucumber already makes use of this, and I bet it would not be too much
trouble to add to RSpec).
http://rubygems.org/gems/iron-term-ansicolor
igem install iron-term-ansicolor
The source is available on github:
http://github.com/hotgazpacho/iron-term-ansicolor
Big thanks to Danny Coates for devising a much better way to parse the
ANSI control codes!
--
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
on 2010-03-01 19:43
Or, possibly related to version of RubyGems (1.3.5) shipped with
IronRuby
RC2. Latest is 1.3.6
Sadly, I cannot run ir -S gem update --system:
C:\Users\will.green\dev\iron-term-ansicolor>ir -S gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.6
Updating RubyGems to 1.3.6
Installing RubyGems 1.3.6
ERROR: While executing gem ... (Gem::Exception)
[BUG] invalid exec_format "ir", no %s
--
Will Green
http://hotgazpacho.org/
on 2010-03-01 19:45
I also get it when I try to install from a remote location. But downloading the source and building the gem does work. --- 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 2010-03-01 20:06
As a temporary workaround, I've uploaded the gem to the downloads section for the project: http://github.com/hotgazpacho/iron-term-ansicolor/downloads Simply download, then, in the directory you downloaded to: ir -S gem install iron-term-ansicolor-0.0.2.gem <http://github.com/hotgazpacho/iron-term-ansicolor/downloads> -- Will Green http://hotgazpacho.org/ On Mon, Mar 1, 2010 at 1:41 PM, Ivan Porto Carrero <
on 2010-03-01 20:24
Thanks!
From: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Monday, March 01, 2010 10:55 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
As a temporary workaround, I've uploaded the gem to the downloads
section for the project:
http://github.com/hotgazpacho/iron-term-ansicolor/downloads
Simply download, then, in the directory you downloaded to:
ir -S gem install iron-term-ansicolor-0.0.2.gem
--
Will Green
http://hotgazpacho.org/
On Mon, Mar 1, 2010 at 1:41 PM, Ivan Porto Carrero
<ivan@whiterabbitconsulting.eu<mailto:ivan@whiterabbitconsulting.eu>>
wrote:
I also get it when I try to install from a remote location. But
downloading the source and building the gem does work.
---
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 Mon, Mar 1, 2010 at 7:39 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
C:\Users\jdeville\projects\cucumber
[35] » ir -S gem sources
*** CURRENT SOURCES ***
http://gemcutter.org
http://gems.rubyforge.org/
http://gems.github.com
That’s what I have for sources, fyi. I’ll try to look into it more later
if no one else does.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Monday, March 01, 2010 10:34 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I am seeing this error, too :-(
I can install locally. Perhaps it is a problem with the Gem sources?
C:\Users\will.green\dev\iron-term-ansicolor\pkg>ir -S gem install
iron-term-ansicolor-0.0.2.gem
Successfully installed iron-term-ansicolor-0.0.2
1 gem installed
Installing ri documentation for iron-term-ansicolor-0.0.2...
unrecognized option `--format'
For help on options, try 'rdoc --help'
--
Will Green
http://hotgazpacho.org/
On Mon, Mar 1, 2010 at 1:04 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
Having issues installing this with ironruby rc2. Anyone else seeing
that? I tried running:
ir -S gem install cucumber iron-term-ansicolor
Pasted output:
[20] » ir -v -e 'exit'
IronRuby 0.9.4.0 on .NET 2.0.50727.4927
C:\temp
[21] » ir -S gem install cucumber iron-term-ansicolor
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
(::) U P G R A D I N G (::)
Thank you for installing cucumber-0.6.2.
Please be sure to read
http://wiki.github.com/aslakhellesoy/cucumber/upgrading
for important information about this release. Happy cuking!
(::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::) (::)
(::)
Successfully installed term-ansicolor-1.0.4
Successfully installed polyglot-0.3.0
Successfully installed treetop-1.4.4
Successfully installed builder-2.1.2
Successfully installed diff-lcs-1.1.2
Successfully installed json_pure-1.2.2
Successfully installed cucumber-0.6.2
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[22] » ir -S gem install iron-term-ansicolor
ERROR: While executing gem ... (IndexError)
Index was outside the bounds of the array.
C:\temp
[23] »
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Very cool!
So if a user runs Cucumber on IronRuby, does Cucumber give the right
error message about having to install iron-term-ansicolor? Cucumber used
to say that you had to install win32console. Just checking that
iron-term-ansicolor will be easily discoverable.
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, February 26, 2010 8:15 PM
To: ironruby-core
Subject: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
Tonight, I released an update to iron-term-ansicolor, a library for
IronRuby that provides console colors for apps like RSpec and Cucumber
(Cucumber already makes use of this, and I bet it would not be too much
trouble to add to RSpec).
http://rubygems.org/gems/iron-term-ansicolor
igem install iron-term-ansicolor
The source is available on github:
http://github.com/hotgazpacho/iron-term-ansicolor
Big thanks to Danny Coates for devising a much better way to parse the
ANSI control codes!
--
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
on 2010-03-01 22:29
I don't see why not. That said, there has been no testing specifically to verify that. If you clone the git repo, install rake and rspec, and run rake, the default rake task is to run the rspec specifications. -- Will Green http://hotgazpacho.org/
on 2010-03-02 05:48
I think I may have pushed a corrupted gem :-/ Sorry about that folks. Trying to get the bits in place to yank it from gemcutter and replace it with a known good version of the gem. -- Will Green http://hotgazpacho.org/
on 2010-03-02 16:49
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/
on 2010-03-02 19:02
This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (“win32console†in this case), and specify platform==â€ironrubyâ€. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==â€ironrubyâ€, and MRI will use the one with platform==â€mswin32â€. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] 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/
on 2010-03-02 19:10
I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == “ironrubyâ€, (or .net, do we need to differentiate .net and mono?), but accept others. JD From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core@rubyforge.org Subject: [Ironruby-core] IronRuby version of existing gems This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (“win32console†in this case), and specify platform==â€ironrubyâ€. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==â€ironrubyâ€, and MRI will use the one with platform==â€mswin32â€. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] 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/
on 2010-03-02 21:00
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 2010-03-03 18:56
It does seem like there isn’t a way to distinguish between IronRuby and MRI. C:\> ir.exe >>> require "rubygems" => true >>> Gem::Platform.local() => #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60"> JRuby otoh does seem to do something different C:\> jruby.exe irb(main):001:0> require "rubygems" => true irb(main):002:0> Gem::Platform.local() => #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6"> From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. Currently, it reports i386-mswin32. -- Will Green http://hotgazpacho.org/ On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote: I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == “ironrubyâ€, (or .net, do we need to differentiate .net and mono?), but accept others. JD From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: [Ironruby-core] IronRuby version of existing gems This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (“win32console†in this case), and specify platform==â€ironrubyâ€. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==â€ironrubyâ€, and MRI will use the one with platform==â€mswin32â€. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 7:47 AM To: ironruby-core Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first. Please let me know if you still have trouble installing it from Rubygems.org. Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI. -- Will Green http://hotgazpacho.org/ _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-05 01:46
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 = '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"
end
I have updated with
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> 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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-05 16:36
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 Someone should contribute that change to the Ruby Gems project as well. -- Will Green http://hotgazpacho.org/
on 2010-03-05 16:57
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = '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"
end
I have updated with
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> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-05 17:13
I'd have to talk to Luis Lavena, 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 Green http://hotgazpacho.org/
on 2010-03-05 18:01
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 Lavena’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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = '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"
end
I have updated with
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> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-05 19:07
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: http://github.com/luislavena/rake-compiler 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 Green http://hotgazpacho.org/
on 2010-03-06 02:43
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = '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"
end
I have updated with
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> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-06 05:44
See 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 Green http://hotgazpacho.org/
on 2010-03-06 07:59
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.
2) 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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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
on 2010-03-06 08:52
rake-compiler does support fat binaries gem
(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.
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: ironruby-core-bounces@rubyforge.org
[ironruby-core-bounces@rubyforge.org] on behalf of Will Green
[will@hotgazpacho.org]
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = '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"
end
I have updated with
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> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org.
Also, I've submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-06 15:03
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 Green http://hotgazpacho.org/ On Mar 6, 2010, at 1:58 AM, Tomas Matousek
on 2010-03-06 15:12
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 Carrero - Mob: +32.486.787.582 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 2010-03-06 19:31
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto
Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core@rubyforge.org
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 Carrero - Mob: +32.486.787.582
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 Sat, Mar 6, 2010 at 2:50 PM, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:58 AM, Tomas Matousek
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>>
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.
2) 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-07 00:38
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 Green http://hotgazpacho.org/
on 2010-03-07 00:58
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Saturday, March 06, 2010 10:25 AM
To: ironruby-core@rubyforge.org
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto
Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core@rubyforge.org
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 Carrero - Mob: +32.486.787.582
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 Sat, Mar 6, 2010 at 2:50 PM, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:58 AM, Tomas Matousek
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>>
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.
2) 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-07 04:30
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Jim Deville
Sent: Saturday, March 06, 2010 3:53 PM
To: ironruby-core@rubyforge.org
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde
Sent: Saturday, March 06, 2010 10:25 AM
To: ironruby-core@rubyforge.org
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto
Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core@rubyforge.org
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 Carrero - Mob: +32.486.787.582
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 Sat, Mar 6, 2010 at 2:50 PM, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:58 AM, Tomas Matousek
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>>
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.
2) 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-07 04:43
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: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
Sent: Saturday, March 06, 2010 3:36 PM
To: ironruby-core@rubyforge.org
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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:24 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Ivan Porto
Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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 Carrero - Mob: +32.486.787.582
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 Sat, Mar 6, 2010 at 2:50 PM, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:58 AM, Tomas Matousek
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>>
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.
2) 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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<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
on 2010-03-07 06:56
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 Green http://hotgazpacho.org/
on 2010-03-07 07:22
I think you can set the platform to be “universal-.net†and it will work
on all .NET versions.
From: ironruby-core-bounces@rubyforge.org
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green
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 Green
http://hotgazpacho.org/
On Sat, Mar 6, 2010 at 10:33 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Saturday, March 06, 2010 3:36 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:24 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote:
Will, Tomas and I did discuss setting RUBY_PLATFORM to something like
“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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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 Carrero - Mob: +32.486.787.582
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 Sat, Mar 6, 2010 at 2:50 PM, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Green
http://hotgazpacho.org/
On Mar 6, 2010, at 1:58 AM, Tomas Matousek
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>>
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.
2) 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
See 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 Green
http://hotgazpacho.org/
On Mar 5, 2010, at 8:39 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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:
http://github.com/luislavena/rake-compiler
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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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 Lavena’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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I'd have to talk to Luis Lavena, 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 Green
http://hotgazpacho.org/
On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
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
Someone should contribute that change to the Ruby Gems project as well.
--
Will Green
http://hotgazpacho.org/
On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> 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> = 'Shri'
s.version = '1.2.3'
s.summary = "Shri summary"
s.platform = "universal-.net<http://universal-.net>"
s.description = %{Shri description}
s.files = []
s.author = "Shri"
s.email = "shri@email"
s.homepage = "http://shri.org"
end
I have updated with
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> to
"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:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the
RUBY_PLATFORM variable, then IronRuby needs to change what it reports
here. Currently, it reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville
<jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion.
If possible we should prefer platform == “ironrubyâ€, (or .net, do we
need to differentiate .net and mono?), but accept others.
JD
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be
for porting existing gems to IronRuby? There could be two possible
approaches:
1. Create a gem with the same name (“win32console†in this case),
and specify platform==â€ironrubyâ€. That way, dependent gems do not need
to be updated, and users have to remember just one name. IronRuby will
use the version with platform==â€ironrubyâ€, and MRI will use the one with
platform==â€mswin32â€. So there should not be any clashes even if you use
MRI and IronRuby on the same machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in
general?
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem
install locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 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<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<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
on 2010-03-07 08:31
I just pushed both "universal-.net" and "universal-.net-2.0" versions to 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 Green http://hotgazpacho.org/
on 2010-03-07 10:20
On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN
on 2010-03-07 16:03
Thanks, Daniele!
I've got three version of iron-term-ansicolor out there on 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 Green
http://hotgazpacho.org/
on 2010-03-07 23:33
My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-08 03:57
Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-08 04:28
I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like github and rubyforge). Does gem attempt all sources to find the most specific? Or does it go with the most specific gem from the first source? JD From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-10 23:14
Glad that we were able to figure out the issue! The fix did make it into
RC3 as well!
It would be great if you could coordinate getting the fix into the
RubyGem sources!
From: Will Green [mailto:will@hotgazpacho.org]
Sent: Tuesday, March 09, 2010 6:49 PM
To: Shri Borde
Subject: Re: [Ironruby-core] IronRuby version of existing gems
Excellent! I just pulled the changes and confirm that I can now install
directly from RubyGems.org.
Would you like me to coordinate getting the change to RubyGems into the
source? I know at least two of the comitters listed on the RubyForge
project page: http://rubyforge.org/scm/?group_id=126
Let me know!
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 9, 2010 at 1:30 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote:
The =~ method needs to be fixed, but fixing that does not help since it
gets called with an argument of “universal-unknownâ€.
I did find a workaround. If I add the following in
Gem::Specification._load around line 308 in
Merlin\External.LCA_RESTRICTED\Languages\Ruby\redist-libs\ruby\site_ruby\1.8\rubygems\specification.rb,
I am able to install iron-term-ansicolor-0.0.4-universal-.net.
if array[8] == "universal-.net"
array[16] = Gem::Platform.new(["universal", ".net"]) if array[16]
== Gem::Platform.new(["universal", "unknown"])
end
Will try to get it into RTM (not sure if it will make it into RC3)
From: Will Green
[mailto:will@hotgazpacho.org<mailto:will@hotgazpacho.org>]
Sent: Tuesday, March 09, 2010 4:38 AM
To: Shri Borde
Subject: Re: [Ironruby-core] IronRuby version of existing gems
The thing is, this works with RC2:
igem install iron-term-ansicolor --platform universal-.net
C:\ironruby\bin>igem install iron-term-ansicolor --platform
universal-.net
Successfully installed iron-term-ansicolor-0.0.4-universal-unknown
1 gem installed
Installing ri documentation for
iron-term-ansicolor-0.0.4-universal-unknown...
Installing RDoc documentation for
iron-term-ansicolor-0.0.4-universal-unknown...
Sure, it recognizes it as universal-unknown, but it still works.
It doesn't work at all with HEAD. I think you missed a spot with the
platform detection in
Merlin/External.LCA_RESTRICTED/Languages/Ruby/redist-libs/ruby/site_ruby/1.8/rubygems/platform.rb
Specifically, the =~ method, which I think gets called because in the
gem spec, the platform is serialized as a string. Just a hunch, but it
couldn't hurt to investigate.
What do you think?
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 9, 2010 at 2:27 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote:
I can see the new gem with “gem query†but “gem install†will not
install it.
d:\ >gem query -d -r -n iron-term-ansicolor
*** REMOTE GEMS ***
iron-term-ansicolor (0.0.4)
Platform: universal-.net
Authors: Will Green, David Blackmon, Ivan Porto Carrero, Danny
Coates
Homepage: http://github.com/hotgazpacho/iron-term-ansicolor
iron-term-ansicolor brings color output to IronRuby on Windows
d:\ >gem install iron-term-ansicolor --no-rdoc --no-ri
ERROR: could not find gem iron-term-ansicolor locally or in a
repository
d:\ >ir.exe -S gem install iron-term-ansicolor --no-rdoc --no-ri
ERROR: could not find gem iron-term-ansicolor locally or in a
repository
It does seem to be the issue I mentioned about the remote gem server,
because adding logging in Gem::Specification._load shows that @platform
and @new_platform are “universal-unknown†when trying to install from a
remote server. When you install locally, marshalling is not an issue.
However, when you install from a remote server, the remote server is
going to have to send information to the client about matching gems, and
this information must be in marshaled data format.
What this means is that setting platform to “universal-.net†will not
work until a patch is made to RubyGems in platform.rb (like has already
been done for JRuby). The workaround will be to set the platform to
“ruby†for now, or to create two gems with platforms set to
“universal-.net2.0†and “universal-.net4.0â€. Do you want to push updates
with platforms set to “universal-.net2.0†and “universal-.net4.0�
Thanks for helping to figure out how all this works or should work!!
From: Will Green
[mailto:will@hotgazpacho.org<mailto:will@hotgazpacho.org>]
Sent: Monday, March 08, 2010 8:17 PM
To: Shri Borde
Subject: Re: [Ironruby-core] IronRuby version of existing gems
I've made the change you suggested. Here's the gemspec that IronRuby
sees and that MRI sees: (igem spec
iron-term-ansicolor-0.0.4-universal-.net.gem and gem spec
iron-term-ansicolor-0.0.4-universal-.net.gem)
http://gist.github.com/326161
Both see platform: universal-.net
Which is great, because I think that means the gemspec is just YAML, so
marshaling is really not an issue.
I am able to successfully install locally, too. So, I'm going to bump
the patch level, commit my changes, push to github, and publish the gem.
Thanks for your help!
--
Will Green
http://hotgazpacho.org/
On Mon, Mar 8, 2010 at 1:17 PM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote:
When I search for “unknown†in the Ruby Gem sources, the only relevant
occurrence is in
Merlin\External.LCA_RESTRICTED\Languages\Ruby\redist-libs\ruby\site_ruby\1.8\rubygems\package.rb,
which I did fix.
Something just occurred to me. Creating the gem just zips up all the
files together, and does not seem to marshal any data-structures,
whereas I am seeing that the marshaled representation of
Gem::Specification contains
@original_platform=@new_platform=â€universal-unknownâ€. So I wonder if the
gem server on rubyforge marshals the contents of the gem. It might need
to do this so that it can cache the results efficiently. Assuming it
does do this, the gem server will be running MRI and will not have the
fix to rubygem\package.rb, and so will generate the corrupt value of
â€universal-unknownâ€.
One possible workaround is to do this:
s.platform = Gem::Platform.new(["universal", ".net"])
By using an array of size 2 as the argument, MRI will be able to parse
the platform into the CPU and OS components, even without my fix to
rubygems\package.rb. Could you please create a gem as such, make sure it
works as expected locally, and then push it? I did apply this fix to
Rakefile, and “ir.exe –S rake package†was able to create the gem.
From: Will Green
[mailto:will@hotgazpacho.org<mailto:will@hotgazpacho.org>]
Sent: Monday, March 08, 2010 3:44 AM
To: Shri Borde
Subject: Re: [Ironruby-core] IronRuby version of existing gems
Yes, I can install the universal-.net<http://universal-.net> gem
locally, when I create it from my git repo.
I can certainly recreate and repush that gem. Maybe I can do a version
bump to 0.0.4 and push only the universal-.net<http://universal-.net>
gem for now.
I'd also look at the change to Ruby Gems again. I seem to recall there
being more than one place in that file where it did platform name
mangling. But I may be mistaken.
Thanks for looking into this, and keep up the good work!
--
Will Green
http://hotgazpacho.org/
On Mar 8, 2010, at 2:42 AM, Shri Borde
<Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote:
I did “ir.exe –S rake package†from your GIT repo, followed by “ir.exe
–S gem install pkg\iron-term-ansicolor-0.0.3-universal-.net.gemâ€, and it
seems to do the right thing. Does that work for you?
This is the repro I am using to drill into the issue. With no changes to
rbconfig.rb, I added the highlighted line to
Merlin\External.LCA_RESTRICTED\Languages\Ruby\redist-libs\ruby\site_ruby\1.8\rubygems\specification.rb
at line 328 in the _load function:
spec.instance_variable_set :@new_platform, array[16]
spec.instance_variable_set :@platform,
array[16].to_s
spec.instance_variable_set :@license, array[17]
spec.instance_variable_set :@loaded, false
puts "ori=#{spec.instance_variable_get(:@original_platform)}
new=#{spec.instance_variable_get(:@new_platform)}
p=#{spec.instance_variable_get(:@platform)}"
spec
I ran the command shown below, and the platform is printed incorrectly.
This data comes from the serialized string representation in the gem,
and so it seems like the gem is corrupt
ir.exe -S gem install iron-term-ansicolor --platformuniversal-.net-4.0
--no-rdoc --no-ri
ori=universal-.net new=universal-unknown p=universal-unknown
ori=ruby new=ruby p=ruby
ori=ruby new=ruby p=ruby
Successfully installed iron-term-ansicolor-0.0.3
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Sunday, March 07, 2010 6:53 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
Will, could you recreate the universal-.net<http://universal-.net> gem
again and push it? I think it might have been created incorrectly. The
persisted Gem::Specification has @new_platform and @original_platform
set to “universal-unknown†which might happen if you create it with MRI
as I had mentioned below…
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Shri Borde
Sent: Sunday, March 07, 2010 2:27 PM
To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
My guess is that RubyGems tries to look for an exact platform match
first. If there is no exact match, it somehow prefers “ruby†over other
platforms.
Btw, you could just change clr_version in
Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running
on .NET 4. After doing this and using the “—platform
universal-.net<http://universal-.net>†option,
iron-term-ansicolor-0.0.3-universal-.net<http://iron-term-ansicolor-0.0.3-universal-.net>-2.0
was installed which was surprising to me as I would have expected it to
install
iron-term-ansicolor-0.0.3-universal-.net<http://iron-term-ansicolor-0.0.3-universal-.net>.
When I used the “—platform universal-.net-4.0†option,
iron-term-ansicolor-0.0.3 was installed which was also surprising. So
there does not seem to be any way to install
iron-term-ansicolor-0.0.3-universal-.net<http://iron-term-ansicolor-0.0.3-universal-.net>.
From:
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>]
On Behalf Of Will Green
Sent: Sunday, March 07, 2010 6:33 AM
To: ironruby-core
Subject: Re: [Ironruby-core] IronRuby version of existing gems
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<http://iron-term-ansicolor-0.0.3-universal-.net>
(gemspec.platform="universal-.net<http://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 Green
http://hotgazpacho.org/
On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri
<suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote:
On Sun, Mar 7, 2010 at 08:07, Will Green
<will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri
http://www.clorophilla.net/
http://twitter.com/JoL1hAHN
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-11 04:41
Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 <http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577>As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet" "gemname-universal-dotnet-2.0" "gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention? -- Will Green http://hotgazpacho.org/
on 2010-03-11 05:57
Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source. -- Will Green http://hotgazpacho.org/
on 2010-03-11 16:46
The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Wednesday, March 10, 2010 8:57 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source. -- Will Green http://hotgazpacho.org/ On Wed, Mar 10, 2010 at 10:33 PM, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote: Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet" "gemname-universal-dotnet-2.0" "gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention? -- Will Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote: I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like github and rubyforge). Does gem attempt all sources to find the most specific? Or does it go with the most specific gem from the first source? JD From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ 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
on 2010-03-11 16:53
Yes, but those of us on case-sensitive operating systems prefer all lower case, if possible. Cory Sent from my Verizon Wireless BlackBerry
on 2010-03-11 17:46
Then why is RbConfig['arch'] "universal-.net2.0" and not "universal-.NET2.0"? -- Will Green http://hotgazpacho.org/
on 2010-03-11 18:26
Wouldn’t “clr†be better after all? Tomas From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Then why is RbConfig['arch'] "universal-.net2.0" and not "universal-.NET2.0"? -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 10:45 AM, Shri Borde <Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote: The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Wednesday, March 10, 2010 8:57 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source. -- Will Green http://hotgazpacho.org/ On Wed, Mar 10, 2010 at 10:33 PM, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote: Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet" "gemname-universal-dotnet-2.0" "gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention? -- Will Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote: I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like github and rubyforge). Does gem attempt all sources to find the most specific? Or does it go with the most specific gem from the first source? JD From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ 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
on 2010-03-11 18:40
I’d also like to echo and +1 the *nix users vote for keeping things lowercase. JD From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Tomas Matousek Sent: Thursday, March 11, 2010 9:11 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Wouldn’t “clr†be better after all? Tomas From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Then why is RbConfig['arch'] "universal-.net2.0" and not "universal-.NET2.0"? -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 10:45 AM, Shri Borde <Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote: The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Wednesday, March 10, 2010 8:57 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source. -- Will Green http://hotgazpacho.org/ On Wed, Mar 10, 2010 at 10:33 PM, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote: Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet" "gemname-universal-dotnet-2.0" "gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention? -- Will Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote: I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like github and rubyforge). Does gem attempt all sources to find the most specific? Or does it go with the most specific gem from the first source? JD From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ 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
on 2010-03-11 18:43
Thinking about it, lower-case “dotnet†sounds fine. Since we don’t know how the value will be used, its better to be conservative and follow existing naming patterns (lower case letters) Any votes for “clrâ€? Else, I will change RbConfig::CONFIG[“archâ€] to “universal-dotnet2.0†/“universal-dotnet4.0†From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Tomas Matousek Sent: Thursday, March 11, 2010 9:11 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Wouldn’t “clr†be better after all? Tomas From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Then why is RbConfig['arch'] "universal-.net2.0" and not "universal-.NET2.0"? -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 10:45 AM, Shri Borde <Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote: The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Wednesday, March 10, 2010 8:57 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source. -- Will Green http://hotgazpacho.org/ On Wed, Mar 10, 2010 at 10:33 PM, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> wrote: Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet" "gemname-universal-dotnet-2.0" "gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention? -- Will Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville@microsoft.com<mailto:jdeville@microsoft.com>> wrote: I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like github and rubyforge). Does gem attempt all sources to find the most specific? Or does it go with the most specific gem from the first source? JD From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems Will, could you recreate the universal-.net gem again and push it? I think it might have been created incorrectly. The persisted Gem::Specification has @new_platform and @original_platform set to “universal-unknown†which might happen if you create it with MRI as I had mentioned below… From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems My guess is that RubyGems tries to look for an exact platform match first. If there is no exact match, it somehow prefers “ruby†over other platforms. Btw, you could just change clr_version in Merlin\Main\Languages\Ruby\Libs\rbconfig.rb to “4.0†to simulate running on .NET 4. After doing this and using the “—platform universal-.net†option, iron-term-ansicolor-0.0.3-universal-.net-2.0 was installed which was surprising to me as I would have expected it to install iron-term-ansicolor-0.0.3-universal-.net. When I used the “—platform universal-.net-4.0†option, iron-term-ansicolor-0.0.3 was installed which was also surprising. So there does not seem to be any way to install iron-term-ansicolor-0.0.3-universal-.net. From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] On Behalf Of Will Green Sent: Sunday, March 07, 2010 6:33 AM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Thanks, Daniele! I've got three version of iron-term-ansicolor out there on 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 Green http://hotgazpacho.org/ On Sun, Mar 7, 2010 at 4:01 AM, Daniele Alessandri <suppakilla@gmail.com<mailto:suppakilla@gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will@hotgazpacho.org<mailto:will@hotgazpacho.org>> 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 Alessandri http://www.clorophilla.net/ http://twitter.com/JoL1hAHN _______________________________________________ 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
on 2010-03-11 18:44
Probably, as it would cover both .NET and Mono. If you look at the JRuby stuff in Ruby Gems, the gems are either "java" or "jruby". We could do "dotnet" and "ironruby", and even "clr", but I think we should standardize on one. My vote is for "dotnet". On Thursday, March 11, 2010, Tomas Matousek <Tomas.Matousek@microsoft.com> wrote: > Subject: Re: [Ironruby-core] IronRuby version of existing gems Attached is a new patch I would propose to address the feedback from the Ruby Gems team. I would love some feedback on it. It is a patch against rev 2463 of trunk of Ruby Gems source.-- > Will Green > http://hotgazpacho.org/On Wed, Mar 10, 2010 at 10:33 PM, Will Green <will@hotgazpacho.org> wrote:Based on some work that Shri and I did to figure this out, I have created and submitted a patch to Ruby Gems to include support form .Net native gems: http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577 As you can see, I've gotten some push-back from the Ruby Gems team on the naming of the platform for the gems. The problem is that they don't like the "." in ".net" (i.e. "universal-.net-2.0"), and have suggested alternatives such as "dotnet", "dotNet", and "Net". I have asked for clarification on their position. If I understand the Gem::Platform class correctly, the initialize method takes in the values read from RbConfig, and performs some translation to come up with a Gem platform name. So, without any changes to IronRuby itself, we could have gems with names like "iron-term-ansicolor-universal-dotnet". Of course, it would require a small tweak to the version of Ruby Gems that is distributed with IronRuby, but the change is very minor. So, does anyone object to .Net native gems like: "gemname-universal-dotnet""gemname-universal-dotnet-2.0""gemname-universal-dotnet-4.0" I think this would get the patch accepted more quickly. Is this kosher with LCA, or even something that needs to be brought to their attention?-- > Will Green > http://hotgazpacho.org/On Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville@microsoft.com> wrote:I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like g -- -- Will Green http://hotgazpacho.org/
on 2010-03-11 19:25
There's pretty strong use of "dotnet" in other open source projects, and I think that would be best in case gems ever need to decide between dotnet and mono (which is rare, but could happen). Cory Sent from my Verizon Wireless BlackBerry
on 2010-03-12 10:49
+1 for lowercase --- 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 2010-03-12 14:10
>> The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would
read better than just "gemname-universal-dotnet".
dotNET looks awful. Microsoft are well known for terrible marketing and
terrible naming, so I'd argue that "use the correct spelling" is an
anti-feature :-)
Personally, I like Tomas' suggestion of clr
gemname-universal-clr2.0 looks very nice :-)
on 2010-03-12 15:24
I don't care either way as long as it's lower-case On Thursday, March 11, 2010, Orion Edwards <orion.edwards@gmail.com> wrote: >>> The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". > > > dotNET looks awful. Microsoft are well known for terrible marketing and terrible naming, so I'd argue that "use the correct spelling" is an anti-feature :-) > > > Personally, I like Tomas' suggestion of clr > gemname-universal-clr2.0 looks very nice :-) > > -- --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero - Mob: +32.486.787.582 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 2010-03-12 21:24
Updated my patch to Ruby Gems to match on "universal-dotnetX.X", where X.X is the version number. This will allow for the creation of .NET-specific gems with names like: - gemname-dotnet - gemname-dotnet-2.0 - gemname-dotnet-4.0 - gemname-universal-dotnet - gemname-universal-dotnet-2.0 - gemname-universal-dotnet-4.0 If there are no objections, I'll resubmit to Ruby Gems. -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 4:19 PM, Ivan Porto Carrero <
on 2010-03-12 23:11
Sounds great. Thanks for pushing on this! From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 7:19 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Updated my patch to Ruby Gems to match on "universal-dotnetX.X", where X.X is the version number. This will allow for the creation of .NET-specific gems with names like: - gemname-dotnet - gemname-dotnet-2.0 - gemname-dotnet-4.0 - gemname-universal-dotnet - gemname-universal-dotnet-2.0 - gemname-universal-dotnet-4.0 If there are no objections, I'll resubmit to Ruby Gems. -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 4:19 PM, Ivan Porto Carrero <ivan@whiterabbitconsulting.eu<mailto:ivan@whiterabbitconsulting.eu>> wrote: I don't care either way as long as it's lower-case On Thursday, March 11, 2010, Orion Edwards <orion.edwards@gmail.com<mailto:orion.edwards@gmail.com>> wrote: >>> The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". > > > dotNET looks awful. Microsoft are well known for terrible marketing and terrible naming, so I'd argue that "use the correct spelling" is an anti-feature :-) > > > Personally, I like Tomas' suggestion of clr > gemname-universal-clr2.0 looks very nice :-) > > -- --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero - Mob: +32.486.787.582 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 _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org<mailto:Ironruby-core@rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core
on 2010-03-19 12:01
FYI, my patch to Ruby Gems was accepted yesterday. Hopefully, we'll see a release that includes it (and rubygems.org using it) at or about the time IronRuby 1.0 goes RTW. -- Will Green http://hotgazpacho.org/ On Mar 12, 2010, at 12:57 PM, Shri Borde <Shri.Borde@microsoft.com>
on 2010-03-19 17:57
Thanks a lot for pushing on this! From: ironruby-core-bounces@rubyforge.org [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Friday, March 19, 2010 3:45 AM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems FYI, my patch to Ruby Gems was accepted yesterday. Hopefully, we'll see a release that includes it (and rubygems.org<http://rubygems.org> using it) at or about the time IronRuby 1.0 goes RTW. -- Will Green http://hotgazpacho.org/ On Mar 12, 2010, at 12:57 PM, Shri Borde <Shri.Borde@microsoft.com<mailto:Shri.Borde@microsoft.com>> wrote: Sounds great. Thanks for pushing on this! From: ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> [mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 7:19 PM To: ironruby-core Subject: Re: [Ironruby-core] IronRuby version of existing gems Updated my patch to Ruby Gems to match on "universal-dotnetX.X", where X.X is the version number. This will allow for the creation of .NET-specific gems with names like: - gemname-dotnet - gemname-dotnet-2.0 - gemname-dotnet-4.0 - gemname-universal-dotnet - gemname-universal-dotnet-2.0 - gemname-universal-dotnet-4.0 If there are no objections, I'll resubmit to Ruby Gems. -- Will Green http://hotgazpacho.org/ On Thu, Mar 11, 2010 at 4:19 PM, Ivan Porto Carrero <ivan@whiterabbitconsulting.eu<mailto:ivan@whiterabbitconsulting.eu>> wrote: I don't care either way as long as it's lower-case On Thursday, March 11, 2010, Orion Edwards <orion.edwards@gmail.com<mailto:orion.edwards@gmail.com>> wrote: >>> The name is spelled as “.NETâ€, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". > > > dotNET looks awful. Microsoft are well known for terrible marketing and terrible naming, so I'd argue that "use the correct spelling" is an anti-feature :-) > > > Personally, I like Tomas' suggestion of clr > gemname-universal-clr2.0 looks very nice :-) > > -- --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero - Mob: +32.486.787.582 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 _______________________________________________ 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
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.