thr3ads.net - Rails core - Weird (AS::Dependencies?) bug [Feb 2013]

If this information is useful, please help other people find it:
Share via:

Rodrigo Rosenfeld Rosas

2013-Feb-08 13:58 UTC

Weird (AS::Dependencies?) bug

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.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 14:06 UTC

head link

Re: Weird (AS::Dependencies?) bug

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

On 08/02/2013, at 14:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> 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.
> 
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
-- 
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.
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

2013-Feb-08 14:18 UTC

head link

Re: Weird (AS::Dependencies?) bug

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?

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 15:03 UTC

head link

Re: Weird (AS::Dependencies?) bug

On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
> 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?
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.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Peter Vandenabeele

2013-Feb-08 16:16 UTC

head link

Re: Weird (AS::Dependencies?) bug

On Fri, Feb 8, 2013 at 4:03 PM, Xavier Noria <fxn@hashref.com> wrote:
> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
> <rr.rosas@gmail.com> wrote:
>
> > 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?
>
> 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 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 <http://localhost:3000/#> | Framework
Trace<http://localhost:3000/#>
 | Full Trace <http://localhost:3000/#>

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


> 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.
>
-- 
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.
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

2013-Feb-08 16:45 UTC

head link

Re: Weird (AS::Dependencies?) bug

Em 08-02-2013 13:03, Xavier Noria escreveu:> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
> <rr.rosas@gmail.com>  wrote:
>
>> 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?
> 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.
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?

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 17:00 UTC

head link

Re: Weird (AS::Dependencies?) bug

Some very common files are loaded at the entry point of every component, to
avoid repeating their require again and again:

   
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb

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

On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> Em 08-02-2013 13:03, Xavier Noria escreveu:
>> 
>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>> <rr.rosas@gmail.com> wrote:
>> 
>>> 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?
>> 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.
> 
> 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?
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
-- 
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.
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

2013-Feb-08 17:12 UTC

head link

Re: Weird (AS::Dependencies?) bug

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:
>
>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
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''?)
>
> 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
>
> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@gmail.com>> wrote:
>
>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>>> <rr.rosas@gmail.com>  wrote:
>>>
>>>> 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?
>>> 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.
>>
>> 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?
>> -- 
>> 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 
>> <mailto:rubyonrails-core+unsubscribe@googlegroups.com>.
>> To post to this group, send email to 
>> rubyonrails-core@googlegroups.com 
>> <mailto:rubyonrails-core@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.
>>
>>
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
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.
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

2013-Feb-08 17:20 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Em 08-02-2013 15:12, Rodrigo Rosenfeld Rosas escreveu:> 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:
>>
>>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>
> 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''?)
>
>>
>> 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
>>
>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com
>> <mailto:rr.rosas@gmail.com>> wrote:
>>
>>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>>>> <rr.rosas@gmail.com>  wrote:
>>>>
>>>>> 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?
>>>> 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.
>>>
>>> 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?
>>> -- 
>>> 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 
>>> <mailto:rubyonrails-core+unsubscribe@googlegroups.com>.
>>> To post to this group, send email to 
>>> rubyonrails-core@googlegroups.com 
>>> <mailto:rubyonrails-core@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.
>>>
>>>
>> -- 
>> 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.
>> Visit this group at 
>> http://groups.google.com/group/rubyonrails-core?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 17:26 UTC

head link

Re: Weird (AS::Dependencies?) bug

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

On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> 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:
>> 
>>    
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
> 
> 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''?)
> 
>> 
>> 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
>> 
>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
>> 
>>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>> 
>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>>>> <rr.rosas@gmail.com> wrote:
>>>> 
>>>>> 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?
>>>> 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.
>>> 
>>> 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?
>>> -- 
>>> 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.
>>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>> -- 
>> 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.
>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
-- 
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.
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

2013-Feb-08 17:36 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Em 08-02-2013 15:26, Xavier Noria escreveu:> 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
>
> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@gmail.com>> wrote:
>
>> 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:
>>>
>>>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>
>> 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''?)
>>
>>>
>>> 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
>>>
>>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
>>> <mailto:rr.rosas@gmail.com>> wrote:
>>>
>>>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>>>>> <rr.rosas@gmail.com>  wrote:
>>>>>
>>>>>> 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?
>>>>> 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.
>>>>
>>>> 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?
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 17:42 UTC

