Christofer Nolander

After some digging I have traced the problem to this line in the executor: https://github.com/Canop/bacon/blob/d256ebcb7e2244bcad335abccafb8ab84fc8aea2/src/executor.rs#L135 Basically, the executor is blocked on reading the next line from `cargo test`, but since...

Pushed a new fixed which I have confirmed fixed the issue: see the commit message for details (my understanding of `tokio::spawn` is obviously not as good as I thought it...

Something else I just noticed with the sample above: while it is stuck in the loop, and a change is made to the code the old output is not cleared....

After further investigations: doing the same test (running the above snippet and re-writing the file) the line `starting...` is shown the first time bacon is run, but after the re-write...

> `externals/glslang/glslang/libglslang.a` Looks like there’s a hardcoded path to a unix-style library somewhere, isn’t the extension `.lib` on Windows?

I cannot verify right now, but try passing the `--target-env=opengl` argument to glslls (double-check the exact names using the `--help` flag)

> @Cloudef Considering how zig package manager works, I think this behavior should be the default. I'm inclined to agree. The package manager expects that the contend pointed to by...

> Since the git url already has special syntax, another option would be to use query parameters to encode more information for example. That's a nice solution! I updated the...

I have been running into this myself after I added support for `#include`: I have split some common functionality into separate files, but seeing as they can be used in...

This is probably some kind of UB triggering the sanitizer, as disabling it [in this commit](https://github.com/nolanderc/tracy-zig/commit/ecdddf8e4b5b37c3dfa9f80556ffdcbc3ad7298f) makes the issue disappear. Related: https://github.com/ziglang/zig/issues/7137