[ANN] Ruby Installer for Windows 1.8.2-14_RC5 (from Ruby 1.8.2 preview1)

C

Curt Hibbs

Today Matz released the official preview1 for Ruby 1.8.2. This release
candidate of the Ruby Installer for Windows was built from this new
preview1.

You can download this release candidate from:

http://rubyinstaller.rubyforge.org/

You can check for reported problems (or report new problems) at:

http://rubyforge.org/tracker/?group_id=167


What is the Ruby Installer for Windows?
---------------------------------------

The Ruby Installer for Windows is a "one-click", self-contained Windows
installer that contains the Ruby language itself, dozens of popular
extensions and packages, a syntax-highlighting editor and execution
environment, and a Windows help file that contains the full text of the
book, "Programming Ruby: The Pragmatic Programmer's Guide".


Release 1.8.2-14:
- This is a build of Ruby 1.8.2 preview1.
- Changed the layout of the Windows registry
entries.
- Fixed a typo in a windows registry entry
(bug 643).
- Upgraded Expat to version 1.95.7
- Upgraded Ruby-odbc to version 0.993
- Upgraded DBI to 0.23
- Upgraded FXRuby to version 1.0.29
 
R

richard lyman

Curt,

I have done absolutely no research, so feel free to respond by
telling me to do my research ;-) ...

There's been a lot of talk lately about Oniguruma.

How does it tie into the Windows Installer? Is it there - can we
use it? Is it the default? Can it just be 'installed' - or does
someone (not me, I don't know how to yet) have to compile it before it
can be installed?

Is 'the standard regexp library problem' even a problem?

Are there any other licensing 'problems' that come about from
what's in the One-click Installer?

Thanks a ton for any response you can give!
-Rich
 
C

Curt Hibbs

richard said:
Curt,

I have done absolutely no research, so feel free to respond by
telling me to do my research ;-) ...

There's been a lot of talk lately about Oniguruma.

