May 10, 2008
Nick Sabalausky wrote:
<snip>
> If you're not familiar with the trick of debugging output statements, it's like this: Start with main() and sprinkle normal output statements through it. For instance, if your main() is like this:
> 
> void main()
> {
>    someFunc();
>    if(something)
>        doSomething();
>    anotherFunc();
>    yetAnotherFunc();
> }
> 
> Then do this:
> 
> void main()
> {
> Stdout("1").newline;
>    someFunc();
> Stdout("2").newline;
>    if(something)
>    {
> Stdout("3").newline;
>        doSomething();
> Stdout("4").newline;
>    }
> Stdout("5").newline;
>    anotherFunc();
> Stdout("6").newline;
>    yetAnotherFunc();
> Stdout("7").newline;
> }
> 
> Obviously, copy/paste helps there ;) Run that and you'll get something like:
> 
> 1
> 2
> 5
> tango.core.Exception.IllegalArgumentException: Argument not valid
> 
> In this case, we know the if() ended up false and "doSomething()" was skipped, and we also know the exception was thrown somewhere in "anotherFunc()". So rip those "Stdout's" out of there, and do the same thing in "anotherFunc()". Keep drilling down like that until you find the problem.
> 
> I do that all the time in my own code (because so far I've been too lazy to actually get a debugger set up with D :) ).
> 
> 

Here's a tip:

Use: __FILE__, __LINE__ in your arguments.  That way you don't need to keep changing the value.

I bet one could write a mixin that would do this automatically and you'd simply wrap each function in that mixin.

-Joel
May 11, 2008
janderson wrote:
> Nick Sabalausky wrote:
> <snip>
>> If you're not familiar with the trick of debugging output statements, it's like this: Start with main() and sprinkle normal output statements through it. For instance, if your main() is like this:
>>
>> void main()
>> {
>>    someFunc();
>>    if(something)
>>        doSomething();
>>    anotherFunc();
>>    yetAnotherFunc();
>> }
>>
>> Then do this:
>>
>> void main()
>> {
>> Stdout("1").newline;
>>    someFunc();
>> Stdout("2").newline;
>>    if(something)
>>    {
>> Stdout("3").newline;
>>        doSomething();
>> Stdout("4").newline;
>>    }
>> Stdout("5").newline;
>>    anotherFunc();
>> Stdout("6").newline;
>>    yetAnotherFunc();
>> Stdout("7").newline;
>> }
>>
>> Obviously, copy/paste helps there ;) Run that and you'll get something like:
>>
>> 1
>> 2
>> 5
>> tango.core.Exception.IllegalArgumentException: Argument not valid
>>
>> In this case, we know the if() ended up false and "doSomething()" was skipped, and we also know the exception was thrown somewhere in "anotherFunc()". So rip those "Stdout's" out of there, and do the same thing in "anotherFunc()". Keep drilling down like that until you find the problem.
>>
>> I do that all the time in my own code (because so far I've been too lazy to actually get a debugger set up with D :) ).
>>
>>
> 
> Here's a tip:
> 
> Use: __FILE__, __LINE__ in your arguments.  That way you don't need to keep changing the value.
> 
> I bet one could write a mixin that would do this automatically and you'd simply wrap each function in that mixin.
> 
> -Joel

On further thought that might not work.  I'm not sure what would be in __FILE__ and __LINE__.  However the mixin could still print out the actual code that was just before the ";".

-Joel
May 11, 2008
Jason House Wrote:
>>Do a try catch at global scope and use the member variables of the exception
to print out extra detail.  Tango exceptions include file and line number as member data.  Maybe someone should submit a ticket for them to add that info to the default toString method.<<


Now thats the stuff . Its just a matter of simplifying it for learners .  If it doesn't give a line ,or statement ,or argument, you end up like a stunned mullet for a while.
Thanks for responses
May 11, 2008
On Sat, 10 May 2008 11:03:38 +0200, Nick Sabalausky <a@a.a> wrote:

> You've just made me feel incredibly stupid. That particular "Why in the
> world did that never occur to me?" kind of stupid. My forehead still hurts
> from the smack. ;)

:)

> I find that turning a single-statement if into a {} block when needed is
> trivial enough of a change (almost second-nature) to justify keeping
> single-statement if's in a nice compact {}-less form (unless the clause or
> single-statement is long enough to be broken into multiple lines for
> readability). But I'm really compulsive when it comes to code formatting
> anyway (everything's gotta be "just so" or I can't focus, kinda like that TV
> detective Monk, albiet far less severe ;) ).

Yeah, I hate it when Eclipse starts to put my case statements on the wrong indentation level. That supports the theory that programmers often tend to have a little trace of authism in their personality. Sometimes small details can drive me mad and I spend lots of time formatting console output so that it lines up neatly or stuff like that.

Another thing about Stdout debugging: it's nice to define an alias for Stdout in a debug { } block and use that alias for debug messages, preferably in a module that's used everywhere in a project. I do that since once, back in my C++ days, one of my "in here" couts went into production - the alias prevents that.

-Mike


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
May 11, 2008
Mike Wrote:

