call_end

    • chevron_right

      Christian Hergert: Manuals on libfoundry

      news.movim.eu / PlanetGnome • 25 April

    I finally got around this past week to getting Manuals ported to libfoundry .

    That was something I wanted to do early so that I can rapidly get away from 3 versions of the documentation engine and Flatpak SDK management code. Currently it existed in Manuals, Builder, and Foundry, and soon we’ll get it to just Foundry.

    That also makes Manuals the first application to use libfoundry which resulted in lots of tree-shaking and things are looking bright! I very much look forward to getting Builder rebased on libfoundry .

    While I was at it, I ticked off a number of requested design issues as part of the Incubator submission . This afternoon it also got support for narrow views meaning you can run it on a GNOME-enabled phone.

    Probably not how most people will use it, but hey, maybe you have actually good public transportation where you are and some free time.

    Using the SDK documentation installation dialog. The Nightly SDK documentation is actively installing.

    Browsing Adwaita documentation inside the Manuals app. The page on button styles is displayed.

    • wifi_tethering open_in_new

      This post is public

      blogs.gnome.org /chergert/2025/04/25/manuals-on-libfoundry/

    • chevron_right

      Allan Day: On Elephants

      news.movim.eu / PlanetGnome • 25 April • 9 minutes

    This post is a response to what Tobias posted yesterday on his blog . I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are.

    For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen.

    The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later.

    I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room.

    The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation.

    The big elephant

    In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. His description of the chain of events is both misleading and a misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation.

    My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion.

    I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient.

    The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with.

    Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else.

    No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on.

    However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure.

    The other elephant

    The other part of Tobias’s post addresses the performance of the Foundation.

    He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex.

    One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off [1]. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped.

    This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah!

    Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time.

    Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post , which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements.

    On resignations

    From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors.

    Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it.

    And if people think we should have different directors, well, that’s what the elections are for.

    Closing

    Readers might wonder why the Foundation has not spoken publicly about this topic (reminder: I’m not speaking on behalf of the Foundation here). The main reasons are confidentiality and legal concerns. We also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are.

    It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful.

    Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

    [1] Edit: we were extremely lucky to have Richard Littauer as interim ED for the second half of 2024, and he did a huge amount. However, Richard was only working for us part-time, so was unable to deliver on strategic initiatives.

    • wifi_tethering open_in_new

      This post is public

      blogs.gnome.org /aday/2025/04/25/on-elephants/

    • chevron_right

      Allan Day: On Elephants

      news.movim.eu / PlanetGnome • 25 April • 9 minutes

    This post is a response to what Tobias posted yesterday on his blog . I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are.

    For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen.

    The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later.

    I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room.

    The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation.

    The big elephant

    In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. There’s a chain of events he presents which is misleading and a is misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation.

    My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion.

    I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient.

    The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with.

    Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else.

    No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on.

    However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure.

    The other elephant

    The other part of Tobias’s post addresses the performance of the Foundation.

    He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex.

    One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped.

    This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah!

    Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time.

    Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post , which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements.

    On resignations

    From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors.

    Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it.

    And if people think we should have different directors, well, that’s what the elections are for.

    Closing

    Readers might wonder why the Foundation has not spoken publicly about this topic before. The main reasons were confidentiality and legal concerns. We have also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are.

    It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful.

    Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

    • wifi_tethering open_in_new

      This post is public

      blogs.gnome.org /aday/2025/04/25/on-elephants/

    • chevron_right

      Jiri Eischmann: Hiring for Flatpak Automation

      news.movim.eu / PlanetGnome • 25 April

    The desktop team in Red Hat has another open position . We’re looking for someone to work on Flatpak automation, for someone who enjoys working on infrastructure. Although the job description states 2+ years of experience, it’s suitable for juniors. Formal experience can be replaced by relevant open source contributions. Being onsite in Brno, Czech Republic is preferred, but not required. We’re open to hiring good candidates elsewhere, too.

    If you’d like to know more about the job before formally applying, don’t hesitate to contact me on Mastodon , Signal , Matrix (@eischmann at fedora.im), or email .

    • wifi_tethering open_in_new

      This post is public

      enblog.eischmann.cz /2025/04/25/hiring-for-flatpak-automation/

    • chevron_right

      Jiri Eischmann: Hiring for Flatpak Automation

      news.movim.eu / PlanetGnome • 25 April

    The desktop team in Red Hat has another open position . We’re looking for someone to work on Flatpak automation, for someone who enjoys working on infrastructure. Although the job description states 2+ years of experience, it’s suitable for juniors. Formal experience can be replaced by relevant open source contributions. Being onsite in Brno, Czech Republic is preferred, but not required. We’re open to hiring good candidates elsewhere, too.

    If you’d like to know more about the job before formally applying, don’t hesitate to contact me on Mastodon , Signal , Matrix (@eischmann at fedora.im), or email .

    • wifi_tethering open_in_new

      This post is public

      enblog.eischmann.cz /2025/04/25/hiring-for-flatpak-automation/

    • chevron_right

      Andy Wingo: partitioning ambiguous edges in guile

      news.movim.eu / PlanetGnome • 25 April • 5 minutes

    Today, some more words on memory management, on the practicalities of a system with conservatively-traced references.

    The context is that I have finally started banging Whippet into Guile , initially in a configuration that continues to use the conservative Boehm-Demers-Weiser (BDW) collector behind the scene. In that way I can incrementally migrate over all of the uses of the BDW API in Guile to use Whippet API instead, and then if all goes well, I should be able to switch Whippet to use another GC algorithm, probably the mostly-marking collector (MMC) . MMC scales better than BDW for multithreaded mutators, and it can eliminate fragmentation via Immix-inspired optimistic evacuation.

    problem statement: how to manage ambiguous edges

    A garbage-collected heap consists of memory, which is a set of addressable locations. An object is a disjoint part of a heap, and is the unit of allocation. A field is memory within an object that may refer to another object by address. Objects are nodes in a directed graph in which each edge is a field containing an object reference. A root is an edge into the heap from outside. Garbage collection reclaims memory from objects that are not reachable from the graph that starts from a set of roots. Reclaimed memory is available for new allocations.

    In the course of its work, a collector may want to relocate an object, moving it to a different part of the heap. The collector can do so if it can update all edges that refer to the object to instead refer to its new location. Usually a collector arranges things so all edges have the same representation, for example an aligned word in memory; updating an edge means replacing the word’s value with the new address. Relocating objects can improve locality and reduce fragmentation, so it is a good technique to have available. (Sometimes we say evacuate, move, or compact instead of relocate; it’s all the same.)

    Some collectors allow ambiguous edges: words in memory whose value may be the address of an object, or might just be scalar data. Ambiguous edges usually come about if a compiler doesn’t precisely record which stack locations or registers contain GC-managed objects. Such ambiguous edges must be traced conservatively : the collector adds the object to its idea of the set of live objects, as if the edge were a real reference. This tracing mode isn’t supported by all collectors.

    Any object that might be the target of an ambiguous edge cannot be relocated by the collector; a collector that allows conservative edges cannot rely on relocation as part of its reclamation strategy. Still, if the collector can know that a given object will not be the referent of an ambiguous edge, relocating it is possible.

    How can one know that an object is not the target of an ambiguous edge? We have to partition the heap somehow into possibly-conservatively-referenced and definitely-not-conservatively-referenced. The two ways that I know to do this are spatially and temporally.

    Spatial partitioning means that regardless of the set of root and intra-heap edges, there are some objects that will never be conservatively referenced. This might be the case for a type of object that is “internal” to a language implementation; third-party users that may lack the discipline to precisely track roots might not be exposed to objects of a given kind. Still, link-time optimization tends to weather these boundaries, so I don’t see it as being too reliable over time.

    Temporal partitioning is more robust: if all ambiguous references come from roots, then if one traces roots before intra-heap edges, then any object not referenced after the roots-tracing phase is available for relocation.

    kinds of ambiguous edges in guile

    So let’s talk about Guile! Guile uses BDW currently, which considers edges to be ambiguous by default. However, given that objects carry type tags, Guile can, with relatively little effort, switch to precisely tracing most edges. “Most”, however, is not sufficient; to allow for relocation, we need to eliminate intra-heap ambiguous edges, to confine conservative tracing to the roots-tracing phase.

    Conservatively tracing references from C stacks or even from static data sections is not a problem: these are roots, so, fine.

    Guile currently traces Scheme stacks almost-precisely: its compiler emits stack maps for every call site, which uses liveness analysis to only mark those slots that are Scheme values that will be used in the continuation. However it’s possible that any given frame is marked conservatively. The most common case is when using the BDW collector and a thread is pre-empted by a signal; then its most recent stack frame is likely not at a safepoint and indeed is likely undefined in terms of Guile’s VM. It can also happen if there is a call site within a VM operation, for example to a builtin procedure, if it throws an exception and recurses, or causes GC itself. Also, when per-instruction traps are enabled, we can run Scheme between any two Guile VM operations.

    So, Guile could change to trace Scheme stacks fully precisely, but this is a lot of work; in the short term we will probably just trace Scheme stacks as roots instead of during the main trace.

    However, there is one more significant source of ambiguous roots, and that is reified continuation objects. Unlike active stacks, these have to be discovered during a trace and cannot be partitioned out to the root phase. For delimited continuations, these consist of a slice of the Scheme stack. Traversing a stack slice precisely is less problematic than for active stacks, because it isn’t in motion, and it is captured at a known point; but we will have to deal with stack frames that are pre-empted in unexpected locations due to exceptions within builtins. If a stack map is missing, probably the solution there is to reconstruct one using local flow analysis over the bytecode of the stack frame’s function; time-consuming, but it should be robust as we do it elsewhere.

    Undelimited continuations (those captured by call/cc ) contain a slice of the C stack also, for historical reasons, and there we can’t trace it precisely at all. Therefore either we disable relocation if there are any live undelimited continuation objects, or we eagerly pin any object referred to by a freshly captured stack slice.

    fin

    If you want to follow along with the Whippet-in-Guile work, see the wip-whippet branch in Git. I’ve bumped its version to 4.0 because, well, why the hell not; if it works, it will certainly be worth it. Until next time, happy hacking!

    • wifi_tethering open_in_new

      This post is public

      wingolog.org /archives/2025/04/25/partitioning-ambiguous-edges-in-guile

    • chevron_right

      Andy Wingo: partitioning ambiguous edges in guile

      news.movim.eu / PlanetGnome • 25 April • 5 minutes

    Today, some more words on memory management, on the practicalities of a system with conservatively-traced references.

    The context is that I have finally started banging Whippet into Guile , initially in a configuration that continues to use the conservative Boehm-Demers-Weiser (BDW) collector behind the scene. In that way I can incrementally migrate over all of the uses of the BDW API in Guile to use Whippet API instead, and then if all goes well, I should be able to switch Whippet to use another GC algorithm, probably the mostly-marking collector (MMC) . MMC scales better than BDW for multithreaded mutators, and it can eliminate fragmentation via Immix-inspired optimistic evacuation.

    problem statement: how to manage ambiguous edges

    A garbage-collected heap consists of memory, which is a set of addressable locations. An object is a disjoint part of a heap, and is the unit of allocation. A field is memory within an object that may refer to another object by address. Objects are nodes in a directed graph in which each edge is a field containing an object reference. A root is an edge into the heap from outside. Garbage collection reclaims memory from objects that are not reachable from the graph that starts from a set of roots. Reclaimed memory is available for new allocations.

    In the course of its work, a collector may want to relocate an object, moving it to a different part of the heap. The collector can do so if it can update all edges that refer to the object to instead refer to its new location. Usually a collector arranges things so all edges have the same representation, for example an aligned word in memory; updating an edge means replacing the word’s value with the new address. Relocating objects can improve locality and reduce fragmentation, so it is a good technique to have available. (Sometimes we say evacuate, move, or compact instead of relocate; it’s all the same.)

    Some collectors allow ambiguous edges: words in memory whose value may be the address of an object, or might just be scalar data. Ambiguous edges usually come about if a compiler doesn’t precisely record which stack locations or registers contain GC-managed objects. Such ambiguous edges must be traced conservatively : the collector adds the object to its idea of the set of live objects, as if the edge were a real reference. This tracing mode isn’t supported by all collectors.

    Any object that might be the target of an ambiguous edge cannot be relocated by the collector; a collector that allows conservative edges cannot rely on relocation as part of its reclamation strategy. Still, if the collector can know that a given object will not be the referent of an ambiguous edge, relocating it is possible.

    How can one know that an object is not the target of an ambiguous edge? We have to partition the heap somehow into possibly-conservatively-referenced and definitely-not-conservatively-referenced. The two ways that I know to do this are spatially and temporally.

    Spatial partitioning means that regardless of the set of root and intra-heap edges, there are some objects that will never be conservatively referenced. This might be the case for a type of object that is “internal” to a language implementation; third-party users that may lack the discipline to precisely track roots might not be exposed to objects of a given kind. Still, link-time optimization tends to weather these boundaries, so I don’t see it as being too reliable over time.

    Temporal partitioning is more robust: if all ambiguous references come from roots, then if one traces roots before intra-heap edges, then any object not referenced after the roots-tracing phase is available for relocation.

    kinds of ambiguous edges in guile

    So let’s talk about Guile! Guile uses BDW currently, which considers edges to be ambiguous by default. However, given that objects carry type tags, Guile can, with relatively little effort, switch to precisely tracing most edges. “Most”, however, is not sufficient; to allow for relocation, we need to eliminate intra-heap ambiguous edges, to confine conservative tracing to the roots-tracing phase.

    Conservatively tracing references from C stacks or even from static data sections is not a problem: these are roots, so, fine.

    Guile currently traces Scheme stacks almost-precisely: its compiler emits stack maps for every call site, which uses liveness analysis to only mark those slots that are Scheme values that will be used in the continuation. However it’s possible that any given frame is marked conservatively. The most common case is when using the BDW collector and a thread is pre-empted by a signal; then its most recent stack frame is likely not at a safepoint and indeed is likely undefined in terms of Guile’s VM. It can also happen if there is a call site within a VM operation, for example to a builtin procedure, if it throws an exception and recurses, or causes GC itself. Also, when per-instruction traps are enabled, we can run Scheme between any two Guile VM operations.

    So, Guile could change to trace Scheme stacks fully precisely, but this is a lot of work; in the short term we will probably just trace Scheme stacks as roots instead of during the main trace.

    However, there is one more significant source of ambiguous roots, and that is reified continuation objects. Unlike active stacks, these have to be discovered during a trace and cannot be partitioned out to the root phase. For delimited continuations, these consist of a slice of the Scheme stack. Traversing a stack slice precisely is less problematic than for active stacks, because it isn’t in motion, and it is captured at a known point; but we will have to deal with stack frames that are pre-empted in unexpected locations due to exceptions within builtins. If a stack map is missing, probably the solution there is to reconstruct one using local flow analysis over the bytecode of the stack frame’s function; time-consuming, but it should be robust as we do it elsewhere.

    Undelimited continuations (those captured by call/cc ) contain a slice of the C stack also, for historical reasons, and there we can’t trace it precisely at all. Therefore either we disable relocation if there are any live undelimited continuation objects, or we eagerly pin any object referred to by a freshly captured stack slice.

    fin

    If you want to follow along with the Whippet-in-Guile work, see the wip-whippet branch in Git. I’ve bumped its version to 4.0 because, well, why the hell not; if it works, it will certainly be worth it. Until next time, happy hacking!

    • wifi_tethering open_in_new

      This post is public

      wingolog.org /archives/2025/04/25/partitioning-ambiguous-edges-in-guile

    • chevron_right

      This Week in GNOME: #197 XML Parsing

      news.movim.eu / PlanetGnome • 25 April • 2 minutes

    Update on what happened across the GNOME project in the week from April 18 to April 25.

    GNOME Core Apps and Libraries

    Software

    Lets you install and update applications and system extensions.

    Philip Withnall announces

    Owen Chiaventone has done some useful profile-guided optimisation of XML parsing in gnome-software (which happens every time repository metadata is updated), and found a few improvements to make; https://gitlab.gnome.org/GNOME/gnome-software/-/issues/941#note_2417546

    Glycin

    Sandboxed and extendable image loading and editing.

    Sophie 🏳️‍🌈 🏳️‍⚧️ (she/her) reports

    More progress on our quest to move away from GdkPixbuf . Glycin now provides a thumbnailer that can be used to create thumbnails for all image formats for which glycin loaders are installed. This is already resulting in more supported image formats, correct support of color profiles, better support for image that have a higher bit depth than 8-bit, better support for Exif orientations, and memory safe implementation for most of the formats. You can see a comparison for some images with a before (left) and after with glycin thumbnailer (right) on the screenshot below.

    This is not properly implemented for GNOME OS yet, but we are on it .

    GNOME Circle Apps and Libraries

    ashpd

    Rust wrapper around freedesktop portals.

    Bilal Elmoussaoui reports

    I have released a new version of ASHPD Demo , the app for testing portals. The release adds support of the USB and Global Shortcut portals contributed with STF support.

    Third Party Projects

    xjuan says

    I am happy to announce a new Cambalache release! Version 0.96.0 – GResource Release! * Add GResource support * Add internal children support * New project format * Save directly to .ui files * Show directory structure in navigation * Add Notification system (version, messages and polls) * Unified import dialog for all file types * Update widget catalogs to SDK 48 Read more about it at https://blogs.gnome.org/xjuan/2025/04/20/cambalache-0-96-released/

    sunniva announces

    After a long period of inactivity, Stockpile 0.5.0 has been released. This release brings the application to the GNOME 48 runtime, as well as improving user experience with a new start screen and the ability to recover corrupted data. See more information about this release on Flathub!

    Pipeline

    Follow your favorite video creators.

    schmiddi says

    Pipeline version 2.2.0 until 2.2.2 were released this week. Starting from this version, Pipeline will now use all Piped instances configured in the settings in parallel to query the feed. This leads to a massive speedup for querying your feed when you have multiple instances configured (for my subscription list, this was a 7x speedup). Along this line, the Piped instance list is now managed by Pipeline automatically, which downloads a list of working instances on every startup. This should lead to a more reliable experience, and does not require manually finding working instances anymore. A bug was also fixed, where different videos replaced each other in the watch later list when they were uploaded at approximately the same time.

    Flare

    Chat with your friends on Signal.

    schmiddi announces

    Flare version 0.16.0 was released. This release adds initial support for receiving stickers.

    Miscellaneous

    Philip Withnall reports

    Maximiliano added support for storing your GitLab token in libsecret when you use gitlab-changelog to write NEWS entries for a release, https://gitlab.gnome.org/pwithnall/gitlab-changelog/-/merge_requests/22

    That’s all for this week!

    See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

    • chevron_right

      Georges Basile Stavracas Neto: Boatswain 5.0

      news.movim.eu / PlanetGnome • 24 April • 4 minutes

    After more than an year after, Boatswain 5.0 is finally out. It took me a long time to push it to the finish line, but I’m relatively happy with how it turned out, and it brings some nice features.

    Let’s take a quick look at what’s new in this release!

    New Devices

    Stream Deck Plus (black)
    Stream Deck Neo (white)

    Boatswain 5.0 comes with support for 2 new device models from Elgato: Stream Deck Plus , and Stream Deck Neo .

    Support for Elgato Stream Deck Plus came after the massively successful fundraising campaign from last year. A huge thanks to everyone that contributed to it!

    As for Elgato Stream Deck Neo, I tentatively introduced support for it without actually having a device to test, so if there’s anyone out there that can test it, that’d be absolutely appreciated.

    Support for Stream Deck Plus was probably the main reason it took so long to release Boatswain 5.0. The entirety of the app was originally written under the assumption that all devices were simply a grid of buttons. Introducing a touchscreen, and dials that act as buttons, required basically rewriting most of the app.

    I used this opportunity to make Boatswain able to handle any kind of device, with any kind of layout. Everything is represented as regions in a grid layout. Simple Stream Deck devices just contain a button grid; Stream Deck Plus contains a button grid, a touchscreen, and a dial grid.

    Keyboard Shortcuts

    The new Keyboard Shortcut action allows executing any keyboard shortcut – or any keyboard event in general – on the desktop. This seems to work better than I could have anticipated!

    Under the hood, this action uses the Remote Desktop portal be able to inject input on the desktop. Locally controlling the desktop was probably not on the original goals of the portal, but alas, it fit the use case perfectly!

    Paired with folders, Keyboard Shortcuts are very powerful, especially for large and complex software with a large number of shortcuts.

    Next Steps

    This release might be a little disappointing as it took so long, and yet didn’t come as packed with new features. And yet, this was the largest release of Boatswain, perhaps larger than the initial release even.

    I’ve reached a point where I’m mostly satisfied with how the internals work now. So much so that, right after the Boatswain 5.0 release, I was able to split the core logic of the app into an internal library, and hide device-specific details from the rest of the app. This paved the way for adding a testing framework using umockdev , and also will allow adding support for devices from other brands such as Loupedeck. If you have any Stream Deck-like device and wish to see it supported in Boatswain, now’s your chance!

    For Boatswain 6, I personally want to focus on 2 major features:

    1. Make Boatswain use the new USB portal . One of my goals with Boatswain is to make it a reference app, using the most modern platform features available – and adding missing features if necessary. The USB portal is an obvious choice!
    2. Remove X11 support . This might come as a controversial decision, but I don’t personally use X11 anymore, do not support it, and will not work on fixing bugs that only exist there. As such, I think it’s fair to just remove X11 support from the apps that I maintain. Practically speaking, this just means removing --socket=fallback-x11 , and users can add back this permission using Flatseal; but please do not expect any kind of support anymore.

    Some features that would be lovely to have, but we currently don’t have either because we lack platform support (i.e. portals ), or simply because nobody sat down and wrote it:

    1. Tracking the current desktop state, such as the focused app, the session idle state, etc. This will be useful for contextual actions.
    2. Clipboard integration. In theory people can simulate this using the Keyboard Shortcuts action, but proper clipboard integration will work better and in more cases.
    3. Picking and launching apps from the host system. This needs to happen through portals which currently don’t exist.
    4. A fancy visual icon editor so that people can create their pretty icons in the app! If any UI designer is reading, please consider yourself assigned to this little project.
    5. Support for custom backgrounds in the touchscreen. I did not have time to finish it before the 5.0 release, but it shouldn’t be too hard to add it.
    6. A proper testing framework!

    Finally, I’d like to thank my Ko-Fi and YouTube supporters for all the patience and for enabling me to do this work. The fundraiser campaign last year was a massive success, and I’m happy to see the all this progress! You all are awesome and I truly appreciate the support.

    Keep an eye on this space as there may be more good news in the near future!

    • wifi_tethering open_in_new

      This post is public

      feaneron.com /2025/04/24/boatswain-5-0/