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

On Thu, Feb 3, 2011 at 1:06 AM, Rocky Bernstein <[e-mail]>wrote:

>
>
> On Wed, Feb 2, 2011 at 11:18 PM, Yusuke ENDOH <[e-mail]> wrote:
>
>> Hi,
>>
>> 2011/2/3 Rocky Bernstein <[e-mail]>:
>> > See also
>> >
>> http://ola-bini.blogspot.com/2008/01/ruby-antipattern-using-eval-without.html
>> .
>> > It is called an "anti-pattern" there which I guess is used in a
>> derogatory
>> > fashion.
>>
>> I'd like to positively call it a "best practice" :-)
>>
>>
>> > A place where setting the file and line is used is in template systems
>> like
>> > merb or erb  where the file the user works on is not a Ruby file but a
>> > template file that expands to a Ruby file. In that situation,
>> disregarding
>> > the expanded Ruby file is convenient since there can only be one
>> location
>> > attached in the Ruby implementation.
>> > However I don't see why a templating system couldn't also provide an
>> > expanded Ruby file for debugging problems much as one can get the
>> > C-preprocessed output for a C program when one wants.
>>
>> I'm not sure that I could understand you.
>> Are you saying that erb users should debug their erb code by looking
>> the erb-generated Ruby code?  I don't think that it is user-friendly.
>>
>
> No I'm not suggesting that. I am saying that given the choice of a
> programming language environment that allows many levels and kinds of
> introspection, one makes it clear what's going such as inside say an eval,
> versus one that doesn't, which environment would one think of as more user
> or programmer friendly?
>
> I think it possible to get this more accurate with insignificant overhead.
> I do in the patched 1.9.2 YARV.
>
>
>> FYI, erb offers ERB#src which provides a generated Ruby code.  However,
>> I don't want to encourage users to read and debug the generated code.
>>
>
> As a programmer, I try to stay a way from making policy about what others
> should or should not do. I don't feel confident that I know what's right for
> others in all situations.
>
> The people who write and work on the macro and templating systems are the
> ones that tend to read and debug the generated Ruby code. I realize this is
> a small number of people, but I care about them too.  I have looked at
> template output in order to track down weird problems. No, it's not my first
> line of attack;  but it's nice that I have the opportunity to do it when it
> is needed.
>
>
>>
>> > But shouldn't we try to address the location problem head on in the Ruby
>> > implementation? I suspect it too late to try to change Ruby MRI 1.x, but
>> > perhaps in Ruby 2.x some thought could be given to how to address.?
>>
>> Yes, it is good to improve the spec in 2.0.
>> Before that, we must first check the use case.
>> For creating what kind of tools, what kind of information do you need?
>>
>
> Reporting position more precisely is what I am calling for. What's the use
> case for reporting a position accurately?
> I think giving accurate position information is generally done so that when
> there is a problem a programmer has to spend less time figuring out the
> places to look for a problem.
>
> When there is a problem in eval(), there are two interesting places:
>
> - the position inside the string that is eval'd and
> - and the location that the eval line is on which is given in a traceback
> -- if you know to look there in this special case.
>
> The redmine ticket cited makes a case for also being interested in the FILE
> position where binding() was defined when binding is explicitly given. This
> causes trouble because the current Ruby implementation can only store one
> file name string and one line number as a location. So the location inside
> the eval string is obscured here.
>
> I find it odd that currently Ruby adds the two line numbers (eval string
> line number plus binding line number) but not the "file" names.
>
>
>
>
>
>>
>> > If the fact that source_location is not trustable is a a concern, then
>> > perhaps setting the file and line parameters on eval can be disallowed
>> at
>> > some level greater than 0 and less than 4 which is where eval() is
>> > disallowed totally.?
>>
>> We should not ignore erb-like use case.  Just prohibiting the file and
>> line parameters is too strict.  Unless Ruby provides an alternative
>> feature, like #line of C-preprocessor.
>>
>>
>>
>> BTW, is it ok for you that source_location returns ["(eval)", 1]?
>> It does not allow to distinguish whether it is executed in Kernel#eval
>> or the source code file is named "(eval)".
>>
>
> In my patched YARV 1.9.2 I try to address this. See
> RubyVM::ThreadFrame#source_location and RubyVM::ThreadFrame#source_container
> of http://github.com/rocky/rb-threadframe
>
> The basic idea is that "file" is really a bad name. I use the word
> "container" which has a "type" property and data.  Two types I currently use
> are currently "file" and "string". The data for a file is the file name. The
> data for a string is the string value.
>

I got this slightly incorrect. I have a bad memory and make mistakes: the
data for a string is still the name (eval) because too many Ruby programs
currently rely on that funny name to signal that the "file" isn't really a
file.

But when showing the location inside the trepanning debuggers, rather than
say that a file name is "(eval)" I show that string and the leading and
trailing context of the string that is eval'd. For example, for the Ruby
statement:
    eval "x=1; y=2"
I show
  (eval "x=1; y=2")

and a backtrace shows

--> #0 EVAL Object#<main> in string "x=1; y=2" at line 1   # 1 is the
position inside the string

The important point is that the debugger doesn't say you are positioned
inside a file when you are positioned inside a string. It would be nice if
the runtime backtraces would not misrepresent things as well.

If the string is long, there are ellipses in the middle of the string.

Also another small correction. A better URL for source_container and
source_location at the bottom of the wiki page of a sample session:

https://github.com/rocky/rb-threadframe/wiki/Sample-Session


> Another container type could be "member of jar".  And in this case we might
> want the member name and a pointer to something that gives location
> properties of the overall jar.  Other non-file locations other than string
> might be a place inside an S-expression or a parse tree.
>
> Right now the code is a hack and to fix it properly I would need to change
> the Ruby implementation more. I may eventually do it though
>
>
>> "-" (for stdin) and "-e" (for -e option) seem to have the same problem.
>>
>
> Same solution.
>
>>
>> --
>>
>> Yusuke Endoh <[e-mail]>
>>
>>
>