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

ruby-talk
41

I finally able to fix the problem

[...]

The problem is in system("more < file"). I try similar thing with irb

irb(main):001:0> system "more < c:\autoexec.bat"
File not found
=> true

Silly me, I forgot to escape '\'.
If i use system("more < c:\\autoexec.bat") everything will work as
expected.

The actual problem is:
1. The path is UNIX style which must be converted to DOS style before
   passed on to external program.
2. For some reason in Windows ME Tempfile is working intermittenly.
   As a workaround I unlink it after use and it always works.

Here's the patch

···

On Mon, Jul 26, 2004 at 07:08:57PM +0900, Zakaria wrote:

--- ri_display.rb.orig 2004-03-25 22:31:10.000000000 +0700
+++ ri_display.rb 2004-07-26 22:34:26.000000000 +0700
@@ -210,7 +210,8 @@
       require 'tempfile'

       @save_stdout = STDOUT.clone
- STDOUT.reopen(Tempfile.new("ri_"))
+ @tempfile = Tempfile.new("ri_")
+ STDOUT.reopen(@tempfile)
     end
   end

@@ -219,6 +220,7 @@
   def page_output
     unless @options.use_stdout
       path = STDOUT.path
+ path = path.gsub(%{/}, '\\\\') if Config::CONFIG['arch'] =~ /mswin/
       STDOUT.reopen(@save_stdout)
       @save_stdout = nil
       paged = false
@@ -232,6 +234,16 @@
         @options.use_stdout = true
         puts File.read(path)
       end
+
+ retryctr = 0
+ begin
+ retryctr += 1
+ @tempfile.unlink
+ rescue
+ sleep 0.1
+ retry if retryctr < 10
+ end
+ @tempfile = nil
     end
   end

=============================================================================

Dave, is the patch OK?

Wassallam,

-- Zakaria
   z4k4ri4@bigfoot.com Yahoo!: z4k4ri4
   http://zakaria.is-a-geek.org
   http://pemula.linux.or.id

42

Curt Hibbs wrote:

I'm in a rush at the moment, but I wanted say, just let me know what URL you
want me to use. Also, If you want me to add anything else, let me know that,
too.

Thanks,
Curt

I've replaced the 1.9 rdocs with 1.8.2 RC rdocs.

The "Core API" link is now
   http://www.ruby-doc.org/core/

So that should be the URL for 'Ruby Core API' shortcut created by the installer.

Thanks for all the work!

James Britt

43

Hi,

At Wed, 4 Aug 2004 22:08:52 +0900,
Curt Hibbs wrote in [ruby-talk:108303]:

I wanted to make these changes, but when I started to make the changes, it
wasn't clear precisely what I was supposed to do. At that time I sent you a
private email (to nobu.nokada@softhome.net) listing what I thought should be
done and asking if that was correct, but I never got a response before I had
to leave for my vacation.

Unfortunately, I've not received it.

