[#35027] [Ruby 1.9-Bug#4352][Open] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) — "James M. Lawrence" <redmine@...>

Bug #4352: [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

16 messages 2011/02/01

[#35114] [Ruby 1.9-Bug#4373][Open] http.rb:677: [BUG] Segmentation fault — Christian Fazzini <redmine@...>

Bug #4373: http.rb:677: [BUG] Segmentation fault

59 messages 2011/02/06

[#35171] [Ruby 1.9-Bug#4386][Open] encoding: directive does not affect regex expressions — mathew murphy <redmine@...>

Bug #4386: encoding: directive does not affect regex expressions

9 messages 2011/02/09

[#35237] [Ruby 1.9-Bug#4400][Open] nested at_exit hooks run in strange order — Suraj Kurapati <redmine@...>

Bug #4400: nested at_exit hooks run in strange order

12 messages 2011/02/15

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

From: Yusuke ENDOH <mame@...>
Date: 2011-02-03 04:18:46 UTC
List: ruby-core #35065
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 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.

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.


> 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?


> 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)".
"-" (for stdin) and "-e" (for -e option) seem to have the same problem.

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

In This Thread