Just switched to 15.1 from 14.1, and after reading through the notes I find that std.RingBuffer is removed, with the comment being that the new improved std.Io. buffers are ring capable.
Looked at a few of the implementations, and I am missing some magic, as what I see is not ring/circular capable. Am I looking at the wrong structs/functions?
In other words, if I have a fixed size backing array of u8, (std.Io.fixedBufferStream(&myBuffer)), then how do I use it both for reading and writing “at the same time” (I handle the concurrency); with the circular wrap around (e.g. pumping and consuming of serial data)
To add salt to the wound, I found the version 14 RingBuffer to be absolutely straight forward and natural, to the point that I didn’t have to think twice about what it was doing, just used it to great effect. Eager to use/understand the new implementation but unable to find the mechanism.
Also, what is the rationale in making the “namespace” Io, all Zig “namespaces” are lowercase (or those that I use, not sure about less obvious containers), with the Io standing out.
std.Io is capitalized because the plan is to make it an interface for doing syscalls or any operation that can block. You can see the beginning of this interface on the async-await-demo branch:
As for adapting to the loss of std.RingBuffer, I’m not sure what to do on that front.
For my use cases I always wanted something closer to Rust’s VecDeque, as my use cases didn’t involve reading/writing bytes. I implemented my own ArrayDeque at one point, however that code is unmaintained at this point, so me or someone else would have to update it.
Thank you for the response. on the std.Io explanation, thank you… understood. I find the basic reasoning understandable, the location (or name) not so much, unless the long term idea is to remove std.io completely. It for me, has a bit of a spoiling effect - but that is just my silly opinion - cannot change it, just mentioning.
Otherwise, what I hear you say is that the 15 release notes is incorrect? As the RingBuffer is then removed without replacement? That can’t be?
I really did not want to write this from scratch, not that it is tough, but because it was really convenient before. I also don’t want to spend endless time searching for it, as the upgrade breaks Zls… so it is very unpleasant at the moment
You can always just drop the file into your project, if it’s what’s best for your usecase. I did the same with RapidHash, which was removed due to not being a stable standard yet (irrelevant to my usecase, and the performance is superior)
Really having a good chuckle at your last comment of copying code and its rating :-)…
Again, the notes says the new “stuff” can react like a RingBuffer, and I just don’t see it; unless I am missing something. Like I said, my IDEs a bit broken so not my best at looking for it.
On the copying of code, I will definitely have to have a look, but my fear is that when you start you realize you need the whole kitchen sink to transfer one thing, so a bit worried about it.
If I have to I will write my own, did it for GoLang and others, but again… I want to embrace what Zig is offering. Depending on 3rd party libs at this point, or having your own reams of code is looking for trouble, as ‘everything’ needs serious attention when you update as Zig is ‘not yet stable’… for which I have tremendous respect as frustrating as it can be.
I mean, the notes claim that std.Io.Reader and std.Io.Writer are ring buffers, but then functions like this make it clear that they don’t handle wrapping around the buffer:
I’ll second the suggestion to copy the code; the Zig project is still at the point where the what will end up in std is uncertain. And yeah, it does kind of suck to have to maintain your own code; at the same time shifting the maintenance burden into std isn’t free. This is the price of using Zig pre-1.0 I guess.
Exactly… there is also a @memcpy, that if you see it you will immediately know it is not a RingBuffer; and none of the classes seems like it has an obvious read and write position… sadly it (my implementation) is not a Queue, as, depending on the data you read you may take “variable” sizes/types from the buffer… which again, RingBuffer did excellently.
I’m kind of glad that the mpsc queue I’m writing isn’t based on the standard library’s ring buffer, but is written from scratch. But this may indicate why the standard library’s ring buffer was removed: for its implementation, people tend to rewrite a new one, just like the multiple duplicate ring buffers in the standard library.
Thank you, the RingBuffer indeed is clean for copy and paste, so that was really no trouble. However, that said, the .15 release brings new challenges as the simplest things now fail (e.g. hex std.debug.print-ing of a slice). No idea yet, but will wade through.
@npc1054657282 - yes, it is all a matter of how much time you have. Fundamentally you can rewrite everything… as at its heart is the posix, os and c layers - but again, I am getting too old and having too little time for all that, so trying my best to use what is offered. It is not called bleeding edge for nothing; for you are going to bleed; and bleeding I am, for the very fundamentals are still radically shifted.
That said, which may be interpreted as negative, I still believe that fundamentally Zig is filling a void, which is funny considering the silly amount of languages out there; but that is purely’ anecdotal.
