Ruby Forum Ruby-core > RUBY_ENGINE?

Hi,

It was discussed in the past but as far as I can tell, there were no
decision made, about the constant to specify the Ruby implementation.

Now that Rubinius and JRuby define RUBY_ENGINE, and RubyGems also uses
RUBY_ENGINE, maybe it's a good time to revisit the issue?
It would be really nice if MRI would have that constant defined as
well (and maybe to put this change into upcoming 1.8.6 and 1.8.7
maintenance releases)?

Opinions?

Thanks,
  --Vladimir

Vladimir Sizikov wrote:
> Hi,
> 
> It was discussed in the past but as far as I can tell, there were no
> decision made, about the constant to specify the Ruby implementation.
> 
> Now that Rubinius and JRuby define RUBY_ENGINE, and RubyGems also uses
> RUBY_ENGINE, maybe it's a good time to revisit the issue?
> It would be really nice if MRI would have that constant defined as
> well (and maybe to put this change into upcoming 1.8.6 and 1.8.7
> maintenance releases)?

I concur...it would be nice to get it out there and finally have an
official variable to tell which "type" of Ruby implementation you're
running on.

And it's just one variable :)

- Charlie

In article <3454c9680807241200xf7cc766qb987905a3987bb78@mail.gmail.com>,
  "Vladimir Sizikov" <vsizikov@gmail.com> writes:

> Now that Rubinius and JRuby define RUBY_ENGINE, and RubyGems also uses
> RUBY_ENGINE, maybe it's a good time to revisit the issue?

What the usage of RUBY_ENGINE?

I heard it is used to know command name at the IRC meeting.
I think it is not good idea.

On Jul 24, 2008, at 19:35 , Tanaka Akira wrote:

> I heard it is used to know command name at the IRC meeting.
> I think it is not good idea.

not command name, but ruby "flavor": (mri) ruby, rubinius, jruby, etc.

On Thu, Jul 24, 2008 at 7:46 PM, Ryan Davis <ryand-ruby@zenspider.com> 
wrote:
>>
>> I heard it is used to know command name at the IRC meeting.
>> I think it is not good idea.
>
> not command name, but ruby "flavor": (mri) ruby, rubinius, jruby, etc.
>

What would be the value if this constant, for 1.8 vs 1.9? Also, String
or Symbol?

Laurent

On Fri, Jul 25, 2008 at 4:53 AM, Laurent Sansonetti
<laurent.sansonetti@gmail.com> wrote:
> What would be the value if this constant, for 1.8 vs 1.9? Also, String
> or Symbol?

It could just be "mri'. For version numbers, you could then inspect
RUBY_VERSION, RUBY_PATCHLEVEL,, and Config::CONFIG as appropriate.

Currently, JRuby's value is "jruby", and Rubinius' value is "rbx", 
strings.

Thanks,
  --Vladimir

Hi,

On Fri, Jul 25, 2008 at 4:35 AM, Tanaka Akira <akr@fsij.org> wrote:
> What the usage of RUBY_ENGINE?

1. RubyGems uses it to invoke #{RUBY_ENGINE}.rb file with
customizations, specific for particular implementation

2. Different implementations have different specifics, like JRuby can
'require' a JAR file and need different activerecord drivers, etc.
There are also some JRuby-specific libraries that only make sens for
JRuby, and the whole Java Integration layer. So, folks need to figure
out when they run with JRuby and when they not.

Initially, the following code was wildly used:
if RUBY_PLATFORM =~ /java/

But this is fragile, and not 100% reliable (other implementations
might have "java" in their platform too!). We also have JRuby-specific
JRUBY_VERSION, so one might check that one. But, when the number of
implementations grows, it gets less and less convenient to use
implementation-specific means to detect the implementation. Hence, the
proposal for that constant. So that the folks could easily and
reliably detect the implementation.

> I heard it is used to know command name at the IRC meeting.
> I think it is not good idea.

Agreed, this is not a good idea, and the constant is not for this. It
has justa short Ruby implementation identificator, like "jruby",
"rbx", etc.

Thanks,
  --Vladimir

From: "Ryan Davis" <ryand-ruby@zenspider.com>
> On Jul 24, 2008, at 19:35 , Tanaka Akira wrote:
>>
>> What the usage of RUBY_ENGINE?
>>
>> I heard it is used to know command name at the IRC meeting.
>> I think it is not good idea.
> 
> not command name, but ruby "flavor": (mri) ruby, rubinius, jruby, etc.

From: http://ruby-design.pbwiki.com/f/ruby-core-20080430.txt

[2008/04/30 20:21:59] @ headius set topic 
http://ruby-design.pbwiki.com/Design20080430 -
RUBY_ENGINE or similar constant to indicate implementation
// ...
[2008/04/30 20:33:31] <evan> can I bring up the root issue?
[2008/04/30 20:33:39] <evan> of wanting this constant
[2008/04/30 20:33:43] <headius> yes
[2008/04/30 20:33:46] <headius> do taht
[2008/04/30 20:33:49] <enebo> please
[2008/04/30 20:33:56] <evan> 99.9% of the time, it's because someone 
needs to know the name of the ruby command
thaht was issued to run the current program
[2008/04/30 20:34:06] <evan> so they'd use this to figure out 
ruby/rbx/jruby whatever.
[2008/04/30 20:34:06] <headius> that's already available
[2008/04/30 20:34:16] <evan> not in 1.8 it's not.
[2008/04/30 20:34:16] <akr> rbconfig
[2008/04/30 20:34:22] <evan> thats the installed location
[2008/04/30 20:34:25] <evan> not the current running one
[2008/04/30 20:34:37] <evan> an great example of that is doing 
../../blah/bin/ruby
[2008/04/30 20:34:41] <lrz> $0 ?
[2008/04/30 20:34:45] <evan> $0 is the script
[2008/04/30 20:34:50] <evan> Rubinius implements this
[2008/04/30 20:35:00] <matz_> evan: keep going
[2008/04/30 20:35:00] <evan> by using getcwd() + argv[0] at start up
[2008/04/30 20:35:02] <akr> argv[0] is not trustable
[2008/04/30 20:35:08] <evan> to calculate the absolute path to the 
running binary

