Weird (AS::Dependencies?) bug

109 views
Skip to first unread message

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 8:58:13 AM2/8/13
to rubyonra...@googlegroups.com
There is a long dating bug affecting my application for a while but I
never bothered to investigate it because it only affected the first
request to my application and only under development environment (where
autoload is used by Rails).

This is what I get:

rails s
=> Booting WEBrick
=> Rails 3.2.11 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2013-02-08 11:50:42] INFO WEBrick 1.3.1
[2013-02-08 11:50:42] INFO ruby 1.9.3 (2013-01-15) [x86_64-linux]
[2013-02-08 11:50:42] INFO WEBrick::HTTPServer#start: pid=1537 port=3000


Started POST "/search/store_state" for 127.0.0.1 at 2013-02-08 11:51:04
-0200

ActionController::RoutingError (uninitialized constant
ActionView::Helpers::NumberHelper):
lib/parse_format_utils.rb:2:in `<top (required)>'
lib/query_builder.rb:4:in `<top (required)>'
lib/search_results.rb:3:in `<top (required)>'
app/controllers/search_controller.rb:1:in `<top (required)>'

parse_format_utils.rb:2 => require 'action_view/helpers/number_helper'

I've modified it to:

begin
require 'action_view/helpers/number_helper'
rescue Exception => e
p e
puts e.backtrace.join "\n"
end

Here is the output:

> rails s
=> Booting WEBrick
=> Rails 3.2.11 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2013-02-08 11:32:04] INFO WEBrick 1.3.1
[2013-02-08 11:32:04] INFO ruby 1.9.3 (2013-01-15) [x86_64-linux]
[2013-02-08 11:32:04] INFO WEBrick::HTTPServer#start: pid=1061 port=3000
#<NameError: uninitialized constant ActionView::Helpers::NumberHelper>
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_view/helpers.rb:50:in
`<module:Helpers>'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_view/helpers.rb:4:in
`<module:ActionView>'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_view/helpers.rb:3:in
`<top (required)>'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_view/helpers/number_helper.rb:10:in
`<module:ActionView>'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_view/helpers/number_helper.rb:8:in
`<top (required)>'
/home/rodrigo/ecore/src/myapp/lib/parse_format_utils.rb:3:in `<top
(required)>'
/home/rodrigo/ecore/src/myapp/lib/query_builder.rb:4:in `<top (required)>'
/home/rodrigo/ecore/src/myapp/lib/search_results.rb:3:in `<top (required)>'
/home/rodrigo/ecore/src/myapp/app/controllers/search_controller.rb:1:in
`<top (required)>'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/inflector/methods.rb:230:in
`block in constantize'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/inflector/methods.rb:229:in
`each'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/inflector/methods.rb:229:in
`constantize'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/routing/route_set.rb:69:in
`controller_reference'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/routing/route_set.rb:54:in
`controller'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/routing/route_set.rb:32:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/journey-1.0.4/lib/journey/router.rb:68:in
`block in call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/journey-1.0.4/lib/journey/router.rb:56:in
`each'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/journey-1.0.4/lib/journey/router.rb:56:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/routing/route_set.rb:601:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/warden-1.2.1/lib/warden/manager.rb:35:in
`block in call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/warden-1.2.1/lib/warden/manager.rb:34:in
`catch'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/warden-1.2.1/lib/warden/manager.rb:34:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/best_standards_support.rb:17:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/etag.rb:23:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/conditionalget.rb:35:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/head.rb:14:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/params_parser.rb:21:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/flash.rb:242:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/session/abstract/id.rb:210:in
`context'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/session/abstract/id.rb:205:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/cookies.rb:341:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/callbacks.rb:28:in
`block in call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/callbacks.rb:405:in
`_run__2728328958449052391__call__575225088242605981__callbacks'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/callbacks.rb:405:in
`__run_callback'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/callbacks.rb:385:in
`_run_call_callbacks'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/callbacks.rb:81:in
`run_callbacks'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/callbacks.rb:27:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/reloader.rb:65:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/remote_ip.rb:31:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/debug_exceptions.rb:16:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/show_exceptions.rb:56:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/rack/logger.rb:32:in
`call_app'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/rack/logger.rb:16:in
`block in call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/tagged_logging.rb:22:in
`tagged'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/rack/logger.rb:16:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/request_id.rb:22:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/runtime.rb:17:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/activesupport-3.2.11/lib/active_support/cache/strategy/local_cache.rb:72:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/lock.rb:15:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/actionpack-3.2.11/lib/action_dispatch/middleware/static.rb:62:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/engine.rb:479:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/application.rb:223:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/content_length.rb:14:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/railties-3.2.11/lib/rails/rack/log_tailer.rb:17:in
`call'
/home/rodrigo/.rvm/gems/ruby-1.9.3-p374/gems/rack-1.4.5/lib/rack/handler/webrick.rb:59:in
`service'
/home/rodrigo/.rvm/rubies/ruby-1.9.3-p374/lib/ruby/1.9.1/webrick/httpserver.rb:138:in
`service'
/home/rodrigo/.rvm/rubies/ruby-1.9.3-p374/lib/ruby/1.9.1/webrick/httpserver.rb:94:in
`run'
/home/rodrigo/.rvm/rubies/ruby-1.9.3-p374/lib/ruby/1.9.1/webrick/server.rb:191:in
`block in start_thread'


