[Rubyinstaller-devel] my old gripe :)

Luis Lavena luislavena at gmail.com
Fri Jun 6 11:07:58 EDT 2008


On Fri, Jun 6, 2008 at 4:43 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:
>>> 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'm  having trouble finding an email where you had mentioned "this isn't
> even a release" but it was like stage 2 of the 'get your hands dirty' email
> series.  Does this ring a bell in any way shape or form?   Am I just making
> things up? :)
>

http://blog.mmediasys.com/2008/05/24/random-bits-and-experiments/

Almost before the post end:

"but still will try to keep my pace with rubyinstaller and code some
stuff to do a proper release of new One-Click Installer (yeah, we all
know that a .7z file is not a release)."

There is also an explanation of what this "sandbox" stuff is aimed to:

http://github.com/luislavena/rubyinstaller/tree/master/README.txt

>> 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.
>
> It seems like there already is an 'install' for gem developers.  The
> installer3.  That worked for the rmagick people, at least, and also for a
> friend of mine who compiled eventmachine on it [eventually, once he figured
> out that the paths had to be a certain style].
>

Actually is no "install", it's a "developer sandbox" version of ruby
that preps the environment to work and develop the One-Click Installer
itself, as I commented in the "Get your hands dirty" post. It's aimed
to developers and gem creators that want to see if they tool can work
on MinGW, since most of the latest development and compatibility stuff
happened just for VC, leaving MinGW behind for a lot of time.


>
>>>
>>> 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.
>
> I wonder if it's caused by readline reading always from stdin [well,
> obviously that's the case], but I wonder if they do it poorly.  Oh well if
> it's a minor bug then... :)  The looping cpu thing is a concern, it seems.
>  Was that ever fixed?
>

The CPU usage is not a bug of readline itself, but was fixed in ruby
code in repository, is the w32_rb_select pooling mechanism that
interferes with some Antivirus software. Change or disable your
antirivus and that problem will go away :-P

>
> [If I ever get time, I wonder if something along the following lines would
> be interesting:
> 1) install the marvelous mingw package distributed by OCI.
> 2) install the devkit package distributed by OCI.
> # now here's the fun part:
> 3) gem install mingw_imagemagick_headers # or gem install
> mingw_imagemagick_binaries
> 5) gem install mingw_openssl_src # or gem update
> 4) gem install mingw_git # or mingw_xming, or mingw_...
>

I don't know what you meant with this. Git already have it's own
installer. double package stuff into rubygems is not the purpose of
Rubygems. RubyGems is not a general packaging software, it just to
ease the distribution of libraries and extensions *for Ruby*, not your
operating system.

The "Runtime" part of OCI will be a Windows Installer, so it can be
easily patched with just creating differences across .msi packages.
The same will happen for Developer Kit, as I explained several times.

The thing with RMagick is the way the work with ImageMagick DLL
instead of some statically linked libraries, like wxRuby guys did and
which seems to work ok.

> i.e. use ruby gems as an apt-get style system for mingw progs, since that is
> very lacking for mingw, or is it?  I'm not sure. They definitely lack
> something of ease. :)

apt-get is not the holy grail, you need to leverage in the own OS
tools, so sysadmins of Windows feel confortable to deploy ruby in
corporate environments. Apt-get for windows sounds as bad idea for
them, trust me.

> But I guess the first step is the packages noted on the roadmap.
> This way end users don't have to be developers.  You can just have rubygems
> dependencies which simplify installation.  Of course, this is for non ruby
> apps, but hey :) Just thinking out loud :)

I like to think, but also to experiment, you can try experimenting and
create stuff, doesn't matter if they work out of the box, the
important thing is that you discover truly if they are useful or not,
and get feedback.

Regards,
-- 
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