I debug code using print

I debug code using print.

How does Jow Forums debug their code?

Attached: 1555640114391.png (339x92, 6K)

Other urls found in this thread:

mercurylang.org/information/doc-latest/mercury_ref/Trace-goals.html
twitter.com/NSFWRedditImage

trace goals, of course.
:- module fib.
:- interface.
:- import_module io.
:- pred main(io::di, io::uo) is det.
:- implementation.
:- import_module int, list, string.

main(!IO) :-
io.command_line_arguments(Args, !IO),
( if
Args = [NStr],
to_int(NStr, N)
then
io.format("fib(%d) = %d\n", [i(N), i(fib(N))], !IO)
else
io.set_exit_status(1, !IO)
).

:- func fib(int) = int.
fib(N) = R :-
trace [io(!IO), runtime(env("TRACE"))] (
io.format("fib(%d) = %d.\n", [i(N), i(R)], !IO)
),
( if N < 2 then
R = N
else
R = fib(N - 1) + fib(N - 3)
).
as used:
$ ./fib 25
fib(40) = 102334155
$ TRACE=y ./fib2 25|tail -5
fib(16) = 60.
fib(19) = 189.
fib(22) = 595.
fib(25) = 1873.
fib(25) = 1873
you get your print debugging, but it's conditional, and you get it in otherwise purely functional code.
and you can use the same stuff for programming-by-contract that you pay for in debugging builds, but not at release.

ah fuck that's the version with the bugged fib.
that's intentional, I swear.

I write a ton of asserts. It's objectively superior to printf because every line of your program is tied to a specific invariant and within the assert, you can check an arbitrary number of values and statements to make use of all knowns and unknowns.
With printf, you work bottom-up. You realise what the problem is, then where the problem is, and finally how to fix it. And unless you printf each variable/statement at each line of code, you never really realise you have a problem in the first place, meaning you miss bugs.
However, writing printfs at every (couple of) line is a net functional subset of asserts because asserts also print messages.
Ergo, asserts are functionally superior to printf.

tl;dr your debugger already keeps track of all variables during step-into

Pretty much the same. Print text at sections with numbers so if one doesn't run something is broke in that section

Dick is diamonds. Mercury?

you said tl;dr but you didn't talk about the debugger at all
yep. mercurylang.org/information/doc-latest/mercury_ref/Trace-goals.html

That's why it's tl;dr.

asserts are cool.
stuff like asserts (pre/post assertions) are cool.
printf debugging?
#include
#include

enum metanym { alice, bob, eve };

int main (void) {
enum metanym n = alice;
char *r;
switch (n) {
case alice:
case bob:
r = "Hello there!";
printf("OwO: %d\n", n);
break;
case eve:
r = "GET OUT OF HERE EVESDROPPER";
break;
}
puts(r);
}
how is this useful?
OwO: 0
Hello there!
compare:$ gcc -g -o owo owo.c
$ gdb ./owo
...
Reading symbols from ./owo...
(gdb) b main
Breakpoint 1 at 0x40113e: file owo.c, line 7.
(gdb) r
Starting program: /home/user/sea/learn/owo
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-15.fc30.x86_64

Breakpoint 1, main () at owo.c:7
7 enum metanym n = alice;
(gdb) n
9 switch (n) {
(gdb) p n
$1 = alice

I don't. If an input causes wrong results I don't use that input.

with an actual debugger ofc

Debugger for the particular language I'm using

Step by step debugging, conditional breakpoints. I should check out that "step backwards" debugging VS has but that's enough for me. Also never tried unit tests, I see their value but they seem like too much effort to setup if they aren't built into the language itself.

why didn't you say gdb?
gdb supports a lot of languages you know.
it supports C, C++, D, Go, Objective-C, OpenCL C, Fortran, Pascal, Rust, Modula-2, and Ada.

Of those only C, C++ and to an extent OpenCL have real-world applications on any level.

D has lots of applications, I'm sure. I can't think of any right now. But it's supported by gdb, the GNU Debugger. Give it some credit.
Go has influxdb, which is a pretty nice time-series database.
Objective C is apple shit and probably deprecated by newer appleshit but you could always use GNUStep in defiance of the times, user.
Fortran's still used. Still competitive for numerical algorithms.
Pascal support was probably added to gdb as a joke.
Rust support was probably added to gdb as a joke.
Modula-2 support was probably added to gdb as a joke.
Ada has lots of real-world application. Realer-world than most. Ada applications can kill you, user.

With a debugger like a white man

If possible with QtCreator or VisualStudio.
If I have to do it on the server with gdb.

Print and compile errors.

Since we have a debugging thread, dear user, could you recommend any books/resources for learning gdb/debugging in general?

for python I use the logging module
pretty fuckin neat

Being a js-dev I go for that sweet alert(), even in loops at times ;)

Same.
>The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
-- Brian Kernighan

I just stare at my code ubtil i find the error

Valgrind and gdb.

With the dbg!() macro of course

If it doesn't do what I want it to do

VS tracepoints, quickwatch, print debugs if necessary, and test cases :-)

Reminds me of when I forgot to remove one of the "OwO" prints I've been using. Client thought the website got hacked when he accidentally hit F12 and saw "OwO"s in the console log lmao.

I turn on the debugging on Android Atudio which prints all the variables on screen and provides the phone's logs at the same time.

export PS4='\[$(tput rev)$(tput setaf 2)\]+\[$(tput sgr0)\] '
bash -x ~/bin/muh_cool_script
rm ~/bin/muh_cool_script

printf("AAAA");
or
printf("NIGGERS");

not even joking

>How does Jow Forums debug their code?
just look on the error and solve it?

I had to use printf in code to see the flow of code that leads up to memory leak in chromium. assertion wouldn't work since i didn't know the condition of it failing, and it didn't happen all the time. Using breakpoint wouldn't work either, as the code was executed very often but the bug only happened a few times. Or in other words, more complicated bugs