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.
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.
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.
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.
As someone who hasn't been following this, playing the connotation game (using "automatic" instead [partially] "implicit") is rubbing me the wrong way.
Otherwise, the keyword use seems too generic to be used for this. But I'm sure this has been bikeshedded already, and if it hasn't, it will be.
Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as "Rust makes it harder for a 'contributor' to sneak in LLM-generated crap".
make uses multiple processes for parallelism, or what the blog post (below) calls "interprocess parallelism". cargo/rustc has that and intraprocess parallelism for code generation (the backend) already. the plan is to have parallelism all the way starting from the frontend. This blog post explains it all:
Along the same vein, too many open source projects don’t factor in non-“gnu/linux” environments from the start.
No one is entitled to anything from open-source projects.
I spent time making sure one of my public tools was cross platform once. This was pre-Rust (a C project), and before CI runners were commonly available.
I did manage it with relative ease, but Mac/mac (what is it now?) without hardware or VMware wasn't fun (or even supported/allowed). Windows was a space hog and it's a shit non-POSIX OS created by shits anyway, and Cygwin/MSYS wouldn't have cut it for multiple reasons including performance. The three major BSDs, however, were very easy (I had prior experience with FreeBSD, but it would have been easy in any case).
People seem to have forgotten that doing open-source was supposed to be fun first and for most. Or rather, the new generation seems to never have gotten that memo.
POSIX is usually where a good balance between fun and public service is struck. Whether Mac/mac is included depends on the project, AND the developers involved. With CLI tools, supporting Mac/mac is often easy, especially nowadays with CI runners. With GUIs, it's more complicated/situational.
Windows support should always be seen as charity, not an obligation, for all projects where it's not the primary target platform.
Yeah, apologies for not communicating the issue clearly.
cp config.example.toml config.toml
./y.sh prepare
./y.sh build --sysroot
./y.sh clean all
# above commands finish with success
# below, building succeeds, but it later fails with "error: failed to load source for dependency `rustc-std-workspace-alloc`
./y.sh test --release
And then trying to use the "release" build fails:
% CHANNEL="release" ./y.sh cargo build --manifest-path tests/hello-world/Cargo.toml
[BUILD] build system
Finished `release` profile [optimized] target(s) in 0.03s
Using `/tmp/rust/rustc_codegen_gcc/build/libgccjit/d6f5a708104a98199ac0f01a3b6b279a0f7c66d3` as path for libgccjit
Compiling mylib v0.1.0 (/tmp/rust/rustc_codegen_gcc/tests/hello-world/mylib)
error[E0463]: can't find crate for `std`
|
= note: the `x86_64-unknown-linux-gnu` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-unknown-linux-gnu`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `mylib` (lib) due to 1 previous error
I will make sure to report issues directly in the future, although from account(s)
not connected to this username.
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.