Forum: Ruby Proposing: A new Ruby Windows installer

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3b01c9de96cf1f45cedcb210ab6cbe40?d=identicon&s=25 Enterprise Astronaut (Guest)
on 2006-05-23 20:39
I understand projects like the Ruby Installer for Windows exists, but
what I'm wondering is:

Why not have AllInOneRuby with gems embedded into it call a gem that has
the Ruby bits and a local copy of Ruby and then follow up with Gems.
From there your home free, correct?  You could even just to get going
have the AllInOneRuby installer simply do a wget and pull down the Ruby
bits and put them into a folder and set the path.  Eventually it would
seem though pulling down the actual Ruby bits in a gem is the "Ruby" way
to do this.

The Ruby Windows Installer seems to lag behind the general releases.  It
would seem the senario I just described would be more up to date.  The
Python guys have their installers down to s science now, it seems like
Ruby is lagging a bit here (the Windows side of it anyway).

Just shooting ideas around so don't shoot the messenger.

- The Enterprise Astronaut
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 20:47
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
> I understand projects like the Ruby Installer for Windows exists, but
> what I'm wondering is:
>
> Why not have AllInOneRuby with gems embedded into it call a gem that has
> the Ruby bits and a local copy of Ruby and then follow up with Gems.
> From there your home free, correct?  You could even just to get going
> have the AllInOneRuby installer simply do a wget and pull down the Ruby
> bits and put them into a folder and set the path.  Eventually it would
> seem though pulling down the actual Ruby bits in a gem is the "Ruby" way
> to do this.

Because it'd be a waste. Better would be to have people actually
volunteer to help Curt keep the release up to date.

-austin
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-23 20:55
(Received via mailing list)
The latest installer will probably be the last time there will be this
much lag. Curt decided to redesign the installer so that subsequent
releases will be much faster. That is why things took so long. Plus he
has been extremely busy.

I recently have been helping him and am now very familiar with the
installer as well as NSIS which the installer is written with. When
the next version of Ruby is released I'll be sure to help Curt if he
needs it to get the installer out quickly.

Ryan
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-05-23 21:26
(Received via mailing list)
Austin Ziegler wrote:
>> seem though pulling down the actual Ruby bits in a gem is the "Ruby" way
>> to do this.
>
>
> Because it'd be a waste. Better would be to have people actually
> volunteer to help Curt keep the release up to date.

Or maybe not, but in any event such a proposal needs to be matched with
at least some proof-of-concept code.  It's one thing to say, "Wouldn't
it be nice if ... ?", quite another to put your money (so to speak)
where your mouth is.

At the end of the day all these ideas mean people volunteering time and
effort.

(Thanks, Curt!)


--
James Britt

"Simplicity of the language  is not what matters, but
simplicity of use."


  - Richard A. O'Keefe in squeak-dev mailing list
3b01c9de96cf1f45cedcb210ab6cbe40?d=identicon&s=25 Enterprise Astronaut (Guest)
on 2006-05-23 21:30
Austin Ziegler wrote:
>
> Because it'd be a waste. Better would be to have people actually
> volunteer to help Curt keep the release up to date.
>

Why would it be a waste?  A lot of time seems to be spent getting
FreeRide, SciTe, etc. all bundled up.  That would be gone.  I'm talking
about just putting Ruby on a Win32 box quick and easily via gems.  No
need for an installer at all.  Run the EXE and it always grabs the
latest gem.  Seems like a lot less maintenance and heartache than the
way its being done currently.
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-23 21:42
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
>
> Why would it be a waste?  A lot of time seems to be spent getting
> FreeRide, SciTe, etc. all bundled up.  That would be gone.  I'm talking
> about just putting Ruby on a Win32 box quick and easily via gems.  No
> need for an installer at all.  Run the EXE and it always grabs the
> latest gem.  Seems like a lot less maintenance and heartache than the
> way its being done currently.

I'm telling you from personal experience that it isn't all that hard
to bundle this stuff up, now that Curt has put the work into it that
he has. I came from knowing nothing about the installer (besides
having installed it myself) to be fixing bugs on it within a day. Of
course I have more experience with installers and Ruby than other
people, but I still think any competent developer could get up to
speed pretty quick.

But as James says, the best way to show us what you are talking about
is to put your money where your mouth is and implement it. Everything
you need for it is available online.

Ryan
C475cffda1800fbc3f3af17bc10c220f?d=identicon&s=25 Curt Hibbs (Guest)
on 2006-05-23 23:01
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:

> to do this.
>
> The Ruby Windows Installer seems to lag behind the general releases.  It
> would seem the senario I just described would be more up to date.  The
> Python guys have their installers down to s science now, it seems like
> Ruby is lagging a bit here (the Windows side of it anyway).


Ryan Leavengood already beat me to answering this, but I thought I
couldn't
hurt to repeat it.

The lag this time around is an anomaly. The 1.8.2 release of the
one-click
installer, for example, was out within a week of the ruby release. But
there
were a number of problems with the way it was built that was making it
harder to be timely.

So, as Ryan pointed out, I completely rewrote the build system with the
goal
of reducing the turnaround time. Withe the new build system it should be
possible to reduce that lag time to a few days.

Also as Austin pointed out, it would be much better to join the
one-click
installer team. I have been asking for help repeatedly over the years
without much response. So far, only Ryan Leavengood and Shashank Date
have
helped. There's a lot that could be done, but without more help, the I
have
to keep the scope limited.

I like the idea of providing the one-click Ruby distro as a zip file (in
addition to a traditional installer). In fact, this is the way that
Instant
Rails uses the one-click ruby installer.

Curt

PS
   Pulling down Ruby in a gem would be a problem -- a chicken and egg
