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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

GLASS mailing list
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.

Thanks! pf
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] How do you develop for gemstone in open source tools (pharo)?

GLASS mailing list
Hello,

several ways to do programming under Gemstone.

I personally use Jade (under Linux using WINE) the whole time. No
support for git, but following the traditional browser concept of
Smalltalk.

Still missing some development point and has limitation - but for the
traditional developer a fast lane into Gemstone/S

Marten


Am 22.06.2017 um 23:16 schrieb Petr Fischer:

> 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.
>
> Thanks! pf
>


--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: How do you develop for gemstone in open source tools (pharo)?

GLASS mailing list
In reply to this post by GLASS mailing list


On Thu, Jun 22, 2017 at 6:16 PM, Petr Fischer via Glass <[hidden email]> 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. 




 
Thanks! pf
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: How do you develop for gemstone in open source tools (pharo)?

GLASS mailing list
In reply to this post by GLASS mailing list
Hi Petr,

I have used or attempted to use Jade (not on your list), tODE, and Gt4Gemstone.

I wish that all three of them were combined together.

This is my experience.

1) Jade - only runs on Windows so you need vmware or wine (as Marten noted). I also agree it is the most similar to a ‘regular’ development environment.
    I have not used it lately and I think I could not change the code inside the debugger. It is a useful tool.

2) I am using tODE for the last two months. It is a very different way of looking at the world where some of the concepts are very useful while others take some getting used to.
    There is not a traditional browser. Rather the browser is made up of independent windows and the code pane can be changed from different places without changing the selected class
    or method. This take a lot of getting used to. It takes a while to get used to it.

    I have ended up having two or three tODE clients open at the same time so I can have effect of separate windows browsers. Issuing a commit/abort ensures the clients are in sync when
    you switch between them. I use one client for my main development work and the other(s) for research, etc.

    One can change code in the the debugger! This is very useful.

    The S-Unit testing window in tODE is also useful.

    The undercover work that has been done to make tODE integrate with the Gemstone file structure has some very good promise.

    BUT the learning curve is steep. Watch Dale’s presentation(s) on tODE to get a feel for it.

    Also, the fact that ‘browser’ commands are separated from the UI is very useful. Ex: ‘browse class Array’ would make the Array the current class in the browser.

    What does it need:
        1) A history of one’s commands. The topez window keeps its history but clicks on UI window items are not stored as history. This would make using the environment much easier.
        2) Much better documentation. (Dale is helpful!).

3) Gt4Gemstone
    This is a very exciting approach.
    The Glamour Browser’s configurability great. Being able to write customized views/inspectors is what is needed.
    However, it does not have a hierarchy browser and I live in the hierarchy when I am working.
    Also, the debugger is ’nicer’.
    But there is no Sunit Test window that I could find.
    There is no colour syntax highlighting!
    Also, there could be a lot more menu items attached to the browser to make it easier to navigate.

4) Pharo and move code to Gemstone
        What I am working on has some Gemstone specific features so this was not an option for me.

So I am working primarily in tODE but I also use Jade and Gt4Gemstone as well as additional client tODE clients as my work environment.

Lack Of Refactoring Tools:
=====================
These are not available at the current time in Gemstone so none of the Gemstone only environments support this.. I understand work has been done on porting the Refactoring Tools but not all the tests pass yet. This is the single biggest deterrent to development in Gemstone. I have recently did some significant refactoring of my code and compared to client development environments (VA, VW, Pharo, etc), it took me at least twice as long to refactor the code.

I hope this helps.

Regards,

Reg

> On 22 Jun2017, at 5:16 PM, Petr Fischer via Glass <[hidden email]> 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.
>
> Thanks! pf
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] How do you develop for gemstone in open source tools (pharo)?

BrunoBB
This post was updated on .
In reply to this post by GLASS mailing list
Hi,

Actually i use Jade and also use GIT.

Inside Jade i save packages to disk (in FileTree format) then using command line i upload the code to Github.

Is pretty simple.

Maybe this can be added to Jade code base using the lastest version of GemStone where you can interact with a OS process (to enter user and password). -not sure 100% if it possible-

(although the aim of Jade is to be able to work with any GS version even 32bits)
If it is possible the feature can be enable only to some GS versions.

Just a though...

regards
bruno
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-users] How do you develop for gemstone in open source tools (pharo)?

GLASS mailing list
In reply to this post by GLASS mailing list
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 <[hidden email]> wrote:
>
>
>
> On Thu, Jun 22, 2017 at 6:16 PM, Petr Fischer via Glass <[hidden email]> 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
> [hidden email]
> 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."




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass