IRC channel logs

2026-03-31.log

back to list of logs

<tohoyn>daviid: I may have found the reason of the layout-manager-2 bug: Fields surface->device_transform.x0 and surface->device_transform.y0 are not initialized in function cairo_surface_set_device_scale.
<tohoyn>daviid: furthermore, the error (singular matrix) seems to occur when y_scale is 0.0.
<tohoyn>daviid: when x_scale or y_scale is 0.0 the matrix becomes singular. so the question is where do the zero scale values come from.
<rlb>wingo: the current utf8 branch code relies on scm_gc_malloc* in various places as a fallback when a given function's work is "too big" for the stack (say > 512 bytes or 1024 or whatever), and it doesn't always explicitly free those "local" allocations. Is that "fine" wrt whippet, or is there some happier path I should prefer if I decide to revise those functions further?
<rlb>(The current approach of course simplifies (and maybe cheapens?) the error handling for the functions that are more complex.)
<jcowan>rlb: Presumably when the stack is popped these things are no longer pointed to, and the gc will reclaim them.
<old>it depends if whippet is in conservative mode I guess?
<old>IIRC, there are multiple mode one can select from
<old>not sure if I would qualified 512 bytes to be too much for stack work
<old>To me, you can easily scale that to at least 1 Mb before it's too much
<old>if no recursion ofc
<ArneBab>sneek: later tell civodul: thank you!
<sneek>Okay.