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

Paul DeBruicker via Glass glass at lists.gemtalksystems.com
Tue Mar 29 16:25:34 PDT 2016


Hi Dale,

Sure.  I'm just in the habit of using topaz to set it to UTC like this:


set user SystemUser pass swordfish gems myGem

printit
| osTZ |
System beginTransaction.
osTZ := TimeZone fromPath:'/usr/share/zoneinfo/UTC'.
osTZ installAsCurrentTimeZone.
TimeZone default: osTZ.
TimeZoneInfo default: osTZ.
System commitTransaction.
%


So anything that makes it a setting that is automatically picked up and
applied to the same effect sounds good to me.



Paul





GLASS mailing list wrote
> Paul,
> 
> So you'd like to have the following done:
> 
>    TimeZone default: (TimeZone named: timeZoneName)
> 
> where timeZoneName comes from the .smalltalk.ston:
> 
> SmalltalkCISpec {
>    #gemstone:
>      SCIGemStoneConfiguration {
>        #gemConfPath : 'tests/gemstone/gem.conf',
>        #stoneCofPath : 'tests/gemstone/system.conf',
>        #timeZone : 'Europe/Prague'
>      }
> }
> 
> Make sense?
> 
> Dale
> 
> On 3/28/16 5:12 PM, Paul DeBruicker via Glass wrote:
>> Maybe a way to set the TimeZone for the stone to something other than PDT
>> would be good.
>>
>>
>>
>>
>>
>> GLASS mailing list wrote
>>> This looks the first use-case for adding GemStone specific options to
>>> the .smalltalk.ston file[1].
>>>
>>> I would imaging that I would add something like an
>>> SCIGemStoneConfiguration class that would have options for
>>> GEM_TEMPOBJ_CACHE_SIZE or perhaps a relative path to the gem.conf would
>>> be better ...
>>>
>>> It looks like builderCI uses a default GEM_TEMPOBJ_CACHE_SIZE of
>>> 100M[2]...
>>>
>>> Adding a new SCIGemStoneConfiguration class and starting off with two
>>> new options: gem.conf and system.conf seems to me to be the right path
>>> ...
>>>
>>> The .smalltalk.ston file would look something like this with the new
>>> options (subject to discussion with Fabio):
>>>
>>> SmalltalkCISpec {
>>>     #gemstone:
>>>       SCIGemStoneConfiguration {
>>>         #gemConfPath : 'tests/gemstone/gem.conf',
>>>         #stoneCofPath : 'tests/gemstone/system.conf'
>>>       }
>>>     #loading : [
>>>       SCIMetacelloLoadSpec {
>>>         #baseline : 'Seaside3',
>>>         #directory : 'repository',
>>>         #load : [ 'CI' ],
>>>         #platforms : [ #pharo ]
>>>       },
>>>       SCIMetacelloLoadSpec {
>>>         #baseline : 'Seaside3',
>>>         #directory : 'repository',
>>>         #load : [ 'Tests' ],
>>>         #platforms : [ #squeak ]
>>>       },
>>>       SCIMetacelloLoadSpec {
>>>         #baseline : 'Seaside3',
>>>         #directory : 'repository',
>>>         #onWarningLog : true,
>>>         #load : [ 'CI' ],
>>>         #platforms : [ #gemstone ]
>>>       },
>>>       SCIMetacelloLoadSpec {
>>>         #baseline : 'Seaside3',
>>>         #directory : 'repository',
>>>         #onWarningLog : true,
>>>         #load : [ 'ALL' ],
>>>         #platforms : [ #gemstone ]
>>>       }
>>>     ]
>>> }
>>>
>>> Do you think this would work for you? Any other ideas?
>>>
>>> As a side note, I anticipate that the smalltalkCI .smalltalk.ston file
>>> will find a place within GsDevKit_home as both a way of specifying
>>> default attributes (system.conf and gem.conf patchs) for creating stones
>>> as well as supporting scripts for launching .smalltalkCI-based local
>>> test runs, so the things we define here could very easily find their way
>>> into usage for GsDevKit_home beyond running travis tests ...
>>>
>>> Dale
>>>
>>> [1]
>>> https://github.com/hpi-swa/smalltalkCI#complete-smalltalkston-template
>>> [2]
>>> https://github.com/dalehenrich/builderCI/blob/master/build_gemstone.sh#L193
>>>
>>> On 03/28/2016 01:35 AM, Johan Brichau via Glass wrote:
>>>> Hi there,
>>>>
>>>> The Seaside Travis build using Smalltalk-CI runs out of temp object
>>>> space [1].
>>>> The travis log does not mention much, but a local run of the
>>>> Smalltalk-CI build confirmed me this is the case after examining the
>>>> gemnetobject log file.
>>>>
>>>> What would be the way to raise the GEM_TEMPOBJ_CACHE_SIZE for the GS
>>>> environment in these builds?
>>>> I guess this first requires to be able to setup a GsDevKit stone with
>>>> a custom GEM_TEMPOBJ_CACHE_SIZE parameter? Or can we pass this to the
>>>> `serverDoit` command in Tode?
>>>>
>>>> Johan
>>>>
>>>> [1] https://travis-ci.org/SeasideSt/Seaside/builds/118681121
>>>>
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>>
>>> Glass at .gemtalksystems
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at .gemtalksystems
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Seaside-Smalltalk-CI-build-for-Gemstone-runs-out-of-temp-object-space-tp4886891p4887047.html
>> Sent from the GLASS mailing list archive at Nabble.com.
>> _______________________________________________
>> Glass mailing list
>> 

> Glass at .gemtalksystems

>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/Seaside-Smalltalk-CI-build-for-Gemstone-runs-out-of-temp-object-space-tp4886891p4887298.html
Sent from the GLASS mailing list archive at Nabble.com.


More information about the Glass mailing list