I started a thread on the GNOME forum about the state of #vala maintenance. I don't have the answers, but let's discuss & figure out as a community what we can do to make sure that Vala is sustainable and can keep moving forward
Sergey Bugaev
mastodon 4.7.3Systems hacker, mostly working on GTK and the wider GNOME platform these days. I made peel and wl-clipboard. Previously active in GNU Hurd and glibc, Darling, etc.
I teach a university course on Unix and RISC-V.
I run, work out, drink too much coffee, and miss dancing.
I like Rust and dislike Docker.
In other news, I finally allocated some time this weekend to do some maintenance work and get wl-clipboard 2.3 out.
People have long been asking for a new release (especially once KDE decided to just drop wlr-data-control support). However, it takes time and effort even to review & test & merge (with changes...) incoming PRs; maintenance work is work too.
Read the release notes at https://github.com/bugaevc/wl-clipboard/releases/tag/v2.3.0
Very happy with how our little collaboration with @slomo@toot.cat on the "#peel for #GStreamer" project is proceeding.
This basically involves adding various little enhancements and fixes into peel to better support GStreamer needs, such as better supporting dynamic properties and signals (this is something that Vala has a whole language feature for!), and also improving GStreamer's own GIR where possible to be more binding-friendly.
The main application code is in Rust, a language I've wanted to explore for quite a while. And the user interface was built as a web application.
Welp
@Mara@hachyderm.io @tauon@possum.city moreover, that just wouldn't work since we've already moved the res into the LHS
- There is not really a UB in languages like Java and Python (you're thinking of C), dereferencing null is well-defined, in Java it will throw a NullPointerException
- There is absolutely unwrap (or expect, etc) usage in any serious/realistic Rust code base