[Rubyinstaller-devel] Migrate to GCC as soon as possible?
joaopedrosa at gmail.com
Sun Nov 30 02:10:05 EST 2008
> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
> the new scripts and some helpers to solve the issues of several
BTW. Being the Ruby Installer a rather special kind of software
building/installing, would not it be better to keep everything in Ruby
itself so it could more easily be understood by everyday's programmer
than to use Rake to its fullest which might be a little beyond potential
It's not as if there is lots of people willing to even try it, let
alone to put into
it the energy required to understand it. I know that Rake doesn't look
that scary, and it might even be handy... I just fear that in the long run it
might be a waste and make the installer harder to integrate with or understand.
There is already RubyGems, setup.rb... And numerous nuisances when
trying to make things install in the right ways... By appealing to the
of Ruby it could prove more than useful.
In the lines of "beware of premature optimization", I would say to
"beware of premature frameworkzation" in this case. Even though the Ruby
Installer would have to adopt its own framework structure for sure. My worry
is that it has to handle with external issues all the time, or in the words
of Linux Distributions, with "upstream".
Take that as just an idea.
> Is good to know VC6 build was beaten by both Jruby and MinGW build!
I have some more data to corroborate. More in another email.
> Every time I test jruby I don't enable any of these flags since
> "average joe ruby" will need to dig into the documentation or some
> sites to get info from them.
> In any case, these should be enabled by default, right? These are safe
> to be used by average joe?
Yes, JRuby's flags like "--server", "-X-C" can be safely used by users,
they are only required to have the JDK to be able to choose.
Also, the JDK seems to be able to adopt one or another internal
VM automatically if the computer seems adequate, as in a server
machine with plenty of RAM and multiple CPUs.
The "-X-C" works more as a testing facility to disable the ruby to bytecode
compiler. The important flag is "--server" because it enables the
ruby to bytecode compiler and uses the more performance-seeking
In single-run algorithms, JRuby should work well enough without the
need to use such flags. It's only if you are running longer-running
algorithms or server services that using the "--server" flag might
JRuby could still enjoy some tunning to achieve greater performances,
and a future JVM version could further help it achieve that. :-)
> For example, MinGW version is built with zero flag optimization, and
> it's even including debug information (-g) to ease the debug process
> while developing the package.
I managed to disable the "-g" flag during my most recent tests and it
didn't seem to significantly impact the performance here.
> The thing is that JRuby requires several things:
> JRE for running it.
> JDK for extending it from Java.
> Also with it's drawbacks:
> Has no native support for extensions, so Hpricot, nokogiri,
> RubyInline, ParseTree and many others end with problems.
> Pretty much current Ruby for Windows situation, anyway :-D
Java has had this indifference to native code and it is one of the things
JRuby seems intent to change on it. For instance, JRuby seems to be
making use of FFI which enables access to C.
> The dependency in a 12 years old compiler (VC6) has made the
> development and compilation of gems on Windows a real problem.
> The goal of using MinGW is not beat VC6 speed (which is a desire) but
> instead ease the integration path between platforms.
As far as I have experienced it, MinGW seems to be competitive enough
with VC for Ruby in terms of producing Ruby interpreters that are fast. Although
I don't have a thorough study on that at all, so take it with a grain
of salt. :-)
> JRuby, like IronRuby adds another layer of compatibility concerns both
> developers and users should take in consideration.
JRuby and IronRuby will appeal to new users who might not have given Ruby
a try otherwise. Also, they provide for different deployment opportunities,
and in doing so, might steal pure Ruby users. :-)
> Don't forget to include Rubinius in the mix. :-D
Rubinius is more vaporware than the others. But I have it as a git repository
mirror alongside the other Ruby implementations to keep an eye on it.
>> See an example of IronRuby:
>> What worries me is Ruby having its ass kicked by these other implementations
>> mainly on Windows. I personally think it's just easier to run JRuby on Windows
>> and in the name of reaching a consensus, JRuby could win as my preferred
>> platform, at least until Microsoft adopts the GNU tools or .NET + Mono
>> with IronRuby give Java and JRuby something to worry about.
> In some way I agree with your statement, but I don't feel in that way.
> As I mentioned previously, neither JRuby or IronRuby will be able to
> work with a huge number of gems that require native extensions.
> In case there is no binding for the library neither in Java or dotNet,
> then the users should decide for other libraries or switch back to
In the case of both Java and .NET, using Ruby as a frontend, it
becomes even less than a deal to create wrappers in Ruby for
the libraries in those languages than it has been in Ruby with C
and C++. It's just a question of making Ruby scale to handle
potentially thousands of files in those platforms in a fast enough
> The goal of One-Click Installer is ease the path, integrating GNU
> tools and documenting the whole process which has been, until now,
> close managed by the guys at garbagecollect for their "binary
> Even more, I will not doubt on creating a One-Click JRuby/IronRuby
> Installer in the future, only if people is interested.
I figure it would have been important for the Ruby Installer to support
even the development versions of Ruby so it could become a reference
and in doing so evolve beyond imagination. :-)
More information about the Rubyinstaller-devel