[Glass] [GemStone-Smalltalk] Using devKit

[Dale Henrichs via Glass]

Sean,

I've switched mailing lists in my reply and answered in-line...


On 08/05/2015 06:19 AM, Sean P. DeNigris via GemStone-Smalltalk wrote:
> Now that I've got tODE up and running, I've got a few questions:
> - would I set up one tODE per project-under-development?
I assume that when you say "one tODE per project-under-development", you 
are referring to the fact that you can create multiple tode client 
images using $GS_HOME/bin/createTodeImage?

I typically create a set of  tODE client images numbered _0, _1, _2, 
etc. I open a new client image in order to log into a different stones 
at the same time
> Or one stone per
> project
After much playing around, I have found that it is easiest to use one 
stone per project. I keep a set of generic generic stones around 
(similar to the tode client images) that I use for short term projects 
and when I am going to embark upon a longer term project I tend to 
dedicate a stone to that project ...

For the short term projects/stones, I tend share my common set of cloned 
github repos: tODE, GLASS1, seaside, filetree, etc.

For the long term projects I clone a stone-specific git repo (so for the 
seaside32 stone, I have a clone of the github Seaside repo[1]) so that I 
can work on an isolated branch without impacting my other work ... when 
the work is moved to the master branch I then go about updating the 
common repo and loading the new versions from the common repo on demand 
as I cycle into a particular stone ... The `project list` turns a 
project red when the SHA of the loaded version of the project doesn't 
match the SHA of the repo on disk ....

The "soon to be released" version of gsDevKitHome and tODE have built-in 
support for this workflow ...

[1] https://github.com/SeasideSt/Seaside
> which I interact with via the same tODE client?
I tend to have multiple tODE clients open and I typically connect to a 
particular stone on demand - over a typical day, I may do work from home 
in a stone and then more work in the same stone from the office, so for 
me it isn't practical to open a single client against a single stone and 
then use it for all of my work ...

To support this multi-client work, I have shared working directories in 
my /home directory dedicated to a particular project, but accessible 
from all stones where I keep scripts that open up the set of windows 
that I work in and set up my working environment in various ways ... for 
example I will have a /home/go script that is stone-specific so I can 
just run `./go` to get my stone-specific enviroment set up ...

Again the "soon to be released" version of gsDevKitHome and tODE have 
built-in support for this workflow ...

The open windows associated with a stone in a tODE client are not saved 
with the stone when you log out of a tode client session ... but they 
could be ....
> If the latter:
>      - what is the purpose of the devKit stone? Is it just an example?
yes
>      - can I create a new stone via tODD, or must I do that on the command
> line?
creating a new stone is done via the $GS_HOME/bin/createTodeStone bash 
script. In the "soon to be released" version there is a 
$GS_HOME/bin/deleteStone bash script .... i guess there should be a 
$GS_HOME/bin/renameStone baxh script, too
> - how do I get a workspace on a stone? It seems like I must be missing
> something simple because I see I can bring up such a workspace from the
> Category window context menu, but that seems like a convoluted approach.
> Also, the workspace title is "Workspace on aTDClassCategoryList (12)". What
> does it mean to have a workspace "on aTDClassCategoryList"?
In the "soon to be released" version of tODE the system menu has been 
changed to be a full tODE menu and there is a "workspace" menu item that 
opens a workspace for the stone and in the tODE console you can type 
`ws` to get a workspace ... the "workspace menu item in the tODE system 
menu executes the `ws` command ...

Hope this helps and keep those cards and letters coming ...

Dale