From: Rocky Bernstein Date: 2011-02-03T23:22:28+09:00 Subject: [ruby-core:35073] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) --0023547c8bc7268575049b617ebd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 3, 2011 at 1:06 AM, Rocky Bernstein wrote: > > > On Wed, Feb 2, 2011 at 11:18 PM, Yusuke ENDOH wrote: > >> Hi, >> >> 2011/2/3 Rocky Bernstein : >> > 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#
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 >> >> > --0023547c8bc7268575049b617ebd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 3, 2011 at 1:06 AM, Rocky Be= rnstein <rocky= b@rubyforge.org> wrote:


On Wed, Feb 2, 2011 at= 11:18 PM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
Hi,

2011/2/3 Rocky Bernstein <rockyb@rubyforge.org>:
> 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 i= n 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 =A0where the file the user works on is not a Ruby file but= a
> template file that expands to a Ruby file. In that situation, disregar= ding
> the expanded Ruby file is convenient since there can only be one locat= ion
> attached in the Ruby implementation.
> However I don't see why a templating system couldn't also prov= ide 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? =A0I don't think that it is user-friendly.=

No I'm not= suggesting that. I am saying that given the choice of a programming langua= ge environment that allows many levels and kinds of introspection, one make= s it clear what's going such as inside say an eval, versus one that doe= sn't, which environment would one think of as more user or programmer f= riendly?

I think it possible to get this more accurate with insi= gnificant overhead. I do in the patched 1.9.2 YARV.=A0

=

FYI, erb offers ERB#src which provides a generated Ruby code. =A0However, 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 templati= ng 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. = =A0I have looked at template output in order to track down weird problems. = No, it's not my first line of attack; =A0but it's nice that I have = the opportunity to do it when it is needed.=A0



> But shouldn't we try to address the location problem head on in th= e Ruby
> implementation? I suspect it too late to try to change Ruby MRI 1.x, b= ut
> perhaps in Ruby 2.x some thought could b= e 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.=A0What's the use case for reportin= g a position accurately?=A0
I think giving accurate=A0position=A0information is generally done so = that when there is a problem a programmer has to spend less time figuring o= ut the places to look for a problem.

When there is= a problem in eval(), there are two interesting places:=A0

- 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.=A0

The redmine ticket cited makes a case for also being interes= ted in the FILE position where binding() was defined when binding is explic= itly 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 num= bers (eval string line number plus binding line number) but not the "f= ile" names.=A0
=A0

=A0


> 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. =A0Just prohibiting the file and line parameters is too strict. =A0Unless 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 add= ress 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" pr= operty and data. =A0Two types I currently use are currently "file"= ; and "string". The data for a file is the file name. The data fo= r 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 nam= e to signal that the "file" isn't really a file. =A0

But when showing the location inside the trepanning deb= uggers, 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:
=A0=A0 =A0eval "x=3D1; y=3D2"
I show
=A0= =A0(eval "x=3D1; y=3D2")=A0

and a backtr= ace shows

--> #0 EVAL Object#<main> in st= ring "x=3D1; y=3D2" at line 1 =A0 # 1 is the position inside the = string

The important point is that the debugger doesn't sa= y 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 a= s well.=A0

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

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

=A0
Another container type could be "member of jar&qu= ot;. =A0And in this case we might want the member name and a pointer to som= ething that gives location properties of the overall jar. =A0Other non-file= locations other than string might be a place inside an S-expression or a p= arse tree.

Right now the code is a hack and to fix it properly I w= ould need to change the Ruby implementation more. I may eventually do it th= ough
=A0
"-" (for stdin) and "-e" (for -e option) seem to have t= he same problem.



--0023547c8bc7268575049b617ebd--