[Cuis-dev] Cuis freezes. I can't debug.

Juan Vuletich juan at cuis.st
Fri Sep 20 04:08:12 PDT 2024


Hi Mariano,

On 9/19/2024 6:29 PM, Mariano Montone via Cuis-dev wrote:
> Hi,
>
> after installing PopupFinder from Cuis-Smalltalk-Tools, and try to 
> open the tool, Cuis freezes and I can't debug what's wrong.
>
> Do you have suggestions?

Yes.

General advice:

1) Install the package with the Transcript open, look for any warnings 
there. (That's what the Transcript is for!) We see:
     Package WorldKeyStrokes successfully installed
         Undeclared: a Dictionary(#MessageSetWindow->nil )
     Package PopupFinder successfully installed
         Undeclared: a Dictionary(#MessageSetWindow->nil )
So it seems that WorldKeystrokes needs some love. This is not 
surprising. It provides low level services on the areas where Cuis has 
been changing lately.

2) `Smalltalk browseUndeclaredReferences` will also be of help here.
#defaultWorldKeyStrokeHandler: should be sync’ed to the current (non 
overriden) version of WorldMorph>>#keystroke:.
Note: This will break each time we improve handling of global keystrokes 
in Cuis. It will happen again!

3) `Smalltalk browseAllUnimplementedCalls`, amongst many unrelated 
smells includes:
FinderMorph>>#openInWorld                                     
calls:          #(#focusFollowsMouse)
FinderSearchBarMorph>>#layoutSubmorphs          calls:          
#(#morphPosition:extent:)
ClassNamesCatalog>>#browse:                                 
calls:          #(#fullOnClass:)

Crudely hacking these issues makes the tool open again.

In general, I can’t take responsibility for all the code written for 
Cuis. Cuis is evolving, and sometimes changes affect compatibility. Any 
package, to be considered “Maintained” and not “Abandoned” needs a 
maintainer that will update it to keep it running as Cuis evolves.

This not Cuis specific, and is true for any piece of code written to run 
on top, or depending on another upstream piece of code. It is a basic 
fact of our field.

> I think it would be better if Cuis didn't freeze at all. The package 
> hasn't changed. It is a problem with latest versions of Cuis.

Yes. It would be better. But there's no magic here.

There's another possible approach: Carefully document supported APIs, 
and stick to them for decades. This means much slower progress at a 
development cost of 2 or 3 additional orders of magnitude to build 
systems that are extremely limited in what they offer, are horribly 
inefficient in the use of resources, and can hardly evolve at all. 
Windows comes to my mind as an extreme case.

>     Mariano
>

Hope this helps,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich



More information about the Cuis-dev mailing list