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

[Otto Behrens]

Mariano,

We've been running a Seaside 3 / Magritte 3 app on GS for a while now.

We develop in Pharo 1.4 (suppose that could be 2). The application
works in Pharo 1.4, almost all tests run in Pharo 1.4. There are a few
very small tests that we run in GemStone only, but to be honest I had
to search for them now because I could not remember - so we rarely
touch them.

We then write the code to filetree and use filetree to load back into
GS via topaz.

The only thing we use GemTools for is to hunt for bugs. If we really
can't understand why the app works in Pharo and not in GS, we use
GemTools to set a breakpoint and figure out what's going on. Once we
know, we exit GemTools and write code in Pharo. Sometimes we edit code
using GemTools just to see how something will work if it is that
specific to GS. Also, sometimes, it helps to inspect data objects
which we only have in a GS DB.

We do not even use GemTools to work on remote GS instances. We only
use topaz for that. Topaz is good enough for most things. In 6 years,
it happened about 2 times that we made a backup of the production DB,
copy it local and then use GemTools to debug.

I would not consider using a GBS based tool, I would just develop in
Pharo, given that you know Pharo pretty well. GemTools is not workable
as a development tool. And I can't imagine that tODE is. That is if
you use refactoring tools, customise your image and run things like
lint.

Some more answers below:

> that running tODE in GemStone could give us the
> functionality we now have in GemTools?

I think so. I think that the energy that would have to go into tODE to
make it more than that would be enormous, but then I would be glad to
hear otherwise.

> 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?

We've used Grease and have some stuff that we did before grease
existed. And we've not been good at contributing stuff. Mainly because
we get under pressure and then soon fall behind, sticking to older
versions. Upgrading is costly. Not sure how to improve this situation.

Having said this, we're willing to help and give anyone stuff we've
done to make the port easier. It is not that onerous. Dale and others
have done a lot; just to get Seaside into GS extended a lot of GS
kernel classes to be Pharo / Seaside compatible.

We have 2 Metacello configs. The one called "Runtime" loads all the
Seaside / Magritte / Whatever tools we use from the community, with
some differences between what we load into GS / Pharo. The other is
our own project that is dependent on Runtime, also with small
compatibility changes between the different environments.

Please let me know where I can give you more info or code.

Cheers
Otto