How does it tie into the Windows Installer? Is it there - can we
use it? Is it the default? Can it just be 'installed' - or does
someone (not me, I don't know how to yet) have to compile it before it
can be installed?

No, Oniguruma is not in the Ruby Installer for Windows. The installer is
just a precompiled version of the standard ruby distribution, some extension
libraries (see the release notes), and the scite editor.
Is 'the standard regexp library problem' even a problem?

Are there any other licensing 'problems' that come about from
what's in the One-click Installer?

The licensing issues with the installer would identical to the issues you
would have if you built Ruby and the included extensions yourself. I have no
answer for you beyond that.
Thanks a ton for any response you can give!

Your welcome!
Curt
 
D

David Espada

El miércoles 21 de julio, Curt Hibbs escribió:
Today Matz released the official preview1 for Ruby 1.8.2. This release
candidate of the Ruby Installer for Windows was built from this new
preview1.

Do it includes ruby-postgres precompiled?

If it doesn't, which reason for not including?

Thanks.

David
 
C

Curt Hibbs

David said:
El miércoles 21 de julio, Curt Hibbs escribió:

Do it includes ruby-postgres precompiled?

If it doesn't, which reason for not including?

No, ruby-postgres is not included, so you would have to install it yourself.

A public debate over what should or should not be included has occurred
several times in the past. As you might expect everyone has their own
favorites. I'm sure that a very good case could be made for each possible
inclusion, but it is simply not practical to include too many things, and
its not possible satisfy everyone.

The way I want to address this problem is to include RubyGems in the
installer, and then encourage package authors to release their packages in
RubyGems format. Then getting ruby-postgres installed on your system would
be as simple as running the command "gem install ruby-postgres".

Up until last week I was going to wait until a GUI interface to RubyGems was
available, but that is probably too far off. So, a couple days ago I started
a discussion with the RubyGems developers on whether or not I should include
RubyGems in this 182-14 release. If the answer turns out to be yes, then I
expect to have in 182-14 RC6.

Curt
 
L

Lothar Scholz

Hello Curt,

CH> A public debate over what should or should not be included has occurred
CH> several times in the past. As you might expect everyone has their own
CH> favorites. I'm sure that a very good case could be made for each possible
CH> inclusion, but it is simply not practical to include too many things, and
CH> its not possible satisfy everyone.

CH> The way I want to address this problem is to include RubyGems in the
CH> installer, and then encourage package authors to release their packages in
CH> RubyGems format. Then getting ruby-postgres installed on your system would
CH> be as simple as running the command "gem install ruby-postgres".

But this does still not help on binary extensions. And until the
brain dead (assuming the build system for extensions is the same as as
the one for the original interpreter) and completely undocumented binary
build system "rb_configure.rb" etc. is changed this is a very serious issue.

My personal request here is to include "wxruby.0.4"
 
L

Lyle Johnson

CH> The way I want to address this problem is to include RubyGems in the
CH> installer, and then encourage package authors to release their packages in
CH> RubyGems format. Then getting ruby-postgres installed on your system would
CH> be as simple as running the command "gem install ruby-postgres".

But this does still not help on binary extensions.

Sure it would, if the package authors provide both source and
precompiled, "binary" gems for their packages. I don't know what
specific issues come into play with the ruby-postgres package, but
I've been experimenting with this in the alpha releases of FXRuby 1.2
and it seems to be working well.
 
L

Laurent Sansonetti

Hi Curt,

Thanks for the package. I guess it's very convenient for Microsoft users.

Just a question... do you plan to provide Ruby/GTK2 some day? GTK2
works great on Windows and I believe it would be interesting to ship
Ruby bindings for it, since you already deliver FOX bindings.

(so there is no jalous :)

Cheers,
 
C

Curt Hibbs

Lothar said:
Hello Curt,

CH> A public debate over what should or should not be included
has occurred
CH> several times in the past. As you might expect everyone has their own
CH> favorites. I'm sure that a very good case could be made for
each possible
CH> inclusion, but it is simply not practical to include too many
things, and
CH> its not possible satisfy everyone.

CH> The way I want to address this problem is to include RubyGems in the
CH> installer, and then encourage package authors to release
their packages in
CH> RubyGems format. Then getting ruby-postgres installed on your
system would
CH> be as simple as running the command "gem install ruby-postgres".

But this does still not help on binary extensions. And until the
brain dead (assuming the build system for extensions is the same as
the one for the original interpreter) and completely undocumented binary
build system "rb_configure.rb" etc. is changed this is a very
serious issue.

My personal request here is to include "wxruby.0.4"

RubyGems *does* support platform-specific binary gems. This was an issue
that I brought up early on with the RubyGems developers precisely because I
wanted to package up wxRuby as a set of platform-specific binary gems
(although that hasn't happened yet). Do you think that wxRuby is mature
enough?

Curt

PS
I still need to resolve your problem with TCL/TK extension. I sent you a
private email to your [mailinglists at scriptolutions dot com] address about
this, but perhaps it got spam-filtered into oblivion. After the postings
from you and [nobu.nokada at softhome dot net], it was not obvious to me
what the correct solution should be. If you could send me your email address
(send to curt at hibbs dot com), I will re-send you that email.
Thanks, -curt
 
R

richard lyman

Curt,

I have a GUI for RubyGems...

... if you promise not to laugh at the code, I'll privately send
you what I've got and you can tell me what to do to get it up to the
specs you'd want/need for inclusion in the Windows Installer.

The way I envision it is that the RubyGem interface would be a
compiled binary for Windows, that could have a link in the Programs
menu... then for the average 10yr old, or mom or dad who wanted to
program, they could easily add libraries on to their Ruby
installation... Double-click the RubyGem interface... wait for the
list to load... select the program, see all versions and a
description, select the version to install... click the install
button... you're done. Obviously there would be more options for
advanced users... but I really like the idea of making the
installation of add-on libraries as simple as the installation of
Ruby.

I really want RubyGems in the Windows One-Click... and I _really_
think RubyGems should have a GUI... i.e. I really want to send you my
code, have it reviewed, get everything done that you need, and package
it with the Windows One-Click.

-Rich
P.s. - Windows One-Click.... WOC? :) Sounds like Wok... which I know
is Chinese, and not Japanese... but it's an interesting acronym. Would
that make it... LOC (Linux...), MOC, (Mac...) ... anyway... :)


Lothar said:
Hello Curt,

CH> A public debate over what should or should not be included
has occurred
CH> several times in the past. As you might expect everyone has their own
CH> favorites. I'm sure that a very good case could be made for
each possible
CH> inclusion, but it is simply not practical to include too many
things, and
CH> its not possible satisfy everyone.

CH> The way I want to address this problem is to include RubyGems in the
CH> installer, and then encourage package authors to release
their packages in
CH> RubyGems format. Then getting ruby-postgres installed on your
system would
CH> be as simple as running the command "gem install ruby-postgres".

But this does still not help on binary extensions. And until the
brain dead (assuming the build system for extensions is the same as
the one for the original interpreter) and completely undocumented binary
build system "rb_configure.rb" etc. is changed this is a very
serious issue.

My personal request here is to include "wxruby.0.4"

