magic / counter-magic? (detect loading file?)

[Giles Bowkett]

Here's something that's puzzling me.

Somewhere inside Rails is something which loads your .irbrc under some
circumstances. It means that if you have a gem which adds a lot of
methods to Object and which is required by people in their .irbrcs,
sooner or later, your methods on Object are going to collide with
Rails' methods on *anything*. I have such a gem, Utility Belt, and
this happened to somebody who installed it. It's going to happen to a
lot of people, in fact, because the method in question was named
"edit," which practically every Rails app uses.

I took a look around the Rails file-loading process and it looked
pretty involved. I know the problem comes from
ActiveSupport:ependencies but that's about it. I'd like to find and
fix the bug in Rails but I just don't have time. What I want to do
instead is set up Utility Belt to recognize when it's being called
from Rails and then have it de-borkify the situation. All I really
need to accomplish that is code which can recognize where it's being
called or loaded from. I know such code, and idioms for using it,
exist, but I'm not sure what they are. Is it just a matter of grepping
against __FILE__? How does my gem determine who it's being loaded by
and send them away if they don't need to be loading it?

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[James Gray]

I took a look around the Rails file-loading process and it looked
pretty involved. I know the problem comes from
ActiveSupport:ependencies but that's about it. I'd like to find and
fix the bug in Rails but I just don't have time.

I realize this isn't what you asked, but I don't consider it a bug
that script/console picks up all of my IRb settings without any action
on my part. In fact, I would consider the opposite a bug.

James Edward Gray II

 

[MonkeeSage]

Here's something that's puzzling me.

Somewhere inside Rails is something which loads your .irbrc under some
circumstances. It means that if you have a gem which adds a lot of
methods to Object and which is required by people in their .irbrcs,
sooner or later, your methods on Object are going to collide with
Rails' methods on *anything*. I have such a gem, Utility Belt, and
this happened to somebody who installed it. It's going to happen to a
lot of people, in fact, because the method in question was named
"edit," which practically every Rails app uses.

I took a look around the Rails file-loading process and it looked
pretty involved. I know the problem comes from
ActiveSupport:ependencies but that's about it. I'd like to find and
fix the bug in Rails but I just don't have time. What I want to do
instead is set up Utility Belt to recognize when it's being called
from Rails and then have it de-borkify the situation. All I really
need to accomplish that is code which can recognize where it's being
called or loaded from. I know such code, and idioms for using it,
exist, but I'm not sure what they are. Is it just a matter of grepping
against __FILE__? How does my gem determine who it's being loaded by
and send them away if they don't need to be loading it?

--
Giles Bowkett

Podcast:http://hollywoodgrit.blogspot.com
Blog:http://gilesbowkett.blogspot.com
Portfolio:http://www.gilesgoatboy.org
Tumblelog:http://giles.tumblr.com

Could you check for some methods or constants that (only?) Rails
defines?

Regards,
Jordan

 

[Robert Klemme]

Here's something that's puzzling me.

Somewhere inside Rails is something which loads your .irbrc under some
circumstances.

That sounds strange. Why would a rails app need IRB?

It means that if you have a gem which adds a lot of
methods to Object and which is required by people in their .irbrcs,
sooner or later, your methods on Object are going to collide with
Rails' methods on *anything*. I have such a gem, Utility Belt, and
this happened to somebody who installed it. It's going to happen to a
lot of people, in fact, because the method in question was named
"edit," which practically every Rails app uses.

I took a look around the Rails file-loading process and it looked
pretty involved. I know the problem comes from
ActiveSupport:ependencies but that's about it. I'd like to find and
fix the bug in Rails but I just don't have time. What I want to do
instead is set up Utility Belt to recognize when it's being called
from Rails and then have it de-borkify the situation. All I really
need to accomplish that is code which can recognize where it's being
called or loaded from. I know such code, and idioms for using it,
exist, but I'm not sure what they are.

You can use caller to find out about the call stack:

