Rubyinstaller devel - Nov 2008 - Migrate to GCC as soon as possible?

Hi guys,

First of all, thanks for working on this installer which is much
appreciated. :-)
It was how I first installed Ruby for instance. :-)

But for a long-time I have also been running Ruby on Linux and left Windows
by itself since then. Every now and then I could be seen testing Ruby
on Windows though, and this is such an occasion.

Today I was testing these versions of Ruby:

ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]

jruby -v
jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java]

When building the MinGW Ruby I used git to download the rubyinstaller
scripts and ran it with rake. When it got to the Rubygems part it returned
an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or
something.
I was able to install the Rubygems by running the setup manually for it, though
I am not sure what else I missed from the remaining of the installation scripts.

To test the different Ruby versions, I ran some JRuby benchmark files with each
interpreter to make a rough comparison. JRuby came faster by a good margin,
though JRuby has different setups itself (--client, --server, -X-C)
which influence
the results. In general though, JRuby has closed the gap and generally surpassed
MRI''s performance. Second faster came the MinGW Ruby I just built. Only
in
third and last came the original OneClick installed Ruby which uses VC6 right?

You can run the benchmarks I ran and see for yourself:
http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb
http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb

They have a bunch of other benchmarks though:
http://svn.codehaus.org/jruby/trunk/jruby/bench/

JRuby could "just work" on unfriendly environments such as Windows
while
it has been a pain in the neck all these years to fully support Ruby on
Windows. To top it all, JRuby could run considerably faster than Ruby on
Windows in special.

I have barely used JRuby at all thus far, and it''s not a perfect
replacement for
Ruby just yet. For example, JRuby can have a hard time presenting more
friendly error messages which really tell what went wrong, but it''s
evolving,
improving, and it "steals" the platform infrastructure from Java so
they can focus
on other issues. Also, when testing GUI applications (GTK+), Ruby runs
instantly while JRuby with Swing can take a while longer, though they could
improve it as well. JRuby generally starts slower with more complex
applications,
is that fair to say? :-)

I came to Ruby from Java and a disillusionment with the .NET surge and the
splitting of the developers into worlds. Ruby was meant to be the third way,
but now Java and .NET more than promise to support Ruby. Also, Java and .NET
try to leave the C/C++ world behind for as much as most developers are
concerned.

As I currently see it, instead of having Ruby by itself, the future will bring
Ruby + Java and Ruby + .NET and we will have to deal with that and it will
be a nice problem to have. :-)

See an example of IronRuby:
http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx

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.

I guess Ruby on Windows will need to take advantage of the latest improvements
on compilers and whatnot to keep it competitive. If Microsoft''s C
compiler
builds faster executables it could be better to use it, though MinGW''s
GCC
could be "fast enough" and even more compatible.

It''s high-time something great happens to Ruby on Windows, other than
Java and .NET. :-)

I invite you to run some of the benchmarks found in the JRuby repository.
JRuby can be run in different ways:

# generally opts for a simpler JVM said to be the "client" one:
jruby bench_colon.rb
# found only in the JDK, this one can more aggressively try to optimize:
jruby --server bench_colon.rb
# disables the ruby to bytecode compiler because the interpreter is
fast already:
jruby --server -X-C bench_colon.rb

And compare "stuff".

I extended myself a lot in this post but I continue to be thoroughly thankful
for the work of you guys.

Cheers,
Joao

Ruby has traditionally been "slighted" on windows [1].  For whatever
reasons :)
You''ll notice that mingw is [at least for more] quite a step up in
speed from the msvc version.

That build error you described is one I ran into, too--Luis has
promised to fix it once a newer version of rubygems comes out :)

I''m also glad to hear that jruby is fast on windows--hardly anybody
has probably even tested it out :)

Another interesting test would be 1.9 versus jruby on windows:
It does build--at least it should :P [every so often the core guys
commit something that causes a build problem--hopefully they''re not
there :P ]
http://betterlogic.com/roger/?p=515

Note also that building it on mingw is easily 10x easier, using Luis''
installer, than it used to be.  Trust me.  Just trust me.