> > > No, eban says those environment variables are not need at all.
> > > RubyInstaller should just set PATH, but not TCL_LIBRARY. And
> > > RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
> > > --enable-tcltk_stubs, but RubyInstaller doesn't.
> >
> > Good, I like that even better! I will change the installer to not set
> > TCL_LIBRARY.
>
> Correction: It couldn't find tk.tcl file when it just is not
> set. It worked by moving tcl/lib/* to lib.
>
> Another issue, there are identical files under samples/sample
> and doc/Tcl/Tk-1.8.1/sample, except for several files only in
> the former. Instead, *.{rb,so,lib} underneath lib are
> superfluous, since they exist also under lib/ruby/1.8 and never
> be used.

I am making changes to the ruby installer build in preparation for matz'
1.8.2 preview1, and I want to make sure that I correctly understand what you
have said needs to be done to fix TCL/TK in the ruby installer. This is
particularly important since I do not know anything about TCL/TK myself and
I rely on others for this advice and eventual testing.

I think the easiest way to do this is to assume that my last release
candidate, ruby182-14_rc3.exe, has been installed in the default location
(c:\ruby), and I will then describe the changes I think need to be made
using absolute paths. I'm fairly certain that this is wrong, but this is
what I got determined from your emails:

DEL C:\ruby\lib\tcl*.*
DEL C:\ruby\lib\tk*.*

And lib/{*-tk.rb,tk,tkextlib,README}. In other words, not
install ext/tk there.

MOVE DIR TREE C:\ruby\tcl\lib\
           TO C:\ruby\lib

Also tcl\include, and remove samples/Tcl/Tk-1.8.1/sample then
move sample/sample to there.

DO NOT SET VAR "TCL_LIBRARY"

And RUBY_TCL_DLL and RUBY_TK_DLL.

Or, you could configure with --enable-tcltk_stubs option; I
recommend this so that users can select other tcl/tk versions
and locations by the above two variables.

···

--
Nobu Nakada

44

richard lyman wrote:

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? :slight_smile: 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... :slight_smile:

Curt

45

Hello richard,

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.

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.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

46

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

···

On Fri, 23 Jul 2004 01:08:21 +0900, Richard Kilmer <rich@infoether.com> wrote:

On 7/22/04 9:05 AM, "Lyle Johnson" <lyle.johnson@gmail.com> wrote:

> On Thu, 22 Jul 2004 21:54:00 +0900, Lothar Scholz > > <mailinglists@scriptolutions.com> wrote:
>
>> > 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".
>>
>> 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.
>
>

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

47

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.

···

On Fri, 23 Jul 2004 01:08:21 +0900, Richard Kilmer <rich@infoether.com> wrote:

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.

48

Jeff Mitchell wrote:

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.

I really think it would make more sense to have all that info stored as metadata in the gem format and not put it in the name. For name collisions on the server just make a seperate directory for each build type. The information should certainly be there but I don't know if it's the best idea to put it all in the name.

Actually come to think of it maybe it would make more sense on the server end if the gem name is actually just a directory containing each of the gem build types. I dunno maybe i'm just picky, but I really think that packages should encode more metadata in a package system and less in the package name.

Charles Comstock

49

just one thing: I'm not sure if this is just a sample or is closely
related to the behaviour of the gem system, but should'nt it be:

Gem::Platform::WIN32::(MS|DJGPP|MINGW|LCC|WHATEVER) ?

different compiling toolchain are things to take in consideration..

···

il Fri, 23 Jul 2004 01:08:21 +0900, Richard Kilmer <rich@infoether.com> ha scritto::

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.

50

I went to apply this patch, and discovered that it doesn't correspond to the current 'ri' source. Is this really the version of ri being distributed in the windows installer?

Cheers

Dave

···

On Jul 26, 2004, at 11:19, Zakaria wrote:

The actual problem is:
1. The path is UNIX style which must be converted to DOS style before
   passed on to external program.
2. For some reason in Windows ME Tempfile is working intermittenly.
   As a workaround I unlink it after use and it always works.

Here's the patch

--- ri_display.rb.orig 2004-03-25 22:31:10.000000000 +0700
+++ ri_display.rb 2004-07-26 22:34:26.000000000 +0700
@@ -210,7 +210,8 @@
       require 'tempfile'

       @save_stdout = STDOUT.clone
- STDOUT.reopen(Tempfile.new("ri_"))
+ @tempfile = Tempfile.new("ri_")
+ STDOUT.reopen(@tempfile)
     end
   end

51

Thanks for the detailed instructions. I will make these changes as soon as I
can and put out RC8 so that people who use TCL/TK can have a chance to test
it.

Curt

···

-----Original Message-----
From: nobu.nokada@softhome.net [mailto:nobu.nokada@softhome.net]
Sent: Thursday, August 05, 2004 1:14 AM
To: ruby-talk ML
Subject: Re: [ANN] Ruby Installer for Windows 1.8.2-14 **RC7**

Hi,

At Wed, 4 Aug 2004 22:08:52 +0900,
Curt Hibbs wrote in [ruby-talk:108303]:
> I wanted to make these changes, but when I started to make the
changes, it
> wasn't clear precisely what I was supposed to do. At that time
I sent you a
> private email (to nobu.nokada@softhome.net) listing what I
thought should be
> done and asking if that was correct, but I never got a response
before I had
> to leave for my vacation.

Unfortunately, I've not received it.

> > > > No, eban says those environment variables are not need at all.
> > > > RubyInstaller should just set PATH, but not TCL_LIBRARY. And
> > > > RUBY_{TCL,TK}_DLL are used only if tcltklib is compiled with
> > > > --enable-tcltk_stubs, but RubyInstaller doesn't.
> > >
> > > Good, I like that even better! I will change the installer
to not set
> > > TCL_LIBRARY.
> >
> > Correction: It couldn't find tk.tcl file when it just is not
> > set. It worked by moving tcl/lib/* to lib.
> >
> > Another issue, there are identical files under samples/sample
> > and doc/Tcl/Tk-1.8.1/sample, except for several files only in
> > the former. Instead, *.{rb,so,lib} underneath lib are
> > superfluous, since they exist also under lib/ruby/1.8 and never
> > be used.
>
> I am making changes to the ruby installer build in preparation for matz'
> 1.8.2 preview1, and I want to make sure that I correctly
understand what you
> have said needs to be done to fix TCL/TK in the ruby installer. This is
> particularly important since I do not know anything about
TCL/TK myself and
> I rely on others for this advice and eventual testing.
>
> I think the easiest way to do this is to assume that my last release
> candidate, ruby182-14_rc3.exe, has been installed in the
default location
> (c:\ruby), and I will then describe the changes I think need to be made
> using absolute paths. I'm fairly certain that this is wrong, but this is
> what I got determined from your emails:
>
> DEL C:\ruby\lib\tcl*.*
> DEL C:\ruby\lib\tk*.*

And lib/{*-tk.rb,tk,tkextlib,README}. In other words, not
install ext/tk there.

> MOVE DIR TREE C:\ruby\tcl\lib\
> TO C:\ruby\lib

Also tcl\include, and remove samples/Tcl/Tk-1.8.1/sample then
move sample/sample to there.

> DO NOT SET VAR "TCL_LIBRARY"

And RUBY_TCL_DLL and RUBY_TK_DLL.

Or, you could configure with --enable-tcltk_stubs option; I
recommend this so that users can select other tcl/tk versions
and locations by the above two variables.

--
Nobu Nakada

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004

52

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

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

···

On 7/22/04 12:49 PM, "richard lyman" <lymans@gmail.com> wrote:

53

Excellent point. I think it's true that binaries compiled with
Microsoft's compiler or the MinGW compiler are compatible with each
other; but I don't know if that's true for the other cases. Yet
another variable to throw in the mix. :wink:

···

On Fri, 23 Jul 2004 21:26:58 +0900, gabriele renzi <surrender_it@rc1.vip.ukl.yahoo.com> wrote:

just one thing: I'm not sure if this is just a sample or is closely
related to the behaviour of the gem system, but should'nt it be:

Gem::Platform::WIN32::(MS|DJGPP|MINGW|LCC|WHATEVER) ?

different compiling toolchain are things to take in consideration.

54

I just posted a test release of the Ruby Installer for
Windows with the TCL/TK files moved around (hopefully
into their correct locations), plus this version of the
installer does not set any environment variables for TCL.

Since I am completely ignorant of TCL/TK, so I have no
idea whether of not this will work. If you know TCL/TK
please test this version and let me know both ways (if
it works or if it doesn't). If it does not work it
would be particularly useful if you could determine why
and include in your report precisely what should be
changed.

Please send reports to curt at hibbs dot com and
include "RubyTCL" in the subject line so that my
spam filter doesn't delete it.

Thanks,
Curt

55

This is why this feature isn't done yet. :slight_smile: It's going to take some
thought to make it work properly. We've got it on the short list of
RubyGems 1.0 features.

Chad

···

On Fri, 23 Jul 2004 21:37:59 +0900, Lyle Johnson <lyle.johnson@gmail.com> wrote:

On Fri, 23 Jul 2004 21:26:58 +0900, gabriele renzi > <surrender_it@rc1.vip.ukl.yahoo.com> wrote:

> just one thing: I'm not sure if this is just a sample or is closely
> related to the behaviour of the gem system, but should'nt it be:
>
> Gem::Platform::WIN32::(MS|DJGPP|MINGW|LCC|WHATEVER) ?
>
> different compiling toolchain are things to take in consideration.

Excellent point. I think it's true that binaries compiled with
Microsoft's compiler or the MinGW compiler are compatible with each
other; but I don't know if that's true for the other cases. Yet
another variable to throw in the mix. :wink:

56

Sorry, I forgot to include the download URL:
  
  http://rubyforge.org/frs/?group_id=167

Curt

Curt Hibbs wrote:

···

I just posted a test release of the Ruby Installer for
Windows with the TCL/TK files moved around (hopefully
into their correct locations), plus this version of the
installer does not set any environment variables for TCL.

Since I am completely ignorant of TCL/TK, so I have no
idea whether of not this will work. If you know TCL/TK
please test this version and let me know both ways (if
it works or if it doesn't). If it does not work it
would be particularly useful if you could determine why
and include in your report precisely what should be
changed.

Please send reports to curt at hibbs dot com and
include "RubyTCL" in the subject line so that my
spam filter doesn't delete it.

Thanks,
Curt