IRC channel logs

<apteryx>ieugen: there's also https://www.gnu.org/software/guile/libraries/

<apteryx>or https://packages.guix.gnu.org/search/?query=guile

<mwette>In nyacc source there is examples/ffi/protobuf.ffi to generate FFI calls for libprotobuf-c. code generated by nyacc's ffi-help looks like this: https://paste.debian.net/1303839/

<ArneBab>iank: you’re welcome ☺

<lloda>graywolf: i think bug-guile for bugs and patches and guile-devel for discussion makes sense. Idk about should, it's just that there's no tracking in guile-devel

<lloda>if contribution text says otherwise, maybe it should be updated, but that's just my opinion

<oriba>how to set the linewidth of the guile repl?

<mwette>oriba: try (use-modules (system repl debug)) (terminal-width 120)

<mwette>or `COLUMNS=120 guile'

<oriba>mwette: hmhh, does not work

<mwette>sorry : that's all I could find in the code

<dthompson>I'm convinced there's something cursed in that code

<dthompson>from debugging strange issues in the past

<mwette>One of my back-burner projects is to figure it all out and update. Was last working on how to update (the dwarf dies) with more info on locals.

<mwette>And I did find something odd wrt stepping through code. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54478

<mwette>stepping through body of let would always return to the start of the let and then back

<oriba>even if it did not work, thanks for your effort

<mwette>yw

<merlin01>hello, is there anyone who would be willing to help me understand how the trap system works in guile?

<mwette>did you read the manual section on that (in debugging infrastructure)?

<mwette>I went though this in detail a few times, but hard to remember it. There are some tricky parts (e.g., vm-trace-level). I wrote this a while ago: https://github.com/mwette/guile-jtd/blob/main/jtd.scm

<merlin01>Sorry for the late response I am still figuring out how IRC works. I have been reading the guile reference manual to figure out how to properly debug guile. I really just want a simple debugging environmnet similar to gdb, but the repo you sent does look promissing so I will check that out thank you.

<mwette>Unfortunately, the guile debugger is not great. (I thought it was great back in the v1.6 days.)

<merlin01>The idea that you can build higher level debugging tools from lower level ones does sound interesting though so at some point I would like to know how it all works. The manual would be a bit clearer if they had more thorough examples imo

<merlin01>dang that is unfortunate. The manual was talking up how the use of the vm could lead to making better debugging tools so I thought it would be good.

<dthompson>the debugging tools could use some work but they're pretty decent I think

<mwette>There are a lot of comments in the code. Check system/vm/{traps,trap-state}.scm. There may be more.

<mwette>I just remember from 20+ years ago I thought the guile-1.6 debugger was so great. You could step through a program and examine variables easily. I want to get back to that satisfaction.

<mwette>I think what's needed now is to add more info into the dwarf object. I've looked into that but it has been tough to make progress.

<ieure>I like Emacs' built-in debugger, and CIDER's is nearly as good. C-u C-M-x on a function and it instruments and you single-step through whenever it's called, with the ability to inspect whatever's in scope. Pretty nice.

<ieure>Lots of languages I've worked with have very poor debuggers that need a lot of setup to work at all, and stop working often with no obvious explanation why. Don't like that.

IRC channel logs

2024-01-12.log