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

[Joachim Tuchel]

Otto,

thanks a million for the insights you're providing here. I'd like to dig 
into a few questions regarding your development process.

One thing that sounds scary to Gemstone wannabees (at least it does to 
me) is the big question of moving/extracting data to use on a separatte 
environment. Like getting a Customer's set of objects from the 
productioon system and moving it to a development/test machine to debug 
and find problems. If you have a big database with a few hundred 
customers' data, a whole db backup might not be a good option.
How do you handle such scenarios with Gemstone? Do you write Smalltalk 
code to extract stuff from Gemstone as XML and move it into Pharo? What 
do you use as a persistence solution for such data? Just the image? XML 
files? Another scenario here is static data (report definitions etc.) 
that you have to move up from your development stage to a test stage and 
finally into the production environment. How do you transport this kind 
of data from your Pharo dev environment to a Gemstone test server and 
then to the production Gem?


How do you test the side effects/behaviour of Gemstone transactions in 
your Pharo image? I mean, you should be able to play back/forth 
ok/cancel games and see if your control flow in Seaside is correct? Is 
there some kind of "Transaction emulator" for Pharo that gives you this?


I know that Gemstone users always laugh about such questions, because 
they found a way to do all this? But as a wannabee, you look at all this 
stuff and just wonder...

Joachim

Am 01.10.13 17:28, schrieb 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
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>