0.15.1 Changes

[gkell]

This thread is already diluted, so let me add:

    pub fn dumpToFile(self : *Self, file : std.fs.File) !void {
        var b : [16384] u8 = undefined;
        var w = file.writer(&b).interface;
        try w.print("Start Pattern:      0x{x:0>2}\n", .{self._startPattern});
...
         try w.flush();

Previously

    pub fn dumpToFile(self : *Self, file : std.fs.File) !void {
        var w = file.writer();
        try w.print("Start Pattern:      0x{x:0>2}\n", .{self._startPattern});

Correct? Problem is getting a

/opt/zig/zig-x86_64-linux-0.15.1/lib/std/posix.zig:1376:22: 0x115d381 in writev (std.zig)
            .BADF => return error.NotOpenForWriting, // Can be a race condition.
                     ^
/opt/zig/zig-x86_64-linux-0.15.1/lib/std/fs/File.zig:1770:21: 0x115ad83 in drain (std.zig)
                    return error.WriteFailed;

I run this code on the std.fs.File.stdout()… and there is no race condition as it is a single threaded app (and obviously it is open)

Additionally…

std.debug.print("{d:0>6} {x:0>12} {x:0>2}", .{ offset, offset, slice });

Used to work out of the box… failing on printing the slice now.

Guys, I am an average Joe (on the best of days) - but it feels like there is an overcomplication in elementary things making the simplest, fundamental things tough with fiery hoops and landmines to boot.
I am at a point where I am considering sticking to the os/posix classes and skipping many reference library items entirely.

[Sze]

@gkell

var w = file.writer(&b).interface;

Same error as:

0.15.1 Reader/Writer

The key insight you’re missing is that reader() creates a thing that needs to live somewhere. var file_reader = file.reader(&buf); // this var needs the same lifetime as `buf` const reader = &file_reader.interface; // `reader` not reassigned, so use `const`

So use:

var file_writer = file.writer(&b);
const w = &file_writer.interface;

[gkell]

Thanks @Sze , I stand by my statement…

Do you have any idea why the slice printing is failing since 15? Used to work in 15. I read through most of the release notes and nothing there.

[Sze]

@gkell

Do you have any idea why the slice printing is failing since 15? Used to work in 15. I read through most of the release notes and nothing there.

15 twice makes no sense?

If your code still contains this line, then it can’t work:

@gkell

var w = file.writer(&b).interface;

you are copying the Io.Writer out of the temporary File.Writer,
destroying the interfaces implementation, you can’t copy .interface as a separate value.

[gkell]

pub fn main() !void {
    var slice: [10]u8 = undefined;
    slice[0] = 'B';

    std.debug.print("{x:0>2}", .{&slice});
}

Runs perfectly in 14.1

╰─○ /opt/zig/zig-x86_64-linux-0.14.1/zig build run
{ 42, aa, aa, aa, aa, aa, aa, aa, aa, aa }%

In 15.1

thread 2242659 panic: reached unreachable code
/opt/zig/zig-x86_64-linux-0.15.1/lib/std/debug.zig:559:14: 0x1044179 in assert (std.zig)
    if (!ok) unreachable; // assertion failure
             ^
/opt/zig/zig-x86_64-linux-0.15.1/lib/std/Io/Writer.zig:1402:11: 0x10dbe59 in optionsForbidden (std.zig)
    assert(options.width == null);

@Sze - sorry, yes typo on the 15 (twice); meant 14 vs 15

[Sze]

const std = @import("std");

const HexString = struct {
    bytes: []const u8,

    pub fn format(hs: HexString, writer: *std.Io.Writer) std.Io.Writer.Error!void {
        try writer.printAsciiChar('{', .{});
        if (hs.bytes.len > 0) {
            try writer.printAsciiChar(' ', .{});
            const last = hs.bytes.len - 1;

            for (hs.bytes, 0..) |byte, i| {
                try writer.printValue("x", .{ .alignment = .right, .fill = '0', .width = 2 }, byte, 0);
                if (i != last) try writer.printAscii(", ", .{});
            }
            try writer.printAsciiChar(' ', .{});
        }
        try writer.printAsciiChar('}', .{});
    }
};

pub fn hexString(bytes: []const u8) HexString {
    return .{ .bytes = bytes };
}

pub fn main() !void {
    var array: [10]u8 = undefined;
    array[0] = 'B';

    std.debug.print("{f}", .{hexString(&array)});

    const slice: []const u8 = &array;
    std.debug.print("\n{f}", .{hexString(slice[0..0])});
    std.debug.print("\n{f}", .{hexString(slice[0..1])});
    std.debug.print("\n{f}", .{hexString(slice[0..2])});
    std.debug.print("\n{f}", .{hexString(slice[0..3])});
    std.debug.print("\n", .{});
}

[gkell]

@Sze , I think you are basically just making my point for me.

[Sze]

I am not here to bike-shed, this is a help topic about adapting to the new changes, not for complaining about them.

[mg979]

This works though

pub fn main() !void {
    var buf: [10]u8 = undefined;
    buf[0] = 'B';

    std.debug.print("{{", .{});
    for (buf) |c| {
        std.debug.print("{x:>3}", .{c});
    }
    std.debug.print(" }}", .{});
}

Honestly I found it strange that it worked before the way you wrote it, since slices required any formatter like

    std.debug.print("{any:0>2}", .{&buf});

which still works. Anyway I still think there’s something funny going on with this kind of errors.

[gkell]

Agreed, and good code. I do it merely to let the powers know, that the simplest of things are breaking, and things that were obvious, are not obvious anymore, without reasonable documentation or example. I understand it is free, I understand it is bleeding edge, I see Zig filling a void in a time where there are millions of languages to choose from and it is still special, I understand all of the above, but after investing much time in it, these issues are worrying me; as the most basic of things cannot recompile after update (and I keep my code simple), some of which don’t give compile errors and you only see at runtime, meaning you would have to create unit tests for everything (time which a 2 man company simply does not have).

Bottom line, worried about the things that I am not aware of yet that has changed/broken, tired of long hours as we all are and disappointed that I have to backtrack profusely and worried about what this holds for the future.

[gkell]

Thanks @Sze solution has better longevity imho. But thanks for your suggestion… the issue is not the inability to print as hex, but that fact that something seemingly obvious and simple that worked does not anymore. (and like script, it fails only when you run it… which kind of defeats some of the purpose…)

“{f}” Required to Call format Methods

The thread is in the vicinity, but really not that obvious to impact something that did not have a format in the first place.

Again, this is not a complaint, it is just a reminder to myself that there is much more work and rework to follow - and to take a weekend and make sure what pain I want to endure.

[squeek502]

Unrelated to 0.15.x, but if you’re just printing bytes for debugging purposes you might be interested in using std.debug.dumpHex. For example, this:

pub fn main() !void {
    var array: [10]u8 = undefined;
    for (&array, 0..) |*v, i| {
        v.* = @intCast('A' + i);
    }

    std.debug.dumpHex(&array);
}

will output something like:

000000025d3ffc6e  41 42 43 44 45 46 47 48  49 4A                    ABCDEFGHIJ

[gkell]

Thanks @squeek502 - yes I am aware of that method.

There however is a big convenience both in code and conceptualizing the output in working with format strings… I guess @Sze 's reference to implementing the format interface is the long term way to go; more often than not.

[gkell]

Thanks for your assistance. I have now converted my readers/writers and formatters (quite a few places). I really was not looking forward to it (as I guess was obvious), but all is well again. I am not fully with the benefits of the new patterns yet, but I am hopeful that we will get good yardage from it.

Thanks again to all.

Off topic, was sitting with a C and C++ problem today… and in an off few minutes I went to look at one of the main Zig ‘competitors’. The C/C++ problem was livable yet unnecessary… the other language, I was just again perplexed at the amount of red tape involved and the patterns it impose.

So - in two words… GO ZIG!

[weskoerber]

@gkell

the simplest of things are breaking

@gkell

the most basic of things cannot recompile after update

A small ship can correct course quickly.

Neither the language nor the standard library is stable. More breaking changes are coming. I don’t mind breakages, especially if that means a better 1.0. The thing is, we don’t yet know if 1.0 would be better because we haven’t crossed that bridge yet; we have to trust the maintainers’ conviction that it will.

Imagine if pre-1.0 Zig had a policy where each breaking change had a backward compatible counterpart. That would put so much extra burden on an already-small team. I, for one, would much rather see their time spent on more important things, such as improving incremental compilation, expanding self-hosted back-end support, improving runtime safety, etc.

There were some changes in 0.14 I didn’t like, but after some time I either came around or just got used to it. I think this will be true for 0.15, too.

[gkell]

I totally understand. If there were unlimited budgets and unlimited hands it would have been cooked already. The communication/documentation is lacking for people that have “day jobs” on 1000 other things. I picked a very stressful time to upgrade as well, don’t know what I was thinking. It fortunately isn’t core stuff -just things to get me going into learning Zig (so I spend much less time at it than I want/need to).

That said, if it wasn’t for the forum I would have given up long ago, as I simply don’t have the time to etc etc. The tooling however is still a major concern… The cross compiling and “embedded clib” is gold.