So apparently 1.8.4 is soon forthcoming. We need testing against it. Could someone help out with that? I believe Ara already checked into some of the issues, do you know if those are resolved, Ara? -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On 12/18/05, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:> So apparently 1.8.4 is soon forthcoming. We need testing against it. > Could someone help out with that? I believe Ara already checked into > some of the issues, do you know if those are resolved, Ara? > --Is there a list of the tests that are known to fail already on Win32? "test_default" in the AR suite fails against PostgreSQL, for example, and then there''s the Iconv thing for ActionMailer, etc. I''d be happy to bang on 1.8.4, but I don''t want to re-report things that are already broken. Thanks, --Wilson.
On Dec 18, 2005, at 13:37, David Heinemeier Hansson wrote:> So apparently 1.8.4 is soon forthcoming. We need testing against it. > Could someone help out with that? I believe Ara already checked into > some of the issues, do you know if those are resolved, Ara?Some guidelines on how to test on 1.8.4 while leaving 1.8.2 intact for regular development would be greatly welcome.
mkdir $HOME/local ./configure --prefix=$HOME/local make make install ruby -v #=> 1.8.2 export PATH=$HOME/local/bin:$PATH ruby -v #=> 1.8.4 On 12/19/05, Caio Chassot <lists@v2studio.com> wrote:> > On Dec 18, 2005, at 13:37, David Heinemeier Hansson wrote: > > > So apparently 1.8.4 is soon forthcoming. We need testing against it. > > Could someone help out with that? I believe Ara already checked into > > some of the issues, do you know if those are resolved, Ara? > > Some guidelines on how to test on 1.8.4 while leaving 1.8.2 intact > for regular development would be greatly welcome. > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Tobi http://jadedpixel.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
On Sun, Dec 18, 2005 at 09:37:57AM -0600, David Heinemeier Hansson wrote:> So apparently 1.8.4 is soon forthcoming. We need testing against it.The major production Rails application I''m developing at work is running just fine and passing all tests with Rails 1.0 gems and Ruby 1.8.4 preview 2 on Debian GNU/Linux unstable. Thanks + HTH, -- Keegan Quinn <keegan@thebasement.org> CEO, Producer the basement productions http://www.thebasement.org _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On Sun, 18 Dec 2005, David Heinemeier Hansson wrote:> So apparently 1.8.4 is soon forthcoming. We need testing against it. Could > someone help out with that? I believe Ara already checked into some of the > issues, do you know if those are resolved, Ara?they are not resolved. however, i could only re-produce them on an older version of freebsd. the box is scheduled to be upgraded this week. my feeling was that i''d wait for the upgrade to see if that fixed the issue. a summary of the problem is simply that rails does a lot of this kind of thing: def foo end alias "bar", "foo" alias "foobar", "bar" alias "foo", "foobar" def foo # new one this time end and this causes infinite recursion when double includes happen - which i see on freebsd but not on linux. the solution is to examine the const_missing/autoloading that''s going on and, more importantly, to avoid these potential cyclic function calls. in my case i was able to fix by simply def __foo end alias "bar", "__foo" alias "foobar", "bar" alias "foo", "foobar" def foo # new one this time end but then there are plenty of instances of this style. read earlier threads for more info... i can look into this more but have some outstanding questions regarding the purpose of redefining methods that way and the autoloading philosophy which i''d like to understand before hacking. regards. -a -- ==============================================================================| ara [dot] t [dot] howard [at] gmails [dot] com | all happiness comes from the desire for others to be happy. all misery | comes from the desire for oneself to be happy. | -- bodhicaryavatara ===============================================================================
> i can look into this more but have some outstanding questions regarding the > purpose of redefining methods that way and the autoloading philosophy which > i''d like to understand before hacking.The problem is definitely double inclusion. Rails is not double inclusion safe and I don''t think its worth making it so. So we should instead make sure that it never happens. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On Thu, 22 Dec 2005, David Heinemeier Hansson wrote:>> i can look into this more but have some outstanding questions regarding the >> purpose of redefining methods that way and the autoloading philosophy which >> i''d like to understand before hacking. > > The problem is definitely double inclusion. Rails is not double > inclusion safe and I don''t think its worth making it so. So we should > instead make sure that it never happens.unfortunately that means the fix must be rather inclusive.... here''s a short summary of the problem extracted from the rails source base: harp:~ > cat a.rb module ActiveRecord class Base class << self def instantiate p 42 end end end end module ActiveRecord module Callbacks def self.append_features(base) #:nodoc: super base.extend(ClassMethods) base.class_eval do class << self alias_method :instantiate_without_callbacks, :instantiate alias_method :instantiate, :instantiate_with_callbacks end end end module ClassMethods def instantiate_with_callbacks instantiate_without_callbacks end end end end ActiveRecord::Base.class_eval do include ActiveRecord::Callbacks include ActiveRecord::Callbacks end ActiveRecord::Base.instantiate harp:~ > ruby a.rb a.rb:25:in `instantiate_without_callbacks'': stack level too deep (SystemStackError) from a.rb:25:in `instantiate'' from a.rb:37 the fix is quite simple def __instantiate p 42 end alias_method :instantiate_without_callbacks, :__instantiate alias_method :instantiate, :instantiate_with_callbacks def instantiate_with_callbacks instantiate_without_callbacks end but this kind of thing happens all over the place. of course it is only triggered when double inclusion happens. i still do not understand why double inclusion was occuring on some platforms and not others - but cleaning up this fragile approach can only help matters. i''d volunteer but aren''t familiar enough with the code base to know all locations of this potential circular method chaining... the other approach is, of course, to implement a require_once functionality early (first thing) in the rails code base. one i put together can be found here. http://wrath.rubyonrails.org/pipermail/rails-core/2005-December/000361.html as this kind of fix might be able to be done at a global level with little effort - it seems worth considering. obivously the above needs tested - i haven''t even run it on windows for intstance. regards. -a -- ==============================================================================| ara [dot] t [dot] howard [at] noaa [dot] gov | all happiness comes from the desire for others to be happy. all misery | comes from the desire for oneself to be happy. | -- bodhicaryavatara ===============================================================================