in other related news... now that github can host some gems http://gems.github.com/ maybe we should just post ''mingw'' friendly gems there of the things that we like. like mongrel, mysql, ruby-debug, eventmachine, etc.? Then we would only have to have one person build it once and [phew] the rest of us could use it :)
as a note, here are mingw instructions for rmagick http://rubyforge.org/forum/message.php?msg_id=55720 On Tue, Jun 3, 2008 at 1:08 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> in other related news... > now that github can host some gems > http://gems.github.com/ > maybe we should just post ''mingw'' friendly gems there of the things > that we like. > like mongrel, mysql, ruby-debug, eventmachine, etc.? > Then we would only have to have one person build it once and [phew] > the rest of us could use it :) >
I''m slightly confused as to how to use gems with the latest git mingw
installer.
I''d think that I should be able to run
c:\dev\latest\rubyinstaller\sandbox> rubygems_mingw\bin\gem.bat list
and it would show ''no gems listed''
It defaults instead to using the installed msvc ruby.exe
Glancing at it I assume we have to install to c:\Ruby now?
Here''s my attempt to run it with the right ruby.exe
c:\dev\latest\rubyinstaller\sandbox>ruby_mingw\bin\ruby.exe
rubygems_mingw\bin\gem
rubygems_mingw/bin/gem:8:in `require'': no such file to load --
rubygems (LoadError)
from rubygems_mingw/bin/gem:8
As a side note, you may also you may want to consider a few more
explicit directory names, since they were somewhat confusing to me
this [and every] time.
ruby_1_8 -> ruby_1_8_src
rubygems -> rubygems_src
To avoid confusion.
I could do it if you want.
Thanks!
-R
On Tue, Jun 3, 2008 at 5:33 PM, Roger Pack
<roger.pack at leadmediapartners.com> wrote:> thanks.
> I took the liberty of doing some readline research. Probably all
> useless, but...
> http://betterlogic.com/roger/?p=312
> there they are. I might try them out sometime. If I
>
> Note that I get the same hmac segfault using a clone of the github repo.
> -R
>
>
> On Tue, Jun 3, 2008 at 5:07 PM, Luis Lavena <luislavena at gmail.com>
wrote:
>> On Tue, Jun 3, 2008 at 8:00 PM, Roger Pack
>> <roger.pack at leadmediapartners.com> wrote:
>>> could you drop me a link to the discussion?
>>
>>
http://rubyforge.org/pipermail/rubyinstaller-devel/2008-April/000288.html
>>
>> And before I run out of battery, grab the tarball from github and use
>> that instead:
>>
>> http://github.com/luislavena/rubyinstaller/
>>
>> --
>> 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
>>
>
On Tue, Jun 3, 2008 at 7:11 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> I''m slightly confused as to how to use gems with the latest git mingw installer. > > I''d think that I should be able to run > > c:\dev\latest\rubyinstaller\sandbox> rubygems_mingw\bin\gem.bat list > > and it would show ''no gems listed'' > It defaults instead to using the installed msvc ruby.exe > Glancing at it I assume we have to install to c:\Ruby now? > > Here''s my attempt to run it with the right ruby.exe > > c:\dev\latest\rubyinstaller\sandbox>ruby_mingw\bin\ruby.exe > rubygems_mingw\bin\gem > rubygems_mingw/bin/gem:8:in `require'': no such file to load -- > rubygems (LoadError) > from rubygems_mingw/bin/gem:8 >>From what I understand, the rubygems install was moved out of the rubyinstall to facilitate the MSI creation, as ruby and rubygems will be listed as seperate features in the installer (or at least the Wix files refer to them as features). During the MSI installation process, they would both be installed to the same location. To run it, you could copy the contents of rubygems_mingw into ruby_mingw. Of course, that''s kind of hacky. Another option would be to flesh out the Wix automation, so that you can build the MSI package and install it via Rake ;-)> As a side note, you may also you may want to consider a few more > explicit directory names, since they were somewhat confusing to me > this [and every] time. > ruby_1_8 -> ruby_1_8_src > rubygems -> rubygems_src > > To avoid confusion. > I could do it if you want.This was confusing to me too at first, but I''ve just been staring at it a lot and the confusion went away ;-). I certainly wouldn''t be opposed to a change.> Thanks! > -R >Hope that helps, Gordon
On Tue, Jun 3, 2008 at 11:47 PM, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote:> On Tue, Jun 3, 2008 at 7:11 PM, Roger Pack > <roger.pack at leadmediapartners.com> wrote: >> I''m slightly confused as to how to use gems with the latest git mingw installer. >> >> I''d think that I should be able to run >> >> c:\dev\latest\rubyinstaller\sandbox> rubygems_mingw\bin\gem.bat listI also meant to say that up until the recent split of ruby_mingw and rubygems_mingw folders, I was testing by just changing my path env variable. I have a batch script that removes the installed ruby and adds the sandbox ruby to path. This only effects the current command session, so no harm done. And, you can just type:>gem listand it will use the sandbox ruby.
On Tue, Jun 3, 2008 at 9:11 PM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> I''m slightly confused as to how to use gems with the latest git mingw installer. > > I''d think that I should be able to run > > c:\dev\latest\rubyinstaller\sandbox> rubygems_mingw\bin\gem.bat list >For the ruby interpreter to work you need ''bin'' folder in the PATH There was a change in rubygems between 1.0 and 1.1 to allow installation of gems outside the default gem home.> and it would show ''no gems listed'' > It defaults instead to using the installed msvc ruby.exe > Glancing at it I assume we have to install to c:\Ruby now? > > Here''s my attempt to run it with the right ruby.exe > > c:\dev\latest\rubyinstaller\sandbox>ruby_mingw\bin\ruby.exe > rubygems_mingw\bin\gem > rubygems_mingw/bin/gem:8:in `require'': no such file to load -- > rubygems (LoadError) > from rubygems_mingw/bin/gem:8 > > > As a side note, you may also you may want to consider a few more > explicit directory names, since they were somewhat confusing to me > this [and every] time. > ruby_1_8 -> ruby_1_8_src > rubygems -> rubygems_src >That is doable.> To avoid confusion. > I could do it if you want.Please, feel free to fork rubyinstaller repository at github and test it by yourself, then send me a pull request. I don''t have enough time (or battery) right now to do it. -- 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
> 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?RoadmapLooks 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. :) -R
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 > => 64Similar 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
>> 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? :)> Yeah, you can see most of the changes are documented into the > changelog file or in the commits logs.thanks> 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].>> >> 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? -R PS [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.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. :) 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 :)
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