problem -- as RubyGems needs Ruby to execute, and needs an existing Ruby
installation in which to place the gems that it installs.
3b01c9de96cf1f45cedcb210ab6cbe40?d=identicon&s=25 Enterprise Astronaut (Guest)
on 2006-05-23 23:30
Curt Hibbs wrote:
> installer team. I have been asking for help repeatedly over the years
> without much response. So far, only Ryan Leavengood and Shashank Date
> have
> helped.

Well, maybe this is the real problem with the Ruby community then?
Asking for assistance over a number of years to get help on an installer
package that I'm sure thousands of people, companies, etc. use daily and
coming back with mostly deaf echos is not ideal.  This installer is a
fundamental piece of Ruby being accepted by a larger audience (sorry but
Windows is still the dominant platform out there).  I know a lot of
developers/companies that unless they get a timely pretty installer
package they won't bother using it or allow it on a server.  (I hear the
argument already "well we don't want those types of developers
anyway"... Don't we?  Do we want critical mass or be a niche language?)

The point of my post was to eliminate the manual work that has to go
into a Ruby installer.  Make it a lot more automated, flick a switch and
walk away.  Even under ideal situations the Ruby Windows Installer is at
least a few days/weeks turn around time.  Right now the 1.84 release is
going on 6 months.  This is the reality right now.  The release of a
Ruby installer should not be based on someone's agenda, it should be an
automated process.  I appreciate what the team does and the endless work
they put into it but at some point the Ruby community will need to
mature in this regard.

From a company's perspective I have a lot better chance of having this
installed on a server based simply off of the organized, tidy webpage:
http://www.python.org/download/releases/2.4.3/
All the releases synced up, all the builds ready for download from one
location.  Nice and easy.  When I look at the Ruby download site I see a
mis-mash of info and links leading off to other sites- it looks
unprofessional at best.  Again, I'm looking at this from a company's
eyes.  First impressions mean a lot.

-The Enterprise Astronaut
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-05-23 23:45
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
> coming back with mostly deaf echos is not ideal.  This installer is a
> least a few days/weeks turn around time.  Right now the 1.84 release is
> location.  Nice and easy.  When I look at the Ruby download site I see a
> mis-mash of info and links leading off to other sites- it looks
> unprofessional at best.  Again, I'm looking at this from a company's
> eyes.  First impressions mean a lot.


Actually the  ruby core team releases a minimal install of Ruby almost
in
sync with the normal releases.  The problem is that it doesn't include
all
of the extensions, and win32 specfic things that people EXPECT from the
installer.  The problem is NOT with building ruby itself, but all of the
expected extensions.  These take time to be brought up to the new
version,
compiled, and tested, there isn't much you can do to automate this
process
any more than it currently is.  But if you have good ideas, you should
definitely be posing these questions to the one-click-installer mailing
list, and developers.

Also you seem to be a bit confused.  The One-Click-Installer is a
community
provided package, NOT something provided by the core ruby team.  The
core
ruby team DOES provide a minimal install (or at least used to).  This is
different than the python package you mentioned above.

And most importantly of all, and it's been stated many times this week
alone, ideas are interesting, discussion is helpful, but code is what
gets
things done.  If you see a need, and think you can fill it, then by all
means provide the code.  But suggesting, or telling others to solve
problems
only serves to annoy those that are currently working on those problems.

-The Enterprise Astronaut
Eeba234182bcbd7faed9ff52e233394d?d=identicon&s=25 Douglas Livingstone (Guest)
on 2006-05-23 23:48
(Received via mailing list)
2006/5/23, Enterprise Astronaut <enterpriseastro@enterprise.ch>:
>
> When I look at the Ruby download site I see a
> mis-mash of info and links leading off to other sites- it looks
> unprofessional at best.

