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! -- Will Green http://hotgazpacho.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100226/8fdb8a19/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/a6164172/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/f22e4f08/attachment-0001.html>
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 Mon, Mar 1, 2010 at 1:19 AM, Shri Borde <Shri.Borde at microsoft.com> wrote:> 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/de253250/attachment.html>
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, February 28, 2010 10:20 PM > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/bc7adc6b/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Monday, March 01, 2010 10:34 AM
To: ironruby-core at 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 at
microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/8bd9a6e3/attachment-0001.html>
Ivan Porto Carrero
2010-Mar-01 18:41 UTC
[Ironruby-core] iron-term-ansicolor 0.0.2 Released
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Monday, March 01, 2010 10:34 AM > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, February 28, 2010 10:20 PM > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/bf822239/attachment.html>
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 Mon, Mar 1, 2010 at 1:33 PM, Will Green <will at hotgazpacho.org>
wrote:
> 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 at
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 at rubyforge.org [mailto:
>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde
>> *Sent:* Sunday, February 28, 2010 10:20 PM
>> *To:* ironruby-core at 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 at rubyforge.org [mailto:
>> ironruby-core-bounces at 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/917e8bbe/attachment-0001.html>
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 < ivan at 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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green >> *Sent:* Monday, March 01, 2010 10:34 AM >> >> *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Sunday, February 28, 2010 10:20 PM >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/f829dbda/attachment.html>
Thanks!
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Monday, March 01, 2010 10:55 AM
To: ironruby-core at 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 at
whiterabbitconsulting.eu<mailto:ivan at 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 at
microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Monday, March 01, 2010 10:34 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Sunday, February 28, 2010 10:20 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/8e978933/attachment-0001.html>
Can this gem be used with IronRuby rc 1. -- Posted via http://www.ruby-forum.com/.
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 Mon, Mar 1, 2010 at 3:49 PM, Mohammad Azam <lists at ruby-forum.com> wrote:> Can this gem be used with IronRuby rc 1. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/2e2538a9/attachment.html>
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 Mon, Mar 1, 2010 at 1:33 PM, Will Green <will at hotgazpacho.org> wrote:> 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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Sunday, February 28, 2010 10:20 PM >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100301/5d89f3e7/attachment.html>
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 Mon, Mar 1, 2010 at 11:45 PM, Will Green <will at hotgazpacho.org> wrote:> 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 Mon, Mar 1, 2010 at 1:33 PM, Will Green <will at hotgazpacho.org> wrote: > >> 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 at 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 at rubyforge.org [mailto: >>> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >>> *Sent:* Sunday, February 28, 2010 10:20 PM >>> *To:* ironruby-core at 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 at rubyforge.org [mailto: >>> ironruby-core-bounces at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100302/94f40f92/attachment-0001.html>
This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (?win32console? in this case), and specify platform==?ironruby?. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 7:47 AM To: ironruby-core Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first. Please let me know if you still have trouble installing it from Rubygems.org. Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI. -- Will Green http://hotgazpacho.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100302/3219cbc8/attachment.html>
I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == ?ironruby?, (or .net, do we need to differentiate .net and mono?), but accept others. JD From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] IronRuby version of existing gems This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (?win32console? in this case), and specify platform==?ironruby?. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 7:47 AM To: ironruby-core Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first. Please let me know if you still have trouble installing it from Rubygems.org. Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI. -- Will Green http://hotgazpacho.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100302/4ad7dcc7/attachment-0001.html>
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. Currently, it reports i386-mswin32. -- Will Green http://hotgazpacho.org/ On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> wrote:> I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > > > JD > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100302/19dfe7be/attachment.html>
It does seem like there isn?t a way to distinguish between IronRuby and MRI. C:\> ir.exe>>> require "rubygems"=> true>>> Gem::Platform.local()=> #<Gem::Platform:0x1409 @cpu="x86", @os="mswin32", @version="60"> JRuby otoh does seem to do something different C:\> jruby.exe irb(main):001:0> require "rubygems" => true irb(main):002:0> Gem::Platform.local() => #<Gem::Platform:0xf0 @cpu="universal", @os="java", @version="1.6"> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 11:52 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. Currently, it reports i386-mswin32. -- Will Green http://hotgazpacho.org/ On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com<mailto:jdeville at microsoft.com>> wrote: I believe JRuby is doing the 1st one, which makes sense in my opinion. If possible we should prefer platform == ?ironruby?, (or .net, do we need to differentiate .net and mono?), but accept others. JD From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Tuesday, March 02, 2010 10:02 AM To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> Subject: [Ironruby-core] IronRuby version of existing gems This brings a question to mind - what should the general approach be for porting existing gems to IronRuby? There could be two possible approaches: 1. Create a gem with the same name (?win32console? in this case), and specify platform==?ironruby?. That way, dependent gems do not need to be updated, and users have to remember just one name. IronRuby will use the version with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So there should not be any clashes even if you use MRI and IronRuby on the same machine. 2. Create a new gem like iron-term-ansicolor. Any pro or cons to the two? What should the recommendation be in general? From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: Tuesday, March 02, 2010 7:47 AM To: ironruby-core Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released I released iron-term-ansicolor 0.0.3 last night after testing the gem install locally first. Please let me know if you still have trouble installing it from Rubygems.org. Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, the same way it tries to use win32console under MRI. -- Will Green http://hotgazpacho.org/ _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100303/273ee195/attachment.html>
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 at 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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/bd7370c9/attachment-0001.html>
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 at 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 = ''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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > *To:* ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/36d80947/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/f9cfdf96/attachment-0001.html>
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 7:08 AM > > *To:* ironruby-core at 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 at 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 = ''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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > > *To:* ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/3315fcf6/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/61f785c5/attachment-0001.html>
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:11 AM > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 7:08 AM > > > *To:* ironruby-core at 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 at 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 = ''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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > > *To:* ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/2c67af3a/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/2f80f7f9/attachment-0001.html>
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 at 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 9:46 AM > To: ironruby-core at 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 at 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 ha > ve to modify Luis Lavena?s code, right? And people installing win32c > onsole 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 8:11 AM > > > To: ironruby-core at 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 at microsoft.com> wrote: > > We should push the change once the dust settles down. Let?s wait unt > il the RTM to make sure that this all actually works as we would lik > e 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 7:08 AM > > > To: ironruby-core at 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 at 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 = ''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 at 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 > 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 11:52 AM > > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it > reports here. Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my > opinion. If possible we should prefer platform == ?ironruby?, > (or .net, do we need to differentiate .net and mono?), but accept ot > hers. > > JD > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Shri Borde > Sent: Tuesday, March 02, 2010 10:02 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach > be for porting existing gems to IronRuby? There could be two > possible approaches: > > 1. Create a gem with the same name (?win32console? in this > case), and specify platform==?ironruby?. That way, dependent gems > do not need to be updated, and users have to remember just one name. > IronRuby will use the version with platform==?ironruby?, and MRI > will use the one with platform==?mswin32?. So there should not be > any clashes even if you use MRI and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in > general? > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 7:47 AM > To: ironruby-core > Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the > gem install locally first. > > > > Please let me know if you still have trouble installing it from Rubygems.org > . > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if > it can, the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100305/c83590f8/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/fd1062f3/attachment-0001.html>
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 at rubyforge.org [ironruby-core-bounces at
rubyforge.org] on behalf of Will Green [will at hotgazpacho.org]
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from Rubygems.org.
Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it
can, the same way it tries to use win32console under MRI.
--
Will Green
http://hotgazpacho.org/
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/ae5d6f0d/attachment-0001.html>
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 at 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 assemb > ly for IronRuby. Any subsystem that builds/uses ?native? > extensions needs to use this variable. A particular VM can support m > ultiple 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 p > latforms. > > > > Is that correct? > > Tomas > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 8:18 PM > To: ironruby-core at 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 at 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 9:46 AM > To: ironruby-core at 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 at 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 ha > ve to modify Luis Lavena?s code, right? And people installing win32c > onsole 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 8:11 AM > > > To: ironruby-core at 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 at microsoft.com> wrote: > > We should push the change once the dust settles down. Let?s wait unt > il the RTM to make sure that this all actually works as we would lik > e 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 7:08 AM > > > To: ironruby-core at 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 at 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 = ''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 at 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 > 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 11:52 AM > > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it > reports here. Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my > opinion. If possible we should prefer platform == ?ironruby?, > (or .net, do we need to differentiate .net and mono?), but accept ot > hers. > > JD > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Shri Borde > Sent: Tuesday, March 02, 2010 10:02 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach > be for porting existing gems to IronRuby? There could be two > possible approaches: > > 1. Create a gem with the same name (?win32console? in this > case), and specify platform==?ironruby?. That way, dependent gems > do not need to be updated, and users have to remember just one name. > IronRuby will use the version with platform==?ironruby?, and MRI > will use the one with platform==?mswin32?. So there should not be > any clashes even if you use MRI and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in > general? > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 7:47 AM > To: ironruby-core > Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the > gem install locally first. > > > > Please let me know if you still have trouble installing it from Rubygems.org > . > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if > it can, the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/6b06c11b/attachment-0001.html>
Ivan Porto Carrero
2010-Mar-06 14:11 UTC
[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 at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:18 PM > *To:* <ironruby-core at rubyforge.org>ironruby-core at rubyforge.org > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > See <http://docs.rubygems.org/read/chapter/20#platform> > http://docs.rubygems.org/read/chapter/20#platform > > > > Basically, most gems contain pure Ruby code. Some gems contain C (or Java, > or now possibly C#) code that gets compiled at gem install time. Some gems > even include pre-compiled code. You will find that the overwhelming majority > of these gems target the mswin32 platform (which is based on the VC6 > runtime). > > > > The reason that binary gems are distributed is that, unlike on most > Linux/UNIX/BSD based systems, Windows does not come with a C compiler, let > alone the specific version used to create mswin32 Ruby, MSVC 6. So, users of > the mswin32 Ruby relied on those who had a license to MSVC 6 to provide > binaries of the gems they needed. This is a major reason why development of > the mswin32 Ruby has ceased... Very few people have MSVC6, it''s old and > slow, and those who want MSVC6 (so they can contribute to mswin32 Ruby) > can''t get it anymore. This is why the mingw32 version of Ruby is the > actively maintained version of C Ruby on Windows: no worries about mingw > licensing and distribution, and it''s freely available. > > > > This is the reason why it is important that IronRuby report the correct > architecture and runtime environment. As I said before, Gems that target > mswin32 will not run on IronRuby, because the thing that makes them mswin32 > is that they include C extensions that can be, or are, compiled to native, > unmanaged code targetting the MSVC6 runtime. So, it is important that > IronRuby not identify itself as mswin32, because the gems that target that > platform won''t work on IronRuby anyway. > > > > What Luis has done with Rake Compiler is allow the gem author to create > extensions in C and Java, and permit them to compile platform specific > versions of the same gem. I''m sure that he would welcome contributions that > would allow us to write extensions in C# and build gems that target IronRuby > as a platform, all while keeping the same gem name. That is, > win32console-mswin32.gem and win32console-mingw32.gem come from the same > source gem, but they are compiled against different runtimes, and target > different platforms. With IronRuby identifying itself correctly, and some > additions to rake-compiler to generate .Net assemblies, it may be possible > to generate a win32console-.net20.gem. Even then, we''d need to provide > patches to libraries that use a regex against RUBY_PLATFORM to determine if > we''re running on Windows. But then, what if you''re running IronRuby on Mono > on Linux, where any of the win32xxx gems make no sense? > > > > My point is that I don''t see a way to just inject IronRuby-specific > libraries in place of the mswin32 ones without causing all sorts of > headaches with platform juggling. IronRuby is not always on Windows, and > thus should not identify itself as running on Windows, and certainly should > not identify itself as the MSVC6 version or Ruby. > > > -- > > Will Green > > <http://hotgazpacho.org/>http://hotgazpacho.org/ > > > > > > > On Mar 5, 2010, at 8:39 PM, Shri Borde < <Shri.Borde at microsoft.com> > Shri.Borde at 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 at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 9:46 AM > *To:* <ironruby-core at rubyforge.org>ironruby-core at 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> > 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/>http://hotgazpacho.org/ > > > On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde < <Shri.Borde at microsoft.com> > Shri.Borde at 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 at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:11 AM > > > *To:* <ironruby-core at rubyforge.org>ironruby-core at 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/>http://hotgazpacho.org/ > > On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde < <Shri.Borde at microsoft.com> > Shri.Borde at 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 at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 7:08 AM > > > *To:* <ironruby-core at rubyforge.org>ironruby-core at 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> > 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/>http://hotgazpacho.org/ > > On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde < <Shri.Borde at microsoft.com> > Shri.Borde at 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| > > <http://s.name>s.name = ''Shri'' > > s.version = ''1.2.3'' > > s.summary = "Shri summary" > > s.platform = " <http://universal-.net>universal-.net" > > s.description = %{Shri description} > > s.files = [] > > s.author = "Shri" > > s.email = "shri at email" > > s.homepage = " <http://shri.org>http://shri.org" > > end > > > > I have updated with > <http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems> > http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems with > this info: > > *IronRuby-specific gems * > > Gems could specifically target IronRuby. They may contain Ruby code which > uses .NET APIs, or they may even include compiled .NET assemblies. In such > cases, the Gem specification should set platform > <http://rubygems.org/read/chapter/20#platform>to "*<http://universal-.net> > 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 at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > > *To:* <ironruby-core at rubyforge.org>ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > <http://hotgazpacho.org/>http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville < <jdeville at microsoft.com> > jdeville at microsoft.com> wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* <ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* <ironruby-core at rubyforge.org>ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* <ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org [mailto:<ironruby-core-bounces at rubyforge.org> > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > <http://Rubygems.org>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/>http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org > <http://rubyforge.org/mailman/listinfo/ironruby-core> > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org > <http://rubyforge.org/mailman/listinfo/ironruby-core> > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org > <http://rubyforge.org/mailman/listinfo/ironruby-core> > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org > <http://rubyforge.org/mailman/listinfo/ironruby-core> > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > <Ironruby-core at rubyforge.org>Ironruby-core at rubyforge.org > <http://rubyforge.org/mailman/listinfo/ironruby-core> > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/7f3f3a43/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:Tomas.Matousek at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/9fea52c6/attachment-0001.html>
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 at 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 cas > es 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero > Sent: Saturday, March 06, 2010 6:12 AM > To: ironruby-core at 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 at 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 at 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 assemb > ly for IronRuby. Any subsystem that builds/uses ?native? > extensions needs to use this variable. A particular VM can support m > ultiple 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 p > latforms. > > > > Is that correct? > > Tomas > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 8:18 PM > To: ironruby-core at 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 at 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 9:46 AM > To: ironruby-core at 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 at 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 ha > ve to modify Luis Lavena?s code, right? And people installing win32c > onsole 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 8:11 AM > > > To: ironruby-core at 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 at microsoft.com> wrote: > > We should push the change once the dust settles down. Let?s wait unt > il the RTM to make sure that this all actually works as we would lik > e 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Friday, March 05, 2010 7:08 AM > > > To: ironruby-core at 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 at 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 = ''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 at 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 > 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 at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 11:52 AM > > > To: ironruby-core at rubyforge.org > > Subject: Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it > reports here. Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my > opinion. If possible we should prefer platform == ?ironruby?, > (or .net, do we need to differentiate .net and mono?), but accept ot > hers. > > JD > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Shri Borde > Sent: Tuesday, March 02, 2010 10:02 AM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach > be for porting existing gems to IronRuby? There could be two > possible approaches: > > 1. Create a gem with the same name (?win32console? in this > case), and specify platform==?ironruby?. That way, dependent gems > do not need to be updated, and users have to remember just one name. > IronRuby will use the version with platform==?ironruby?, and MRI > will use the one with platform==?mswin32?. So there should not be > any clashes even if you use MRI and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in > general? > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Will Green > Sent: Tuesday, March 02, 2010 7:47 AM > To: ironruby-core > Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the > gem install locally first. > > > > Please let me know if you still have trouble installing it from Rubygems.org > . > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if > it can, the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/8d703a55/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Shri Borde
Sent: Saturday, March 06, 2010 10:25 AM
To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:Tomas.Matousek at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/017069c5/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Jim Deville
Sent: Saturday, March 06, 2010 3:53 PM
To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Shri Borde
Sent: Saturday, March 06, 2010 10:25 AM
To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:Tomas.Matousek at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/e5fda9e8/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Will Green
Sent: Saturday, March 06, 2010 3:36 PM
To: ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of
Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:Tomas.Matousek at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/eed1ed2c/attachment-0001.html>
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Saturday, March 06, 2010 3:36 PM > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Ivan Porto Carrero > *Sent:* Saturday, March 06, 2010 6:12 AM > *To:* ironruby-core at 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 at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:18 PM > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 9:46 AM > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:11 AM > > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 7:08 AM > > > *To:* ironruby-core at 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 at 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 = ''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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > > *To:* ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/40fec5ae/attachment-0001.html>
I think you can set the platform to be ?universal-.net? and it will work on all
.NET versions.
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Saturday, March 06, 2010 3:36 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Ivan Porto Carrero
Sent: Saturday, March 06, 2010 6:12 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
hotgazpacho.org<mailto:will at 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 at
microsoft.com<mailto:Tomas.Matousek at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:18 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 9:46 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 8:11 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Friday, March 05, 2010 7:08 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at
microsoft.com<mailto:Shri.Borde at 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 at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 11:52 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby version of existing gems
That all depends on how Gem checks the platform. If it uses the RUBY_PLATFORM
variable, then IronRuby needs to change what it reports here. Currently, it
reports i386-mswin32.
--
Will Green
http://hotgazpacho.org/
On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at
microsoft.com<mailto:jdeville at microsoft.com>> wrote:
I believe JRuby is doing the 1st one, which makes sense in my opinion. If
possible we should prefer platform == ?ironruby?, (or .net, do we need to
differentiate .net and mono?), but accept others.
JD
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Tuesday, March 02, 2010 10:02 AM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
Subject: [Ironruby-core] IronRuby version of existing gems
This brings a question to mind - what should the general approach be for
porting existing gems to IronRuby? There could be two possible approaches:
1. Create a gem with the same name (?win32console? in this case), and
specify platform==?ironruby?. That way, dependent gems do not need to be
updated, and users have to remember just one name. IronRuby will use the version
with platform==?ironruby?, and MRI will use the one with platform==?mswin32?. So
there should not be any clashes even if you use MRI and IronRuby on the same
machine.
2. Create a new gem like iron-term-ansicolor.
Any pro or cons to the two? What should the recommendation be in general?
From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: Tuesday, March 02, 2010 7:47 AM
To: ironruby-core
Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
I released iron-term-ansicolor 0.0.3 last night after testing the gem install
locally first.
Please let me know if you still have trouble installing it from
Rubygems.org<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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/5e9ffd88/attachment-0001.html>
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 Sun, Mar 7, 2010 at 1:16 AM, Shri Borde <Shri.Borde at microsoft.com> wrote:> I think you can set the platform to be ?universal-.net? and it will work > on all .NET versions. > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Saturday, March 06, 2010 3:36 PM > > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Ivan Porto Carrero > *Sent:* Saturday, March 06, 2010 6:12 AM > *To:* ironruby-core at 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 at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:18 PM > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 9:46 AM > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 8:11 AM > > > *To:* ironruby-core at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Friday, March 05, 2010 7:08 AM > > > *To:* ironruby-core at 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 at 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 = ''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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 11:52 AM > > > *To:* ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] IronRuby version of existing gems > > > > That all depends on how Gem checks the platform. If it uses the > RUBY_PLATFORM variable, then IronRuby needs to change what it reports here. > Currently, it reports i386-mswin32. > > > -- > Will Green > http://hotgazpacho.org/ > > On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com> > wrote: > > I believe JRuby is doing the 1st one, which makes sense in my opinion. If > possible we should prefer platform == ?ironruby?, (or .net, do we need to > differentiate .net and mono?), but accept others. > > JD > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Tuesday, March 02, 2010 10:02 AM > *To:* ironruby-core at rubyforge.org > *Subject:* [Ironruby-core] IronRuby version of existing gems > > This brings a question to mind - what should the general approach be for > porting existing gems to IronRuby? There could be two possible approaches: > > 1. Create a gem with the same name (?win32console? in this case), > and specify platform==?ironruby?. That way, dependent gems do not need to be > updated, and users have to remember just one name. IronRuby will use the > version with platform==?ironruby?, and MRI will use the one with > platform==?mswin32?. So there should not be any clashes even if you use MRI > and IronRuby on the same machine. > > 2. Create a new gem like iron-term-ansicolor. > > > > Any pro or cons to the two? What should the recommendation be in general? > > > > *From:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Will Green > *Sent:* Tuesday, March 02, 2010 7:47 AM > *To:* ironruby-core > *Subject:* Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released > > > > I released iron-term-ansicolor 0.0.3 last night after testing the gem > install locally first. > > > > Please let me know if you still have trouble installing it from > Rubygems.org. > > > > Also, I''ve submitted a patch to RSpec to use iron-term-ansicolor if it can, > the same way it tries to use win32console under MRI. > > > -- > Will Green > http://hotgazpacho.org/ > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/dc2a3534/attachment-0001.html>
Daniele Alessandri
2010-Mar-07 09:01 UTC
[Ironruby-core] IronRuby version of existing gems
On Sun, Mar 7, 2010 at 08:07, Will Green <will at 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
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 at
gmail.com>wrote:
> On Sun, Mar 7, 2010 at 08:07, Will Green <will at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/eddbb878/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100307/dae48c49/attachment-0001.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100308/7587e411/attachment.html>
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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at 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 at rubyforge.org [mailto:ironruby-core-bounces at 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100308/8c17df76/attachment-0001.html>
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 at 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 at
microsoft.com<mailto:Shri.Borde at 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 at hotgazpacho.org<mailto:will at
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 at
microsoft.com<mailto:Shri.Borde at 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 at hotgazpacho.org<mailto:will at
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 at
microsoft.com<mailto:Shri.Borde at 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 at hotgazpacho.org<mailto:will at
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 at
microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Sunday, March 07, 2010 6:53 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Shri Borde
Sent: Sunday, March 07, 2010 2:27 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Will Green
Sent: 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 at
gmail.com<mailto:suppakilla at gmail.com>> wrote:
On Sun, Mar 7, 2010 at 08:07, Will Green <will at
hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20100310/17b01c83/attachment-0001.html>
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 Sun, Mar 7, 2010 at 10:01 PM, Jim Deville <jdeville at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, March 07, 2010 6:53 PM > > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, March 07, 2010 2:27 PM > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at gmail.com> > wrote: > > On Sun, Mar 7, 2010 at 08:07, Will Green <will at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100310/c160ed9b/attachment-0001.html>
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 at 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 > > > <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 at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Sunday, March 07, 2010 6:53 PM >> >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde >> *Sent:* Sunday, March 07, 2010 2:27 PM >> *To:* ironruby-core at 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 at rubyforge.org [mailto: >> ironruby-core-bounces at 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 at gmail.com> >> wrote: >> >> On Sun, Mar 7, 2010 at 08:07, Will Green <will at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100310/fc420c15/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: dotnet_ironruby_support.diff Type: application/octet-stream Size: 3327 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100310/fc420c15/attachment.obj>
The name is spelled as ?.NET?, and so "gemname-universal-dotNET" would read better than just "gemname-universal-dotnet". From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/b324a864/attachment-0001.html>
cory.foy at gmail.com
2010-Mar-11 15:48 UTC
[Ironruby-core] IronRuby version of existing gems
Yes, but those of us on case-sensitive operating systems prefer all lower case, if possible. Cory Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Shri Borde <Shri.Borde at microsoft.com> Date: Thu, 11 Mar 2010 15:45:50 To: ironruby-core at rubyforge.org<ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Ivan Porto Carrero
2010-Mar-11 16:33 UTC
[Ironruby-core] IronRuby version of existing gems
+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 Thu, Mar 11, 2010 at 4:48 PM, <cory.foy at gmail.com> wrote:> Yes, but those of us on case-sensitive operating systems prefer all lower > case, if possible. > > Cory > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Shri Borde <Shri.Borde at microsoft.com> > Date: Thu, 11 Mar 2010 15:45:50 > To: ironruby-core at rubyforge.org<ironruby-core at rubyforge.org> > Subject: Re: [Ironruby-core] IronRuby version of existing gems > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/570d38ab/attachment.html>
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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at 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 at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, March 07, 2010 6:53 PM > > > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Shri Borde > *Sent:* Sunday, March 07, 2010 2:27 PM > *To:* ironruby-core at 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 at rubyforge.org [mailto: > ironruby-core-bounces at 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 at gmail.com> > wrote: > > On Sun, Mar 7, 2010 at 08:07, Will Green <will at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/50a5af7c/attachment-0001.html>
Wouldn?t ?clr? be better after all? Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core at 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 at microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/236879a5/attachment-0001.html>
I?d also like to echo and +1 the *nix users vote for keeping things lowercase. JD From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek Sent: Thursday, March 11, 2010 9:11 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Wouldn?t ?clr? be better after all? Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core at 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 at microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/47d23b92/attachment-0001.html>
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 at microsoft.com> wrote:> Wouldn?t ?clr? be better after all??Tomas?From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green > Sent: Thursday, March 11, 2010 8:47 AM > To: ironruby-core at 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 at 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 at rubyforge.org [mailto:ironruby-core-bounces at 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 at 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 at 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/
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 at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek Sent: Thursday, March 11, 2010 9:11 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] IronRuby version of existing gems Wouldn?t ?clr? be better after all? Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Thursday, March 11, 2010 8:47 AM To: ironruby-core at 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 at microsoft.com<mailto:Shri.Borde at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at hotgazpacho.org<mailto:will at 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 at microsoft.com<mailto:jdeville at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 6:53 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Shri Borde Sent: Sunday, March 07, 2010 2:27 PM To: ironruby-core at rubyforge.org<mailto:ironruby-core at 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 at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Will Green Sent: 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 at gmail.com<mailto:suppakilla at gmail.com>> wrote: On Sun, Mar 7, 2010 at 08:07, Will Green <will at hotgazpacho.org<mailto:will at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/a5448318/attachment-0001.html>
cory.foy at gmail.com
2010-Mar-11 18:18 UTC
[Ironruby-core] IronRuby version of existing gems
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 -----Original Message----- From: Will Green <will at hotgazpacho.org> Date: Thu, 11 Mar 2010 12:37:51 To: <ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] IronRuby version of existing gems 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 at microsoft.com> wrote:> Wouldn?t ?clr? be better after all??Tomas?From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green > Sent: Thursday, March 11, 2010 8:47 AM > To: ironruby-core at 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 at 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 at rubyforge.org [mailto:ironruby-core-bounces at 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 at 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 at 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/ _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
>> The name is spelled as ?.NET?, and so "gemname-universal-dotNET" wouldread 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 :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100312/f7e77568/attachment.html>
Ivan Porto Carrero
2010-Mar-11 21:19 UTC
[Ironruby-core] IronRuby version of existing gems
I don''t care either way as long as it''s lower-case On Thursday, March 11, 2010, Orion Edwards <orion.edwards at 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
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 at 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 at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/9b5c73be/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: dotnet_ironruby_support.diff Type: application/octet-stream Size: 3331 bytes Desc: not available URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100311/9b5c73be/attachment.obj>
Sounds great. Thanks for pushing on this! From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at 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 at whiterabbitconsulting.eu<mailto:ivan at 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 at gmail.com<mailto:orion.edwards at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100312/a2aed2ed/attachment.html>
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 at microsoft.com> wrote:> Sounds great. Thanks for pushing on this! > > > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at 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 at 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 at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100319/8842a07f/attachment.html>
Thanks a lot for pushing on this! From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: Friday, March 19, 2010 3:45 AM To: ironruby-core at 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 at microsoft.com<mailto:Shri.Borde at microsoft.com>> wrote: Sounds great. Thanks for pushing on this! From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Will Green Sent: 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 at whiterabbitconsulting.eu<mailto:ivan at 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 at gmail.com<mailto:orion.edwards at 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 at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100319/30b3c2bc/attachment-0001.html>