Any ideas what is happening here? I have no clue! Why a code like this
would automatically load helpers.rb?

helpers/number_helper.rb:

8: module ActionView
9: # = Action View Number Helpers
10: module Helpers #:nodoc:

Thanks in advance,
Rodrigo.

Xavier Noria

unread,
Feb 8, 2013, 9:06:27 AM2/8/13
to rubyonra...@googlegroups.com
Seems unrelated to dependencies.rb, most likely a missing require somewhere within Rails.

It can be the case that it does not show up in production because of eager loading.

Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 9:18:55 AM2/8/13
to rubyonra...@googlegroups.com
Em 08-02-2013 12:06, Xavier Noria escreveu:
> Seems unrelated to dependencies.rb, most likely a missing require somewhere within Rails.
>
> It can be the case that it does not show up in production because of eager loading.

Any ideas why helpers.rb is loaded when you write code like below?

module ActionView
module Helpers
module NumberHelper

Is this normal MRI behavior or is this caused by dependencies.rb?

Xavier Noria

unread,
Feb 8, 2013, 10:03:41 AM2/8/13
to rubyonrails-core
Ruby on Rails itself does not use dependencies.rb to load its code. It
is a regular Ruby library that uses requires and Kernel#autoload with
some added sugar. AS::Dependencies only covers application constant
autoloading.

The thing goes like this: When an application boots in any environment
action_view.rb is loaded. When that file is executed an autoload for
:Helpers is configured under ActionView. In a default setup,
helpers.rb is not yet loaded. That is, if you run

rails runner 1

helpers.rb is not loaded (at least in 3-2-stable, not that we are
explaining any contract, only load order execution to follow what
happens in your exception).

But if you force the evaluation of the constant as in your example above:

module ActionView
module Helpers
...
end
end

that autoload is triggered because the interpreter checks whether
"Helpers" is a constant defined in the module object stored in
ActionView. Therefore, helpers.rb is interpreted and sets in turn an
autoload for NumberHelper below AV::Helpers.

So, module Helpers in that snippet *reopens* a module object defined
via the autoload, rather than creating the module object. The
execution follows and the same happens with the "NumberHelper"
constant down below. The interpreter checks whether it belongs to the
module object stored in AV::Helpers. Since it is unknown and there is
an autoload for it it gets triggered, and loads... well the very
number_helper.rb whose execution we were in the middle of (not sure
this sentence is valid English :).

I suspect there is a circularity here that is showing up that way.

Would need to dig deeper to fully explain how this ends up in an
exception, maybe I'll do it tonight, but in the meantime here's some
context in case it helps.

Peter Vandenabeele

unread,
Feb 8, 2013, 11:16:48 AM2/8/13
to rubyonra...@googlegroups.com
I think I was fighting the same bug some time ago ...

(the resolution for me to avoid any explicit use of
'require' in the application and depend fully on autoloading).

Doing what amounts to a "circular" call of 'require' triggers it. The
second time around, it seems to have forgotten the results of the
earlier require (IIRC, the second call to require is not really executed,
(correct, because it was already executed), but the result of the require
seems to be forgotten ...) and then later on, when that module is called,
I got an

  uninitialized constant

exception.

Only occurs in development (not in test or production),
actually with WEBrick.

