IRC channel logs

2024-05-04.log

back to list of logs

<daviid> FlaminWa`: wrt to your goops quiz, you should use ensure-generic, see "8.11.9 Generic Function Internals"
<daviid>mwette: i don't know, but you might want to look at /libguile/gsubr.h and ./libguile/programs.h
<daviid>mwette: in this paste, i think you miss an argument to the g_object_get_type call(?)
<daviid>g_object_new needs a valid GType (those that can be instantiated ...)
<daviid>and affaict only takes one arg?
<daviid>mwette: as in (g-object-new (g-type-from-name "GObject"))\n $7 = #<pointer 0x56192c5df000>
<mwette>daviid: right: all the get_type calls are thunks that return a GType (aka unsigned-long); e.g., extern GType g_object_get_type(void);
<mwette>daviid: I'm not using g-golf or gi-guile, if that's what you mean.
<daviid>mwette: no, i was tryting to help knowing you do not ... can you just try (g_object_new 80)
<daviid>g_object_get_type is not in (public api of the) GObject ref man - https://docs.gtk.org/gobject/method.Object.bind_property.html?q=g_object_get_type
<daviid>and with the def you give in the paste, i dont see how it can possibly return a valid instantiable GType, just curious
<mwette>here is sample of what I'm doing: https://paste.debian.net/1315978/
<mwette>If I call (g_object_get_type) it returns 80
<mwette>this is gtk2+ btw
<mwette>I think something is hosed in the class registration.
<mwette>I'm using ffi-helper w/ scheme-bytestructures.
<mwette>I think I may see the problem.
<daviid>ah ok, so (g_object_new (g_object_get_type) %null-pointer) should work indeed then
<daviid>mwette: fwiw, the GI team did recommend me to use size_t, not unsigned_long, a while ago, i forgot the details of the discussion, but i did take some notes about this ... would need to dig
<mwette>I believe that. The ffi-helper uses whatever is defined in the headers, which must be unsigned long.
<mwette>GType is typedef'd from gsize, and gsize is typedef'd from unsigned long.
<mwette>If you want to see what example Gtk2+ C code looks like with all the C macros expanded, and then cleaned up, check here: https://github.com/mwette/probing-gobject
<daviid>mwette: i highly recommend you patch the ffi-helper so it uses size_t as the GType C type, but do as you wish ofc
<mwette>The ffi-helper is a black box. If unsigned long is bad, this is a case of garbage in, garbage out. On x86_64, size_t and unsigned long are both unsigned 8-byte integers.
<daviid>mwette: don't you have an override mechanism in the ffi-helper? anyway, yes it will work for most 'situations', but there are arch and/or platforms where that is not the case ... so was i told ... then i patched g-golf, as all other GI lang bindings did to, fwiw
<mwette>daviid: I believe you. So, you're saying that's a bug in glib.h. I could try to change the glib.ffi spec so that is changes gsize def from unsigned long to ssize_t.
<daviid>mwette: no, i ean to say that in ythis paste, and any such guile ffi calls that would use a GType arg, you should pass size_t (not ssize_t, but not sure it is a typo in your text or an existing type :))
<daviid>mwette: your paste here - https://paste.debian.net/1315972/
<mwette>daviid: That code was to isolate the bug I was running into. It's hard to belive that could be a problem when /usr/include/glib-2.0/gobject/gtype.h defines GType to be an unsigned long.
<daviid>i was not saying it was the reason why your pasted code was not working, i was just sharing with you that those who wrote /usr/include/glib-2.0/gobject/gtype.h did recommend GI lang bindings authors to define GType as a size_t - so did i immediately patch g-golf ... do as you wish, but it will fail on sone platform, so was i told ...
<mwette>OK. Got it now. Thanks. To fix, I would try adding "gsize=size_t" to the ffi-helper #cpp-defs option.
<daviid>mwette: wrt "... how gobject finds an interface given a class.", i don't know how GObject itself does that in its 'engine', but iiuc your quiz, in g-golf, i defined g-type-interfaces procedure, which retrieves the GType list of the interfaces used by a GObject (sub)class, then use/call g_type_interface_peek to retreive its (pointer to) structure ... if that helps
<daviid>mwette: i am a bit scared that you would change the gsize def, and not the GType def, they might be cases where gsize is used and meant to be an unsigned_loing ... i am not competent enough here, please ask in #introspection (matrix room, they left irc a while ago)
<daviid>mwette: if its help, here - https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/gobject/type-info.scm?h=devel#n147
<daviid>*it helps
<mwette>thanks; I'll check it out
<cow_2001>is it at all possible to use (srfi srfi-9 gnu)'s set-fields to change a field whose value is a vector? maybe with getter-with-setter?
<rlb>cow_2001: offhand I'd assume only if you want to replace the whole vector with some other vector. i.e. not if you mean setting individual values, a la clojure's assoc-in where you can "traverse" vector sub-components via their indices...
<rlb>e.g. (assoc-in {:x [0 {:y 1}]} [:x 1 :y] 2) => {:x [0 {:y 2}]}
<cow_2001>what i'm thinking of is something like (set-fields foo ((foo-vector (vector-field 2)) new-value))
<declan>Can someone help me with this regex in Scheme https://bpa.st/TFFQ ? The regex works here https://regex101.com/r/4bu2m1/1 .
<sneek>declan, you have 1 message!
<sneek>declan, vagrantc says: glad to hear you're enjoying guix, welcome to the community!
<cow_2001>where foo is a (make-foo (make-vector 8 0))
<rlb>declan: guile's regexes do "whatever the platform does" (I'd prefer we eventually provide something stable -- pcre or whatever, if we can.)
<rlb>declan: I suspect "man 7 regex" will give you your local syntax.
<rlb>And also suspect it just doesn't support some of what you have there.
<rlb>(stable/standardized across platforms)
<rlb>s/standardized/the same/
<rlb>Hmm, or maybe we do that, i.e. if you have regex support, it's always defined to be POSIX?
<declan>I don't know. Got an error: `No manual entry for regex in section 7`
<rlb>Hmm, might need to install the relevant manpages. In debian it's in "manpages".
<rlb>But this may also be reasonably accurate: https://pubs.opengroup.org/onlinepubs/9699919799/
<rlb>See the "as described in"...
<rlb>link
<declan>I am using Guix BTW. I am not so familiar with regex in general.
<Kolev>We Guix should take over the "I use BTW" meme.
<declan>Thank you. Will read the link.
<rlb>I would guess that \d might not be in posix (I forget), if so, you might just need to replace those with [0-9]
<rlb>ACTION is much more familiar with jvm/perl(pcre)/python rx.
<rlb>Oh, and I believe guile defaults to the "extended" flavor, when you're reading those docs.
<rlb>(also bet there's a guix way to get those manpages)
<rlb>regex(7) etc.
<declan>What is \. in Posix?
<rlb>An actual dot, I think, i.e. not a wildcard.
<rlb>But note that if you're typing scheme code, you'll need a double backslash for each one to make it through to the eventual string, i.e. "\\." or whatever -- if you mean a literal dot.
<rlb>Oh, right, that's at least part of your issue.
<rlb>Just tried it, and the error you're seeing is what you get for that.
<declan>Thanks. Will try this later.
<rlb>Try, for example just "\." in the repl -- that doesn't work because \. is not a string escape. But "\"" does, and gives you a string containing just a double-quote.
<rlb>e.g. "this is \"exciting\", no?"
<graywolf>Hello :) How can I use (case) to compare symbols? (case 'x (('x) #t)) this complains that (quote x) cannot be meaningfully compared using eqv?.
<graywolf>Is there a way to check symbols using (case)?
<dsmith>You do not need to quote the cases.
<dsmith>scheme@(guile-user)> (case 'x ((x) #t))
<dsmith>$1 = #t
<ArneBab>mwette: I saw it now — thank you!
<graywolf>Aaaah I see, thanks :)
<mwette>ArneBab: yw
<graywolf>Hm, how can I get current buffering behavior of a port? There does not seem not seem to be getvbuf.
<dthompson>david wilson's keynote for libreplanet is going to start soon
<dthompson>if you don't know he's a big guile/guix fan
<dthompson> https://libreplanet.org/2024/live/
<dthompson>and he built his slide deck with guile!
<ggoes>just started
<daviid>is there a way to temporarily 'block' the gc to 'enter in action'? i'd like to test running a g-golf based example in guix, blocking the gc and see if that 'solves' the bug i am tracking
<old>daviid: I do not think that this is possible without leaving Guile context, thus not executing scheme code
<old>Although it would be possible, just not implemented