[ruby-core:35042] Re: [Ruby 1.9-Bug#4352][Open] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

On Tue, Feb 1, 2011 at 10:46 PM, Yusuke ENDOH <[e-mail]> wrote:

> Hi,
>
> 2011/2/1 James M. Lawrence <[e-mail]>:
> > Knowing the line of an error inside eval is useful. Passing a binding
> > shouldn't discard that information.
>
>
> I understand you, but the behavior is intended.
>
> A binding also has its own information of filename and lineno.
> Some people ([ruby-core:28307] [ruby-dev:38767]) think that binding's
> lineno information is more important than eval's information, and that
> eval shouldn't discard the binding's informantion.
>
>  # foo.rb
>  eval("p [__FILE__, __LINE__]", binding)  #=> expected: ["foo.rb", 2]
>
> In addition, the behavior is compatible to 1.8.
>
>
> > Present behavior is even wrong:
> > there's no line 10 in this file.
> > ----
> > eval %{
> >
> >   # .. code ...
> >   raise
> >
> >
> > }, binding
> > ----
> > Without patch:
> > /Users/jlawrence/tmp/raiser.rb:10:in `<main>': unhandled exception
> >        from /Users/jlawrence/tmp/raiser.rb:7:in `eval'
> >        from /Users/jlawrence/tmp/raiser.rb:7:in `<main>'
> >
> > With patch:
> > /Users/jlawrence/tmp/raiser.rb:7:in `eval': (eval):4:in `<main>':
> ?(RuntimeError)
> >        from /Users/jlawrence/tmp/raiser.rb:7:in `eval'
> >        from /Users/jlawrence/tmp/raiser.rb:7:in `<main>'
>
>
> It is indeed confusing, but it can be understood as follows:
>
> 1) Here are actual linenos.  The binding has its own lineno at which the
> method is called:
>
> 1: eval %{
> 2:
> 3:   # .. code ...
> 4:   raise
> 5:
> 6:
> 7: }, binding
>
> 2) binding virtually overwrites linenos so that the eval'ing code starts
> with the binding's own lineno (that is, Line 7):
>
> 1: eval %{          # ( 7)
> 2:                  # ( 8)
> 3:   # .. code ...  # ( 9)
> 4:   raise          # (10)
> 5:                  # (11)
> 6:                  # (12)
> 7: }, binding       # (13)
>
> 3) an exception is raised at (virtual) Line 10.
>
>
> You can exploit this behavior to know the lineno more directly:
>
>  1: # foo.rb
>  2: b, s = binding, %{
>  3:
>  4:
>  5:   # .. code ...
>  6:   raise           # <- HERE!!
>  7:
>  8:
>  9: }, b
> 10: eval s, b #=> foo.rb:6:in `<main>': unhandled exception
>
> I guess eval should have received binding as the first argument ;-)
>

I wonder how many people who want to use eval with binding are going to
write in this fashion.  Frankly, I can't say I will.

More unsettling is that it's impossible from the traceback to unscramble
things because we don't know the line number that the binding started from.

(The "file" value which is alluded to in bug report
http://redmine.ruby-lang.org/issues/show/2782 is not relevant here. That
report refers to a __FILE__ inconsistency, so  __LINE__ was also changed to
make __FILE__ and __LINE__ consistent.) But if binding were in another file,
and then we might not know which file the eval is in! )

In my opinion the fundamental problem here is not having an expressive
enough notion of location. What I think you'd like to say is that   you are
in the eval block at location x, but that eval block has a binding location
y. And right now the discussion is about which one or combination of those
locations is the "right" one to report. For some things it seems the
"binding" location is preferable, and in other cases it seems the "eval"
location is preferable.

A similar conflation of locations can occur when you have a package
management file, say a "jar" and the program is running file member of that.
So again here one would want to say that the location refers to "file" xxx
but it is part of jar yyy.

I can't see how people aren't just going to be confused by the current
behavior no matter how consistent it is.  Please, can we do better in Ruby
2.0?


>
>  eval binding, %{
>    ...
>  }
>
> --
> Yusuke Endoh <[e-mail]>
>
>