Skip to main content

SqueakJS runs Etoys now

TL;DR: Try Etoys in your web browser without a plugin (still buggy, but even works on iPad). Feedback from more platforms is very welcome, and fixes to improve the compatibility, too.
Half a year has passed since my initial release of SqueakJS. Now I can report on some significant progress since then.

For one, I adopted a UI layout similar to Dan’s Smalltalk-72 emulator, where the debugger interface is only visible when the system is stopped. Now that the basics are working, there is no need to show the debugger all the time. Try it yourself at the Lively page.


But more importantly, many more subsystems are working now. BitBlt is almost complete (all the important modes are implemented), WarpBlt works (for scaling and rotating morphs), the image can be saved, an emulated file system supports reading and writing of persistent files. This now is enough to not only run the very old and undemanding “mini.image”, but SqueakJS now can even run the very latest Etoys image, the same version as on Squeakland. Beware of the many incomplete features and outright bugs still left to be fixed, but try it for yourself here.

While Etoys feels a lot slower than the MVC “mini.image”, and some operations take many seconds, it is surprisingly responsive for normal interaction. On the browsers with the fastest JIT compilers (Safari on Mac, IE on Windows) it is almost good enough, even though no serious optimizations were done yet. It is also interesting to see that some browsers (Chrome and Firefox) are currently significantly slower. And not just a little slower, but Safari outperforms Chrome by 200% for this workload! This is likely due to Safari›’s excellent LLVM-based FTL JIT.


The remarkable thing about the screenshot above is how unremarkable it looks. Apart from the missing white oval behind the “Home” label it looks just like it’s supposed to. In comparison, a week ago the screen still looked like this:


The difference is that Tobias Pape and I added support for Balloon2D rendering. This is Squeak’s default vector rendering engine, originally created by Andreas Raab to show Flash animations. But unlike the rest of the SqueakJS VM, we did not port the original code. Instead, our plugin intercepts the drawing commands and renders them using HTML5 canvas drawing routines. While still far from complete, it can already render one kind of important shapes: TrueType font glyphs. They are defined by Bézier curves, which need to be rendered with anti-aliasing to look nice. And now that we can render text, the graphics are almost complete. Many more details still need to be implemented, especially color gradients.

This highlights one strength of Squeak: The VM and its plugin modules present a well-defined, stable interface to the outside world. That is what makes a machine truly “virtual”. In contrast, other systems rely on FFI (the foreign function interface) or similar techniques for extension. While convenient during rapid development, it does not keep the interface small and stable. That interface is overly broad and unpredictable. Typically, client code must be special-cased per platform. It's calling C functions directly, which may or may not exist on a given platform. That makes it much harder to move the system to another platform, and in particular one that is completely different, like the web browser. The Squeak Etoys image on the other hand did not have to be modified at all.

What I’d like to see fixed in Squeak is that there should be working fallback code for all non-essential primitive functions. This would make it much easier to get up and running on new platforms.

For SqueakJS, bugs need to get fixed, and many features are still missing to run Etoys fully. Adding support for other Squeak releases than Etoys would be great (closure/Cog/Spur images). Contributions are welcome: fork my github project.

Comments

It keeps crashing in Safari on my Mac (running OS X Yosemite). Date: Jan. 4, 2015.

And it's abysmally slow in Chrome.
Vanessa said…
Richard: the Safari crashes have been reported. It looks like a bug in WebKit's FTL JIT.

SqueakJS is very demanding, as you discovered, so the JavaScript VM gets exercised in unusual ways, leading to the discovery of problems in browsers. E.g., one optimization problem was fixed in Chrome after I reported it.

The overall speed of curse depends on what you do with it. Running a full Etoys image is very expensive, that's why it is still really slow. For now, it's amazing that it works at all. It takes no shortcuts.

With lighter workloads, such as what e.g. Amber would be doing (basically generating some HTML via DOM) I would bet SqueakJS is competitive. Try e.g. my JSBridge demo (which could be made to load faster by not filing in the bridge code on startup).

In raw execution speed SqueakJS currently is 3x faster than Amber in Chrome as measured by "0 tinyBenchmarks", even though it implements the complete Smalltalk semantics.

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is Croquet.io, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: can be hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully controls the inputs to these identi

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Emulating Smalltalk-76

If you got as excited as me about Dan Ingalls' live Smalltalk-76 demo on an actual 1970's Xerox Alto, you may have wanted to try it yourself.  For one, you could try my Smalltalk-78 VM. Smalltalk-78 is a leaner version of Smalltalk-76 but very much identical in syntax semantics.  It is also possible to run the full Smalltalk-76 environment, and here is how: First, you need an emulator for the Alto computer. Ken Shiriff posted a nice piece on how to run ContrAlto on Windows . It is written in C# and I got it to work on my Mac using Mono. So here's a step-by-step: Install Mono from  http://www.mono-project.com/download/ Download ContrAlto-mono.zip from https://github.com/livingcomputermuseum/ContrAlto/releases Download this Smalltalk-76 disk image: http://www.bitsavers.org/bits/Xerox/Alto/disk_images/chm/xmsmall.zip Unzip both  ContrAlto-mono.zip  and  xmsmall.zip  in the same folder. In a terminal, change to the ContrAlto directory and run mono Contralto.exe .