http://blog.gmane.org/gmane.comp.lang.ruby.rails.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10654 On Dec 1, 6:57 pm, "Mislav Marohnić" <mislav.maroh...< at >gmail.com> wrote: Thanks! I think you're onto something... the whole stack trace is below, but now I see that rake rails:update did not update the scripts; so it still had my 2.1 version of script/about, wheres the 2.2 version explicitly adds the rails_info directory to the load path. Methinks many other things didn't get updated, either. What's the "right" way to make sure everything gets updated to 2.2.2? Here's the whole stack trace I get when trying to start script/server, for example - maybe I'm missing something obvious? (purple) current: script/server => Booting Thin (use 'script/server webrick' to force WEBrick) => Rails 2.2.2 application starting on http://0.0.0.0:3000 => Ctrl-C to shutdown server Exiting /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ template_handler.rb:11:in `initialize': wrong number of arguments (0 for 1) (ArgumentError) from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/template_handler.rb:11:in `new' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/template_handler.rb:11:in `call' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/renderable.rb:21:in `_unmemoized_compiled_source' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:57:in `compiled_source' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:25:in `__send__' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:25:in `memoize_all' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:22:in `each' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:22:in `memoize_all' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/memoizable.rb:17:in `freeze' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:88:in `reload!' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:102:in `templates_in_path' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:100:in `each' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:100:in `templates_in_path' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:86:in `reload!' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:78:in `load' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `load' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `each' from /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/ action_view/paths.rb:109:in `load' from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 357:in `load_view_paths' from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 182:in `process' from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 112:in `send' from ./script/../config/../vendor/rails/railties/lib/initializer.rb: 112:in `run' from /home/jcohen/sites/pw/current/config/environment.rb:13 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:521:in `new_constants_in' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/rails.rb: 31:in `load_application' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/rails.rb: 23:in `initialize' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/ loader.rb:36:in `new' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/rack/adapter/ loader.rb:36:in `for' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/controllers/ controller.rb:163:in `load_adapter' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/controllers/ controller.rb:67:in `start' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `send' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `run_command' from /usr/lib/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:139:in `run!' from /home/jcohen/sites/pw/current/vendor/rails/railties/lib/commands/ servers/thin.rb:20 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:521:in `new_constants_in' from /home/jcohen/sites/pw/current/vendor/rails/activesupport/lib/ active_support/dependencies.rb:153:in `require' from /home/jcohen/sites/pw/current/vendor/rails/railties/lib/commands/ server.rb:49 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from script/server:3 Thanks again! Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Jeff 2008-12-02T01:07:40 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10653 Sounds more like an issue where you have mismatching framework versions. You should have posted the full stack trace. Does every line come from vendored rails, or did some framework load accidentally from a gem? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Mislav Marohnić 2008-12-02T00:57:25 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10652 I started a thread over on rails-talk (http://groups.google.com/group/ rubyonrails-talk/browse_thread/thread/e799165794ea0052) but got no responses, and am a little concerned this might be an issue with Ruby 1.8.7 and Rails 2.2.2, if only because I can't eliminate any other possibilities yet. Here's the story: shortly after upgrading my Slice server from Ubuntu 8.04 to 8.10 - which upgraded Ruby to 1.8.7 along the way - I found that I couldn't start up my app anymore. The app was frozen to 2.1, and after realizing the Ruby upgrade, I re-froze to 2.2. Still wouldn't work; doing a script/about yields this error message: /home/jcohen/sites/pw/current/vendor/rails/actionpack/lib/action_view/ template_handler.rb:11:in `initialize':ArgumentError: wrong number of arguments (0 for 1) After much trial and error, I came to notice that the $LOAD_PATH is a bit messed up; the server app does not have the following in the $LOAD_PATH like my local app does: ../vendor/rails/railties/builtin/rails_info/ Not sure why this would explain the error, but I'm trying to figure out why I'd get that strange error when the only difference I can see is a change from 1.8.6 to 1.8.7. I've tried switching from frozen Rails to 2.2.2 gems but it made no difference. Any ideas/insights/suggestions would be very welcome, this is driving me nuts; if this is surely not a Rails bug, then I'll continue on the rails-talk list instead. Thanks Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Jeff 2008-12-02T00:46:46 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10651 No worries. I ended up over writing both the getting and the setting in the app since I was relying on another subtle aspect of the behavior which I think changed. so why not try something like: Makes sense. I'm hoping to come back and have another look at this when I get chance, I'll let you know when I do. Cheers, Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Paul Horsfall 2008-12-01T23:24:54 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10650 Names in CHANGELOGs are going to be normalized with the mapping that resulted from the effort in this thread: http://gist.github.com/23458 This is the current patch: http://rails.lighthouseapp.com/projects/8994/tickets/1495 Please if you'd like to have a different "canonical" name/nick/whatever just drop me a line! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Xavier Noria 2008-12-01T22:31:06 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10649 Any chance of having these work by scope/proxy, instead? For instance: MyTable.all.each do |record| ... end Or, something like this, with named scopes: User.registered.customers.each do |user| ... end I think this already works, actually -- it just implicitly converts the AssociationProxy to an array. In other words, it slurps the entire result set. It would be nice if this behavior could be made to transparently (or optionally) do what you've implemented, rather than inventing a whole new interface -- for example, find_each doesn't help when you want to use other things from Enumerable, like select/reject, inject, etc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- David Masover 2008-12-01T21:47:18 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10648 Nice! I'd love to see something along these lines baked right in to 2.3 Michael Koziarski 2008-12-01T20:14:14 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10647 Keep in mind that multiple instances of rails will be running on all but the simplest applications, so relying on in-application information will be broken from the start since each instance of the application will have it's own in-memory objects. I agree it would be nice to not need to reload the object after an increment/decrement call is made, but I think the proper solution would be to retrieve the new value from the database after the UPDATE has occurred. One way I think this could be done is by issuing a query similar to this: UPDATE users SET score = score + 1 WHERE users.id = 1; SELECT users.score FROM users WHERE users.id = 1; Then the return value from that query could be used to update the in- memory object. You still have two separate db operations, but at least they come through in one back and forth trip to the db, which is where the wost of the performance penalty occurs in this type of sequence (at least, that's what my profiling has shown). Also note that this new in-memory value is again immediately stale upon retrieval and you'd to do a select for update inside a transaction if you wanted to use that value to write back to the db. As for the bi-directionality of in-memory AR objects, you should check out the parental-control plugin, which while incomplete, covers quite a bit of what is needed to support bi-directional associations in rails: http://github.com/h-lame/parental_control/tree/master Cheers, Andrew On Nov 30, 6:15 pm, adamc <adam.coo...< at >gmail.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- acechase 2008-12-01T20:06:14 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10646 Applied to master and 2-2 stable. Are there any other pending gems changes we should investigate before we cut a 2.2 point release to address On Wed, Nov 26, 2008 at 6:46 AM, Kenneth Kalmer <kenneth.kalmer< at >gmail.com> wrote: Michael Koziarski 2008-12-01T19:46:26 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10645 Sorry this took so long. Conferences and projects lead to less mailing list time. We already have special code in there for serialized Date and Time classes, so why not try something like: http://pastie.caboo.se/327995 That causes two tests to fail simply because they're testing on uniqueness of a serialized field while not storing serialized fields in the database. Michael Koziarski 2008-12-01T19:07:04 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10644 Hey Chris, No, I don't think it has, you're welcome to do the change regarding "require_frameworks" (but you'll have to drop silence warnings as I did). I was supposed to do it (because I ranted about it), but because I've patched the issue in my own app I forgot to do the same to rails. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Mislav Marohnić 2008-12-01T18:07:09 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10643 Koz (or others), Has this issue has been addressed, and if so, in which commit? -Chris On Nov 7, 3:07 am, "Michael Koziarski" <mich...< at >koziarski.com> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Chris Cruft 2008-12-01T17:15:03 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10642 OK, so from my perspective the ideal solution would be that you can just tell your users to require the json gem *after* activesupport, and have everything 'just work' because it nukes our methods. If that's not the case, lets fix it. Our current json implementation works fine for my projects, if there are bugs we should fix them. But 'just rewrite it' is generally a great way to break stuff and piss people off. Michael Koziarski 2008-12-01T16:54:57 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10641 On 1 Dec 2008, at 02:15, adamc wrote: Be aware of the subtleties involved if someone else has also created a record (which is why the counter code doesn't just do foo.bars_counter += 1; foo.save) Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Frederick Cheung 2008-12-01T12:08:46 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10640 On Mon, Dec 1, 2008 at 11:05 AM, Mislav Marohnić <mislav.marohnic< at >gmail.com> wrote: Seems like it. They're not particularly portable, nor are they particularly useful. Every project I've worked on uses some other method of process spawning and monitoring. Monit, God, Runit, mongrel_cluster, etc. Shipping with a mostly-broken set of scripts doesn't seem like something we should do. 2.3 is probably a while off, so hopefully the cobwebs get blown out and no one even notices :). I think we'll send jamis some patches to change the default capistrano recipes, or remove them entirely, or something. Michael Koziarski 2008-12-01T10:29:39 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10639 Re: github.com/rails/rails/commit/3b3c05 Says process scripts were extracted to github.com/rails/irs_process_scripts, but that repo hasn't been pushed to. Did DHH forget? What was the reason for this change; because it wasn't portable (unix only)? Has it something to do with moving over to Rack? Default Capistrano recipe kinda relies on these and I use them in most of my projects that aren't on Passenger. Thanks, # Mislav --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- Mislav Marohnić 2008-12-01T10:05:28 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10638 Hello, For an internal project we were looking for a solution which extends ActiveRecord by an iterator function. Using find(:all) is no fun if you have to process some 10.000 records. Until now there have been two ways of dealing with that scenario: - write your logic a second times (e.g. use stored procedure) - bet on AR plugins which work around that limitation by fetching IDs and processing them in groups, or by using :offset and :limit Rewriting logic is something we wanted to avoid, and the plugins don't fully respect transactional contexts. So we started to implement our own true iterator support for AR. Our project is on Oracle, but in the meantime we have added support for MySQL. Probably other adapters can be extended easily, too. We also tried JRuby 1.1.x, which is sometimes faster than Ruby 1.8.6, but a patch is needed to bring the Java part of the connection adapter into shape for a result set iteration. Okay, you're about to ask: how does it work. Here we go: MyTable.find_each_by_sql("some SQL here") { |my_table| ... } MyTable.find_each(:all, :conditions => ..., :include => ...) { |my_table| ... } Attached you find the magic code which can be used as a plugin for Rails. When testing, please keep in mind that only Oracle and MySQL is fully supported. JDBC will take lots of RAM for large result sets until you have patched the JdbcConnectionAdapter. Some figures with JRuby: I've tested the code for an export of ~80.000 customer data records. Originally I couldn't run the export with heap space less than 2 GB (JRuby 1.1.4 without extensive garbage collection). After having patched the connection adapter, it works with less than 128 MB heap space (JRuby 1.1). I'd be happy if our idea would be picked up and AR would get these iterator methods integrated. I've seen lots of people asking for exactly this behavior. It's possible to implement, it's easy to implement, and IMHO it doesn't break the AR metaphor. If you like the idea and want to send feedback, please CC me. I'm not subscribed to the list. Regards, Andreas Andreas Gungl 2008-11-29T14:14:00 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10637 Hi, I've started looking at the counter_cache implementation with the original intention to have the increment, decrement update the model in memory (without relying on a reload) to be called. You can see a sample of the bug here: http://gist.github.com/30580. While starting to look at this issue (my first real look at the rails code base) I'm wondering if anyone has already done any initial thinking of this issue or has an idea of what they would like to see happen here. In my initial thinking (I haven't looked at the association proxy/collection enough) there could be a bi-directional link for the has_many/belongs_to reflections/assocations. Looking around I noticed a small bug with custom counter cache names not be utilized in the record with the has_many association. There is currently no way for this association/reflection object to know about the belongs_to settings where the counter_cache name is set. An easy way to quickly solve this is to add a :counter_cache => 'custom_name' to the has_many method call. What are your thoughts on this proposed change for the has_many options? Thanks, Adam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core< at >googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe< at >googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~--- adamc 2008-12-01T02:15:15 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10636 Agreed. For my example above it works perfectly well, since I'm not really concerned with the Time instances. They're just part of a JSON payload, and I control only part of the payload (where time doesn't matter). How about this? (Don't kill me if I've stepped out of line here). When the JSON gem(s) are present and loaded prior to ActiveSupport, ActiveSupport backs off from re-defining all the #to_json methods and delegate the decoding work to JSON again. Another obvious thing would be to load ActiveSupport before JSON and have JSON simply overwrite the work of ActiveSupport. Another option might be to strip down json_pure and bundle it into ActiveSupport, seeing my local copy is roughly 756KB... But the co-existance of the JSON and ActiveSupport gems in the same projects cannot be ignored. The ruote project, and other fast moving targets like CouchDB will make this an increasingly bigger issue in the future. I honestly don't know what the impact of any of these would be. I'll keep on throwing ideas at the list, even if it is all the wrong ones, just to keep the thoughts churning and get us closer to a solution. Anycase, thanks for your patience. Kenneth Kalmer 2008-11-29T12:46:43 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10635 I'm a little hesitant because those arguments to to_json are just ignored. So you get 'compatibility' in the sense that you don't get an ArgumentError, but it won't do what you think it will. Silent misbehaviour here seems *worse* than failing fast? Michael Koziarski 2008-11-29T12:30:05 http://permalink.gmane.org/gmane.comp.lang.ruby.rails.core/10634 This is something that's being worked on in edge rails at present. The goal is to move that preloading code to be as 'lazy' as it can be. The code still needs to fire in order to allow thread safe dispatching, but there's definitely no reason to do it for rake tasks, script/runner etc. Josh and jeremy have been hacking away on it, perhaps they have something to add? Michael Koziarski 2008-11-29T11:55:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.rails.core