[Rubyinstaller-devel] my old gripe :)
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
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.
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
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
> Gordon generously took the time to collect and update the wiki with
> the Roadmap:
>> 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"
> 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?]
=> 'windows' # or :windows
But that would be somewhat kludgey. I'm not sure why core seems
reluctant to make simplifying changes. :)
More information about the Rubyinstaller-devel