What sets the Monticello Local Cache Directory default in a new image?
Locked
What sets the Monticello Local Cache Directory default in a new image?
 
|
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 |
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <[hidden email]> 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. My strategy is to use a shared repository for all my images. As part of my build image scripts I do something like this:
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. |
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
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
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
Try to run the image with --no-default-preferences. -- Pavel 2017-08-02 14:37 GMT+02:00 Tim Mackinnon <[hidden email]>:
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
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
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
In reply to this post by Mariano Martinez Peck
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
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <[hidden email]> wrote:
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,
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
I’d be curious about your script if it is easily handy (I did notice a blog article you wrote on StartupLoader a while back).
By the way - I really appreciated your article "Moving contexts and debuggers between images with Fuel” - it inspired me to figure it out for debugging on AWS lambda (which is very cool BTW - and I’ll write it up soon when I have it bedded in) Tim
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
On Wed, Aug 2, 2017 at 12:04 PM, Tim Mackinnon <[hidden email]> wrote:
As said, nothing fancy at all [1]. And it keeps evolving all the time as Pharo evolves too.
Yeah, but that post is not a bit outdated as StartupLoader changed quite a bit since I wrote the article. But the idea is still the same.
Thanks. Yes, that fact made us won the first price [2]. I still remember I was sit on my living room, preparing the demo for ESUG I was thinking how could I show Fuel in a cool manner. I knew at that point we were able to serialize closures, methods, classes, etc... but I just thought "what If I serialize the debugger?". I took me 5 minutes to try it out and realized it worked from the first run hahaa. That was one of my top 5 best programming days of my life hahaha. This feature was then used for the "Fuel out stack" and to revive CI failure tests locally.
Cool. I have been following your emails about having a small image and a small vm and I am very interesting on that. Well, I should be considering which was my PhD [3] hahaha Cheers,
|
Re: What sets the Monticello Local Cache Directory default in a new image?
|
|
In reply to this post by Tim Mackinnon
On Wed, Aug 2, 2017 at 2:37 PM, Tim Mackinnon <[hidden email]> wrote:
They should co-exits with no issues if you share the play-cash and play-stash folders between multiple images.
The play-stash is for scripts you explicitly give a name. You can double click on the tab and enter a name. Then a file with that name plus a timestamp is created in the play-stash folder. The content gets then saved to that file. Right now you can access the stashed scripts again though spotter by searching for the script name or typing #play to get the cached and stashed pages. Cheers, Andrei
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |