[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

magic / counter-magic? (detect loading file?

Giles Bowkett

12/16/2007 7:53:00 PM

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::Dependencies 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.bl...
Blog: http://gilesbowkett.bl...
Portfolio: http://www.gilesg...
Tumblelog: http://giles....
9 Answers

James Gray

12/16/2007 8:00:00 PM

0

On Dec 16, 2007, at 1:52 PM, Giles Bowkett wrote:

> I took a look around the Rails file-loading process and it looked
> pretty involved. I know the problem comes from
> ActiveSupport::Dependencies 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

12/16/2007 9:02:00 PM

0

On Dec 16, 1:52 pm, Giles Bowkett <gil...@gmail.com> wrote:
> 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::Dependencies 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.bl...
> Blog:http://gilesbowkett.bl...
> Portfolio:http://www.gilesg...
> Tumblelog:http://giles....

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

Regards,
Jordan

Robert Klemme

12/16/2007 9:43:00 PM

0

On 16.12.2007 20:52, Giles Bowkett wrote:
> 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::Dependencies 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

12/17/2007 12:32:00 AM

0

> > I took a look around the Rails file-loading process and it looked
> > pretty involved. I know the problem comes from
> > ActiveSupport::Dependencies 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.

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.bl...
Blog: http://gilesbowkett.bl...
Portfolio: http://www.gilesg...
Tumblelog: http://giles....

Giles Bowkett

12/17/2007 12:39:00 AM

0

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

>> caller(0)
=> ["(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.

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

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.bl...
Blog: http://gilesbowkett.bl...
Portfolio: http://www.gilesg...
Tumblelog: http://giles....

James Gray

12/17/2007 12:55:00 AM

0

On Dec 16, 2007, at 6:32 PM, Giles Bowkett wrote:

>>> I took a look around the Rails file-loading process and it looked
>>> pretty involved. I know the problem comes from
>>> ActiveSupport::Dependencies 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.
>
> 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

12/17/2007 1:37:00 AM

0

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.
--
Posted via http://www.ruby-....

Rob Sanheim

12/17/2007 1:38:00 AM

0

On Dec 16, 2007 2:52 PM, Giles Bowkett <gilesb@gmail.com> wrote:
> 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::Dependencies 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

12/17/2007 5:43:00 AM

0

> 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.bl...
Blog: http://gilesbowkett.bl...
Portfolio: http://www.gilesg...
Tumblelog: http://giles....