// ...

[2008/04/30 20:41:44] <matz_> I don't think RUBY_ENGINE should be used 
for feature check
// ...
[2008/04/30 20:42:09] <matz_> it must be used for something different
// ...
[2008/04/30 20:42:23] <ko1_> RUBY_ENGINE purpose: (1) search bin name, 
(2) check spec
[2008/04/30 20:42:28] <matz_> for example, choosing performance trick 
depends on implementation
[2008/04/30 20:42:29] <headius> people will use RUBY_ENGINE for feature 
set either way
[2008/04/30 20:42:29] <ko1_> any other reason?
[2008/04/30 20:42:32] <headius> I guarantee it
[2008/04/30 20:42:43] <ko1_> (3) show version
[2008/04/30 20:43:04] <MenTaLguY> I think there needs to be a more 
explicit way to determine the command name
the current Ruby interpreter was started with
[2008/04/30 20:43:06] <unak> (4) installing gems
// ...


Seems people had a number of use cases in mind, indeed including
determining the name of the actual ruby binary name.


Regards,

Bill

In article 
<3454c9680807250045q6d3ecbe8n2692c899dc62a94a@mail.gmail.com>,
  "Vladimir Sizikov" <vsizikov@gmail.com> writes:

> It could just be "mri'. For version numbers, you could then inspect

RubyGems uses RUBY_ENGINE as a directory name:

lib/rubygems/defaults.rb:

  def self.default_dir
    if defined? RUBY_FRAMEWORK_VERSION then
      File.join File.dirname(ConfigMap[:sitedir]), 'Gems',
                ConfigMap[:ruby_version]
    elsif defined? RUBY_ENGINE then
      File.join ConfigMap[:libdir], RUBY_ENGINE, 'gems',
                ConfigMap[:ruby_version]
    else
      File.join ConfigMap[:libdir], 'ruby', 'gems', 
ConfigMap[:ruby_version]
    end
  end

If RUBY_ENGINE is "mri", libdir/mri/gems/version is used as default_dir.

I guess RubyGems expects "ruby".

On 25/07/2008, Tanaka Akira <akr@fsij.org> wrote:
>  lib/rubygems/defaults.rb:
>     end
>   end
>
>  If RUBY_ENGINE is "mri", libdir/mri/gems/version is used as default_dir.
>
>  I guess RubyGems expects "ruby".

I guess this is bogus since there is no guarantee that RUBY_ENGINE is
in any way related to filesystem. Wether it's the executable name or
the ruby flavour RubyGems should use the ruby config variables to
determine library directory, not RUBY_ENGINE.

The variable name lends itself easily to both uses so I guess a
different name should be used for both features to avoid confusion.

Thanks

Michal

Hi Bill,

Ah, I forgot about that discussion...

Maybe I'm missing something here, but I always thought that this kind
of functionality (detecting the path to the implementation that
currently runs the code) *is* already available via 'rbconfig' lib:

RUBY = File.join(Config::CONFIG['bindir'], 
Config::CONFIG['ruby_install_name'])

Works fine with MRI 1.8 and 1.9, JRuby, Rubinius.

thanks,
  --Vladimir

Hi,

On Fri, Jul 25, 2008 at 10:23 AM, Tanaka Akira <akr@fsij.org> wrote:
> If RUBY_ENGINE is "mri", libdir/mri/gems/version is used as default_dir.
>
> I guess RubyGems expects "ruby".

Ah, good point.

Thanks,
  --Vladimir

On Jul 25, 2008, at 01:21 AM, Bill Kelly wrote:
> From: http://ruby-design.pbwiki.com/f/ruby-core-20080430.txt
Evan is mistaken.  You can calculate the current ruby like this:

ruby = File.join RbConfig::CONFIG['bindir'],
RbConfig::CONFIG['ruby_install_name']
ruby << RbConfig::CONFIG['EXEEXT']

On Jul 25, 2008, at 01:23 AM, Tanaka Akira wrote:
>
> If RUBY_ENGINE is "mri", libdir/mri/gems/version is used as  
> default_dir.
>
> I guess RubyGems expects "ruby".

I expect the MRI value to be "ruby" as it is the reference
implementation.

From: "Eric Hodel" <drbrain@segment7.net>
> On Jul 25, 2008, at 01:21 AM, Bill Kelly wrote:
>>
>> From: http://ruby-design.pbwiki.com/f/ruby-core-20080430.txt
> 
> Evan is mistaken.  You can calculate the current ruby like this:
> 
> ruby = File.join RbConfig::CONFIG['bindir'],  
> RbConfig::CONFIG['ruby_install_name']
> ruby << RbConfig::CONFIG['EXEEXT']

