FastMail Is Kind of Awesome
I recently switched servers for Flying Meat (to Linode), and as part of that I also switched to using a hosted mail server. I'd been trying out FastMail for a while, and it's pretty awesome. In some ways, it’s even better than Mail.app. The shortcuts for getting around are really awesome.
It almost makes me want to write an email client again, with the same power and shortcuts that FastMail has.
Micro post on November 14, 2018 at 13:21:15
Computational Notebooks and MPW
Thinking more about computational notebooks (Jupyter, RunKit, etc), they are bringing up memories of MPW's worksheet, waaaay back in the day (and of course, BBEdit also has worksheets). They are very different of course, but it makes me smile to see wonderful old ideas being brought forward.
Micro post on November 13, 2018 at 10:26:43
Jupyter Notebook in Nature
Nature: Why Jupyter is data scientists’ computational notebook of choice.
Jupyter notebook showed up number of times at WWDC this past year. Computational notebooks have long been a fascination of mine- VoodooPad had a number of ways to run scripts and accessing data in the various pages from those scripts. Rainier from Brent Simmons might fit that bill some day as well.
Micro post on October 30, 2018 at 12:24:55
The Future of WebAssembly
Mozilla: WebAssembly’s post-MVP future: A cartoon skill tree.
I really like WebAssembly. I think it's going to enable some interesting languages and exploration in and outside the browser.
As it grows though, I worry it's going to become another JVM. And maybe it will be, but hopefully without the memory requirements and crashing nature.
Micro post on October 22, 2018 at 12:34:17
October 20, 2018
Work on my FMJS is coming along. I've been trying things out, having fun looking up symbols at runtime, disassembling code, learning a bit about strict aliasing, and basically organizing things in a way that works for me.
Functions, object creation and method calls, creating, modifying, and passing around structs all work now. And I've got a little test suite using Xcode's unit test framework that's been a wonderful way to develop FMJS and make sure nothing breaks with my changes.
JSGarbageCollect, doesn't actually clean up unreferenced objects when you ask it to. Instead, it schedules the cleanup to happen sometime in the future. And it doesn't happen soon enough for my needs.
I have a test which allocates objects, and waits to see if they go away after cleaning up the JS runtime. They weren't being deallocated. I'm not sure what made me think of it, but I setup a runloop that just spins around until eventually JSCore decides to do it's thing between 3 and 70 seconds later. And then the test passes. But that's an extra 3-70 seconds of just sitting around waiting for my objects to be deallocated.
OK, let's print out the runloop and see what's going on:
OK using that information I was able to find the source code on GitHub that sets up the timers for the garbage collection. In the code a JS CFRunLoopTimer is created, with an interval of a decade (60 60 24 365 10) and a firedate of a decade from when it is created.
OK, so that explains why it's not called in a reasonable time frame. But, 10 years isn't the same as 70 seconds. What's going on? Why is it being called before a 10 year time frame?
I never promised answers. And I have no idea. Runloops are magic I guess.
But, while poking around a bit more in JSCore's source, I did find this private method:
JS_EXPORT void JSSynchronousGarbageCollectForDebugging(JSContextRef);
Which does exactly what it says on the box. No runloops needed.
Obviously, this is a private API. And obviously you wouldn't want to use this in production code. But in a unit test with the right protections around it, I think it's an OK call.
But I still need to figure out how to work around the delayed garbage collection. And I suppose I should write up a radar for synchronous garbage collection.
October 18, 2018
I was complaining the other day about how Mojave still doesn't support writing 16bpc HEIC images (aka, deep color). I know most people still don't quite get why it's important, and it occurred to me that maybe there was another way to talk about it, rather than saying "more bits per pixel!" or "It's deep".
How about, "It's like @2x for color"?
So deep pixels are like @2x images. When we (developers) got our Retina displays, we didn't just size up our existing images with nearest neighbor scaling. That would have created blocky images! Instead, we added more pixels which made our curves more crisp and accurate. The same thing happens when you work with higher bits per color.
You get accuracy. You get less banding. Sure, you could dither your images to hide banding, but that's a temporary hack- sort of like subpixel antialiasing for text is (or was; Apple removed support for subpixel antialiasing in Mojave and iOS never had it).
At any rate, I filed it this past summer as radar://41731847: Mojave does not support writing 16bpc/deep color HEIC images.
The format supports it, and we've got DP3 color profiles on iOS and MacOS now. We just need the encoders to catch up.
Ironically, the introduction of a wider color gamut such as Display P3 will increase the amount of banding in our images, unless you move from 8 to 16bpc.
Brent Tells Us About Frontier
Brent Simmons: Why Create a Frontier-Inspired Scripting App?
I was bugging Brent about this the other day, and I'm happy to see him write it up. I really really like the idea of an object database, but maybe not so much the editing code in an outliner part. I'll give it a shot of course.
Micro post on October 16, 2018 at 9:27:07
September 27, 2018
On Monday I flipped some switches on the FM servers and Acorn 6.2 was released to the universe. You might also remember that Monday a little known operating system from Apple was updated, which includes a neat new feature known as Dark Mode.
I think Acorn looks pretty good in Dark Aqua, especially the icon refresh from Matthew Skiles.
To celebrate the new release, we've put Acorn on sale for 50% off. So go grab it at the insanely low price of $14.99. If you haven't already upgraded from previous versions of Acorn, now is a good time to do so.
We've also packed a bunch of little changes, bug fixes, and compatibility with Mojave in there. And of course, there's more to come in the future as always.
Shoutout to the Core Image Team
I want to give a shoutout to the Core Image team at Apple. MacOS 10.14 Mojave was released today, and in the over 10 years I've been developing Acorn, this has got to be the smoothest and most bug free release day for the Core Image framework I've ever seen.
So many thanks. Most folks won't know or care, but this graphics API guy certainly did.
Micro post on September 24, 2018 at 14:52:34
FMDB Ships in MacOS and iOS
It's not a huge thing, but it puts a smile on my face. Piggybacking on the Apple News app, FMDB is now shipping in MacOS Mojave starting today, and has been shipping as part of iOS for a number of years. That's my software being used on a lot of devices.
Micro post on September 24, 2018 at 10:04:34