Anyone unable to upgrade to 0.17.0 for some reason?

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 :grin:)

Which is crazy cool btw. Display the window on screen is an order of magnitude (!) slower than compile the app. You read that right :sweat_smile:.

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: ** :right_arrow: @splat, bufPrintZ :right_arrow: bufPrintSentinel, std.builtin.Type.StructField :right_arrow: 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. :grin:

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:

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.zon and how to use them from build.zig (and Zig code).
  • C compilation (addCSourceFile and link_libc and 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 init generated build.zig causes 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!