[2008/04/30 20:34:22] <evan> thats the installed location
[2008/04/30 20:34:25] <evan> not the current running one
[2008/04/30 20:34:37] <evan> an great example of that is doing 
../../blah/bin/ruby


(Note, I don't have any vested interest in this, I am
merely quoting from the IRC logs... For example, I don't
know why it was important to find the current running
binary.  But I'm not sure how RUBY_ENGINE was supposed
to help in the ../../blah/bin/ruby situation anyway? :)


Regards,

Bill

On Jul 25, 2008, at 11:55 AM, Bill Kelly wrote:
> [2008/04/30 20:34:25] <evan> not the current running one
> [2008/04/30 20:34:37] <evan> an great example of that is doing ../../ 
> blah/bin/ruby
>
>
> (Note, I don't have any vested interest in this, I am merely quoting  
> from the IRC logs... For example, I don't know why it was important  
> to find the current running binary.

RubyGems needs to know the path to ruby so it can `#{ruby} extconf.rb`
when building extensions.   Ruby may not be installed as `ruby` or you
may have multiple versions installed either in different paths or with
different names.  Just picking `ruby` every time may lead to an
extension getting built with an incompatible ruby.

> But I'm not sure how RUBY_ENGINE was supposed to help in the ../../ 
> blah/bin/ruby situation anyway? :)

rbconfig.rb takes care of relative paths for you:

$ cat rbconfig.rb
[...]
module Config
[...]
   TOPDIR = File.dirname(__FILE__).chomp!("/lib/ruby/1.8/i686-
darwin9.4.0")
[...]
   CONFIG["prefix"] = (TOPDIR || DESTDIR + "/usr/local")
[...]
   CONFIG["exec_prefix"] = "$(prefix)"
   CONFIG["bindir"] = "$(exec_prefix)/bin"
[...]
   def Config::expand(val, config = CONFIG)
     [code that expands $()]
   end
   CONFIG.each_value do |val|
     Config::expand(val)
   end
[...]

So you always get a full path to your current interpreter's executable.

$ ../../usr/bin/ruby -rubygems -e 'p Gem.ruby'
"/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby"

In article 
<3454c9680807250054i70db563duf44b42d92ba41bfb@mail.gmail.com>,
  "Vladimir Sizikov" <vsizikov@gmail.com> writes:

> 1. RubyGems uses it to invoke #{RUBY_ENGINE}.rb file with
> customizations, specific for particular implementation

I'm not sure what the customizations to be done.

> 2. Different implementations have different specifics, like JRuby can
> 'require' a JAR file and need different activerecord drivers, etc.
> There are also some JRuby-specific libraries that only make sens for
> JRuby, and the whole Java Integration layer. So, folks need to figure
> out when they run with JRuby and when they not.

Why don't just try "some feature"?

For example, zlib is written in C.  So someone may think it
can be used only in RUBY_ENGINE is "ruby" as:

  if RUBY_ENGINE == "ruby"
    require "zlib"
  else
    raise "this program doesn't work on #{RUBY_ENGINE}"
  end

I think

  begin
    require "zlib"
  rescue LoadError
    raise "no zlib"
  end

or

  require "zlib"

is much better becuase it works well with other engines if
it provide zlib.

On Sat, Jul 26, 2008 at 5:09 AM, Tanaka Akira <akr@fsij.org> wrote:
> In article <3454c9680807250054i70db563duf44b42d92ba41bfb@mail.gmail.com>,
>  "Vladimir Sizikov" <vsizikov@gmail.com> writes:
>
>> 1. RubyGems uses it to invoke #{RUBY_ENGINE}.rb file with
>> customizations, specific for particular implementation
>
> I'm not sure what the customizations to be done.
>

One example is the gem stub files generated by RubyGems that need to
be changed to reflect the name of the executable for jRuby (jruby.bat)
at least in Windows.

I've seen and dealt with many regexp that just evaluate /java/ for
RUBY_PLATFORM and I need to perform customization for it (like using a
.jar file instead of a C extension).

> is much better becuase it works well with other engines if
> it provide zlib.

This is for gems or packages that are both compatible (or intend to
be) with the different implementations. Is not about the rescue of a
missing feature.

One example is jruby on Windows cannot perform a series of socket
related functions, while on posix platform it can. So limit your code
to only RUBY_PLATFORM =~ /java/ doesn't work.

So under jRuby there is no way to know the underlying OS because they
rely on RUBY_PLATFORM to make it looks like java. The same will happen
with Rubinius when it works on Windows or IronRuby when it build in
Mono.

Right now, besides query RUBY_PLATFORM, you also need:

defined?(JRUBY_VERSION) or defined?(Rubinius) to deal with specfic
code for those cases... (dunno about IronRuby).

What about an unified way that doesn't pollute the already complicated
RUBY_PLATFORM?

--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On Jul 26, 2:04 am, "Luis Lavena" <luislav...@gmail.com> wrote:
> be changed to reflect the name of the executable for jRuby (jruby.bat)
> >> out when they run with JRuby and when they not.
> missing feature.
> Right now, besides query RUBY_PLATFORM, you also need:
>
> defined?(JRUBY_VERSION) or defined?(Rubinius) to deal with specfic
> code for those cases... (dunno about IronRuby).
>
> What about an unified way that doesn't pollute the already complicated
> RUBY_PLATFORM?
>

RUBY_ENGINE is needed to definitively identify the implementation on
which the code is running. This information needs to be simple and
unambiguous, not tacked onto some other information. When there was a
single implementation, this was not needed, but there are now multiple
implementations.

The RubySpec project needs this information and other code certainly
will. Whether folks use the value of RUBY_ENGINE in conditionals for
requiring code is up to them. They may have a good need to do so.

Also, the name is very clear and descriptive: engine, noun: a thing
that is the agent or instrument of a particular process. RUBY_ENGINE
== the thing that makes your Ruby code run.

Cheers,
Brian

On Jul 26, 2:04 am, "Luis Lavena" <luislav...@gmail.com> wrote:
> be changed to reflect the name of the executable for jRuby (jruby.bat)
> >> out when they run with JRuby and when they not.
> missing feature.
> Right now, besides query RUBY_PLATFORM, you also need:
>
> defined?(JRUBY_VERSION) or defined?(Rubinius) to deal with specfic
> code for those cases... (dunno about IronRuby).
>
> What about an unified way that doesn't pollute the already complicated
> RUBY_PLATFORM?

RUBY_ENGINE is needed to definitively identify the implementation on
which the code is running. This information needs to be simple and
unambiguous, not tacked onto some other information. When there was a
single implementation, this was not needed, but there are now multiple
implementations.

The RubySpec project needs this information and other code certainly
will. Whether folks use the value of RUBY_ENGINE in conditionals for
requiring code is up to them. They may have a good need to do so.

Also, the name is very clear and descriptive: engine, noun: a thing
that is the agent or instrument of a particular process. RUBY_ENGINE
== the thing that makes your Ruby code run.

Cheers,
Brian

On Sat, Jul 26, 2008 at 2:04 AM, Luis Lavena <luislavena@gmail.com> 
wrote:
--- snip ----

> Right now, besides query RUBY_PLATFORM, you also need:
>
> defined?(JRUBY_VERSION) or defined?(Rubinius) to deal with specfic
> code for those cases... (dunno about IronRuby).
>
> What about an unified way that doesn't pollute the already complicated
> RUBY_PLATFORM?
>

RUBY_ENGINE is needed to definitively identify the implementation on
which the code is running. This information needs to be simple and
unambiguous, not tacked onto some other information. When there was a
single implementation, this was not needed, but there are now multiple
implementations.

The RubySpec project needs this information and other code certainly
will. Whether folks use the value of RUBY_ENGINE in conditionals for
requiring code is up to them. They may have a good need to do so.

Also, the name is very clear and descriptive: engine, noun: a thing
that is the agent or instrument of a particular process. RUBY_ENGINE
== the thing that makes your Ruby code run.

Cheers,
Brian

On 27/07/2008, Brian Ford <brixen@gmail.com> wrote:

>
>  Also, the name is very clear and descriptive: engine, noun: a thing
>  that is the agent or instrument of a particular process. RUBY_ENGINE
>  == the thing that makes your Ruby code run.

However, there are at least two interpretations of of "the thing that
makes your Ruby code run":
1) "the way the thing that makes your Ruby code run is implemented"
2) "the file that holds the thing that makes your Ruby code run"

