Seaside Smalltalk-CI build for Gemstone runs out of temp object space
Locked
Seaside Smalltalk-CI build for Gemstone runs out of temp object space
 
|
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 _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
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, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
Maybe a way to set the TimeZone for the stone to something other than PDT would be good.
|
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
That sounds good, too
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@.gemtalksystems >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >> >> _______________________________________________ >> Glass mailing list >> Glass@.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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
In reply to this post by Paul DeBruicker
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@.gemtalksystems >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >> >> _______________________________________________ >> Glass mailing list >> Glass@.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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
Hi,
On 29.03.2016, at 07:40, Dale Henrichs via Glass <[hidden email]> 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', Don't want to be a nitpicker, but this should be #stoneConfPath right? :) Best -Tobias > #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@.gemtalksystems >>>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>> >>> _______________________________________________ >>> Glass mailing list >>> Glass@.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 >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
In reply to this post by GLASS mailing list
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. thanks Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
On 3/29/16 12:24 AM, Johan Brichau via
Glass wrote:
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 travis. 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:) Dale [1] https://github.com/hpi-swa/smalltalkCI/blob/master/gemstone/run.sh#L111-L127 [2] https://github.com/hpi-swa/smalltalkCI/blob/master/gemstone/run.sh#L150-L157 [3] https://github.com/hpi-swa/smalltalkCI/commit/bc072cce2ca7b1657d5b320bc07faa04360af4da#diff-1b0c2b516b83393edb7200ad5ff12181L139 [4] https://github.com/dalehenrich/obex/blob/master/.travis.yml#L10-L11 [5] https://github.com/hpi-swa/smalltalkCI/tree/master/repository _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
Some general thoughts:
- for each of the configuration options there should be a corresponding environment variable (SmalltalkCI_GS_<config-name> perhaps) that can be set in the .travis.yml file and/or used to drive test matrices. An env var overrides the value specified in the .ston file. - for each of the environment variables, there should be a corresponding --gs-<env-var-name> option defined for run.sh. The command line setting overrides env vars and .ston file values Also, I'm inclined to try to add features on demand ... there are quite a few options for controlling the whole system and within the above framework, I think we can get things implemented ... Unless I hear from others, I'm will start work going down this path in the next day or so (working with Fabio on details of the spec and command line args) implementing the following .ston cofiguration options: SmalltalkCISpec { #configuration: SCISystemConfiguration { #gemConfPath : 'tests/gemstone/gem.conf', #timeZone : 'Europe/Prague', #platforms : [ #gemstone ] }, #loading : ['...'] } with corresponding env vars: SMALLTALK_CI_GS_GEM_CONF_PATH SMALLTALK_CI_GS_TIMEZONE and run.sh options: --gs-GEM_CONF_PATH --gs-TIMEZONE Dale On 03/29/2016 07:04 AM, Dale Henrichs
wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
In reply to this post by GLASS mailing list
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
|
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
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@.gemtalksystems >>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>>> _______________________________________________ >>>> Glass mailing list >>>> Glass@.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@.gemtalksystems >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >> _______________________________________________ >> Glass mailing list >> Glass@.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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
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: 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. 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@.gemtalksystems >>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>>> _______________________________________________ >>>> Glass mailing list >>>> Glass@.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@.gemtalksystems >>> http://lists.gemtalksystems.com/mailman/listinfo/glass >> _______________________________________________ >> Glass mailing list >> Glass@.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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
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. 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@.gemtalksystems >>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>>>> _______________________________________________ >>>>> Glass mailing list >>>>> Glass@.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@.gemtalksystems >>>> http://lists.gemtalksystems.com/mailman/listinfo/glass >>> _______________________________________________ >>> Glass mailing list >>> Glass@.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@.gemtalksystems >> http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ > Glass mailing list > Glass@.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 > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
In reply to this post by GLASS mailing list
Johan,
It looks like my recent SmalltalkCI changes{1] fixed your out of temp obj space problem .... without needing to change the size of the temp obj cache ... I wrapped the Metacello load with with a GsDeplouyer class>>bulkMigrate: and that addressed the issue ... Clean GemStone3.1.0.6 build[2] ... I do think that there are improvements needed for the .smalltalk.ston file (I'll submit a PR with my suggestions soon)... but they aren't needed for the tests to turn green for GemStone... Dale [1] https://github.com/hpi-swa/smalltalkCI/pull/123 [2] https://travis-ci.org/dalehenrich/Seaside/jobs/122355269#L6991 On 03/28/2016 01:35 AM, Johan Brichau
via Glass wrote:
Hi there, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside Smalltalk-CI build for Gemstone runs out of temp object space
|
|
Hi Dale,
That’s very good news indeed. Thanks for all your hard work, as always. Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |