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