Thanks

Michal

ruby_install_name could be ruby1.8 if the install name is different than
just "Ruby". There's currently no reliable variable that always says
"ruby" under MRI, "jruby" under JRuby, "rbx" under Rubinius, and so on.
The primary goal for this was to eliminate the confusion over which
property to use to know "which ruby impl am I running under".

Michal Suchanek wrote:
>>  requiring code is up to them. They may have a good need to do so.
>>
>>  Also, the name is very clear and descriptive: engine, noun: a thing
>>  that is the agent or instrument of a particular process. RUBY_ENGINE
>>  == the thing that makes your Ruby code run.
> 
> However, there are at least two interpretations of of "the thing that
> makes your Ruby code run":
> 1) "the way the thing that makes your Ruby code run is implemented"
> 2) "the file that holds the thing that makes your Ruby code run"

JRuby is JRuby no matter how you want to slice it. But there's no
variable that can consistently tell you you're running on JRuby or
Rubinius other than RUBY_ENGINE, unless you cobble together checks of
multiple other variables.

- Charlie

Tanaka Akira wrote:
>> There are also some JRuby-specific libraries that only make sens for
>> JRuby, and the whole Java Integration layer. So, folks need to figure
>> out when they run with JRuby and when they not.
> 
> Why don't just try "some feature"?

It's not quite that simple, since just having specific libraries doesn't
mean they're exactly the same. And there are many libraries that may be
only partially implemented on a given implementation. For example,
callcc doesn't exist on JRuby, but you can't find that out without
trying to call it. So you need a missing method check. JRuby has no
syslog at present, so you need a load error check.

And this doesn't help RubyGems. If there's three different versions of a
gem, one that works on Rubinius, one that works on JRuby, one that works
on MRI...how should it choose the right one? By checking
implementation-specific config information? By trying to load libraries
that don't work today (but might work tomorrow)? There's too much
complication in figuring out "which Ruby impl am I running", and adding
a variable to explicitly state it is a clean, simple way to do it.

- Charlie

Bill Kelly wrote:
> (Note, I don't have any vested interest in this, I am merely quoting 
> from the IRC logs... For example, I don't
> know why it was important to find the current running
> binary.  But I'm not sure how RUBY_ENGINE was supposed
> to help in the ../../blah/bin/ruby situation anyway? :)

Say you have a library written in C for MRI, modified C or Ruby with
Rubinius features on Rubinius, or using Java in JRuby. It would be much
nicer to be able to do:

require "my_library/platform/#{RUBY_ENGINE}_api"

Rather than a series of if/else checks that use a combination of
variables. As much as Rubinius, JRuby, MRI, IronRuby may look the same
as far as normal Ruby code, there are differences in how they integrate
with the underlying platform and differences in how you may want to use
them. And currently there's no simple way to definitively know which
Ruby implementation you're using. RUBY_ENGINE is just one constant that
will solve that problem forever...I'm not sure why there's so much
resistance to adding it.

- Charlie

Hi all.

I don't think it's really productive to be discussing about this
constant. After all, it's only a single constant. Implementing it won't
have any negative impacts on the MRI core developers, but it does make
lifes for a lot of people a whole lot easier.

So here's a patch which defines RUBY_ENGINE as "ruby". I've already
committed this patch to Ruby Enterprise Edition's repository, and it
will be bundled with the next release.

With kind regards,
Hongli Lai
--
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

Hi,

On Sat, Jul 26, 2008 at 5:09 AM, Tanaka Akira <akr@fsij.org> wrote:
>  require "zlib"
>
> is much better becuase it works well with other engines if
> it provide zlib.

I agree, that in this case there is need for RUBY_ENGINE, but there
are other use cases when RUBY_ENGINE is much more preferable way. We
get constant flow of questions from users on how to detect the current
implementation.

One of the typical cases is Rails database config. JRuby uses
different drivers and slightly different configuration options, so
having a standard way to detect JRuby would be great. The same most
probably will be true for IronRuby, etc.
And sometimes users need to use different gems for different
implementations for various reasons. Begin-rescue is not the
best/performant way to do that.

Here's the example of rails database configuration:

if defined? JRUBY_VERSION
  gem 'activerecord-jdbc-adapter'
  require 'jdbc_adapter'
  adapter = 'jdbcmysql'
else
  adapter = 'mysql'
end

Add a couple more implementations with custom ways to detect them and
you have a mess.

Thanks,
  --Vladimir

Hi,

In message "Re: [ruby-core:18001] Re: RUBY_ENGINE?"
    on Mon, 28 Jul 2008 05:21:11 +0900, Hongli Lai <hongli@plan99.net> 
writes:

|So here's a patch which defines RUBY_ENGINE as "ruby". I've already 
|committed this patch to Ruby Enterprise Edition's repository, and it 
|will be bundled with the next release.

Don't be so quick.  You guys haven't made it clear that

  * 1.8 and 1.9 can share same RUBY_ENGINE value (since both of them
    are "my" ruby), or not (since they are different)

  * plain 1.8 and RubyEnterpriseEdition (or other forks) can share
    same RUBY_ENGINE (since they are almost identical), or not (since
    they are different after all).

              matz.

Yukihiro Matsumoto wrote:
> Don't be so quick.  You guys haven't made it clear that
> 
>   * 1.8 and 1.9 can share same RUBY_ENGINE value (since both of them
>     are "my" ruby), or not (since they are different)

They are both MRI. But it's easy to distinguish between them by checking
RUBY_VERSION.

>   * plain 1.8 and RubyEnterpriseEdition (or other forks) can share
>     same RUBY_ENGINE (since they are almost identical), or not (since
>     they are different after all).

Ruby Enterprise Edition is meant to be fully compatible with MRI. It's
basically just MRI + GC patches + a different memory allocator. There
are no language-level changes or binary compatibility issues, so as far
as the script is concerned it's just MRI.

Regards,
Hongli Lai

Hongli Lai wrote:
>>   * plain 1.8 and RubyEnterpriseEdition (or other forks) can share
>>     same RUBY_ENGINE (since they are almost identical), or not (since
>>     they are different after all).
> 
> Ruby Enterprise Edition is meant to be fully compatible with MRI. It's 
> basically just MRI + GC patches + a different memory allocator. There 
> are no language-level changes or binary compatibility issues, so as far 
> as the script is concerned it's just MRI.

By the way, Ruby Enterprise Edition's goal is to be eventually merged
back to MRI. Last time you had some issues with performance, so I'm
testing Ruby Enterprise Edition in real-world applications and observing
its performance characteristics.

Regards,
Hongli Lai

On Sun, Jul 27, 2008 at 11:37 PM, Hongli Lai <hongli@plan99.net> wrote:
>
> By the way, Ruby Enterprise Edition's goal is to be eventually merged back
> to MRI. Last time you had some issues with performance, so I'm testing Ruby
> Enterprise Edition in real-world applications and observing its performance
> characteristics.
>

Before considering merging of REE into Ruby you should also take a
look at other platforms. Right now the memory allocation techniques
used by REE are not compatible with Windows (either VC or GCC
compilers).

So I think that before mergeing them REE should be able to run in the
broad selection of platforms Ruby currently runs, including, of
course, Windows.

Regards,
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

Luis Lavena wrote:
> Before considering merging of REE into Ruby you should also take a
> look at other platforms. Right now the memory allocation techniques
> used by REE are not compatible with Windows (either VC or GCC
> compilers).
>
> So I think that before mergeing them REE should be able to run in the
> broad selection of platforms Ruby currently runs, including, of
> course, Windows.
> 
> Regards,

That's easily achieved by disabling the memory allocator for unsupported
platforms. As for the memory allocator supporting Windows, I don't think
that's going to happen anything soon. We're dependent on the tcmalloc
developers when it comes to this.

In any case, it'll gracefully fallback on platforms that don't support
tcmalloc and/or fork-copy-on-write.

Regards,
Hongli Lai

