Thank you (+ contributors) for doing this work and keeping us posted.
Last time I took a look, I think LTO was broken. Is that still the case?
BB_C
joined 2 years ago
I always felt "for embedded" was always selling this crate short, or rather pushing potential users away who aren't aware some data structures here are useful in non-embedded scenarios.
I for example use the admittedly simple Deque (with its is_full()) method in one of my projects for pushing/popping tasks to/from a fixed-size thread queue, which one could argue is a very unembedded-like use-case 😉.
Forgot to mention that I wasn't exactly young at the time. We just didn't have reliable broadband internet back then in my neck of the woods. So I had to download ISOs and save them in a USB thumb drive in a uni computer lab.
Early Mandriva with KDE 3.4 or 3.5 I think, but I can barely remember anything with clarity. It couldn't have been bad though, since I haven't used Windows on my own devices since 😉.
From my foggy memory, I think it was good for my then nocoder self, easy to use, stable, relatively lite, and had good looks.
I missed the Mandrake and pre-Fedora Red Hat era, but not by much.
Be realistic. Filling out forms to get CI runners means no serious users will be attracted. They can just go to GitLab instead. And even then, a migration wouldn't be fully seamless.
Those are immediate show-stoppers before we get to contributor pool sizes and network effects.
My purist young self picked Gitorious over GitHub. I even vaguely remember the KDE presence there, so it was a trusted host with big(ish) betters on it. But it closed shop soon after, and that was a quick learned lesson.
I will be more intrigued by the first jj-native forge when it appears. I may even help alpha test it, as it may bring a breath of fresh air to the space, unless it's going to be AI buzz-filled. In that case to the ~~trash~~ blocklist it will go.
Yes. Note that I'm replying to this:
messy Result type just seems like a case of something that should’ve been handled already (or properly propagated up).
My point was that without flattening, "provide context and propagate" vs. "directly propagate" is always explicit and precise, and is obviously already supported and easy to do.
Use with functional chaining, as pointed out by others, wasn't lost on me either. I've been using Option::flatten() for years already, because such considerations don't exist in that case.
(stating the obvious)
You can already :
res_res??;
// or
res_res?.map_err(..)?;
// or
res_res.map_err(...)??;
// or
res_res.map_err(...)?.map_err(...)?;
With res_res.flatten()?, you don't know where you got the error anymore, unless the error type itself is "flatten-aware", which is a bigger adjustment than the simple ergonomic library addition, and can become itself a problematic pattern with its own disadvantages.
Result::flatten()is probably my favorite addition
It's rare to a have a negative reaction to a library addition. But I don't like this one at all actually.
For me, error contexts are as important as the errors themselves. And ergonomically helping with muddying these contexts is not a good thing!
With all the surface false analogies and general lack of solid knowledge in the comments here, I truly hope that at least half of them are LLM generated.
This is cool and lies within my area of interests.
One thing that is not clear is if there will be a way to do playback outside of custom players. If a stream can't be trivially grabbed, and/or played directly in mpv (via ffmpeg library support or otherwise), this won't be very useful for me.
It would also be interesting to see how the video streams are encoded, if the GOP size is forced to 1 and it's all intra frames or not, and if it's not, how synchronization after recovery (where FEC is not enough) is done.
Hopefully this gets posted again when the code is released.
Good thing we can edit titles here.
view more: next ›
Thank you for the update.