Add support for Cuis-Smalltalk

[fniephaus]

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

• Provide an infrastructure allowing users to pick a Smalltalk image on first launch
• Run Cuis tests as part of TruffleSqueak's CI to catch bugs and regressions
• Port TruffleSqueak code to Cuis to allow for language interoperability
• Generate Cuis-based image for TruffleSqueak
• Evaluate what needs to be done to support live typing (e.g., for the Cuis University image)

Open Questions

• What Cuis base image should be used?
• Which Cuis tests should/could/are safe to run on TruffleSqueak? Here's how they are executed.
• How could the TruffleSqueak code be maintained for Cuis (needs to be kept in sync)?

/cc @jvuletich @hernanwilkinson

[jvuletich]

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

[jvuletich]

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]

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]

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).