On Sun, Jul 27, 2008 at 2:35 PM, Hongli Lai <hongli@plan99.net> wrote:
>>  * plain 1.8 and RubyEnterpriseEdition (or other forks) can share
>>    same RUBY_ENGINE (since they are almost identical), or not (since
>>    they are different after all).
>
> Ruby Enterprise Edition is meant to be fully compatible with MRI. It's
> basically just MRI + GC patches + a different memory allocator. There are no
> language-level changes or binary compatibility issues, so as far as the
> script is concerned it's just MRI.
>

Mmh, Ruby Enterprise Edition is compatible with MRI, but the engine
(which this constant is supposed to represent?) under the covers is
not the exact same one.

# MacRuby is supposed to be somewhat compatible with MRI 1.9 too. But
it has a different memory allocator, GC, object model, dispatcher, ...
in other words, a completely different engine.

Just my 2 cents,

Laurent

Laurent Sansonetti wrote:
>>>    same RUBY_ENGINE (since they are almost identical), or not (since
> 
> # MacRuby is supposed to be somewhat compatible with MRI 1.9 too. But
> it has a different memory allocator, GC, object model, dispatcher, ...
> in other words, a completely different engine.

Rubinius is intended to be compatible with MRI 1.8. JRuby is intended to
be compatible with MRI 1.8 and 1.9. IronRuby is intended to be
compatible with MRI 1.8. I don't think that reduces the need for a
specific constant describing which implementation/codebase you're
running on.

All Ruby implementations are intended to be compatible...otherwise they
wouldn't be Ruby. MacRuby would probably want to specify RUBY_ENGINE as
"macruby" since as you state it is a different engine underneath that
will have different quirks. Also in MacRuby's case, there's a pretty
seamless two-way integration with ObjC, so people would use RUBY_ENGINE
== "macruby" to know if they should load their ObjC-based libraries.

So like JRuby with Java, Rubinius with various extensions to core
classes and a differen execution/IO/threading model, IronRuby with .NET,
MagLev with potentially SmallTalk-based libraries...it's a perfect way
to identify "hey, I'm on implementation X and can expect
features/bugs/quirks of that implementation to be present."

- Charlie

Charles Oliver Nutter wrote:
> Michal Suchanek wrote:
>> On 27/07/2008, Brian Ford <brixen@gmail.com> wrote:
>>
>>> RUBY_ENGINE is needed to definitively identify the implementation on
>>>  which the code is running. This information needs to be simple and
>>>  unambiguous, not tacked onto some other information. When there was a
>>>  single implementation, this was not needed, but there are now multiple
>>>  implementations.
>>>

A RUBY_BUILD string which can arbitrarily be set by binary package 
maintainer
at ./configure time would also be helpful.  We routinely apply source 
level
patches to our build.  It would be helpful to identify our build 
separately
from a stock Debian package, for example, because we target our in-house
package for a different install directory, but both are usable on the 
same
machine.  Ubuntu package maintainers are notorious for applying source
packages that are not visible by internal run-time identifiers.

Perhaps RUBY_BUILD should default to current date, if not specified?

Kurt Stephens

On 27/07/2008, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> > >
> > makes your Ruby code run":
> > 1) "the way the thing that makes your Ruby code run is implemented"
> > 2) "the file that holds the thing that makes your Ruby code run"
> >
>
>  JRuby is JRuby no matter how you want to slice it. But there's no variable
> that can consistently tell you you're running on JRuby or Rubinius other
> than RUBY_ENGINE, unless you cobble together checks of multiple other
> variables.

Nobody is denying JRuby is JRuby, and it would be useful to know one
is running it.

However, last time the topic was brought up nobody could think of any
constant name or other place where to store that information in
generally acceptable way.

RUBY_ENGINE is ambiguous because some people would think it's the
actual file with the ruby executable or something like that

RUBY_FLAVOUR has two alternate spellings

etc, etc

Thanks

Michal

At 10:55 08/07/28, Laurent Sansonetti wrote:

># MacRuby is supposed to be somewhat compatible with MRI 1.9 too. But
>it has a different memory allocator, GC, object model, dispatcher, ...
>in other words, a completely different engine.

And not to mention the differences with respect to character encodings
(at least for the moment).

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

From: "Charles Oliver Nutter" <charles.nutter@sun.com>
> 
> require "my_library/platform/#{RUBY_ENGINE}_api"
> 
> Rather than a series of if/else checks that use a combination of 
> variables. As much as Rubinius, JRuby, MRI, IronRuby may look the same 
> as far as normal Ruby code, there are differences in how they integrate 
> with the underlying platform and differences in how you may want to use 
> them. And currently there's no simple way to definitively know which 
> Ruby implementation you're using. RUBY_ENGINE is just one constant that 
> will solve that problem forever...I'm not sure why there's so much 
> resistance to adding it.

I've been hesitant to respond; I don't want to clutter up the thread
given that I don't have any say in this anyway either way.

But for what it's worth, your require example above makes perfect
sense to me.  And (as an observer) I'm not personally against
RUBY_ENGINE at all.  But it's nice to see a use case I can readily
understand.  (I admit to having been perplexed over the prospect of
using RUBY_ENGINE to locate the active ruby executable binary.)


Regards,

Bill

In article <3454c9680807271330pd68dc2agdc76554a5482dcaa@mail.gmail.com>,
  "Vladimir Sizikov" <vsizikov@gmail.com> writes:

