Something that bothers me a lot in Python is not really Python's fault but when I use it and make a bug and my brain immediately goes
"Nye heh heh heh, if you just had a type system that wouldn't have happened!"
It's just really hard to argue with "this thing that would have otherwise stopped the build and told you to fix your shit is now a runtime error that manifests under specific conditions with a client" and it's just so much wasted comms 'n' work for an easily-caught problem.
This isn't meant to be type system propaganda or whatever, it just keeps smacking me in the face every time I go work in some dynamic language, and every time it just makes me mad. Like, yeah, I get it, I'm an idiot, but that's why we have the tool.
@vitaut@thephd I tried to convert my one big python code base (https://github.com/floooh/fips) to type hints and it was a pain in the ass TBH, because it quickly turns into a "generics-puzzle".
IMHO Python's "journey" towards a "proper" programming language is a dead end, Python shines for quick'n'dirty cross-platform scripting and sloppy glue code (and Python 2.x was just right for that).
When you see this sequence of characters in a Rust program:
|_|
Never mind whether you would ever say it out loud— in your head, what do you think of the name of this sequence of symbols being? Do you have a name for it at all?
I wonder if @andrewrk just added the "unused variables are errors" Zig feature as a honeypot for drive-by-critics to have a common and easy to identify thing to complain about without ever having used Zig or investing the time to provide constructive feedback :D
In that sense it's very similar to the "WASM can't access the DOM" complaint (which is a non-issue but nonetheless a critic's darling).
Computers like the ZX Spectrum had each 8x8 block have 1 bit per pixel, and that 1 bit selects between two colours chosen by an 8-bit attribute. For the Spectrum the attribute had 3 bits for colour 0, 3 bits for colour 1, 1 bit to make them bright, and a completely pointless "flash" attribute.
But what if you had twice as many bits?
Well, you'd have four colours per pixel to choose from, and a 16-bit attribute chunk. So 16/4 = 4 bits per colour. Same as the Speecy. Buuuut....
@TomF@mcmartin@mogwai_poet the little known East German KC85/4 had 8x1 color attributes, and (best and AFAIK unique feature) a "vertical" linear video memory layout at 320x256 pixels (e.g. 40 columns at 256 rows). Writing 8 consecutive bytes fills an 8x8 pixel block. 8x LDI to blit a character, or 16x LDI to blit a character with color.
The big downside of 8x1 color attributes is of course that you had to move so much more data (the predecessor had 8x4 color attribute blocks).
@TomF it would also have helped a lot if Speccy colors were a bit more "diverse". For comparison KC85 again: 3 bits background, 4 bits foreground, 1 bit blinking. The foreground colors were all brighter than the same background color number.
@TomF btw, the "useless" blinking bit could be used for an interesting "fullscreen effect" on the KC85 (AFAIK not on the Speccy though), because the blink frequency was controlled by a Z80 CTC timer channel. This sets the blink frequency to the duration of somewhere between 4 and 5 PAL scanlines which causes this "running image" effect, all without programmable color palette :)
I merged a metric shitton of PRs over the last few days, mainly related to the Sokol Odin bindings, but also a nice debug feature for D3D11 (debug resource labels are communicated to D3D11), and some warning fixes when compiling the D3D11 backend in GCC. Many thanks to @jakubtomsu and GH user @edubart!
Actually found a use case where C flexible array members are useful:
In GLSL, SSBO structs can have a 'non-repeating header', followed by repeated data. This GLSL struct could map directly to a similar C struct by a shader compiler like sokol-shdc...
This doesn't map to non-C languages though, that's why I will probably not allow such header data, at least when using sokol-shdc.
So, I don't really understand the point of Google search any more.
I just checked back in with it for a search query, for the first time in forever, as I wasn't turning up much with the alternatives I use. (Due to the web slowly collapsing under its own weight, sigh.) The first two pages were solid "sponsored" links trying to sell me something, often from stores that demonstrably have nothing to do with the term, and large pictures of the same thing.
@andrewwillmott the worst thing is when you search for regular words or events and Google search just blasts you with products/movies of a similar name. I guess most 'muggles' use Google as exactly that (a shopping guide), but it's infuriating.
It's also interesting because the "western world" and especially the US has been built upon "individual freedom" (dare I say: "extreme individualism"), while Google seems to follow the Chinese/Russian model of "individuals don't matter" :D
This work enables a runtime to transparently and automatically relocate heap objects in unmanaged languages like C or C++ with no changes to the source code.
We do this using a level of indirection well known in the managed languages world: the handle. We present an LLVM compiler transformation that automatically translates these handles whenever they are used. This indirection allows us to relocate objects freely, which enables heap defragmentation in unmodified C programs like Redis and Memcached.
@wanninger@tommy Very interesting! (moving the handle management into the compiler more so than the 'object mobility' feature). Are you aware of tagged handles where the tag is a generation counter for temporal memory safety (aka Generational References)? E.g. see:
@wanninger I wonder if it's feasible to somehow inject user-provided code for creating, 'resolving' (e.g. convert into ptr) and destroying a handle, while keeping the ability of the compiler to track handles and remove redundant 'resolve' calls. Would probably require some serious C attribute magic :)
@isaackuo@eiZen ...the other advantage is that a character can be rendered with an unrolled loop of 8x LDI instructions (LDI copies the byte at address in register DE to the address in register HL and then increments both DE and HL in 16 clock cycles, so an 8x8 character can be blitted in 128 clock cycles.
