<div dir="ltr"><div dir="ltr">Nicola,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 1, 2021 at 10:17 AM Nicola Mingotti <<a href="mailto:nmingotti@gmail.com">nmingotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div><br>
    I would add this consideration. The procedure of not saving the
    image would not fit well in Squeak because there, by default, <br>
    are included tools for children [of all ages;)] which do not require
    code writing to make a full artifact. <br>
    For example EToys. Since it does not require code but cinematics
    interactions it <br>
    would make more difficult/cumbersome/indirect to export<br>
    your work as file in Git. There it makes a lot more sense to save
    the Image.<br>
    <br></div></blockquote><div> </div><div>I'd argue it makes sense to save an image if you have a collection of packages and state you work with regularly.</div><div><br></div><div>In my case, it takes nearly 10 minutes to reload all of my packages into a new development image and then I have a couple of dozen Morphs to instantiate, programatically.  Yet more time is often required to load/process some additional amount of data to get the image into the state needed.  If I had to do that after every time the image hangs or otherwise just starting up the image, I'd lose my mind.</div><div><br></div><div>Then there are all the variations of images I use:  I have a full development image, a minimal development image, a testing image, a couple of application specific images and a number of server images.  But they're all just variations on a theme: they mix and match different collections of my packages and have some unique persisted state.  I don't actually care what happens to the images themselves, they are just time savers to have pre-built.  Sometimes I rebuild one or more of them multiple times in a day, sometimes I'll go months before needing to rebuild.</div><div><br></div><div>Since you seem interested in automating things, here's an example of why this is a better way to go in my opinion:  I have a web server image that from the time I hit enter on the command line, the image loads and is accepting requests within about half a second.  I can interact with the image (either via the Cuis GUI or a web browser) which results in say 1GB of data being loaded and processed, save it to a new image and then reload that in less than 30 seconds which is handy for pre-loaded data sets / pre-warmed caches.  If I need to scale it out over multiple cores, I can parameterize it so that it takes a port number as a command line argument and then start any number of instances of it painlessly.  Say I then see an announcement on the list of some updates that I want, so I just delete all of these images and start over.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    As I see it, Cuis starts minimal. If you bend it into the Squeak use
    case then it becomes interesting<br>
    to save the image. If you bend it more into, say, Python, then it is
    more fit, and you<br>
    will fill more at home keeping on with Git.<br></div></blockquote><div><br></div><div>Git is recommended, but optional for personal stuff.  It is particularly handy to do checkpoints to sync up your code periodically with new Cuis releases so that you can go back and run your code with older images in the future if you need to.  Sometimes this will be the only quick way to determine whether or not an issue you're seeing today is a Cuis bug or something you introduced months ago, for example.  Regardless of how you end up using Cuis, I think you'll find packages on the other hand, are pretty much mandatory once you get to a certain level of complexity.</div><div><br></div><div>The basic point I'm trying to get across is to not think in terms of files but rather think in terms of packages and images... it will take you farther.  The key is to persist your code and state outside of the image frequently.  So then you can feel free to manipulate a copy of the image into whatever form you want, but  remembering that any particular image file is fleeting and you should always be in a position to recreate it from scratch from a base image as needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <br>
    bye<br>
    Nicola<br></div></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>