> One of the typical cases is Rails database config. JRuby uses
> different drivers and slightly different configuration options, so
> having a standard way to detect JRuby would be great. The same most
> probably will be true for IronRuby, etc.
> And sometimes users need to use different gems for different
> implementations for various reasons. Begin-rescue is not the
> best/performant way to do that.

What's problem of rescue LoadError?

begin
  gem 'activerecord-jdbc-adapter'
  require 'jdbc_adapter'
  adapter = 'jdbcmysql'
rescue LoadError
  adapter = 'mysql'
end

Why do you like RUBY_ENGINE over LoadError?

If LoadError is used, it may be work on non-JRuby
implementation.

I heard Rubinius can use Ruby's extension library
implemented in C.  I think it is difficult to use
RUBY_ENGINE accurately.

In article <488CCF46.6000806@sun.com>,
  Charles Oliver Nutter <charles.nutter@sun.com> writes:

> It's not quite that simple, since just having specific libraries doesn't 
> mean they're exactly the same. And there are many libraries that may be 
> only partially implemented on a given implementation. For example, 
> callcc doesn't exist on JRuby, but you can't find that out without 
> trying to call it. So you need a missing method check. JRuby has no 
> syslog at present, so you need a load error check.

Agreed.  It should be possible to test a method is really
implemented without calling it.

So I implemented a way to do it.
In [ruby-dev:34707], I implemented respond_to? returns false
for a method which just raises NotImplementedError.

I think RUBY_ENGINE is not appropriate way to test a method.

> And this doesn't help RubyGems. If there's three different versions of a 
> gem, one that works on Rubinius, one that works on JRuby, one that works 
> on MRI...how should it choose the right one? By checking 
> implementation-specific config information? By trying to load libraries 
> that don't work today (but might work tomorrow)? There's too much 
> complication in figuring out "which Ruby impl am I running", and adding 
> a variable to explicitly state it is a clean, simple way to do it.

I heard Rubinius can use Ruby's extension library written in
C.  Do we need different gems for Rubinius and MRI?

On Wed, Jul 30, 2008 at 6:19 AM, Tanaka Akira <akr@fsij.org> wrote:
>
> Why do you like RUBY_ENGINE over LoadError?
>

Because:

1) user can force the installation of the gem:

gem install activerecord-jdbc-adapter --platform=java even java is not
one of the platforms the implemenetation supports.

The require will work, but it will raise later then other kind of
errors that your rescue is not covering.

> If LoadError is used, it may be work on non-JRuby
> implementation.
>
> I heard Rubinius can use Ruby's extension library
> implemented in C.  I think it is difficult to use
> RUBY_ENGINE accurately.

Is not about C extensions versus non-C extensions or Jar files, is
about functionality missing and differences between platforms. I'll
mention again some weirdness of JRuby in Windows compared to Linux.
Both are RUBY_PLATFORM == 'java' but in Windows you don't have
unixsockets...

So, the only way to determine the platform for your code to run is
combine RUBY_PLATFORM + JRUBY_VERSION is being defined. Now, what
about IronRuby, or better yet IronRuby on Mono?

Anyway, just my comments, even the mswin32 versus the mingw32
"platforms" can drive you crazy.
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

Exactly.  This constant would've been infinitely helpful to a project
I was working on where we're deploying to JRuby but developing on MRI.
 It's difficult to conditionally require gems that require special
versions such as Hpricot without knowing which engine we're running
on.

--Jeremy

On Sun, Jul 27, 2008 at 10:28 PM, Charles Oliver Nutter
<charles.nutter@sun.com> wrote:
>>>
>>> language-level changes or binary compatibility issues, so as far as the
>
> to know if they should load their ObjC-based libraries.
>
> So like JRuby with Java, Rubinius with various extensions to core classes
> and a differen execution/IO/threading model, IronRuby with .NET, MagLev with
> potentially SmallTalk-based libraries...it's a perfect way to identify "hey,
> I'm on implementation X and can expect features/bugs/quirks of that
> implementation to be present."
>
> - Charlie
>
>



--
http://jeremymcanally.com/
http://entp.com/
http://omgbloglol.com

My books:
http://manning.com/mcanally/
http://humblelittlerubybook.com/ (FREE!)

Tanaka Akira wrote:
> Agreed.  It should be possible to test a method is really
> implemented without calling it.
> 
> So I implemented a way to do it.
> In [ruby-dev:34707], I implemented respond_to? returns false
> for a method which just raises NotImplementedError.
> 
> I think RUBY_ENGINE is not appropriate way to test a method.

Not a method...a feature. A method is not a feature. JRuby has an entire
Java integration subsystem. MacRuby has similar for Objective C and
IronRuby has .NET. Rubinius has custom built-in classes that can be
access for specific problems. RUBY_ENGINE describes which implementation
you're running on, so you'll know which of these features (not methods)
are likely to be available.

> I heard Rubinius can use Ruby's extension library written in
> C.  Do we need different gems for Rubinius and MRI?

Rubinius can load some extensions, but the layer that allows that is not
going to be able to make them all work (because many depend in deep MRI
internals like st.c and so on). So it's almost certain that there will
be different extensions for Rubinius in some cases.

And of course JRuby and IronRuby will never run Ruby C extensions. We
did a half implementation of Rubinius's "subtend" layer, and were able
to load simple extensions, but the performance was atrocious and the
more support we added the more we had to do bulk memory copies into and
out of VM space. It was not feasible, and eventually impossible to 
scale.

- Charlie

Hi,

