[Glass] How do you develop for gemstone in open source tools (pharo)?

[Mariano Martinez Peck via Glass]

On Thu, Jun 22, 2017 at 6:16 PM, Petr Fischer via Glass <
glass at 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/gsDevKitServerBlocks.md

[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 at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



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