> On Sat, 10 May 2008 11:03:38 +0200, Nick Sabalausky <a@a.a> wrote:
> 
> > You've just made me feel incredibly stupid. That particular "Why in the
> > world did that never occur to me?" kind of stupid. My forehead still
> > hurts
> > from the smack. ;)
> 
> :)
> 
> > I find that turning a single-statement if into a {} block when needed is
> > trivial enough of a change (almost second-nature) to justify keeping
> > single-statement if's in a nice compact {}-less form (unless the clause
> > or
> > single-statement is long enough to be broken into multiple lines for
> > readability). But I'm really compulsive when it comes to code formatting
> > anyway (everything's gotta be "just so" or I can't focus, kinda like
> > that TV
> > detective Monk, albiet far less severe ;) ).
> 
> Yeah, I hate it when Eclipse starts to put my case statements on the wrong indentation level. That supports the theory that programmers often tend to have a little trace of authism in their personality. Sometimes small details can drive me mad and I spend lots of time formatting console output so that it lines up neatly or stuff like that.
> 
> Another thing about Stdout debugging: it's nice to define an alias for Stdout in a debug { } block and use that alias for debug messages, preferably in a module that's used everywhere in a project. I do that since once, back in my C++ days, one of my "in here" couts went into production - the alias prevents that.
> 
> -Mike
> 
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

If you are proud of your work its job satisfaction to clean it up and pretty up the output.

Can you explain the debug{} a bit more please  Mike . What does that look like and how is it used?
May 11, 2008
Mike wrote:
> Yeah, I hate it when Eclipse starts to put my case statements on the wrong indentation level.

Both JDT and Descent let you choose. Window > Preferences > Java/D > Code Style > Formatter > Edit... > Indentation
May 12, 2008
On Sun, 11 May 2008 02:04:00 +0200, janderson <askme@me.com> wrote:

> janderson wrote:
>>  Here's a tip:
>>  Use: __FILE__, __LINE__ in your arguments.  That way you don't need to keep changing the value.
>>  I bet one could write a mixin that would do this automatically and you'd simply wrap each function in that mixin.
>>  -Joel
>
> On further thought that might not work.  I'm not sure what would be in __FILE__ and __LINE__.  However the mixin could still print out the actual code that was just before the ";".
>
> -Joel

import std.stdio;
import std.traits;

template _debug(alias f, int line = __LINE__, string file = __FILE__)
{
	ReturnType!(f) _debug(ParameterTypeTuple!(f) u)
	{
		writefln("%s(%d) executed.", file, line);
		return f(u);
	}
}


Usage:

_debug(function)(parameters);


There might be a simpler, more prettiful way to find the return type and parameters, but this works.

-- Simen
May 12, 2008
Robert Fraser wrote:
> Mike wrote:
>> Yeah, I hate it when Eclipse starts to put my case statements on the wrong indentation level.
> 
> Both JDT and Descent let you choose. Window > Preferences > Java/D > Code Style > Formatter > Edit... > Indentation

I think I know what he means: unfortunately, Descent doesn't seem to pay attention to that setting when you're just typing code. If I try to type
---
void foo(int bar) {
    switch (bar) {
        case 1:
    }
}
---
I instead get:
---
void foo(int bar) {
    switch (bar) {
    case 1:
    }
}
---
Note the indenting of 'case'. This is with the checkbox for [Indent] "'case'/'default' statements within 'switch'" turned on. And it happens whether or not I press 'tab' before typing 'case'. (If I use tab to manually indent the 'case', it *unindents* the moment I hit 'e'!)

Pressing Ctrl-Shift-F fixes the indentation; this seems to be an auto-indenting issue, not a formatter issue.

(Descent 0.5.2.20080501, Eclipse 3.2.2 / M20070212-1330 (Ubuntu version: 3.2.2-5ubuntu2))
May 12, 2008
On Mon, 12 May 2008 13:06:45 +0200, Frits van Bommel <fvbommel@REMwOVExCAPSs.nl> wrote:

> Robert Fraser wrote:

> I think I know what he means: unfortunately, Descent doesn't seem to pay attention to that setting when you're just typing code. If I try to type
> ---
> void foo(int bar) {
>      switch (bar) {
>          case 1:
>      }
> }
> ---
> I instead get:
> ---
> void foo(int bar) {
>      switch (bar) {
>      case 1:
>      }
> }
> ---
> Note the indenting of 'case'. This is with the checkbox for [Indent] "'case'/'default' statements within 'switch'" turned on. And it happens whether or not I press 'tab' before typing 'case'. (If I use tab to manually indent the 'case', it *unindents* the moment I hit 'e'!)
>
> Pressing Ctrl-Shift-F fixes the indentation; this seems to be an auto-indenting issue, not a formatter issue.
>
> (Descent 0.5.2.20080501, Eclipse 3.2.2 / M20070212-1330 (Ubuntu version: 3.2.2-5ubuntu2))

Exactly. It seems to do it only with the first case, however.

-Mike



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
May 12, 2008
On Mon, 12 May 2008 00:22:39 +0200, Tower Ty <tytower@hotmail.com> wrote:

> Can you explain the debug{} a bit more please  Mike . What does that look like and how is it used?

It's code that only gets compiled in a debug build.

Here's roughly what I do:

debug
{
    alias Stdout dbg;
}

Later on I use Stdout for every normal output, but dbg for temporary debug messages:

<example>

Stdout("Initializing warp drive ...").newline; // this should be in the console in debug and release mode

WarpEngine.prepareUnipolarMatrixPhalanxThingie(unipolar);
dbg("first call ok, foo = ")(WarpEngine.foo).newline; // this should be removed before release

WarpEngine.resetWarpParameterFieldConstants(1, 2, 1701);
dbg("second call ok, bar = ")(WarpEngine.bar).newline;

WarpEngine.initializeWarpNacelles(BOTH);
dbg("third call ok, baz = ")(WarpEngine.baz).newline;

WarpEngine.removeTribbles(all);
dbg("fourth call ok, now engaging").newline;

WarpEngine.engage();

Stdout("Warp drive ready.").newline;

</example>

Those dbg Stdouts should be removed in a release build. But every now and then you forget to remove one and it ends up in production. So if you now compile this with the -release flag, the alias never gets defined and every dbg call still in there yields a syntax error.

-Mike

PS: I'm NOT a Star Trek fan :)

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/