The inspector should not use unsafe storeString

[nicolas-cellier-aka-nice]

Recipe for a disaster:

| window |
MCWorkingCopyBrowser open.
window := ToolSet inspect: DependentsFields.
window model selectionIndex: 95

What happens?

• The MCWorkingCopyBrowser adds a bunch of MCWorkingCopy in the DependentsFields, so as to add itself as a dependent and get notified of some package change.
• Since the DependentFields is quite populated, the DictionaryInspector omits most of the keys and replace them with ellipsis '...'
• when we select the ellipsis (at index 95 at this time of writing), the inspector is trying to print something wth storeString
• the VM gets overwhelmed, and in my case finish by freezing

If we user-interrupted soon enough, debugging the problem is already a challenge.

Even if we use debugIt instead of doIt in the above code snippet, Morphic stepping will freeze the UI soon after setting the selectionIndex inst. var. of the Inspector.

What are the problem with storeString?

• it's verbose (instVarAt:put:)
• it can work on simple trees, but will store the objects several times for a more general graph, and will run indefinitely if the object graph is cyclic
  Invoking storeString on a MCWorkingCopy, even if not a cyclic graph (I hope), is not a thing to do, because it can consume several Gbytes just with the business of printing the ancestry.
• the storeString of complex objects cannot be evaluated because of intrinsic limitations of the language (number of literals in a single method, execution stack depth, ...).
• it's neither of much use for a human interface, we ain't gonna decipher several Gbytes of instVarAt:put: instructions.

storeString is for simple objects at best with simple graphs, its simplistic nature is otherwise a failure.

An inspector aiming at some robustness shall not invoke storeString.

[timrowledge]

#storeString should have been either removed years ago, or replaced with sometihng SIXX-like that might actually work. And an Inspector should not be using it either way.

On 2024-02-08, at 11:37 AM, Nicolas Cellier ***@***.***> wrote: storeString is for simple objects at best with simple graphs, it's simplistic nature is otherwise a failure. An inspector aiming at some robustness shall not invoke storeString.

tim -- tim Rowledge; ***@***.***; http://www.rowledge.org/tim Spell checkers at maximum! Fire!

[LinqLover]

My motivation to use storeString here was that you can directly copy it into the "inspect element ..." prompt where you have to provide a key, or use it in a manual self at: ... expression. I get the disadvantages of this approach though ...

[timrowledge]

On 2024-02-08, at 3:12 PM, Christoph Thiede ***@***.***> wrote: My motivation to use storeString here was that you can directly copy it into the "inspect element ..." prompt where you have to provide a key, or use it in a manual self at: ... expression. I get the disadvantages of this approach though ...

A fair point, but I think we've seen that a better solution would be very much desired. After all, surely if you have a reference to an object so you can send it #storeString you can also just open an inspector directly on it? Or create a carrier-morph to let you drag it somewhere to torture later? tim -- tim Rowledge; ***@***.***; http://www.rowledge.org/tim Strange OpCodes: VMB: Verify, then Make Bad