IRC channel logs

<daviid>sneek later tell tohoyn, that's not the cause of the problem no, and fyi, callback use the libffi api, which means that we (lang binding, g-golf as well ofc), must call ffi-cif-prep, which validates what is needed to place callback calls ... the problem is, for some reason I can't identify, though the emit-signal properly sets its utf8 gi-args to a pointer to the string, the signal callback ffi-arg array is filled with a pointer to the

<daviid>pointer to the string - gi folks argue that it is g-golf, but I fail to see where g-golf is involved, in between the emit-signal and signal callback call, afaitc, I mean the code that fills the ffi-args array, g-golf is not invlolved - so you see for yourself, if I patch ffi-arg-string->scm to double dereference the ffi-arg, for utf8 args, then 'we' get the expected values, here - https://bpa.st/VDPA

<daviid> sneek later tell tohoyn, that's not the cause of the problem no, and

<daviid> fyi, callback use the libffi api, which means that we (lang binding,

<daviid> g-golf as well ofc), must call ffi-cif-prep, which validates what is

<daviid> needed to place callback calls ...

<sneek>Okay.

<daviid>sneek later tell tohoyn the problem is, for some reason I can't identify, though the emit-signal properly sets its utf8 gi-args to a pointer to the string, the signal callback ffi-arg array is filled with a pointer to the string - gi folks argue that it is g-golf, but I fail to see where g-golf is involved, in between the emit-signal and signal callback call, afaitc, I mean the code that fills the ffi-args array, g-golf is not

<daviid>invlolved - so you see for yourself, if I patch ffi-arg-string->scm to double dereference the ffi-arg, for utf8 args, then 'we' get the expected values, here - https://bpa.st/VDPA

<daviid> sneek later tell tohoyn the problem is, for some reason I can't

<daviid> identify, though the emit-signal properly sets its utf8 gi-args to a

<daviid> pointer to the string, the signal callback ffi-arg array is filled

<daviid> with a pointer to the string - gi folks argue that it is g-golf, but

<daviid> I fail to see where g-golf is involved, in between the emit-signal

<daviid> and signal callback call, afaitc, I mean the code that fills the

<daviid> ffi-args array

<daviid>wohw, sorry, I was preparing an answer a bit too long and either irc or sneek can't cope with ... now tat I (have to)use matrix, I am used to unlimited msgs

<ft>:)

<daviid>ok, i'll leave it for tomorow :-), I cn't get this irc nor sneek to work propley ... sorry for the noise

<daviid>i'll just post the msg, hoping tohoyn will read the logs

<daviid>tohoyn, that's not the cause of the problem no, and fyi, callback use the libffi api, which means that we (lang binding, g-golf as well ofc), must call ffi-cif-prep, which validates what is needed to place callback calls ... the problem is, for some reason I can't identify, though the emit-signal properly sets its utf8 gi-args to a pointer to the string, the signal callback ffi-arg array is filled with a pointer to the pointer to the

<daviid>string - gi folks argue that it is g-golf, but I fail to see where g-golf is involved, in between the emit-signal and signal callback call, afaitc, I mean the code that fills the ffi-args array, g-golf is not invlolved - so you see for yourself, if I patch ffi-arg-string->scm to double dereference the ffi-arg, for utf8 args, then 'we' get the expected values, here - https://bpa.st/VDPA

<sneek>Yey! tohoyn is back :D

<tohoyn>daviid: it seems that variable ffi-arg in procedure g-golf-callback-closure-marshal is a pointer to a stack frame or corresponding structure as it is incremented by procedure gi-pointer-inc.

<sneek>tohoyn, you have 1 message!

<sneek>tohoyn, daviid says: that's not the cause of the problem no, and

<tohoyn>daviid: so the double referencing is caused when the ffi-arg pointers to a pointer into the stack frame which points to the string.

<tohoyn>daviid: consider procedure ffi-arg-int64->scm: first the pointer is referenced by procedure dereference-pointer and the new pointer is dereferenced by procedure pointer->bytevector.

<tohoyn>daviid: I did read your previous mail from the log.

<tohoyn>s/is referenced/is dereferenced/

<tohoyn>daviid: the second comment should be: the double referencing is caused when pointer ffi-arg points to a pointer in the stack frame and that pointer points to a string.

<tohoyn>daviid: I might have been wrong

<tohoyn>daviid: it seems that procedure does the double dereferencing

<tohoyn>daviid: procedure gi-string->scm

<lechner>Hi, anyone else yearn for a bytevector-index?

<identity>bytevector-index?

<lechner>yeah, like this: (list-index (lambda (element) (= value element)) (bytevector->u8-list bv))

<empathy_monster>Hello. I'm reading version 3 of the reference manual and cannot seem to figure out how to compile or run ECMAscript. I'm using guile version 3.0.11 on Void Linux trying to do SICPjs. Any help would be greatly appreciated, thanks!

<empathy_monster>If I run `guild compile main.js` for example, it definitely does something because I get a warning about possible unbound variables and it seems to write to a cache file?

<daviid>tohoyn, no none of the ffi-arg pointers are being dereferenced twice, and no, gi-string->scm does not 'double dereference'

<tohoyn>daviid: btw, I switched on some debugging code in Gio and function emit_signal_instance_in_idle_cb passes correct arguments to the callback.

<lechner>Hi, calling 'error' is very convenient. Is there also a 'warning' or similar?

<identity>lechner: i guess you can do (define (warning . etc) (raise-continuable (apply make-warning etc))) for that

<identity>i guess that is not exactly how you use &warning, but you get the idea

<identity>while calling ‘error’ is very convenient, it is also frequently the wrong thing

<lechner>like when?

<sneek>wb mwette

<mwette>sneek: botsnack

<sneek>:)

<mwette>Since yesterday I can't connect to this irc w/ emacs. Anyone willing to share a minimal (stubbed) erc config?

<identity>mwette: (setopt erc-modules (cl-pushnew 'sasl erc-modules)) and the rest depends on whether you use CertFP or not

<identity>if yes, (setopt erc-sasl-mechanism 'external) (erc-tls :client-certificate t) ;where t means ask .authinfo for the certificates, see (info "(erc) Connecting") on CLIENT-CERTIFICATE

<mwette>identity: thanks, let me try that ...

<xiews>congratulations to wingo

IRC channel logs

2025-12-26.log