I haven''t been following the RoR community for a while as my work caught up to me, but now things have slowed down a little and I''m looking at getting back to learning Rails for my web app idea (a customized CRM type app for services like lawn care, carpet cleaning and pool cleaning). As I see, the current version of Ruby 1.9 is 1.9.1-p129. Is Rails compatible with this version? I know from a little reading before that there were issues and upgrading was NOT recommended; has this changed? Any common gems that don''t work, or have most of the bugs been ironed out? I already started writing some of my code in Ruby 1.8.7 (Rails 2.3.2) so I''m considering upgrading now to 1.9.1 but I don''t want to start an upgrade only to find that a lot of basic things aren''t working. Right now I have both Ruby 1.8.7 and 1.9.1 installed side-by-side on my MacBook just to be on the safe side.
On Jul 2, 1:46 pm, Wayne Molina <wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I haven''t been following the RoR community for a while as my work > caught up to me, but now things have slowed down a little and I''m > looking at getting back to learning Rails for my web app idea (a > customized CRM type app for services like lawn care, carpet cleaning > and pool cleaning). > > As I see, the current version of Ruby 1.9 is 1.9.1-p129. Is Rails > compatible with this version?Rails 2.3 is; plugins and gems may be not be. I see no reason to upgrade at the moment. See http://isitruby19.com for compatibility info. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
Okay, I''ve been developing on 1.8.6, 1.8.7, and 1.9.1-p129. After so many frustrations with 1.9.1-p129, I stopped developing RoR with it. Your best bet is to stick with 1.8.6 or 1.8.7 depending on your development environment. The biggest issues are the following: Gem incompatibilities Gem binary builds Core ruby binary builds I have pretty much encountered them all. I even managed to create a 75% windows build for Ruby 1.9.1-p129 using VC8 instead of ming. There are simply too many packages to build. Ming is being used for building Ruby now by many. If you think you can still do it, then visit the following links: http://isitruby19.com/ Do a search on all the core gems you will be using in RoR to make sure they are now compatible. The biggest issues with gems are: mysql, sqlite3, mongrel, rspec, and a few others I have work arounds for all of them and actually have a fully working 1.9.1 but it took a lot of doing and I had to build some of the binary gems myself to get there. If using windows: http://github.com/oneclick/rubyinstaller/tree/master Luis Lavena is the SME on this project.. You can also get some good answers from Roger Pack.. If using linux: Do a search for your linux distro and installing 1.9.1. Make sure you have all of the libraries on hand before you build from source. Failure to do so will create some issues. You will still have issues with gems though. -- Posted via http://www.ruby-forum.com/.
On Thu, Jul 2, 2009 at 10:46 AM, Wayne Molina <wayne.molina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:> > I haven''t been following the RoR community for a while as my work > caught up to me, but now things have slowed down a little and I''m > looking at getting back to learning Rails for my web app idea (a > customized CRM type app for services like lawn care, carpet cleaning > and pool cleaning). > > As I see, the current version of Ruby 1.9 is 1.9.1-p129. Is Rails > compatible with this version? I know from a little reading before > that there were issues and upgrading was NOT recommended; has this > changed? Any common gems that don''t work, or have most of the bugs > been ironed out? I already started writing some of my code in Ruby > 1.8.7 (Rails 2.3.2) so I''m considering upgrading now to 1.9.1 but I > don''t want to start an upgrade only to find that a lot of basic things > aren''t working. > > Right now I have both Ruby 1.8.7 and 1.9.1 installed side-by-side on > my MacBook just to be on the safe side.Hi, I have been using it in production for about 3 months after its release and I must say that I have noticed a considerable speed up of my applications. Furthermore, I noticed this more so with the bigger applications that required more processing. Ruby 1.9.1-p129 is definitely ready for production with Rail 2.3.2/Edge IMO. I did have to make some minor mods to gems but it was well worth the deep dive. At this time, I''m also starting to do some testing with JRuby and MacRuby implementations since the Global Interpreter Lock (GIL) doesn''t exist in these 1.9.1 implementations. Now, you can really start to write some concurrent applications if this is your internal requirement. However, Ruby 1.9.1-p129 still has GIL which means you can only execute a single thread at a time. Thus, your programs will run sequentially unless you off load your threading to external processes. Good luck, -Conrad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Conrad Taylor wrote: [...]> Hi, I have been using it in production for about 3 months after its > release and I must say that I have noticed a considerable speed up of > my applications. Furthermore, I noticed this more so with the bigger > applications that required more processing. Ruby 1.9.1-p129 is > definitely > ready for production with Rail 2.3.2/Edge IMO. I did have to make some > minor mods to gems but it was well worth the deep dive.Good to know...but why not just use Ruby EE? It acts just like MRI 1.8.7, so no modification of code is required, but it''s significantly faster, or at least that''s what the benchmarks say. Is Ruby 1.9 enough faster than Ruby EE to justify the extra work of modifying gems? Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Thu, Jul 2, 2009 at 2:24 PM, Marnen Laibow-Koser < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Conrad Taylor wrote: > [...] > > Hi, I have been using it in production for about 3 months after its > > release and I must say that I have noticed a considerable speed up of > > my applications. Furthermore, I noticed this more so with the bigger > > applications that required more processing. Ruby 1.9.1-p129 is > > definitely > > ready for production with Rail 2.3.2/Edge IMO. I did have to make some > > minor mods to gems but it was well worth the deep dive. > > Good to know...but why not just use Ruby EE? It acts just like MRI > 1.8.7, so no modification of code is required, but it''s significantly > faster, or at least that''s what the benchmarks say. Is Ruby 1.9 enough > faster than Ruby EE to justify the extra work of modifying gems? > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted via http://www.ruby-forum.com/. >Marren, as far as I know, the GIL still exists in Ruby EE. The minor mods were either on the Ruby side or the C-Extension side and I''m looking to do a bit of concurrent processing. MacRuby is being used because it allows me to seamlessly interact with the Objective-C/Cocoa. Furthermore, it has no GIL and plans for better support for multi-core systems. JRuby is being used because we need to interact with existing Java frameworks with parts of the system. My boss wants me to push the technology to its limits and see what''s possible. BTW, we do a lot of AI, bioinformatic, and other related projects and I''m dealing with systems with the following configurations most of the time: CPU: 8-cores RAM: 16 GB minimum HDD: 4 TB minimum However, I tend to also do e-commerce stuff on the side and I can see where good concurrency would be beneficial to the user''s experience. In short, I''m using the implementation/technology that best supports the specific part of the system because one size doesn''t fit all. -Conrad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
* Marnen Laibow-Koser <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> [2009-07-02 23:24:45 +0200]:> > Conrad Taylor wrote: > [...] > > Hi, I have been using it in production for about 3 months after its > > release and I must say that I have noticed a considerable speed up of > > my applications. Furthermore, I noticed this more so with the bigger > > applications that required more processing. Ruby 1.9.1-p129 is > > definitely > > ready for production with Rail 2.3.2/Edge IMO. I did have to make some > > minor mods to gems but it was well worth the deep dive. > > Good to know...but why not just use Ruby EE? It acts just like MRI > 1.8.7, so no modification of code is required, but it''s significantly > faster, or at least that''s what the benchmarks say. Is Ruby 1.9 enough > faster than Ruby EE to justify the extra work of modifying gems?AFAIK, Ruby EE is not significantly faster, but has a much smaller memory use? -J> > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted via http://www.ruby-forum.com/. > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en > -~----------~----~----~----~------~----~------~--~----- jan=callcc{|jan|jan};jan.call(jan)
Flower Born wrote:> > AFAIK, Ruby EE is not significantly faster, but has a much smaller > memory use? > > -JAccording to Phusion''s own benchmarks at http://www.rubyenterpriseedition.com/comparisons.html , Ruby EE is faster than MRI, at least in conjunction with Passenger. I recently found a set of Ruby-only benchmarks taking into account JRuby as well as all other leading Ruby interpreters, and in those, I seem to recall that REE fared even better -- comparable to JRuby and significantly faster than MRI. Of course, now I can''t find the URL for that one. :P Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Thu, Jul 2, 2009 at 7:41 PM, Marnen Laibow-Koser < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Flower Born wrote: > > > > AFAIK, Ruby EE is not significantly faster, but has a much smaller > > memory use? > > > > -J > > According to Phusion''s own benchmarks at > http://www.rubyenterpriseedition.com/comparisons.html , Ruby EE is > faster than MRI, at least in conjunction with Passenger. I recently > found a set of Ruby-only benchmarks taking into account JRuby as well as > all other leading Ruby interpreters, and in those, I seem to recall that > REE fared even better -- comparable to JRuby and significantly faster > than MRI. Of course, now I can''t find the URL for that one. :P > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted via http://www.ruby-forum.com/. >Well, here''s Antonio''s Cangiano benchmarks from the December 2008 shootout which tests Ruby performance: http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008 I''m sure that these numbers are different today but it''s snapshot of the performance compared to other implementations back in December. My requirements are different from your requirements because I tend to do more Ruby development without Rails. Also, I need to be able to interact with non-Ruby frameworks/libraries in various parts of the system. -Conrad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Good information Conrad. However, going back to the original question by the OP.. The short answer is (it can be done) The long answer is (with a lot of work and hurdling many issues) So, if you are the type of person that is patient and is willing to work through many possible issues and you don''t mind that some gems are not ready yet - then make the jump. Or, the safe route IMO, is to stay with what you have. -- Posted via http://www.ruby-forum.com/.
On Fri, Jul 3, 2009 at 6:33 AM, Älphä Blüë <rails-mailing-list@andreas-s.net> wrote:> > Good information Conrad. > > However, going back to the original question by the OP.. >> The short answer is (it can be done) > The long answer is (with a lot of work and hurdling many issues) >If you''re versed in C/C++, Ruby C extensions API, C/C++ build process, and understand the Ruby 1.8.6/1.9.1 differences this should be a relatively straight forward process.> > So, if you are the type of person that is patient and is willing to work > through many possible issues and you don''t mind that some gems are not > ready yet - then make the jump. > > Or, the safe route IMO, is to stay with what you have. >A better approach would be to do the following: a) download and install Ruby 1.9 for non-production purposes b) optionally install the relevant multi-ruby gems or write a Ruby/Bash script to switch between the different implementations c) read the README file and execute the relevant tests of the gem(s) you need for your Rails application against the relevant Ruby implementations d) play with your Rails application against the different Ruby implementations by executing the relevant tests of your Rails application as well as browser testing e) now you have a Ruby 1.9 test harness in place for your Rails application In short, one should start to prepare their Rails applications now for Ruby 1.9 and the same could be said for both gems and plugins. Good luck, -Conrad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---