Note also that if you wanted a ''tidge'' more performance, you
could try
to use GCC 4.2.x or what not [and enable the gentoo flags :) ].  The
rubyinstaller doesn''t use it because it''s still kind of edgey,
but
apparently it is slightly faster.  So things will improve that way.

I''d be interested in running "benchmarks not from jruby"
against them all, too.

In general, though--I don''t see it as a "competition" or
"problem" to
have ruby running with a backend vm on .net or java--the nicety of
writing ruby is that [hopefully] you never have to touch code in the
lower level, so...it should just work, so which ever is faster, it
won''t hurt you to use it.  Just my $0.02.

Cheers!
-=R
[1]
http://www.rubyinside.com/is-windows-a-first-class-platform-for-ruby-823.html
On Wed, Nov 26, 2008 at 12:39 AM, Joao Pedrosa <joaopedrosa at gmail.com>
wrote:
> Hi guys,
>
> First of all, thanks for working on this installer which is much
> appreciated. :-)
> It was how I first installed Ruby for instance. :-)
>
> But for a long-time I have also been running Ruby on Linux and left Windows
> by itself since then. Every now and then I could be seen testing Ruby
> on Windows though, and this is such an occasion.
>
> Today I was testing these versions of Ruby:
>
> ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
>
> C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v
> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
>
> jruby -v
> jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java]
>
> When building the MinGW Ruby I used git to download the rubyinstaller
> scripts and ran it with rake. When it got to the Rubygems part it returned
> an error during the "ruby setup.rb [...]
c:/path/c:/doubling_path" or something.
> I was able to install the Rubygems by running the setup manually for it,
though
> I am not sure what else I missed from the remaining of the installation
scripts.
>
> To test the different Ruby versions, I ran some JRuby benchmark files with
each
> interpreter to make a rough comparison. JRuby came faster by a good margin,
> though JRuby has different setups itself (--client, --server, -X-C)
> which influence
> the results. In general though, JRuby has closed the gap and generally
surpassed
> MRI''s performance. Second faster came the MinGW Ruby I just built.
Only in
> third and last came the original OneClick installed Ruby which uses VC6
right?
>
> You can run the benchmarks I ran and see for yourself:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb
> http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb
>
> They have a bunch of other benchmarks though:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/
>
> JRuby could "just work" on unfriendly environments such as
Windows while
> it has been a pain in the neck all these years to fully support Ruby on
> Windows. To top it all, JRuby could run considerably faster than Ruby on
> Windows in special.
>
> I have barely used JRuby at all thus far, and it''s not a perfect
> replacement for
> Ruby just yet. For example, JRuby can have a hard time presenting more
> friendly error messages which really tell what went wrong, but
it''s evolving,
> improving, and it "steals" the platform infrastructure from Java
so
> they can focus
> on other issues. Also, when testing GUI applications (GTK+), Ruby runs
> instantly while JRuby with Swing can take a while longer, though they could
> improve it as well. JRuby generally starts slower with more complex
> applications,
> is that fair to say? :-)
>
> I came to Ruby from Java and a disillusionment with the .NET surge and the
> splitting of the developers into worlds. Ruby was meant to be the third
way,
> but now Java and .NET more than promise to support Ruby. Also, Java and
.NET
> try to leave the C/C++ world behind for as much as most developers are
> concerned.
>
> As I currently see it, instead of having Ruby by itself, the future will
bring
> Ruby + Java and Ruby + .NET and we will have to deal with that and it will
> be a nice problem to have. :-)
>
> See an example of IronRuby:
> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
>
> 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.
>
> I guess Ruby on Windows will need to take advantage of the latest
improvements
> on compilers and whatnot to keep it competitive. If Microsoft''s C
compiler
> builds faster executables it could be better to use it, though
MinGW''s GCC
> could be "fast enough" and even more compatible.
>
> It''s high-time something great happens to Ruby on Windows, other
than
> Java and .NET. :-)
>
> I invite you to run some of the benchmarks found in the JRuby repository.
> JRuby can be run in different ways:
>
> # generally opts for a simpler JVM said to be the "client" one:
> jruby bench_colon.rb
> # found only in the JDK, this one can more aggressively try to optimize:
> jruby --server bench_colon.rb
> # disables the ruby to bytecode compiler because the interpreter is
> fast already:
> jruby --server -X-C bench_colon.rb
>
> And compare "stuff".
>
> I extended myself a lot in this post but I continue to be thoroughly
thankful
> for the work of you guys.
>
> Cheers,
> Joao
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>


