IRC channel logs
2023-09-10.log
back to list of logs
<rlb>mwette: ok, assuming this test run works, I should be able to push something today -- test will take a while because I had to test some changes far enough back in the series (across the compiler / string format changes) that I have to bootstrap again. <mwette>no problem, just let me know when I can pull <rlb>Will do (should be a bit faster too, I suspect). <rlb>Hopefully fixes your issue, and some others. <mwette>rlb: thanks -- will try, maybe tomorrow <apteryx>neat, the hierarchical %load-verbosely improvement helped me understanding a cyclic module dependency <apteryx>is this warning expected during early bootstrap? ice-9/boot-9.scm:4692:35: warning: possibly unbound variable `syntax?' <apteryx>should patches be preferably sent to bug-guile or guix-devel? <apteryx>HACKING says guile-devel but it seems that could easily fall into cracks <mirai>apteryx: tape a note at the sides of the monitor <mirai>“remind me to remind someone else about a thread in guile-devel” <mirai>dungposting aside, I've voiced the same concern before though tbh guile-devel isn't getting a lot of posts (yet? ™) so it shouldn't get buried too soon <mirai>but you'll have to keep a note somewhere to inquire about it once in a while <daviid>RhodiumToad: is libadwaita 1.4.x (beta in debian) available in freebsd? <RhodiumToad>no port for it yet. x11-toolkits/libadwaita is version 1.3.4 <RhodiumToad>daviid: is there an example anywhere of creating a gobject subclass with new properties? <daviid>ok - i am porting the demo to use 1.4.0, nearly done - then i'll release 0.8.0-a.6 <daviid>RhodiumToad: actually the adw1-demo has one, but here - https://paste.centos.org/view/0eb1c75f - note that curretnly, it supposrts 'int, 'enum and 'object - obviously i can add the other types, and plan to do so 'now' [ after my port of the adwaita demo to 1.4.0 ] <daviid>RhodiumToad: if you need another property type let me know i can 'switch to do so' for you and push ... <daviid>not 'registered' ones i am afraid <daviid>but otherwise yes, then you do not 'expose' those slots as g-gproperty, would that not work for you ? <RhodiumToad>this would be specifically for property slots, so as to use GPropertyAction <daviid>ok - as a rule of thumb (anyway, not saying this to 'defend' a g-golf missing feature) i would avoid gobject when what you're deaking with can be implemented in scheme ... like ghash, glist ... unless forced to <daviid>fwiw, there is a slightly diff but yet similar example of such a string 'out of an enum' int value, in the adw1-demo - see the transition-row slot and its expression in (adw1-demo leaflet) - this 'overly compliacted' aproach, i'd never program this like this, i merely ported the example, has the objective to be able to display the translation of the enum value [mentioned in the coment line 121 [ the (adw1-demo leaflet) will be removed <daviid>*i would avoid glib/gobject/gio when what you're deaking with can be implemented in scheme ... <RhodiumToad>(add-from-file <gtk-builder> filename) is bombing out with Gtk-CRITICAL **: 06:27:37.394: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed <daviid>no, but there is an example of add-from-file in gtk-4 <daviid>ah - don't know, but maybe worth a looka t the gtk-4 example anyway, not all api changed ... <daviid>if/once you confident your code is ok, you may ask in #gtk [ just hide telling it is gtk-3 :) ], they may suggest/have an idea ... <RhodiumToad>it segfaults if trying to g_set_error due to an error in the input, though - is the GError param not being handled in a sane way? <daviid>maybe, never occured 'here' but ... have to leave now, be back tomorrow ... <waaay2meo4u>any way to limit the length of an exception's string output? megabyte long errors go into geiser's output buffer and emacs grinds to a halt on that <mwette>sneek: later tell rlb, the patch fixed issue01, and, as well as my code that reads includes from glib.h, gobject.h, pango.h, cairo.h, gdk.h, gtk.h, etc. and generates scheme ffi wrappers for all <minima>hi, if i have a record type <foo>, is there any way to introspect its field or even it's whole definition, other than looking at the original implementation / source code? <RhodiumToad>for native or srfi-9 records see record-type-fields, for rnrs records see (rnrs records inspection), for GOOPS see the whole "Introspection" chapter in the manual <minima>RhodiumToad: thank, yes, i primarily meant srfi-9 <apteryx>is there a means to validate if a variable is used at the top level or not? <apteryx>are modules loaded sequentially or in parallel? <apteryx>it looks sequential to me, but the output I see when encountering circular module dependency problems seems not to be caused by the last loaded module, so I'm puzzled <mwette>I think at least at once it was parallel. There were issues in guix wrt loading in parallel. civodul would remember. as for top-level variables, you might lok at the guile compiler (language/tree-il and language/cps) to see if there are warning about unused (private) variables. <rlb>For the record (and I might try to fix it myself if no one else gets to it first), check-guile is missing a dep on check-guile.in. i.e. if you edit the latter, nothing happens to the former until you manually remove it, or reconfigure. <sneek>Welcome back rlb, you have 2 messages! <sneek>rlb, mwette says: My heavy use of strings seems to be working w/ the new patch. This reads includes from glib.h, gobject.h, pango.h, cairo.h, gdk.h, gtk.h, etc. and generates scheme ffi wrappers for all. <sneek>rlb, mwette says: the patch fixed issue01, and, as well as my code that reads includes from glib.h, gobject.h, pango.h, cairo.h, gdk.h, gtk.h, etc. and generates scheme ffi wrappers for all <rlb>mwette: nice, and thanks for the testing. If it's a relevant amount of string mangling and you feel like it, be interesting to see how the relative "time ..." (or /usr/bin/time -v ...) values compare, as a coarse check. <rlb>mwette: finally got around to adding a patch that implements GUILE_RANDOM_STATE=(platform|INTEGER|none) and uses it to randomize (for now just) ./check-guile by default (chooses an integer, reports it and exports it). If that ends up being acceptable, should eventually be extended to cover all the tests (once I figure out how :) ). <rlb>(*slowly* working through the todo list...) <rlb>(Will also of course need docs, etc. if we end up allowing it.) <rlb>apteryx: unfortunately, I suspect I won't have time to review your changes in any detail, at least not for a good while, but from a quick glance, naively, I suspect we might not be able to change the arity of the publicly documented functions (hooks) without a "guile 4" (or deprecation period, or whatever the current policy is). <rlb>But of course, probably best to check to see if that's right before worrying about it. <rlb>If it is, then other arrangements might be needed (e.g. new hook or some other approach, or...) <mwette>rlb: I compiled gtk2.ffi -> gtk2.go, which reads a large number of includes, generates large .scm files and compiles them; good work! <rlb>great, and thanks again. <mwette>nominal guile: user/system time => 374.89/0.88 seconds; utf8: user/system => 302.73/0.85 seconds <rlb>Oh, it's *faster*? I wasn't actually hoping for that -- just not too much worse :) <mwette>20% reduction in time, and who knows what % of that is string-ops <rlb>If that's at all representative, I suppose it could mean my size/locality expectations might have even more of a positive impact than I thought, but just a wild guess. <mwette>it is heavy on (read-char <file-port>) (reverse-list->string <list>), pretty-print and simple-format <mwette>and a bit of (read-char <string>) <rlb>I think we might be able to do even better if we decide to drop in-place mutation entirely and implement the read-only stringbuf -> string optimization: if test -z "$GUILE_RANDOM_STATE"; then <rlb>And yeah, list->string and reverse-list->string are (I hope) medium-level optimized at this point. <mwette>note my "nom" case was actully 3.0.9 so I'm assuming there are no other major differences between your branch from main and 3.0.9 <rlb>hmm, yeah, not sure -- but good point. Could actually be stuff wingo's been doing :) <rlb>I also think there could be a reasonable amount of room for optimization on the C/intrinsics utf-8 wrangling front, if we decide it's worth the effort (and if gcc's optimizer isn't already way ahead of us, which it might be). In particular, I don't know how clever libunistring is in the cases we care about. <rlb>And if it's not, could also consider just trying to help hack on libunistring. <mwette>ACTION needs to reboot ... back later <apteryx>rlb: hi, thanks for the early comments; the current approach is to preserve the backward compatibility of existing hooks -- if that's not necessary we can't streamline the new defs in load.c away (the error handling part / fall-back to scm_call_1) <rlb>Oh, do you try to figure out the arity of the existing hook? <rlb>If so, I hadn't noticed (clearly). <apteryx>I just call with scm_call_2, if that fails with a wrong-args-number exception, retry with scm_call_1 <apteryx>it's a bit verbose to do just that on the C side <rlb>Hmm, OK. By default, I might guess that people will want to avoid an exception for every invocation with all the existing hooks, but not sure. I wonder if we already do that elsewhere for backward compatibility... <rlb>Anyway, no worries, just happened to wonder about it during a quick scan. <rlb>Anyone know of any general "string-heavy" scheme benchmarks? I also wondered if there might be relevant big/complex srfi test suites out there, or similar... <rlb>Oh, right, I'd actually seen some, just forgotten. Might have something reasonable to try. <dsmith>I was just looking to see if I could contact him a few days ago.. <dsmith>He didn't always agree with the guile maintainers (kept his own fork alaive for years), but he has this subtle, witty, enigmatic writing style in his emails that Iw as really drawn to. <dsmith>I would have liked to have known him better.. <xiews>He was very kind, and replied my emails as we had knew each other. Sad.