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

Huh.

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.

Xcode Unit Testing Shortcuts

I’ve not had a chance to use the latest (within the past 5 years or so) built in Xcode unit testing frameworks, because my needs are pretty specialized. I tend to build my own.

But I’ve been using the stuff in Xcode 10, and it’s pretty dang great. ^⌥⌘G & ^⌥⌘U? Wonderful.

Is Mojave 10.14?

On Apple's MacOS Mojave page, there's no mention of 10.14 anywhere on the page. I find that interesting, and I can't remember if this was the same for previous OS releases.

September 19, 2018

Every couple of years I'll read through a favorite book of mine, Code: The Hidden Language of Computer Hardware and Software. I originally bought it in 2003, and the first time I read Code I couldn't get through it. A bunch of the concepts were over my head and I just didn't grasp certain ideas. Which made me feel a bit stupid because supposedly I was a professional computer programmer. A self-taught professional programmer, but still a programmer.

But if I'm anything, it's stubborn and determined. So I read it again after having more experience and I got farther this time, understood more, and even had a bunch of aha! moments. Things that I sort of knew and kind of understood at the lower levels of the computer clicked into place.

And then later on I read it again and understood more.

Lately I've been having the itch to read it again, but then I thought maybe I'd try something else. Why not do some real coding around some lower level stuff that I kind of understood, but don't completely get? What about libffi?

I've run across libffi before when working with Mocha, which is a JavaScript to Cocoa bridge that my project Cocoa Script uses. libffi is not as low level as you can get, but it is interesting because you get to deal with things like making room on the stack for returning values from functions. You also get handle a bunch of pointers and deal with memory alignment and other fun things that the compiler usually just handles for you. So as a side project, this might be a fun learning experience.

Plus, JavaScript is an important feature of both Acorn and Retrobatch, and probably even more so in future versions of Retrobatch. If it's going to play a big part of Retrobatch I really want to know it through and through and I want things structured the way my particular brain works.

So that's how FMJS was born. It's very incomplete, but it's a start. In fact, just yesterday it could finally load up Core Image and use a filter.

It's also been educational and interesting. And it helps that it's useful too.