[-] FizzyOrange@programming.dev 13 points 11 months ago

Yeah it was inspired by Powershell. But it also has syntax that isn't completely awful.

[-] FizzyOrange@programming.dev 13 points 1 year ago

They won't ban corporate VPNs.

[-] FizzyOrange@programming.dev 13 points 1 year ago

Ha this is even worse than I could have imagined!

[-] FizzyOrange@programming.dev 13 points 1 year ago

Gotta agree on the name. Please choose meaningful names especially for low level components like drivers, libraries and CLI tools. It's fine for end-user facing applications to have unique names like Blender, Krita, Inkscape, Chrome, etc. But nobody wants to have to look up what the name of random system packages is.

[-] FizzyOrange@programming.dev 13 points 1 year ago

Use -ffast-math... if you dare. Or just use

inline double position_from_steps(int steps) {
  return (2.0 * PI / 4096.0) * steps;
};

The reason it doesn't optimise it into one multiplication is because that isn't actually the same calculation. Floating point numbers aren't real numbers, so it isn't true that (a * b) / c == (a / c) * b. Since the "optimisation" would actually change the semantics, compilers don't do it by default.

-ffast-math says "hey I don't care about reliable semantics; just do whatever to make it fast". But it also does a load of stuff that you may find surprising. so you really shouldn't use it. Much better just to reorganise your code.

You can also use -funsafe-math-optimizations which is the more specific subset of -ffast-math that does this particular optimisation. See https://gcc.gnu.org/wiki/FloatingPointMath

Also I would question if it matters. This micro-optimisation will make zero difference on x86. On a microcontroller (I assume what you're actually using if you're encoding motor positions) it might matter a bit more but double check your microcontroller even has an FPU. Lots don't. Even if it does, doing it in integer space will probably be faster (though not necessarily).

[-] FizzyOrange@programming.dev 13 points 1 year ago

Ha no. SQLite can easily handle tens of GB of data. It's not even going to notice a few thousand text files.

The initial import process can be sped up using transactions but as it's a one-time thing and you have such a small dataset it probably doesn't matter.

[-] FizzyOrange@programming.dev 13 points 2 years ago

... in one benchmark.

[-] FizzyOrange@programming.dev 14 points 2 years ago

Ask the Rust maintainers to fix it presumably? The antagonist in the video above claimed there are 50 filesystems in Linux. Do they really fix all 50 filesystems themselves when they change the semantics of the filesystem API? I would be very surprised. I suspect what actually happens currently is either

  1. They actually don't change the semantics very often at all. It should surely be stable by now?
  2. They change the semantics and silently break a load of niche filesystems.

I mean, the best answer is "just learn Rust". If you are incapable of learning Rust you shouldn't be writing filesystems in C, because that is way harder. And if you don't want to learn Rust because you can't be bothered to keep up with the state of the art then you should probably find a different hobby.

These "ooo they're trying to force us to learn Rust" people are like my mum complaining you have to do everything online these days "they're going to take away our cheque books!" 🙄

[-] FizzyOrange@programming.dev 13 points 2 years ago

This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.

Interesting advantage of little endian!

[-] FizzyOrange@programming.dev 13 points 2 years ago

That brings more problems. Despite the scaling challenges monorepos are clearly the way to go for company code in most cases.

Unfortunately my company heavily uses submodules and it is a complete mess. People duplicating work all over the place, updates in submodules breaking their super-modules because testing becomes intractable. Tons of duplicate submodules because of transitive dependencies. Making cross-repo changes becomes extremely difficult.

[-] FizzyOrange@programming.dev 14 points 2 years ago

They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.

No they aren't. A higher version of UUID isn't "newer and better", like the word "version" implies. It's just different. It's like they called a car "vehicle version 1" and a motorbike "vehicle version 2". The common use of "version" in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.

The talking pumpkin is 100% right that they should have used "type" or "mode" or "scheme" or something instead.

[-] FizzyOrange@programming.dev 14 points 2 years ago

Very common. Your coworkers are either idiots, or more likely they're just being lazy, can't be bothered to set it up and are coming up with excuses.

The one exception I will allow is for GUI programs. It's extremely difficult to do automatically tests for them, and in my experience it's such a pain that manual testing is often less annoying. For example VSCode has no automatic UI tests as far as I know.

That will probably change once AI-based GUI testing becomes common but it isn't yet.

For anything else, you should 100% have automated tests running in CI and if you don't you are doing it wrong.

view more: ‹ prev next ›

FizzyOrange

0 post score
0 comment score
joined 2 years ago