Kernel#caller doesn't show directories
Suppose you have foo.rb: def __DIR__ caller[0] raise 'death' end puts __DIR__ If you call that from, say, a directory two levels below it, you get this: 818 $ macruby ../../foo.rb foo.rb:2:in `__DIR__': death (RuntimeError) from foo.rb:6:in `<main>' In 1.8.6 (and I sure hope in stock 1.9), you get filenames with the relative directory: 819 $ ruby ../../foo.rb ../../foo.rb:3:in `__DIR__': death (RuntimeError) from ../../foo.rb:6 I think that's important because there are tools (IDEs, my emacs hacks) that use the backtrace from a test to jump to the failing code. You can't do that unless you have the full pathname. I will file a ticket if this is a real bug. ----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
Oh, forgot to mention: Ramaze also uses (or used to) use the caller() result to find its root and would probably break too. ----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
I see that this works in 0.7. Sorry for the waste of bandwidth. On May 3, 2010, at 11:27 AM, Brian Marick wrote:
Suppose you have foo.rb:
def __DIR__ caller[0] raise 'death' end
puts __DIR__
If you call that from, say, a directory two levels below it, you get this:
818 $ macruby ../../foo.rb foo.rb:2:in `__DIR__': death (RuntimeError) from foo.rb:6:in `<main>'
In 1.8.6 (and I sure hope in stock 1.9), you get filenames with the relative directory:
819 $ ruby ../../foo.rb ../../foo.rb:3:in `__DIR__': death (RuntimeError) from ../../foo.rb:6
I think that's important because there are tools (IDEs, my emacs hacks) that use the backtrace from a test to jump to the failing code. You can't do that unless you have the full pathname.
I will file a ticket if this is a real bug.
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
Hi Brian, This looks like a bug. I don't know why it's fixed in 0.7 for you, because we haven't changed a lot of things there. In any case, a trac ticket might be a good idea if you still reproduce the problem. Note that backtraces in MacRuby are generated by walking through the stack and sometimes some entries are missing. File/line numbering is retrieved from DWARF metadata but sometimes it's incorrectly compiled. So, bug reports are welcome :-) Laurent On May 3, 2010, at 1:12 PM, Brian Marick wrote:
I see that this works in 0.7. Sorry for the waste of bandwidth.
On May 3, 2010, at 11:27 AM, Brian Marick wrote:
Suppose you have foo.rb:
def __DIR__ caller[0] raise 'death' end
puts __DIR__
If you call that from, say, a directory two levels below it, you get this:
818 $ macruby ../../foo.rb foo.rb:2:in `__DIR__': death (RuntimeError) from foo.rb:6:in `<main>'
In 1.8.6 (and I sure hope in stock 1.9), you get filenames with the relative directory:
819 $ ruby ../../foo.rb ../../foo.rb:3:in `__DIR__': death (RuntimeError) from ../../foo.rb:6
I think that's important because there are tools (IDEs, my emacs hacks) that use the backtrace from a test to jump to the failing code. You can't do that unless you have the full pathname.
I will file a ticket if this is a real bug.
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I couldn't reproduce it. Vanilla 1.8.6 is still slightly better in that it prints from ../../foo.rb:6 whereas a recent 0.7 prints a full path: from /Users/marick/src/clients/SES/Tests/preferences/../../foo.rb:6:in `<main>' On May 3, 2010, at 4:46 PM, Laurent Sansonetti wrote:
Hi Brian,
This looks like a bug. I don't know why it's fixed in 0.7 for you, because we haven't changed a lot of things there.
In any case, a trac ticket might be a good idea if you still reproduce the problem. Note that backtraces in MacRuby are generated by walking through the stack and sometimes some entries are missing. File/line numbering is retrieved from DWARF metadata but sometimes it's incorrectly compiled. So, bug reports are welcome :-)
Laurent
On May 3, 2010, at 1:12 PM, Brian Marick wrote:
I see that this works in 0.7. Sorry for the waste of bandwidth.
On May 3, 2010, at 11:27 AM, Brian Marick wrote:
Suppose you have foo.rb:
def __DIR__ caller[0] raise 'death' end
puts __DIR__
If you call that from, say, a directory two levels below it, you get this:
818 $ macruby ../../foo.rb foo.rb:2:in `__DIR__': death (RuntimeError) from foo.rb:6:in `<main>'
In 1.8.6 (and I sure hope in stock 1.9), you get filenames with the relative directory:
819 $ ruby ../../foo.rb ../../foo.rb:3:in `__DIR__': death (RuntimeError) from ../../foo.rb:6
I think that's important because there are tools (IDEs, my emacs hacks) that use the backtrace from a test to jump to the failing code. You can't do that unless you have the full pathname.
I will file a ticket if this is a real bug.
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
----- Brian Marick, independent consultant Mostly on agile methods with a testing slant Author of /Programming Cocoa with Ruby/ www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
participants (2)
-
Brian Marick
-
Laurent Sansonetti