[Ironruby-core] IronRuby version of existing gems

Will Green will at hotgazpacho.org
Sat Mar 6 18:36:06 EST 2010


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>


More information about the Ironruby-core mailing list