Magik’s collection types: visualising with Emacs’ data viewer

GE Smallworld applications often hide the most useful evidence inside collections. A geometry operation may return an array, a network traversal may produce a list, and a domain object may expose its state through a property set. For Magik programmers working in Emacs, seeing those structures directly turns a vague runtime symptom into a specific element, key or slot that can be investigated.

Magik’s collection types do not all answer the same question. Sequence order, lookup keys, named fields and linked elements send debugging in different directions. Emacs’ data viewer gives them a common visual surface: expand a node, inspect its value and follow the structure towards the point where the data becomes wrong, rather than adding another temporary print statement.

That fits the Australian Smallworld market, where teams in Sydney and Melbourne support organisations running browser portals for banks, utilities and councils. Australian English uses “visualising”, “colour” and “behaviour”, while workshop language stays direct—let’s crack the case, have a go and record what we found. The tooling should feel just as practical.

Why collections need a visual lens

Collections are easy to underestimate because a value can look harmless at the call site. A short array may contain a nil entry; a large list may include a valid object with the wrong state; a property set may carry an unexpected key. Printing the whole result can bury the relevant detail in noise, while printing only a count removes the context needed to understand it.

Visual inspection helps because it keeps the type and shape of the data visible while the developer narrows the search. An indexed container suggests checking position and bounds. A linked list calls for examining the head and each remainder. A mapping suggests comparing expected and actual keys. A named record encourages checking slot semantics rather than assuming every value is just another collection.

The objective is a faster diagnosis with less code churn. Magik Emacs can keep the live interpreter, source buffer and viewer close together, letting a programmer move from a result to the method that produced it. For Australian teams working across distributed systems, that short path matters: Sydney may already be in a client workshop while a Brisbane or Perth colleague picks up the query later.

Magik’s core collection shapes

The two common indexed forms are array and vector. Their elements have meaningful numeric positions, so the viewer is useful for spotting an off-by-one boundary, an unexpected numeric value or a nested structure at a precise element. They should not be treated as interchangeable: code that works with one may rely on different sizing or update rules, making the displayed type worth checking before any change.

A list presents a different mental model. Rather than jumping straight to an index, the developer follows its head and tail or linked remainder. Truncation, an early nil or a chain of objects that all reference the same mutable state can explain a result that looks correct in isolation. In the data viewer, the list structure makes those relationships easier to test.

A property_set is mapping-like: names point to values, so missing properties, unexpected keys and wrongly typed values become the main concerns. A record or domain object instead offers named slots, and a hash-table-like container may be present in some libraries. These kinds share broad collection behaviour but preserve different semantics. The viewer should reveal that distinction instead of flattening every object into an anonymous string.

Strings also appear in collection APIs, yet they are usually best inspected as character data rather than as a general-purpose container. Knowing whether a result is text, a sequence, a mapping or a domain object prevents a false lead. It also lets the Magik programmer choose the right Magik method for the next query and keeps collection analysis aligned with Smallworld’s object model.

Preparing a collection for inspection

Start with the smallest expression that returns the suspect value. Keep it in a named Magik variable rather than immediately converting it to text or a plain array. In a method, a line such as candidate_ids << _self.candidate_ids is enough for many investigations; replace it with the receiver and property used by the application. The variable gives the viewer a stable target while preserving keys, ordering and object identity.

Evaluate the expression in the Magik process from Emacs, then invoke the data-viewer command supplied by the Magik Emacs setup. Because command names and bindings can vary between releases, open M-x, type data-viewer and choose the matching entry rather than copying a shortcut from another workstation. If the result is buried in a larger record, expose that field deliberately rather than inspecting an opaque top-level object.

Readable source makes the next step easier. A custom Magik highlighting theme can distinguish Magik symbols, strings, comments and method syntax, while code folding can collapse long routines without hiding their signatures. These small Emacs features reduce the effort spent deciding where the returned collection came from and which branch created it.

Working with the data viewer

The viewer normally presents the selected value as a navigable tree. The header establishes its type and immediate structure; child nodes expose elements, properties or slots; expansion reveals further nesting. That view answers common Magik debugging questions quickly: Is the collection empty? Which child has the wrong type? Does a property point to a shared object? Is an expected key absent? These are better questions than scanning a wall of printed output.

From there, work in both directions. Follow the unusual value back to the method that assembled it, then move forward through the tree to verify neighbouring entries. Magik Emacs’s source navigation can take you to the defining method, and Emacs cross-reference navigation such as M-. can help connect the displayed object with its implementation. The data viewer provides the state; the source shows the transformation that produced it.

Treat the viewer as a diagnostic snapshot rather than a substitute for the Magik debugger. A snapshot is excellent for comparing shape, keys and content, but a live debugger may be needed when a slot changes after the collection is built. Copy or save the important representation in the Emacs kill ring or a scratch buffer, then reproduce the call with the debugger active. That sequence preserves evidence and avoids mistaking an old value for current behaviour.

Turning findings into repeatable checks

Once the faulty structure is understood, turn it into a repeatable check. Depending on the issue, the assertion may concern element count, a required property, key uniqueness, a type boundary or the identity of a nested object. Keep the expression close to the Magik method or helper that owns the rule, so the test documents domain behaviour instead of a temporary debugging implementation.

For behaviour visible through a browser portal, carry the same expectation into an end-to-end scenario. Thucydides web tests can record user journeys and attach concrete examples to the requirement, giving teams evidence that the portal still behaves as agreed after a change. The browser check and the Magik collection check are complementary: one confirms the user path, while the other isolates the underlying data.

Australian delivery teams can then make the evidence easier to hand over. A failing example from a council asset portal or a utility customer portal should include the collection shape, the exact invariant and the relevant method, not merely a screenshot. A team in Perth can review the stored result when working hours overlap with Melbourne, while a Brisbane team can include the same example in the next release without relying on someone remembering a live debugging session.

Building a durable Magik debugging routine

A repeatable Magik routine is straightforward: isolate the collection, inspect it in the viewer, trace the producing method, and verify the fix with a focused check. Code folding keeps large procedures manageable during the trace; object inspection and method navigation shorten the distance between a suspicious value and its owner. The Magik Emacs site’s tutorials, extensions and screen-casts can support that loop, particularly when a team standardises its interpreter setup and viewer workflow.

Document the collection type, the transformation applied and the invariant that must remain true. Screenshots can help, but a small Magik expression and a saved test are more durable. HydePark Consulting can also help organisations turn this debugging pattern into maintainable Magik and Emacs practices, including team conventions, local support and practical training for developers who move between Australian Smallworld environments.

Open your next Magik investigation with this sequence: start the interpreter, bind the suspicious collection, launch the Emacs data viewer and save one precise observation about its shape. Fix the producing method, add the corresponding check to the project, and use that case to train the next developer who touches the workflow. One collection, one visible invariant and one reusable test will give your team a faster and more dependable debugging cycle.