Line directives

ruby-talk
1

Does ruby support anything like #line directives in C or Perl? or
any other way to dynamically change what ruby thinks is the current
sourcefile and sourceline in its warning and error reporting?

regards,
andrew

2

Note:
I’m replying to my own post as I found the following response in the
ruby-talk archives, but no replies seem to have made it through to my
c.l.r. newsfeed.

In [ruby-talk:96620] (http://ruby-talk.org/blade/96620), Assaph writes:

What exactly do you need it for?

This would be useful when the source code has been extracted / assembled
from another source — in particular, literate programming. When the
extracted code is run, it is much nicer when warnings and errors point
to the relevant locations in the literate source file (which is where the
code is written and edited), rather than the extracted source file which
is executed.

regards,
andrew

3

“Andrew Johnson” ajohnson@cpan.org schrieb im Newsbeitrag
news:ikjcc.33539$Ig.1574@pd7tw2no…

Does ruby support anything like #line directives in C or Perl? or
any other way to dynamically change what ruby thinks is the current
sourcefile and sourceline in its warning and error reporting?

In C one often had to correct messed up compilers - dunno why you should
need that in Ruby though. Anyway, the eval family of functions has often
additional arguments that can be used to set file and line:

http://www.rubycentral.com/book/ref_m_kernel.html#Kernel.eval

Regards

robert
4

Andrew Johnson wrote:

Note:
I’m replying to my own post as I found the following response in the
ruby-talk archives, but no replies seem to have made it through to my
c.l.r. newsfeed.

In [ruby-talk:96620] (http://ruby-talk.org/blade/96620), Assaph writes:

What exactly do you need it for?

This would be useful when the source code has been extracted / assembled
from another source — in particular, literate programming. When the
extracted code is run, it is much nicer when warnings and errors point
to the relevant locations in the literate source file (which is where the
code is written and edited), rather than the extracted source file which
is executed.

regards,
andrew

If you execute your extracted code via ‘eval’ you can indicate a file
name and a starting line number that ‘eval’ will use to report errors:

----------------------------------------------------------- Kernel::eval
eval( aString [, aBinding [file [line]]]) → anObject

··· 
  Evaluates the Ruby expression(s) in aString. If aBinding is given,
  the evaluation is performed in its context. The binding may be a
  Binding object or a Proc object. If the optional file and line
  parameters are present, they will be used when reporting syntax
  errors. As of Ruby 1.8, local variables assigned within an eval are
  only available after the eval if they were defined at the outter
  scope before the eval executed. In this way eval has the same
  scoping rules as blocks.
     def getBinding(str)
       return binding
     end
     str = "hello"
     eval "str + ' Fred'"                      #=> "hello Fred"
     eval "str + ' Fred'", getBinding("bye")   #=> "bye Fred"

Gennady.

5

Robert Klemme wrote:

In C one often had to correct messed up compilers - dunno why you should
need that in Ruby though. Anyway, the eval family of functions has often
additional arguments that can be used to set file and line:

I aways thought the line directive was used by preprocessors, so that
compile errors in the C source code would reference lines in the
preprocessor input. Ratfor did this (for example).

···

–
– Jim Weirich jim@weirichhouse.org http://onestepback.org

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

6

Well, one problem with that is that the source is extracted and assembled
from multiple locations in the literate source file(s): I’m not sure that
having the final program consist of a set of (possibly nested) eval’d
strings is a workable solution.

I’m currently thinking that a simple filter (that recognizes #line
directives) on TestUnit output may be a sufficient work-around for my
present purposes (but not really a general solution).

regards,
andrew

···

On Thu, 8 Apr 2004 02:56:05 +0900, Gennady gfb@tonesoft.com wrote:

If you execute your extracted code via ‘eval’ you can indicate a file
name and a starting line number that ‘eval’ will use to report errors: