The Gemstone port

The fileOuts are on GitHub.

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

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


There are a number of possible approaches:

  • fileOut VW XML format
    • no XML reader available?
    • nicely extensible with custom tags
    • todo
      • extend in VW
      • write an XML loader in Gemstone
      • interpret in GS
  • fileOut30 ST80 chunk format
    • may load with Monticello?
    • looses namespace and pundle infos
    • todo
      • mangle in VW
      • load with Monticello
  • fileOut GS Topaz input format
    • need to write a writer for this format
    • todo
      • writer in VW
  • fileout Values
    • add transfer values
    • nicely extensible
    • todo
      • define transfer values in VW and GS (same)
      • interpret in GS

Not considered

  • Using GemBuilder for Gemstone (GBS)
    • easy way to move code to Gemstone
    • but, since GBS is commercial, porting and maintaining should not depend on this
    • use it for porting Values?

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…

1. write code from VW

apapt the code

  • class renamings
  • namespace treatment
  • exclude, add or replace methods

2. read code in Gemstone

apapt the code

  • class renamings
  • namespace treatment
  • exclude, add or replace methods
  • gemstoneport.txt
  • Last modified: 2022/04/03 20:07
  • by christian