head link

Re: Weird (AS::Dependencies?) bug

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

On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> 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.
> 
> Em 08-02-2013 15:26, Xavier Noria escreveu:
>> 
>> 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
>> 
>> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
>> 
>>> 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:
>>>> 
>>>>    
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>> 
>>> 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''?)
>>> 
>>>> 
>>>> 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
>>>> 
>>>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com> wrote:
>>>> 
>>>>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>>>> 
>>>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld Rosas
>>>>>> <rr.rosas@gmail.com> wrote:
>>>>>> 
>>>>>>> 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?
>>>>>> 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.
>>>>> 
>>>>> 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?
> 
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
-- 
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.
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

2013-Feb-08 17:46 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Em 08-02-2013 15:42, Xavier Noria escreveu:> 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
>
> On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@gmail.com>> wrote:
>
>> 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.
>>
>> Em 08-02-2013 15:26, Xavier Noria escreveu:
>>> 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
>>>
>>> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
>>> <mailto:rr.rosas@gmail.com>> wrote:
>>>
>>>> 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:
>>>>>
>>>>>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>>>
>>>> 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''?)
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas 
>>>>> <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>
>>>>>> Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>>>>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld
Rosas
>>>>>>> <rr.rosas@gmail.com>  wrote:
>>>>>>>
>>>>>>>> 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?
>>>>>>> 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.
>>>>>>
>>>>>> 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?
>>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 17:51 UTC

head link

Re: Weird (AS::Dependencies?) bug

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 scoperequire
''action_view/helpers''


Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>wrote:
>  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.
>
> Em 08-02-2013 15:42, Xavier Noria escreveu:
>
> 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
>
> On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
> wrote:
>
>   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.
>
> Em 08-02-2013 15:26, Xavier Noria escreveu:
>
> 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
>
> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
> wrote:
>
>   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:
>
>
>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>
>
> 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''?)
>
>
>  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
>
> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
> wrote:
>
>   Em 08-02-2013 13:03, Xavier Noria escreveu:
>
> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld
Rosas<rr.rosas@gmail.com> <rr.rosas@gmail.com> wrote:
>
>
>  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?
>
>  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.
>
>
> 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?
>
>
>
>  --
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 17:53 UTC

head link

Re: Weird (AS::Dependencies?) bug

See also https://github.com/rails/rails/pull/6964#issuecomment-6765540

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 3:51 PM, Rafael Mendonça França <
rafaelmfranca@gmail.com> wrote:
> 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 scoperequire
''action_view/helpers''
>
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas <
> rr.rosas@gmail.com> wrote:
>
>>  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.
>>
>> Em 08-02-2013 15:42, Xavier Noria escreveu:
>>
>> 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
>>
>> On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   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.
>>
>> Em 08-02-2013 15:26, Xavier Noria escreveu:
>>
>> 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
>>
>> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   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:
>>
>>
>>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>
>>
>> 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''?)
>>
>>
>>  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
>>
>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   Em 08-02-2013 13:03, Xavier Noria escreveu:
>>
>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld
Rosas<rr.rosas@gmail.com> <rr.rosas@gmail.com> wrote:
>>
>>
>>  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?
>>
>>  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.
>>
>>
>> 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?
>>
>>
>>
>>  --
>> 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.
>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
-- 
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.
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

2013-Feb-08 17:53 UTC

head link

Re: Weird (AS::Dependencies?) bug

Is this documented somewhere? Since it doesn''t follow any best
practices
I think this particular Rails behavior should be documented, right?

Em 08-02-2013 15:51, Rafael Mendonça França escreveu:> 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''|
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>
>     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.
>
>     Em 08-02-2013 15:42, Xavier Noria escreveu:
>>     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
>>
>>     On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas
>>     <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>>
>>>     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.
>>>
>>>     Em 08-02-2013 15:26, Xavier Noria escreveu:
>>>>     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
>>>>
>>>>     On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
>>>>     <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>
>>>>>     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:
>>>>>>
>>>>>>    
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>>>>
>>>>>     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''?)
>>>>>
>>>>>>
>>>>>>     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
>>>>>>
>>>>>>     On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
>>>>>>     <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>>
>>>>>>>     Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>>>>>>     On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo
Rosenfeld Rosas
>>>>>>>>     <rr.rosas@gmail.com> 
<mailto:rr.rosas@gmail.com>  wrote:
>>>>>>>>
>>>>>>>>>     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?
>>>>>>>>     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.
>>>>>>>
>>>>>>>     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?
>>>
>
-- 
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.
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

