ID:2404815
 
Man this week has flown by, but I'd say it's been a success. Some of it was blown by an unexpected bout of fatigue, after a bad flu shot reaction ruined a night's sleep and left me zombified the next day. The good news is all is well now, and hopefully the flu vaccine will actually be effective this year. Gentlemen, place your bets. Or better yet, just donate or become a Member or sign up on Patreon. (Ha! I opened with a plug. Bet you didn't see that coming!)

On Monday I released build 512.1452, which made a major change to compilation times resulting in enormous speedup. I mentioned that last week but the official release wasn't till Monday. Everything appears to have gone really well with that, except a minor issue with static vars which I fixed in the subsequent 512.1453 build yesterday.

Another bug report of an obscure crash in 512 related to animating filters finally panned out, as I ultimately discovered the cause of the crash and why it wasn't coming up in testing. The server keeps a list of internal filter references that are basically short-lived objects describing the source object and which filter (by number) is referenced. The animation code was holding onto the address of one of these references, but the growth of the array it was in caused that address to change. Solution: reference everything indirectly, which saved the day. The reason this never showed up in any prior tests was because as I mentioned, those refs are supposed to be short-lived, yet this project was apparently holding onto some for way longer; in most cases the array wouldn't have been expected to grow beyond its initial allocation.

I spent a bit of time looking into more compiler issues, but this time on the IDE side of things. The object tree has needed some love for a while, mainly in the fact that for some projects it takes forever to generate and it can also take forever to update. When I did a quick profile I discovered most of the time was being spent in tree UI routines instead of the actual work of looking through compiled nodes. To fix this I made a change that allowed me to work with the tree "offline" and then copy it over, and while that was ultimately a success it also took some doing because I ran into multiple snags along the way.

I think the IDE needs more love and so it might be worth diverting a little more time to it shortly.

Meanwhile another small bug was found to have appeared in the aftermath of the string refactor, and that had to be dealt with in build 512.1453 as well. This specifically was in fcopy_rsc() or anything that used it, when adding named files to the cache.

Although we observed Columbus Day on the 8th, or what the SS13 community is now calling Lummox Day thanks to the compiler speedup, today is the real Columbus Day. So in honor of that genocidal maniac who ridiculously believed the earth was way smaller than it actually is, go ahead and celebrate by not taking the day off--because unless you're a student or work in a school or bank or government job, it's not a real holiday and you don't get it off anyway. Hey, I didn't take it off either, and that's why we have Lummox Day.
All hail our Glorious Supreme Leader Lummox!
Columbus found one new world, which was revolutionized by new bugs (i.e. diseases) and new tech (guns, etc), changing it forever. Lummox finds many new worlds BYOND, then gives them light-speed new tech (though sometimes a few bugs sneak in, too). Who is the greater space pioneer? You decide!