Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...
Arpa is used for all kinds of random chance things, not specifically for lottery. I feel like ticket would still be the equivalent but I guess that would be more transliteration and opinion than direct translation? Also my view for lottery may be skewed due to the Finnish lottery culture, and how lottery has more meanings in English. Sorry turned ranty.
I remember borrowing a book from the library, which had a type-in checksum program of this sort. It was done like was common for C=64 things of this kind - there's a BASIC FOR-loop iterating through a memory area, reading in bytes from DATA statements you've typed in and POKEing those bytes into memory, not completely unlike entering a program manually from the front-panel switches of an older computer.
So, after typing that in and probably SYSing (C=64 BASIC command for executing machine code from arbitrary memory location) to some address, it did print out a two-digit (eight-bit) hex checksum after every BASIC line I entered on the C=64 and the program listing in the book had the correct checksums for every line, so spotting errors was more or less instantaneous.
This stuff brings memories.
FOR I=40960 TO 49152:POKE I,PEEK(I):NEXT I
POKE 1,54
From top of my head; loop through the BASIC interpreter area, reading byte by byte with PEEK and POKEing those bytes back to the same addresses. Sounds nonsensical? Not so, because the C=64 does have full 64 kB of RAM, but some of it is overlapped by ROMs. What happens here is that you're reading from ROM but writes always go to RAM, so you're copying the BASIC interpreter from ROM to RAM. After that, the POKE statement turns off the ROM overlap and the interpreter is now run from RAM, so you can edit it live - and obviously cause all sorts of interesting crash situations.
It sure did help later with career in IT to have understood this kind of stuff at age of around ten.
I feel this is a side-effect of so many people getting "simple" wrong, as in, calling things simple because they superficially seem so, even while being aware of but ignoring the underlying complexities.
A no-frills X toolkit. Think Athena, add things like dialogs, file picker and make it completely vectored. No antialiasing, top goal is small size and fast execution. Can display vector and bitmap fonts, only external dependency is xcb. I just recently got my first digital storage oscilloscope and begun writing a companion software for it, as I couldn't find anything usable. This is one of the offshoots of that, the other being a somewhat Postscript-like language for scripting the thing.
Once I get this done, I get back to the actual project of a 2.11-BSD based handheld computing appliance.
Does not reflect my experience at all. T420 from 2011 is still completely usable. Haven't clocked the boot-up time but definitely not minutes, more like a couple dozen seconds. Everything worked out of box with latest stable Debian. Can do 2560x1600 over the DP connector, too. This is not even a top-spec model but the slowest i5 available back then.
To be fair, they didn't say /what/ computer from 2011 ran terribly. The Intel Core CPU's were the best back then. There were also Atom netbooks, terrible AMD chips, etc. AMD solidly has the performance crown now, but in 2011 they did not.
Pretty much anything from 2011 that was not a Core i5 or better will probably not run well today unless you use a purpose-built ultralight distro.
I've gotten an OS to run on a new platform with a debugging tool portfolio consisting of a handful of LEDs and a pushbutton. After getting to the point where I could printf() to the console felt like more than anyone could ever ask for.
Anecdote aside, it certainly doesn't hurt to be able to debug things without a debugger if it comes to that.
Since most of my work is in distributed systems, I find the advice to never printf downright laughable.
"Oh sure, lemme just set a breakpoint on this network service. Hm... Looks like my error is 'request timed out', how strange."
That having been said: there are some very clever solutions in cloud-land for "printf" debugging. (Edit: forgot this changed names) Snapshot Debugger (https://github.com/GoogleCloudPlatform/snapshot-debugger) can set up a system where some percentage of your instances are run in a breakpointed mode, and for some percentage of requests passing through the service, they can log relevant state. You can change what you're tracking in realtime by adding listeners in the source code view. Very slick.
I have the 122-key version and a ton of Emacs bindings to make the most out of the 24 function keys and the 12-key panel on the left. It is simply the best.
Dunno how this is supposed to be worded, but it's because the "pointerhood" is tied to the variable being declared, not the type itself. This becomes obvious when you declare multiple variables at once.
char* cat, dog; /* one char pointer, one char */
char *cat, *dog; /* two char pointers */
The trade-off is one vs. two operator sub-syntaxes or in other words "sub-syntax economy". As it is, C has just one operator expression syntax (and one set of operator precedences/associativities). The "forward applicative" expression syntax is "reused" in the "backward" or "inverse" type declarations.
In my native language (Finnish) it's even worse, or better, depending on personal preference - it translates directly to .mildew.lottery-ticket.