IRC channel logs
2026-02-04.log
back to list of logs
<daviid>sneek: later tell tohoyn the 1st sentence makes no sence, because there is no conversion from char* to char** in G-Golf callback - the ffi-args array is filled by the upstream lib - and 'even if it would', which it doesn't, how could that possibly be a feature of an upstream library? <daviid>sneek later tell tohoyn the chatgpt conversation link is empty for me (which I have next to zero interest to look at, but out of curiosity ...), it seems you need a gitlab account, I don't and never will create an account with gitlab.com <daviid>sneek leter tell tohoyn last about this first sentence, about those upstream lib lines, I do not see how those would introduce a double reference, for utf8 args only - these lines seems to treat/deal with alignment 'problems', I am also not inytereste to read the libffi code ... fwiw <sneek>tohoyn, daviid says: last about this first sentence, about those upstream lib lines, I do not see how those would introduce a double reference, for utf8 args only - these lines seems to treat/deal with alignment 'problems', I am also not inytereste to read the libffi code ... fwiw <daviid>sneek later tell tohoyn last about this first sentence, about those upstream lib lines, I do not see how those would introduce a double reference, for utf8 args only - these lines seems to treat/deal with alignment 'problems', I am also not inytereste to read the libffi code ... fwiw <rlb>guessing it's the buildd fs somehow. <rlb>I should add some "system info" commands to debian/rules so it's easy to see what's going on with the host. <rlb>Or, hmm, might make sense to do that in ports.test proper... <rlb>Though I guess there's no way to see that output by default, so perhaps that doesn't help. <daviid>sneel later tell tohoyn the rest of your explaination is quite obscure, and does not seem to 'retrace' what g-golf does, here is what g-golf-callback-closure-marshal does: it walks the ffi-args array, which by definition is an array of pointers (and by walking I mean it takes the address of the ffi-args array, treats its first arg, increment the 'walking pointer' by the size of a pointer and ...; for each, it calls ffi-arg->cb-arg <daviid>(which calls ffi-arg->scm, which dereference the address it receives, which leads to a pointer to the C value, which gets 'decodewd' according to its type (none of those decoding 'subprocs' do ever double dereference, unlike you said in the past (pointer->bytevector is _not_ a dereference operation) ... then ffi-arg->cb-arg either returns the value it received from ffi-arg->cb-arg or further 'post process it' when needed; utf8 are not <daviid>further processed, only array glist gslist ghash error and interface (because the pointer being returned is the g-inst pointer, g-golf must retreive (or create) the proxy (goops) instance so the (guile scheme) callback code may work ... utf8 args are not further processed, the expected arg pointer must be a pointer to a string, and it is not (in the case of the DBus callback situation we are facing) ... there is nothing wrong with <daviid>g-golf, afaict, til prooved wrong (but no one has so far, and as said earlier, fwiw, g-golf passes all utrf8 marshalling tests (it wouls not if it it introduced double string (de)references ...) <daviid>too bad tohoyn only appears a few minutes, the disappear ... it makes the conversation extremelly annoying <daviid>sneek: sneek later tell tohoyn the rest of your explaination is quite obscure, and does not seem to 'retrace' what g-golf does, here is what g-golf-callback-closure-marshal does: it walks the ffi-args array, which by definition is an array of pointers (and by walking I mean it takes the address of the ffi-args array, treats its first arg, increment the 'walking pointer' by the size of a pointer and ...; for each, it calls <daviid>sneek later tell tohoyn the rest of your explaination is quite obscure, and does not seem to 'retrace' what g-golf does, here is what g-golf-callback-closure-marshal does: it walks the ffi-args array, which by definition is an array of pointers (and by walking I mean it takes the address of the ffi-args array, treats its first arg, increment the 'walking pointer' by the size of a pointer and ...; for each, it calls <daviid>ACTION should have done that before ... sorry for 'the mess' <rlb>latest run for it there <rlb>I've added a selective lsblk to the autoreconf stage, so I should be able to see that next time. <rlb>(i.e. see the fs type, etc.) <rlb>Of course past a certain point, unless we're going to make ports.test fancier, it's possible I should just mark it XFAIL for debian. <rlb>I think I have a tree here where I improved ports.test using some experience from bup wrt portability, but I wasn't sure whether we wanted it or not --- it runs df (differently depending on the platform) and parses the output to decide whether or not to run sparse tests. <rlb>...I'd actually forgotten about that work <hwpplayer1>Hello, I am working on a new shell language and Guile will be the extension language. <tohoyn>daviid: I sent you the ChatGPT PDF file by email <sneek>Welcome back tohoyn, you have 4 messages! <sneek>tohoyn, daviid says: the 1st sentence makes no sence, because there is no conversion from char* to char** in G-Golf callback - the ffi-args array is filled by the upstream lib - and 'even if it would', which it doesn't, how could that possibly be a feature of an upstream library? <sneek>tohoyn, daviid says: the chatgpt conversation link is empty for me (which I have next to zero interest to look at, but out of curiosity ...), it seems you need a gitlab account, I don't and never will create an account with gitlab.com <sneek>tohoyn, daviid says: last about this first sentence, about those upstream lib lines, I do not see how those would introduce a double reference, for utf8 args only - these lines seems to treat/deal with alignment 'problems', I am also not inytereste to read the libffi code ... fwiw <tohoyn>daviid: conversion from char* to char** occurs in the libffi library <tohoyn>daviid: as regards function ffi_closure_unix64_inner and string callback arguments, the call stack contains a char* pointer and argp points into the stack. hence argp and avalue[i] are char** pointers. <tohoyn>daviid: the G-Golf marshaller gets avalue as its third argument <tohoyn>daviid: ffi-arg-string->scm dereferences the pointer ffi-arg. ffi-arg points to a char** as the marshaller received it so. consequently the dereferencing results to a char**. now gi-string->scm constructs a string as if its argument were a char* even though it is actually char**. <daviid>tohoyn: that does not make sense, there is no 'conversion from *char to **char in the libffi - not as far as i can tell at least, and this would be a bug, not a feature - g-golf-callback-closure-marshal 3rd arg, as explained many times now, is the ffi-args array pointer <daviid>guile uses libffi, if what you claim was right, every binding to a C function that has one or more *char arg would fail <tohoyn>daviid: no, passing strings as char** applies only to callbacks (GIFFIClosureCallback) <tohoyn>daviid: for example, closures created with g_callable_info_create_closure <tohoyn>daviid: actually GIFFIClosureCallback is the type of the third argument to g_callable_info_create_closure <tohoyn>daviid: in our example, GIFFIClosureCallback is the type of the G-Golf marshaller <tohoyn>daviid: look at file ffi64.c: for a string argument, the callback contains a char* value and thus argp is a pointer to that value (char**) <tohoyn>daviid: s/callback contains/call stack contains/ <tohoyn>daviid: the ffi-args argument of g-golf-callback-closure-marshal is the array avalue in ffi64.c function ffi_closure_unix64_inner. The marshaller is called at line 902 in ffi64.c. <tohoyn>daviid: I close the connection now. I'll be back tomorrow. <daviid>tohoyn: i'll pass your statement and claim to the introspection room, let's see - I have to go afk for a few hours as well <lechner>Hi, should (system foreign), which implements native machine access, really be called "native"? Would it be consistent with the "native" naming in (rnrs bytevectors)? Thanks! <sneek>lechner, you have 1 message! <sneek>lechner, ArneBab says: can I add your point to the more 10x advantages? <mcarmo>heya folks! just found this channel <mcarmo>is there a nice resource for someone starting out with guile? I already know some of the ins and outs of scheme <mcarmo>uh damn haha, I hadn't checked the actual guile website at all <mcarmo>I've been going through reference manual yeah <mcarmo>but I see there are quite a lot of resources there <rlb>In the reference manual? If so, yes, it's fairly dense. <rlb>OK, hopefully debian riscv64's fixed now, and 3.0.11 will be able to migrate to forky/testing soon for all the architectures. <rlb>I just disabled the jit on riscv64 for now. Suppose we need a bug for it somewhere. <rlb>It *was* trivial to reproduce by just trying to build fibers. <rlb>well, build and then run the tests (which segfault, a lot) <lechner>mwette / Hi, what's a use case for Nyacc's #:inc-filter to be anything other than #t, please? <mwette>lechner: If you compile-ffi gobject you don't want everything from glib, stdio, stdlib, etc in the .scm. Usually you just want the gobject-speciic stuff. Check out some of the examples/*.ffi files. <mwette>for example, the glib.ffi module has an inc-filter to produce declarations only in the glib-2.0/glib and in glibconfig.h (buried down under /lib) <mwette>And there is a 'use-ffi-module' feature, so that gobject.scm (produced from gobject.ffi) can use the contents of glib.scm (produced from glib.ffi) <lechner>why do you provide access to preprocessor #defines via a symbol tab rather than outright defines in Scheme, please? <ArneBab>sneek: later tell dthompson: just listening to the beyond javascript talk again: Python on Guile by stis suddenly sounds much more powerful than before -- maybe finally a way to fix brython? <ArneBab>sneek: later tell stis: does python-on-guile support being hoot-compiled to wasm? <mwette>lechner: defines would generate too many global symbols IMO (namespace pollution) <lechner>mwette / Does the argument also hold when the generated FFI modules are imported with prefixes, as I usually do? <ArneBab>sneek: later tell stis: s/compile/compare/ <ArneBab>^ sorry for the first, the data was better than expected. <ArneBab>ACTION is looking for chances to get in. <ArneBab>⇒ it’s a 3x advantage, but still a reason to use Guile for those who need to get Python logic to the browser. <ArneBab>integrating python-on-guile into hoot compile-wasm (or more generally: first class language support) might be quite a big win. <ArneBab>does anyone know why python-on-guile isn’t packaged in guix? <mwette>lechner: prefixes are the helper for avoiding collisions; you could probably add code to the .ffi file to make defines for each item in the symbols alist, eigher using module reflection or using a macro <johnwcowan>lechner: the connection nakes sennse to me: yiu use "native" inbthe names of bytevector procedures to access the hardware representation of ints and floats <mcarmo>heya folks, quick question for geiser-guile users on emacs. is there a way to make it work with eldoc? <mcarmo>since it seems to use its own buffers to show documentation and stuff <ieure>mcarmo, I think your confusing eldoc and the various help-modes. <ieure>mcarmo, I haven't configured anything special, but I get argument signatures in the echo area when I put point in a procedure call. I don't know if it's using eldoc or something else, but it's equivalent to what eldoc gets you. <ieure>Not sure if it shows docstrings or not, those don't seem to be as common in Guile code as other Lisps I've used. <mcarmo>I might have phrased that kinda weird, sorry about that <mcarmo>but I'm referring to the buffer that pops up when you call geiser-doc-symbol-at-point <mcarmo>geiser doesn't rely on eldoc for that buffer, it seems. I use eldoc-box, which I quite like for seeing docs like this. the full buffer is kinda annoying <mcarmo>though admittedly since I typically work with geiser with the frame split in two, with the code on the left and the REPL on the right, it works out somewhat <daviid>sneek later tell tohoyn I patch g-golf, devel branch, added a comment in the source and did thank you in the commit - I am patching the adwaita demo to sync it with the upstream 1.8 version, then I should release, asap <Arsen>ACTION is looking forward to the video for the modern guile fosdem talk being uploaded