[Cuis-dev] Cuis Smalltalk Issues

Tue Nov 16 09:46:50 PST 2021

Hi Juan,

Thanks for the detailed response — and more insight into the “Smalltalk Philosophy.” That helps a lot.
(As I mentioned in another post: Chapter 9 — Code Management (https://cuis-smalltalk.github.io/TheCuisBook/Code-Management.html <https://cuis-smalltalk.github.io/TheCuisBook/Code-Management.html>) cleared up some things)

At least knowing that freezing up cuis and relaunching is part of the “growing pains”, is a good thing. :-)

It would be nice if there were a way as simple as “World (menu)” > “Save Image” to save the current state without “mucking” up the “core” of Smalltalk.
However, I realize as I type that, that that is not “The (Smalltalk) Way” 🙂

Here are some more observations.

OBSERVATION #1

I did create a “startup script” to setup the environment, which is great — but, it has its own issue. I’ve included the following (based on the sample), and I would expect the “Welcome to Cuis” window to be closed when it receives the “delete” message … but, it’s still there, along with a “Transcript” window showing that the package “Theme-Themes” was successfully installed.

| list morph area extent |

"------------------------------------------------------"
"Delete all windows but the taskbar"
"------------------------------------------------------"
list := UISupervisor ui submorphs reject: [:aMorph |
   aMorph is: #TaskbarMorph].
list do: [:each | each delete].

OBSERVATION #1.1

(Along the lines of the above observation)I have noticed that when I instantiate some morphs from the Workspace, they sometimes cannot be deleted with a “delete.”
What I observe is that they do disappear off the world/screen, but when I send “allInstances size.”, the response is not “0”, which is what I’d expect.

Is this a case where memory garbage collection hasn’t run yet?
When does that get triggered?
Is there a way to initiate garbage collection to see verify instances are removed after that?

OBSERVATION #2

If the “preferred” mode of development is to not save the image, but rather use packages, then I’ve noticed that the “Change Sorter” doesn’t always show all the changes reflected in “*.changes” files.

I see changes files with names like:

Are these “original/downloaded” change files?
	Cuis5.0-4963-v3.changes
	Cuis5.0-4963.changes

Are these created after I entered my initials?
	Cuis5.0-4963-mdj.changes
	Cuis5.0-4963-mdj.user.nnn.changes
	Cuis5.0-4963-mdj.user.changes

Are these created before my initials are known to the system?
	Cuis5.0-4963.user.nnn.changes
	Cuis5.0-4963.user.changes

When I open the “Change Sorter”, it only shows:
	"4964-CuisCore-AuthorName-2021Nov16-09h29m”
	“Install-Theme-Themes”

Which do not obviously (to me! 😉) correspond to the filenames.

Again, probably n00b issues that will make more sense over time. 🙂

Thanks,

	— Mark

> On Nov 16, 2021, at 6:20 AM, Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
> 
> 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/ <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 <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 <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 <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 <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 <http://www.cuis-smalltalk.org/>
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev <https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev>
> https://github.com/jvuletich <https://github.com/jvuletich>
> https://www.linkedin.com/in/juan-vuletich-75611b3 <https://www.linkedin.com/in/juan-vuletich-75611b3>
> @JuanVuletich
> -- 
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev <https://lists.cuis.st/mailman/listinfo/cuis-dev>

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