From: Rocky Bernstein Date: 2011-02-03T15:06:41+09:00 Subject: [ruby-core:35068] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) --0023547c91935852ae049b5a916f Content-Type: text/plain; charset=ISO-8859-1 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. 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 > > --0023547c91935852ae049b5a916f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 2, 2011 at 11:18 PM, Yusuke = ENDOH <mame@tsg.ne.j= p> 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 s= aying that given the choice of a programming language environment that allo= ws many levels and kinds of introspection, one makes it clear what's go= ing such as inside say an eval, versus one that doesn't, which environm= ent would one think of as more user or programmer friendly?

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 fro= m 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 be given to how to addres= s.?

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 ca= lling for.=A0What's the use case for reporting 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)".
<= br>
In my patched YARV 1.9.2 I try to address this. See RubyVM::T= hreadFrame#source_location and RubyVM::ThreadFrame#source_container of http://github.com/rocky/rb-t= hreadframe

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. Another container type could be "membe= r of jar". =A0And in this case we might want the member name and a poi= nter to something that gives location properties of the overall jar. =A0Oth= er non-file locations other than string might be a place inside an S-expres= sion or a parse tree.

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

Same solution.=A0

--
Yusuke Endoh <mame@tsg.ne.jp>

--0023547c91935852ae049b5a916f--