- Pharo-users - lists.pharo.org

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Mariano Martinez Peck

On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Mariano - out of curiosity, how do you build your image - do you use zero > conf and then apply a known .st script? (I used to use pharo launcher back > in the day - but now I find that zeroconf is actually handier anyway). > > My work flow explained below is only for when I am using stable Pharo for a paid client. In this case, I am not grabbing Pharo latest code all the time. Only every in a while. So, my workflow is as follow: 1) with zero conf I simply grab image and vm (I try to keep my app working with latest stable) 2) Apply a known load script that we keep maintained (this is somehwere in a wiki). This script contains: 2.1) settings of Author, Monticello username and pass etc. 2.2) Several custom settings/preferences that I like to change to the default image (this could be replaced by startup preferences thingy). 2.3) Workaround for bugs I hit and that are not backported to stable version. 2.4) Install 3er party libs I want for my development image (Calypso browser, code critics (now integrated), etc etc). 2.5) Finally, I load my app code. 3) Once I am done loading all of it, I save that image as "PharoMyAppTemplate.image". And I never do real work with that image. 4) Each time I need a new image (to make a new feature, a bug fix, whatever) I take "PharoMyAppTemplate.image" and I do a "save as" with either number like "PharoMyApp1.image" or "PharoMyAppBug3232.image" or ""PharoMyAppNewFeature.image" etc. I create these images many times and I don't have a strong policy on when to create new ones. Whenever I create one of these images, I upload my app code to latest code. 5) Every in a while, I update my template image. Mostly when I change my dependencies. I can share the script if you want. Cheers, > Tim > > On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a >> fresh directory) - that when I launch it, the setting Tools | Software >> Config Mgnmnt | Monticello | Local Cache Directory has a value that points >> to a directory from one of my earlier images. >> >> Is this normal (does it store this information somewhere on my computer >> so that different setups can access it)? >> >> At first I thought this was annoying - but Iâm now wondering if this is >> useful as Iâm guessing that there isnât any reason to have separate caches >> for version controlled libraries and so maybe I should actually set it to >> some common directory? >> >> What is the recommended strategy? >> >> > My strategy is to use a shared repository for all my images. As part of my > build image scripts I do something like this: > > > " =============== Personal Settings ================ " > MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. > > GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' > asFileReference. > > > I guess you save stuff: > > find /Users/mariano/Pharo/localRepo/ -type f | wc -l > > *32301* > > du -sh /Users/mariano/Pharo/localRepo > *6.1G* /Users/mariano/Pharo/localRepo > > > Not only you save disk space, but also: > 1) Each image build is likely to take less time as many files will be > already in the cache (no need to redownload it). > 2) it works as a yet another backup of your code and other packages. > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Aug. 2, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Tim Mackinnon

Mariano - out of curiosity, how do you build your image - do you use zero conf and then apply a known .st script? (I used to use pharo launcher back in the day - but now I find that zeroconf is actually handier anyway). Tim > On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > > > On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images. > > Is this normal (does it store this information somewhere on my computer so that different setups can access it)? > > At first I thought this was annoying - but Iâm now wondering if this is useful as Iâm guessing that there isnât any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory? > > What is the recommended strategy? > > > My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this: > > > " =============== Personal Settings ================ " > > MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. > MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. > GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. > GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. > > > I guess you save stuff: > > find /Users/mariano/Pharo/localRepo/ -type f | wc -l > 32301 > > du -sh /Users/mariano/Pharo/localRepo > 6.1G /Users/mariano/Pharo/localRepo > > > Not only you save disk space, but also: > 1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it). > 2) it works as a yet another backup of your code and other packages. > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Aug. 2, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Tim Mackinnon

Ahhhh thatâs how it worksâ¦ StartupPreferencesHandler and its in my user/Library/Preferences/Pharo/6.0 folderâ¦ You learn something new every day (minute it seems lately) Tim > On 2 Aug 2017, at 14:04, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Try to run the image with --no-default-preferences. > > -- Pavel > > 2017-08-02 14:37 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > Hey thanks - that seems like a good strategy (I hadnât though of sharing the GT ones as well). > > However, Iâm still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be? > > With regards to the GT settings - how does it work if you share them - do they happily co-exist? The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (Iâm still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list? > > Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing. > > Tim > >> On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images. >> >> Is this normal (does it store this information somewhere on my computer so that different setups can access it)? >> >> At first I thought this was annoying - but Iâm now wondering if this is useful as Iâm guessing that there isnât any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory? >> >> What is the recommended strategy? >> >> >> My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this: >> >> >> " =============== Personal Settings ================ " >> >> MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. >> MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. >> GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. >> GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. >> >> >> I guess you save stuff: >> >> find /Users/mariano/Pharo/localRepo/ -type f | wc -l >> 32301 >> >> du -sh /Users/mariano/Pharo/localRepo >> 6.1G /Users/mariano/Pharo/localRepo >> >> >> Not only you save disk space, but also: >> 1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it). >> 2) it works as a yet another backup of your code and other packages. >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > >

Aug. 2, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Pavel Krivanek

Try to run the image with --no-default-preferences. -- Pavel 2017-08-02 14:37 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Hey thanks - that seems like a good strategy (I hadnât though of sharing > the GT ones as well). > > *However, Iâm still curious how/why a new image would pick up settings > from what I did in another image (at least I think thats what its done - > certainly the directory it shows in my fresh image is not File > @pharo-local/package-cache like I would expect it to be?* > > With regards to the GT settings - how does it work if you share them - do > they happily co-exist? The stash one is also quite new to me - Sven > mentioned it a few weeks ago as I was confused how the playground got saved > (Iâm still not clear) - but he suggested double-clicking the title and > giving the tab a name. Are these named ones the stashed ones (it looks like > it). And do stashed ones honour cmd-s to save them? Which then leads to the > question, that in different images - if you share the stash then I guess if > you want to reload a file, you close that playground and then pick it again > from the list? > > Its quite a cool way of working (not perfect) but a real time saver. > Thanks for sharing. > > Tim > > On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a >> fresh directory) - that when I launch it, the setting Tools | Software >> Config Mgnmnt | Monticello | Local Cache Directory has a value that points >> to a directory from one of my earlier images. >> >> Is this normal (does it store this information somewhere on my computer >> so that different setups can access it)? >> >> At first I thought this was annoying - but Iâm now wondering if this is >> useful as Iâm guessing that there isnât any reason to have separate caches >> for version controlled libraries and so maybe I should actually set it to >> some common directory? >> >> What is the recommended strategy? >> >> > My strategy is to use a shared repository for all my images. As part of my > build image scripts I do something like this: > > > " =============== Personal Settings ================ " > MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. > > GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' > asFileReference. > > > I guess you save stuff: > > find /Users/mariano/Pharo/localRepo/ -type f | wc -l > > *32301* > > du -sh /Users/mariano/Pharo/localRepo > *6.1G* /Users/mariano/Pharo/localRepo > > > Not only you save disk space, but also: > 1) Each image build is likely to take less time as many files will be > already in the cache (no need to redownload it). > 2) it works as a yet another backup of your code and other packages. > > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Aug. 2, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Tim Mackinnon

Hey thanks - that seems like a good strategy (I hadnât though of sharing the GT ones as well). However, Iâm still curious how/why a new image would pick up settings from what I did in another image (at least I think thats what its done - certainly the directory it shows in my fresh image is not File @pharo-local/package-cache like I would expect it to be? With regards to the GT settings - how does it work if you share them - do they happily co-exist? The stash one is also quite new to me - Sven mentioned it a few weeks ago as I was confused how the playground got saved (Iâm still not clear) - but he suggested double-clicking the title and giving the tab a name. Are these named ones the stashed ones (it looks like it). And do stashed ones honour cmd-s to save them? Which then leads to the question, that in different images - if you share the stash then I guess if you want to reload a file, you close that playground and then pick it again from the list? Its quite a cool way of working (not perfect) but a real time saver. Thanks for sharing. Tim > On 2 Aug 2017, at 13:24, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images. > > Is this normal (does it store this information somewhere on my computer so that different setups can access it)? > > At first I thought this was annoying - but Iâm now wondering if this is useful as Iâm guessing that there isnât any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory? > > What is the recommended strategy? > > > My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this: > > > " =============== Personal Settings ================ " > > MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. > MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference. > GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. > GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. > > > I guess you save stuff: > > find /Users/mariano/Pharo/localRepo/ -type f | wc -l > 32301 > > du -sh /Users/mariano/Pharo/localRepo > 6.1G /Users/mariano/Pharo/localRepo > > > Not only you save disk space, but also: > 1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it). > 2) it works as a yet another backup of your code and other packages. > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Aug. 2, 2017

Re: [Pharo-users] What sets the Monticello Local Cache Directory default in a new image?

by Mariano Martinez Peck