app/models $ head -10 sparql.rb 
#
#
#
#
#
#

require 'sparql/query'

module Sparql


app/models $ head -12 sparql/query.rb 
#
#
#
#
#
#

module Sparql

  class Query

    include Sparql::Helper



app/models $ head -12 sparql/helper.rb 
#
#
#
#
#
#

require 'sparql'

module Sparql
  module Helper



Yields:

uninitialized constant Sparql::Helper

Rails.root: ... demo-001

Application Trace | Framework Trace | Full Trace
app/models/sparql.rb:14:in `singletonclass'
app/models/sparql.rb:12:in `<module:Sparql>'
app/models/sparql.rb:10:in `<top (required)>'
app/models/sparql/helper.rb:8:in `<top (required)>'
app/models/sparql/query.rb:12:in `<class:Query>'
app/models/sparql/query.rb:10:in `<module:Sparql>'
app/models/sparql/query.rb:8:in `<top (required)>'
app/models/sparql.rb:8:in `<top (required)>'

The 'require' statements are actually not required if all files are
in the correct place for autoloading and then this issue completely
disappears.

HTH,

peter_v

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 11:45:59 AM2/8/13
to rubyonra...@googlegroups.com
It makes total sense. What doesn't make sense is the source of helpers.rb to me:

https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers.rb

First it should explicitly require (or require_dependency) 'active_support/autoload' and 'active_support/concern', right?

But then, why using autoload if you're just including all modules next?

Xavier Noria

unread,
Feb 8, 2013, 12:00:32 PM2/8/13
to rubyonra...@googlegroups.com
Some very common files are loaded at the entry point of every component, to avoid repeating their require again and again:


As for the autoload + include, I don't really know, maybe it is a fancy way to avoid writing a file path. Seems unnecessary to me at first glance. Maybe someone else from the team has a better justification?

Sent from my iPhone
--

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:12:58 PM2/8/13
to rubyonra...@googlegroups.com
Em 08-02-2013 15:00, Xavier Noria escreveu:
Some very common files are loaded at the entry point of every component, to avoid repeating their require again and again:


But shouldn't helpers.rb require 'active_support/rails' then instead of just 'active_support/benchmarkable'?

Otherwise it should be documented that we're not supposed to require specific parts of some libraries included in Rails... That way I'd know (although surprised) that I'm not supposed to require 'action_view/helpers/number_helper' but simply 'action_view/helpers' (or just 'action_view'?)

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:20:39 PM2/8/13
to rubyonra...@googlegroups.com
Anyway, thanks for your input. It helped documenting the bug in my own code and stop the exception on the first request for dev environment. But here is how my file looks like currently on latest released Rails:

require 'action_view/helpers' # required due to bug in Rails: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-core/2EV3tpWIhPI
require 'action_view/helpers/number_helper'
# number_helper depends on non declared module below. This is fixed on Rails master and 3.2-stable branch so this can be removed
# once we upgrade to Rails 4 or when a new Rails 3.2 is released:
require 'active_support/core_ext/hash/keys'
require 'active_support/core_ext/hash/reverse_merge'


I've fixed the last issues recently in the 3.2-stable branch but I'd still like to be able to remove the first require.

Should I send a pull request to helpers.rb to just replace autoload by regular requires (or require_relative, maybe for master)?

Thanks,
Rodrigo.

Xavier Noria

unread,
Feb 8, 2013, 12:26:56 PM2/8/13
to rubyonra...@googlegroups.com
No, no, as/rails.rb is already required by the entry point
of every component (except AS). That is a given in the
context of a Rails application, and

    gem 'active_record'

does that if standalone.

Sent from my iPhone

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:36:26 PM2/8/13
to rubyonra...@googlegroups.com
I don't understand what you mean. In my unit tests involving ParseFormatUtils for instance Rails is never loaded and my application doesn't even use ActiveRecord.

But my tests weren't complaining anyway because they don't autoload ActionView/Helpers.

Also, even if I explicitly required as/rails it wouldn't fix the situation for my case.

This is what's happening in a simplified way:


./test.rb:
autoload :A, 'a'
require 'a/b'

./lib/a.rb:
module A
  autoload :B, 'a/b'
  include B
end

./lib/a/b.rb:
module A
  module B
  end
end

