[Glass] Seaside Smalltalk-CI build for Gemstone runs out of temp object space
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Wed Mar 30 07:37:45 PDT 2016
Paul,
I didn't realize that the path /usr/share/zoneinfo/UTC is the same as
(TimeZone named: 'UTC') --- are they the same?
Unless I'm mistaken, `TimeZone default: (TimeZone named: 'UTC')` should
give you the same result as your workspace...
I was initially confused about why you didn't use the "shortcut" and
thought it might be doing things "differently"....
More below ...
On 3/29/16 8:03 PM, Paul DeBruicker via Glass wrote:
> 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.
Setting the TimeZone is a very good idea and in fact unless you are in
the Pacific timezone, absolutely necessary ...
>
> 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.
Makes a ton of sense!
>
>
> 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.
This is where I was confused ... I didn't recognize that you were
setting the 'UTC' timezone explicitly ... I thought that you might be
picking up the os timezone using a different and foreign to me mechanism ...
>
>
>> 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.
Well the main point of this exercise is to allow you to be able to set
the travis builds to the correct timezone for your tests and unless you
roll your own smalltalkCI version you can't do that easily without
adding some monkey business to properly set the time zone ... so I think
that for travis, you'd be able to use `#timeZone : 'UTC'` in the
configuration and get the result you are looking for ...
>
> Aside: What is the value of having two time zones in the stone?
I don't think I was trying to say that there would be two time zones ...
I was confused after all ...
Dale
>
>
> 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.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
More information about the Glass
mailing list