[Glass] GsDevKit_stones - questions

[Kurt Kilpela]

Marten,

>- when using createStone.solo, startStone.solo - only the license key
located at $GEMSTONE/sys/community.starter.key is used. The configuration
value KEYFILE is not defined anywhere
The solo session uses the community license key because it doesn't need a
special key. The stone key can be configured in systems.conf in the stone
directory.

Is this causing some specific problem to have the .solo scripts use the
community key?



>- when I create stones with different templates (--template=)  I sometimes
must define tode-stuff (default_seaside) in the registry, sometimes not
(minimal).
What command and arguments are you using to create a stone showing this
problem? I wouldn't expect tode unless the template contains `#tode :
'enabled'`.



>** Environments for solo scripts **
If you set GEMSTONE, superDoit will use this GEMSTONE directory to run. You
shouldn't set GEMSTONE when using GsDevKit_stones/superDoit. Here is an
example script and usage to allow you to run low-level GemStone commands
without polluting your environment.

Script:
```gemstone-command.sh
#!/usr/bin/env bash

export GEMSTONE=/path/to/GemStone64Bit3.7.1-x86_64.Linux
export PATH=$GEMSTONE/bin:$PATH
export MANPATH=$GEMSTONE/doc

exec "${@:1}"

```

Usage examples:
```
# Run gslist command with the exhaustive flag
./gemstone-command.sh gslist -x

# Get a shell with GEMSTONE and PATH set
./gemstone-command.sh bash
```

(Note, you can pass a GemStone version as an argument to the
GsDevKit_stones script to tell it to use that GemStone version instead of
the 3.7.0. For instance, `$GSDEVKIT_STONES_ROOT/bin/install.sh 3.7.1` will
cause GsDevKit_stones/superDoit to use 3.7.1. Right now, it only permits
3.7.0/3.7.1.)



>*** How to change code below directory "src" ***
Could you run the script with the `-D` flag and share the stack? I need
more information to give a good answer.

Kurt

On Mon, Dec 2, 2024 at 11:16 AM Marten Feldtmann via Glass <
glass at lists.gemtalksystems.com> wrote:

> Hallo Dale,
>
> ok, I thought, that I got the stuff to a point, that I can use it in our
> runtime environments, but the config files and the environment variables
> are partly not correctly defined - as an example:
>
>
> - when using createStone.solo, startStone.solo - only the license key
> located at $GEMSTONE/sys/community.starter.key is used. The configuration
> value KEYFILE is not defined anywhere
>
> - when I create stones with different templates (--template=)  I sometimes
> must define tode-stuff (default_seaside) in the registry, sometimes not
> (minimal).
>
> - If tode stuff must be defined, I get strange GEMSTONE_DATADIR (e.g.
> /datadisk/pas/work/tode3/sys/local/server/stones/catipf10) definitions.
>
>
> ** Environments for solo scripts **
>
> That was funny one. If one changes the GEMSTONE environment variable (e.g.
> in bash script to call low-level gemstone tool) and execute a solo script,
> it will be executed in that Gemstone database - but the code in
> GsDevKit_stones actually is based on 3.7.0, so it fails if its an older
> stone.  Don not know how to handle this.
>
>
> *** How to change code below directory "src" ***
>
> If I want to change the code under GsDevKit_stones/src ... how do I get
> the changed code to be executed. If I change the code and try to use it I
> get "Attempt to modify invariant object (markWrittenC)"
>
>
>
> Marten
>
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20241202/64557cc7/attachment.htm>