I debug code using print.
How does Jow Forums debug their code?
I debug code using print.
How does Jow Forums debug their code?
Other urls found in this thread:
mercurylang.org
twitter.com
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
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