[Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE

[Johan Brichau]

Hi Mariano,

We're doing "develop in Pharo, deploy in Gemstone" for a couple of years now.
After what Otto and Norbert said, I feel I have very few things to add.

Since we are GLASS users, we are only using GemTools and Topaz to interact with a running Gemstone.
We hopefully will be able to test-drive tODE really soon (hint hint ;-)

GemTools is used to debug and develop gemstone-specific parts of the application. Whenever an error occurs in Gemstone, a continuation is pushed onto a persistent log (aka ObjectLog) and this can be easily inspected and debugged using the Smalltalk debugger in GemTools afterwards. We either debug directly on a production system or we make a backup copy to restore on our local machine and debug from there. When we need to develop against specific Gemstone parts (things like indexes for example), we develop on a local Gemstone install.

Topaz is used to execute scripts. All upgrades (running metacello load and migration code) is run via a topaz script that is launched on the commandline. We never use Topaz for anything else.

> Now that I have this thread already open ;) I wonder if someone has ever written some "port rules" or things to be aware when deploying to GemStone. I guess certain Pharo kernel classes/methods may not exist or answer something different, etc... And I think the answer would be around Grease?  In other words, what I ask is the following: imagine (it is not the case unfortunately) I don't use any other library than seaside/magritte. What are the things that would make the port to gemstone complicated? Is there any list or conventions somewhere?

It depends a bit what you will be making. If it's a Seaside app, the chances are that most things that work in Pharo will also work in GLASS. I am saying GLASS because the additions in GLASS to Gemstone are what makes it behave sufficiently close to a Pharo with image-based persistency.

There are a couple of differences we learned to "know" and there are things we wrapped in a compatibility package (some parts contributed back but most pending).
We also used an Abstract Factory pattern to differentiate those parts of the application that need Gemstone-specific code. This is mostly when we are dealing with indexes or some very specific Gemstone stuff we came to use over the years.
We also made DALi: an abstraction layer for transactions that makes the app run transparantly with GLASS, Pharo-GOODS and Pharo-image-based-persistency. The library works very well but I guess it needs work/explaining to make it useable/understandable for others. To appreciate its abstraction, you need to understand how GLASS transactions for Seaside work.

Here are some other rules that pop to mind:
- The Gemstone compiler is more strict than Pharo's (shadowed variabes, empty statement will not compile). Grease has some "code portability" code critics which detect these cases so you can prevent them in Pharo too.
- Assignments to temporaries to transfer values from one Seaside callback to another does not work in Gemstone (not even 3.x). This is often used in Seaside methods where you have multiple callbacks being triggered in the same action. There is a very easy workaround: use a valueholder object to hold the value. 
- GemStone's DateAndTime implementation (and related parts) includes daylight savings time (while Pharo's does not). This is great for us, but you need to know that some days have 23 hours durations and some have 25 hour durations ;-)
- Use Grease when possible or plug factory methods onto the Grease framework (using class extensions) when you need them in your app