[Cuis-dev] Not saving the image?

[Nicola Mingotti]

Hi Phil,

great explanation ! Thank you for taking the time to write it !

I extremely interested in automation. Most of what I do run in servers. 
Sometimes
it is a web application but not always. The fascination for 
Cuis/Smalltalk in my case comes from
the fact that I could inspect my services when they are running, modify 
them as they are running,
I can do it graphically if I wish and I can put notes and pictures 
nearby the code (StyledText).
This is a tremendous mix! I see some opportunities of making good & 
maintainable stuff in reasonable time.

I think I got the idea of how you deploy the image.
Still, i am used to the C/Python/Ruby/JS... way of thinking. You change 
the code. Shut down, restart,
see what happens.  It will take me a while and a well fitting problem to 
appreciate fully the image
capabilities.

About 1 year ago I discovered Squeak. I made a some experiments, also 
with eToys, like
this one (simulation of a vaccum cleaner robot) 
https://youtu.be/hUpffz3Uz6E . There
I saw that saving the image was the only way to save the state, since I 
didn't type one line of code.
All the state and login came from a graphical interactions. [maybe there 
way to save as code but i did not find it;) ]
Now I see it can be more useful than that.

bye
Nicola










On 8/1/21 6:29 PM, Phil B wrote:
> Nicola,
>
> On Sun, Aug 1, 2021 at 10:17 AM Nicola Mingotti <nmingotti at gmail.com 
> <mailto: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/f8ccd09c/attachment-0001.htm>