2013-Feb-08 17:59 UTC

head link

Re: Weird (AS::Dependencies?) bug

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''


Em 08-02-2013 15:53, Rodrigo Rosenfeld Rosas escreveu:> Is this documented somewhere? Since it doesn''t follow any best 
> practices I think this particular Rails behavior should be documented, 
> right?
>
> Em 08-02-2013 15:51, Rafael Mendonça França escreveu:
>> 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''|
>>
>> Rafael Mendonça França
>> http://twitter.com/rafaelfranca
>> https://github.com/rafaelfranca
>>
>>
>> On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas 
>> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>>
>>     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.
>>
>>     Em 08-02-2013 15:42, Xavier Noria escreveu:
>>>     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
>>>
>>>     On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas
>>>     <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>>
wrote:
>>>
>>>>     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.
>>>>
>>>>     Em 08-02-2013 15:26, Xavier Noria escreveu:
>>>>>     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
>>>>>
>>>>>     On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
>>>>>     <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>
>>>>>>     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:
>>>>>>>
>>>>>>>    
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>>>>>
>>>>>>     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''?)
>>>>>>
>>>>>>>
>>>>>>>     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
>>>>>>>
>>>>>>>     On 08/02/2013, at 17:45, Rodrigo Rosenfeld
Rosas
>>>>>>>     <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>>>
>>>>>>>>     Em 08-02-2013 13:03, Xavier Noria escreveu:
>>>>>>>>>     On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo
Rosenfeld Rosas
>>>>>>>>>     <rr.rosas@gmail.com> 
<mailto:rr.rosas@gmail.com>  wrote:
>>>>>>>>>
>>>>>>>>>>     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?
>>>>>>>>>     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.
>>>>>>>>
>>>>>>>>     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?
>>>>
>>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 18:04 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 3:53 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>wrote:
>  Is this documented somewhere? Since it doesn''t follow any best
practices
> I think this particular Rails behavior should be documented, right?
>
> Em 08-02-2013 15:51, Rafael Mendonça França escreveu:
>
> 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 scoperequire
''action_view/helpers''
>
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas <
> rr.rosas@gmail.com> wrote:
>
>>  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.
>>
>> Em 08-02-2013 15:42, Xavier Noria escreveu:
>>
>> 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
>>
>> On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   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.
>>
>> Em 08-02-2013 15:26, Xavier Noria escreveu:
>>
>> 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
>>
>> On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   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:
>>
>>
>>
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>
>>
>> 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''?)
>>
>>
>>  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
>>
>> On 08/02/2013, at 17:45, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>
>> wrote:
>>
>>   Em 08-02-2013 13:03, Xavier Noria escreveu:
>>
>> On Fri, Feb 8, 2013 at 3:18 PM, Rodrigo Rosenfeld
Rosas<rr.rosas@gmail.com> <rr.rosas@gmail.com> wrote:
>>
>>
>>  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?
>>
>>  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.
>>
>>
>> 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?
>>
>>
>>
>>
>  --
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 18:06 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

-- 
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.
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

2013-Feb-08 18:06 UTC

head link

Re: Weird (AS::Dependencies?) bug

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

