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: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
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:
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
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…
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: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
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:
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
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?
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…
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: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
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:
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
http://rubyforge.org/tracker/index.php?func=detail&aid=27951&group_id=126&atid=577As
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.
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 G. [mailto:[email protected]]
Sent: Tuesday, March 09, 2010 6:49 PM
To: Shri B.
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
On Tue, Mar 9, 2010 at 1:30 PM, Shri B.
<[email protected]mailto:[email protected]> 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)
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.
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!!
To: Shri B.
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)
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 G. http://hotgazpacho.org/
On Mon, Mar 8, 2010 at 1:17 PM, Shri B.
<[email protected]mailto:[email protected]> 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.
Subject: Re: [Ironruby-core] IronRuby version of existing gems
Yes, I can install the universal-.nethttp://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-.nethttp://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!
On Mar 8, 2010, at 2:42 AM, Shri B.
<[email protected]mailto:[email protected]> 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:
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
Will, could you recreate the universal-.nethttp://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…
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-.nethttp://universal-.net†option,
iron-term-ansicolor-0.0.3-universal-.nethttp://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-.nethttp://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-.nethttp://iron-term-ansicolor-0.0.3-universal-.net.
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
The name is spelled as “.NETâ€, and so “gemname-universal-dotNET” would
read better than just “gemname-universal-dotnet”.
From: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
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.
On Wed, Mar 10, 2010 at 10:33 PM, Will G.
<[email protected]mailto:[email protected]> 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:
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.
On Sun, Mar 7, 2010 at 10:01 PM, Jim D.
<[email protected]mailto:[email protected]> 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?
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…
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.
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
On Thu, Mar 11, 2010 at 10:45 AM, Shri B.
<[email protected]mailto:[email protected]> wrote:
The name is spelled as “.NETâ€, and so “gemname-universal-dotNET” would
read better than just “gemname-universal-dotnet”.
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 G. http://hotgazpacho.org/
On Wed, Mar 10, 2010 at 10:33 PM, Will G.
<[email protected]mailto:[email protected]> 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:
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.
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 G. http://hotgazpacho.org/
On Sun, Mar 7, 2010 at 10:01 PM, Jim D.
<[email protected]mailto:[email protected]> 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?
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…
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.
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
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 G. http://hotgazpacho.org/
On Wed, Mar 10, 2010 at 10:33 PM, Will G.
<[email protected]mailto:[email protected]> 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:
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.
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 G. http://hotgazpacho.org/
On Sun, Mar 7, 2010 at 10:01 PM, Jim D.
<[email protected]mailto:[email protected]> 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?
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…
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.
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
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â€
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 G. http://hotgazpacho.org/
On Wed, Mar 10, 2010 at 10:33 PM, Will G.
<[email protected]mailto:[email protected]> 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:
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.
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 G. http://hotgazpacho.org/
On Sun, Mar 7, 2010 at 10:01 PM, Jim D.
<[email protected]mailto:[email protected]> 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?
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…
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.
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
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).
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.
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 G. http://hotgazpacho.org/On Wed, Mar 10, 2010 at 10:33 PM, Will G. [email protected] 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 G. http://hotgazpacho.org/On Sun, Mar 7, 2010 at 10:01 PM, Jim D. [email protected] wrote:I’m also wondering what will happen if you put the gem on two different gem servers (if that is possible, like g
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
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
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.
From: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
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.
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
