IRC channel logs
2023-04-04.log
back to list of logs
<rekado>there’s obviously a bug there when going from one month to the next <dokma>How do I list the context when debugging? Something like l in gdb? <lloda>there's ,locals, but it's not very useful unfortunately <dsmith>rekado, I think that bug surfaced about the time when the year changed to 2023 <dsmith>rekado, And thanks for your service, BTW! <old>dokma: I don't think there's such possibility right now. That would require the .debug_line program in DWARF section of the ELF program I think <old>there's been discussion for a workgroup to make a debugger in Guile <old>I for one would pay for that feature <old>having the ability to list like in GDB would be such a breeze while single-stepping <dokma>old: strange... if I recall correctly, while I'm stepping it's showing me the line the debugger is on... <old>dokma: In guile? I've never had that <old>would like to see that <dokma>lloda, old: how do you guys debug guile then? It seems hugely impaired without the ability to see where I am in code? <dsmith>dokma: usually with pk or just evaluating things in a repl or emacs/geiser <dokma>those 341:2, 342:27, 343:33 correspond precisely to the source code lines inside getopt-long.scm <old>dokma: that's a frame on the stack <old>listing would point where in the file you're <old>I usually use pk and also <old>dokma: try peek or pk: (pk 'foo 'bar' 'buz) <old>Not the best way of doing programmation, but it get the job done most of the time <dokma>old: 341:2 means line 342 and probably column 2 <dokma>it corresponds precisely to the source code lines inside getopt-long.scm <old>yes I know. my point is that in GDB you can do `list' to have the source code where you're printed <old>what you have is the location in the source, not the source itself <dokma>old: is there a way to set a breakpoint by the source code line? <old>,break-at-source FILE LINE <old>never used it though <old>don't know if it works <dokma> ,break-at-source /usr/share/guile/3.0/ice-9/getopt-long.scm 353 <dokma>While executing meta-command: <dokma>No procedures found at ~a:~a. "/usr/share/guile/3.0/ice-9/getopt-long.scm" 353 <old>,break-at-source ice-9/boot-9.cm:3241 <old>Trap1: BVreakpoiont at ice-9/boot-9.scm:3241 <old>,break-at-source ice-9/boot-9.cm 3241 <dokma>,break-at-source ice-9/getopt-long.scm 353While executing meta-command: <dokma>No procedures found at ~a:~a. "ice-9/getopt-long.scm" 353 <old>i got the same thing here <old>yet, line 353 is inside getopt-long <old>you need to (use-modules (ice-9 getopt-long)) before <dokma>scheme@(guile-user)> (use-modules (ice-9 getopt-long)) <dokma>scheme@(guile-user)> ,break-at-source ice-9/getopt-long.scm 353 <dokma>While executing meta-command: <dokma>No procedures found at ~a:~a. "ice-9/getopt-long.scm" 353 <dokma>I hope I'm not pasting too much <old>well our version msut differ then <old>try ,break getopt-long <dokma>scheme@(guile-user)> (version) <old>mwette: look nice ! Is it possible to just copy this in my ~/.guile? <old>dokma: You would need perhaps to open the getopt-long.scm manually to see where the procedure is located <old>line 353 seems to not be anything in your version <dokma>353 is smack in the middle of getopt-long <dokma>(and (option-spec->required? spec) <old>I can't tell why you havve this behavior <dokma>Anyone got an idea why this would fail: <dokma>(use-modules (ice-9 getopt-long)) <dokma>(getopt-long '("--database") '((database (single-char #\d) (value #t) (required? #t)))) <dokma>Even this: (getopt-long '("--database=path") '((database (single-char #\d) (value #t) (required? #t)))) <old>you're missing argv[0] in it <old>usually program have their first argument as the name of the program <old>try: (getopt-long '("program" "--database=path") '((database (single-char #\d) (value #t) (required? #t)))) <dokma>old: damn, now it works... chatgpt told me I don't need argv[0] <old>well a program that assume argv[0] is always present is indeed wrong <old>it's possible for argc == 0 <old>but IRC, so many program relies on this behavior now that you can always assume that argc >= 1 <old>where agrv[0] is always the name of the program <old>don't listen to that bot :-) <dsmith>Things spawned from a shell probably always have argv[0] correct. Prob the only way to not have argv[0] is to directly call exec specifically without it. <old>but there's absolutely nothing in any standard stipulating argv[0] must be set <old>it's not documented in any API/ABI <dokma>scm_c_define("arguments", arguments); <dokma>SCM arguments = scm_c_eval_string("(define arguments '()) arguments") <unmatched-paren>ACTION has never used libguile but is quite surprised that the '() object is called SCM_EOL rather than SCM_NULL or SCM_NIL <count3rmeasure>hey all, I have a license question! I see that guile itself is LGPL, but my code depends on the guile libraries bundled with GDB, which would make them (the modules) subject to the GPL, right? <count3rmeasure>thus any work that I release would have to be subject to the GPL as well? rather than the LGPL? <dokma>count3rmeasure: did you check license tldr? <daviid>count3rmeasure: i woukd ask in #gnu and/or #fsf <count3rmeasure>I've read the license, and the COPYING3.LIB in binutils source directory, which seems to me to say that, yes, my work would be necessity be GPL3 <count3rmeasure>in case anyone has similar questions in the future, a kind soul on #gnu noted that there FSF has an email account specifically for answering these questions licensing@fsf.org <Arsen>count3rmeasure: you might be well served by #gdb <dsmith>old, I was trying to see if I can get argc to be 0. Haven't been able to.