Add support for Cuis-Smalltalk

[fniephaus]

Add support for Cuis-Smalltalk

[jvuletich]

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

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

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