[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 18:09:38 PDT 2016
Hey Paul,
Your script is a bit different than what I was using by default for
builderCI which is `TimeZone fromLinux` which itself calls `TimeZone
fromGemPath: '/etc/localtime'` which is a different path than
/usr/share/zoneinfo/UTC which you are using ... I think that the rest of
the code is the same ...
And picking up the TimeZone from the os is different than setting the
TimeZone to a specific named TimeZone ... are both forms needed or is
sufficient to pick up the TimeZone from the OS? ...
For Travis tests, the TimeZone of the machine may be something totally
unexpected, if your tests are TimeZone sensitive .... but the default
behavior could be to set the TZ from the OS and from the name if not
specified ...
Dale
On 03/29/2016 04:25 PM, Paul DeBruicker via Glass wrote:
> 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.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
More information about the Glass
mailing list