Fix: Prevent Inspector UI freeze by lazy loading allChildren

[HossamSaberr]

Fixes #39

This PR fixes the massive memory allocation and UI-freezing bug in the AVL Tree inspector by replacing the full-tree BFS with a lazy-loading structural approach.

Changes:

1. Updated CTAVLTree >> allChildren to only return the root node.
2. Injected allChildren into CTAVLNode (via *Containers-AVL-Tree-Inspector extension protocol) to return only its immediate left and right children using Array streamContents:.
3. Injected allChildren into CTAVLNilNode to return an empty array.
4. Updated testAllChildren in CTAVLTreeTest to assert against the new lazy-loading expected behavior instead of a full tree dump.

Video Proof of Fix:
(Running the exact same 200,000 node stress-test script from Issue #39)

Screencast.From.2026-02-28.00-05-15.mp4

Result:
The Pharo Inspector is designed to be hierarchical. By returning only the immediate children, the Inspector can unfold the tree incrementally. Inspecting a tree with 200,000+ nodes is now instantaneous and uses O(1) memory overhead per click, completely eliminating the Garbage Collection freeze.

[Ducasse]

In pharo the protocol allX and withAllX are codified.

• allX should return all the nodes.
• withAllX should return the receiver with all the nodes.

So we should follow this semantics. Now if the inspector is slow then we should change something else :)

[HossamSaberr]

Thank you for the explanation! That makes perfect sense.

I dug into the Inspector and the massive freeze wasn't the traversal itself, it was CTAVLTreeVisualizer attempting to mathematically layout all the nodes simultaneously on the canvas!

To fix this properly, here is what I am planning to push:

1. Revert allChildren back to its deep traversal.
2. Add a new inspectorTree: method using Spec2's native tree builder. This adds a lazy loaded "Tree" tab that easily handles 200,000+ nodes instantaneously.
3. Add a safety size limit to the "AVL" tab (inspectorCanvas:) to prevent the UI thread from freezing or crashing on massive trees.

I tested the canvas with 8,000 nodes—it actually did draw them with only a very small lag, but the event loop eventually crashed on mouse hover due to the sheer number of elements.

Because of the crash risk, I think adding a hard limit of 1,000 nodes for the graphical view would be a great spot. It keeps the Inspector perfectly stable, and users can just use the new Spec2 Tree tab for anything larger.

Does a limit of 1,000 sound good to you, or would you prefer a different number? Also, if this overall plan doesn't seem like the best practice for Pharo at all, please let me know! I am completely open to tackling this another way before I push the commit.

[jordanmontt]

There is one test that is not passing. Could you fix it?

CTAVLTreeInspectorTest
✗ #testCreateCanvas (29ms)
TestFailure: Got 1 instead of 4.

[HossamSaberr]

Yea, That test is failing because my commit changed the semantics of allChildren (which made it return 1 instead of 4).

As I mentioned in the plan above, my next commit reverts allChildren back to its original behavior, which will automatically fix this test! Should i push that updated code now? take a look at the prev comment and tell me

[jordanmontt]

yes please push all the commits here

[HossamSaberr]

All Green now

The CI should hopefully be completely green now. Let me know if everything looks good or if you'd like any other adjustments

[jordanmontt]

the CI is failing because this method should be in the Containers-ALV-Tree package and not in the Containers-ALV-Tree-Inspector.

Now this method is an extension, it should be not. Could you change that please? If you need more info about what the problem is write me on Discord