codefrau

You can run the emulator with a different screen size: https://codefrau.github.io/Smalltalk78/?width=640&height=480

There’s also an Alto mode https://codefrau.github.io/Smalltalk78/?alto which is closer to what folks used to work with back then

This is using my Smalltalk-78 Virtual Machine https://github.com/codefrau/Smalltalk78

For a more modern Smalltalk in the browser you can try SqueakJS https://squeak.js.org/

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.

Absolutely. And you know Lars Bak went from Self to Strongtalk to Sun’s Java Hotspot VM to Google’s V8 JavaScript engine.

My plan is to do as little as necessary to leverage the enormous engineering achievements in modern JS runtimes.

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.

Peep my brain dumps and experiments at https://squeak.js.org/docs/jit.md.html

By dividing up the world into tiles so each player only needs to simulate tiles around their own location.

That’s the reason Brian Upton (Rainbow 6 etc) joined Croquet originally, and used it for his “wide wide world” experiments.

Haha, thanks for the plug, Don!

I just fleshed out the README for my Croquet resurrection yesterday so others may have an easier time trying it. It maybe even contribute :)

https://github.com/codefrau/jasmine

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.

Dan published an updated version of that paper here: https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk....

Would be great if you could cite that one next time. The main improvement for me is not being deadnamed. There are other corrections as well.

Cool. If I had a few free weekends I'd want to make that Smalltalk image run on my SqueakJS VM. One of theses days ...

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.

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.