IRC channel logs
2023-09-04.log
back to list of logs
<daviid>RhodiumToad: i pushed a fix so signal-connect [and therefore connect, connect-after] return the handler-id <daviid>RhodiumToad: and pushed support for disconnect - let me know ... tx <RhodiumToad>hmm. if (make <some-object> prop: foo) isn't actually setting the property, how best to debug it? <RhodiumToad>other properties on the same object work, it's just one that doesn't <daviid>no typo in the prop name? it would not complain ... <RhodiumToad>this is from the library "GooCanvas", (make <goo-canvas-text> parent: root x: 32 y: 2 text: "0" font-desc: large-digit-desc fill-color: "blue) <RhodiumToad>I just finished digging through the GIBaseInfo stuff for the property lists, and font-desc is in the list of properties (for the parent class <goo-canvas-item-simple>) <RhodiumToad>printing the value of (!font-desc obj) shows a null pointer <daviid>ok, i can't look right now, but will later ... if in the meantime you find the cause, let me know ... <daviid>but if you could paste a reproducible snipset, that would help ... <daviid>tx, will look asap, but not 'now' ... <RhodiumToad>(it should display a large bold 0 somewhere roughly in the grey box, but in fact displays a smaller non-bold 0 from some default font) <RhodiumToad>maybe it's because the value is a pointer, rather than some sort of object? (at the C level it's a "struct" not a class) <sneek>I've been serving for one day and 9 hours <sneek>This system has been up 22 weeks, 1 day, 7 hours, 11 minutes <rlb>wingo: do I recall correctly that our internal representation should be (fully?) normalized? i.e. no combining chars, etc. Also wondered about char-level vs string level insensitivity, e.g. string_compare. <RhodiumToad>hm. slot-definition-options says #:g-type 3506135061353888 which is 'boxed according to g-type->symbol <RhodiumToad>(g-value-set! $13 (scm->g-property 35061353888 $5)) ;; where $5 is a pointer to a PangoFontDescription <rlb>Hmm, I don't know why I thought wingo had said something along those lines. In any case, I think I've mostly preserved what we have. <rlb>In any case, got string_compare (and all the funcs that depend on it) away from string_ref, so that's goo. <rlb>s/string_compare/compare_strings/ which has nothing to do with string-compare and scm_string_compare -- that's next up. <rlb>None of this should hold up anyone who wants to mess with the utf-8 branch -- just further optimizations since string-ref is more expensive now. (Still effectively O(N), with the index, but a bigger N.) <RhodiumToad>anyway, that explains the bug: it stores any opaque struct pointer (and PangoFontDescription is opaque) into a GValue as NULL <RhodiumToad>ACTION switches from using font-desc: to font: and achieves actual progress <daviid>RhodiumToad: nice, i'll fix that thanks <RhodiumToad>I'm getting 3 args in a 'button-press-event signal. is that expected? <daviid>RhodiumToad: i pushed a fix for the g-value-set-boxed bug, please confirm it's ok now ... tx <RhodiumToad>anyway, this (incomplete) thing I was porting away from guile-gnome now works as well as the original did <RhodiumToad>part of why boxed types exist is to be able to copy an object without knowing its implementation <daviid>that's what i hope, but it would be nice to confirm it works as expected in your app ... <daviid>and i don't see what else i could do anyway, refering to the patch i mean ... <RhodiumToad>it's at least selecting the correct fonts for everything <RhodiumToad>on balance, more of the changes I had to do to this (relatively simple) thing were to do with the change of canvas widget than with changing from guile-gnome to g-golf <RhodiumToad>(nobody does good canvas widgets except Tk, it's annoying) <daviid>what does your app do? do you plan to port to libadwaita/gtk-4 ? <RhodiumToad>probably not, it's more of a testing thing than anything else <RhodiumToad>I had a version of it that used shift/reset heavily that managed to crash guile-gnome <RhodiumToad>(basic idea is to do coroutine-like things by aborting back to the event loop when you need to update, with the continuation called from an idle event) <daviid>which the author tested using g-golf, with a working main-loop which worked for days (if not weeks i don't remember), no crash, no mem leaks ... <daviid>here, in debian testing, libadwaita 1.4 (beta) and gtk 4.12 landed today - so, appart from fixing the bugs you raise :) (thanks a lot for those), i will spend some time to update the g-golf adw1-demo to use AdwNavigationView (instead of the deprecated AdwLeaflet i mean ... <ArneBab>I just spotted srfi-128 for Guile in Guix: guile-srfi-128 — are there reasons why this isn’t merged into Guile core? <graywolf>Hello, I am trying to use (ice-9 match), but cannot figure out based on the info page how to do so. Pattern ('foo . bar) matches for example '(foo . xxx) and captures 'xxx into the bar. <graywolf>However, how can I restrict the type of bar? <rekado>(match thing (('foo . (? string? bar)) (pk 'bar-is-a-string bar))) <graywolf>Oh, I see. I so did not get that from the docs... Just to make sure I understand how it works, (? string? string bar) is the same (with the string not doing anything useful), and (? string? number bar) is correct syntax, but would never match? And (? string? bar baz) ensures it is string, and binds it to both bar and baz. <rekado>the (? …) introduces a predicate that must match <rekado>it can be any single-argument procedure <rekado>with (? string? string bar) you bind two values “string” and “bar” if both of them match the predicate “string?” <graywolf>oh I misunderstood the grammar; string refers to "string" for example, not to a `string'. I feel somewhat dumb. <rekado>the match documentation is pretty confusing <rekado>it’s one of those things that would benefit from a whole lot of simple and complex examples <apteryx>is everything used in a procedure definition guaranteed to be 'delayed' until the procedure execution? <graywolf>ArneBab: np, will send something, but will likely require few iterations on the patch <rlb>apteryx: roughly speaking, I think yes? Plus or minus any macro expansion-time activities. i.e. macros can do "anything" during expansion. <apteryx>can I delay a macro expansion? The problem I'm trying to resolve is that there are circular dependencies at the top level <apteryx>so I'd like to delay the expansion until all the modules have loaded... but that's probably not possible <rlb>I assume you can't restructure the relevant code/modules to eliminate the cycle(s)? <rlb>I suppose it depends on how much control you have, but I don't think the module system is really intended to handle cycles. And if that's the problem, i.e. that a's trying to load b and b's trying to load a, then I'd guess that's the only thing that matters (i.e. not macros specifically). But I haven't been following closely. <rlb>(fwiw, I restructure/rearrange modules now and then to avoid cycles when augmenting them in some of my projects...) <apteryx>this being Guix it's not always possible to avoid cycles between modules, as they express packages, and their own dependency relationship <jpoiret>apteryx: it's more a design choice of guix <jpoiret>each package could've had its own module <rlb>Not very familiar with guix yet, but yeah, then I'd assume it'd have to have some way to handle that. <apteryx>even if each package had its own module you'd still have cycles <rlb>i.e. I believe the debian resolvers have various mechanisms, and there's some policy around dpkg's handling wrt maintainerscript state graphs, etc. <jpoiret>apteryx: how so? we don't let packages have cycles in their dep graph <rlb>i.e. unless there's some other way to handle that with guile modules, can't just use guile modules. <jpoiret>tbh I think if we keep doing what we're doing it's going to get less and less usable <jpoiret>`guix pull` is getting slower day after day with all the new cycles being introduced <rlb>ACTION has been reading a lot of that policy lately to address some emacsen-common/policy bugs... <apteryx>jpoiret: I forgot, but civodul explained it somewhere <apteryx>I think the problems stems from 'inherit', which is not lazy <civodul>apteryx: yes, typically one should always inherit from a package defined in the same module <rlb>wingo: I'm toying with moving some of the string operations to scm. Compiler-wise, etc., are there likely to be (relevant) penalties to relying on say a C string-for-each for the bulk traversal, and then (local) scm-side closures that handle any other state, e.g. keeping track of the character index when that's needed.? <rlb>(I was leaning on string-for-each in this case to keep the C side simple, but could of course use a more flexible C "primitive".) <rlb>Any general rule of thumb for the cost of an escape via prompt? And/or is that our cheapest escape only mechanism? <rlb>Guess moving srfi-13 code to scheme won't work, at least not without other changes -- crashes the sandbox tests because the scheme-side functions don't exist in (guile), because (I think?) guile only loads srfi-13 via init.c calling the C-side init function. Anyway, not going to delve. Will set that aside for now. But I think it may eventually be feasible to implement a number of the srfi-13 functions in scheme in terms of some <rlb>C-side bulk primitives, hopefully without too much perf effect.