ruby -I lib test.rb


This is enough to create the circular dependency error. Maybe this is one of the reasons why Matz wants to remove autoload from Ruby...

Sorry but I don't have any suggestions right now that would make require 'a/b' work if 'a' is set to be autoloaded and 'a' requires 'b' which depends on 'a'...

Unless we create some 'action_view/helpers/all.rb'  file. Would that be acceptable?

Best,
Rodrigo.

Xavier Noria

unread,
Feb 8, 2013, 12:42:45 PM2/8/13
to rubyonra...@googlegroups.com, rubyonra...@googlegroups.com
I am only explaining why autoload and concern have no explicit requires in that file. That was a tangential question you did not directly related to the exception.

Sent from my iPhone

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:46:33 PM2/8/13
to rubyonra...@googlegroups.com
I know it is tangential. I was just explaining why I don't agree with the current approach because non Rails code could rely only on 'action_view/helpers', don't you agree? How are they supposed to know that they should first require 'active_support/rails' or any other entry point?

I don't think it is fine to just assume that ActionView classes only make sense in within the Rails context. This is an unsafe assumption that I don't agree with.

Rafael Mendonça França

unread,
Feb 8, 2013, 12:51:11 PM2/8/13
to rubyonra...@googlegroups.com
The correct way to use any one of the rails pieces is to require the framework file first.

You have to do

require 'action_view' # this file only loads what is needed to use the framework inside and outside the rails scope
require 'action_view/helpers'

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:53:16 PM2/8/13
to rubyonra...@googlegroups.com
Is this documented somewhere? Since it doesn't follow any best practices I think this particular Rails behavior should be documented, right?

Rafael Mendonça França

unread,
Feb 8, 2013, 12:53:06 PM2/8/13
to rubyonra...@googlegroups.com

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 12:59:47 PM2/8/13
to rubyonra...@googlegroups.com
At least, now that I know that this behavior is intentional in Rails I documented myself in my own class so that other developers could also understand the reason I'm depending on full ActionView when I really depend only on NumberHelper:

require 'bigdecimal'
# In Rails, if you need action_view/helpers/number_helper you have to require 'action_view',
# then 'action_view/helpers and finally 'action_view/helpers/number_helper'. Pretty stupid but we don't control
# Rails. Since ActionView will load all components, we don't need to require the other files, just 'action_view':
require 'action_view'
#require 'action_view/helpers/number_helper'

Rafael Mendonça França

unread,
Feb 8, 2013, 1:04:55 PM2/8/13
to rubyonra...@googlegroups.com
I don't remember if this is documented somewhere but I don't think we have a guide to "How to use Rails pieces outside Rails" to put this kind of information.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:06:49 PM2/8/13
to rubyonra...@googlegroups.com
If I wrote a small guide on the subject would it be accepted?

Xavier Noria

unread,
Feb 8, 2013, 1:06:19 PM2/8/13
to rubyonrails-core
I would be grateful if you don't insult the project.

Maybe I think twice before expending so much time writing detailed
replies to you again.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:07:52 PM2/8/13
to rubyonra...@googlegroups.com
Sorry.

Xavier Noria

unread,
Feb 8, 2013, 1:09:21 PM2/8/13
to rubyonrails-core
On Fri, Feb 8, 2013 at 7:06 PM, Rodrigo Rosenfeld Rosas
<rr.r...@gmail.com> wrote:

> If I wrote a small guide on the subject would it be accepted?

Not qualified, it is clear to the whole Universe that you don't use
Active Record, because you say it at every single opportunity you
have. Thank you anyway.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:11:04 PM2/8/13
to rubyonra...@googlegroups.com
The guide wouldn't be about ActiveRecord, but I got the message.

Rafael Mendonça França

unread,
Feb 8, 2013, 1:18:03 PM2/8/13
to rubyonra...@googlegroups.com
Before calling something or someone stupid please try to understand the person/project, its historical reasons, its needs.

Talking about something you don't understand is very easy.

Next time think twice before insulting the project on this list again, or you could not get replies.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:22:54 PM2/8/13
to rubyonra...@googlegroups.com
I was planning to send a particular message to Xavier about that but it
seems he was not the only one offended.

I'd like to apologize about that and I simply forgot to remove that
particular opinion from the message. I just copied and pasted my
solution and forgot I had written that along the other lines.

