dzaima

30 ms·

391.
by dzaima 2y ago
Much as JSON is without a doubt far from perfect, I think most of the article is rather meh. Protobuf won't stop people from trying to put a license keys, card numbers, or other IDs in a 64-bit float or int. All it'll do is make s
392.
by dzaima 2y ago
A "proper" search while still retaining sufficiently-looking randomness might be achievable via an SMT solver, by asking it to find an index above the current position, below a binary-searched top boundary, that contains the searc
393.
by dzaima 2y ago
I'd add: - People think that messages they haven't read will be below ones they have. which is in direct conflict with your first point. Which of the two is stronger probably depends on the person. And indeed it's a tradeoff
394.
by dzaima 2y ago
And then there's the issue on switching between clients (e.g. PC and phone) or otherwise having client state lost - if the complete reading progress isn't saved server-side, then it becomes entirely impossible to restart reading;
395.
by dzaima 2y ago
This might not sound entirely awful in theory, but I'm fairly certain it'd be entirely awful in practice for a good amount of users. Having colored backgrounds might look ugly and thus immediately make that a non-option, and, even
396.
by dzaima 2y ago
That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Grant
397.
by dzaima 2y ago
Aand that brings up another issue - that (and a good amount of things that will work as expected on the default -j1) breaks with -j4. Apparently .WAIT and .NOTPARALLEL exist, which I couldn't find last time I needed something around th
398.
by dzaima 2y ago
I've written a good amount of makefiles (and even one rather complex one.. before replacing it with a thing written in an actually sane language, bootstrapped by a stripped down version of the makefile), and I still mix up $@ $< $&g
399.
by dzaima 2y ago
Filtering requires a filter to exist, which is time alternatively spent doing rebasing (esp. awful if you're not the one who wrote it and now have to make sense of the awful mess to achieve literally anything out of it). And that log c
400.
by dzaima 2y ago
For most things (or, well, that depends on what one commits I guess), the filtered form will likely be the more preferable one. If you want to keep around some of the largely-useless stuff just in case, you can `git tag backup/sso-garb
401.
by dzaima 2y ago
Git blame and bisect do care about the state of specific commits. During development of a thing it should be desirable to be able to handle/test just whatever the current thing is and clean up afterwards if necessary, without having to
402.
by dzaima 2y ago
Not necessarily; if one commit touches all lines (or a bunch), and another reverts that, the blame is thrashed; much worse than having rebased the temp change away. And a commit name of "." is quite significantly less useful in a
403.
by dzaima 2y ago
L3 cache bandwidth is often more than main memory; most systems at https://old.chipsandcheese.com/memory-bandwidth-data/ give at least a ~2x difference from whatever sample I clicked.
404.
by dzaima 2y ago
For an interesting comparison, here's BQN, an array language, at 25.5μs (on an i3-4160) for both parts, including input parsing: https://github.com/dzaima/aoc/blob/master/2024/BQN/1_fast.bq
405.
by dzaima 2y ago
Transpilers are a subset of compilers, even if somewhat often "compiler" is used to refer to the ones producing executables. And .exe-s still need the OS, dynamic libraries, and, perhaps most importantly, the CPU (which is pretty
406.
by dzaima 2y ago
There's the middle-ground approach of having primarily target-specific operations but with intersecting ones named the same, and allowing easily building custom abstractions on top of such to paper over the differences how best it make
407.
by dzaima 2y ago
It is a bit dramatic, though less so for some approaches to programming. And of course prototyping is very different from general purpose programming. With Rust, if you really want the borrow checker to actually never bother you, you really
408.
by dzaima 2y ago
Runtime safety still comes with a good amount of complication source-wise, having to spam RefCell/Arc everywhere, and whatever derefs/.get()s they necessitate, and probably a different approach to passing references. Refactoring e
409.
by dzaima 2y ago
Of note is that even if you have some massive ≥2^48 data sources, you could still quite likely get away with having NaN-boxed pointers to within the low-size heap, with an extra indirection for massive data. This only would break apart if y
410.
by dzaima 2y ago
Knowing non-algol languages won't make editor actions any less useful for algol-like. If anything, it'll just make you pretend that you don't need such and as such will end up less productive than you could be. And editor act
411.
by dzaima 2y ago
SIMD can work quite well here too - with 128-bit SIMD (available on both baseline x86-64 and aarch64) this can be just ≤8 loop iterations checking for the newline character (each iteration counting the number of newline characters encounter
412.
by dzaima 2y ago
With my ~2 weeks of Rust usage, that looks pretty readable. You can freely skip over reading some if not most of the boilerplate, reading just the bits actually doing the main stuff (and whatever context you desire), without fear of having
413.
by dzaima 2y ago
> invariants of data structures are not a practical problem in C. Is that not the cause of like all memory safety vulnerabilities, which are like 30%-or-whatever of linux ones? I've certainly written my fair share of mistakes around
414.
by dzaima 2y ago
More generally, with C you can't restrict what can (accidentally or not) interact with the internal unsafe bits (without the cost of forcing the data to always live in the heap at least; or perhaps annoying field names that are automat
415.
by dzaima 2y ago
A long time ago, "set use-deprecated-index-sections on" improved some things; don't know if any modern compilers need that anymore. I also have a "disable pretty-printer global builtin" in my ~/.gdbinit, though
416.
by dzaima 2y ago
To add on to the pile of more GDB GUIs, here's one I've made: https://github.com/dzaima/grr . Though it's still got a fair bit of missing features that may be essential for some uses (due to my usage bein
417.
by dzaima 2y ago
Right; it's not unreasonable to want to quickly transfer away from it, but it's still a rather short deprecation cycle compared to everything else I've had to touch never being deprecated; it's not an "example"
418.
by dzaima 2y ago
No, most of those are just plain and simple bad outcomes due to not having thought out extremely basic things ahead-of-time. And even if there are problems with actually no simple fix, that in no way means the problem ceases to be a problem
419.
by dzaima 2y ago
At least that means that you will never have messages get dropped due to network issues, or even restarts if you persist the token across such. (the API will jump forwards if there are too many unsynced messages, but at least it should then
420.
by dzaima 2y ago
There are some hilariously ugly things for even trivial things like editing/replies: Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_c

More ›