The Shape of Everything
A website mostly about Mac stuff, written by Gus Mueller
» Acorn
» Retrobatch
» Twitter
» Mastodon
» Instagram
» Github
» Maybe Pizza?
» Archives
» Feed
» Micro feed
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 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.

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.

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.

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.

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.

The biggest problem I've been running into is getting JavaScriptCore to run garbage collection in a reasonable time frame. The API for doing this, 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:

0 : <CFRunLoopTimer 0x10a2b68b0 [0x7fffa8fe68e0]>{valid = Yes, firing = Yes, interval = 315360000, tolerance = 0, next fire date = 559929410 (-5.33140898 @ 151250457040796), callout = _ZN3JSC14JSRunLoopTimer20timerDidFireCallbackEP16__CFRunLoopTimerPv (0x7fff5537e6d0 / 0x7fff5537e6d0) (/System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore), context = <CFRunLoopTimer context 0x10a7009e0>}

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.

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.

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.