[Rubyinstaller-devel] my old gripe :)

Luis Lavena luislavena at gmail.com
Fri Jun 6 03:13:52 EDT 2008


On Thu, Jun 5, 2008 at 8:48 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:
>> 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 :)

I asked in ruby-core about some tests that seems to always fails (at
least on windows) there was 3 of them, so we can say it was labeled
"all tests passes".

>> 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.

Yeah, you can see most of the changes are documented into the
changelog file or in the commits logs.

>>
>> 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.
>

The git one contains the source code to build everything, and the
files in the dump sections are packages of that stuff "pre-baked" with
some patches that we sent to ruby-core and got merged in.

>> 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.
>

Unless they have cygwin in the path I don't see a clash there, some
user uses the cygwin-like console like some guys use the MSYS one, so
is not usually in the PATH.

>>
>>> 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.

Again: there will not be a "gem" for the compiler and supporting tools
for GCC, there will be a installer, just like the one we are building
for the Runtime itself.

All the addons or extensions will be added using rubygems as manager
to avoid leave files "orphaned" between updates.

>>
>> 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?
>

Haven't encountered anyone with this problem, but never heard back
from ruby-core about this behavior.

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

The RUBY_PLATFORM stuff is about to be standarized:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17116

But there should be some discussion about it that I didn't had time to
tackle and shoot my thoughts about it.

I can collect some of the mailing lists posts but you must indulge me
since I'm getting used to a new timezone and working hours (just
arrived to Paris 2 days ago)... let me collect that during the
weekend.

> 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

Similar to the stuff the Platform gem is providing right now, and too
similar to what Rubinius guys did (Rubinius::COMPILER)

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

I think that will be rejected even before you hit send. But maybe we
can all workout some sort of solution. In any case, will look into
that topic after get some feedback about RUBY_PLATFORM discussion.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams


More information about the Rubyinstaller-devel mailing list