From: Jean-Hugues ROBERT <jean_hugues_robert@...>
Date: 2004-11-18T18:59:22+09:00
Subject: Re: assert

At 01:18 18/11/2004 +0900, you wrote:
>Michael Neumann wrote:
>
>>How about this:
>>  def breakpoint
>>    file, line_no = caller.first.split(':', 2)
>>    reason = File.readlines(file)[line_no.to_i - 1].
>>      strip.sub(/^breakpoint\s+/, '')
>>    p reason
>>    # setup irb session etc.
>>  end
>>  a = 4
>>  breakpoint unless a == 5
>>This extracts the "unless a == 5" out of the source file. Of course, that does not work for evaled-code (unless the source-buffer is stored somewhere and we could access it).
>
>I have extracted run-time information from the source code before (proc_source.rb -- it finds the source code of a lambda / lambdafied block) and while it is a nice technique I think the overhead would be too high in this case. (Plus it will not work with -e which is a minor annoyance.)

What overhead are you referring too ?

When an assert bombs, this is an exceptional situation
(supposedly). In such a case I don't mind if the handling
of the exception takes a little while, because I would
rather have more info than less.

BTW: I think that "assert" is a perfect name. That assert()
should re throw an exception or start an irb session should
be a configurable behaviour at run time (i.e. when I am
debugging, it should start an irb session, when in production
it should throw an exception).

There is something I would definitely love to have: The
stack of bindings. So far I can get the binding of the caller
(thanks to some clever code, thanks Florian) and the
"text formatted" caller(). That is not enough. I want to
have a look at the local variables all the way up to the
top of the call stack.

I have begin to develop a work-around but it does not work
yet. It basically uses assert() to store bindings (including
the ones when the assert does not bomb) in a cycling array.
When an assert bombs, it uses the text info from caller() to
try to cross-correlate the recently stored bindings with the
caller() provided call stack. It should work decently in a
mostly single threaded contexts when one calls assert()
frequently enough. This is an heuristic, not 100% reliable.

FWIW.

Yours,

    JeanHuguesRobert

-------------------------------------------------------------------------
Web:  http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17