In Croquet that simply falls out of synchronizing computation itself, rather than just state. Since all machines receive the exact same inputs, their physics engines arrive at the exact same results without any need to cooperate.
Vanessa, it has always amazed me how you managed to square the circle and pull a rabbit out of a hat by the way you got garbage collection to work efficiently in SqueakJS, making Smalltalk and JavaScript cooperate without ending up with two competing garbage collectors battling it out. (Since you can't enumerate "pointers" with JavaScript references by just incrementing them.)
>The fact that SqueakJS represents Squeak objects as plain
JavaScript objects and integrates with the JavaScript garbage collection (GC) allows existing JavaScript code to interact with Squeak objects. [...]
>• a hybrid garbage collection scheme to allow Squeak object
enumeration without a dedicated object table, while delegating
as much work as possible to the JavaScript GC,
Have you ever thought about implementing a Smalltalk VM in WebAssembly, and how you could use the new reference types for that?
I would like to speed up some parts of SqueakJS using web assembly. For example BitBlt would be a prime target.
For the overall VM, however, I’ll leave that to others (I know Craig Latta has been making progress).
I just love coding and debugging in a dynamic high-level language. The only thing we could potentially gain from WASM is speed, but we would lose a lot in readability, flexibility, and to be honest, fun.
I’d much rather make the SqueakJS JIT produce code that the JavaScript JIT can optimize well. That would potentially give us more speed than even WASM.
>Where this scheme gets interesting is when the execution progressed somewhat deep into a nested call chain and we then need to deal with contexts. It could be that execution is interrupted by a process switch, or that the code reads some fields of thisContext, or worse, writes into a field of thisContext. Other “interesting” occasions are garbage collections, or when we want to snapshot the image. Let's look at these in turn.
This sounds similar to Self's "dynamic deoptimization" that it uses to forge virtual stack frames representing calls into inlined code, for the purposes of the debugger showing you the return stack that you would have were the functions not inlined.
I always thought that should be called "dynamic pessimization".
Debugging Optimized Code with Dynamic Deoptimization.
Urs Hölzle, Craig Chambers, and David Ungar, SIGPLAN Notices 27(7), July, 1992.
That paper really blew my mind and cemented my respect for Self, in how they were able to deliver on such idealistic promises of simplicity and performance, and then oh by the way, you can also debug it too.
Indirectly, as in I worked on both, and they are directly inspired by ideas from Smalltalk. Both Lively Kernel and Croquet were done by members of Alan Kay’s group.
Have a look at http://www.squeaksource.com/Hobbes/, but don't expect impressive performance. It's not the code in the Bluebook part 4 though. If you want to implement it yourself be prepared that it might take many weekends until it runs as expected; debugging Bluebook errors took many hours.
Yep, I was surprised by the linear stack when I implemented the NoteTaker JS VM with Dan. In the Lively interface, you can stop the running VM and enable the two little checkboxes on the top right to see the whole stack, rather than just the current frame.
Re "the NoteTaker image and VM was also ported to the Dorado": both the NoteTaker image (a.k.a. Smalltalk-78) and the Dorado image were initially generated from Smalltalk-76 running on the Alto. In the Notetaker image there still are branches depending on what system it's running on (see e.g. UserView>>buttons).
Smalltalk-80 was also built on Smalltalk-76 by "backporting" some of the more interesting changes from the Notetaker version, plus adding much more.
Didn't Digitalk Methods and Smalltalk/V also use a linear stack? Self did as well and to make that simpler they made using a block from a method that had already returned an error (an optimization that some have regretted).
About the NoteTaker being too slow to be usable, having used Squeak on 386 and 486 machines I am hardly shocked. On the other hand people would be being Osborn 1 a few years after the Notaker with just a fraction of the speed (but not trying to run Smalltalk, of course).
By the way, quite a bit of information about the NoteTaker on the web is wrong. So I was really glad when Bitsavers got hold of all the original material (mostly memos):
They did and do support version control etc. E.g. even Smalltalk back in the day kept a log of every single change of code in what's called a "changes" file.
"Corrupting the VM" just means that you were editing the stack frame class in the live system running on the VM and as soon as you hit "save", the VM crashes. So you simply run it again. And if needed, replay the changes log up to before the crashing change.
This only takes seconds, and is part of the reason why Smalltalk is so productive.
There’s also an Alto mode https://codefrau.github.io/Smalltalk78/?alto which is closer to what folks used to work with back then