-- 
Thanks!
-=R

Hey,
> I''m also glad to hear that jruby is fast on windows--hardly
anybody
> has probably even tested it out :)
I think many JRuby users tend to use Windows as well. It''s like Java
in that regard, I would guess.
> Another interesting test would be 1.9 versus jruby on windows:
> It does build--at least it should :P [every so often the core guys
> commit something that causes a build problem--hopefully they''re
not
> there :P ]
> http://betterlogic.com/roger/?p=515
I just easily built it using VS2008 command line. Ruby 1.9 seems
promising and Ruby''s best try to keeping things competitive.
> Note also that building it on mingw is easily 10x easier, using
Luis''
> installer, than it used to be.  Trust me.  Just trust me.
It was relatively easy indeed. Although to me it works like a
"blackbox"
right now given I hardly know the installer processes. :-)
> Note also that if you wanted a ''tidge'' more performance,
you could try
> to use GCC 4.2.x or what not [and enable the gentoo flags :) ].  The
> rubyinstaller doesn''t use it because it''s still kind of
edgey, but
> apparently it is slightly faster.  So things will improve that way.
Yesterday I tried to download my own version of MinGW but it has
become a little more complicated since I last used it. I wanted to test
one of the latest versions of GCC for sure. :-)
> I''d be interested in running "benchmarks not from jruby"
against them all, too.
Me too. Eventually will do.
> In general, though--I don''t see it as a "competition" or
"problem" to
> have ruby running with a backend vm on .net or java--the nicety of
> writing ruby is that [hopefully] you never have to touch code in the
> lower level, so...it should just work, so which ever is faster, it
> won''t hurt you to use it.  Just my $0.02.
Yes. Ruby code is malleable enough to work on different interpreters with
relative little change. Albeit each interpreter has got to try to keep as much
compatibility as possible to make it more fun. :-)

Cheers,
Joao

On Wed, Nov 26, 2008 at 5:39 AM, Joao Pedrosa <joaopedrosa at gmail.com>
wrote:
> Hi guys,
>
> First of all, thanks for working on this installer which is much
> appreciated. :-)
> It was how I first installed Ruby for instance. :-)
Thanks to you and welcome! :-)
>
> But for a long-time I have also been running Ruby on Linux and left Windows
> by itself since then. Every now and then I could be seen testing Ruby
> on Windows though, and this is such an occasion.
Sometimes I go back and forth these environments too, so I know how
you must feel.
> Today I was testing these versions of Ruby:
>
> ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
>
> C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v
> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
>
> jruby -v
> jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java]
>
> When building the MinGW Ruby I used git to download the rubyinstaller
> scripts and ran it with rake. When it got to the Rubygems part it returned
> an error during the "ruby setup.rb [...]
c:/path/c:/doubling_path" or something.
> I was able to install the Rubygems by running the setup manually for it,
though
> I am not sure what else I missed from the remaining of the installation
scripts.
Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
the new scripts and some helpers to solve the issues of several
projects.

Manually installing latest version of rubygems (1.3.1) works, so
fixing the scripts will be easy.
> To test the different Ruby versions, I ran some JRuby benchmark files with
each
> interpreter to make a rough comparison. JRuby came faster by a good margin,
> though JRuby has different setups itself (--client, --server, -X-C)
> which influence
> the results. In general though, JRuby has closed the gap and generally
surpassed
> MRI''s performance. Second faster came the MinGW Ruby I just built.
Only in
> third and last came the original OneClick installed Ruby which uses VC6
right?
Yes, current One-Click Installer is based on VC6.

