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

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