IRC channel logs


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>can you paste a snipset?
<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>large-digit-desc is a PangoFontDescription
<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 ...
<RhodiumToad>using font: instead (which takes a string) works
<RhodiumToad>(and yes, I use postfix keywords, bite me)
<daviid>but if you could paste a reproducible snipset, that would help ...
<RhodiumToad>just setting up a self-contained test, sec
<daviid>ok, bbl
<RhodiumToad>needs gtk3, pango, goocanvas2
<RhodiumToad>hm, paste is a bit tabdamaged
<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)
<RhodiumToad>all the other properties are simple values
<dsmith>sneek, botsnack
<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
<sneek>dsmith: Greetings :)
<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>normalization should be up to the user
<RhodiumToad>hm. slot-definition-options says #:g-type 3506135061353888 which is 'boxed according to g-type->symbol
<RhodiumToad>but I don't think that's right
<RhodiumToad>or maybe it is, but if it is, then this is wrong:
<RhodiumToad>(g-value-set! $13 (scm->g-property 35061353888 $5)) ;; where $5 is a pointer to a PangoFontDescription
<RhodiumToad>(g-value-get-boxed $13) ;; returns #<pointer 0x0>
<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>(cond ((!is-opaque? gi-boxed) %null-pointer)
<RhodiumToad>ding ding ding
<RhodiumToad>why in the nine hells is it doing that?
<RhodiumToad>anyway, that explains the bug: it stores any opaque struct pointer (and PangoFontDescription is opaque) into a GValue as NULL
<RhodiumToad>daviid: ^^
<RhodiumToad>(that's in g-value-set-boxed of course)
<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?
<RhodiumToad>ACTION would have expected 2
<RhodiumToad>ah, I see why
<RhodiumToad>(i.e. my fault, not yours)
<daviid>no problem -
<daviid>RhodiumToad: i pushed a fix for the g-value-set-boxed bug, please confirm it's ok now ... tx
<RhodiumToad>I just changed my code to work around it :-(
<RhodiumToad>I'll test it later
<RhodiumToad>anyway, this (incomplete) thing I was porting away from guile-gnome now works as well as the original did
<daviid>RhodiumToad: great
<daviid>RhodiumToad: it would be nice if you could try the fix though, in a real situation, here is what i do to test - - and - and to my surprise, $7 is a diff pointer then $6 ...
<RhodiumToad>it may be copying the object.
<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 ...
<RhodiumToad>ok. give me a sec.
<daviid>and i don't see what else i could do anyway, refering to the patch i mean ...
<RhodiumToad>doesn't look good
<RhodiumToad>let me check whether I made any mistakes
<RhodiumToad>gah. helps to do make install
<RhodiumToad>aha. _now_ that looks better.
<RhodiumToad>it's at least selecting the correct fonts for everything
<RhodiumToad>disconnecting a signal works too
<daviid>ok perfect, thanks
<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>I plan to try that with g-golf at some point
<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>ok, we'll seee :) - you might be interested to look at
<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> - ... (a-sync g-golf) - provides some convenience await procedures for the glib main loop using g-golf ...
<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 ...
<Wurt>Hi, I sent a few days ago this patch . Could someone check it? It is my first Guile patch and I do not know if it is wrong.
<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>So far so good
<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>string? is such a predicate
<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.
<graywolf>Thanks a lot :)
<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?
<ArneBab>graywolf: is there a chance that you could add to the documentation of match the examples that would have helped you?
<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)?
<apteryx>that would be very difficult indeed
<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>ACTION reads
<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
<tohoyn>sneek: botsnack
<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.