On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a > fresh directory) - that when I launch it, the setting Tools | Software > Config Mgnmnt | Monticello | Local Cache Directory has a value that points > to a directory from one of my earlier images. > > Is this normal (does it store this information somewhere on my computer so > that different setups can access it)? > > At first I thought this was annoying - but Iâm now wondering if this is > useful as Iâm guessing that there isnât any reason to have separate caches > for version controlled libraries and so maybe I should actually set it to > some common directory? > > What is the recommended strategy? > > My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this: " =============== Personal Settings ================ " MCCacheRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.MCGitHubRepository cacheDirectory: '/Users/mariano/Pharo/localRepo/' asFileReference.GTPlayBook cacheDirectory: '/Users/mariano/Pharo/play-cache/' asFileReference. GTPlayBook stashDirectory: '/Users/mariano/Pharo/play-stash/' asFileReference. I guess you save stuff: find /Users/mariano/Pharo/localRepo/ -type f | wc -l *32301* du -sh /Users/mariano/Pharo/localRepo *6.1G* /Users/mariano/Pharo/localRepo Not only you save disk space, but also: 1) Each image build is likely to take less time as many files will be already in the cache (no need to redownload it). 2) it works as a yet another backup of your code and other packages. -- Mariano http://marianopeck.wordpress.com

Aug. 2, 2017

What sets the Monticello Local Cache Directory default in a new image?

by Tim Mackinnon

Hi - Iâve noticed that when I download a new image+vm with zeroconf (in a fresh directory) - that when I launch it, the setting Tools | Software Config Mgnmnt | Monticello | Local Cache Directory has a value that points to a directory from one of my earlier images. Is this normal (does it store this information somewhere on my computer so that different setups can access it)? At first I thought this was annoying - but Iâm now wondering if this is useful as Iâm guessing that there isnât any reason to have separate caches for version controlled libraries and so maybe I should actually set it to some common directory? What is the recommended strategy? Tim

Aug. 2, 2017

Glorp reconnection management (was: Re: Glorp: how to reconnect after image shutdown / load?)

by Herby VojÄÃk

jtuchel(a)objektfabrik.de wrote: > Herby, > > I am not aware of any automatic reconnect tools. Kepping a DB connection > alive after an image is closed is surely not desired and chances are the > DB will close the inactive session eventually anyways. Hm. When I though about it, image save / load cycle is just one example of losing a connection to db. So the question is more on "how to manage possible disconnections / reconnections"? > So it's probably best to make the DB connections reconnect on demand. > That means that whenever you open a session, check if a DB connection is > available or establish a new one otherwise. Hm, I though that once I open a session it does actually connect on demand (it has Login, system and all the information for it). Does it actually mean that if I want to stay connected I must do `session login` before each `session inUnitOfWorkDo:`? > There are many scenarios that can lead to the loss of a DB connection > that you usually cannot influence (network connection drops, DB server > has some error condition etc.) , so this is a good idea anyways. As written above, I thought glorp manages this kind of reconnection itself. If not, can someone point me to the some example where this is managed? I am asking because in Glorp book I did not find anything about this (I have read it). Thanks, Herby > HTH > > Joachim > > > Am 01.08.17 um 22:29 schrieb Herby VojÄÃk: >> Hello! >> >> ZnServers have its own register mechanism by which they listen when >> they are tagged as such after image save and load. >> >> I wonder if there is some way to connect to database in Glorp and then >> "keep the connection" between image save/load. Or how is this managed >> notmally in apps that use databases? Is image "preconfigured" with >> live self-healing connection or does some special piece of startup >> code be installed so it runs after deployment and image start? >> >> Thanks, Herby >> >> > >

Aug. 2, 2017

Re: [Pharo-users] Spotter question. "Spotter" search keyword need font setting from Pharo Setting Value.

by peter yoo

of course. i can report. look attached image please. i try this process. 1. open spotter(shift + enter) 2. press "shift + ctrl + mouse click" to spotter keyword area 3. explore object. can look this...... it's bad try?

Aug. 2, 2017

Re: [Pharo-users] Glorp: how to reconnect after image shutdown / load?

by jtuchel＠objektfabrik.de

Herby, I am not aware of any automatic reconnect tools. Kepping a DB connection alive after an image is closed is surely not desired and chances are the DB will close the inactive session eventually anyways. So it's probably best to make the DB connections reconnect on demand. That means that whenever you open a session, check if a DB connection is available or establish a new one otherwise. There are many scenarios that can lead to the los of a DB connection that you usually cannot influence (network connection drops, DB server has some error condition etc.) , so this is a good idea anyways. HTH Joachim Am 01.08.17 um 22:29 schrieb Herby VojÄÃk: > Hello! > > ZnServers have its own register mechanism by which they listen when > they are tagged as such after image save and load. > > I wonder if there is some way to connect to database in Glorp and then > "keep the connection" between image save/load. Or how is this managed > notmally in apps that use databases? Is image "preconfigured" with > live self-healing connection or does some special piece of startup > code be installed so it runs after deployment and image start? > > Thanks, Herby > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 2, 2017