Is good to know VC6 build was beaten by both Jruby and MinGW build!

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?

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.
> You can run the benchmarks I ran and see for yourself:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb
> http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb
>
> They have a bunch of other benchmarks though:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/
Cool, I''ll check them out later if time allows.
> JRuby could "just work" on unfriendly environments such as
Windows while
> it has been a pain in the neck all these years to fully support Ruby on
> Windows. To top it all, JRuby could run considerably faster than Ruby on
> Windows in special.
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

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.

JRuby, like IronRuby adds another layer of compatibility concerns both
developers and users should take in consideration.
> I have barely used JRuby at all thus far, and it''s not a perfect
> replacement for
> Ruby just yet. For example, JRuby can have a hard time presenting more
> friendly error messages which really tell what went wrong, but
it''s evolving,
> improving, and it "steals" the platform infrastructure from Java
so
> they can focus
> on other issues. Also, when testing GUI applications (GTK+), Ruby runs
> instantly while JRuby with Swing can take a while longer, though they could
> improve it as well. JRuby generally starts slower with more complex
> applications,
> is that fair to say? :-)
Yes, JRuby was it''s own nice looking attributes, neither me or anyone
can deny that some of those are good looking.
> I came to Ruby from Java and a disillusionment with the .NET surge and the
> splitting of the developers into worlds. Ruby was meant to be the third
way,
> but now Java and .NET more than promise to support Ruby. Also, Java and
.NET
> try to leave the C/C++ world behind for as much as most developers are
> concerned.
>
> As I currently see it, instead of having Ruby by itself, the future will
bring
> Ruby + Java and Ruby + .NET and we will have to deal with that and it will
> be a nice problem to have. :-)
>
Don''t forget to include Rubinius in the mix. :-D

Yet still, there will be flavors of Ruby implementations for all the
backgrounds, the ones coming form Java, and the ones coming from .NET
> See an example of IronRuby:
> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
>
> 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
MRI.

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
releases".

Even more, I will not doubt on creating a One-Click JRuby/IronRuby
Installer in the future, only if people is interested.
> I guess Ruby on Windows will need to take advantage of the latest
improvements
> on compilers and whatnot to keep it competitive. If Microsoft''s C
compiler
> builds faster executables it could be better to use it, though
MinGW''s GCC
> could be "fast enough" and even more compatible.
>
The VC8/9 path has been discussed previously in the list under which I
expressed both my points and concerns. As you said, MinGW will provide
more value to the equation.
> It''s high-time something great happens to Ruby on Windows, other
than
> Java and .NET. :-)
>
> I invite you to run some of the benchmarks found in the JRuby repository.
> JRuby can be run in different ways:
>
I''ll as soon time allows, and maybe drop some post in my blog.
> # generally opts for a simpler JVM said to be the "client" one:
> jruby bench_colon.rb
> # found only in the JDK, this one can more aggressively try to optimize:
> jruby --server bench_colon.rb
> # disables the ruby to bytecode compiler because the interpreter is
> fast already:
> jruby --server -X-C bench_colon.rb
>
> And compare "stuff".
>
> I extended myself a lot in this post but I continue to be thoroughly
thankful
> for the work of you guys.
Thanks to you man for putting together all this, exposing issues and
your point of view about One-Click Installer and current situation.

I believe that even JRuby or IronRuby became good candidates for usage
on Windows, there is still room for MRI (and maybe Rubinius?) :-D
> Cheers,
> Joao
Cheers and have a nice week!
-- 
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

I agree--the reason I stick with MRI (despite its shortcomings--GC,
speed, etc.)  is that it is the "de facto standard" and, like it or
not, used by most rubyists.
Cheers!
-=R