Em 08-02-2013 16:04, Rafael Mendonça França escreveu:> 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.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 3:53 PM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>
>     Is this documented somewhere? Since it doesn''t follow any best
>     practices I think this particular Rails behavior should be
>     documented, right?
>
>     Em 08-02-2013 15:51, Rafael Mendonça França escreveu:
>>     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''|
>>
>>     Rafael Mendonça França
>>     http://twitter.com/rafaelfranca
>>     https://github.com/rafaelfranca
>>
>>
>>     On Fri, Feb 8, 2013 at 3:46 PM, Rodrigo Rosenfeld Rosas
>>     <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>>
>>         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.
>>
>>         Em 08-02-2013 15:42, Xavier Noria escreveu:
>>>         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
>>>
>>>         On 08/02/2013, at 18:36, Rodrigo Rosenfeld Rosas
>>>         <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>
>>>>         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.
>>>>
>>>>         Em 08-02-2013 15:26, Xavier Noria escreveu:
>>>>>         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
>>>>>
>>>>>         On 08/02/2013, at 18:12, Rodrigo Rosenfeld Rosas
>>>>>         <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>
>>>>>>         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:
>>>>>>>
>>>>>>>        
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/rails.rb
>>>>>>
>>>>>>         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''?)
>>>>>>
>>>>>>>
>>>>>>>         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
>>>>>>>
>>>>>>>         On 08/02/2013, at 17:45, Rodrigo Rosenfeld
Rosas
>>>>>>>         <rr.rosas@gmail.com
<mailto:rr.rosas@gmail.com>> wrote:
>>>>>>>
>>>>>>>>         Em 08-02-2013 13:03, Xavier Noria
escreveu:
>>>>>>>>>         On Fri, Feb 8, 2013 at 3:18 PM,
Rodrigo Rosenfeld Rosas
>>>>>>>>>         <rr.rosas@gmail.com> 
<mailto:rr.rosas@gmail.com>  wrote:
>>>>>>>>>
>>>>>>>>>>         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?
>>>>>>>>>         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.
>>>>>>>>
>>>>>>>>         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?
>>>>
>>
>
-- 
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.
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

2013-Feb-08 18:07 UTC

head link

Re: Weird (AS::Dependencies?) bug

Em 08-02-2013 16:06, Xavier Noria escreveu:> 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.
>
Sorry.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 18:09 UTC

head link

Re: Weird (AS::Dependencies?) bug

On Fri, Feb 8, 2013 at 7:06 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@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.

-- 
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.
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

2013-Feb-08 18:11 UTC

head link

Re: Weird (AS::Dependencies?) bug

Em 08-02-2013 16:09, Xavier Noria escreveu:> On Fri, Feb 8, 2013 at 7:06 PM, Rodrigo Rosenfeld Rosas
> <rr.rosas@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.
>
The guide wouldn''t be about ActiveRecord, but I got the message.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 18:18 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.
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

2013-Feb-08 18:22 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 18:24 UTC

head link

Re: Weird (AS::Dependencies?) bug

On Fri, Feb 8, 2013 at 7:22 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-08 18:24 UTC

head link

Re: Weird (AS::Dependencies?) bug

Accepted, thanks for the email.

On Fri, Feb 8, 2013 at 7:22 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
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.
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

2013-Feb-08 18:30 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.rosas@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.
>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 18:36 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@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<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> To post to this group, send email to
rubyonrails-core@googlegroups.**com<rubyonrails-core@googlegroups.com>
> .
> Visit this group at http://groups.google.com/**
>
group/rubyonrails-core?hl=en<http://groups.google.com/group/rubyonrails-core?hl=en>
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
>
>
-- 
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.
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

2013-Feb-08 18:58 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@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
>     <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>.
>     To post to this group, send email to
>     rubyonrails-core@googlegroups.com
>     <mailto:rubyonrails-core@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.
>
>
>
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 19:07 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 4:58 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>wrote:
>  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.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas <
> rr.rosas@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.
>> Visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
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.
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

2013-Feb-08 19:09 UTC

head link

Re: Weird (AS::Dependencies?) bug

It is convention over configuration, not convention instead of 
configuration.

How are we supposed to learn how to configure it?

Em 08-02-2013 17:07, Rafael Mendonça França escreveu:> 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.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 4:58 PM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>
>     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.
>>
>>     Rafael Mendonça França
>>     http://twitter.com/rafaelfranca
>>     https://github.com/rafaelfranca
>>
>>
>>     On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas
>>     <rr.rosas@gmail.com <mailto:rr.rosas@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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rafael Mendonça França

2013-Feb-08 19:18 UTC

head link

