***berndj-blackout is now known as berndj
<spk121>rlb: you can check if a string is wide or narrow with (define (is-wide? x) (assv-ref (%string-dump x) 'stringbuf-wide)) <rlb>spk121: yeah - I'd imagine; but since I'm on the C side in this case, I can just use the scm_i_ calls. I was just speculating about whether we might be able to offer some supported way to do that, even if it might become less efficient if we change the internal representations some day. <rlb>But for now, I may just accept the risk of the scm_i_ calls... ***jonsger1 is now known as jonsger
<spk121>rlb: makes sense. There have been discussions of UTF-8 as the internal representation, someday <spk121>If we ever redo the internal representation, we could add in Perl's trick where the string representation also can represent both unicode codepoints and unencoded bytes. Emacs does something similar ***Server sets mode: +nt
<daviid>tohoyn: in g-golf, struct are <gi-struct> instances, not class <daviid>all 'struct' are cached under the 'boxed key, because some actually are 'seen' as 'boxed, not very sure why that is, but it happens that most of the time, GVlaue fundamental type tag for those will be 'boxed, not 'struct ... <daviid>some of these are opaque, or semi-opaque, which means g-golf won't (as it shouldn't) neither encode nor decode those, but 'blindingly' pass its pointer, and users must use the struct procedures and 'methods' api <daviid>but looking at (gi-import-by-name "Pango" "Attribute"), although it's not opaque nor semi-opaque, its name is wrong, and its registered type sems suspicious as well, not sure why, i'll ask on #introspection <daviid>tohoyn: so you may try (gi-import-by-name "Pango" "Attribute") - then use (describe $xx) to see its def/content, as see for yourself that the name is 'wrong' and the registered type is rather suspcious <daviid>tohoyn: it's probably ben imported already, it is cached under 'struct 'void, and that is a problem because qute a few struct/boxed will also have "void" as their registered name, I have to figure out why ... <daviid>tohoyn: to nswer a previous question, all methods of imported GObject subclass are always imported, so far though, using their long name only, getting their equicvalent short name method is on the todo list ... <daviid>*cached under 'boxed 'void, not 'struct 'void <tohoyn>daviid: is there going to be an alpha release of g-golf? ***apteryx is now known as Guest48020
***apteryx_ is now known as apteryx
<rbarraud>It's peak ADHD/imsomnia wide-awake time here. <rbarraud>RhodiumToad: Might even be up for some packagin' :-) <rbarraud>Weirdly. my Handbook seems to have evaporated... probably as a result of 'make install/deinstall/reinstall' of ports cascade from wanting Just One Simple Thing to work.... :;-/ <rbarraud>... @ least 12.1 is a bit kinder than the poor tired ol'11.x I replaced it with (after too long) <rbarraud>Also suspect I may have an MSG buzz on at the moment - Wonton noodle soup reheated from last nigght from local (best I've found here yet) Sichuan place. <rbarraud>Yup, we don't all live inside hillsides, have hairy feet or wear grass skirts down here... amazingly :-) <tohoyn>the argumen type descriptor of the third argument of procedure gtk-drag-dest-set is "(c -1 #f 2 interface)". What does it mean? <mwette>The objective is to look at object layouts to try to come up with something that could be common amoung a set of different language front-ends on to of Guile <rlb>spk121: I'd have to think about that -- the clearest handling I've seen so far of "reality" is rust's string vs osstring. I'm hoping that eventually Guile will be able to do something similar, i.e. so it can more cleanly handle paths, usernames, groups, etc. For now, I've just been trying to be very careful and "carry" them as iso-8859-1 (i.e. make sure they encode/decode via "narrow" strings). <rlb>sneek: later tell civodul my "clever" plan to make a more efficient pcre2 wrapper might not work out for common cases. So far it doesn't look like pcre2 can be asked to treat an ioso-8859-1 byte sequence as a unicode subset, i.e. for byte-width units, it looks like it can only do utf-8 or "not unicode" with differing behaviors. ***w2gz is now known as w1gz
***matijja``` is now known as matijja
<rlb>It'd be nice if we could eventually have better output when you accidentally create a use-modules dependency cycle. At the moment I just see indirect failures not obviously related to the problem and have to go hunting. ***jao is now known as Guest35264