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 > On 2 Aug 2017, at 15:10, Mariano Martinez Peck <marianop...@gmail.com > <mailto:marianop...@gmail.com>> wrote: > > > > On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <tim@testit.works > <mailto:tim@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 <marianop...@gmail.com >> <mailto:marianop...@gmail.com>> wrote: >> >> >> >> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <tim@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/> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
