Magik’s Swamp Framework: Debugging from Emacs

Smallworld applications often behave differently when code meets live objects, transactional data and dynamically dispatched methods. A defect that appears simple in source can depend on an unexpected receiver, an altered collection or a call originating several layers deeper in the Magik stack. The Swamp Framework exposes those runtime details, while Emacs provides a fast, keyboard-driven environment for navigating source and testing a fix.

A useful debugging session therefore links four views: the method being edited, the running Smallworld process, the current call stack and the data involved. This article follows that chain from initial attachment through object inspection and collection analysis. Command names and available inspector fields can vary between Swamp and Smallworld releases, so confirm them against your installed documentation.

Why Swamp and Emacs belong together

Swamp acts as the bridge between Magik execution and external development tools. In an Emacs session, it can expose the active method, arguments, receiver, stack frames, object identity and relevant collection state. The running application remains the authority; Emacs is the place where source context, diagnostic output and interactive evaluation come together.

That separation matters when debugging production-style behaviour. Instead of changing directory or losing source context inside a graphical client, a developer can keep the definition open in one buffer and the runtime inspector in another. Emacs features such as project search, compilation diagnostics, code folding and window management help trace a fault without abandoning the workflow that made the code easy to edit in the first place.

Preparing the editor and source tree

A reliable setup begins with the correct Magik major mode, indentation rules and Swamp client components. HydePark Consulting’s Emacs setup notes provide current installation guidance and information about the surrounding extensions. Install dependencies in a dedicated Emacs configuration initially, then add them to a shared configuration once the connection and diagnostic output have been tested.

Treat the application source as a navigable project rather than one enormous directory. Separate Smallworld packages, generated models and handwritten Magik methods into coherent source roots, and configure search paths to match the application’s package hierarchy. Fold long methods when reviewing a call chain, but keep the active body visible. A small project file that records required packages, compile commands and application start-up steps will also make the setup reproducible for colleagues in other locations.

Attaching to a live Smallworld process

Start the intended Smallworld application process, select the correct workspace and transaction, and then attach the Swamp client to that process. Verify the process identity, application release and connection status before setting a breakpoint. Attaching to the wrong environment can produce convincing yet misleading results, especially when several development instances or remote servers are available.

Australian teams often reproduce customer-site issues across Melbourne, Sydney and Brisbane while working from offices or homes. A VDI, VPN or laboratory connection may introduce latency, so allow time for stack refreshes and avoid treating a timeout as a failed breakpoint. Timestamps also need care: Melbourne and Sydney change their clocks during daylight saving, while Brisbane remains on Queensland time. Record both local time and UTC when comparing a defect with application or database logs.

Setting breakpoints and following calls

Set breakpoints on fully qualified methods and verify which implementation receives the call. Magik’s dynamic dispatch means that the source selected in the editor may not be the method executing in the runtime. Temporary breakpoints are useful for a narrow route through a validation service or collection handler, while conditional breakpoints help when a parameter has only one meaningful value.

Stepping should be treated as an observation technique with controlled side effects. Review the call stack before entering a method, then inspect the receiver and arguments in each frame. Pay particular attention to callbacks invoked by dialogs, because values may be copied, transformed or lost between creation and confirmation. For a narrower example of following callback parameters, the dialog parameter walkthrough offers a useful companion to the Swamp inspector view.

Inspecting objects and runtime state

The object inspector should reveal more than a class name. Check object identity, inheritance, slot values, ownership and the collection containing an element, then expand only the branches needed for the investigation. Identity is especially valuable when two records appear equivalent in the user interface but refer to different persistent objects within the Smallworld database.

Use a scratch buffer for small evaluations and keep each expression close to the observed problem. Read-only accessors are usually safe, while setters, collection mutations and methods that commit transactions can change the state being investigated. If a value changes unexpectedly, capture it before continuing. A clear sequence of object, slot and timestamp evidence is more valuable than a large transcript containing unrelated evaluations.

Navigating methods in large code bases

Emacs becomes particularly effective when the stack points into a package that is difficult to visualise in a conventional debugger. Search for the method name, move to its definition and use folding to isolate the relevant branch. Keep the stack frame visible while editing so that a renamed local variable or changed guard condition remains connected to the observed execution path.

Compiler and source mismatches can invalidate an otherwise convincing investigation. Recompile the affected package, refresh the runtime source mapping and confirm that the breakpoint now resolves to the intended definition. Repeat the smallest failing path after each change, and record the method, receiver and argument values needed to reproduce it. This turns an interactive debugging session into evidence another developer can test.

Analysing collections and controlling risk

Collections reveal faults that isolated objects can hide. The Swamp debugger can help inspect collection size, element types, ownership and selected values without loading an entire dataset into the editor. Sample representative records, check the predicate involved in a query and watch transaction boundaries while stepping through collection operations. Avoid broad evaluations on large persistent collections, since they may consume substantial memory or hold locks.

Australian utility, council and mining systems commonly combine operational, geographic and customer information. Where records contain personal information, the Privacy Act 1988 and Australian Privacy Principles constrain how debugging data is accessed, recorded and shared. Use least-privilege accounts, redact customer details from logs and screenshots, and keep production evidence under the organisation’s access controls. A read-only connection is preferable when the investigation does not require a code change.

Make the final debugging run repeatable: capture the revision, package, database state, breakpoint conditions, stack frames and representative values. Store only the evidence required for the defect, and remove temporary access to sensitive records when the investigation ends. This protects the application while making the result usable by a distributed support or development team.

Install the Emacs extensions in a test configuration, attach to a disposable Smallworld process and reproduce one controlled fault from breakpoint to inspection. Record the full evidence chain, then turn that manual run into a documented procedure. Make the first focused debugging session today and keep its breakpoint, frames and collection findings with every defect report.