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

Dale K. Henrichs dale.henrichs at gemtalksystems.com
Tue Oct 1 15:33:21 PDT 2013


Mariano,

I would second what Otto recommends ... He is living the "develop in Pharo and deploy in GemStone" life every day and as such has first hand experience and invaluable advice.

GemTools is way past it's "use by date":) and tODE is targetted to replace GemTools. When tODE is ready for prime time, I expect to be providing a new round of documentation (and tODE scripts) for working with GLASS. At worst, tODE will be a better option than topaz, at best ... well, we'll just have to see:) Until then, tODE is still in development, so I would not recommend that you try using it. 

I encourage Otto (and others ... hint, hint) to share more about their processes and procedures ... 

Dale
----- Original Message -----
| From: "Otto Behrens" <otto at finworks.biz>
| To: "Mariano Martinez Peck" <marianopeck at gmail.com>
| Cc: glass at lists.gemtalksystems.com
| Sent: Tuesday, October 1, 2013 8:28:30 AM
| Subject: Re: [Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE
| 
| 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
| 


More information about the Glass mailing list