On Wed, Nov 26, 2008 at 2:34 PM, Luis Lavena <luislavena at gmail.com>
wrote:
> On Wed, Nov 26, 2008 at 5:39 AM, Joao Pedrosa <joaopedrosa at
gmail.com> wrote:
>> Hi guys,
>>
>> First of all, thanks for working on this installer which is much
>> appreciated. :-)
>> It was how I first installed Ruby for instance. :-)
>
> Thanks to you and welcome! :-)
>
>>
>> But for a long-time I have also been running Ruby on Linux and left
Windows
>> by itself since then. Every now and then I could be seen testing Ruby
>> on Windows though, and this is such an occasion.
>
> Sometimes I go back and forth these environments too, so I know how
> you must feel.
>
>> Today I was testing these versions of Ruby:
>>
>> ruby -v
>> ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
>>
>> C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v
>> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
>>
>> jruby -v
>> jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java]
>>
>> When building the MinGW Ruby I used git to download the rubyinstaller
>> scripts and ran it with rake. When it got to the Rubygems part it
returned
>> an error during the "ruby setup.rb [...]
c:/path/c:/doubling_path" or something.
>> I was able to install the Rubygems by running the setup manually for
it, though
>> I am not sure what else I missed from the remaining of the installation
scripts.
>
> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
> the new scripts and some helpers to solve the issues of several
> projects.
>
> Manually installing latest version of rubygems (1.3.1) works, so
> fixing the scripts will be easy.
>
>> To test the different Ruby versions, I ran some JRuby benchmark files
with each
>> interpreter to make a rough comparison. JRuby came faster by a good
margin,
>> though JRuby has different setups itself (--client, --server, -X-C)
>> which influence
>> the results. In general though, JRuby has closed the gap and generally
surpassed
>> MRI''s performance. Second faster came the MinGW Ruby I just
built. Only in
>> third and last came the original OneClick installed Ruby which uses VC6
right?
>
> Yes, current One-Click Installer is based on VC6.
>
> Is good to know VC6 build was beaten by both Jruby and MinGW build!
>
> 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?
>
> 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.
>
>> You can run the benchmarks I ran and see for yourself:
>> http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb
>> http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb
>>
>> They have a bunch of other benchmarks though:
>> http://svn.codehaus.org/jruby/trunk/jruby/bench/
>
> Cool, I''ll check them out later if time allows.
>
>> JRuby could "just work" on unfriendly environments such as
Windows while
>> it has been a pain in the neck all these years to fully support Ruby on
>> Windows. To top it all, JRuby could run considerably faster than Ruby
on
>> Windows in special.
>
> 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
>
> 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.
>
> JRuby, like IronRuby adds another layer of compatibility concerns both
> developers and users should take in consideration.
>
>> I have barely used JRuby at all thus far, and it''s not a
perfect
>> replacement for
>> Ruby just yet. For example, JRuby can have a hard time presenting more
>> friendly error messages which really tell what went wrong, but
it''s evolving,
>> improving, and it "steals" the platform infrastructure from
Java so
>> they can focus
>> on other issues. Also, when testing GUI applications (GTK+), Ruby runs
>> instantly while JRuby with Swing can take a while longer, though they
could
>> improve it as well. JRuby generally starts slower with more complex
>> applications,
>> is that fair to say? :-)
>
> Yes, JRuby was it''s own nice looking attributes, neither me or
anyone
> can deny that some of those are good looking.
>
>> I came to Ruby from Java and a disillusionment with the .NET surge and
the
>> splitting of the developers into worlds. Ruby was meant to be the third
way,
>> but now Java and .NET more than promise to support Ruby. Also, Java and
.NET
>> try to leave the C/C++ world behind for as much as most developers are
>> concerned.
>>
>> As I currently see it, instead of having Ruby by itself, the future
will bring
>> Ruby + Java and Ruby + .NET and we will have to deal with that and it
will
>> be a nice problem to have. :-)
>>
>
> Don''t forget to include Rubinius in the mix. :-D
>
> Yet still, there will be flavors of Ruby implementations for all the
> backgrounds, the ones coming form Java, and the ones coming from .NET
>
>> See an example of IronRuby:
>> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
>>
>> 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
> MRI.
>
> 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
> releases".
>
> Even more, I will not doubt on creating a One-Click JRuby/IronRuby
> Installer in the future, only if people is interested.
>
>> I guess Ruby on Windows will need to take advantage of the latest
improvements
>> on compilers and whatnot to keep it competitive. If
Microsoft''s C compiler
>> builds faster executables it could be better to use it, though
MinGW''s GCC
>> could be "fast enough" and even more compatible.
>>
>
> The VC8/9 path has been discussed previously in the list under which I
> expressed both my points and concerns. As you said, MinGW will provide
> more value to the equation.
>
>> It''s high-time something great happens to Ruby on Windows,
other than
>> Java and .NET. :-)
>>
>> I invite you to run some of the benchmarks found in the JRuby
repository.
>> JRuby can be run in different ways:
>>
>
> I''ll as soon time allows, and maybe drop some post in my blog.
>
>> # generally opts for a simpler JVM said to be the "client"
one:
>> jruby bench_colon.rb
>> # found only in the JDK, this one can more aggressively try to
optimize:
>> jruby --server bench_colon.rb
>> # disables the ruby to bytecode compiler because the interpreter is
>> fast already:
>> jruby --server -X-C bench_colon.rb
>>
>> And compare "stuff".
>>
>> I extended myself a lot in this post but I continue to be thoroughly
thankful
>> for the work of you guys.
>
> Thanks to you man for putting together all this, exposing issues and
> your point of view about One-Click Installer and current situation.
>
> I believe that even JRuby or IronRuby became good candidates for usage
> on Windows, there is still room for MRI (and maybe Rubinius?) :-D
>
>> Cheers,
>> Joao
>
> Cheers and have a nice week!
> --
> 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
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>