There was a nice redesign with some momenutum about it a while back,
but it seems to have gotten lost somewhere :-(

http://redhanded.hobix.com/redesign2005/

If there's any help needed bashing out HTML for the design[1] I'm more
than happy to help out, though I'm worried it's gotten tangled up over
some non-technical issues...

Douglas

[1] http://redhanded.hobix.com/redesign2005/images/joh...
3b01c9de96cf1f45cedcb210ab6cbe40?d=identicon&s=25 Enterprise Astronaut (Guest)
on 2006-05-23 23:53
Douglas Livingstone wrote:
> There was a nice redesign with some momenutum about it a while back,
> but it seems to have gotten lost somewhere :-(
>
> http://redhanded.hobix.com/redesign2005/
>

Those looks really good.  Professional.

- The Enterprise Astronaut
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-05-23 23:58
(Received via mailing list)
Enterprise Astronaut wrote:

>
>
> Well, maybe this is the real problem with the Ruby community then?

You are the community.

Among others, of course.


> Asking for assistance over a number of years to get help on an installer
> package that I'm sure thousands of people, companies, etc. use daily and
> coming back with mostly deaf echos is not ideal.  This installer is a
> fundamental piece of Ruby being accepted by a larger audience (sorry but
> Windows is still the dominant platform out there).  I know a lot of
> developers/companies that unless they get a timely pretty installer
> package they won't bother using it or allow it on a server.  (I hear the
> argument already "well we don't want those types of developers
> anyway"... Don't we?  Do we want critical mass or be a niche language?)

I want Ruby.  What other people do or don't think of Ruby is not a big
issue for me. (Well, there are some exceptions on this list.)

>
> The point of my post was to eliminate the manual work that has to go
> into a Ruby installer.  Make it a lot more automated, flick a switch and
> walk away.  Even under ideal situations the Ruby Windows Installer is at
> least a few days/weeks turn around time.  Right now the 1.84 release is
> going on 6 months.  This is the reality right now.  The release of a
> Ruby installer should not be based on someone's agenda, it should be an
> automated process.  I appreciate what the team does and the endless work
> they put into it but at some point the Ruby community will need to
> mature in this regard.

Does this mean you are offering to help Curt?  Because posts don't
eliminate manual work.  (Nor, for that matter, does pulling the maturity
card.)

>
>>From a company's perspective I have a lot better chance of having this
> installed on a server based simply off of the organized, tidy webpage:
> http://www.python.org/download/releases/2.4.3/


Interesting. A company picking technology based on Web page design and
layout.  And these are the people whose opinions should influence Ruby
packaging?

The list has seen a repeated threads of the form, "If the Ruby doesn't
offer [this|that|other_thing], then it won't be accepted by
[BigCo|Mainstream|TheEnterprise]"

It's unpersuasive.


Code, on the other hand ...


:)


--
James Britt

"Blanket statements are over-rated"
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-24 00:01
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
> Well, maybe this is the real problem with the Ruby community then?

What, that we're overworked and haven't yet gotten someone to bankroll
our efforts?

> The point of my post was to eliminate the manual work that has to go
> into a Ruby installer.  Make it a lot more automated, flick a switch
> and walk away.  Even under ideal situations the Ruby Windows Installer
> is at least a few days/weeks turn around time.  Right now the 1.84
> release is going on 6 months.  This is the reality right now.  The
> release of a Ruby installer should not be based on someone's agenda,
> it should be an automated process.  I appreciate what the team does
> and the endless work they put into it but at some point the Ruby
> community will need to mature in this regard.

So? It's shifting the installer base. That doesn't happen overnight,
especially when *both* people on the team are overworked. I've also been
exploring an alternative that will make it much easier to build from
scratch and automate *everything* about the installer.

I've had exactly zero hours to work on it since January, because of my
day job.

That's why I'm saying "DO SOMETHING" instead of proposing something that
is probably not going to help at all.

-austin
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-24 00:07
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
> fundamental piece of Ruby being accepted by a larger audience (sorry but
> Windows is still the dominant platform out there).  I know a lot of
> developers/companies that unless they get a timely pretty installer
> package they won't bother using it or allow it on a server.  (I hear the
> argument already "well we don't want those types of developers
> anyway"... Don't we?  Do we want critical mass or be a niche language?)

I didn't know help was needed here, if there's something I can do, I
volunteer. Professionally, I am a WIndows and embedded software
developer. Perhaps there's something I can do.

> The point of my post was to eliminate the manual work that has to go
> into a Ruby installer.  Make it a lot more automated, flick a switch and
> walk away.  Even under ideal situations the Ruby Windows Installer is at
> least a few days/weeks turn around time.  Right now the 1.84 release is
> going on 6 months.  This is the reality right now.  The release of a
> Ruby installer should not be based on someone's agenda, it should be an
> automated process.  I appreciate what the team does and the endless work
> they put into it but at some point the Ruby community will need to
> mature in this regard.

You are part of the community right? Are you going to help? Few of us
get paid for Ruby projects so we have to do these things in our spare
time. Who will sacrifice to help more people get the Ruby joy?

> From a company's perspective I have a lot better chance of having this
> installed on a server based simply off of the organized, tidy webpage:
> http://www.python.org/download/releases/2.4.3/
> All the releases synced up, all the builds ready for download from one
> location.  Nice and easy.  When I look at the Ruby download site I see a
> mis-mash of info and links leading off to other sites- it looks
> unprofessional at best.  Again, I'm looking at this from a company's
> eyes.  First impressions mean a lot.

In all the eyes of the people who love Ruby, it's the greatest
langauge ever. Like most open source projects it seems that the makers
and maintainers of Ruby etc. have no agenda other than to make
something great for themselves to use. A lot of people assume
everybody wants Ruby to be "prime time" or to appeal to some company
or some greater body of developers so it doesn't die out or fade away
- but I don't think that's true. If you want your company to like
Ruby, put in the effort to make it appeal to your company. Perhaps you
can help with the mish-mash. Remeber that your goal of making Ruby
"professional" isn't necessarily the goal of the community.

The important thing is that you can only complain about lack of
community support if you yourself are in there helping!
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-05-24 00:23
(Received via mailing list)
On 5/23/06, Enterprise Astronaut <enterpriseastro@enterprise.ch> wrote:
> Curt Hibbs wrote:
> > installer team. I have been asking for help repeatedly over the years
> > without much response. So far, only Ryan Leavengood and Shashank Date
> > have
> > helped.
>
> Well, maybe this is the real problem with the Ruby community then?
> Asking for assistance over a number of years to get help on an installer
> package that I'm sure thousands of people, companies, etc. use daily and
> coming back with mostly deaf echos is not ideal.

I think the problem is far more one of the 'Windows users community'.

Not many windows users know how to compile files, or have experience
with building an installer.  Add to that, having the time, ability,
willingness to help, etc, and the group keeps getting smaller.

I do agree that it would be nice if more people helped, and I'm sure
as more windows users start using Ruby, more people (with the required
skills) will help.

Personally, I'll look into NSIS, and see how much I can learn about
it, but even if I can pick it up, it's more of a time crunch issue for
me these days.  Then there's the fact that I don't _need_ the most
recent release, and since I'm not paying Curt, Ryan, or Shashank to
produce one, I'm fine with waiting for it.

> This installer is a
> fundamental piece of Ruby being accepted by a larger audience (sorry but
> Windows is still the dominant platform out there).  I know a lot of
> developers/companies that unless they get a timely pretty installer
> package they won't bother using it or allow it on a server.  (I hear the
> argument already "well we don't want those types of developers
> anyway"... Don't we?  Do we want critical mass or be a niche language?)

Indeed, it is accepted by a large audience.  Probably because it works
well, and is updated frequently enough for most of us.

This is at least the third time in about a week that somebody has
presumed that 'we want critical mass' (or 'enterprise', or whatever).
Well, I can't speak for 'we', but I don't particularly care how many
people use Ruby, I just care that it exists, and I get to use it.

Ruby was much more of a niche language when I first started using it
(pre Rails), and even then, it was getting enough care and attention
for me.  Since then, it's usage has grown just fine on it's own.

> The point of my post was to eliminate the manual work that has to go
> into a Ruby installer.  Make it a lot more automated, flick a switch and
> walk away.

Excellent idea.  Build it, and set it up on a server for us.  If you
can't host it, I'm sure others will volunteer.

> Even under ideal situations the Ruby Windows Installer is at
> least a few days/weeks turn around time.  Right now the 1.84 release is
> going on 6 months.  This is the reality right now.

On 5/23/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:
  "The lag this time around is an anomaly."
and...
  "With the new build system it should be possible to reduce that lag
time to a few days."

> location.  Nice and easy.  When I look at the Ruby download site I see a
> mis-mash of info and links leading off to other sites- it looks
> unprofessional at best.  Again, I'm looking at this from a company's
> eyes.  First impressions mean a lot.

Ok, so the logical choices are...

Make a better build system, or at least spec one out, and see if you
can get others to build it for you.

Hire others to make a better build system.

Offer to sponsor it (ala Google's Summer of Code).

Deal with the current build system, and use Ruby until others get the
chance to improve it.

Walk away, and use Python until the build system is improved.

I think that's about it.  Telling the people (who are doing all of
this for free) that they are 'doing it wrong' really doesn't do much
to solve the problem.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-24 00:52
(Received via mailing list)
On May 23, 2006, at 4:46 PM, Douglas Livingstone wrote:

> There was a nice redesign with some momenutum about it a while back,
> but it seems to have gotten lost somewhere :-(

Not at all.  We've made tons of progress on it just recently.  Behold:

http://new.ruby-lang.org/

That's the custom-built CMS running on the ruby-lang.org server and
serving up content we made or imported.  Yes, there are holes, but we
are working to fill them in.

James Edward Gray II

P.S.  I need volunteers who can generate needed content for the new
site.  If you are interested, email me off-list.
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-05-24 04:24
(Received via mailing list)
On May 23, 2006, at 3:51 PM, James Edward Gray II wrote:

> serving up content we made or imported.  Yes, there are holes, but
> we are working to fill them in.
>
> James Edward Gray II
>
> P.S.  I need volunteers who can generate needed content for the new
> site.  If you are interested, email me off-list.
>
>

Awesome! I'm so glad to see that coming together.

-Ezra
788a2539092e5429d8c546e8ad5084b2?d=identicon&s=25 Peter C. Verhage (Guest)
on 2006-05-24 12:15
(Received via mailing list)
Curt Hibbs wrote:
> Also as Austin pointed out, it would be much better to join the one-click
> installer team. I have been asking for help repeatedly over the years
> without much response. So far, only Ryan Leavengood and Shashank Date have
> helped. There's a lot that could be done, but without more help, the I have
> to keep the scope limited.

Hi,

I read your message on the ruby-talk mailinglist. What kind of help do
you need?  I don't have a Visual C++ environment running, but as I
understand it the environment can be downloaded for free nowadays (the
express edition at least).

Regards,

Peter
C475cffda1800fbc3f3af17bc10c220f?d=identicon&s=25 Curt Hibbs (Guest)
on 2006-05-24 13:07
(Received via mailing list)
There is a slight problem here though. I don't have time to go into the
detais (I've got to get out of the house in 15 minutes), but right now
to
build the one-click ruby installer/distro you need VC++ 6.0. The free
version is VC++ 8 and is not compatible.

Curt
B33ea5c12d767bfd1253940a960274f5?d=identicon&s=25 Tim Hunter (timhunter)
on 2006-05-24 14:39
Curt Hibbs wrote:
> There is a slight problem here though. I don't have time to go into the
> detais (I've got to get out of the house in 15 minutes), but right now
> to
> build the one-click ruby installer/distro you need VC++ 6.0. The free
> version is VC++ 8 and is not compatible.
>
> Curt


What compiler do you need to build binary extensions that are compatible
with the one-click installer?
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-24 14:59
(Received via mailing list)
On Wed, May 24, 2006 at 09:39:43PM +0900, Tim Hunter wrote:
> What compiler do you need to build binary extensions that are compatible
> with the one-click installer?

IIRC MSVC 6 or MinGW.
B33ea5c12d767bfd1253940a960274f5?d=identicon&s=25 Tim Hunter (timhunter)
on 2006-05-24 15:13
Mauricio Fernandez wrote:
> On Wed, May 24, 2006 at 09:39:43PM +0900, Tim Hunter wrote:
>> What compiler do you need to build binary extensions that are compatible
>> with the one-click installer?
>
> IIRC MSVC 6 or MinGW.

Thanks, Mauricio.

We tried building RMagick with MinGW and ran into problems (with Rails
apps) that smell very much like they were caused by an incompatibility
between MinGW and the compiler used for the 1.8.4 ruby-mswin binary.
Through 1.8.2, RMagick built with MinGW has always worked just fine.

So I'm wondering what to do. If I'm right and MinGW-compiled binaries
are incompatible with ruby-mswin 1.8.4, and MSVC6 is no longer available
for free, what compiler should we use to create ruby-mswin-compatible
compiled extensions?
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-24 15:49
(Received via mailing list)
On Wed, 24 May 2006, Curt Hibbs wrote:

> There is a slight problem here though. I don't have time to go into the
> detais (I've got to get out of the house in 15 minutes), but right now to
> build the one-click ruby installer/distro you need VC++ 6.0. The free
> version is VC++ 8 and is not compatible.
>
> Curt

hi curt-

i've never understood why one would use the mingw?  my biggest issue
with
windows ruby is that i can't do this

   ruby extconf.rb && make && make install

which renders ruby useless for my purposes - doing just about any
science will
require one to compile ruby extensions and third-party libs...

so, when i compiled the gsl for win i had to do this

   - install msys
   - compile a ruby using msys
   - compile gsl
   - compile ruby-gsl using msys-ruby
   - manually copy *.so, *rb, etc into c:\ruby\lib\...

not to mention quite a few small tweaks i made to ruby-gsl... anyhow.
here is
my question:

why not compile ruby with msys so that windows users can install
extensions
like the rest of the ruby world?  it always seems strange to me that
ruby's
built-in extension creation does not work on windows...

anyhow, not wanting to look a gift horse in the mouth, but why not msys?


cheers.

-a
74361169979a843b3a5c12d81000debc?d=identicon&s=25 Jon Egil Strand (Guest)
on 2006-05-24 15:58
(Received via mailing list)
Not really relevant to the one-click-installer, but precompiled windows
binaries are available here:

http://www.antoniocangiano.com/articles/tag/ruby

both stable 1.8.4 pr 2006-05-03 and unstable 1.9 pr 2006-05-01
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-24 16:32
(Received via mailing list)
On 5/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>
> why not compile ruby with msys so that windows users can install extensions
> like the rest of the ruby world?  it always seems strange to me that ruby's
> built-in extension creation does not work on windows...
>
> anyhow, not wanting to look a gift horse in the mouth, but why not msys?

We do not compile Ruby ourselves, but use the compiled version provided
here:

http://www.garbagecollect.jp/ruby/mswin32/en/downl...

It seems they use VC6 to compile this, so we must use it as well for
extensions.

I'll let Curt explain why this particular version is used, because I
do not know.

Ryan
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-24 17:10
(Received via mailing list)
On Wed, May 24, 2006 at 11:31:11PM +0900, Ryan Leavengood wrote:
>
> http://www.garbagecollect.jp/ruby/mswin32/en/downl...

But would it be more difficult to use
http://ftp.ruby-lang.org/pub/ruby/binaries/mingw/1.8/  instead?

Quoting from that page

mswin32
 Compiled by Microsoft Visual C++. This is the most 'standard' binary
from the
 common point-of-view in the Windows world. But we cannot use some parts
of
 characteristic functions which ruby on UNIX has. After 1.7.3, mswin32
has
 binary level compatibility of extension libraries with mingw32.
RUBY_PLATFORM
 is *-mswin32.
[...]
mingw32
 Compiled by gcc. Since most of the source code of ruby-mingw32 is the
same as
 ruby-mswin32, the behaviors of it are almost the same as that of
ruby-mswin32
 (probably). After 1.7.3, mingw32 has binary level compatibility of
extension
 libraries with mswin32. RUBY_PLATFORM is *-mingw32.
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-24 17:26
(Received via mailing list)
On Wed, May 24, 2006 at 10:13:14PM +0900, Tim Hunter wrote:
> apps) that smell very much like they were caused by an incompatibility
> between MinGW and the compiler used for the 1.8.4 ruby-mswin binary.
> Through 1.8.2, RMagick built with MinGW has always worked just fine.
>
> So I'm wondering what to do. If I'm right and MinGW-compiled binaries
> are incompatible with ruby-mswin 1.8.4, and MSVC6 is no longer available
> for free, what compiler should we use to create ruby-mswin-compatible
> compiled extensions?

If you're right that's pretty bad news :-| I thought MinGW was
compatible with
the MSVC6-based ruby-mswin32 builds (I only knew of compatibility
problems
with the runtime used by newer VC compilers). I'm using MinGW to
cross-compile the extension used by rcov, and was considering offering a
hand
to the One Click team...

If they're actually incompatible, this would almost make ruby-mingw32
preferable as a base to build the One-Click Installer upon, since:
* mingw is readily available and will not disappear the way MSVC6 did
* it allows for cross-compilation, meaning one doesn't need a win32 box
nearby
  to create win32 binaries

Is there anything that would make builds made with the VC-of-the-day
better an
option than ruby-mingw32?

I'd guess a possible transition wouldn't be too costly given the new
One-Click infrastructure. Maybe as little as pointing to
http://ftp.ruby-lang.org/pub/ruby/binaries/mingw/1...
instead of
http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32...
?
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-24 17:48
(Received via mailing list)
On Wed, 24 May 2006, Ryan Leavengood wrote:

> http://www.garbagecollect.jp/ruby/mswin32/en/downl...
>
> It seems they use VC6 to compile this, so we must use it as well for
> extensions.
>
> I'll let Curt explain why this particular version is used, because I
> do not know.
>
> Ryan

fwiw i downloaded msys and compiled ruby-1.8.4 on an xp in about 10
minutes -
no errors even.

regards.

-a
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-24 17:52
(Received via mailing list)
On 5/24/06, Curt Hibbs <ml.chibbs@gmail.com> wrote:
> There is a slight problem here though. I don't have time to go into the
> detais (I've got to get out of the house in 15 minutes), but right now to
> build the one-click ruby installer/distro you need VC++ 6.0. The free
> version is VC++ 8 and is not compatible.

*and* has significant problems of its own.

This is the stuff that I'm working on when I have time.

-austin
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-24 17:55
(Received via mailing list)
On 5/24/06, Tim Hunter <rmagick@gmail.com> wrote:
> Through 1.8.2, RMagick built with MinGW has always worked just fine.
That's odd, because MinGW is supposed to be compatible with VC++6. It
would be useful to see further information.

> So I'm wondering what to do. If I'm right and MinGW-compiled binaries
> are incompatible with ruby-mswin 1.8.4, and MSVC6 is no longer available
> for free, what compiler should we use to create ruby-mswin-compatible
> compiled extensions?

It's worse: MSVC6 is no longer available at all. Even I, with an MSDN
subscription, can no longer get MSVC6, as I understand it.

-austin
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-24 17:55
(Received via mailing list)
On 5/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Wed, 24 May 2006, Curt Hibbs wrote:
> > There is a slight problem here though. I don't have time to go into the
> > detais (I've got to get out of the house in 15 minutes), but right now to
> > build the one-click ruby installer/distro you need VC++ 6.0. The free
> > version is VC++ 8 and is not compatible.
> i've never understood why one would use the mingw?  my biggest issue with
> windows ruby is that i can't do this

MinGW uses MSYS. You're using MinGW when you use MSYS, Ara.

-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-24 18:04
(Received via mailing list)
On Thu, 25 May 2006, Austin Ziegler wrote:

> On 5/24/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>> On Wed, 24 May 2006, Curt Hibbs wrote:
>> > There is a slight problem here though. I don't have time to go into the
>> > detais (I've got to get out of the house in 15 minutes), but right now to
>> > build the one-click ruby installer/distro you need VC++ 6.0. The free
>> > version is VC++ 8 and is not compatible.
>> i've never understood why one would use the mingw?  my biggest issue with
>> windows ruby is that i can't do this
>
> MinGW uses MSYS. You're using MinGW when you use MSYS, Ara.

ooops.  typo.  what i meant to say was

   ... i've never understood why one __wouldn't__ use the mingw/msys
combo? ...



obviously i'm campaigning for extconf.rb cross-platform compat - and
that
means using mingw/msys.

sorry for confusion.

-a
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-05-24 19:16
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
...
>
>   - install msys
>   - compile a ruby using msys
>   - compile gsl
>   - compile ruby-gsl using msys-ruby
>   - manually copy *.so, *rb, etc into c:\ruby\lib\...

What goes wrong with gsl when you use ruby-mswin32 and nmake/vc6?

ruby extconf.rb
nmake
nmake install

This has worked for some extensions, but maybe gsl is peculiar about
being compiled with gcc?
C475cffda1800fbc3f3af17bc10c220f?d=identicon&s=25 Curt Hibbs (Guest)
on 2006-05-24 19:22
(Received via mailing list)
On 5/24/06, Mauricio Fernandez <mfp@acm.org> wrote:
> If they're actually incompatible, this would almost make ruby-mingw32
> I'd guess a possible transition wouldn't be too costly given the new
> One-Click infrastructure. Maybe as little as pointing to
>
> http://ftp.ruby-lang.org/pub/ruby/binaries/mingw/1...
> instead of
>
> http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32...
> ?


Overall, this is a distressing state of affairs. If anyone here knows a
reason why MinGW would be a bad idea, please speak up. In the long term
it
seems like MinGW would be the way to go. But the current 1.8.4 version
is
within a week or so of a final release and needs to go out as is.

The reason that I went back to VC++6 was that all of the extensions that
I
pick up in binary format are VC++6.

As Ara pointed out, buildng Ruby itself is easy. I've never had problems
building Ruby. Its problems building the extensions that take the most
effort, which is why I went for binaries whenever possible.

But this came from the days when everyone thought that all these
compilers
(MinGW, VC++6, VC++7, etc.) were compatible. It really looks like the
only
safe approach for the long term is to build everything from source.

I think this is the right thing to do, but I need to find additional,
help.
Ryan Leavengood has been tremendously helpful over the last two months.
But
knowing my other commitments, we'd need at least one other knowlegable C
and
Ruby developer who could be realiably counted on to help.

Curt
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-24 19:25
(Received via mailing list)
On Thu, 25 May 2006, Joel VanderWerf wrote:

>>
> ruby extconf.rb
> nmake
> nmake install
>
> This has worked for some extensions, but maybe gsl is peculiar about
> being compiled with gcc?

yup, you never would even make it this far.  you need to do this first

   cd gsl-1.8/

   ./configure --prefix=/usr/local && make && make install

and for that you need msys.  same goes for sqlite, etc, etc.  people
have
compiled gsl using vc6 but they charge 400 bucks for it... that must
mean
something.

regards.

-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-24 19:31
(Received via mailing list)
On Thu, 25 May 2006, Curt Hibbs wrote:

> Overall, this is a distressing state of affairs. If anyone here knows a
> reason why MinGW would be a bad idea, please speak up.

i can't really comment on this - but my baby steps have shown it to be
ok.

>
> But this came from the days when everyone thought that all these compilers
> (MinGW, VC++6, VC++7, etc.) were compatible. It really looks like the only
> safe approach for the long term is to build everything from source.

btw.  the incompatibility i found was isascii()  one compiler defines it
as a
macro, and the other a function.  at runtime it fails to find the
symbol.
sorry i forget which is which, but it's and example of incompat.

> I think this is the right thing to do, but I need to find additional, help.
> Ryan Leavengood has been tremendously helpful over the last two months. But
> knowing my other commitments, we'd need at least one other knowlegable C and
> Ruby developer who could be realiably counted on to help.

i can lend a little assistance wrspt to compiling things - be it third
party
or otherwise.

cheers.

-a
3afd3e5e05dc9310c89aa5762cc8dd1d?d=identicon&s=25 Timothy Hunter (Guest)
on 2006-05-25 01:31
(Received via mailing list)
Curt Hibbs wrote:

>> cross-compile the extension used by rcov, and was considering offering a
>> Is there anything that would make builds made with the VC-of-the-day
>> http://ftp.ruby-lang.org/pub/ruby/binaries/mswin32...
>
> (MinGW, VC++6, VC++7, etc.) were compatible. It really looks like the
>
> Curt
>
Rats. Kaspar Scheiss actually does the RMagick Win32 work, and he's on
holiday now, so my info is 2nd-hand. I'll do the best I can...

Kaspar has been using mingw to build the RMagick Win32 gem all along.
However we started getting complaints that the one he built last
September, for Ruby 1.8.2, was causing problems when run with the 1.8.4
one-click installer previews. Apparently the latest version of Rails
requires 1.8.4. Of course it's easy to believe that a compiled extension
built for 1.8.2 will be incompatible with 1.8.4, so he used mingw to
build a new gem for 1.8.4. Almost immediately we started getting reports
of problems when using it in Rails apps. Consequently I withdrew the
gem, which leaves the old 1.8.2-compatible version as the only option
for RMagick users on Windows. We have not had any reports of problems
outside of Rails.

I admit that doesn't 100% prove that mingw is incompatible with VC++6,
but if it's not fire it's at least smoke. I'd be interested to hear from
other people who have built extensions using mingw. Have you had any
problems using your extension with ruby-mswin 1.8.4?

My concern is that if VC++6 is not available, and mingw is not
compatible with VC++6, then there's no way for us to build a version of
RMagick for Win32 that is compatible with the one-click installer.

Is it possible to get VC++6 from someplace other than MS? Does MS allow
it?

I think mingw is the way to go in the future. I wish I could give a good
answer about where you could get additional help.

Will the new one-click infrastructure extend to building compatible
extensions? That is, is this something we could use to build a
guaranteed-compatible-with-the-one-click version of RMagick for Win32?
This is something we'd adopt in a heartbeat. If not, what it would take
to make such an infrastructure, not just for RMagick of course but for
all C extensions? (Everybody jumped on Zed & Luis' comments about Ruby
peformance, but I was particularly struck by Luis' comments about the
problems he ran into with Ruby libraries on Win32).
2c8df79b2a68a7532af01d8851f7fa2d?d=identicon&s=25 John Lam (Guest)
on 2006-05-25 03:39
(Received via mailing list)
Jumping in real late on this thread - but I know there are folks on the
VC++
team at MSFT who really want to help get Ruby compiling using C++ 14.0
(the
release that ships with VS 2005). I don't have cycles to really help out
here (have some nasty bugs to squash in RubyCLR), but I can hook people
up
with the appropriate folks on the team to get the ball rolling if
someone
wants to drive this effort on the Ruby side of the house.

Cheers,
-John
http://www.iunknown.com
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-25 06:46
(Received via mailing list)
On 5/24/06, John Lam <drjflam@gmail.com> wrote:
> Jumping in real late on this thread - but I know there are folks on the VC++
> team at MSFT who really want to help get Ruby compiling using C++ 14.0 (the
> release that ships with VS 2005). I don't have cycles to really help out
> here (have some nasty bugs to squash in RubyCLR), but I can hook people up
> with the appropriate folks on the team to get the ball rolling if someone
> wants to drive this effort on the Ruby side of the house.

Get them in touch with me if you don't mind; I've got a lot of work
that I've done so far and I'll point out that the problem, at the
moment, isn't so much Ruby itself, but extensions and the things upon
which those extensions are based. There are also some concerns about
the permissions required to install Ruby build with C++ 14 (VS 2005,
MSVCRT8).

-austin
02bd6b98b7c04f9ae5868eda3d01fb73?d=identicon&s=25 Guest (Guest)
on 2006-05-25 15:51
> fwiw i downloaded msys and compiled ruby-1.8.4 on an xp in about 10
> minutes - no errors even.

I've got mingw and msys installed on a windows 2003 box... I've got the
path variables set, etc... how did you run ./configure on the ruby
source???
02bd6b98b7c04f9ae5868eda3d01fb73?d=identicon&s=25 Guest (Guest)
on 2006-05-25 16:01
Guest wrote:

> I've got mingw and msys installed on a windows 2003 box... I've got the
> path variables set, etc... how did you run ./configure on the ruby
> source???

I figured it out... I have to use the msys shell... works great.
02bd6b98b7c04f9ae5868eda3d01fb73?d=identicon&s=25 Guest (Guest)
on 2006-05-25 16:34
So, now that I have a working ruby.exe, irb, ri, etc. built with mingw
and msys... I suppose the next step is to build the extensions with
mingw and msys in the same manner? Is it really that simple?

> I figured it out... I have to use the msys shell... works great.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-25 17:00
(Received via mailing list)
On Thu, 25 May 2006, Guest wrote:

>> fwiw i downloaded msys and compiled ruby-1.8.4 on an xp in about 10
>> minutes - no errors even.
>
> I've got mingw and msys installed on a windows 2003 box... I've got the
> path variables set, etc... how did you run ./configure on the ruby
> source???

start msys # gives you a shell

  > tar xvfz ruby-1.8.4.tar.gz
  > cd ruby-1.8.4
  > ./configure --prefix=/usr/local/ && make && make install

is all i did


what problem are you seeing?

-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-25 17:00
(Received via mailing list)
On Thu, 25 May 2006, Guest wrote:

> Guest wrote:
>
>> I've got mingw and msys installed on a windows 2003 box... I've got the
>> path variables set, etc... how did you run ./configure on the ruby
>> source???
>
> I figured it out... I have to use the msys shell... works great.


yup.  and know you can do things like

   tar xvfz narray.tgz

   cd narray

   ruby extconf.rb && make && make install


voila - you've got the narray c extension installed.  easy cheasy.

as far as i'm concerned a ruby that can't be extended this way is
crippled...

the other nice thing is that you can stay as current as you like and
even
patch your own local ruby.

cheers.

-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-25 17:28
(Received via mailing list)
On Thu, 25 May 2006, Guest wrote:

> So, now that I have a working ruby.exe, irb, ri, etc. built with mingw and
> msys... I suppose the next step is to build the extensions with mingw and
> msys in the same manner? Is it really that simple?

yes.

download this script

   http://fortytwo.merseine.nu/presentations/narray_install.sh

use this link if your browser doesn't understand *.sh files

   http://fortytwo.merseine.nu/presentations/narray_i...

edit the line

   msys_ruby="/c/usr/local/bin/ruby"

to point to wherever you installed your msys ruby

run it.

you should see a bunch of output and then

   you just installed NArray

it's that easy.

-a
02bd6b98b7c04f9ae5868eda3d01fb73?d=identicon&s=25 Brad (Guest)
on 2006-05-25 17:45
> yes.
>
> download this script
>
>    http://fortytwo.merseine.nu/presentations/narray_install.sh
>
> use this link if your browser doesn't understand *.sh files
>
>    http://fortytwo.merseine.nu/presentations/narray_i...
>
> edit the line
>
>    msys_ruby="/c/usr/local/bin/ruby"
>
> to point to wherever you installed your msys ruby
>
> run it.
>
> you should see a bunch of output and then
>
>    you just installed NArray
>
> it's that easy.
>
> -a

That is so cool! I can't fault the guys who build the one-click
installer for using a MS compilier as I've used and enjoyed their work
greatly, but it seems to me the natural way to build Ruby on Windows in
the future would be mingw and msys as it's so easy and won't go away
like MS compilers seem to do :)

I could probably find this info elsewhere, but I wonder what does Daniel
Berger of the win32utils project build binaries with?
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-25 18:25
(Received via mailing list)
On Fri, 26 May 2006, Brad wrote:

> That is so cool! I can't fault the guys who build the one-click installer
> for using a MS compilier as I've used and enjoyed their work greatly, but it
> seems to me the natural way to build Ruby on Windows in the future would be
> mingw and msys as it's so easy and won't go away like MS compilers seem to
> do :)
>
> I could probably find this info elsewhere, but I wonder what does Daniel
> Berger of the win32utils project build binaries with?

i am under the impression that dan is re-working all that code to use
ruby/dl
- ergo it will not be, nor require, a compiler.  is that true dan?

-a
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-05-25 19:50
(Received via mailing list)
From: <ara.t.howard@noaa.gov>
>
>  > tar xvfz ruby-1.8.4.tar.gz
>  > cd ruby-1.8.4
>  > ./configure --prefix=/usr/local/ && make && make install
>
> is all i did

Nice. . . . But what does /usr/local mean on windows?  Did it
really install C:\usr\local?  :)

Also... I've searched the mingw FAQ and Google'd a bit, but
I haven't found an answer as to whether mingw can produce
debugging symbols in a format compatible with the Visual
Studio debugger.

> as far as i'm concerned a ruby that can't be extended this way
> is crippled...

./configure && make would be nice... provided the result is
debuggable with symbols in devenv.exe.  Otherwise it would
seem like curing the cripple in exchange for poking his eyes
out.

(I'll admit I've never tried using gdb under Windows. Maybe
it's not as horrifying as I'm imagining.)


Regards,

Bill
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-25 20:44
(Received via mailing list)
On Fri, 26 May 2006, Bill Kelly wrote:

>> start msys # gives you a shell
>>
>>  > tar xvfz ruby-1.8.4.tar.gz
>>  > cd ruby-1.8.4
>>  > ./configure --prefix=/usr/local/ && make && make install
>>
>> is all i did
>
> Nice. . . . But what does /usr/local mean on windows?  Did it
> really install C:\usr\local?  :)

to msys /usr/local means /c/usr/local whic means c:\usr\local.  however,
if
one tries this

   ./configure --prefix=c:\usr\local

the configure will explode in many, like the gsl, packages.  i don't
know how
it implements the 'virtual' /usr/local - but it does.

> Also... I've searched the mingw FAQ and Google'd a bit, but I haven't found
> an answer as to whether mingw can produce debugging symbols in a format
> compatible with the Visual Studio debugger.

what's a debugger?  ;-)

>> as far as i'm concerned a ruby that can't be extended this way
>> is crippled...
>
> ./configure && make would be nice... provided the result is debuggable with
> symbols in devenv.exe.  Otherwise it would seem like curing the cripple in
> exchange for poking his eyes out.
>
> (I'll admit I've never tried using gdb under Windows. Maybe
> it's not as horrifying as I'm imagining.)

it acutally seems to work fine - though i've not used it in anger.

cheers.

-a
C914fa463a2b1b067586c6432b12a824?d=identicon&s=25 Juergen Strobel (Guest)
on 2006-06-06 02:38
(Received via mailing list)
On Wed, May 24, 2006 at 04:30:56AM +0900, Enterprise Astronaut wrote:
> latest gem.  Seems like a lot less maintenance and heartache than the
> way its being done currently.
>
> --
> Posted via http://www.ruby-forum.com/.
>

Real men %x{aptitude install ruby} and
%x{aptitude search "lib.*ruby1.8"} for the rest on their own.

*ducks and runs for cover*
J├╝rgen
This topic is locked and can not be replied to.