[Ironruby-core] IronRuby version of existing gems

Will Green will at hotgazpacho.org
Sun Mar 7 02:07:29 EST 2010


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>


More information about the Ironruby-core mailing list