-- 
Thanks!
-=R

Hi,
> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
> the new scripts and some helpers to solve the issues of several
> projects.
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
contributor''s skills?

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
full power
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
hotspot VM.

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
pay off.

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
True. :-)

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:
>> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
>>
>> 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
> MRI.
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
way. :-)
> 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
> releases".
>
> 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. :-)

Thanks!

Cheers,
Joao

On Sun, Nov 30, 2008 at 5:10 AM, Joao Pedrosa <joaopedrosa at gmail.com>
wrote:
>  Hi,
>
>> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
>> the new scripts and some helpers to solve the issues of several
>> projects.
>
> 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
> contributor''s skills?
Hmn,

Indeed the project started as pure-ruby driving the ruby build
process, which included download of source files and even unpacking
those without external dependencies, but not as custom scripts.
Instead is driven by Rake.

AFAIK Rake is the best tool for the job. Other projects created a
specific DSL that generates the needed Rake tasks. Reinventing the
wheel is out of question.

What we found is that using current implementation, building multiple
versions of ruby or the tools Ruby depends on (which are more than 10)
get''s complicated and messy.

You can confirm this statement looking at the recipes on github repository:

http://www.github.com/luislavena/rubyinstaller

The DSL been working on add a better designed layer on top of it,
taking in consideration the issues we found with current one.
> 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.
One of the things that made me decide step back and look at this new
DSL on top of Rake is lower the entry point to users.

The new structure encourage a event-driven concept of tasks, what
should happen before of after a operation.

http://gist.github.com/19707

If you compare that with current implementation, will see is much more clear.

http://github.com/luislavena/rubyinstaller/tree/master/recipes/dependencies/openssl.rake

Just an example, will work on complete the DSL implementation now that
rake-compiler is usable:

http://github.com/luislavena/rake-compiler
> There is already RubyGems, setup.rb... And numerous nuisances when
> trying to make things install in the right ways... By appealing to the
> full power
> of Ruby it could prove more than useful.
Oh, we are not reinventing the wheel on this. The objective is have
Ruby and their dependencies built properly and in a stable way, so we
can run the tests and trust the things we build, in a more automated
fashion of current implementation.

RubyGems gem installation will be the official way to install stuff on
new installer, the only thing is that rubygems needs setup.rb to
install itself ;-)

Maybe I should put a manifesto about this? I thought the wiki pretty
well exposed our goals:

