Curious about GemStone 3.5

Hi,

I have read in Git issues and mail list some features of GS 3.5 ...
It seems it will support Tonel package format and run a Gem without the need
of a Stone.

It is possible to list features here ?
Or i should wait until official release ?

Some doubts in my mind:
* How the Stoneless Gem will get the classes if it is not connected to a
Stone ?
* Maybe it will be a special Gem with the behavior stored somewhere else (or
preloaded) ?
   - If the Stone is upgraded how this will affect the Stoneless Gem ?

regards,
bruno



--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On 4/10/19 2:00 PM, BrunoBB via Glass wrote:
> Some doubts in my mind:
> * How the Stoneless Gem will get the classes if it is not connected to a
> Stone ?
A solo gem runs with a static read-only extent serving as its "image".
You would use a normal setup with a stone to set up the classes and
objects you want your solo gem to have, shut down the stone, then copy
the extent to be used by the solo gem.

Regards,

-Martin

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

As Martin said, stoneless (we call it "solo" mode) is just
single-session access to an existing, read-only repository.  Classes can
be loaded into a solo session, but need to be reloaded every time a solo
session is started.  Alternatively, you can load all your classes and
objects into a normal GemStone session (with a stone) and commit, then
shut down the stone and access the shut down repository in solo mode.

Norm



On 4/10/2019 2:00 PM, BrunoBB via Glass wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Good questions, Bruno:) ... my replies are below.

On 4/10/19 2:00 PM, BrunoBB via Glass wrote:
> Hi,
>
> I have read in Git issues and mail list some features of GS 3.5 ...
> It seems it will support Tonel package format

Tonel format package loading will be present in GemStone 3.5.0, however,
that support is very limited and has not been integrated into the
GLASS/GsDevKit environment ... at this point in time it is more akin to
doing GemStone fileins -- it installs code into the image, but there is
no package management to speak of ...

At one point in time, the plan was to include Rowan support in GemStone
3.5.0 and Tonel support was added to the base in anticipation of Rowan
replacing the functionality. We are using Tonel format for a small
subset of the base image code. Unfortunately, reality intervened and
Rowan was not complete enough to be included in 3.5.0.

Rowan v1.2.x is in production at a customer site, but v1.2.x does not
quite have the full set of functionality that is needed.

Work has been underway on Rowan v2.0.0 for several months now and
probably has several more months of development before it will be ready
for general availability. When Rowan v2.0.0 is complete, there will more
development needed to properly integrate it into the GLASS/GsDevKit
environment ... Rowan is a replacement for Metacello/Monticello and it
isn't clear to me at this point in time how the two project/package
management systems will be merged together ... right now I am focusing
on Rowan functionality ... I have several ideas as to how they will be
merged, but the real proof is in the pudding:)

Rowan includes a Tonel reader/writer implementation so the likely
solution will be to use the Rowan Tonel reader/writer from within
Monticello ... as we speak I am working on the Rowan Tonel reader/writer
and when I finish this work it would be possible for someone else to
take that work and do the Monticell/Metacello integration (I will still
be busy working on the remaining bits of Rowan:)

> and run a Gem without the need
> of a Stone.
This feature will be in GemStone 3.5.0 and it is called topaz solo. You
will be able to use topaz to read class definitions from an extent
without needing a stone or shared page cache ... you will not be able to
persist any objects with topaz solo (the extent will be read only), but
you will be able to execute GemStone smalltalk code using topaz as your vm.
>
> It is possible to list features here ?
> Or i should wait until official release ?
The release notes and new documentation for 3.5.0 when we release are
the best places to get the full list of features...
>
> Some doubts in my mind:
> * How the Stoneless Gem will get the classes if it is not connected to a
> Stone ?
... the topaz process attaches to an extent that was created by a stone
and reads the classes that are present there ... the extent is basically
a read only image file.
> * Maybe it will be a special Gem with the behavior stored somewhere else (or
> preloaded) ?
>     - If the Stone is upgraded how this will affect the Stoneless Gem ?
for upgrades, you would simply attach a stone to the extent and then run
through the upgrade process ...

Dale

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

Martin/Norm/Dale,

Got it. Thanks for your answers.

How will work the readonly restriction ?

It will be possible to anything but the commit will fail. Or some feature
will be disabled ?
I mean if it is possible to execute GS code then is possible to create
classes but classes are persistent.
So this will be disable or a commit will fail ?

