eddyb

8 ms·

1.
by eddyb 10mo ago
> So what was the screenshot feature of X11? In case I wasn't clear enough, there was never a screenshot feature . Any X11 client could read any pixel written by any other X11 client. > Have all the best or most popular apps bee
2.
by eddyb 10mo ago
If you're not familiar, the way X11 works is comparable to "multiplayer notepad" for your pixels ("multiplayer MSPaint"?). All your monitors are combined into a large canvas where every pixel can be written and read
3.
by eddyb 10mo ago
If your Linux distribution is handling Mesa packages correctly, you will never lack OpenGL/Vulkan drivers . The reason is that Mesa includes "software rendering" drivers for both OpenGL ("llvmpipe") and Vulkan (&qu
4.
by eddyb 2y ago
Not sure if there's a better section elsewhere, but at least this one touches on it: https://doc.rust-lang.org/reference/destructors.html#tempora...
5.
by eddyb 4y ago
This is effectively a rustdoc bug, the pattern is very much part of the body of the function, not the signature (and this split is explicitly represented in the compiler IRs, which rustdoc effectively undoes). While it's not really h
6.
by eddyb 4y ago
> So what are you using or recommending? I am using KDE (aka Plasma5) in Wayland mode, on NixOS unstable. I would not recommend NixOS, just like I mentioned, and I didn't really want to get into the weeds of why, but while Nix is
7.
by eddyb 4y ago
GNOME has kind of always been on the opposite end of the configurability spectrum from KDE, IME. But also I'm not super clear on how libinput fits into the picture, I think there used to be some Synaptics-specific integration in certai
8.
by eddyb 4y ago
> Maybe it would be called #[expect(deprecated)] Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek. Or maybe it's the obvious name choice, heh, because it literally exists with that very synt
9.
by eddyb 4y ago
We explicitly support building against librustc_driver-*.so for both "custom drivers" (what we call those binaries I mentioned) and generally "rustc as a library" usecases. We should maybe rename it to librustc and remov
10.
by eddyb 4y ago
> but also parts of rustc are implemented in a dynamic library ("librustc_driver") Nit: 100% of rustc is found within librustc_driver-*.so (I mention it in https://news.ycombinator.com/item?id=32329062 - which
11.
by eddyb 4y ago
[continued from above due to size limit] What I'm referring to is incremental recompilation with the following properties: 1. automatic correctness ` - that is, a compiler change not explicitly updating anything related to dependency
12.
by eddyb 4y ago
No, at most we would've invested more in e.g. ensuring¹ you cannot accidentally (or intentionally) mix-and-match shared objects not built by the same build process, or in ways to reduce the cost² of safe ("full relro") dynami
13.
by eddyb 5y ago
It's a shame LLVM isn't more explicit about calling conventions (especially since the front-end has to lower most of the platform-specific C ABI details, short of the exact list of registers or stack offsets, into LLVM IR anyway).
14.
by eddyb 5y ago
Don't you want "interrupt ABIs" for that specific usecase? IIRC `#[naked]` are only really guaranteed to allow inline assembly, so it's like defining a function in `global_asm!` except for monomorphization and generally
15.
by eddyb 5y ago
> For instance `(*role).name` creates a `&mut &'static str` behind the scenes which is illegal, even if we can't observe it because the memory where it points to is not initialized. Where is this coming from? It's
16.
by eddyb 5y ago
I live in Bucharest, Romania and I pay $9/mo for 1Gbps FTTH (fiber into my flat, with an ISP-provided fiber terminal). This offering is available from digi.ro pretty much throughout most major cities (so city area doesn't matter u
17.
by eddyb 5y ago
I agree that ARM isn't going anywhere, as long as it can be licensed for less than it takes to design a good-enough RISC-V core, it will get used (with opensource designs slowly lowering the latter on average). It's really more th
18.
by eddyb 5y ago
> Or I'm missing something big. It's the software tooling cost. There's nothing exceptional in the spec because it's trying to insert itself into the industry as a standard baseline , so staying small and simple is p
19.
by eddyb 5y ago
You could look at Cranelift, which I believe uses integer indices, and several datastructures for control-flow vs dataflow. There is no SSA IR in rustc itself (MIR, regrettably, only lowers control-flow, but uses variables instead of repres
20.
by eddyb 6y ago
Not at all, RISC-V doesn't need extremely clever compilers, and instead it's designed to maximize what the microarchitectures (hardware implementations) can do, and reduce unnecessary overhead. My reply was mostly aimed at the ide
21.
by eddyb 6y ago
Betting on smart compilers without putting in the effort to build them is how the Itanic happened.
22.
by eddyb 6y ago
When I first heard the news, I started imagining EPYC with some core dies replaced with FPGAs connected to the Infinity Fabric. Really cool to hear this used to be a thing with HT (though long before chiplets), gives me some hope we'll
23.
by eddyb 6y ago
> but I have not seen any evidence that the average program is actually more likely to behave correctly in the face of wrapping. Rust takes a simple stance of "safe code should be UB-free". Yes, you may have logic bugs with wra
24.
by eddyb 6y ago
I kept grumbling about the `Copy` limitations on iterators for years, but at the end of the day, someone has to write the lint for "iterating on a copy of a variable" and I don't think that has happened yet. But unlike the ot
25.
by eddyb 6y ago
> heterogenous arenas are more or less a solved problem in Rust To expand a bit on what pcwalton said: Rust never had a concept of a type you can't move (we likely can't ever introduce it) and placement was never about "
26.
by eddyb 6y ago
Fascinating coincidence! It was probably the LLVM upgrade ( https://github.com/rust-lang/rust/pull/73526 ) landing, probably before the comment was even posted (but the nightly would only show up with the upgra
27.
by eddyb 6y ago
IIRC, that "optimization" mostly avoids wasting time compiling a complex `Clone` implementation, when simply returning `*self` suffices (there are some crates with at lot of `#[derive(Copy, Clone)]` types). We try to avoid having
28.
by eddyb 6y ago
Did you mean to link to a different example, or different compiler flags? The link you provide shows only one function, because LLVM has optimized both to be identical, and deduplicated them. (If you disable the "Directives" filte
29.
by eddyb 6y ago
The RISC-V Vector ISA is credited to Cray "vector processors" [1], explicitly by the RISC-V authors. Additionally, I believe experimenting with vector ISAs was mentioned as one of the reasons they started another RISC research pro
30.
by eddyb 6y ago
> * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. It's public though, just not externally reachable , the private mod

More ›