Joshua Batty

Yep that's a great idea @freesig

Hey @freesig Maybe you would be interested in [this issue](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/issues/150) I opened about Vulkan support on the Gstreamer Gitlab. Looks like Vulkan support needs to be added into Gstreamer itself...

This came up again recently while working on dependency documentation (https://github.com/ProvableHQ/leo-docs-source/pull/556) and the edition handling PR (https://github.com/ProvableHQ/leo/pull/29027). The `leo.lock` infrastructure exists (files get created, error types defined) but doesn't appear...

> > please update title accordingly. > > please ellaborate more , what title ? Thanks for the PR. I'll take a look at this on Monday. The PR tilte...

Thank you for your contribution, but this PR introduces significant architectural problems including arbitrary recursion limits, thread-local state pollution, removal of most tests, and complex nested loops in the token...

> I have a few questions but overall LGTM. > > Would love a redesign to make it simpler to use for developers. Agreed. Once we have the [lock file](https://github.com/ProvableHQ/leo/issues/28591)...

Thanks!

-13.24% compile time regression is a bit unfortunate. Any way we can get this number down a bit?

Nice, this is a great idea. My vote goes to Option 1. * It mirrors the Cargo approach, leveraging a target/output directory to store build artifacts. This approach is familiar...

In the compiler we've already implemented in-memory incremental compilation by caching the program's AST in the query engine. This helps avoid recompiling unchanged code and improves response times but is...