[Cuis-dev] Not saving the image?

[Phil B]

Nicola,

Not a problem and that's why I responded.  It is natural to take what
you're used to and try to apply it to new tools and languages.  That's
probably how most of us started with Smalltalk.  It takes a while to adjust
to an image-based approach, and using it correctly (especially re: Cuis
which is maintained differently than other Smalltalks) not trying to use it
as a data store.  But once you make the transition, you might not look at
the file-based approach the same way again.

Thanks,
Phil

On Sun, Aug 1, 2021 at 1:54 PM Nicola Mingotti <nmingotti at gmail.com> wrote:

>
> 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>
> 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/4194ac5d/attachment.htm>