Michael Neumann wrote:
Would be really great if that works.
trace { x + y } #=> x+y = 5 assert { x + y == 0 } #=> assertion 'x+y==0' failed...
It is possible with proc_source, but that's quite ugly.
proc_source.rb (6.54 KB)
$ parse_tree_show
class Test
def test
trace { x + y }
assert { x + y == 0 }
end
end
[[:defn,
"test",
[:scope,
[:block,
[:args],
[:iter,
[:fcall, "trace"],
nil,
[:call, [:vcall, "x"], "+", [:array, [:vcall, "y"]]]],
[:iter,
[:fcall, "assert"],
nil,
[:call,
[:call, [:vcall, "x"], "+", [:array, [:vcall, "y"]]],
"==",
[:array, [:lit, 0]]]]]]]]
It is pretty easy to walk that tree to find the [:iter, [:fcall,
"trace"], ...] or "assert" and then generate some reasonable english
phrase from it.
You could pull and walk the tree on failures to the assertion you wanted
to generate a comment for...
···
Michael Neumann (mneumann@ntecs.de) wrote:
On Sun, Nov 14, 2004 at 01:20:49AM +0900, Gavin Sinclair wrote:
> On Sunday, November 14, 2004, 2:48:24 AM, Florian wrote:
>
> > Gavin Sinclair wrote:
>
> >>>>>I have thought about changing the name to "assume" so it can be included
> >>>>>in dev-utils, but I'm not sure if that name is better.
> >>>I think that would be way too much magic. I'd expect the method to just
> >>>take a block.
> >>
> >> Why a block? The breakpoint code uses Binding.of_caller anyway, so a
> >> block is not needed for evaluation. I don't see any other reason,
> >> technical or stylistic, why a block should be preferred.
>
> > Using strings for code is a bit ugly. We have blocks in Ruby, why not
> > use them? Using a String also causes a bit of escaping trouble (I know
> > this can be worked around via the %{} or <<-END syntax, but I still
> > think blocks are clearer than that.)
>
> Agreed, but you can print strings. You can't print blocks. See
> below.Hm, has someone tried ParseTree
(zenspider projects | software projects | by ryan davis) to print out blocks?Would be really great if that works.
trace { x + y } #=> x+y = 5
assert { x + y == 0 } #=> assertion 'x+y==0' failed...Uhm, seems that's only possible to dump methods in classes, not
arbitrary code. But maybe, it's possible.
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Gavin Sinclair wrote:
Are you suggesting that all breakpoint would only be enabled in debug
mode, or just the 'assume' ones? What kind of debug mode do you mean?
$DEBUG?
Only the assume ones. Yup, I was referring to $DEBUG.
What would you think about an assume() method that could take either a
block or a String?I agree it looks nicer, but I feel that breakpoint_unless is actually
a more appropriate name, even though it's a little ugly. 'assume'
doesn't tell you what it does. Setting breakpoints in this manner is
such a specific and irregular thing to do that I think the name needs
to be clear.
assume {} states an assumption that your code does. If it isn't met then something went wrong and you're now in a code branch that is completely unhandled and that should not occur. The traditional C version (called assert, but I can't have that name anymore because of test/unit, I suppose) figures that it would be best to shut down the application completely now. This one instead tells you that something went very wrong and gives you a chance of examining why and how things went wrong. The latter part is a detail, it need not be known to understand that assume {} states an assumption. I guess there could even be an implementation of it that fails just like assert in C instead of setting a breakpoint.
> Are you suggesting that all breakpoint would only be enabled in debug
> mode, or just the 'assume' ones? What kind of debug mode do you mean?
> $DEBUG?Only the assume ones. Yup, I was referring to $DEBUG.
That would be good.
(called
assert, but I can't have that name anymore because of test/unit, I
suppose)
Why? I think test/unit's assert only applies inside TestCases, where it is
quite applicable and I would continue to use it. I'd use your assert
anywhere else.
···
"Florian Gross" <flgr@ccan.de> wrote
itsme213 wrote:
(called
assert, but I can't have that name anymore because of test/unit, I
suppose)Why? I think test/unit's assert only applies inside TestCases, where it is
quite applicable and I would continue to use it. I'd use your assert
anywhere else.
Hm, good point. But a potential overlap could still be a bit confusing if somebody wants to use both of them in test cases. (That seems quite unlikely, however) What do you think about using 'assume'? It's quite similar, but still distinct enough not to confuse them with each other.
personally i don't like assume. when i have just finished executing a hairy
piece of code i would like to assert some predicate about the expected state
of the world.
assume works better in a specialized context: as a precursor to some block
(like a precondition): this assumption is needed for this block to do the
expected thing.
expect .... is an alternative but i prefer assert.
"Florian Gross" <flgr@ccan.de> wrote in message
news:2vnb6rF2m9lq7U1@uni-berlin.de...
itsme213 wrote:
>>(called
>>assert, but I can't have that name anymore because of test/unit, I
>>suppose)
>
> Why? I think test/unit's assert only applies inside TestCases, where it
is
···
> quite applicable and I would continue to use it. I'd use your assert
> anywhere else.Hm, good point. But a potential overlap could still be a bit confusing
if somebody wants to use both of them in test cases. (That seems quite
unlikely, however) What do you think about using 'assume'? It's quite
similar, but still distinct enough not to confuse them with each other.
It's not unlikely at all, actually. Test cases are a clearly a good
way to set up the conditions you need to expose a bug. That's when I
tend to use breakpoints very often.
Gavin
···
On Sunday, November 14, 2004, 8:08:24 AM, Florian wrote:
itsme213 wrote:
(called
assert, but I can't have that name anymore because of test/unit, I
suppose)Why? I think test/unit's assert only applies inside TestCases, where it is
quite applicable and I would continue to use it. I'd use your assert
anywhere else.
Hm, good point. But a potential overlap could still be a bit confusing
if somebody wants to use both of them in test cases. (That seems quite
unlikely, however) What do you think about using 'assume'? It's quite
similar, but still distinct enough not to confuse them with each other.
Gavin Sinclair <gsinclair@soyabean.com.au> writes:
It's not unlikely at all, actually. Test cases are a clearly a good
way to set up the conditions you need to expose a bug. That's when I
tend to use breakpoints very often.
I think there are are least two common scenarios described here:
1. You want an assertion as kind of a "can't happen" test.
2. You want to set breakpoints to inspect the state.
In my opinion, the first is the traditional "assert" while the second is
similiar to BREAK in Common Lisp. The former is useful in both test and
production code, while the latter only makes sense in test code. These
are different, and should have different names:
- "assert" or similiar to die horriby (except maybe when $DEBUG is set)
- "breakpoint" or similiar to simply interrupt execution.
···
--
Bjørn
Bjorn Nordbo wrote:
Gavin Sinclair <gsinclair@soyabean.com.au> writes:
It's not unlikely at all, actually. Test cases are a clearly a good
way to set up the conditions you need to expose a bug. That's when I
tend to use breakpoints very often.I think there are are least two common scenarios described here:
1. You want an assertion as kind of a "can't happen" test.
2. You want to set breakpoints to inspect the state.In my opinion, the first is the traditional "assert" while the second is
similiar to BREAK in Common Lisp. The former is useful in both test and
production code, while the latter only makes sense in test code. These
are different, and should have different names:- "assert" or similiar to die horriby (except maybe when $DEBUG is set)
- "breakpoint" or similiar to simply interrupt execution.
assert() doesn't die horribly in test cases either and when you find something wrong it can make sense to let a developer examine state so that the problem can be fixed instead of dieing without a way of diagnosing problems. I renamed the assert() that spawns an irb shell to assume() mostly to avoid collisions with test/unit. Personally I don't think it makes much sense to spawn an irb shell in test cases where you already have the problems clearly isolated anyway -- but test cases will require() the main application and if the main application still uses breakpoint.rb there will be a collision between test/unit's assert() and breakpoint's assert().
I guess assume() would be okay -- if anybody dislikes it and would rather use breakpoint() manually then great, I'm not forcing anybody to use assume() instead of breakpoint(). I have just found it useful to have both in my own code.
I just wonder if anybody would run into real problems because of breakpoint.rb providing assume().