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

Wed Oct 2 08:44:36 PDT 2013

On Wed, Oct 2, 2013 at 12:24 PM, Johan Brichau <johan at yesplan.be> wrote:

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

Thanks for the answer. We should really keep this thread stored somewhere!
too many valuable information!

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

Ok, this is clear. It's similar to fuel-out a stack in Pharo :)

> 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.
>
>
OK, here I am confused. Why would GLASS help me more than plain GemStone to
run my app? I GUESS this is because Seaside itself needs some extensions to
GemStone (for methods that do not exist there but do in Pharo) or something
like that, hence our app has already covered several of these problems
(those already present for Seaside and friends)?

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

So this is how you solve the fact that special select: and friends for
indexes use a different syntax? because in my case, I would like the app to
continue running in Pharo, so this:

| aTime |
aTime := Time now.
myEmployees select: {:i | aTime == i.name}

will simply not work. Did you delegate to a strategy or Abstract Factory or
similar, or is there a compatibility package for Pharo that can somehow
understand and parse this?

> 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.
>
>
mmm yes. Is it documented somewhere how the Seaside-sessions and related to
GemStone sessions in Glass?

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

interesting!

> - 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
>
>
Cool.

Thanks Johan for sharing this info.

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131002/5ef18a19/attachment.html>