Prev: Robert Martins' payroll example (Was: Why is Object Oriented so successfull)
Next: Am I "Overqualified"?
From: Martin Vuille on 29 Jan 2008 15:00
"Paul E. Black" <p.black(a)acm.org> wrote in
news:fnnpnk02421(a)news5.newsguy.com:

> ASSERT(0 <= linebufp-linebuf && linebufp-linebuf <=
> line_width)
>
> Here's comes from the last one when the assertion fails
>
> 0 <= linebufp-linebuf && linebufp-linebuf <= line_width false
> in format.c, line 110
>

I've done that too, but what's missing is displaying the
actual value of the variables so you can tell what went wrong.

MV

--
I do not want replies; please follow-up to the group.
From: Dmitry A. Kazakov on 29 Jan 2008 15:51
On 29 Jan 2008 20:00:03 GMT, Martin Vuille wrote:

> "Paul E. Black" <p.black(a)acm.org> wrote in
> news:fnnpnk02421(a)news5.newsguy.com:
>
>> ASSERT(0 <= linebufp-linebuf && linebufp-linebuf <=
>> line_width)
>>
>> Here's comes from the last one when the assertion fails
>>
>> 0 <= linebufp-linebuf && linebufp-linebuf <= line_width false
>> in format.c, line 110
>>
>
> I've done that too, but what's missing is displaying the
> actual value of the variables so you can tell what went wrong.

And also the call stack at the spot, and a message to show.

But a far better debugging technique than fake assertions (the true ones
are strict compile-time invariants) is IMO tracing. Such that you can hang
a handler on it. In Gtk+ there is such. Then you can attach a handler that
stops upon an interesting tracing event and breaks into the debugger, so
that you could inspect the stack and the variables around.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Patrick May on 31 Jan 2008 07:47
Phlip <phlip2005(a)gmail.com> writes:
> I have invented a new concept of developer test assertions. This
> post is a preview of its features, before I release it for
> Ruby. Porting it to other languages is left as an exercise for the
> reader.
>
> assert{ 2.0 }
>
> I don't like the simple assertions - assert_equal, assert_match,
> assert_not_nil, etc, in my developer tests. They only exist for one
> reason - to print out their values when they fail. And then they
> don't even reflect their variable names, either.
>
> So I wrote an assertion to replace them. Put whatever you want into
> it; it prints out your expression, and all its values.

You mean like you can easily do in Common Lisp:

http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html

It's nice to see people making the effort to bring these primitive
languages into the brave new world of the late 1950s and early 1960s.
;-)

Ha, ha, only serious,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Phlip on 31 Jan 2008 09:50
> You mean like you can easily do in Common Lisp:

Already pointed out on another forum.

> Ha, ha, only serious,

I'll stick with the language where every parenthesis pair is optional, thanks.
From: Dmitry A. Kazakov on 31 Jan 2008 11:14
On Wed, 30 Jan 2008 06:50:57 -0800, Phlip wrote:

> I'll stick with the language where every parenthesis pair is optional, thanks.

I always wondered why dynamically typed languages do not make brackets
dynamic... To enjoy that at full one could invent assertions asserting that
the numbers of left and right brackets are same... Or what about asserting
statements:

if assert I said, "if"! then assert I really mean "then"! or else! ...

you get the idea... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Robert Martins' payroll example (Was: Why is Object Oriented so successfull)
Next: Am I "Overqualified"?