<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    Hi Phil,<br>
    <br>
    great explanation ! Thank you for taking the time to write it !<br>
    <br>
    I extremely interested in automation. Most of what I do run in
    servers. Sometimes<br>
    it is a web application but not always. The fascination for
    Cuis/Smalltalk in my case comes from<br>
    the fact that I could inspect my services when they are running,
    modify them as they are running,<br>
    I can do it graphically if I wish and I can put notes and pictures
    nearby the code (StyledText).<br>
    This is a tremendous mix! I see some opportunities of making good
    & maintainable stuff in reasonable time.<br>
    <br>
    I think I got the idea of how you deploy the image. <br>
    Still, i am used to the C/Python/Ruby/JS... way of thinking. You
    change the code. Shut down, restart,<br>
    see what happens.  It will take me a while and a well fitting
    problem to appreciate fully the image<br>
    capabilities. <br>
    <br>
    About 1 year ago I discovered Squeak. I made a some experiments,
    also with eToys, like<br>
    this one (simulation of a vaccum cleaner robot)
    <a class="moz-txt-link-freetext" href="https://youtu.be/hUpffz3Uz6E">https://youtu.be/hUpffz3Uz6E</a> . There<br>
    I saw that saving the image was the only way to save the state,
    since I didn't type one line of code.<br>
    All the state and login came from a graphical interactions. [maybe
    there way to save as code but i did not find it;) ]<br>
    Now I see it can be more useful than that.<br>
    <br>
    bye<br>
    Nicola<br>
    <br>
    <br>
    <br>
    <br>
    <br>
     <br>
    <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 8/1/21 6:29 PM, Phil B wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMJMOejVeZ1u5NQp3=UAu3ogomVOgFsOei-kUo-LQoLOMeA-ZQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true">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>
    </blockquote>
    <br>
  </body>
</html>