http://rubyinstaller.rubyforge.org/wiki/wiki.pl?Roadmap
> 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".
I agree, but in the land of Windows users, there is no alternative for us.

Current installer scripts (installer2) is a single file that drives
the whole show.

http://rubyinstaller.rubyforge.org/svn/trunk/installer-win2/rakefile.rb

It not only bundles everything under the sun, but there is no
automated way to verify it. Moreover, it depends on a external build
of ruby (VC6) which we don''t have control over, and thus require
manual steps that make generating, testing and packaging new releases
a burden.

When we reached that point, the work on the new set of scripts proven
to be more easy:

Pro:
Based on a free compiler, we have all the control over the build process
Everything well detailed, presenting the dependency chain to the user
(ruby depends on openssl and readline).
Focusing on the core, not the 150 gems bundled on previous version

Con:
We need to build everything, which some projects don''t make it easy
(yeah, that goes for GNU projects)
The "detailed" recipes couldn''t scale to handle more than one
time of
version (check the hooks for CHECKOUT and will see the dilemma).

Based on those things, I started to explore how to solve that without
exposing the dirty details and keep things under control and
standardized.

The new DSL tries to solve that, yet still is not ready to replace
current implementation but will be more easy to jump in for new users.
After all, is a descriptive way of detail steps and things that should
happen after and before each of the actions by default a version will
perform.

1) download code
2) unpack it
3) execute the configure script
4) make
5) make install

Those steps has been present in most of every tool and even linux
distro under the sun... Why not rely on that?
> Take that as just an idea.
>
Point taken, but please review my comments again and see if it still apply.

I''m very passionate about what I do, so all these things can be a bit
biased.

One thing that I noticed was a bad choice is go with Windows Installer
(MSI) technology. While is worth it, rely on WiX and XML to build the
components is too complex to be easily maintained.
>> 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
> hotspot VM.
>
> 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
> pay off.
>
> JRuby could still enjoy some tunning to achieve greater performances,
> and a future JVM version could further help it achieve that. :-)
>
I cannot say too much about JRuby, I''m not even a user of it.
>> 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.
No debug information impacts on size, while O2 compile parameter too.
O3 and other architecture flags can enable generation of faster code.
>> 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
>
> True. :-)
>
> 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.
>
Well, work on ruby-ffi can now be started, but will happen after
One-Click Installer, cannot commit free time to it when upcoming 1.9.1
release is close :-)
>> 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. :-)
Is not only about speed, while could be a point. The main goal is
reduce the burden across platforms.

For example, I was really annoyed by "gem.bat" vs "gem" when
doing
system calls... we got that fixed into Ruby, so no more conditionals
to take care:

http://blog.mmediasys.com/2008/04/24/contributions-speedup-and-less-quirks-for-us/

Check less quirk for us section.
>
>> 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.
>
vaporware or not, FFI stuff came out from it :-)

Other concepts like mvm (multi vm branch in ruby source) where
inspired by Rubinius mvm actors and inter-vm communication.
>>> See an example of IronRuby:
>>>
http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
>>>
>>> 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
>> MRI.
>
> 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
> way. :-)
>
>> 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
>> releases".
>>
>> 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. :-)
That''s one of the things we are working on, but not yet for prime time
;-)

Stay tuned :-)
>
> Thanks!
>
Thanks to you Joao!

-- 
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 Mon, Dec 1, 2008 at 10:02 AM, Roger Pack <rogerpack2005 at gmail.com>
wrote:
> I''ve heard some nice things about the nsys (nullsoft?) packager,
> though I''ve never used it.
Current One-Click Installer is built with NSIS.

If you take a look to the build scripts:

http://rubyinstaller.rubyforge.org/svn/trunk/installer-win2/NSIS/

IMHO I guess those comments came from people that feels comfortable
with non-structured and primitive scripting functionality.

One of the problems with current installer is that wipe out everything
during uninstall. That''s because it lacks a manifest of installed
files to only remove those.

InnoSetup is more intelligent in that front, but I need to explore a bit more.

-- 
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