The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
A better Kernel#caller

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Eigen Class

Posts: 358
Nickname: eigenclass
Registered: Oct, 2005

Eigenclass is a hardcore Ruby blog.
A better Kernel#caller Posted: Jun 6, 2006 8:58 AM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Eigen Class.
Original Post: A better Kernel#caller
Feed Title: Eigenclass
Feed URL: http://feeds.feedburner.com/eigenclass
Feed Description: Ruby stuff --- trying to stay away from triviality.
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Eigen Class
Latest Posts From Eigenclass

Advertisement

Proposals for extending Kernel#caller come up regularly on ruby-core and ruby-talk. Indeed, the information it returns in textual form isn't as utile and easy to use as it could be, forcing one to parse it:

def foo; bar end
def bar; puts caller; end
foo

 kernel_caller.rb:1:in `foo'
 kernel_caller.rb:3

I decided to implement a Kernel#caller substitute for rcov which would provide more information in a more convenient format:

require 'my_caller'
require 'pp'

def foo; bar end
def bar; pp $rec.callstack(2).map{|cs| cs.to_a} end

$rec = CallStackRecorder.new
$rec.install_hook
foo

would print

 [[Object, :bar, "example.rb", 5], [Object, :foo, "example.rb", 4]]

(it actually returns an array of CallSite structs).

Actually, the main reason to implement it was performance-related: Kernel#caller doesn't allow you to specify how deep the backtrace information should be (one how many levels to skip). When creating cross-referenced code coverage repots for Rails applications, Kernel#caller proved to be way too slow since the stack was very deep (over 60 levels...). I didn't need anything past the second stack frame, so Kernel#caller was wasting everybody's time generating useless data. Therefore, the key feature I needed was the ability to get only the top N frames.

I implemented that in C, using Ruby's RUBY_EVENT hooks. I traced all the (c-)call/return events to maintain a call stack for each Ruby thread. That's fairly slow, but I anticipated it would be faster overall than Kernel#caller if the call stack was deep enough, and I was right (rcov's tracing phase was nearly 2X faster than before).

It took about ~500 lines of C, which corresponded broadly to 80 lines of Ruby:

class CallStack
  def initialize(stack = []); @stack = stack end
  def <<(x); @stack << x end
  def pop; @stack.pop end
  def last(n = 1); @stack[-[n,@stack.size].min..-1] end # bomb for n <= 0?
  def tos; @stack.last end
  def to_a; @stack end
end


Read more...

Read: A better Kernel#caller

Topic: PLANETARGON.org Previous Topic   Next Topic Topic: Just Go With The Flow

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use