RubyGems *does* support platform-specific binary gems. This was an issue
that I brought up early on with the RubyGems developers precisely because I
wanted to package up wxRuby as a set of platform-specific binary gems
(although that hasn't happened yet). Do you think that wxRuby is mature
enough?

Curt

PS
I still need to resolve your problem with TCL/TK extension. I sent you a
private email to your [mailinglists at scriptolutions dot com] address about
this, but perhaps it got spam-filtered into oblivion. After the postings
from you and [nobu.nokada at softhome dot net], it was not obvious to me
what the correct solution should be. If you could send me your email address
(send to curt at hibbs dot com), I will re-send you that email.
Thanks, -curt
 
C

Curt Hibbs

richard said:
Curt,

I have a GUI for RubyGems...

... if you promise not to laugh at the code, I'll privately send
you what I've got and you can tell me what to do to get it up to the
specs you'd want/need for inclusion in the Windows Installer.

Yes, please do send it along to [curt at hibbs dot com].
The way I envision it is that the RubyGem interface would be a
compiled binary for Windows, that could have a link in the Programs
menu... then for the average 10yr old, or mom or dad who wanted to
program, they could easily add libraries on to their Ruby
installation... Double-click the RubyGem interface... wait for the
list to load... select the program, see all versions and a
description, select the version to install... click the install
button... you're done. Obviously there would be more options for
advanced users... but I really like the idea of making the
installation of add-on libraries as simple as the installation of
Ruby.

Well, we're definitely on the same page here.
I really want RubyGems in the Windows One-Click... and I _really_
think RubyGems should have a GUI... i.e. I really want to send you my
code, have it reviewed, get everything done that you need, and package
it with the Windows One-Click.

-Rich
P.s. - Windows One-Click.... WOC? :) Sounds like Wok... which I know
is Chinese, and not Japanese... but it's an interesting acronym. Would
that make it... LOC (Linux...), MOC, (Mac...) ... anyway... :)

Curt
 
L

Lothar Scholz

Hello richard,

rl> Curt,

rl> I have a GUI for RubyGems...

rl> ... if you promise not to laugh at the code, I'll privately send
rl> you what I've got and you can tell me what to do to get it up to the
rl> specs you'd want/need for inclusion in the Windows Installer.

I have done some testing for Arachno Ruby. But i will wait until
RubyGems 1.0 is released. A stable backward compatible interface
would be indeed a nice thing, especially now where i get more and more
downloads from files32.com, download.com etc. I can see in my
webserver logs that the first thing they do is to press the "download
ruby" button in my program (it's a redirect on my webserver for the
case that www.ruby-lang.org is down or changing the name).

So for these ruby newbies it would be great if they can have access
to Ruby-GTK, Ruby-ImageMagic and all the other stuff without reading
man pages.
 
G

gabriele renzi

il Thu, 22 Jul 2004 22:25:10 +0900, Laurent Sansonetti
Hi Curt,

Thanks for the package. I guess it's very convenient for Microsoft users.

Just a question... do you plan to provide Ruby/GTK2 some day? GTK2
works great on Windows and I believe it would be interesting to ship
Ruby bindings for it, since you already deliver FOX bindings.

(so there is no jalous :)

on the lines of the hread, I think the best thing would be to package
up all the ruby-gnome2 stuff that works on windows in some gems, and
maybe provide a choice at install time something like cygwin does
 
G

gabriele renzi

il Thu, 22 Jul 2004 15:28:26 GMT, gabriele renzi
on the lines of the hread, I think the best thing would be to package
up all the ruby-gnome2 stuff that works on windows in some gems, and
maybe provide a choice at install time something like cygwin does

I mean, when the one click gets installed, pop up a gui with "select
additional packages.."
 
C

Curt Hibbs

gabriele said:
il Thu, 22 Jul 2004 22:25:10 +0900, Laurent Sansonetti


on the lines of the hread, I think the best thing would be to package
up all the ruby-gnome2 stuff that works on windows in some gems, and
maybe provide a choice at install time something like cygwin does

That's the approach I want to take with almost all extensions -- provide
add-ons through RubyGems.

Curt
 
R

Richard Kilmer

Sure it would, if the package authors provide both source and
precompiled, "binary" gems for their packages. I don't know what
specific issues come into play with the ruby-postgres package, but
I've been experimenting with this in the alpha releases of FXRuby 1.2
and it seems to be working well.

And, we are adding to Gems the ability to utilize the platform attribute
within the gemspec to select the appropriate binary vs. source gem (or give
the user the option) if provided. So if Lyle puts:

fxruby-1.2.0.gem
#=> spec.platform = Gem::platform::RUBY

