[Cuis-dev] Cuis Smalltalk Issues

[Juan Vuletich]

Hi Mark,

On 11/13/2021 7:17 PM, Mark via Cuis-dev wrote:
> Hi,
>
> I’m new to the Cuis implementation of Smalltalk.
> I’ve dabbled with Squeak and Pharo in the past … and then life would 
> strike and distract me from it. :-)

Welcome!

> Now, I’m playing with Cuis — and I really like the minimalist approach.
>
>     System: MacBook Pro 16” (2019)
>     OS: macOS Catalina (10.15.7)
>     Cuis image: Cuis5.0-4963.image
>
>
> I’ve been working my way through “The Cuis” book 
> (https://cuis-smalltalk.github.io/TheCuisBook/), learning lots.

Cool.

> It’s all been running quite stable until today and have run into two 
> issues.
>
> (I did DuckDuckGo around to find similar issues, but I didn’t find 
> any. If these are noted somewhere, please point me to them. Thanks! 🙂)
>
> ISSUE #1
>
> I got to the clock morph chapter 
> (https://cuis-smalltalk.github.io/TheCuisBook/A-Clock-Morph.html) and 
> got the clock running.
>
> Then, I started playing with the #stepTime values — just for fun. I 
> set it to values like “16” and “66.7” and then, suddenly, the whole 
> environment froze.
>
> The Squeak menu still responded, but it wouldn’t allow me to quit.
>
> I sent it a USR1 signal, and it generated a crash dump, here: 
> https://www.dropbox.com/s/1e4st9fp8xrm29p/crash-01.dmp?dl=0
>
> Is this a known issue? I realize a step time of 16ms (or possibly even 
> 67.7ms) is pretty short, but I didn’t expect it to freeze everything.
> (Sadly, I hadn’t saved the image, so I lost all the samples I’d added. 
> :-( )
>

The problem is not the #stepTime being too small (you can answer zero, 
and it will do as many fps as your hardware allows). The problem is that 
the system assumed it would always be an integer number. I just posted 
to GitHub an update to truncate to integer otherwise. Good catch!

> ISSUE #2
> After restarting Cuis, I re-added the LineExampleMorph (section 7.1.1 
> - https://cuis-smalltalk.github.io/TheCuisBook/Going-Vector.html)
> And instantiated it.
> It drew a green line.
>
> Then, I went to the class definition and changed its superclass from 
> Morph to MovableMorph and saved.
>
> Everything seems fine … but, when I clicked on the existing green 
> line, the debugger popped up
>
> So, I closed the debug window and went to the Workspace window and 
> executed “LineExampleMorph allInstancesDo: [:x | x delete. ]”
> The green line disappears, but a debug window popped up.
> So, I changed the class back to “Morph” … and then a “Recompiling” 
> dialog popped up … and stayed there.
> Then debug windows started popping all over — to the point where the 
> whole display is unusable.
>
> It looks like it may have generated a log file for each debug message 
> (there are 16 of them … 😉)
>
> Here’s a screen recording (.mov file) of what it looked 
> like:https://www.dropbox.com/s/ja6hynzfpka5jua/Cuis-Smalltalk-Issue02.mov?dl=0

As Hilaire already pointed out, changing the class definition while 
having live instances might leave them in an inconsistent state. In this 
case, the system doesn't know how to initialize the 'new' instance 
variables added by MovableMorph being the superclass. They are left as 
nil, and stuff breaks.

> I guess my overall questions are:
> Should these kinds of things be happening?

Yes. It is like going in a car on the highway, and taking a wrench and 
messing with the engine without even pulling to the curbside. It is a 
consequence of a completely live and open system.

> Or are these somehow n00b errors on my part?

Not at all. I've developed the Morphic framework you are using. You'd 
have to see the thousands times I froze my image because I didn't 
realize the full consequences of some change.

> How can I ensure data is lost as I experiment with the environment?

Ensuring date is lost is really easy!!! I guess you mean ensuring data 
is not lost!

The system keeps track of all the code you write and the Smalltalk 
expressions you evaluate. These are not lost even if you kill Smalltalk 
from the host OS. Check the *.changes files. WRT to live objects in the 
image, these will be lost if you need to kill the image for whatever 
reason. An alternative is to save the image from time to time. 
Personally, I generally prefer to create examples with 'doit' Workspace 
expressions. These get saved in the *.user.*.changes files.

> Since the whole philosophy of Smalltalk is to be able to examine the 
> whole system and try things, I’d like to do that without worrying that 
> the next thing I do could blow up the environment. 😉
> These don’t seem like things that should freeze the environment.

I don't think that is even possible. If you can examine any part of the 
system, there will always ways to break it. Smalltalk is not a sandbox 
for safe playing. Don't worry. You'll get used to it, and learn how to 
never lose your stuff. The freedom Smalltalk gives you is well worth 
this learning experience!

> Thanks, in advance, for any insights you might have.
>
> — Mark

You're most welcome. Keep telling about stuff you find annoying. Fresh 
eyes always see new things. This time, for instance, you reported two, 
and one of them resulted in an enhancement. The other, hopefully, helped 
you learn something. Both were positive outcomes!

Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20211116/c8242ef8/attachment-0001.htm>