THE FUTURE...

Step 1: Run to the store to buy a USB card reader because all of a sudden you have a need to use a 16Mb CF card that was tossed in a junk drawer for 20 years (hoping it still works, of course), but that was the easy part...

Step 2: Realize that the apps - your own - you want to run on your new (old) Casio E-125 PocketPC (to re-live "glory" days) are compiled in ARM format, not MIPS, which is the CPU this device uses, and the installer packages you have FOR YOUR OWN APPS don't include MIPS, only ARM (WHY DID I DO THAT?!), so, the saga REALLY begins...

Step 3: Get a 20-year old OS to install in a Hyper-V VM... find out that basic things like networking don't work by default because the OS is so damn old, so spend hours solving that and other issues to get it to basically run well enough to...

Step 4: Get that OS updated so that it's at least kind/sorta/maybe (but between you and me, not really!) safe online, all without a browser that will work on ANY modern site (oh, and good luck finding a version of Firefox that runs on it - that all took a few hours)...

Step 5: Okay, OS is ready to go, now get 20-year old dev tools that you haven't even seen in that many years working. Oh, do this with a missing CD key and ISO's that weren't archived in a format that's usable today, plus a bunch of missing dependencies because the OS is, again, SO old (a few MORE hours)...

Step 6: Get 20-year old code written in a language you haven't used in probably almost that long to compile, dealing with pathing issues, missing libs, and several other issues, all the while trying to dust off long-dormant knowledge somewhere in the deep, dark recesses of your brain... surprisingly, it all came back to me, more or less, in under an hour, which lead to...

Step 7: FINALLY get it all to work, FINALLY get the code to compile, FINALLY get it transferred to the device (which has no network capabilities, by the way, which is where the card reader and CF card came into play) and re-live the glory of your old, crappy PocketPC apps and games running on the real thing! WOO-HOO!

Step 8: Realize it's 3:30am by the time that's all done and be VERY thankful that you're on vacation this week or work tomorrow would SSUUCCKK!!!!

Step 9. Get called into work the next day for a production issue despite being tired from the night before and an afternoon of errands, lose basically a whole day of vacation (7 hours spent on it) and not actually resolve it by after midnight when you finally say that's enough :(

Talk about your highs and your lows.

Sorry, need to vent.

In my current project I'm using two main libraries [slack client and k8s client], both official. And they both suck!

Okay, okay, their code doesn't really suck [apart from k8s severely violating Liskov's principle!]. The sucky part is not really their fault. It's the commonly used 3rd-party library that's fucked up.

Okhttp3

yeah yeah, here come all the booos. Let them all out.

1. In websockets it hard-caps frame size to 16mb w/o an ability to change it. So.. Forget about unchunked file transfers there... What's even worse - they close the websocket if the frame size exceeds that limit. Yep, instead of failing to send it kills the conn.

2. In websockets they are writing data completely async. Without any control handles.. No clue when the write starts, completes or fails. No callbacks, no promises, no nothing other feedback
3. In http requests they are splitting my request into multiple buffers. This fucks up the slack cluent, as I cannot post messages over 4050 chars in size . Thanks to the okhttp these long texts get split into multiple messages. Which effectively fucks up formatting [bold, italic, codeblocks, links,...], as the formatted blocks get torn apart. [didn't investigate this deeper: it's friday evening and it's kotlin, not java, so I saved myself from the trouble of parsing yet unknown syntax]

yes, okhttp is probably a good library for the most of it. Yes, people like it, but hell, these corner cases and weird design decisions drive me mad!

And it's not like I could swap it with anynother lib.. I don't depend on it -- other libs I need do!

Decided to change how my game engine asset loading and sorting systems work, giving up on making everything editable JSON files just so it's easier to manage and actually build things.

Currently trying to work out a way to load all of the packages sprites into 1 singular asset bundle and here is the evolution so far...

Revision 1: Compiles a single 328KB PNG into a 24MB file in 190 seconds.

Revision 2: Compiles same image into a 24MB file in 5 seconds.

Revision 3: Compiles into a 16MB image in 4 seconds.

It's not much but it's a start :-D

(Still haven't built a loading system so who knows if it works yet ¯\_(ツ)_/¯)

I just got my third 128GB MicroSD card off Amazon, this time SanDisk. Yet again, trying to do anything not involving the OEM full-disk exFAT partition staying intact (which, fuck that, all that uses that is Windows and Linux, i'm looking for splitting this thicc bih up) shifts EVERYTHING, including MBR+PT/GPT down the disk by 16MB exactly inserting data from... the atmosphere? whatever's using it? ...do SD cards have that secure key/DRM store space thing still?

(EDIT: I do verify that they ARE genuinely the right size after purchasing before reformatting or repartitioning, by the way.)

First it was a Silicon Power card, then a Samsung card, now a SanDisk.

(Also, why all S?)

Luckily, this time it wasn't a pain in the ass to get it to read as anything but "Bad Card" or a 0-byte/empty/non-existent device in Windows/Linux (respectively) so I was able to see that it was indeed the same issue without taking 3 days to jump through device hoops to finally get it to do it again but in such a way that it shifts out and back in all zeroes.