It wasn't my intention to publicly offend any of you. I should have
re-read my message and removed that "stupid" piece from it if I have
noticed it there.

It was intended to be kept only in my private repository as my
particular opinion on the subject.

It wasn't meant to offend any of you.

So sorry about that.

Xavier Noria

unread,
Feb 8, 2013, 1:24:04 PM2/8/13
to rubyonrails-core
On Fri, Feb 8, 2013 at 7:22 PM, Rodrigo Rosenfeld Rosas
<rr.r...@gmail.com> wrote:
> I was planning to send a particular message to Xavier about that but it
> seems he was not the only one offended.
>
> I'd like to apologize about that and I simply forgot to remove that
> particular opinion from the message. I just copied and pasted my solution
> and forgot I had written that along the other lines.
>
> It wasn't my intention to publicly offend any of you. I should have re-read
> my message and removed that "stupid" piece from it if I have noticed it
> there.
>
> It was intended to be kept only in my private repository as my particular
> opinion on the subject.
>
> It wasn't meant to offend any of you.
>
> So sorry about that.
>
> Em 08-02-2013 16:18, Rafael Mendonça França escreveu:
>
>> Before calling something or someone stupid please try to understand the
>> person/project, its historical reasons, its needs.
>>
>> Talking about something you don't understand is very easy.
>>
>> Next time think twice before insulting the project on this list again, or
>> you could not get replies.
>>
>

Xavier Noria

unread,
Feb 8, 2013, 1:24:28 PM2/8/13
to rubyonrails-core
Accepted, thanks for the email.

On Fri, Feb 8, 2013 at 7:22 PM, Rodrigo Rosenfeld Rosas
<rr.r...@gmail.com> wrote:
> I was planning to send a particular message to Xavier about that but it
> seems he was not the only one offended.
>
> I'd like to apologize about that and I simply forgot to remove that
> particular opinion from the message. I just copied and pasted my solution
> and forgot I had written that along the other lines.
>
> It wasn't my intention to publicly offend any of you. I should have re-read
> my message and removed that "stupid" piece from it if I have noticed it
> there.
>
> It was intended to be kept only in my private repository as my particular
> opinion on the subject.
>
> It wasn't meant to offend any of you.
>
> So sorry about that.
>
> Em 08-02-2013 16:18, Rafael Mendonça França escreveu:
>
>> Before calling something or someone stupid please try to understand the
>> person/project, its historical reasons, its needs.
>>
>> Talking about something you don't understand is very easy.
>>
>> Next time think twice before insulting the project on this list again, or
>> you could not get replies.
>>
>

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:30:15 PM2/8/13
to rubyonra...@googlegroups.com
Thank you for accepting my appologies and for your awesome work on
Rails, specially on documentation.

By the way, I has being honest about the guide on using parts of Rails
in user applications. If you change your mind about that please let me know.

Em 08-02-2013 16:24, Xavier Noria escreveu:
> Accepted, thanks for the email.
>
> On Fri, Feb 8, 2013 at 7:22 PM, Rodrigo Rosenfeld Rosas
> <rr.r...@gmail.com> wrote:
>> I was planning to send a particular message to Xavier about that but it
>> seems he was not the only one offended.
>>
>> I'd like to apologize about that and I simply forgot to remove that
>> particular opinion from the message. I just copied and pasted my solution
>> and forgot I had written that along the other lines.
>>
>> It wasn't my intention to publicly offend any of you. I should have re-read
>> my message and removed that "stupid" piece from it if I have noticed it
>> there.
>>
>> It was intended to be kept only in my private repository as my particular
>> opinion on the subject.
>>
>> It wasn't meant to offend any of you.
>>
>> So sorry about that.
>>

Rafael Mendonça França

unread,
Feb 8, 2013, 1:36:21 PM2/8/13
to rubyonra...@googlegroups.com
Accepted too.

About the subject, I think we had a guide or a topic in some guide about how to use Action View outside Rails. I'm not 100% sure but if this guide/section existed we reverted it since we thought doesn't make sense to leave it as official documentation since it is too advanced and talks more about the Rails internals and how it is implemented, not about how it is used.

I know is hard to understand the Rails internals but I don't think there are more that we can do that try to answers the people questions.
On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:
I was planning to send a particular message to Xavier about that but it seems he was not the only one offended.

