sin-ack's writings

Hi there. It’s been quite a while since I posted here, mostly due to real life responsibilities. I’m planning on making monthly updates here from now on so that I can showcase the new things that are in ZigSelf. For the first update though, let’s play some catch-up.

Hello there. I have not posted in a while, and not without good reason. In my first article I had mentioned that I was going to make posts about my own implementation of Self called mySelf. That project never took off, and my interest shifted to other things. I had largely forgotten about it, but then LangJam happened.

LangJam

LangJam is a programming jam that works similar to game jams, but instead of developing video games you develop a programming language based around the theme of the jam. When I heard about it back in August, I remembered about my interest in implementing Self, and decided to join the jam. My implementation went largely nowhere, as it wasn’t really interesting from the standpoint of the jam’s theme. However, spending 48 hours to implement the lexer, parser and then a basic interpreter was pretty fun, and I started wondering again.

I got the chance to investigate an interesting bug in SerenityOS this week. It was related to the decoding of JPG images in the operating system. For some reason, when a JPG image is viewed, it comes out like this:

Weird, huh? Also seems like a simple confusion of RGB vs. BGR. And sure enough, making the following change on JPGLoader.cpp:

-   const Color color { (u8)block.y[pixel_index], (u8)block.cb[pixel_index], (u8)block.cr[pixel_index] };
+   const Color color { (u8)block.cr[pixel_index], (u8)block.cb[pixel_index], (u8)block.y[pixel_index] };
    context.bitmap->set_pixel(x, y, color);

makes the image show up correctly. Case closed!

…not. Why did this even break in the first place?

When I first introduced Self, I mentioned that Self is a programming language which employs prototype-based inheritance; it does not depend on a class-instance distinction to facilitate object-oriented programming, but rather, it uses a prototype object from which copies are created. The methods associated with a prototype is stored in a traits object which is just another object storing methods that can be used on a prototype and all its copies through a parent slot.

The trouble begins when we actually try to implement this prototype-based inheritance system as an actual virtual machine, particularly with regards to memory consumption. Say that I have a prototype object point with a constant parent slot pointing to traits point and two assignable slots, x and y.¹ When we copy this object, we would expect to copy all three fields. But if we scale that up, that’s so much unnecessary data being copied! For one, for every copy of the point prototype we make, we’re copying that traits point parent slot reference. Not to mention, because our language is dynamic, we can’t simply treat x and y as offsets into memory, because they might be constant or assignable (Self can’t intrinsically know). So our naive implementation would be pretty inefficient.

Can we make this more memory-efficient? In fact, we can; we can exploit the fact that most Self objects that are copied only ever have their assignable slots modified. Let’s take a look at how the original developers of Self have optimized the memory usage of the Self virtual machine.

In my previous two posts, I talked about Self as the language, and the system which allows it to serialize objects into text format. Now let’s talk about another big part of Self, which is the programming environment and the UI toolkit that it is created from: Morphic.