If the commit will fail then it will possible to create objects attach them
to class vars but no commit available.

What was the main motivation to create a solo Gem ?
* To ease the development of Gs_devKit ?
* To execute GS code without performance penalties for persistence ?
* To use a solo Gem for development ?

Regards,
Bruno




--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Martin/Norm/Dale,

Got it. Thanks for your answers.

How will work the readonly restriction ?

I believe that commits will fail or are disabled ... basically you will be running "normally" in the topaz vm ... so all of the smalltalk functionality will work ... with the restriction that you won't be able to save your work to disk ...

 

It will be possible to anything but the commit will fail. Or some feature
will be disabled ?
I mean if it is possible to execute GS code then is possible to create
classes but classes are persistent.
So this will be disable or a commit will fail ?

If the commit will fail then it will possible to create objects attach them
to class vars but no commit available. 

I think that this is the model ...

What was the main motivation to create a solo Gem ?
* To ease the development of Gs_devKit ?
* To execute GS code without performance penalties for persistence ?
* To use a solo Gem for development ? 

I think it was mainly the general case of being able to write executable smalltalk scripts without *requiring* that a stone be up and running ... internally we have a number shell scripts and perl scripts that we use for test drivers and the like and it would be real nice to be able write and maintain these scripts in gemstone smalltalk ...

so GsDevKit_home is one of the use cases ... the Pharo3.0 vm that gets built and run in GsDevKit_home is a good example that there are some things that you can't do in bash --- like extract information from .ston files ... with topaz solo, we could distribute and extent file with the GsDevKit_home code preloaded and quite a lot can be done without ever having to have a live stone running ... you do get to the point where it might make sense to use a running stone to store some of the meta data for the system, but with topaz solo, we can run lightweight scripts without requiring a stone to be running ...

In preparation for topaz solo being available, I've started playing around with smalltalk shebang scripts[1] that are based on using a Tonel class file as a script that could be run using topaz solo or a live stone[2]:

#!/usr/bin/smalltalk
"
Example executable script
"
Class {
     #name : 'Sample',
     #superclass : 'StashScript',
     #category : 'Stash-Scripts'
}

{ #category : 'script execution' }
Sample >> scriptOptions [
	^ {
			#('help' $h #'none').
			#('print' $p #'optional').
	}
]

{ #category : 'script execution' }
Sample >> executeScript [

	opts
		at: 'help'
    ifAbsent: [
			| stream |
			stream := WriteStreamPortable on: String new.
			args size > 0
				ifTrue: [
					stream nextPutAll: '|args| '.
					args do: [:arg | stream nextPutAll: arg; space ] ]
				ifFalse: [ stream nextPutAll: 'no args ' ].
			opts at: 'print' 
				ifPresent: [:optionalArg |
					stream nextPutAll: ' |print| ', optionalArg asString ]
				ifAbsent: [ stream nextPutAll: ' || no --print ' ].
			^ stream contents ]
    ifPresent: [ ^ self usage ]
]

{ #category : 'usage' }
Sample >> usage [
	| dashes |
	dashes := '----------------------------------------------------
'.
  ^ dashes,
		(self manPageClass
          fromString:
'NAME
	sample - example script
SYNOPSIS
	sample [-h|--help] [-p [<arg>] | --print[=<arg>]] [ <positional-args> ]\
		[ -- <topaz-specific-options> ]
DESCRIPTION

	This example script shows how to define command options and positional arguments.

	Use the env var GEMSTONE_SCRIPT_ARGS to define default <stone-name> and other
	topaz arguments (<startTopaz-specific-options>) to be used when running scripts.

EXAMPLES
	sample.st --help
	sample.st -h

	sample.st --print=\`hi there\`
	sample.st -p \`hi there\` arg1

	sample.st --print=hi arg1 arg2
	sample.st -p hi

	sample.st --print
	sample.st -p

	sample.st arg1 arg2 arg3
') printString, dashes
]

You might recognize that the above script is similar to what I've been doing for tODE scripts ... this is all fairly experimental at this point ... I'm basically trying to see how far I can go without having to resort to bash:) So far I've been working with a live stone ... when writing some scripts it is very convenient to be able to use a smalltalk development environment (Jadeite and Rowan in my case) to write the scripts, but I anticipate that you should be able to target a smalltalk shebang script at a live stone or topaz solo ...

Dale

[1] https://github.com/dalehenrich/stash
[2] https://github.com/dalehenrich/stash/blob/master/bin/sample.st

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