I'd like to apologize about that and I simply forgot to remove that particular opinion from the message. I just copied and pasted my solution and forgot I had written that along the other lines.

It wasn't my intention to publicly offend any of you. I should have re-read my message and removed that "stupid" piece from it if I have noticed it there.

It was intended to be kept only in my private repository as my particular opinion on the subject.

It wasn't meant to offend any of you.

So sorry about that.

Em 08-02-2013 16:18, Rafael Mendonça França escreveu:

Before calling something or someone stupid please try to understand the person/project, its historical reasons, its needs.

Talking about something you don't understand is very easy.

Next time think twice before insulting the project on this list again, or you could not get replies.


--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 1:58:39 PM2/8/13
to rubyonra...@googlegroups.com
I wouldn't mention just ActionView. I believe this approach is used by all major pieces in rails repository, like AR, ActionPack and the like with the exception being AS.

The guide would be something like:

---
"Using Rails components outside Rails" (In some Advanced topics)

Sometimes you may want to rely on parts of Rails pieces in your own code. Maybe you're writing unit tests or maybe you are not using Rails at all (another web framework or the application is not a web one at all).

Still you might be interested on formatting numbers or currency in your code (ActionView::Helpers::NumberHelper), use ActiveRecord, ActiveModel or some other components you might be interested on.

Rails follows a few conventions you should be aware of if you want to try those components outside of the Rails context.

Since most Rails components make extensive use of some core extensions added by ActiveSupport, they're commonly included ('active_support/rails') in the entry point of those frameworks. For instance, if you want to use some part of ActionView you should require the entire ActionView component instead of only the specific part you want. That is because the specific parts may not declare all dependencies on their own files since they were already declared in the entry point of those components.

This avoids requiring all those common files over and over but you have to be aware that it means you have to load the entire component and not just part of it.

So, if you want to use ActionView::Helpers::NumberHelper, please be sure you require 'action_view' instead of 'action_view/helpers/number_helper'.

The same is true for all other components except ActiveSupport who always have explicit dependencies on each file it contains.

---


This is basically what I was proposing.

Best,
Rodrigo.



Em 08-02-2013 16:36, Rafael Mendonça França escreveu:
Accepted too.

About the subject, I think we had a guide or a topic in some guide about how to use Action View outside Rails. I'm not 100% sure but if this guide/section existed we reverted it since we thought doesn't make sense to leave it as official documentation since it is too advanced and talks more about the Rails internals and how it is implemented, not about how it is used.

I know is hard to understand the Rails internals but I don't think there are more that we can do that try to answers the people questions.
On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:
I was planning to send a particular message to Xavier about that but it seems he was not the only one offended.

I'd like to apologize about that and I simply forgot to remove that particular opinion from the message. I just copied and pasted my solution and forgot I had written that along the other lines.

It wasn't my intention to publicly offend any of you. I should have re-read my message and removed that "stupid" piece from it if I have noticed it there.

It was intended to be kept only in my private repository as my particular opinion on the subject.

It wasn't meant to offend any of you.

So sorry about that.

Em 08-02-2013 16:18, Rafael Mendonça França escreveu:

Before calling something or someone stupid please try to understand the person/project, its historical reasons, its needs.

Talking about something you don't understand is very easy.

Next time think twice before insulting the project on this list again, or you could not get replies.


--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

Rafael Mendonça França

unread,
Feb 8, 2013, 2:07:52 PM2/8/13
to rubyonra...@googlegroups.com
Although I agree it is a nice addition, our guides are more about the conventions. This is configuration.

As everyone know Rails is conventions over configurations. So I prefer to leave it outside our guides.

Rodrigo Rosenfeld Rosas

unread,
Feb 8, 2013, 2:09:55 PM2/8/13
to rubyonra...@googlegroups.com
It is convention over configuration, not convention instead of configuration.

How are we supposed to learn how to configure it?

Rafael Mendonça França

unread,
Feb 8, 2013, 2:18:56 PM2/8/13
to rubyonra...@googlegroups.com
Some topics are not fit for the guides, it is really about conventions. Regarding configuration we have a guide only to the applications configurations but I don't think a guide about how to use Rails pieces outside Rails is a good fit to our guide.

The best way to learn about this topic is source diving or asking a someone who know. ;)