irb(main):003:0> def f(n) caller(n) end
=> nil
irb(main):004:0> f 0
=> ["(irb):3:in `f'", "(irb):4:in `irb_binding'",
"/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]
irb(main):005:0> f 1
=> ["(irb):5:in `irb_binding'",
"/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]
irb(main):006:0> f 2
=> ["/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]

Is it just a matter of grepping
against __FILE__? How does my gem determine who it's being loaded by
and send them away if they don't need to be loading it?

Alternatively you could set up tracing with set_trace_func and determine
the calling chain that leads to this behavior by looking at the trace
output.

Kind regards

robert

 

[Giles Bowkett]

I took a look around the Rails file-loading process and it looked

I realize this isn't what you asked, but I don't consider it a bug
that script/console picks up all of my IRb settings without any action
on my part. In fact, I would consider the opposite a bug.

Duh. I'm talking about Rails, not script/console. When something does
what it's supposed to do, that's not a bug. When a Web app picks up
REPL-only settings, that's a bug.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[Giles Bowkett]

Here's something that's puzzling me.

That sounds strange. Why would a rails app need IRB?

It doesn't. That's the point!

[...I need code which can find out where it's being loaded from...]

You can use caller to find out about the call stack:

irb(main):003:0> def f(n) caller(n) end
=> nil
irb(main):004:0> f 0
=> ["(irb):3:in `f'", "(irb):4:in `irb_binding'",
"/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]
irb(main):005:0> f 1
=> ["(irb):5:in `irb_binding'",
"/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]
irb(main):006:0> f 2
=> ["/usr/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'", ":0"]

Check out this weirdness:
=> ["(irb):2:in `irb_binding'",
"/opt/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'",
"/opt/local/lib/ruby/gems/1.8/gems/aws-s3-0.4.0/lib/aws/s3/extensions.rb:188"]

I don't know how that got in there, either, but I bet it's similar to
what's going on with Rails. I've seen this happen on another person's
machine as well.

Alternatively you could set up tracing with set_trace_func and determine
the calling chain that leads to this behavior by looking at the trace
output.

Cool. You can hand that a Proc and get back custom stack-tracing
goodness? I could probably just give it a regex-y Proc which tells the
gem to scuttle everything the first time it encounters a Rails class
anywhere in the call stack.

Or at least, I **could**, except then people wouldn't be able to use
Utility Belt with Rails' script/console, which would kind of suck,
especially since one of those people would be me and Rails'
script/console is one of the main places I use Utility Belt.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[James Gray]

Duh. I'm talking about Rails, not script/console. When something does
what it's supposed to do, that's not a bug. When a Web app picks up
REPL-only settings, that's a bug.

Ah, I misunderstood. My apologies.

You are right, it's weird.

James Edward Gray II

 

[Marc Heiler]

Heh I once wondered why anything rails related needs my .irbrc (and then
crashed because of some issues with my .irbrc and the many files i
require upon a typical IRB startup)

Gave up to investigate it though.

 

[Rob Sanheim]

Here's something that's puzzling me.

Somewhere inside Rails is something which loads your .irbrc under some
circumstances. It means that if you have a gem which adds a lot of
methods to Object and which is required by people in their .irbrcs,
sooner or later, your methods on Object are going to collide with
Rails' methods on *anything*. I have such a gem, Utility Belt, and
this happened to somebody who installed it. It's going to happen to a
lot of people, in fact, because the method in question was named
"edit," which practically every Rails app uses.

I took a look around the Rails file-loading process and it looked
pretty involved. I know the problem comes from
ActiveSupport:ependencies but that's about it. I'd like to find and
fix the bug in Rails but I just don't have time. What I want to do
instead is set up Utility Belt to recognize when it's being called
from Rails and then have it de-borkify the situation. All I really
need to accomplish that is code which can recognize where it's being
called or loaded from. I know such code, and idioms for using it,
exist, but I'm not sure what they are. Is it just a matter of grepping
against __FILE__? How does my gem determine who it's being loaded by
and send them away if they don't need to be loading it?

I have utility_belt 1.0.5, rails 2.0.1, and an app with controllers
with edit actions. None of them have shown this bug. How are you
sure its really a rails bug, and not just some weird combination of
plugins/gems, utility_belt, _and_ rails that causes the error to show
on a few unlucky folks apps?

- Rob

 

[Giles Bowkett]

I have utility_belt 1.0.5, rails 2.0.1, and an app with controllers

with edit actions. None of them have shown this bug. How are you
sure its really a rails bug, and not just some weird combination of
plugins/gems, utility_belt, _and_ rails that causes the error to show
on a few unlucky folks apps?

Good question! Because I used to have some constants initialized in my
irbrc, and I would get weird "Constants already initialized" errors
in my server logs from when Rails repeatedly loaded my .irbrc. I could
tell because those constants literally weren't used anywhere else on
my machine. (They had long and extremely specific names.)

I've actually known about this bug for months, I just forgot about it
because it never had any significant consequences for me until now.
I'm not seeing the bug on my system either, but at the same time, I
haven't been checking my server logs thoroughly for traces of it. It
*is* something which only shows up for a few unlucky folks, but it
also *is* a bug in Rails.

What I really wish I knew of is a way to compare systems that have the
bug with systems that don't. Maybe if that tattle gem could be adapted
to serve as a general-purpose bug-reporting utility, so that any time
anyone reports a bug on a gem, they can
fire off tattle to deliver an exact system snapshot to the gem's
maintainer. That would be pretty cool.
--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com