From roger.pack at leadmediapartners.com Mon Nov 3 16:16:49 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Mon, 3 Nov 2008 14:16:49 -0700 Subject: [Rubyinstaller-devel] RC 1 thought Message-ID: <966599840811031316t78784f64m4013f3df5e9011f8@mail.gmail.com> Perhaps it could be bundled with rubygems 3.1 when it is completed? Also while I'm at it...here's a thought for the mingw distro: also have an optional barebones version [no rdoc, ri]. and a 1.9 version :) maybe just skip 1.8.7? -- Thanks! -=R From luislavena at gmail.com Mon Nov 3 16:19:14 2008 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 3 Nov 2008 18:19:14 -0300 Subject: [Rubyinstaller-devel] RC 1 thought In-Reply-To: <966599840811031316t78784f64m4013f3df5e9011f8@mail.gmail.com> References: <966599840811031316t78784f64m4013f3df5e9011f8@mail.gmail.com> Message-ID: <71166b3b0811031319l49bfbc9dsacac53fd8ed28f6e@mail.gmail.com> On Mon, Nov 3, 2008 at 6:16 PM, Roger Pack wrote: > Perhaps it could be bundled with rubygems 3.1 when it is completed? > I waiting to bundle Rake 0.8.4, which is about to be released and include several patches for Windows. > Also while I'm at it...here's a thought for the mingw distro: > > also have an optional barebones version [no rdoc, ri]. > No rdoc and no ri for it, CHM files all the way ;-) > and a 1.9 version :) > Yes. > maybe just skip 1.8.7? No 1.8.7, we hear you :-) Working on this: http://gist.github.com/21857 Right after, jumping to make this other "snip" a reality: http://gist.github.com/19707 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 From roger.pack at leadmediapartners.com Mon Nov 3 18:41:36 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Mon, 3 Nov 2008 16:41:36 -0700 Subject: [Rubyinstaller-devel] err on build Message-ID: <966599840811031541o359d57c7id1b46f928a5b5aa6@mail.gmail.com> I'll probably look into this sometime. after doing git clone, rake ... ** Invoke sandbox/ruby_mingw (not_needed) ** Execute tools:rubygems:install cd sandbox/rubygems ruby setup.rb install --no-ri --no-rdoc --destdir=c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw mkdir -p c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw/c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/site_ruby/1.8 c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:243:in `mkdir': Invalid argument - c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw/c: (Errno::EINVAL) from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:243:in `fu_mkdir' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:217:in `mkdir_p' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:215:in `reverse_each' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:215:in `mkdir_p' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:201:in `each' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:201:in `mkdir_p' from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:1527:in `mkdir_p' from setup.rb:141 rake aborted! Command failed with status (1): [ruby setup.rb install --no-ri --no-rdoc --...] c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:971:in `sh' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `call' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `sh' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `sh' c:/dev/rubyinstaller_clone/recipes/tools/rubygems.rake:58 c:/Ruby18/lib/ruby/1.8/fileutils.rb:121:in `chdir' c:/Ruby18/lib/ruby/1.8/fileutils.rb:121:in `cd' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `cd' c:/dev/rubyinstaller_clone/recipes/tools/rubygems.rake:57 c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/1.8/monitor.rb:242:in `synchronize' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in `invoke_prerequisites' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `invoke_prerequisites' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/1.8/monitor.rb:242:in `synchronize' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in `invoke_prerequisites' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `invoke_prerequisites' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/1.8/monitor.rb:242:in `synchronize' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run' c:/Ruby18/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31 c:/Ruby18/bin/rake:19:in `load' c:/Ruby18/bin/rake:19 c:\dev\rubyinstaller_clone> -- Thanks! -=R From luislavena at gmail.com Tue Nov 4 05:33:05 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 4 Nov 2008 07:33:05 -0300 Subject: [Rubyinstaller-devel] err on build In-Reply-To: <966599840811031541o359d57c7id1b46f928a5b5aa6@mail.gmail.com> References: <966599840811031541o359d57c7id1b46f928a5b5aa6@mail.gmail.com> Message-ID: <71166b3b0811040233k2022767fud502167f6f6052ca@mail.gmail.com> On Mon, Nov 3, 2008 at 8:41 PM, Roger Pack wrote: > I'll probably look into this sometime. > after doing git clone, rake > > > ... > ** Invoke sandbox/ruby_mingw (not_needed) > ** Execute tools:rubygems:install > cd sandbox/rubygems > ruby setup.rb install --no-ri --no-rdoc > --destdir=c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw > mkdir -p c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw/c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/site_ruby/1.8 > c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:243:in > `mkdir': Invalid argument - > c:/dev/rubyinstaller_clone/sandbox/rubygems_mingw/c: (Errno::EINVAL) > from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:243:in > `fu_mkdir' > from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:217:in > `mkdir_p' > from c:/dev/rubyinstaller_clone/sandbox/ruby_mingw/lib/ruby/1.8/fileutils.rb:215:in > `reverse_each' Yup, that's RubyGems. I have some patches in my local branch that didn't push yet, was waiting for 1.3.1 to come out. -- 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 From roger.pack at leadmediapartners.com Wed Nov 5 18:06:46 2008 From: roger.pack at leadmediapartners.com (Roger Pack) Date: Wed, 5 Nov 2008 16:06:46 -0700 Subject: [Rubyinstaller-devel] RC 1 thought In-Reply-To: <71166b3b0811031319l49bfbc9dsacac53fd8ed28f6e@mail.gmail.com> References: <966599840811031316t78784f64m4013f3df5e9011f8@mail.gmail.com> <71166b3b0811031319l49bfbc9dsacac53fd8ed28f6e@mail.gmail.com> Message-ID: <966599840811051506s30e64b6bxec5630958a02901b@mail.gmail.com> > No rdoc and no ri for it, CHM files all the way ;-) That's intense :) > http://gist.github.com/21857 > > Right after, jumping to make this other "snip" a reality: > > http://gist.github.com/19707 Kool. Add a section for dependencies and maybe we'll have a sweet mingwport install system :) I have noticed that mingw is pretty popular for cross-platform compiles--vlc uses it, git uses it...it seems to not be all that bad, so the move to mingw might have been a good choice :) [of course, I just use it for the speed :) ] re: install difficulties--let me know when a new version goes up or maybe you could create a temporary branch with the necessary patches? Thanks. -=R From luislavena at gmail.com Wed Nov 5 18:20:24 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 5 Nov 2008 20:20:24 -0300 Subject: [Rubyinstaller-devel] RC 1 thought In-Reply-To: <966599840811051506s30e64b6bxec5630958a02901b@mail.gmail.com> References: <966599840811031316t78784f64m4013f3df5e9011f8@mail.gmail.com> <71166b3b0811031319l49bfbc9dsacac53fd8ed28f6e@mail.gmail.com> <966599840811051506s30e64b6bxec5630958a02901b@mail.gmail.com> Message-ID: <71166b3b0811051520n3a2ceb0enc75298fa86fadf31@mail.gmail.com> On Wed, Nov 5, 2008 at 8:06 PM, Roger Pack wrote: >> No rdoc and no ri for it, CHM files all the way ;-) > That's intense :) > yup, thanks Gordon for working on these tasks. >> http://gist.github.com/21857 >> >> Right after, jumping to make this other "snip" a reality: >> >> http://gist.github.com/19707 > > Kool. Add a section for dependencies and maybe we'll have a sweet > mingwport install system :) > the dependencies will only resolve to other packages defined inside rubyinstaller. *I* don't want to conquer the world. > I have noticed that mingw is pretty popular for cross-platform > compiles--vlc uses it, git uses it...it seems to not be all that bad, > so the move to mingw might have been a good choice :) [of course, I > just use it for the speed :) ] > Yup, is not only speed, but nified build and compilation process. Btw, I'm pretty much slowed rubyinstaller development due rake-compiler: (no docs yet, shame on me). http://github.com/luislavena/rake-compiler/ The goal is add native packaging and later cross platform building using mingw32. > re: install difficulties--let me know when a new version goes up or > maybe you could create a temporary branch with the necessary patches? > Cool, planned a hacking session with a colleague this sunday for One-Click, keep you posted. -- 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 From rogerpack2005 at gmail.com Thu Nov 6 15:51:56 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Thu, 6 Nov 2008 13:51:56 -0700 Subject: [Rubyinstaller-devel] autoconf 1.6 Message-ID: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> Would there be any problem with upgrading the autoconf version in the git mingw version to 1.6? I think it's like 1.59 now. Thanks! -=R From luislavena at gmail.com Thu Nov 6 19:06:29 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 6 Nov 2008 21:06:29 -0300 Subject: [Rubyinstaller-devel] autoconf 1.6 In-Reply-To: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> References: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> Message-ID: <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> On Thu, Nov 6, 2008 at 5:51 PM, Roger Pack wrote: > Would there be any problem with upgrading the autoconf version in the > git mingw version to 1.6? I think it's like 1.59 now. > Thanks! I had various problems using 1.6 when building 1.8.6 and 1.9 from trunk. For several reasons the generated configure scripts and the resulting makefiles just blow up. This also happened with usage of mingw-make (that's why we use msys-make). -- 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 From rogerpack2005 at gmail.com Fri Nov 7 11:47:51 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 7 Nov 2008 09:47:51 -0700 Subject: [Rubyinstaller-devel] autoconf 1.6 In-Reply-To: <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> References: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> Message-ID: <966599840811070847x6d43dbadoac38896555935d58@mail.gmail.com> > I had various problems using 1.6 when building 1.8.6 and 1.9 from > trunk. For several reasons the generated configure scripts and the > resulting makefiles just blow up. Hmm. That stinks. I wonder if building it from straight source would help [?] I should try it out sometime. -=R http://thread.gmane.org/gmane.comp.gnu.mingw.user/22580 mentions some weirdness... From rogerpack2005 at gmail.com Fri Nov 7 11:49:44 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 7 Nov 2008 09:49:44 -0700 Subject: [Rubyinstaller-devel] autoconf 1.6 In-Reply-To: <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> References: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> Message-ID: <966599840811070849q6d997b9fibf698dab25075cf0@mail.gmail.com> > I had various problems using 1.6 when building 1.8.6 and 1.9 from > trunk. For several reasons the generated configure scripts and the > resulting makefiles just blow up. > > This also happened with usage of mingw-make (that's why we use msys-make). So is there any way to build from SVN TRUNK or is it best to just use nightly snapshots? Thanks! -=R From luislavena at gmail.com Fri Nov 7 12:10:00 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 7 Nov 2008 14:10:00 -0300 Subject: [Rubyinstaller-devel] autoconf 1.6 In-Reply-To: <966599840811070849q6d997b9fibf698dab25075cf0@mail.gmail.com> References: <966599840811061251s79560328v3556e2456852e7df@mail.gmail.com> <71166b3b0811061606j1d114c25r9ad5bc8d4cfc8b4e@mail.gmail.com> <966599840811070849q6d997b9fibf698dab25075cf0@mail.gmail.com> Message-ID: <71166b3b0811070910m19015a1cie65460b4c7bbbfb1@mail.gmail.com> On Fri, Nov 7, 2008 at 1:49 PM, Roger Pack wrote: >> I had various problems using 1.6 when building 1.8.6 and 1.9 from >> trunk. For several reasons the generated configure scripts and the >> resulting makefiles just blow up. >> >> This also happened with usage of mingw-make (that's why we use msys-make). > > So is there any way to build from SVN TRUNK or is it best to just use > nightly snapshots? rake CHECKOUT=1 It will use the svn ruby_1_8_6 branch, not 1.9 or other. That's on ruby_installer.rb under checkout URLs (that pretty much sucks, almost done with rake-compiler to jump into the installer dsl). HTH, -- 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 From rogerpack2005 at gmail.com Fri Nov 7 21:38:57 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 7 Nov 2008 19:38:57 -0700 Subject: [Rubyinstaller-devel] RC1 feedback Message-ID: <966599840811071838n5af2ebf7i999144bbac5e2c7c@mail.gmail.com> so the enable rubygems checkbox actually means "enable rubygems for all programs" is that right? [I thought it might mean "install rubygems" like the mingw installer--might be nice to clarify that]. Also might be better to add the install\bin path to the end of the path [though not sure if it's better]... That's my feedback :) Thanks! -=R From luislavena at gmail.com Fri Nov 7 23:10:08 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 8 Nov 2008 01:10:08 -0300 Subject: [Rubyinstaller-devel] RC1 feedback In-Reply-To: <966599840811071838n5af2ebf7i999144bbac5e2c7c@mail.gmail.com> References: <966599840811071838n5af2ebf7i999144bbac5e2c7c@mail.gmail.com> Message-ID: <71166b3b0811072010y4639d0dcq73457865eafb0a42@mail.gmail.com> On Fri, Nov 7, 2008 at 11:38 PM, Roger Pack wrote: > so the enable rubygems checkbox actually means "enable rubygems for > all programs" is that right? [I thought it might mean "install > rubygems" like the mingw installer--might be nice to clarify that]. > Also might be better to add the install\bin path to the end of the > path [though not sure if it's better]... > That's my feedback :) > Eh, I appreciate your feedback Roger, but don't mess with by brain friday night :-) The RC1 checkbox is teh dreaded RUBYOPT environment variable, which I changed from default on to off, since was generating issues with other implementations and even the installation of rubygems itself. The MinGW is a work in progress, don't expect too much similarities between the two, and don't expect the installer itself will be in the same way like it is now. There is no environment variable change in MinGW version since I believe is not production quality and right now I'm not taking responsibility for it :-D (actually I am, but don't tell anyone). ;-) There is plan to put that as user level or system level, but not right now. I believe will be better get the platform working that worring about the PATH right now. > Thanks! > -=R Thank you again for the feedback, we should put all this in a todo list :-) -- 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 From rogerpack2005 at gmail.com Sat Nov 8 00:53:30 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 7 Nov 2008 22:53:30 -0700 Subject: [Rubyinstaller-devel] RC1 feedback In-Reply-To: <71166b3b0811072010y4639d0dcq73457865eafb0a42@mail.gmail.com> References: <966599840811071838n5af2ebf7i999144bbac5e2c7c@mail.gmail.com> <71166b3b0811072010y4639d0dcq73457865eafb0a42@mail.gmail.com> Message-ID: <966599840811072153i3a060db6rf8572662fcc9a49d@mail.gmail.com> > Eh, I appreciate your feedback Roger, but don't mess with by brain > friday night :-) sorry! lol > > The RC1 checkbox is teh dreaded RUBYOPT environment variable, which I > changed from default on to off, since was generating issues with other > implementations and even the installation of rubygems itself. Yeah...I might be tempted to suggest a change to be more explicit about what that checkbox does :) Also...does this work for anybody with any version on windows? a = File.new 'a', 'w' a.write_nonblock 'test' ? Thanks! -=R From rogerpack2005 at gmail.com Sat Nov 8 02:19:35 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Sat, 8 Nov 2008 00:19:35 -0700 Subject: [Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw... In-Reply-To: <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811061353r2132c78dlcb3a9405a57be5a0@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> Message-ID: <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> Anybody run into similar errors to these before? (these while building rev on mingw) gcc -shared -s -o rev_ext.so rev_buffer.o rev_ext.o rev_io_watcher.o rev_loop.o rev_ssl.o rev_timer_watcher.o rev_utils.o rev_watcher.o -L. -Lc:/Ruby18/lib -L. -Wl,--enable-auto-image-base,--enable-auto-import,--export-all -lmsvcrt-ruby18 -lshell32 -lws2_32 -lssl -lcrypto rev_ssl.o: In function `Rev_SSL_IO_ssl_setup': c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference to `ossl_ssl_ex_ptr_idx' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:132: undefined reference to `ossl_ssl_ex_vcb_idx' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:134: undefined reference to `ossl_ssl_ex_client_cert_cb_idx' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:136: undefined reference to `ossl_ssl_ex_tmp_dh_callback_idx' c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:121: undefined reference to `ossl_raise' collect2: ld returned 1 exit status Also...this is what I currently get with "rake test"... 1607 tests, 15690 assertions, 8 failures, 50 errors I suppose that the glimmer of good news is that mingw passes all the tests for 1.9 :) Thanks for your help. I would fork and do pull requests but have yet to figure out how to get mingw git to use private keys... -=R From rogerpack2005 at gmail.com Sat Nov 8 02:45:42 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Sat, 8 Nov 2008 00:45:42 -0700 Subject: [Rubyinstaller-devel] [Rev-talk] latest on windows mingw... In-Reply-To: <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> Message-ID: <966599840811072345v79052461wb624e2f184075794@mail.gmail.com> > I would fork and do pull requests but have yet to figure out how to > get mingw git to use private keys... K got a fork to work, but...now the second I check it out and do git status it shows C:\dev\rubyinstaller_my_fork>git status C:\dev\rubyinstaller_my_fork>"c:\Program Files\Git_here"\bin\git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # # modified: resources/installer/devkit.wxi # modified: resources/installer/mingw.wxs # modified: resources/installer/msys.wxs # modified: resources/installer/msys_stubs.wxs # modified: resources/installer/ruby_bin.wxs # modified: resources/installer/ruby_lib.wxs # modified: resources/installer/rubygems_bin.wxs # modified: resources/installer/rubygems_lib.wxs # modified: resources/msys_stubs/bin/gcc.bat # modified: resources/msys_stubs/bin/make.bat # modified: resources/msys_stubs/bin/sh.bat I think maybe it's tweaking the line endings on their way in. Will that be a problem? Can I avoid that? Thanks for your help with this. In other news sometimes I have the weird "csrss+irb using 100% cpu even on a computer with no virus scanner--but currently only with 1.8.6 and not with 1.9. Odd. -=R From luislavena at gmail.com Sat Nov 8 09:43:33 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 8 Nov 2008 11:43:33 -0300 Subject: [Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw... In-Reply-To: <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> Message-ID: <71166b3b0811080643y7c11e3b8o5183fcde7f868c0d@mail.gmail.com> On Sat, Nov 8, 2008 at 4:19 AM, Roger Pack wrote: > Anybody run into similar errors to these before? (these while building > rev on mingw) > > gcc -shared -s -o rev_ext.so rev_buffer.o rev_ext.o rev_io_watcher.o > rev_loop.o rev_ssl.o rev_timer_watcher.o rev_utils.o rev_watcher.o -L. > -Lc:/Ruby18/lib -L. > -Wl,--enable-auto-image-base,--enable-auto-import,--export-all > -lmsvcrt-ruby18 -lshell32 -lws2_32 -lssl -lcrypto > rev_ssl.o: In function `Rev_SSL_IO_ssl_setup': > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference > to `ossl_ssl_ex_ptr_idx' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:132: undefined reference > to `ossl_ssl_ex_vcb_idx' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:134: undefined reference > to `ossl_ssl_ex_client_cert_cb_idx' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:136: undefined reference > to `ossl_ssl_ex_tmp_dh_callback_idx' > c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:121: undefined reference > to `ossl_raise' > collect2: ld returned 1 exit status > Maybe the OpenSSL version used by RubyInstaller is not the same one expected by Rev? > Also...this is what I currently get with "rake test"... > > 1607 tests, 15690 assertions, 8 failures, 50 errors > That's rubyinstaller tests? so we have now 8 failures... was 5 last time. > I suppose that the glimmer of good news is that mingw passes all the > tests for 1.9 :) > Cool! > Thanks for your help. > I would fork and do pull requests but have yet to figure out how to > get mingw git to use private keys... > msysgit + pageant for your keys and ensure GIT_SSH is set and point to the full path of plink.exe (e.g. C:\Program Files\PuTTY\plink.exe) or you can generate a pair of keys with ssh-keygen inside the bash environment of msysGit and use ssh. -- 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 From luislavena at gmail.com Sat Nov 8 09:46:27 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 8 Nov 2008 11:46:27 -0300 Subject: [Rubyinstaller-devel] [Rev-talk] latest on windows mingw... In-Reply-To: <966599840811072345v79052461wb624e2f184075794@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> <966599840811072345v79052461wb624e2f184075794@mail.gmail.com> Message-ID: <71166b3b0811080646s201adb7cxb1ee41a12ebb2e3f@mail.gmail.com> On Sat, Nov 8, 2008 at 4:45 AM, Roger Pack wrote: >> I would fork and do pull requests but have yet to figure out how to >> get mingw git to use private keys... > > K got a fork to work, but...now the second I check it out and do git > status it shows > > > C:\dev\rubyinstaller_my_fork>git status > > C:\dev\rubyinstaller_my_fork>"c:\Program Files\Git_here"\bin\git status > # On branch master > # Changed but not updated: > # (use "git add ..." to update what will be committed) > # > # modified: resources/installer/devkit.wxi > # modified: resources/installer/mingw.wxs > # modified: resources/installer/msys.wxs > # modified: resources/installer/msys_stubs.wxs > # modified: resources/installer/ruby_bin.wxs > # modified: resources/installer/ruby_lib.wxs > # modified: resources/installer/rubygems_bin.wxs > # modified: resources/installer/rubygems_lib.wxs > # modified: resources/msys_stubs/bin/gcc.bat > # modified: resources/msys_stubs/bin/make.bat > # modified: resources/msys_stubs/bin/sh.bat > > I think maybe it's tweaking the line endings on their way in. > > Will that be a problem? Can I avoid that? > Thanks for your help with this. > OMG, another victim of autocrlf! please, in your .gitconfig file for your user set: [core] autocrlf = false And do the clone again. the msysGit guys thinks is cool do that magic trick in the background, but is not. > In other news sometimes I have the weird "csrss+irb using 100% cpu > even on a computer with no virus scanner--but currently only with > 1.8.6 and not with 1.9. Odd. That's odd, never got that, and even I'm suing NOD32. Maybe there are other roots for that issue that we must investigate. I'll bet is related to readline, but who knows :-P -- 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 From rogerpack2005 at gmail.com Sat Nov 8 23:05:58 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Sat, 8 Nov 2008 21:05:58 -0700 Subject: [Rubyinstaller-devel] [Rev-talk] latest on windows mingw... In-Reply-To: <71166b3b0811080646s201adb7cxb1ee41a12ebb2e3f@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> <966599840811072345v79052461wb624e2f184075794@mail.gmail.com> <71166b3b0811080646s201adb7cxb1ee41a12ebb2e3f@mail.gmail.com> Message-ID: <966599840811082005o4c222ff4vd495bdf61238dadb@mail.gmail.com> > please, in your .gitconfig file for your user set: > > [core] > autocrlf = false Cool thought it might be that. I'll try that instead :) note that it appears the .gitconfig file for mingw git is c:\documents and and settings\username\.gitconfig # or is it \git\.config and that in order to add to it using "git config" you may need to create the .git file [or some file or other] by hand first. Yipes. > That's odd, never got that, and even I'm suing NOD32. Maybe there are > other roots for that issue that we must investigate. I'll bet is > related to readline, but who knows :-P I should look at it sometime. strace only reveals: [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 [T1400] LeaveCriticalSection(77c61a88, 2462038, 77c2eaff, 3, ...) = 0 [T1400] GetCurrentThreadId(2461b40, 246ffe0, 2461f58, 66b97ea9, ...) = 578 [T1400] EnterCriticalSection(77c61a88, 29b20d0, 2462038, 77c2eaf1, ...) = 0 [T1400] GetNumberOfConsoleInputEvents(f, 2461f20, 2bb0720, 29b20d0, ...) = 1 [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 [T1400] LeaveCriticalSection(77c61a88, 2462038, 77c2eaff, 3, ...) = 0 [T1400] GetCurrentThreadId(2461b40, 246ffe0, 2461f58, 66b97ea9, ...) = 578 [T1400] EnterCriticalSection(77c61a88, 29b20d0, 2462038, 77c2eaf1, ...) = 0 [T1400] GetNumberOfConsoleInputEvents(f, 2461f20, 2bb0720, 29b20d0, ...) = 1 [T1400] PeekConsoleInputA(f, 2461ec8, 3, 2461f1c, ...) = 1 repeated and repeated...hmm. ruby-prof might help me here. Thanks for your help. Hopefully sometime I'll get an up to date version to test :) Any ideas why c:/dev/downloads/rev_clone/ext/rev/rev_ssl.c:130: undefined reference > to `ossl_ssl_ex_ptr_idx' might occur in windows not linux? -=R From rogerpack2005 at gmail.com Mon Nov 10 02:41:15 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Mon, 10 Nov 2008 00:41:15 -0700 Subject: [Rubyinstaller-devel] current mingw make test results Message-ID: <966599840811092341p38924168r6d096b643ec78944@mail.gmail.com> I assume these errors are common? for the default [from git--1.8.6] 1607 tests, 15685 assertions, 5 failures, 72 errors (lots of soap errors) and for the same with rake CHECKOUT=1 1632 tests, 16038 assertions, 6 failures, 0 errors sometimes 5 failures, sometimes 6. I assume the ssl error [the 6th] is timing related? [like the server closes too fast in some instances or something?] It seems hard to reproduce. Do you think the rest of these are bugs in ruby or in ruby mingw? I'm afraid I'll hurt the MSVC distro if I try and fix them :) As a side note, I also get the old "mingw -e quoted fails" stuff just like I used to--I knew I wasn't going crazy :) ruby 1.8.6 (2008-07-17 patchlevel 279) [i386-mingw32] ruby -e "20.times { \"a\"}" -e:1: syntax error, unexpected tSTRING_BEG, expecting $end 20.times { "a"}"? Thanks. -=R From rogerpack2005 at gmail.com Tue Nov 11 02:33:27 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Tue, 11 Nov 2008 00:33:27 -0700 Subject: [Rubyinstaller-devel] Fwd: [Rev-talk] latest on windows mingw... In-Reply-To: <71166b3b0811080643y7c11e3b8o5183fcde7f868c0d@mail.gmail.com> References: <966599840811061124k1300c5abid767abccdd058ca5@mail.gmail.com> <966599840811071733w74ef83f0h5e4e48c1bca7ba8e@mail.gmail.com> <966599840811071752w7984c5e9x192c069ba060ad84@mail.gmail.com> <966599840811071842g6f674558x9e8b2764519097ff@mail.gmail.com> <966599840811071848u780b3707rd513f32dc81d84a9@mail.gmail.com> <966599840811071850l4f639057l4c901af231775c39@mail.gmail.com> <966599840811072319t2593a28dy2acef24bf12b0083@mail.gmail.com> <71166b3b0811080643y7c11e3b8o5183fcde7f868c0d@mail.gmail.com> Message-ID: <966599840811102333g2bacffbfrb542ec2cf87e4829@mail.gmail.com> > That's rubyinstaller tests? so we have now 8 failures... was 5 last time. Yeah I get 5 now :) >> I suppose that the glimmer of good news is that mingw passes all the >> tests for 1.9 :) >> > > Cool! I have been having fun trying to figure out how to get 1.9 to compile without cygwin help. I think you can hack it to work. [i.e. run make, then when it errs, run make in the extension directories one by one, then make install]. I should look more closely at the 1.8 recipes and see if they'd help me out In other news 1.9 mingw passes 'make test' [all 918] but errs on some make test-all. Well we do what we can :) Thanks for your help on this. Hopefully it will make a bigger and badder ruby for all of us. I'd be happy to hack on some of the 1.8.7 errors--I just need approval that I'm not breaking something by fixing them :) -=R From luislavena at gmail.com Thu Nov 13 06:03:23 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Nov 2008 08:03:23 -0300 Subject: [Rubyinstaller-devel] current mingw make test results In-Reply-To: <966599840811092341p38924168r6d096b643ec78944@mail.gmail.com> References: <966599840811092341p38924168r6d096b643ec78944@mail.gmail.com> Message-ID: <71166b3b0811130303p657fc9a9ue84fa7e3cc0a9211@mail.gmail.com> On Mon, Nov 10, 2008 at 4:41 AM, Roger Pack wrote: > I assume these errors are common? > > for the default [from git--1.8.6] > > 1607 tests, 15685 assertions, 5 failures, 72 errors (lots of soap errors) > > and for the same with rake CHECKOUT=1 > > 1632 tests, 16038 assertions, 6 failures, 0 errors > > sometimes 5 failures, sometimes 6. I assume the ssl error [the 6th] > is timing related? [like the server closes too fast in some instances > or something?] It seems hard to reproduce. > > Do you think the rest of these are bugs in ruby or in ruby mingw? > I'm afraid I'll hurt the MSVC distro if I try and fix them :) > > As a side note, I also get the old "mingw -e quoted fails" stuff just > like I used to--I knew I wasn't going crazy :) > > ruby 1.8.6 (2008-07-17 patchlevel 279) [i386-mingw32] > > ruby -e "20.times { \"a\"}" > -e:1: syntax error, unexpected tSTRING_BEG, expecting $end > 20.times { "a"}"? > > Thanks. > -=R Can you tell me which console are you using? which codepage? I tried to reproduce your problem several times without luck. Used standard command prompt and Console2 The only one I didn't tried is rxvt with bash since they have serious issues (I suggest you use directly bash with console2 to get a nicer tabbed console). -- 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 From rogerpack2005 at gmail.com Thu Nov 13 18:05:15 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Thu, 13 Nov 2008 16:05:15 -0700 Subject: [Rubyinstaller-devel] current mingw make test results In-Reply-To: <71166b3b0811130303p657fc9a9ue84fa7e3cc0a9211@mail.gmail.com> References: <966599840811092341p38924168r6d096b643ec78944@mail.gmail.com> <71166b3b0811130303p657fc9a9ue84fa7e3cc0a9211@mail.gmail.com> Message-ID: <966599840811131505u35079db9x4e2651b20890b198@mail.gmail.com> Yeah it's just cmd.exe +- console2. Good news is that I don't think anything else is broke so it's not a biggie. Not sure exactly why it's caused. Thanks! -=R On Thu, Nov 13, 2008 at 4:03 AM, Luis Lavena wrote: > On Mon, Nov 10, 2008 at 4:41 AM, Roger Pack wrote: >> I assume these errors are common? >> >> for the default [from git--1.8.6] >> >> 1607 tests, 15685 assertions, 5 failures, 72 errors (lots of soap errors) >> >> and for the same with rake CHECKOUT=1 >> >> 1632 tests, 16038 assertions, 6 failures, 0 errors >> >> sometimes 5 failures, sometimes 6. I assume the ssl error [the 6th] >> is timing related? [like the server closes too fast in some instances >> or something?] It seems hard to reproduce. >> >> Do you think the rest of these are bugs in ruby or in ruby mingw? >> I'm afraid I'll hurt the MSVC distro if I try and fix them :) >> >> As a side note, I also get the old "mingw -e quoted fails" stuff just >> like I used to--I knew I wasn't going crazy :) >> >> ruby 1.8.6 (2008-07-17 patchlevel 279) [i386-mingw32] >> >> ruby -e "20.times { \"a\"}" >> -e:1: syntax error, unexpected tSTRING_BEG, expecting $end >> 20.times { "a"}"? >> >> Thanks. >> -=R > > > Can you tell me which console are you using? which codepage? I tried > to reproduce your problem several times without luck. Used standard > command prompt and Console2 > > The only one I didn't tried is rxvt with bash since they have serious > issues (I suggest you use directly bash with console2 to get a nicer > tabbed console). > > -- > 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 > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel -- Thanks! -=R From z4k4ri4 at gmail.com Tue Nov 18 01:28:09 2008 From: z4k4ri4 at gmail.com (Zakaria) Date: Tue, 18 Nov 2008 13:28:09 +0700 Subject: [Rubyinstaller-devel] Use openssl 0.9.8e in the next version? Message-ID: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> Hi, I'm testing your RC1 and using it for rails 2.1 and postgresql. It turnout your libeay32.dll and ssleay32.dll conflict with PostgreSQL 8.3.1 version of the same dll (0.9.8.4 vs 0.9.8.5). Could you upgrade the next version to use OpenSSL 0.9.8e like PostgreSQL? I'm choosing that particular version of PostgreSQL because that the version the target server will use (Ubuntu LTS 8.04). Thanks, -- Zakaria z4k4ri4 at gmail.com Yahoo!: z4k4ri4 From rogerpack2005 at gmail.com Tue Nov 18 10:11:52 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Tue, 18 Nov 2008 08:11:52 -0700 Subject: [Rubyinstaller-devel] Use openssl 0.9.8e in the next version? In-Reply-To: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> References: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> Message-ID: <966599840811180711u1ac73de4n87816736603ad94f@mail.gmail.com> I wonder if there's a way to use separate versions of the dll's without causing conflicts. -=R On Mon, Nov 17, 2008 at 11:28 PM, Zakaria wrote: > Hi, > > I'm testing your RC1 and using it for rails 2.1 and postgresql. > It turnout your libeay32.dll and ssleay32.dll conflict with > PostgreSQL 8.3.1 version of the same dll (0.9.8.4 vs 0.9.8.5). > > Could you upgrade the next version to use OpenSSL 0.9.8e like PostgreSQL? > > I'm choosing that particular version of PostgreSQL because that the version > the target server will use (Ubuntu LTS 8.04). > > Thanks, > > > -- Zakaria > z4k4ri4 at gmail.com Yahoo!: z4k4ri4 > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel > From luislavena at gmail.com Tue Nov 18 10:13:12 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Nov 2008 13:13:12 -0200 Subject: [Rubyinstaller-devel] Use openssl 0.9.8e in the next version? In-Reply-To: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> References: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> Message-ID: <71166b3b0811180713i24713083p50390d8b2ffb9029@mail.gmail.com> On Tue, Nov 18, 2008 at 4:28 AM, Zakaria wrote: > Hi, > > I'm testing your RC1 and using it for rails 2.1 and postgresql. > It turnout your libeay32.dll and ssleay32.dll conflict with > PostgreSQL 8.3.1 version of the same dll (0.9.8.4 vs 0.9.8.5). > > Could you upgrade the next version to use OpenSSL 0.9.8e like PostgreSQL? > We can try, but I found problems between the openssl extension bundled with the Ruby version we are using and newer OpenSSL releases. Did you tried replacing those files for the newer ones? Just rename the ones in Ruby/bin to .old or something and copy over the ones from PostgreSQL > I'm choosing that particular version of PostgreSQL because that the version > the target server will use (Ubuntu LTS 8.04). > > Thanks, > > > -- Zakaria > z4k4ri4 at gmail.com Yahoo!: z4k4ri4 -- 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 From luislavena at gmail.com Tue Nov 18 10:14:12 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Nov 2008 13:14:12 -0200 Subject: [Rubyinstaller-devel] Use openssl 0.9.8e in the next version? In-Reply-To: <966599840811180711u1ac73de4n87816736603ad94f@mail.gmail.com> References: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> <966599840811180711u1ac73de4n87816736603ad94f@mail.gmail.com> Message-ID: <71166b3b0811180714k13e993f8k79b9a700f5542323@mail.gmail.com> On Tue, Nov 18, 2008 at 1:11 PM, Roger Pack wrote: > I wonder if there's a way to use separate versions of the dll's > without causing conflicts. > -=R > The only way to avoid that is do static linked version of all the dependencies Ruby depends on (like zlib, openssl, readline and others). -- 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 From luislavena at gmail.com Wed Nov 19 16:28:39 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 Nov 2008 19:28:39 -0200 Subject: [Rubyinstaller-devel] Use openssl 0.9.8e in the next version? In-Reply-To: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> References: <837f1cb0811172228y69e7c148v4013628e9c36dfe2@mail.gmail.com> Message-ID: <71166b3b0811191328o18fe40baw989872725bd5365a@mail.gmail.com> On Tue, Nov 18, 2008 at 4:28 AM, Zakaria wrote: > Hi, > > I'm testing your RC1 and using it for rails 2.1 and postgresql. > It turnout your libeay32.dll and ssleay32.dll conflict with > PostgreSQL 8.3.1 version of the same dll (0.9.8.4 vs 0.9.8.5). > > Could you upgrade the next version to use OpenSSL 0.9.8e like PostgreSQL? > > I'm choosing that particular version of PostgreSQL because that the version > the target server will use (Ubuntu LTS 8.04). > After futher review, it seems sseay32.dll and libeay32.dll "official" builds are prepared with VC9, http://www.slproweb.com/products/Win32OpenSSL.html That will render the updated files incompatible with current One-Click installer (VC6). Too bad there isn't other releases of this for MinGW or VC6 compilers. The alternative will be manually copy these files into Ruby/bin once installed. MinGW version of One-Click will not be affected by this. 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 From rogerpack2005 at gmail.com Fri Nov 21 11:05:38 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Fri, 21 Nov 2008 09:05:38 -0700 Subject: [Rubyinstaller-devel] rev Message-ID: <966599840811210805u2b06fdf2w417cb5721934f006@mail.gmail.com> As a note, I got rev to work [after some pain] on mingw [with 1.9, 1.8.6]. Yet another compatible gem :) It doesn't have working SSL yet [punted on that one] but at least it compiles and runs [works with > 64 fd's in a select, too]. Take care. -=R From luislavena at gmail.com Sat Nov 22 17:34:43 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 22 Nov 2008 20:34:43 -0200 Subject: [Rubyinstaller-devel] rev In-Reply-To: <966599840811210805u2b06fdf2w417cb5721934f006@mail.gmail.com> References: <966599840811210805u2b06fdf2w417cb5721934f006@mail.gmail.com> Message-ID: <71166b3b0811221434l1105f74fp7f6e0b65ce2754ed@mail.gmail.com> On Fri, Nov 21, 2008 at 2:05 PM, Roger Pack wrote: > As a note, I got rev to work [after some pain] on mingw [with 1.9, > 1.8.6]. Yet another compatible gem :) > It doesn't have working SSL yet [punted on that one] but at least it > compiles and runs [works with > 64 fd's in a select, too]. > Take care. > -=R Cool! Did you had chance to spicy it up with rake-compiler? Need to finish that up to ease cross compilation this weekend. -- 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 From rogerpack2005 at gmail.com Sat Nov 22 21:39:41 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Sat, 22 Nov 2008 19:39:41 -0700 Subject: [Rubyinstaller-devel] overcoming readline's cpu Message-ID: <966599840811221839j7dbf6767l225570cecdd5df8e@mail.gmail.com> appears you can somewhat avoid the 'irb 100% cpu' by changing lib\irb\input-method.rb from def gets if l = readline(@prompt, false) ... to def gets print @prompt if l = $stdin.gets ... Which at least doesn't use 100% cpu :) Wonder if any other libraries have found this weirdness with readline + mingw...and why it doesn't happen sometimes. Odd. msvcrt versioning weirdness? -=R From luislavena at gmail.com Mon Nov 24 10:57:40 2008 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 24 Nov 2008 13:57:40 -0200 Subject: [Rubyinstaller-devel] overcoming readline's cpu In-Reply-To: <966599840811221839j7dbf6767l225570cecdd5df8e@mail.gmail.com> References: <966599840811221839j7dbf6767l225570cecdd5df8e@mail.gmail.com> Message-ID: <71166b3b0811240757x55845c38i1b5982bdd2ff15dc@mail.gmail.com> On Sun, Nov 23, 2008 at 12:39 AM, Roger Pack wrote: > appears you can somewhat avoid the 'irb 100% cpu' > by changing lib\irb\input-method.rb > > from > def gets > if l = readline(@prompt, false) > ... > to > def gets > print @prompt > if l = $stdin.gets > ... > Doing that you loose the readline autocompletion functionality > Which at least doesn't use 100% cpu :) > Wonder if any other libraries have found this weirdness with readline > + mingw...and why it doesn't happen sometimes. Odd. msvcrt versioning > weirdness? No, is GNU Readline issue and linking to a different version of readline. Going to 4.2 instead of 5 version doesn't produce that CPU usage. FYI. -- 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 From joaopedrosa at gmail.com Wed Nov 26 02:39:30 2008 From: joaopedrosa at gmail.com (Joao Pedrosa) Date: Wed, 26 Nov 2008 05:39:30 -0200 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? Message-ID: Hi guys, First of all, thanks for working on this installer which is much appreciated. :-) It was how I first installed Ruby for instance. :-) But for a long-time I have also been running Ruby on Linux and left Windows by itself since then. Every now and then I could be seen testing Ruby on Windows though, and this is such an occasion. Today I was testing these versions of Ruby: ruby -v ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] jruby -v jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java] When building the MinGW Ruby I used git to download the rubyinstaller scripts and ran it with rake. When it got to the Rubygems part it returned an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or something. I was able to install the Rubygems by running the setup manually for it, though I am not sure what else I missed from the remaining of the installation scripts. To test the different Ruby versions, I ran some JRuby benchmark files with each interpreter to make a rough comparison. JRuby came faster by a good margin, though JRuby has different setups itself (--client, --server, -X-C) which influence the results. In general though, JRuby has closed the gap and generally surpassed MRI's performance. Second faster came the MinGW Ruby I just built. Only in third and last came the original OneClick installed Ruby which uses VC6 right? You can run the benchmarks I ran and see for yourself: http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb They have a bunch of other benchmarks though: http://svn.codehaus.org/jruby/trunk/jruby/bench/ JRuby could "just work" on unfriendly environments such as Windows while it has been a pain in the neck all these years to fully support Ruby on Windows. To top it all, JRuby could run considerably faster than Ruby on Windows in special. I have barely used JRuby at all thus far, and it's not a perfect replacement for Ruby just yet. For example, JRuby can have a hard time presenting more friendly error messages which really tell what went wrong, but it's evolving, improving, and it "steals" the platform infrastructure from Java so they can focus on other issues. Also, when testing GUI applications (GTK+), Ruby runs instantly while JRuby with Swing can take a while longer, though they could improve it as well. JRuby generally starts slower with more complex applications, is that fair to say? :-) I came to Ruby from Java and a disillusionment with the .NET surge and the splitting of the developers into worlds. Ruby was meant to be the third way, but now Java and .NET more than promise to support Ruby. Also, Java and .NET try to leave the C/C++ world behind for as much as most developers are concerned. As I currently see it, instead of having Ruby by itself, the future will bring Ruby + Java and Ruby + .NET and we will have to deal with that and it will be a nice problem to have. :-) See an example of IronRuby: http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx What worries me is Ruby having its ass kicked by these other implementations mainly on Windows. I personally think it's just easier to run JRuby on Windows and in the name of reaching a consensus, JRuby could win as my preferred platform, at least until Microsoft adopts the GNU tools or .NET + Mono with IronRuby give Java and JRuby something to worry about. I guess Ruby on Windows will need to take advantage of the latest improvements on compilers and whatnot to keep it competitive. If Microsoft's C compiler builds faster executables it could be better to use it, though MinGW's GCC could be "fast enough" and even more compatible. It's high-time something great happens to Ruby on Windows, other than Java and .NET. :-) I invite you to run some of the benchmarks found in the JRuby repository. JRuby can be run in different ways: # generally opts for a simpler JVM said to be the "client" one: jruby bench_colon.rb # found only in the JDK, this one can more aggressively try to optimize: jruby --server bench_colon.rb # disables the ruby to bytecode compiler because the interpreter is fast already: jruby --server -X-C bench_colon.rb And compare "stuff". I extended myself a lot in this post but I continue to be thoroughly thankful for the work of you guys. Cheers, Joao From rogerpack2005 at gmail.com Wed Nov 26 09:22:50 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Wed, 26 Nov 2008 07:22:50 -0700 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: References: Message-ID: <966599840811260622h7f21fca7k45a80dc7b3d41ea5@mail.gmail.com> Ruby has traditionally been "slighted" on windows [1]. For whatever reasons :) You'll notice that mingw is [at least for more] quite a step up in speed from the msvc version. That build error you described is one I ran into, too--Luis has promised to fix it once a newer version of rubygems comes out :) I'm also glad to hear that jruby is fast on windows--hardly anybody has probably even tested it out :) Another interesting test would be 1.9 versus jruby on windows: It does build--at least it should :P [every so often the core guys commit something that causes a build problem--hopefully they're not there :P ] http://betterlogic.com/roger/?p=515 Note also that building it on mingw is easily 10x easier, using Luis' installer, than it used to be. Trust me. Just trust me. Note also that if you wanted a 'tidge' more performance, you could try to use GCC 4.2.x or what not [and enable the gentoo flags :) ]. The rubyinstaller doesn't use it because it's still kind of edgey, but apparently it is slightly faster. So things will improve that way. I'd be interested in running "benchmarks not from jruby" against them all, too. In general, though--I don't see it as a "competition" or "problem" to have ruby running with a backend vm on .net or java--the nicety of writing ruby is that [hopefully] you never have to touch code in the lower level, so...it should just work, so which ever is faster, it won't hurt you to use it. Just my $0.02. Cheers! -=R [1] http://www.rubyinside.com/is-windows-a-first-class-platform-for-ruby-823.html On Wed, Nov 26, 2008 at 12:39 AM, Joao Pedrosa wrote: > Hi guys, > > First of all, thanks for working on this installer which is much > appreciated. :-) > It was how I first installed Ruby for instance. :-) > > But for a long-time I have also been running Ruby on Linux and left Windows > by itself since then. Every now and then I could be seen testing Ruby > on Windows though, and this is such an occasion. > > Today I was testing these versions of Ruby: > > ruby -v > ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] > > C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v > ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] > > jruby -v > jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java] > > When building the MinGW Ruby I used git to download the rubyinstaller > scripts and ran it with rake. When it got to the Rubygems part it returned > an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or something. > I was able to install the Rubygems by running the setup manually for it, though > I am not sure what else I missed from the remaining of the installation scripts. > > To test the different Ruby versions, I ran some JRuby benchmark files with each > interpreter to make a rough comparison. JRuby came faster by a good margin, > though JRuby has different setups itself (--client, --server, -X-C) > which influence > the results. In general though, JRuby has closed the gap and generally surpassed > MRI's performance. Second faster came the MinGW Ruby I just built. Only in > third and last came the original OneClick installed Ruby which uses VC6 right? > > You can run the benchmarks I ran and see for yourself: > http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb > http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb > > They have a bunch of other benchmarks though: > http://svn.codehaus.org/jruby/trunk/jruby/bench/ > > JRuby could "just work" on unfriendly environments such as Windows while > it has been a pain in the neck all these years to fully support Ruby on > Windows. To top it all, JRuby could run considerably faster than Ruby on > Windows in special. > > I have barely used JRuby at all thus far, and it's not a perfect > replacement for > Ruby just yet. For example, JRuby can have a hard time presenting more > friendly error messages which really tell what went wrong, but it's evolving, > improving, and it "steals" the platform infrastructure from Java so > they can focus > on other issues. Also, when testing GUI applications (GTK+), Ruby runs > instantly while JRuby with Swing can take a while longer, though they could > improve it as well. JRuby generally starts slower with more complex > applications, > is that fair to say? :-) > > I came to Ruby from Java and a disillusionment with the .NET surge and the > splitting of the developers into worlds. Ruby was meant to be the third way, > but now Java and .NET more than promise to support Ruby. Also, Java and .NET > try to leave the C/C++ world behind for as much as most developers are > concerned. > > As I currently see it, instead of having Ruby by itself, the future will bring > Ruby + Java and Ruby + .NET and we will have to deal with that and it will > be a nice problem to have. :-) > > See an example of IronRuby: > http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx > > What worries me is Ruby having its ass kicked by these other implementations > mainly on Windows. I personally think it's just easier to run JRuby on Windows > and in the name of reaching a consensus, JRuby could win as my preferred > platform, at least until Microsoft adopts the GNU tools or .NET + Mono > with IronRuby give Java and JRuby something to worry about. > > I guess Ruby on Windows will need to take advantage of the latest improvements > on compilers and whatnot to keep it competitive. If Microsoft's C compiler > builds faster executables it could be better to use it, though MinGW's GCC > could be "fast enough" and even more compatible. > > It's high-time something great happens to Ruby on Windows, other than > Java and .NET. :-) > > I invite you to run some of the benchmarks found in the JRuby repository. > JRuby can be run in different ways: > > # generally opts for a simpler JVM said to be the "client" one: > jruby bench_colon.rb > # found only in the JDK, this one can more aggressively try to optimize: > jruby --server bench_colon.rb > # disables the ruby to bytecode compiler because the interpreter is > fast already: > jruby --server -X-C bench_colon.rb > > And compare "stuff". > > I extended myself a lot in this post but I continue to be thoroughly thankful > for the work of you guys. > > Cheers, > Joao > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel > -- Thanks! -=R From joaopedrosa at gmail.com Wed Nov 26 16:03:54 2008 From: joaopedrosa at gmail.com (Joao Pedrosa) Date: Wed, 26 Nov 2008 19:03:54 -0200 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: <966599840811260622h7f21fca7k45a80dc7b3d41ea5@mail.gmail.com> References: <966599840811260622h7f21fca7k45a80dc7b3d41ea5@mail.gmail.com> Message-ID: Hey, > I'm also glad to hear that jruby is fast on windows--hardly anybody > has probably even tested it out :) I think many JRuby users tend to use Windows as well. It's like Java in that regard, I would guess. > Another interesting test would be 1.9 versus jruby on windows: > It does build--at least it should :P [every so often the core guys > commit something that causes a build problem--hopefully they're not > there :P ] > http://betterlogic.com/roger/?p=515 I just easily built it using VS2008 command line. Ruby 1.9 seems promising and Ruby's best try to keeping things competitive. > Note also that building it on mingw is easily 10x easier, using Luis' > installer, than it used to be. Trust me. Just trust me. It was relatively easy indeed. Although to me it works like a "blackbox" right now given I hardly know the installer processes. :-) > Note also that if you wanted a 'tidge' more performance, you could try > to use GCC 4.2.x or what not [and enable the gentoo flags :) ]. The > rubyinstaller doesn't use it because it's still kind of edgey, but > apparently it is slightly faster. So things will improve that way. Yesterday I tried to download my own version of MinGW but it has become a little more complicated since I last used it. I wanted to test one of the latest versions of GCC for sure. :-) > I'd be interested in running "benchmarks not from jruby" against them all, too. Me too. Eventually will do. > In general, though--I don't see it as a "competition" or "problem" to > have ruby running with a backend vm on .net or java--the nicety of > writing ruby is that [hopefully] you never have to touch code in the > lower level, so...it should just work, so which ever is faster, it > won't hurt you to use it. Just my $0.02. Yes. Ruby code is malleable enough to work on different interpreters with relative little change. Albeit each interpreter has got to try to keep as much compatibility as possible to make it more fun. :-) Cheers, Joao From luislavena at gmail.com Wed Nov 26 16:34:01 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 26 Nov 2008 19:34:01 -0200 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: References: Message-ID: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> On Wed, Nov 26, 2008 at 5:39 AM, Joao Pedrosa wrote: > Hi guys, > > First of all, thanks for working on this installer which is much > appreciated. :-) > It was how I first installed Ruby for instance. :-) Thanks to you and welcome! :-) > > But for a long-time I have also been running Ruby on Linux and left Windows > by itself since then. Every now and then I could be seen testing Ruby > on Windows though, and this is such an occasion. Sometimes I go back and forth these environments too, so I know how you must feel. > Today I was testing these versions of Ruby: > > ruby -v > ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] > > C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v > ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] > > jruby -v > jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java] > > When building the MinGW Ruby I used git to download the rubyinstaller > scripts and ran it with rake. When it got to the Rubygems part it returned > an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or something. > I was able to install the Rubygems by running the setup manually for it, though > I am not sure what else I missed from the remaining of the installation scripts. Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in the new scripts and some helpers to solve the issues of several projects. Manually installing latest version of rubygems (1.3.1) works, so fixing the scripts will be easy. > To test the different Ruby versions, I ran some JRuby benchmark files with each > interpreter to make a rough comparison. JRuby came faster by a good margin, > though JRuby has different setups itself (--client, --server, -X-C) > which influence > the results. In general though, JRuby has closed the gap and generally surpassed > MRI's performance. Second faster came the MinGW Ruby I just built. Only in > third and last came the original OneClick installed Ruby which uses VC6 right? Yes, current One-Click Installer is based on VC6. Is good to know VC6 build was beaten by both Jruby and MinGW build! Every time I test jruby I don't enable any of these flags since "average joe ruby" will need to dig into the documentation or some sites to get info from them. In any case, these should be enabled by default, right? These are safe to be used by average joe? For example, MinGW version is built with zero flag optimization, and it's even including debug information (-g) to ease the debug process while developing the package. > You can run the benchmarks I ran and see for yourself: > http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb > http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb > > They have a bunch of other benchmarks though: > http://svn.codehaus.org/jruby/trunk/jruby/bench/ Cool, I'll check them out later if time allows. > JRuby could "just work" on unfriendly environments such as Windows while > it has been a pain in the neck all these years to fully support Ruby on > Windows. To top it all, JRuby could run considerably faster than Ruby on > Windows in special. The thing is that JRuby requires several things: JRE for running it. JDK for extending it from Java. Also with it's drawbacks: Has no native support for extensions, so Hpricot, nokogiri, RubyInline, ParseTree and many others end with problems. Pretty much current Ruby for Windows situation, anyway :-D The dependency in a 12 years old compiler (VC6) has made the development and compilation of gems on Windows a real problem. The goal of using MinGW is not beat VC6 speed (which is a desire) but instead ease the integration path between platforms. JRuby, like IronRuby adds another layer of compatibility concerns both developers and users should take in consideration. > I have barely used JRuby at all thus far, and it's not a perfect > replacement for > Ruby just yet. For example, JRuby can have a hard time presenting more > friendly error messages which really tell what went wrong, but it's evolving, > improving, and it "steals" the platform infrastructure from Java so > they can focus > on other issues. Also, when testing GUI applications (GTK+), Ruby runs > instantly while JRuby with Swing can take a while longer, though they could > improve it as well. JRuby generally starts slower with more complex > applications, > is that fair to say? :-) Yes, JRuby was it's own nice looking attributes, neither me or anyone can deny that some of those are good looking. > I came to Ruby from Java and a disillusionment with the .NET surge and the > splitting of the developers into worlds. Ruby was meant to be the third way, > but now Java and .NET more than promise to support Ruby. Also, Java and .NET > try to leave the C/C++ world behind for as much as most developers are > concerned. > > As I currently see it, instead of having Ruby by itself, the future will bring > Ruby + Java and Ruby + .NET and we will have to deal with that and it will > be a nice problem to have. :-) > Don't forget to include Rubinius in the mix. :-D Yet still, there will be flavors of Ruby implementations for all the backgrounds, the ones coming form Java, and the ones coming from .NET > See an example of IronRuby: > http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx > > What worries me is Ruby having its ass kicked by these other implementations > mainly on Windows. I personally think it's just easier to run JRuby on Windows > and in the name of reaching a consensus, JRuby could win as my preferred > platform, at least until Microsoft adopts the GNU tools or .NET + Mono > with IronRuby give Java and JRuby something to worry about. In some way I agree with your statement, but I don't feel in that way. As I mentioned previously, neither JRuby or IronRuby will be able to work with a huge number of gems that require native extensions. In case there is no binding for the library neither in Java or dotNet, then the users should decide for other libraries or switch back to MRI. The goal of One-Click Installer is ease the path, integrating GNU tools and documenting the whole process which has been, until now, close managed by the guys at garbagecollect for their "binary releases". Even more, I will not doubt on creating a One-Click JRuby/IronRuby Installer in the future, only if people is interested. > I guess Ruby on Windows will need to take advantage of the latest improvements > on compilers and whatnot to keep it competitive. If Microsoft's C compiler > builds faster executables it could be better to use it, though MinGW's GCC > could be "fast enough" and even more compatible. > The VC8/9 path has been discussed previously in the list under which I expressed both my points and concerns. As you said, MinGW will provide more value to the equation. > It's high-time something great happens to Ruby on Windows, other than > Java and .NET. :-) > > I invite you to run some of the benchmarks found in the JRuby repository. > JRuby can be run in different ways: > I'll as soon time allows, and maybe drop some post in my blog. > # generally opts for a simpler JVM said to be the "client" one: > jruby bench_colon.rb > # found only in the JDK, this one can more aggressively try to optimize: > jruby --server bench_colon.rb > # disables the ruby to bytecode compiler because the interpreter is > fast already: > jruby --server -X-C bench_colon.rb > > And compare "stuff". > > I extended myself a lot in this post but I continue to be thoroughly thankful > for the work of you guys. Thanks to you man for putting together all this, exposing issues and your point of view about One-Click Installer and current situation. I believe that even JRuby or IronRuby became good candidates for usage on Windows, there is still room for MRI (and maybe Rubinius?) :-D > Cheers, > Joao Cheers and have a nice week! -- 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 From rogerpack2005 at gmail.com Sun Nov 30 00:47:18 2008 From: rogerpack2005 at gmail.com (Roger Pack) Date: Sat, 29 Nov 2008 22:47:18 -0700 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> References: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> Message-ID: <966599840811292147y4ed7088en84655edfd0385fa0@mail.gmail.com> I agree--the reason I stick with MRI (despite its shortcomings--GC, speed, etc.) is that it is the "de facto standard" and, like it or not, used by most rubyists. Cheers! -=R On Wed, Nov 26, 2008 at 2:34 PM, Luis Lavena wrote: > On Wed, Nov 26, 2008 at 5:39 AM, Joao Pedrosa wrote: >> Hi guys, >> >> First of all, thanks for working on this installer which is much >> appreciated. :-) >> It was how I first installed Ruby for instance. :-) > > Thanks to you and welcome! :-) > >> >> But for a long-time I have also been running Ruby on Linux and left Windows >> by itself since then. Every now and then I could be seen testing Ruby >> on Windows though, and this is such an occasion. > > Sometimes I go back and forth these environments too, so I know how > you must feel. > >> Today I was testing these versions of Ruby: >> >> ruby -v >> ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] >> >> C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v >> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] >> >> jruby -v >> jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java] >> >> When building the MinGW Ruby I used git to download the rubyinstaller >> scripts and ran it with rake. When it got to the Rubygems part it returned >> an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or something. >> I was able to install the Rubygems by running the setup manually for it, though >> I am not sure what else I missed from the remaining of the installation scripts. > > Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in > the new scripts and some helpers to solve the issues of several > projects. > > Manually installing latest version of rubygems (1.3.1) works, so > fixing the scripts will be easy. > >> To test the different Ruby versions, I ran some JRuby benchmark files with each >> interpreter to make a rough comparison. JRuby came faster by a good margin, >> though JRuby has different setups itself (--client, --server, -X-C) >> which influence >> the results. In general though, JRuby has closed the gap and generally surpassed >> MRI's performance. Second faster came the MinGW Ruby I just built. Only in >> third and last came the original OneClick installed Ruby which uses VC6 right? > > Yes, current One-Click Installer is based on VC6. > > Is good to know VC6 build was beaten by both Jruby and MinGW build! > > Every time I test jruby I don't enable any of these flags since > "average joe ruby" will need to dig into the documentation or some > sites to get info from them. > > In any case, these should be enabled by default, right? These are safe > to be used by average joe? > > For example, MinGW version is built with zero flag optimization, and > it's even including debug information (-g) to ease the debug process > while developing the package. > >> You can run the benchmarks I ran and see for yourself: >> http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb >> http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb >> >> They have a bunch of other benchmarks though: >> http://svn.codehaus.org/jruby/trunk/jruby/bench/ > > Cool, I'll check them out later if time allows. > >> JRuby could "just work" on unfriendly environments such as Windows while >> it has been a pain in the neck all these years to fully support Ruby on >> Windows. To top it all, JRuby could run considerably faster than Ruby on >> Windows in special. > > The thing is that JRuby requires several things: > > JRE for running it. > JDK for extending it from Java. > > Also with it's drawbacks: > > Has no native support for extensions, so Hpricot, nokogiri, > RubyInline, ParseTree and many others end with problems. > > Pretty much current Ruby for Windows situation, anyway :-D > > The dependency in a 12 years old compiler (VC6) has made the > development and compilation of gems on Windows a real problem. > > The goal of using MinGW is not beat VC6 speed (which is a desire) but > instead ease the integration path between platforms. > > JRuby, like IronRuby adds another layer of compatibility concerns both > developers and users should take in consideration. > >> I have barely used JRuby at all thus far, and it's not a perfect >> replacement for >> Ruby just yet. For example, JRuby can have a hard time presenting more >> friendly error messages which really tell what went wrong, but it's evolving, >> improving, and it "steals" the platform infrastructure from Java so >> they can focus >> on other issues. Also, when testing GUI applications (GTK+), Ruby runs >> instantly while JRuby with Swing can take a while longer, though they could >> improve it as well. JRuby generally starts slower with more complex >> applications, >> is that fair to say? :-) > > Yes, JRuby was it's own nice looking attributes, neither me or anyone > can deny that some of those are good looking. > >> I came to Ruby from Java and a disillusionment with the .NET surge and the >> splitting of the developers into worlds. Ruby was meant to be the third way, >> but now Java and .NET more than promise to support Ruby. Also, Java and .NET >> try to leave the C/C++ world behind for as much as most developers are >> concerned. >> >> As I currently see it, instead of having Ruby by itself, the future will bring >> Ruby + Java and Ruby + .NET and we will have to deal with that and it will >> be a nice problem to have. :-) >> > > Don't forget to include Rubinius in the mix. :-D > > Yet still, there will be flavors of Ruby implementations for all the > backgrounds, the ones coming form Java, and the ones coming from .NET > >> See an example of IronRuby: >> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx >> >> What worries me is Ruby having its ass kicked by these other implementations >> mainly on Windows. I personally think it's just easier to run JRuby on Windows >> and in the name of reaching a consensus, JRuby could win as my preferred >> platform, at least until Microsoft adopts the GNU tools or .NET + Mono >> with IronRuby give Java and JRuby something to worry about. > > In some way I agree with your statement, but I don't feel in that way. > > As I mentioned previously, neither JRuby or IronRuby will be able to > work with a huge number of gems that require native extensions. > > In case there is no binding for the library neither in Java or dotNet, > then the users should decide for other libraries or switch back to > MRI. > > The goal of One-Click Installer is ease the path, integrating GNU > tools and documenting the whole process which has been, until now, > close managed by the guys at garbagecollect for their "binary > releases". > > Even more, I will not doubt on creating a One-Click JRuby/IronRuby > Installer in the future, only if people is interested. > >> I guess Ruby on Windows will need to take advantage of the latest improvements >> on compilers and whatnot to keep it competitive. If Microsoft's C compiler >> builds faster executables it could be better to use it, though MinGW's GCC >> could be "fast enough" and even more compatible. >> > > The VC8/9 path has been discussed previously in the list under which I > expressed both my points and concerns. As you said, MinGW will provide > more value to the equation. > >> It's high-time something great happens to Ruby on Windows, other than >> Java and .NET. :-) >> >> I invite you to run some of the benchmarks found in the JRuby repository. >> JRuby can be run in different ways: >> > > I'll as soon time allows, and maybe drop some post in my blog. > >> # generally opts for a simpler JVM said to be the "client" one: >> jruby bench_colon.rb >> # found only in the JDK, this one can more aggressively try to optimize: >> jruby --server bench_colon.rb >> # disables the ruby to bytecode compiler because the interpreter is >> fast already: >> jruby --server -X-C bench_colon.rb >> >> And compare "stuff". >> >> I extended myself a lot in this post but I continue to be thoroughly thankful >> for the work of you guys. > > Thanks to you man for putting together all this, exposing issues and > your point of view about One-Click Installer and current situation. > > I believe that even JRuby or IronRuby became good candidates for usage > on Windows, there is still room for MRI (and maybe Rubinius?) :-D > >> Cheers, >> Joao > > Cheers and have a nice week! > -- > 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 > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel > -- Thanks! -=R From joaopedrosa at gmail.com Sun Nov 30 02:10:05 2008 From: joaopedrosa at gmail.com (Joao Pedrosa) Date: Sun, 30 Nov 2008 04:10:05 -0300 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> References: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> Message-ID: Hi, > Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in > the new scripts and some helpers to solve the issues of several > projects. BTW. Being the Ruby Installer a rather special kind of software building/installing, would not it be better to keep everything in Ruby itself so it could more easily be understood by everyday's programmer than to use Rake to its fullest which might be a little beyond potential contributor's skills? It's not as if there is lots of people willing to even try it, let alone to put into it the energy required to understand it. I know that Rake doesn't look that scary, and it might even be handy... I just fear that in the long run it might be a waste and make the installer harder to integrate with or understand. There is already RubyGems, setup.rb... And numerous nuisances when trying to make things install in the right ways... By appealing to the full power of Ruby it could prove more than useful. In the lines of "beware of premature optimization", I would say to "beware of premature frameworkzation" in this case. Even though the Ruby Installer would have to adopt its own framework structure for sure. My worry is that it has to handle with external issues all the time, or in the words of Linux Distributions, with "upstream". Take that as just an idea. > Is good to know VC6 build was beaten by both Jruby and MinGW build! I have some more data to corroborate. More in another email. > Every time I test jruby I don't enable any of these flags since > "average joe ruby" will need to dig into the documentation or some > sites to get info from them. > > In any case, these should be enabled by default, right? These are safe > to be used by average joe? Yes, JRuby's flags like "--server", "-X-C" can be safely used by users, they are only required to have the JDK to be able to choose. Also, the JDK seems to be able to adopt one or another internal VM automatically if the computer seems adequate, as in a server machine with plenty of RAM and multiple CPUs. The "-X-C" works more as a testing facility to disable the ruby to bytecode compiler. The important flag is "--server" because it enables the ruby to bytecode compiler and uses the more performance-seeking hotspot VM. In single-run algorithms, JRuby should work well enough without the need to use such flags. It's only if you are running longer-running algorithms or server services that using the "--server" flag might pay off. JRuby could still enjoy some tunning to achieve greater performances, and a future JVM version could further help it achieve that. :-) > For example, MinGW version is built with zero flag optimization, and > it's even including debug information (-g) to ease the debug process > while developing the package. I managed to disable the "-g" flag during my most recent tests and it didn't seem to significantly impact the performance here. > The thing is that JRuby requires several things: > > JRE for running it. > JDK for extending it from Java. > > Also with it's drawbacks: > > Has no native support for extensions, so Hpricot, nokogiri, > RubyInline, ParseTree and many others end with problems. > > Pretty much current Ruby for Windows situation, anyway :-D True. :-) Java has had this indifference to native code and it is one of the things JRuby seems intent to change on it. For instance, JRuby seems to be making use of FFI which enables access to C. > The dependency in a 12 years old compiler (VC6) has made the > development and compilation of gems on Windows a real problem. > > The goal of using MinGW is not beat VC6 speed (which is a desire) but > instead ease the integration path between platforms. As far as I have experienced it, MinGW seems to be competitive enough with VC for Ruby in terms of producing Ruby interpreters that are fast. Although I don't have a thorough study on that at all, so take it with a grain of salt. :-) > JRuby, like IronRuby adds another layer of compatibility concerns both > developers and users should take in consideration. JRuby and IronRuby will appeal to new users who might not have given Ruby a try otherwise. Also, they provide for different deployment opportunities, and in doing so, might steal pure Ruby users. :-) > Don't forget to include Rubinius in the mix. :-D Rubinius is more vaporware than the others. But I have it as a git repository mirror alongside the other Ruby implementations to keep an eye on it. >> See an example of IronRuby: >> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx >> >> What worries me is Ruby having its ass kicked by these other implementations >> mainly on Windows. I personally think it's just easier to run JRuby on Windows >> and in the name of reaching a consensus, JRuby could win as my preferred >> platform, at least until Microsoft adopts the GNU tools or .NET + Mono >> with IronRuby give Java and JRuby something to worry about. > > In some way I agree with your statement, but I don't feel in that way. > > As I mentioned previously, neither JRuby or IronRuby will be able to > work with a huge number of gems that require native extensions. > > In case there is no binding for the library neither in Java or dotNet, > then the users should decide for other libraries or switch back to > MRI. In the case of both Java and .NET, using Ruby as a frontend, it becomes even less than a deal to create wrappers in Ruby for the libraries in those languages than it has been in Ruby with C and C++. It's just a question of making Ruby scale to handle potentially thousands of files in those platforms in a fast enough way. :-) > The goal of One-Click Installer is ease the path, integrating GNU > tools and documenting the whole process which has been, until now, > close managed by the guys at garbagecollect for their "binary > releases". > > Even more, I will not doubt on creating a One-Click JRuby/IronRuby > Installer in the future, only if people is interested. I figure it would have been important for the Ruby Installer to support even the development versions of Ruby so it could become a reference and in doing so evolve beyond imagination. :-) Thanks! Cheers, Joao From luislavena at gmail.com Sun Nov 30 09:13:39 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 30 Nov 2008 09:13:39 -0500 Subject: [Rubyinstaller-devel] Migrate to GCC as soon as possible? In-Reply-To: References: <71166b3b0811261334i3b655a2cp755f2786bcfa2294@mail.gmail.com> Message-ID: <71166b3b0811300613s57eed570k1f0b7ce919b38659@mail.gmail.com> On Sun, Nov 30, 2008 at 5:10 AM, Joao Pedrosa wrote: > Hi, > >> Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in >> the new scripts and some helpers to solve the issues of several >> projects. > > BTW. Being the Ruby Installer a rather special kind of software > building/installing, would not it be better to keep everything in Ruby > itself so it could more easily be understood by everyday's programmer > than to use Rake to its fullest which might be a little beyond potential > contributor's skills? Hmn, Indeed the project started as pure-ruby driving the ruby build process, which included download of source files and even unpacking those without external dependencies, but not as custom scripts. Instead is driven by Rake. AFAIK Rake is the best tool for the job. Other projects created a specific DSL that generates the needed Rake tasks. Reinventing the wheel is out of question. What we found is that using current implementation, building multiple versions of ruby or the tools Ruby depends on (which are more than 10) get's complicated and messy. You can confirm this statement looking at the recipes on github repository: http://www.github.com/luislavena/rubyinstaller The DSL been working on add a better designed layer on top of it, taking in consideration the issues we found with current one. > It's not as if there is lots of people willing to even try it, let > alone to put into > it the energy required to understand it. I know that Rake doesn't look > that scary, and it might even be handy... I just fear that in the long run it > might be a waste and make the installer harder to integrate with or understand. One of the things that made me decide step back and look at this new DSL on top of Rake is lower the entry point to users. The new structure encourage a event-driven concept of tasks, what should happen before of after a operation. http://gist.github.com/19707 If you compare that with current implementation, will see is much more clear. http://github.com/luislavena/rubyinstaller/tree/master/recipes/dependencies/openssl.rake Just an example, will work on complete the DSL implementation now that rake-compiler is usable: http://github.com/luislavena/rake-compiler > There is already RubyGems, setup.rb... And numerous nuisances when > trying to make things install in the right ways... By appealing to the > full power > of Ruby it could prove more than useful. Oh, we are not reinventing the wheel on this. The objective is have Ruby and their dependencies built properly and in a stable way, so we can run the tests and trust the things we build, in a more automated fashion of current implementation. RubyGems gem installation will be the official way to install stuff on new installer, the only thing is that rubygems needs setup.rb to install itself ;-) Maybe I should put a manifesto about this? I thought the wiki pretty well exposed our goals: http://rubyinstaller.rubyforge.org/wiki/wiki.pl?Roadmap > In the lines of "beware of premature optimization", I would say to > "beware of premature frameworkzation" in this case. Even though the Ruby > Installer would have to adopt its own framework structure for sure. My worry > is that it has to handle with external issues all the time, or in the words > of Linux Distributions, with "upstream". I agree, but in the land of Windows users, there is no alternative for us. Current installer scripts (installer2) is a single file that drives the whole show. http://rubyinstaller.rubyforge.org/svn/trunk/installer-win2/rakefile.rb It not only bundles everything under the sun, but there is no automated way to verify it. Moreover, it depends on a external build of ruby (VC6) which we don't have control over, and thus require manual steps that make generating, testing and packaging new releases a burden. When we reached that point, the work on the new set of scripts proven to be more easy: Pro: Based on a free compiler, we have all the control over the build process Everything well detailed, presenting the dependency chain to the user (ruby depends on openssl and readline). Focusing on the core, not the 150 gems bundled on previous version Con: We need to build everything, which some projects don't make it easy (yeah, that goes for GNU projects) The "detailed" recipes couldn't scale to handle more than one time of version (check the hooks for CHECKOUT and will see the dilemma). Based on those things, I started to explore how to solve that without exposing the dirty details and keep things under control and standardized. The new DSL tries to solve that, yet still is not ready to replace current implementation but will be more easy to jump in for new users. After all, is a descriptive way of detail steps and things that should happen after and before each of the actions by default a version will perform. 1) download code 2) unpack it 3) execute the configure script 4) make 5) make install Those steps has been present in most of every tool and even linux distro under the sun... Why not rely on that? > Take that as just an idea. > Point taken, but please review my comments again and see if it still apply. I'm very passionate about what I do, so all these things can be a bit biased. One thing that I noticed was a bad choice is go with Windows Installer (MSI) technology. While is worth it, rely on WiX and XML to build the components is too complex to be easily maintained. >> Is good to know VC6 build was beaten by both Jruby and MinGW build! > > I have some more data to corroborate. More in another email. > >> Every time I test jruby I don't enable any of these flags since >> "average joe ruby" will need to dig into the documentation or some >> sites to get info from them. >> >> In any case, these should be enabled by default, right? These are safe >> to be used by average joe? > > Yes, JRuby's flags like "--server", "-X-C" can be safely used by users, > they are only required to have the JDK to be able to choose. > > Also, the JDK seems to be able to adopt one or another internal > VM automatically if the computer seems adequate, as in a server > machine with plenty of RAM and multiple CPUs. > > The "-X-C" works more as a testing facility to disable the ruby to bytecode > compiler. The important flag is "--server" because it enables the > ruby to bytecode compiler and uses the more performance-seeking > hotspot VM. > > In single-run algorithms, JRuby should work well enough without the > need to use such flags. It's only if you are running longer-running > algorithms or server services that using the "--server" flag might > pay off. > > JRuby could still enjoy some tunning to achieve greater performances, > and a future JVM version could further help it achieve that. :-) > I cannot say too much about JRuby, I'm not even a user of it. >> For example, MinGW version is built with zero flag optimization, and >> it's even including debug information (-g) to ease the debug process >> while developing the package. > > I managed to disable the "-g" flag during my most recent tests and it > didn't seem to significantly impact the performance here. No debug information impacts on size, while O2 compile parameter too. O3 and other architecture flags can enable generation of faster code. >> The thing is that JRuby requires several things: >> >> JRE for running it. >> JDK for extending it from Java. >> >> Also with it's drawbacks: >> >> Has no native support for extensions, so Hpricot, nokogiri, >> RubyInline, ParseTree and many others end with problems. >> >> Pretty much current Ruby for Windows situation, anyway :-D > > True. :-) > > Java has had this indifference to native code and it is one of the things > JRuby seems intent to change on it. For instance, JRuby seems to be > making use of FFI which enables access to C. > Well, work on ruby-ffi can now be started, but will happen after One-Click Installer, cannot commit free time to it when upcoming 1.9.1 release is close :-) >> The dependency in a 12 years old compiler (VC6) has made the >> development and compilation of gems on Windows a real problem. >> >> The goal of using MinGW is not beat VC6 speed (which is a desire) but >> instead ease the integration path between platforms. > > As far as I have experienced it, MinGW seems to be competitive enough > with VC for Ruby in terms of producing Ruby interpreters that are fast. Although > I don't have a thorough study on that at all, so take it with a grain > of salt. :-) Is not only about speed, while could be a point. The main goal is reduce the burden across platforms. For example, I was really annoyed by "gem.bat" vs "gem" when doing system calls... we got that fixed into Ruby, so no more conditionals to take care: http://blog.mmediasys.com/2008/04/24/contributions-speedup-and-less-quirks-for-us/ Check less quirk for us section. > >> JRuby, like IronRuby adds another layer of compatibility concerns both >> developers and users should take in consideration. > > JRuby and IronRuby will appeal to new users who might not have given Ruby > a try otherwise. Also, they provide for different deployment opportunities, > and in doing so, might steal pure Ruby users. :-) > >> Don't forget to include Rubinius in the mix. :-D > > Rubinius is more vaporware than the others. But I have it as a git repository > mirror alongside the other Ruby implementations to keep an eye on it. > vaporware or not, FFI stuff came out from it :-) Other concepts like mvm (multi vm branch in ruby source) where inspired by Rubinius mvm actors and inter-vm communication. >>> See an example of IronRuby: >>> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx >>> >>> What worries me is Ruby having its ass kicked by these other implementations >>> mainly on Windows. I personally think it's just easier to run JRuby on Windows >>> and in the name of reaching a consensus, JRuby could win as my preferred >>> platform, at least until Microsoft adopts the GNU tools or .NET + Mono >>> with IronRuby give Java and JRuby something to worry about. >> >> In some way I agree with your statement, but I don't feel in that way. >> >> As I mentioned previously, neither JRuby or IronRuby will be able to >> work with a huge number of gems that require native extensions. >> >> In case there is no binding for the library neither in Java or dotNet, >> then the users should decide for other libraries or switch back to >> MRI. > > In the case of both Java and .NET, using Ruby as a frontend, it > becomes even less than a deal to create wrappers in Ruby for > the libraries in those languages than it has been in Ruby with C > and C++. It's just a question of making Ruby scale to handle > potentially thousands of files in those platforms in a fast enough > way. :-) > >> The goal of One-Click Installer is ease the path, integrating GNU >> tools and documenting the whole process which has been, until now, >> close managed by the guys at garbagecollect for their "binary >> releases". >> >> Even more, I will not doubt on creating a One-Click JRuby/IronRuby >> Installer in the future, only if people is interested. > > I figure it would have been important for the Ruby Installer to support > even the development versions of Ruby so it could become a reference > and in doing so evolve beyond imagination. :-) That's one of the things we are working on, but not yet for prime time ;-) Stay tuned :-) > > Thanks! > Thanks to you Joao! -- 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 From luislavena at gmail.com Sun Nov 30 10:37:49 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 30 Nov 2008 10:37:49 -0500 Subject: [Rubyinstaller-devel] ANN: rake-compiler 0.2.1 Message-ID: <71166b3b0811300737vfbce944k1421b5798fc7c909@mail.gmail.com> Hello Rubysts: I'll like to introduce you rake-compiler gem version 0.2.1 rake-compiler aims to help Gem developers while dealing with Ruby C extensions, simplifying the code and reducing the duplication. It follows *convention over configuration* and set an standardized structure to build and package C extensions in your gems. This is the result of experiences dealing with several Gems that required native extensions across platforms and different user configurations where details like portability and clarity of code were lacking. http://github.com/luislavena/rake-compiler/tree/master == Current functionality: * One-liner to be able to compile extensions using Rake * One-liner to be able to package native extensions into Gems. * 3 Lines of code to be able to cross compile extensions for Windows from Linux or OSX * Same 3 lines of code to be able to package those extensions into Gems for Windows. I know 3 lines sounds a lot... but compared to current alternatives (ala: none), 3 lines is cheap. == How to get it Right now it's only available at github: gem install luislavena-rake-compiler --source http://gems.github.com Soon at rubyforge, both will be keep on sync. == Integration You can use any gem packaging and releasing tool with rake-compiler (Hoe, Echoe, MrBones, etc). It doesn't interfere as long you can provide a Gem::Specification to hook into the native gems generation. == Target audience rake-compiler is not only to generate gems for Windows. Under certain circumstances users request binary gems for Linux since their production servers lack the build tools available under development environments. This solution ease the path on all these fields. == Feedback While there is no project page for it (yet), I encourage users send their feedback to Ruby Installer development mailing list. rake-compiler is a side project of One-Click Installer and attempts reduce the gap between users across platforms. == Thanks Several users contributed to make this project a reality, which includes: * Aaron Patterson from nokogiri for the simplified cross compile ruby tasks that inspired the ones implemented in this project * Dan Kubb from DataMapper and DataObjects for care about support of Windows users. * Jonathan Stott from DataMapper and DataObjects for hacking in cross compilation into DO and playing with the workflow Thanks to everyone for their support and feedback during the development of this project! -- 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 From joaopedrosa at gmail.com Sun Nov 30 12:12:08 2008 From: joaopedrosa at gmail.com (Joao Pedrosa) Date: Sun, 30 Nov 2008 14:12:08 -0300 Subject: [Rubyinstaller-devel] Some benchmarks with MinGW, JRuby, MSVC... Message-ID: So, I have managed to build several different versions of Ruby to compare all in some benchmarks. I am going to let the numbers talk for themselves. It was all tested on an old desktop computer with Windows XP, so I am not testing anything too impressive. Of importance is the seemingly poor performance of Ruby 1.8.7 for whatever reason. It's as if Ruby 1.8.7 were like Windows ME, a version between major versions, as an analogy. :-) Also, I was not able to run the Mongrel gem on Ruby 1.9.1. I am going to order the data by fastest to make it easier to compare it on text. I have collected the data on a Google Spreadsheet: http://spreadsheets.google.com/ccc?key=pmtaDyNoButGKeSVdIGi7Fg I am going to keep it short here and for more detail on versions and whatnot please refer to the spreadsheet. == WEBrick (req/s) 22.39 - jruby 16.95 - jruby --server 12.82 - ruby oneclick 1.8.6 12.49 - ruby msvc 1.8.6 12.45 - ruby rubyinstaller 1.8.6 12.43 - ruby mingw 1.8.6 11.94 - ruby msvc 1.9.1 11.48 - ruby mingw 1.9.1 3.42 - ruby msvc 1.8.7 3.40 - ruby mingw 1.8.7 == Mongrel (req/s) 357.14 - ruby mingw 1.8.6 347.45 - ruby rubyinstaller 1.8.6 326.70 - ruby msvc 1.8.6 313.57 - ruby oneclick 1.8.6 274.68 - ruby mingw 1.8.7 232.39 - ruby msvc 1.8.7 71.24 - jruby 62.22 - jruby --server (crash when starting up) - ruby mingw 1.9.1 (error when building gem) - ruby msvc 1.9.1 == bench_pythag.rb (s) 19.09 - jruby --server 24.35 - jruby 31.72 - ruby mingw 1.9.1 31.91 - ruby mingw 1.8.6 32.73 - ruby mingw 1.8.7 33.94 - ruby msvc 1.9.1 35.67 - ruby rubyinstaller 1.8.6 35.83 - ruby msvc 1.8.7 39.79 - ruby msvc 1.8.6 48.30 - ruby oneclick 1.8.6 == bench_fractal.rb (s) 3.22 - jruby --server 3.89 - jruby 5.67 - ruby msvc 1.9.1 5.75 - ruby mingw 1.9.1 9.80 - ruby mingw 1.8.6 9.90 - ruby mingw 1.8.7 10.11 - ruby rubyinstaller 1.8.6 10.30 - ruby msvc 1.8.6 10.64 - ruby msvc 1.8.7 15.17 - ruby oneclick 1.8.6 == bench_float_math.rb (s) 103.44 - jruby --server 125.89 - jruby 158.64 - ruby msvc 1.9.1 175.41 - ruby mingw 1.9.1 176.61 - ruby mingw 1.8.6 179.94 - ruby mingw 1.8.7 184.73 - ruby rubyinstaller 1.8.6 195.37 - ruby msvc 1.8.7 197.39 - ruby msvc 1.8.6 279.62 - ruby oneclick 1.8.6 Since I collected these data, the Ruby 1.9.1 branch has had a number of updates for one thing. :-) Benchmarks can be kind of tough to do right and there are all possibilities when it comes to doing them. If anyone has an algorithm that he would like to test on all those Ruby implementations I would be glad to test it. With the exception of testing Rails, which I have never used and don't know enough about it to willingly make myself available when testing it. :-) Cheers, Joao