[Cuis-dev] Not saving the image?

[Phil B]

Nicola,

On Sun, Aug 1, 2021 at 10:17 AM Nicola Mingotti <nmingotti at gmail.com> wrote:

>
> I would add this consideration. The procedure of not saving the image
> would not fit well in Squeak because there, by default,
> are included tools for children [of all ages;)] which do not require code
> writing to make a full artifact.
> For example EToys. Since it does not require code but cinematics
> interactions it
> would make more difficult/cumbersome/indirect to export
> your work as file in Git. There it makes a lot more sense to save the
> Image.
>
>
I'd argue it makes sense to save an image if you have a collection of
packages and state you work with regularly.

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.

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.

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.


> As I see it, Cuis starts minimal. If you bend it into the Squeak use case
> then it becomes interesting
> to save the image. If you bend it more into, say, Python, then it is more
> fit, and you
> will fill more at home keeping on with Git.
>

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.

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.


>
> bye
> Nicola
>

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210801/74e56522/attachment.htm>