Florian Gross
11/18/2004 3:36:00 PM
Jean-Hugues ROBERT wrote:
>>> 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.
Oh, I was not referring to performance overhead -- I was talking about
maintenance overhead. It adds a lot of fragile code (at least if you
want to handle code on STDIN, inside an eval, inside irb and so on
properly). I should have been more clear.
> 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).
I agree with this except that assert() has a name clash with test/unit.
> 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.
You can have this with a custom C extension or a global trace func. The
problem with the former is that it would likely be quite slow. The
problem with the latter is that it would require a C compiler and that
it might have side effects. (I'm pretty sure that the binding of the
immediate caller can safely be fetched without causing trouble because
eval() does this. I'm not sure about going further up the binding chain.)
> 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.
Hm, I wonder if it is worth the hassle. Would it not be simpler to just
use a String instead?
I think my current proposed solution to all this looks like this:
- Rename assert() to assume()
- Let assume() take either a block or a code string
- Alias breakpoint?() to assume()
In that case assume() could be omitted in dev-utils though I fear it
might cause some confusion. I still need to get final feedback from
Gavin. (I hope he is not tired of this yet. It grew to quite a long
thread and I am the one to blame for that.)