You’re right, that’s what I get for not having written a line of C in what 15 years. Bonus challenge: write for i in i32::MIN..=i32::MAX in C, that is, iterate over the whole range, start and end inclusive.
(I guess the ..= might be where my confusion came from because Rust’s .. is end-exclusive and thus like <, but also not what you want because i32::MAX + 1 panics).
I mean i < 10 isn’t wrong as such, it’s just good practice to always use <= because in the INT_MAX case you have to and everything should be regular because principle of least astonishment: That 10 might become a , that then might become , each of those changes look valid in isolation but if there’s only a single i < FOO in your codebase you introduced a bug by spooky action at a distance. (overflow on int is undefined behaviour in C, in case anyone is wondering what the bug is).
…never believe anyone who says “C is a simple language”. Their code is shoddy and full of bugs and they should be forced to write Rust for their own good.
i <= 9, you heathen. Next thing you’ll do is i < INT_MAX + 1 and then the shit’s steaming.
I’m cooked, see thread.
There’s plenty of schemes that aren’t fully standards-compliant but I don’t think leaving out eval is common – it’s easy to implement and nothing about the standard says that it needs to run code fast.
Just wanted to point out that eval is the real static vs dynamic boundary. As to evil, sure, you shouldn’t run just any code you find without having a sandbox in place, C’s way to do the same thing is to call cc followed by dlopen, that’s way scarier, which is why people just link in lua or something instead. I guess in <currentyear> you should probably include a wasm runtime instead of using dlopen.
Fork. Setting up a whole new project infrastructure, getting fellow developers on board with your putsch and everything can be a PITA but all those are natural hurdles, due to how the licensing works the BDFL has no way to stop you.
As such, as a BDFL you rule by the grace of authority of the bootmaker. If you don’t make sense, if you aren’t respected, sooner than later the community is going to leave you behind.
Rust has affine types and gets close to linear when you include #[must_use] (you can still let _ = foo but at least it won’t be an accident, also, drop code isn’t guaranteed to run and there’s good reasons for that), refinement types there’s a library for that. GADTs… I mean sure trait magic can get annoying and coming from Haskell you’d want to do more in the type system but in the end the idiomatic rust way to do many of those things is with macros. Which, unlike Haskell, Rust actually is really good at. Really good. Tack refinement types onto the language kind of good.
Proving tools, honestly, there’s only one piece of actually proven software (SeL4) and the only language it’s really written in is Coq. Which Rust will never, ever, compete with on its home turf.
Any language containing eval in its spec cannot be (fully) compiled ahead of time, you’ll need interpretation or JIT.
Also last I checked (it’s been a while) Racket compiles to bitcode and then links in a bitcode interpreter. There’s static lisp/scheme compilers but when they come across an eval, they’re going to bail and compile in a JIT compiler or interpreter to deal with that stuff.
Should all be in place. Even nvidia driver support. It’s one of the rare cases where I actually support nvidia on a technical level, that is, having explicit sync is good. I can also understand that they didn’t feel like implementing proper implicit sync (hence all the tearing etc) when it’s a technically inferior solution.
OTOH, they shouldn’t have bloody waited until now to get this through. Had they not ignored wayland for a literal decade this all could’ve been resolved before it became an issue for end-users.
Programs can’t set position or size of windows, period, at most they can ask and then hope they don’t get ignored and it’s good that way. Window management is responsibility of the compositor, not of applications.
At least KDE has support for it that’s about on X11 level, a proper-proper solution is still in the pipeline. And yes you’re seeing right it’s been there for four years.
And nobody wants to rewrite Xorg or understand the code (other than very basic security maintenance).
That’s precisely the point: All the devs got tired of it and started wayland instead.
X12 might happen at some point when wayland is mature, as in a “let’s create and bless a network-transparent protocol so we might have a chance of getting rid of XWayland in 50 years” kind of move.
Yep that’d be Wayland devs maintaining XWayland, which is part of the x.org codebase. There are no “X11 devs”, they’re the ones who started Wayland to get rid of that bowl of spaghetti!
I argue that X11 would have hyperactive development, if we did not have Wayland
Wayland was started by the X developers because they were sick and tired of hysterical raisins. Noone else volunteered to take over X, either, wayland devs are thus still stuck with maintaining XWayland themselves. I’m sure that at least a portion of the people shouting “but X just needs some work” at least had a look at the codebase, but then noped out of it – and subsequently stopped whining about the switch to Wayland.
What’s been a bit disappointing is DEs getting on the wayland train so late. A lot of the kinks could have been worked out way earlier if they had given their 2ct of feedback right from the start, instead of waiting 10 years to even start thinking about migrating.
Making screenshots does, too, which is why that functionality gets implemented at the compositor level. And so will screenreaders. In fact looking at my settings panel KDE does have support for Orca. Dunno how well it’s working but it’s not like the issue is being ignored.
That does not seem to be a stray and yes there’s definitely reasons to take potshots at Gnome. They still don’t support server-side decorations. Everyone is absolutely fine with them not wanting to use them in their own apps, have them draw window decorations themselves, and every other DE lets gnome apps do exactly that, but Gnome is steadfastly and pointlessly refusing to draw decorations for apps which don’t want to draw their own decorations. It’d be like a hundred straight-forward lines of code for them.
And that’s just the tip of the iceberg when it comes to breakage you have to expect when running Gnome.
Wayland kinda is an x.org project in the first place. AFAIK it’s officially organised under freedesktop but the core devs are x.org people.
x.org as in the organisation and/or domain might not be needed any more, but the codebase is still maintained by exactly those Wayland devs for the sake of XWayland. Support for X11 clients isn’t going to go away any time soon. XWayland is also capable of running in rootfull mode and use X window managers, if there’s enough interest to continue the X.org distribution I would expect them to completely rip out the driver stack at some point and switch it over to an off the shelf minimum wayland compositor + XWayland. There’s people who are willing to maintain XWayland for compatibility’s sake, but all that old driver cruft, no way.
Because allow/blocklist are just as old if not even older and are way clearer terminology.
“white” and “black” there are metaphors, the “master” in git branches and SCSI isn’t.
See at some point you have to ask yourself the question whether you’d be opposed to the change if blue-haired college students really into performative politics weren’t a thing. Imagine the idea coming from your slightly computer-illiterate 60yold shop floor boss saying “I don’t want to think about the terms here, I want to do CAD/CAM. Speak English, whippersnapper”.
The false positive problem actually works in favour of the dogs, here: Their noses are excellent they know exactly whether there’s drugs there or not. They also know that the humans can’t tell so it’s easy to get a treat regardless. And they also know to not overdo it.
Even more complicated are cats, figures that they are by and large uninterested in being studied or proving anything to you.
Dogs are way more intelligent than that. LLM tech is basically a way to quickly breed fruit flies to fly right or left when they see a particular pattern.
modules >>> classes, anyway.
Would you be bold enough to write
if (i++ == INT_MAX) break? The result of the increment is never used, but an increment is being done, at least syntactically, and it overflows, at least theoretically, so maybe (I’m not 100% sure) the compiler could be allowed to break out into song because undefined behaviour allows anything to happen.