IRC channel logs

<sneek>Yey! tohoyn is back!!

<tohoyn>sneek: botsnack

<tohoyn>I'm debugging code where a Guile callback is called by the Gio library (GDBus). I'm using a modified version of libguile/guile launching Guile in GDB, see https://paste.debian.net/hidden/dd2a02cf for the patch. The callback raises a Guile exception. However, when I give commands run and bt in GDB it says "No stack". What can I do to obtain the call stack in GDB?

<tohoyn>daviid: here is the Guile backtrace from the previous example: https://paste.debian.net/hidden/f21fe91a

<tohoyn>daviid: it suggests that the conversion from gchar* to gchar** while calling on-my-signal is not performed by G-Golf.

<tohoyn>daviid: note that I use a modified version of Guile for printing the backtrace since the Guile backtrace is buggy.

<daviid>tohoyn: signal uses closures (GClosures) and that works fine, on-my-signal does receive the strings as expecte. the Gio callback argument should fill a pointer to a string, it does not, it fills a pointer to a pointer (against the callback signature def) - i gave up trying to find why, i have received nearly zero help from upstream, and spent too much time on this already ...

<daviid>tohoyn: no idea wrt gdb

<daviid>tohoyn: what you can do is to locally patch ffi-arg-string->scm like this

<daviid>(define (ffi-arg-string->scm ffi-arg) (gi->scm (dereference-pointer (dereference-pointer ffi-arg)) 'string))

<tohoyn>daviid: are you sure it won't break any existing code?

<daviid>but I am not gona patch g-golf because it is wrong, by definition ... but you may do this locally and you'll be fine

<tohoyn>daviid: ok. tx.

<daviid>yes, you'll be fine, till you face another callback arg situation for ahich a string arg would be properly filled ... I coudn't find an example so far

<daviid>if you or anyone here knows a callback arg example that one of its arg is a string, let me know (and not a DBus example)

<sneek>Yey! mwette is back :D

<mwette>sneek: botsnack

<sneek>:)

<ekaitz>mwette: do you need assistance with anything in Mes?

<sneek>ekaitz, you have 1 message!

<sneek>ekaitz, csantosb says: we're in red here, https://www.kicad.org/download/linux/; you were thinking about some kind of meta package here, right ?

<mwette>ekaitz: Not now, thanks. I'm working on the C preprocessor and working to keep to Mes-compatible forms (match, let-values).

<janneke>mwette: i found that nyacc may unread two characters, is that intentional/are you aware of that?

<janneke>currently, mes simply uses the one character buffer of [fd]ungetc, now very scheme'y, we may have to change that...

<janneke>the pre-processor, that is

<graywolf>Hello Guile! So, interesting problem. I have a binding around a C library, exposing few defines. It basically boils down to (define-public foo 42).

<mwette>janneke: I think it could. lex.scm: read-c-num make-comm-reader make-chseq-reader. If you find out where, I could take a look.

<graywolf>How do I set a dostring for such a variable?

<graywolf>docstring*

<janneke>mwette: it happens when pre-processing https://paste.debian.net/hidden/b648bd71

<janneke>stefan found that, when removing all spaces after all 'n' characters, the double unread no longer happens

<mwette>Ah. Last line of cpp.scm(collect-args), I think. It's looking to see if n is a function macro so has to scan to find `?', then undo '?' and ' '

<mwette>s/function macro/function macro call/

<mwette>The new C preprocessor, if I ever finish it, is totally token based, so I think this case would not happen.

<janneke>sounds good :)

<identity>graywolf: i would guess (info "(guile) Procedure Properties")

<identity>graywolf: actually, you seem to want a documentation string for a variable, but with Guile variables can not have documentation strings attached to them, only procedures

<janneke>mwette: yes, (else (unread-char ch) (if sp (unread-char #\space)) #f) that's it

<janneke>thanks

<graywolf>One thing I did not realize is that the documentation strings are associated with the values, not with the variable, I find that a bit confusing. So it works fine for procedures and (mostly) for strings and lists, but fails badly for integers.

<mwette>And I believe *variables* don't have docstrings, only procedure values.

<graywolf>Only values, it is not limited to procedures. But as I discovered there are practical limitations for other types. Two variables in two separate modules, both defined to 42, cannot have a different docstring. Which is bit limitting.

<mwette>You could add object-property to the variable from the module, maybe.

<graywolf>oh, I am gonna try that and see if ,d pick it up, good idea

<graywolf>thx

<mwette>,d wont work I think but you can add your own custom repl commands

<graywolf>Yeah probably not worth it going there, since I would also need to patch geiser to handle it correctly, so I will just leave it in the info manual

<mwette>janneke: Is that n(x) macro usage (i.e., identifier happens to be a function macro) in tcc?

<janneke>mwette: yes; stefan has been patching tcc to remove spaces after 'n' in for this case

<janneke>ie, areturn 0 < n? n- 1 : 0;

<janneke>(but that kind of patch isn't really upstream'able)

<mwette>But maybe using different identifier is; seems like tcc should avoid edge cases for the cpp.

<janneke>mwette: I would hope so

<mwette>multi-level use of ## is another one

IRC channel logs

2026-01-18.log