fxruby-1.2.0-win32.gem
#=> spec.platform = Gem::platform::WIN32

It will pick (not based on the name, that is convention) the fxruby 1.2.0
for your platform if one exists.

If a Linux user did:

gem install -r fxruby

RubyGems would download fxruby-1.2.0.gem and it would build it (using the
extconf.rb, etc) upon install from source.

If a Windows user did:

gem install -r fxruby

RubyGems would download fxruby-1.2.0-win32.gem and it would just install (no
building necessary).

This automatic selection capability will be in Gems SOON (hopefully in a
week), but as Lyle said, you can currently build and install gems that are
binary but its a manual choosing process.

-rich
 
R

richard lyman

Perfect!!

I will love that functionality.

I had that very problem with the current setup (and I understand that
you've said that this is already being changed), is that when I ran
the command (something like):

gem install --remote fxruby

It got the version that had to be compiled - which I couldn't use...
Lyle helped point out that I'd need to manually select the binary
version (which you've mentioned will be automated), by running the
command

gem install --remote fxruby-1.2.1-mswin32

... and then it worked perfectly.

So... I'm excited for the functionality that will automatically know
that I'm on windows and that I want the binary, precompiled, version
of the package.

I have a question though - what about the list of Gems? Can the basic
listing of remotely installable gems indicate the existance of a
binary version? In other words, when I run the command:

gem list --remote

Can I get some indication of the existance (or non-existance) of the
binary versions?

I'm hoping to avoid useability problems when a package is listed in
the GUI as 'installable', but it really isn't, since there's no binary
version... I hope I'm making sense...

I want you guys to know that your work is really helping the
distribution-ability of Ruby.

-Rich
 
R

Richard Kilmer

I have a question though - what about the list of Gems? Can the basic
listing of remotely installable gems indicate the existance of a
binary version? In other words, when I run the command:

gem list --remote

Can I get some indication of the existance (or non-existance) of the
binary versions?

Yeah...we will work that out. It will likely be listed as two gems (one
source, one binary), but the UI (and the list function) will perhaps
highlight the fact that the binary gem for your platform is available.
We'll figure it out so its simple :)
I'm hoping to avoid useability problems when a package is listed in
the GUI as 'installable', but it really isn't, since there's no binary
version... I hope I'm making sense...

You are, and we agree...the goal is simplicity of use...hope we reach that
goal!
I want you guys to know that your work is really helping the
distribution-ability of Ruby.

Thanks, and the main thing that will help is the whole community
contributing gems!!! So, code and distribute!!!

-rich
 
L

Lyle Johnson

And, we are adding to Gems the ability to utilize the platform attribute
within the gemspec to select the appropriate binary vs. source gem (or give
the user the option) if provided.

As long as we're on the subject, are there any plans to include (and
make use of) metadata about the Ruby version for which a binary gem
was built? If I build a binary gem against Ruby 1.8.1 and you try to
use it with a different Ruby version, it's likely not to work.
 
J

Jeff Mitchell

Curt Hibbs said:
Lothar Scholz wrote: [...]
But this does still not help on binary extensions. And until the
brain dead (assuming the build system for extensions is the same as
the one for the original interpreter) and completely undocumented binary
build system "rb_configure.rb" etc. is changed this is a very
serious issue.

My personal request here is to include "wxruby.0.4"

RubyGems *does* support platform-specific binary gems. This was an issue
that I brought up early on with the RubyGems developers precisely because I
wanted to package up wxRuby as a set of platform-specific binary gems
(although that hasn't happened yet). Do you think that wxRuby is mature
enough?

RubyGems supports binary gems in the sense that you can put any file
type, including binary, into a gem. But there is no useful support
for binary gems; I asked in [ruby-talk:104609] and [ruby-talk:104486]
and in private email, all without reply. (By "binary" I mean
precompiled gems.)

For my gems, I experimented with a mypackage-i686-linux-ruby18-1.2.3.gem
naming scheme but decided it was too polluting to the global gem list
since every platform must have a separate, "unrelated" gem. The naming
scheme mypackage-1.2.3-i686-linux-ruby18.gem is a "Malformed version
number" error. The precompiled gems were also about twice as large as
a .tbz2 of the same files.

I eventually decided to stick with tarballs with .so files until
rubygems formally supports precompiled extensions.

This could be implemented by recognizing a -linux-i686-ruby18 suffix,
for example. Currently, when mypackage-1.2.3-i686-linux-ruby18.gem
exists on gems.rubyforge.org/gems/, there is a 404 Not Found error
for "gem -i mypackage". A first step could be to find gems matching
the host platform suffix when the primary search fails or when the
user requests a binary gem.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top