On Wed, Aug 2, 2017 at 12:04 PM, Tim Mackinnon <tim@testit.works> wrote:
> I’d be curious about your script if it is easily handy > As said, nothing fancy at all [1]. And it keeps evolving all the time as Pharo evolves too. > (I did notice a blog article you wrote on StartupLoader a while back). > > 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. > By the way - I really appreciated your article "Moving contexts > and debuggers between images with Fuel” - > 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. > 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) > > 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 [1] http://ws.stfx.eu/OCV4GOA5D6DR [2] http://www.esug.org/wiki/pier/Conferences/2011/InnovationTechnologyAwards [3] https://marianopeck.wordpress.com/2012/11/07/dr-mariano-martinez-peck/ Cheers, > Tim > > On 2 Aug 2017, at 15:10, Mariano Martinez Peck <marianop...@gmail.com> > wrote: > > > > On Wed, Aug 2, 2017 at 10:50 AM, Tim Mackinnon <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> >> wrote: >> >> >> >> On Wed, Aug 2, 2017 at 9:16 AM, Tim Mackinnon <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 >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com
