[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 20:03:56 PDT 2016
Hey Dale,
The reasons I explicitly set it to what I want rather than taking one or the
other from the OS are:
1. I don't want an understanding of where they might be different or used
differently inside GemStone. Having them the same seems simpler to me.
2. I sometimes make stones on my laptop which is generally in
'America/Los_Angeles' and then upload those stones to servers that are
generally in UTC and I don't want to have to remember to convert them post
upload. So I set it and forget it after installing/upgrading Glass & Tode
and things.
So to answer your questions:
GLASS mailing list wrote
> 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? ...
I most always override the OS setting on servers so it wouldn't necessarily
be a problem to get it from the OS there, but my laptop is always not UTC.
> 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
If you leave it such that it may pull one from the OS that's fine but I'll
just stick to overriding it as part of the build process with my script.
Its something I'm habituated to at this point.
Aside: What is the value of having two time zones in the stone?
Thanks
Paul
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 .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-tp4886891p4887317.html
Sent from the GLASS mailing list archive at Nabble.com.
More information about the Glass
mailing list