[Glass] Can I use tODE in this context?

[Mariano Martinez Peck via Glass]

On Mon, Sep 14, 2015 at 7:03 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> If you look in the $GS_HOME/bin/installTodeStone script you will see (at
> the end) the `installTode $stoneName` command is sent to the pharo vm via
> the command line and this ends up invoking the following tODE shell
> builtIns:
>
>   script --script=installServerTode
>   script --script=installServerTode2
>
> Which themselves cause tODE commands to be loaded from the two files
> `installServerTode` and `installServerTode2` which can be found in the
> $GS_HOME/tode/sys/default/client/scripts directory (you can arrange to
> customize these installation steps by putting the modified copies in the
> $GS_HOME/tode/sys/local/client/scripts).
>
> The `installServerTode` performs the `installServer`  command which
> automatically loads the 4 .ws files I told you about in a previous email ..
> so you've alread done this step.
>
>
Cool. Thanks for the explanation. I get it.



> The `installServerTode2` performs the following commands:
>
>   bu backup --safely tode.dbf   # make a backup of initial tODE install
>   bu snapshot --safely tode.dbf # make a snapshot of initial tODE install
>   script --script=setUpSys      # set up the in-image tODE /sys structure
>   bu backup --safely home.dbf   # backup of initial tODE install with /sys
> structures in place
>   bu snapshot --safely home.dbf # make a snapshot of initial tODE install
> with /sys structures in place
>
> These guys are basically making before and after backups for the
> `setUpSys` script (which itself is found in same directory):
>
>   # Set up /sys node structure
>   mount --todeRoot sys/default /sys default
>   mount --todeRoot sys/local /sys local
>   mount --todeRoot sys/stones /sys stones
>   # ensure that --stoneRoot directory structure is present
>   /sys/default/bin/validateStoneSysNodes --files --repair
>   mount --stoneRoot / /sys stone
>   # Define /home and /projects based on a composition of the /sys nodes
>   mount --stoneRoot homeComposition.ston / home
>   mount --stoneRoot projectComposition.ston / projects
>   commit
>   cd
>
> The `mount` command links a directory on disk to an object the `/` object
> structure in tODE. `--todeRoot` references the serverTodeRoot: field from
> the TDSessionDescription. The implication of the first three commands is
> that you can access $GS_HOME/tode/sys/default, $GS_HOME/tode/sys/local and
> $GS_HOME/tode/sys/stones from within the tODE shell using the paths:
> /sys/default, /sys/local, /sys/stones.
>
> With $GS_HOME/tode/sys/default, it is possible to execute the
> $GS_HOME/tode/sys/default/bin/validateStoneSysNodes command in tODE. The
> validateStoneSysNodes  command creates a set of stone specific disk
> artifacts that are used to define the '/home' and '/project' object
> structures along with the `/sys/stone`which makes it possible to access the
> $GS_HOME/tode/sys/stones/<stone-name> directory without having to query the
> name of the running stone ... makes writing stone independent scripts real
> easy ... `/sys/default/bin/validateStoneSysNodes -h` will bring up the man
> page for this command in tODE ...
>
> After validateStoneSysNodes is run, `/sys/stone`, `/home`and `/projects`
> are mounted. `/home` is where you can access and share scripts/objects and
> `/projects`is where the projectEntries are found for your stone (the
> project list is created based on the list of project entries found in
> `/projects`.
>
>
ok...


> `/home` is actually a composition of the disk directories
> $GS_HOME/tode/sys/default/home, $GS_HOME/tode/sys/local/home, and
> $GS_HOME/tode/sys/stone/<stone-name>/home. If you want to share a script
> with other stones you can copy it to /sys/local/home and all stones will
> see it ... By default scripts created in your home directory are created on
> disk in /sys/stone/home. If you want to see how the composition works/is
> specified, `edit /sys/stone/homeComposition` to see the Smalltalk code that
> is invoked when you access /home ...
>

Ufff this is nice. I really would like to save out scripts to easily run in
different stones!


>
> Basically you just need to execute `script --script=setUpSys ` command
> .... BUUUUUUT you need to make a decision or two first ...
>
> If you want to share the SAME stone directory structure between stones,
> then you will need to arrange to override the default definition of for the
> --stoneRoot option used above .... this is possible but can be a bit tricky
> and possibly error prone (as in tODE might assume things that wouldn't be
> true in your case). In addition to this sticky wicket, I actually think you
> will be happier if you arrange to use a separate stone directory structure
> for each of your stones (I worked in a shared environment for quite awhile
> and the home directory becomes crowded real fast). If you want to do it
> this way, let me know and I will do a bit more research and get back to
> you..
>
> To create the directory structure you only need to copy the directory that
> was created when you created the initial stone using gsDevKitHome ... was
> it called mariano? And you can do that by executing the following bash
> shell command for each stone (like you have a description file for every
> stone):
>
>   cp -r $GS_HOME/tode/sys/stones/mariano
> $GS_HOME/tode/sys/stones/<stone-name>
>
>
Perfect.
Pufffff you know what? I was afraid of doing that CP because I thought this
folder was the one containing all the stone info as well (extent, env
files, etc etc). But I just realized that is
elsewhere: $GS_HOME/gemstone/stones ... what a relief. That was the main
confusion. Didn't know tode has it's own directories too.

Also..I did a grep -R to be sure the stone name was not used anywhere
inside the files inside the folder (those ston files), and there is none ,
so we are safe :)



> Where <stone-name> matches the stoneName: field in your description file.
>
> Soooooo, to hook up your stone to the directory structure, execute the
> following tODE shell script:
>
>   script --script=installServerTode2
>
>
Damn...I am running out of disk space in this small SSD....grrr... Either I
trust and do not do backups (and I call setUpSys directly, and if screw up
I use time machine), or .... we add compressed backups. I tried: 'man bu
backup' but I do not see any option like --compressed which would be super
cool :)

and you'll be ready to rumba... the script does a backup before running the
> setUpSys commands so if we run into problems in your sandbox we can restore
> from backup and try again ...
>
>
OK, tomorrow I will try later with setUpSys without backups...

Thanks!


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