On Wed, Jul 30, 2008 at 7:46 AM, Luis Lavena <luislavena@gmail.com> 
wrote:
>>
> The require will work, but it will raise later then other kind of
> errors that your rescue is not covering.

Also, what if the application to support more implementations? How
about 4? MRI, JRuby, Rubinius, IronRuby?
You'll have very messy, nested (4-level deep) requires with no
guarantees that they would work as expected.

(Not to mention that even on JRuby that gem/require won't work if user
forgot to install the gem first).

In short, unsuccessfull require doesn't mean we're not on JRuby, and
successful require doesn't mean that either. Granted, users might
figure out the current Ruby implementation one way or another, but
they will be not precise ways.


Thanks,
  --Vladimir

Vladimir Sizikov wrote:
> In short, unsuccessfull require doesn't mean we're not on JRuby, and
> successful require doesn't mean that either. Granted, users might
> figure out the current Ruby implementation one way or another, but
> they will be not precise ways.

And another reason: ideally people could eventually be able to share gem
repositories, with both JRuby and Ruby gems available. So this might not
fail with a load error, it might fail with some other error because Java
isn't present for normal Ruby.

Or we could have a single check for RUBY_ENGINE and be done with it.

- Charlie

So where do we stand on this? I'm still convinced RUBY_ENGINE is needed,
and I've been recommending folks on JRuby use it.

Vladimir Sizikov wrote:

Since this thread seemed to die out, I'll ask again:

Could RUBY_ENGINE please be added to 1.8.x and 1.9.x so users can rely
on one constant to know the implementation they're on?

Hi,

In message "Re: [ruby-core:18284] Re: RUBY_ENGINE?"
    on Thu, 14 Aug 2008 10:59:24 +0900, Charles Oliver Nutter 
<charles.nutter@sun.com> writes:

|Since this thread seemed to die out, I'll ask again:
|
|Could RUBY_ENGINE please be added to 1.8.x and 1.9.x so users can rely 
|on one constant to know the implementation they're on?

In that case, what should the value for each implementation be?

  * Ruby 1.8 ("mri" or "ruby"?)
  * Ruby 1.9 ("yarv" or "ruby"?)
  * JRuby ("jruby" perhaps)
  * MacRuby ("macrruby"?)
  * Rubinius ("rubinius" or "rbx"?)
  * IronRuby ("ironruby"?)
  * ....

              matz.

On Thu, Aug 14, 2008 at 2:22 AM, Yukihiro Matsumoto <matz@ruby-lang.org> 
wrote:
> In that case, what should the value for each implementation be?
>
>  * Ruby 1.8 ("mri" or "ruby"?)
>  * Ruby 1.9 ("yarv" or "ruby"?)

I think both of these should be "ruby", as you can find the version by
RUBY_VERSION,
But "ruby" would indicate the core's implementation.

-greg

From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org]
Sent: Wednesday, August 13, 2008 11:22 PM

> In that case, what should the value for each implementation be?

IronRuby already returns "ironruby" for RUBY_ENGINE.

Hi,

In message "Re: [ruby-core:18289] Re: RUBY_ENGINE?"
    on Thu, 14 Aug 2008 15:36:55 +0900, "Gregory Brown" 
<gregory.t.brown@gmail.com> writes:

|>  * Ruby 1.8 ("mri" or "ruby"?)
|>  * Ruby 1.9 ("yarv" or "ruby"?)
|
|I think both of these should be "ruby", as you can find the version by
|RUBY_VERSION,
|But "ruby" would indicate the core's implementation.

The point is we have different core for 1.8 and 1.9, but anyway, I
have added RUBY_ENGINE (as "ruby") constant for 1.9 now.  Let's see
how it goes.

              matz.

On Thu, Aug 14, 2008 at 1:27 AM, Yukihiro Matsumoto <matz@ruby-lang.org> 
wrote:
> |But "ruby" would indicate the core's implementation.
>
> The point is we have different core for 1.8 and 1.9, but anyway, I
> have added RUBY_ENGINE (as "ruby") constant for 1.9 now.  Let's see
> how it goes.
>

FYI, I added RUBY_ENGINE as "macruby" in my private branch.

Laurent

Yukihiro Matsumoto wrote:
> |But "ruby" would indicate the core's implementation.
> 
> The point is we have different core for 1.8 and 1.9, but anyway, I
> have added RUBY_ENGINE (as "ruby") constant for 1.9 now.  Let's see
> how it goes.

Excellent Matz, thank you very much!

I think it's ok that both 1.8 and 1.9 return RUBY_ENGINE as "ruby" since
even though they have a different interpreter (AST-based or
bytecode-based) they're still largely based on the same code and run the
same extensions. And both are the direct descendants of "standard Ruby"
where others are heavily modified versions (macruby) or entirely
different codebases (all others).

- Charlie

On Aug 13, 2008, at 23:22 , Yukihiro Matsumoto wrote:

> |on one constant to know the implementation they're on?
>
> In that case, what should the value for each implementation be?
>
>  * Ruby 1.8 ("mri" or "ruby"?)
>  * Ruby 1.9 ("yarv" or "ruby"?)
>  * JRuby ("jruby" perhaps)
>  * MacRuby ("macrruby"?)
>  * Rubinius ("rubinius" or "rbx"?)
>  * IronRuby ("ironruby"?)
>  * ....

symbols? better for case stmts / hashes etc.

(and I agree that it should be "ruby" for both 1.8 and 1.9--it is the
family that matters)