Hi, gt4gemstone is indeed a new project. The initial target of gt4gemstone is actually to support scenario 3). In this situation, even if you develop in Pharo, once you deploy your application you still want to be able to inspect/debug GemStone. In this situation, you want to have the same experience as you do in Pharo, including the extensions to the tools. Indeed, the project also contains an initial code browser (including senders/implementors) and its first target to support quick code modifications. Of course, that browser can evolve and this can lead to a full fledged experience of completely developing remotely from Pharo to GemStone. Calypso is indeed a very interesting project, but at the moment it is Pharo specific. One thing Andrei did in gt4gemstone is serialize the Glamour presentations and browsers. This is quite powerful and fast and adds another argument to the idea that browsers should be built mostly declarative. One direction we brainstormed about with Denis is to learn from the experience of both gt4gemstone and Calypso and find a common ground. But, this is future work. Cheers, Doru

On Jun 23, 2017, at 1:03 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Thu, Jun 22, 2017 at 6:16 PM, Petr Fischer via Glass <glass@lists.gemtalksystems.com> wrote: Hello, I'm curious how _comfortably_ develop software for Gemstone, which is the preferred/best way (and future)?

1) tODE - OK, a decent amount of work was inserted to it to make it work somehow. Decent tools with git support, a lot of windows (autolayouting required), very basic inspector, based on obsolete Pharo3, no autocomplete, weird auto code formating etc. :( Will the development continue (better inspectors, autocomplete, etc)?

2) gt4gemstone - new project based on GT tools, great playground/workspace/inspectors, running in latest Pharo, but again, just basic browser, no autocompletion, no syntax coloring (so far), but modern way What is the plan? Write proper class browser and code editor again from scratch? There is amazing new browser for Pharo, Calypso, which has remote browsing capabilities (but probably different remoting/proxy layer than gt tools) - is possible to utilize this project for remote Gemstone browsing in future?

3) develop in Pharo, then deploy to Gemstone With some compatibility layers, there is possibility to develop application/business logic in Pharo (with bare collections, dicts, containers etc.) and then deploy code to Gemstone and test. Nice scenario, latest modern dev tools (browsers, inspectors, versioning) from Pharo, but on the dev side in Pharo, no transaction logic (test transaction logic with junit impossible/not available etc.), also not compatible class library - so also with drawbacks with different Smalltalk implementation chaos :( I would very much like to get involved with Gemstone dev, but it scratches a bit now.

Hi Hi Petr,

I personally do 3). I like developing on Pharo and keep doing that on each latest stable release. And yeah, you must have some compatibility layers, you must keep a ConfigurationOf working on both platforms, different class libraries (files, etc), etc. This takes time at the beginning, but then it gets easier and easier. I still use tODE for evaluating code (workspace), browsing GemStone specific code (browser), debug (stored continuations), and for developing the GemStone specific code.

4)

I think you made a good summary. In all those cases, you still consider GemStone like both things, the language interpreter PLUS the persistency. There is one last approach which uses GemStone mostly only for "persistence". In this scenario you would use GemStone similarly to what you do with a normal relational DB, that is, you open a connection, then do something. Dale went a bit further and developed a simple Voyage kind of API with this idea in mind. Anyway, below are some interesting links.

[0] https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/articles/gsDevKitServ... [1] https://github.com/dalehenrich/Tugrik

[2] https://github.com/dalehenrich/voyage

[3] http://www.slideshare.net/esug/tugrik-a-new-persistence-option-for-pharo

Thanks! pf _______________________________________________ Glass mailing list Glass@lists.gemtalksystems.com http://lists.gemtalksystems.com/mailman/listinfo/glass

-- Mariano http://marianopeck.wordpress.com

-- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."