[Rubyinstaller-devel] my old gripe :)

Roger Pack rogerpack2005 at gmail.com
Thu Jun 5 19:48:41 EDT 2008

> Is not a window bug "per se" but a implementation bug of
> Ruby+MinGW+Readline, can't complicated to explain, so feel free to dig
> into my mails and look by yourself.
> Again: these ports don't sole the issue, but why you don't ask them
> and see what they answer?
>> Or, as you did before, just release it with the [working] readline.so
>> compiled by MSVC 6 :)
> Again, the test halting is not a problem, only for automated testing,
> again you missed the whole point.
> The readline.so build with MSVC6 segfaul on MinGW Ruby, plain as  
> simple.

I was trying to remember an email sent once to ruby-talk [not the  
sandbox one] where you mentioned a "pre-release" of mingw, which  
passed all the tests.  So I was suggesting [as you already knew] to  
just use that one :)
>> Take care!

> To run the test it automatically add the sandboxed ruby in the path,
> you don't need to do it manually. Also to run the tests there is no
> need to have rubygems into the sandboxed ruby.
sounds like you're on the right path, then.  I was just confused as it  
had changed since the last time I downloaded the sandbox.
> http://dump.mmediasys.com/installer3/
yep that's the one.  Except now I just use a git-clone of the repo, as  
per your suggestion.

> For me, the gcc, make and sh bat files make rubygems tests pass, also
> make mongrel and other gems painless to build without tweaking the
> path.

Sure.  My only fear is that they'll clash with cygwin on some users'  
machines.  Barring that they'll work as good as any, esp. with your  
patch idea.

> Gordon generously took the time to collect and update the wiki with  
> the Roadmap:
> http://rubyinstaller.rubyforge.org/wiki/wiki.pl?Roadmap

Looks great.
>> Could also offer the 'normal' OCI for mingw, too.
> By normal you mean what?

The one you plan on releasing, apparently.  now that I realize there's  
a gem in the works then my comments are moot.
> With this version of One-Click we are trying to avoid the mistakes did
> on the first place. I wouldn't not invest time on something that in
> the long run will be dropped (like a NSIS or InnoSetup script) or
> cannot be easily manageable.
Do you think the IO redirection problem will become a big problem ever?

> Also the approach to bundle everything is not part of our goal right
> now. In any case only gems and extensions bundled in gems will be the
> only components that will be part of this, mainly because they have a
> mechanism to manage them, on the contrary of normal "setup.rb"
> extensions.
sounds good.
> There is a lot of discussion about RUBY_PLATFORM, changes between
> implementations and fixes for the underlying Ruby code to reduce the
> incompatibilities between platforms, so we have our hands busy right
> now, feel free to fork and contribute with your ideas and experiments,
> I'm eager to see what cool ideas can you bring to this project.
Do you have any links for these discussions?  I know my own idea on it  
was rapidly shot down :)
One thought I had was to tell the facets people to implement something  
that yielded something like [Python's?]
require 'facets'
 > OS.os
  => 'windows' # or :windows
 > OS.compiler
  => 'mingw'
 > OS.bits
  => 64

But that would be somewhat kludgey.  I'm not sure why core seems  
reluctant to make simplifying changes. :)

More information about the Rubyinstaller-devel mailing list