Anyone who ran into regressions or other blockers when upgrading to 0.17.0, is your bug filed, and assigned to the 0.17.1 milestone? Anyone need help upgrading?
Waiting for projects like dvui to upgrade first.
DVUI 0.17.x branch is almost merged state.
Now would be the perfect time to test your project against it.
There is something wrong with -fincremental, sdl2 backend that I didnāt have time to investigate but thatās the only issue I encountered and all other backends compile incrementally as far as I can tell. (i.e. on my machine
)
Which is crazy cool btw. Display the window on screen is an order of magnitude (!) slower than compile the app. You read that right
.
Not directly tied to the zig project itself, but the lack of support for zls for the 0.17.0 release forced me to revert back to my previous version that had support for it (0.17.0-dev.2125+0d600e488 in my case).
Iāve tried updating my project to use Raylib 0.17 but havenāt managed to as I havenāt had much time to dig into the build system issues that have popped up.
I know there was a rework of the build system, with the maker and configurer being separated 0.17.0 Release Notes ā” The Zig Programming Language but itās been hard to find information about what those changes entail for those writing libraries and those consuming it.
For raylib-zig in particular, the project is at the 3rd build system patch to figure out how users can consume said library Unable to find module "raylib," zig 0.17.0 Ā· Issue #364 Ā· raylib-zig/raylib-zig Ā· GitHub. Personally Iāve had a hard time finding what the issue could be based on the build system documentation (and release notes), so I plan on diving into the code later to understand. In sum, the issue seems to be circling around lazy dependencies and in how 0.17 changed when and how dependencies are fetched
In my raylib-zig project, I had the same issue with 364 (PR 365). I took a lot of cue from this commit. For instance, getInstallPath(install_dir, html_filename) had to be replaced by graph.path(.install_prefix, html_filename), I didnāt find that in the release notes. Also, the emccStep changed a lot, and windows target required the fixEmccOnWindows patch to call the .bat instead of the .py.
In the code itself, the documented stuff was straightforward: **
@splat, bufPrintZ
bufPrintSentinel, std.builtin.Type.StructField
std.builtin.Type.Struct (that is more of a struct of arrays).
What threw me off was @bitSizeOf no longer works on extern struct, I used that to truncate savegame I put in persistence, and now I think it might have broken compatibility. I would have expected something in the release note, like @bitSizeOf no longer apply to extern struct because they donāt have a defined bit layout or something. I guess itās because extern struct cannot be part of a packed struct, so @bitSizeOf no longer make sense.
Relevant Zig issue: https://codeberg.org/ziglang/zig/issues/37163
Iām starting, but waiting for zls a little
Iāve worked on that! I was a lot of rebasing (the main branch moves fast!), and we did it with a couple of people, but most of the stuff was āmechanicalā,
Yeah, I noticed of course. ![]()
You authored a good third of the commit in this branch.
Indeed mainly mechanical and on my side a lot of dependency tracking. And a lot of rebase, and merge.
Thank you so much @yinameah and @brodo, also @Der-Teufel and @AndrewKraevskii, you all are making it so easy for me!
Iāve gone through the code changes, those were straightforward. Now doing testing across all our backends, hit the lazy dependency thing, glad to see https://codeberg.org/ziglang/zig/pulls/37177 already up - thank you @squeek502 !
Hope to get through testing in the next few days and will report anything I run into.
fyi itās quite straight forward to build ZLS, and Iāve been using this branch for 0.17:
git clone https://github.com/zigtools/zls
git checkout techatrix/build-runner-process
zig build -Doptimize=ReleaseSafe
cp ./zig-out/bin/zls /wherever/you/want
Yesterday at Zig Day Portland, Lateef ran into a renameat2() issue which may already be a known issue:
For those (like me) who are unaware of what this syscall does, some context Iāve found:
renameat()introduced around 2005 Some new system calls [LWN.net]renameat2()introduced in 2014 (Linux kernel 3.15) Exchanging two files [LWN.net]renameat2()fails on encrypted filesystem Intermittent issues with software using `renameat2` to exchange directories - Linux Mint Forumsrenameat2()fails on filesystems that are POSIX compatible and donāt implementRENAME_EXCHANGEflag Graceful fallback when `renameat2(RENAME_EXCHANGE)` is not supported by the filesystem Ā· Issue #96835 Ā· ClickHouse/ClickHouse Ā· GitHub
Thanks for those links. I closed one as a duplicate of the other, set to 0.17.1 milestone, and added closure criteria.
Currently, to remove a ** b syntax is not allowed to resolve "42" ** 10 (ā42424242424242424242ā)
Using the @splat is led the error.
error: expected type 'u8', found '*const [2:0]u8'
const expected: [20]u8 = @splat("42");
Not a blocker / regression, but what I miss the most right now is comprehensive and up-to-date build system documentation. Most of the time, Zig Build System ā” Zig Programming Language does not include what Iām looking for. Some examples:
- Dependencies - how to add (and update) them to
build.zig.zonand how to use them frombuild.zig(and Zig code). - C compilation (
addCSourceFileandlink_libcand friends). - Itās really hard for me to wrap my head around just the very basics of how build steps and dependencies even work. Looking closely at
zig initgeneratedbuild.zigcauses new spaghetti connections to form in my brain, leaving me more confused than before. I find Git more intuitive to understand than all this, and itās probably just for some trivial puzzle piece that didnāt āclickā for me yet.
Some discussion of options here: Removed array multiplication from Zig - #11 by ScottRedig
This case can be tackled with a pinch of comptime :
fn splat(comptime str: []const u8, comptime n: usize) []const u8 {
return comptime text: {
var b: []const u8 = "";
for (0..n) |_| b = b ++ str;
break :text b;
};
}
test {
try std.testing.expectEqualStrings("42424242424242424242", splat("42", 10));
}
Edit : beaten by squeek502.
Despite my suggestion in that thread, what I ultimately used when I needed this was the bitcast version:
https://codeberg.org/ziglang/zig/src/commit/e76df171db6260f5eb1d51eb4abfe6857060d46a/lib/std/http/Server.zig#L1015
const repetition: [@divExact(lanes, 4)][4]u8 = @splat(mask);
const array: [lanes]u8 = @bitCast(repetition);
I didnāt run into any further zig issues, just a few more dependency bumps. dvui is now on zig 0.17.0 - wohoo!