hpi-swa / trufflesqueak

A Squeak/Smalltalk VM and Polyglot Programming Environment for the GraalVM.
MIT License
286 stars 14 forks source link

Add support for Cuis-Smalltalk #154

Open fniephaus opened 2 years ago

fniephaus commented 2 years ago

TruffleSqueak can run Cuis-Smalltalk images and many of its tests. Let's integrate Cuis so that it's easy to run on TruffleSqueak.

Todos

Open Questions

/cc @jvuletich @hernanwilkinson

jvuletich commented 2 years ago

This is a great initiative! Let me comment a bit on your questions.

jvuletich commented 2 years ago

What Cuis base image should be used? At any point in time, the best image to use is the latest. In Cuis we do not maintain separate "stable" releases. So, when taking a snapshot of Cuis, just pull the repo, and run the Cuis?.?-????.image. Currently it is Cuis6.0-5031.image. Additionally, we push numbered updates more often than we save updated images. The latest updates are needed many times for the commited version of optional code packages, so it is best to always load them. So, after pulling the repo, and starting the image, I suggest doing World / Changes... / Install New Updates. Then save the image (perhaps with an appropriate name), and until next repo pull, just use that.

jvuletich commented 2 years ago

Which Cuis tests should/could/are safe to run on TruffleSqueak? Here's how they are executed. Running BaseImageTests.pck.st as you are doing now is perfectly fine. If we find that we want to disable some tests for TruffleSqueak (for instance the 16bit jpegs), we'd mark them in some way in the official Cuis package, so they are skipped for TruffleSqueak.

jvuletich commented 2 years ago

How could the TruffleSqueak code be maintained for Cuis (needs to be kept in sync)? If possible, it would be best not to fork the code, but use the same for Cuis and Squeak. This requires FileTree support for Cuis, with the detail that Cuis FileTree should do cr<->lf conversions on load and save, so files follow the historical ST-80/Squeak cr file convention. Additionally, if some incompatibility between Cuis and Squeak arises, we'd address it with a SqueakCompatibility extension for Cuis, or some other solution. I'm willing to help with all this. We'd resort to code forking as a last resource only, for example for GUIs that are today incompatible (although porting ToolBuilder to Cuis is also possible).