[Glass] Seaside Smalltalk-CI build for Gemstone runs out of temp object space

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Tue Mar 29 07:04:05 PDT 2016

On 3/29/16 12:24 AM, Johan Brichau via Glass wrote:
>> On 28 Mar 2016, at 21:32, Dale Henrichs via Glass 
>> <glass at lists.gemtalksystems.com 
>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>> Do you think this would work for you? Any other ideas?
> Sounds good.
> Perhaps: having generic hooks for before and after scripts would make 
> sense as well. There will always be things that are specific to a 
> project that need to be configured somehow.
> But perhaps that’s out of the scope of Smalltalk-CI and is possible 
> via other Travis options. I have not investigated that yet.
SmalltalkCI _is_ the travis environment, so we are able to define 
anything we want, but we have to create it ...

For GemStone, SmalltalkCI is built on top of GsDevKit_home. Once 
GsDevKit_home is installed, the stone is created[1]. Then the project is 
loaded and tests launched bases on the specification in the 
.smalltalk.ston file[2].

I am working with Fabio to arrange to pass in gemstone-specific 
arguments from the run.sh command line[3]. Command line options  can be 
set from within .travis.ym;[4], but my thoughts on run.sh arguments is 
that we want to use them for local control of smalltalkCI - things like 
"create stone named X in an existing GsDevKit_home clone" .

The load and launching of tests is driven by the .smalltalk.ston file 
and the classes are implemented here[5]. The .smalltalk.ston specs are 
mostly shared across Smalltalk dialects, but we can add fields and 
classes that are specific to GemStone ... My inclination for the 
.smalltalk,ston file is that things should be included there that apply 
equally to local and travis runs.

It is possible that to support certain features in SmalltalkCi we will 
have to make changes to GsDevKit_home, but I think that is cool ... like 
I said, I think I will probably be adding (local) batch test running 
support GsDevKit_home so that it becomes simple to run local tests to 
reproduce errors seen on travis or to simply run local tests in batch 
mode without involving travis ...

Changing the TOC means that we have to arrange for a gem.conf to be 
used, since tODE is not currently being run from a topaz command line 
... GsDevKit_home and that means putting a gem.conf into the stone 
directory (where the GsDevKit_home GEMSTONE_EXE_CONF points). We can 
arrange to do this in gemstone/run.sh base on .smalltalk.ston settings - 
and TOC changes are something that would be needed both locally and on 

Setting time zones for the stone is also something that can be done base 
on .smalltalk.ston settings, but in this case one needs to login as 
system user to make the changes ... this is something that is 
straigtforward for trais, but gets a bit dicey for local systems:

   - how do we get the system password, as I haven't cracked this nut 
quite net for GsDevKit_home

But this shouldn't stop us from adding the feature to .smalltalk.ston, 
because it _is_ a useful feature ...

This brings us to Travis/SmalltalkCI environment variables ... very 
useful for setting up test matrices we _could_ use env vars AND 
gemstone/run/sh command line options making it easy to create test 
matrices for travis runs and perhaps parse the .travis.yml file for the 
local GsDevKit_home test driver --- although I don't know of Smalltalk 
port of YAML and I don't think it is trivial?

Sooo we have a lot of different options these are just my thoughts on 
things and I welcome additional feedback and ideas ... nothing is set in 
stone at this point:)


[4] https://github.com/dalehenrich/obex/blob/master/.travis.yml#L10-L11
[5] https://github.com/hpi-swa/smalltalkCI/tree/master/repository
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160329/a6d85498/attachment.html>

More information about the Glass mailing list