[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