This is how I debug SystemStackError when there is no stack trace.
My first attempt was:
begin
a_method_that_causes_infinite_recursion_in_a_not_obvious_way
rescue SystemStackError
puts caller
end
This is how I debug SystemStackError when there is no stack trace.
My first attempt was:
begin
a_method_that_causes_infinite_recursion_in_a_not_obvious_way
rescue SystemStackError
puts caller
end
$enable_tracing = false | |
#$trace_out = File.open(Rails.root + 'trace.txt', 'w') | |
set_trace_func proc { |event, file, line, id, binding, classname| | |
if $enable_tracing && event == 'call' | |
#$trace_out.puts "#{file}:#{line} #{classname}##{id}" | |
raise "crash me" if caller_locations.length > 500 | |
end | |
} |
NOTE: This post now lives (and kept up to date) on my blog: http://hakunin.com/rails3-load-paths
Do nothing. All files in this dir are eager loaded in production and lazy loaded in development by default.
Many modern Rails application use third-party assets like JavaScript and CSS libraries or frameworks. In most cases these assets are minified and compressed by tools outside of the Rails asset pipeline. For example popular gem React on Rails uses WebPack to build JavaScript bundles. When we include these files to assets pipeline it goes to minify again. We can safely avoid double minification and reduce assets compilation time. Meanwhile it is still good to add a digest and gzip compression.
Savings are strongly depend on how many minified assets are used in an application, some numbers for a random application:
# standard setup