Switch prongs from comptime arrays proposal accepted
On my first zig project, a little over a year ago, I got into a situation where I would have liked to generate switch prongs from comptime known values. My research led me to an open proposal on github that confirmed it wasn't possible at the time. 2 weeks ago, following the release, a year ago, of an optimization commit that identified the slow implementation of std.meta.stringToEnum, Andrew Kelley chose a syntax, marked the proposal as accepted and added it to the urgent milestone. Indeed, stringToEnum is a prime use case for switch prong generation. Whilst we do not know when this feature will be implemented, and the oldest proposal on the github urgent milestone is from 2015, I am happy to see the language is still moving forward, and that the zig foundation is working on this important feature whose absence had personally affected me before.
23 points · 4 comments
Please, help me with understanding std.Io.Reader.discardRemaining()
I am writing a small tic-tac-toe program in ZIg, because I want to practice what I have learnt by doing exercises from Ziglings. I got to the part where I needed to take a single byte of a user's input.
For that I used Reader's takeByte() method:
pub fn main(init: std.process.Init) !void {
const stdin = std.Io.File.stdin();
var stdin_buffer: [1]u8 = undefined; // I only need the first byte
var stdin_reader = stdin.reader(init.io, &stdin_buffer);
// ...
const b = try stdin_reader.interface.takeByte();
// ...
}
Well, here Zig forced me to learn that a terminal has its input queue and that if I don't deal with the rest of potential input bytes, they will be carried on, so an input like this 3rm -rf will kill my computer, because my program will consume the "3" and then my terminal will execute the rest of the input.
I needed a way to discard the rest of the bytes. In my research I have also learned about Termios interface that I can use in order to control my terminal. And Zig's std has tools for that:
pub fn main(init: std.process.Init) !void {
const stdin = std.Io.File.stdin();
const termios = try std.posix.tcgetattr(stdin.handle);
defer std.posix.tcsetattr(stdin.handle, .FLUSH, termios) catch {};
// ...
const b = try stdin_reader.interface.takeByte();
// ...
}
And it worked! But I then thought controlling terminal for simple user input had to be an overkill, and that there had to be a simpler way.
So, finally, I have found std.Io.Reader.discardRemaining():
pub fn main(init: std.process.Init) !void {
// ...
const b = try stdin_reader.interface.takeByte();
const discardedLength = try stdin_reader.interface.discardRemaining();
// ...
}
But now the problem is that my program hangs inside the discardRemaining and never leaves. The closest issue I could find was this one, but it was fixed in version 0.15 and I am now on Zig version 0.17.0.
Could you, please, help me understand, what I am missing here? I am pretty sure I forgot (more probably I don't know) to do something.
Your help is much appreciated!
14 points · 5 comments
If you check out the original proposal they explicitly cite Pony. Fun fact, that person submitted quite a few language proposals around that time, most of which had me scratching my head, but this one struck me as a good idea.
I think it's badass that Pony took it all the way, including + and *. Even I wouldn't dare to take it that far.
20 points
@adityazero_ reminds me of zig#2291 (which makes Zig an absolute powerhouse for CUDA NVVM code)
42 views
Switch prongs from comptime arrays proposal accepted
On my first zig project, a little over a year ago, I got into a situation where I would have liked to generate switch prongs from comptime known values. My research led me to an open proposal on github that confirmed it wasn't possible at the time. 4 days ago, following the release, a year ago, of an optimization commit that identified the slow implementation of std.meta.stringToEnum, Andrew Kelley chose a syntax, marked the proposal as accepted and added it to the urgent milestone. Indeed, stringToEnum is a prime use case for switch prong generation. Whilst we do not know when this feature will be implemented, and the oldest proposal on the github urgent milestone is from 2015, I am happy to see the language is still moving forward, and that the zig foundation is working on this important feature whose absence had personally affected me before.
1 point
[quote="sshockwave, post:28, topic:143083"]
Zig tells you to always pass by value and let the compiler decide whether to actually pass by value or not
[/quote]
That was true in the past but that feature was removed from Zig and will not be supported. Rust does support it, as described above.
zig#5973
ziggit.dev
4 likes · 1 comment
@jammingames Reminds me of Zig logo btw:
ziglang/logo
4 views
What I'm suggesting works perfectly for that kind of lop-sided size distribution. It's especially great for lists of size 0 (since you waste a ton of relative space per ArrayList by needlessly storing both a length and a capacity) and size 1 (since a lot of ArrayList implementations will jump-start capacity from 0 to something greater than 1 for non-large element sizes in an attempt to skip the slowest part of the exponential growth curve).
I don't understand the objection about cache locality as it pertains to the lop-sided size distribution and recycling work-in-progress lists through a builder context.
2 points
For reference, Zig's standard library HTTP client is not that much bigger than the build.zig required to compile curl.
2 points
Mentions
Switch prongs from comptime arrays proposal accepted On my first zig project, a little over a year ago, I got into a situation where I would have liked to generate switch prongs from comptime known values. My research led me to an open proposal on github that confirmed it wasn't possible at the time. 2 weeks ago, following the release, a year ago, of an optimization commit that identified the slow implementation of std.meta.stringToEnum, Andrew Kelley chose a syntax, marked the proposal as accepted and added it to the urgent milestone. Indeed, stringToEnum is a prime use case for switch prong generation. Whilst we do not know when this feature will be implemented, and the oldest proposal on the github urgent milestone is from 2015, I am happy to see the language is still moving forward, and that the zig foundation is working on this important feature whose absence had personally affected me before.
Please, help me with understanding std.Io.Reader.discardRemaining() I am writing a small tic-tac-toe program in ZIg, because I want to practice what I have learnt by doing exercises from Ziglings. I got to the part where I needed to take a single byte of a user's input. For that I used Reader's takeByte() method: pub fn main(init: std.process.Init) !void { const stdin = std.Io.File.stdin(); var stdin_buffer: [1]u8 = undefined; // I only need the first byte var stdin_reader = stdin.reader(init.io, &stdin_buffer); // ... const b = try stdin_reader.interface.takeByte(); // ... } Well, here Zig forced me to learn that a terminal has its input queue and that if I don't deal with the rest of potential input bytes, they will be carried on, so an input like this 3rm -rf will kill my computer, because my program will consume the "3" and then my terminal will execute the rest of the input. I needed a way to discard the rest of the bytes. In my research I have also learned about Termios interface that I can use in order to control my terminal. And Zig's std has tools for that: pub fn main(init: std.process.Init) !void { const stdin = std.Io.File.stdin(); const termios = try std.posix.tcgetattr(stdin.handle); defer std.posix.tcsetattr(stdin.handle, .FLUSH, termios) catch {}; // ... const b = try stdin_reader.interface.takeByte(); // ... } And it worked! But I then thought controlling terminal for simple user input had to be an overkill, and that there had to be a simpler way. So, finally, I have found std.Io.Reader.discardRemaining(): pub fn main(init: std.process.Init) !void { // ... const b = try stdin_reader.interface.takeByte(); const discardedLength = try stdin_reader.interface.discardRemaining(); // ... } But now the problem is that my program hangs inside the discardRemaining and never leaves. The closest issue I could find was this one, but it was fixed in version 0.15 and I am now on Zig version 0.17.0. Could you, please, help me understand, what I am missing here? I am pretty sure I forgot (more probably I don't know) to do something. Your help is much appreciated!
If you check out the original proposal they explicitly cite Pony. Fun fact, that person submitted quite a few language proposals around that time, most of which had me scratching my head, but this one struck me as a good idea. I think it's badass that Pony took it all the way, including + and *. Even I wouldn't dare to take it that far.
@adityazero_ reminds me of zig#2291 (which makes Zig an absolute powerhouse for CUDA NVVM code)
Switch prongs from comptime arrays proposal accepted On my first zig project, a little over a year ago, I got into a situation where I would have liked to generate switch prongs from comptime known values. My research led me to an open proposal on github that confirmed it wasn't possible at the time. 4 days ago, following the release, a year ago, of an optimization commit that identified the slow implementation of std.meta.stringToEnum, Andrew Kelley chose a syntax, marked the proposal as accepted and added it to the urgent milestone. Indeed, stringToEnum is a prime use case for switch prong generation. Whilst we do not know when this feature will be implemented, and the oldest proposal on the github urgent milestone is from 2015, I am happy to see the language is still moving forward, and that the zig foundation is working on this important feature whose absence had personally affected me before.
[quote="sshockwave, post:28, topic:143083"] Zig tells you to always pass by value and let the compiler decide whether to actually pass by value or not [/quote] That was true in the past but that feature was removed from Zig and will not be supported. Rust does support it, as described above. zig#5973 ziggit.dev
@jammingames Reminds me of Zig logo btw: ziglang/logo
What I'm suggesting works perfectly for that kind of lop-sided size distribution. It's especially great for lists of size 0 (since you waste a ton of relative space per ArrayList by needlessly storing both a length and a capacity) and size 1 (since a lot of ArrayList implementations will jump-start capacity from 0 to something greater than 1 for non-large element sizes in an attempt to skip the slowest part of the exponential growth curve). I don't understand the objection about cache locality as it pertains to the lop-sided size distribution and recycling work-in-progress lists through a builder context.
For reference, Zig's standard library HTTP client is not that much bigger than the build.zig required to compile curl.