Table of Contents

The Gemstone port

The fileOuts are on GitHub.

The origin of the code is VisualWorks and the target is Gemstone.

Log

Sunday, the 3rd of April

The latest version (2.5.3.1) loads without errors.

Big thanks to Richard Sargent, who discovered all the defects and fixed them!

Tests (on Gemstone 3.5.x and 3.6.x): PDFtalk: 499 run, 499 pass, 0 fail, 0 errors Report4PDF: 156 run, 11 pass, 145 fail, 0 errors


older...

There are a number of possible approaches:

Not considered

Decision Matrix

Approach Mangler (VW) Writer (VW) Format Reader (GS) Interpreter (GS)
fileOut30 not extensible? OK Chunk Monticello todo
XML fileOut todo OK XML XMLParser todo
Values todo OK Values OK todo
Topaz input todo OK? Topaz OK OK

The chunk format used by Squeak and Pharo does not support extensions needed for Gemstone (pundles, treat namespaces, …). It also depends on Monticello, which I don't understand. This is not further considered.

XML fileOut would be nice if there would be an XML reader for Gemstone. Then, the fileOut could be extended with special tags for renamings and replacings etc.. On Gemstone, the XML structures need to be interpreted to setup namespaces and compile the source appropriately.

The Values approach is the same as the XML fileOut except that the reader is there (once I ported the Values to Gemstone by hand). The drawback is that it is yet another format for code interchange… (although a good one, I think).

Currently, I tend to favor the last solution where all the Gemstone code for input is generated solely from VW. There is a goodie in the public store (GemKitForStore (Copyright from OOCL)) which may have a Topaz input writer…

Processing steps

1. write code from VW

apapt the code

2. read code in Gemstone

apapt the code