IRC channel logs


back to list of logs

<apteryx>ieugen: there's also
<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:
<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
<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
<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:
<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.