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 <marianopeck@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 <marianopeck@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