Re: Weird (AS::Dependencies?) bug

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. ;)

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Fri, Feb 8, 2013 at 5:09 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com>wrote:
>  It is convention over configuration, not convention instead of
> configuration.
>
> How are we supposed to learn how to configure it?
>
> Em 08-02-2013 17:07, Rafael Mendonça França escreveu:
>
> 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.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Fri, Feb 8, 2013 at 4:58 PM, Rodrigo Rosenfeld Rosas <
> rr.rosas@gmail.com> wrote:
>
>>  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.
>>
>> Rafael Mendonça França
>> http://twitter.com/rafaelfranca
>> https://github.com/rafaelfranca
>>
>>
>> On Fri, Feb 8, 2013 at 4:22 PM, Rodrigo Rosenfeld Rosas <
>> rr.rosas@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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

José Valim

2013-Feb-08 19:35 UTC

head link

Re: Weird (AS::Dependencies?) bug

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:

https://github.com/jimweirich/rake/blob/master/lib/rake.rb

For example, this file assumes Task is loaded:

https://github.com/jimweirich/rake/blob/master/lib/rake/multi_task.rb

2. Rack sets up autoloads:

https://github.com/rack/rack/blob/master/lib/rack.rb

3. Webrick does the same as Rake:

https://github.com/ruby/ruby/blob/trunk/lib/webrick.rb

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

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Ryan Bigg

2013-Feb-08 22:57 UTC

head link

Re: Weird (AS::Dependencies?) bug

I agree with José. Is there a tl;dr for this thread?

 

On 09/02/2013, at 6:35, José Valim <jose.valim@gmail.com> wrote:
> 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:
> 
> https://github.com/jimweirich/rake/blob/master/lib/rake.rb
> 
> For example, this file assumes Task is loaded:
> 
> https://github.com/jimweirich/rake/blob/master/lib/rake/multi_task.rb
> 
> 2. Rack sets up autoloads:
> 
> https://github.com/rack/rack/blob/master/lib/rack.rb
> 
> 3. Webrick does the same as Rake:
> 
> https://github.com/ruby/ruby/blob/trunk/lib/webrick.rb
> 
> So saying Rails is "stupid" regarding this requirement shows
rather a lack of understanding how most Ruby libraries work.
> -- 
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Gabriel Sobrinho

2013-Feb-09 15:51 UTC

head link

Re: Weird (AS::Dependencies?) bug

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 :)

On Friday, February 8, 2013 8:57:20 PM UTC-2, Ryan Bigg
wrote:>
> I agree with José. Is there a tl;dr for this thread?
>
>  
>
> On 09/02/2013, at 6:35, José Valim <jose....@gmail.com
<javascript:>>
> wrote:
>
> 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:
>
> https://github.com/jimweirich/rake/blob/master/lib/rake.rb
>
> For example, this file assumes Task is loaded:
>
> https://github.com/jimweirich/rake/blob/master/lib/rake/multi_task.rb
>
> 2. Rack sets up autoloads:
>
> https://github.com/rack/rack/blob/master/lib/rack.rb
>
> 3. Webrick does the same as Rake:
>
> https://github.com/ruby/ruby/blob/trunk/lib/webrick.rb
>
> So saying Rails is "stupid" regarding this requirement shows
rather a lack
> of understanding how most Ruby libraries work.
>
> -- 
> 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 <javascript:>.
> To post to this group, send email to
rubyonra...@googlegroups.com<javascript:>
> .
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Xavier Noria

2013-Feb-09 16:08 UTC

head link

Re: Weird (AS::Dependencies?) bug

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.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Johnneylee Rollins

2013-Feb-09 16:12 UTC

head link

Re: Weird (AS::Dependencies?) bug

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



On Sat, Feb 9, 2013 at 11:08 AM, Xavier Noria <fxn@hashref.com> wrote:
> 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.
>
> --
> 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.
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Gabriel Sobrinho

2013-Feb-09 16:19 UTC

head link

Re: Weird (AS::Dependencies?) bug

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 ;)

On Feb 9, 2013, at 2:08 PM, Xavier Noria <fxn@hashref.com> wrote:
> 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.
> 
> -- 
> 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.
> 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
gabrielsobrinho.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-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@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.

Xavier Noria

2013-Feb-09 16:26 UTC

head link

Re: Weird (AS::Dependencies?) bug

On Sat, Feb 9, 2013 at 5:12 PM, Johnneylee Rollins
<johnneylee.rollins@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.

-- 
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.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Rails core - Feb 2013 - Weird (AS::Dependencies?) bug

Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug

Re: Weird (AS::Dependencies?) bug