José Valim

unread,
Feb 8, 2013, 2:35:38 PM2/8/13
to rubyonra...@googlegroups.com
I don't know what the fuss is about and what needs to be documented.

Most Ruby gems (and even libs inside Ruby) require you to load the *top-level* file in order to use it properly.
You can't go around picking whatever you want and expect it to work. Examples:

1. Rake does common requires:


For example, this file assumes Task is loaded:


2. Rack sets up autoloads:


3. Webrick does the same as Rake:


So saying Rails is "stupid" regarding this requirement shows rather a lack of understanding how most Ruby libraries work.

Ryan Bigg

unread,
Feb 8, 2013, 5:57:20 PM2/8/13
to rubyonra...@googlegroups.com
I agree with José. Is there a tl;dr for this thread?

 
--

Gabriel Sobrinho

unread,
Feb 9, 2013, 10:51:26 AM2/9/13
to rubyonra...@googlegroups.com
I think it should be documented, maybe not on guides but somewhere.

I've opened a issue about a similar subject in the past assuming that was a bug instead of the expected behavior.

Note that I agree that's a "advanced topic" but the truth is we need to document it somewhere.


I would be happy to make a blog post about this topic but posts aren't always found like the official documentation or wiki.

Makes any sense to enable the GitHub wiki?

The GitHub wiki will allow topics like that without making any extra effort from the rails core team who already have a lot of work :)

Xavier Noria

unread,
Feb 9, 2013, 11:08:26 AM2/9/13
to rubyonrails-core
We closed the Rails wiki a while back, wikis rarely work in the long
term and I have a series of reasons why to avoid wikis maintained
outside the project as official documentation.

The documentation of a project belongs to the project and has to
evolve alongside the source code. Everything has to move forward in
sync. That's why we have everything in Git and patches must update
code, tests, and docs to be complete.

If there is a bug we should fix it, but I am with José and I think
this particular use case needs no documentation: you just can't grab a
random file from some lib just because it is available from the load
path and expect it to be self-contained. And the lib does not need to
document which files work and which don't. *Unless* specified
otherwise, when you use a lib you load first its main file.

In Ruby in addition you tend to do that because as anyone who have
maintained a non-trivial Ruby library knows writing self-contained
files that do not depend on load order execution is a fucking
nightmare. It is basically impossible to get right because when you
miss something the interpreter does not (and has no way to) warn you.
So to play safe and to avoid repeating common things a hundred times
you balance being extra careful and factoring common things out to the
entry points.

Johnneylee Rollins

unread,
Feb 9, 2013, 11:12:26 AM2/9/13
to rubyonra...@googlegroups.com
Not to be argumentative,

But I've been having a good time lately of making each file require only
what it needs to function on its own. Sometimes I have to require every
file, but most of the time I get to be able to do what rosenfeld likes.

I agree that this kind of documentation is a bit unnecessary,
furthermore I think it'd be better to be considerate of the necessary
collaborators for each given class/file. No change required.

~Spaceghost



Gabriel Sobrinho

unread,
Feb 9, 2013, 11:19:42 AM2/9/13
to rubyonra...@googlegroups.com
You convinced me now.

I didn't maintained a wiki in a long term so I can't argue about that.

What you said about picking random files makes absolutely sense, in fact, that was my problem on the issue ;)

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.



Cheers,

Gabriel Sobrinho

Xavier Noria

unread,
Feb 9, 2013, 11:26:17 AM2/9/13
to rubyonrails-core
On Sat, Feb 9, 2013 at 5:12 PM, Johnneylee Rollins
<johnneyle...@gmail.com> wrote:

> But I've been having a good time lately of making each file require only
> what it needs to function on its own. Sometimes I have to require every
> file, but most of the time I get to be able to do what rosenfeld likes.

Rails components do that, except that you have to load the root file.
Because if you grep AR and the blank extension appears 100 times...
well, not only that means you are repeating too many require calls, it
means from those with the pass of time possibly 5 are no longer
necessary, and other 10 are missing. Solution: move loading blank to
the main entry point, and do the same with the files grep stats show
as the most used.

active_support/rails.rb was defined using source code statistics by the way.

Of course we are talking about using the components standalone, if you
have loaded a Rails application then you are/should be golden.
Reply all
Reply to author
Forward
0 new messages