Magik’s debug log: Filtering with Emacs’ log-edit

Magik’s debug log can become a wall of method names, collection identifiers, transaction markers, and runtime messages. The useful failure may be one line among thousands, especially when a procedure runs from a scheduled task rather than an interactive Smallworld session. Emacs’ log-edit turns that diagnostic output into a filterable working view, letting a Magik programmer isolate suspect entries without discarding the captured evidence.

Filtering becomes practical when the question is narrow: Did a collection fail inside a particular transaction, which method emitted the warning, or which errors followed a schema change? log-edit can filter by regular expression, fixed text, priority, or tag, then remove or relax a filter as the investigation develops. The result is a faster path from raw runtime output to a method, collection, or data condition that can be tested.

Australian teams encounter an additional complication when investigations cross cities. Sydney and Melbourne alternate between AEST and AEDT, Brisbane remains on AEST, and Perth alternates between AWST and AWDT. Recording an explicit UTC offset prevents a copied timestamp from appearing to precede the event that caused it, particularly during a screen-share or stand-up when several people are following the same diagnostic sequence.

The workflow must also suit the Australian Smallworld consulting market. HydePark Consulting serves developers and organisations maintaining Magik-based systems, where a compact runbook can be more useful than an elaborate debugging framework. For a covered organisation handling personal information, the Privacy Act 1988 and Australian Privacy Principles may apply to logs containing operator names or identifiable customer records. Shared notes should use 24-hour timestamps, Australian spelling such as “analyse”, and redacted excerpts where appropriate.

Why log-edit fits Magik diagnostics

Log-edit is an Emacs major mode for working with structured text. It treats a file as a series of entries, displays those entries with useful headers and fonts, and lets filters hide entries that do not match a criterion. That makes it well suited to diagnostic output even when the log was not generated by Emacs.

A simplified Magik diagnostic log might contain records shaped like this:

2025-03-18 14:07:32.118 ERROR tx=884213 method=sw_collection.open C=445901
2025-03-18 14:07:32.204 INFO  tx=884213 method=sw_transaction.begin
2025-03-18 14:07:33.001 WARN  tx=884213 method=sw_collection.scan

Open the captured file with C-x C-f, then run M-x log-edit-mode. Filters change the visible selection rather than deleting source text, so the same buffer can move from a broad error view to a single transaction without repeatedly reopening the file.

Prepare a clean, searchable working copy

Preserve the original log before adding filters or tags. If the log is still being written, capture a snapshot using the redirect or logging mechanism provided by the runtime, service wrapper, or scheduled-job configuration. Then use M-x copy-file or a directory copy to create a working file. The snapshot provides a stable point of comparison while the live source continues to grow.

Entry boundaries matter because log-edit filters operate on entries, commonly a header and body separated from the next entry by a blank line. A diagnostic stream containing one continuous line per event may not divide naturally. On the working copy, M-x query-replace-regexp can insert a blank line before every timestamp. For the example format, search for ^\([0-9-]+ [0-9][0-9]:\) and replace it with \n\1, then reopen the file in log-edit mode.

Give working copies unambiguous names that include the date, time, and offset, such as 2025-03-18T1432+1100-debug.log. Use AWST, AEST, or UTC according to the source rather than applying one Australian zone to every file. Check the copy for personal information before circulating it beyond the immediate investigation team, particularly when the source came from a customer environment.

Build the first useful filters

Begin with the simplest reliable value. Run M-x log-edit-add-filter, choose the fixed-string option, and enter a transaction identifier such as tx=884213. Run C-c C-a to apply the filters. A literal search is useful for identifiers containing punctuation that has special meaning in a regular expression, including brackets, full stops, and question marks.

Use a regular expression when the relationship between fields matters. Choose the regexp option in M-x log-edit-add-filter and enter \\(ERROR\\|FATAL\\) to retain entries containing either severity. The expression is matched against the visible content of each entry, including its header and body. Another useful expression is tx=[0-9]+, which isolates every line associated with a transaction while allowing the particular identifier to vary.

Add filters progressively rather than constructing a large expression immediately. Start with ERROR, apply it, and inspect the result before adding a transaction constraint. If two filters hide everything, disable or remove one from the Filters menu and run C-c C-a again. Once the set is useful, C-c C-n and C-c C-p can move between entries that log-edit recognises as errors.

Combine priority, tag and transaction filters

A priority filter is valuable when the log follows log-edit’s recognised priority conventions. Choose Priority from M-x log-edit-add-filter to concentrate on Error, Fatal, or another configured severity. A plain word such as ERROR in an arbitrary Magik log does not automatically become a log-edit priority; use a regexp filter when the format is custom.

Tags provide another way to organise confirmed material. A tag is metadata associated with an entry, rather than any keyword found in its text. Use C-c C-t to tag the current entry, then filter by that tag as the investigation develops. This is useful for marking a reproducible exception separately from warnings that are noisy but harmless.

The most effective sequence is often priority first, tag second, and transaction identifier last. Priority reveals the relevant failure class, the tag preserves a reviewed group, and the transaction narrows the view to one reproducible operation. Use fixed-string filtering for the final identifier when its exact characters are known.

Preserve evidence while narrowing the view

A filtered display is a diagnostic view, not a replacement for the original file. Filters normally leave entries in the Emacs buffer, while adding tags, comments, or headings modifies buffer text. Keep the untouched capture, perform annotations only on the working copy, and save that copy under a separate name. This distinction matters when an incident review needs to establish exactly what the process emitted.

Record the investigation steps in the change ticket or runbook. Include the filter type, the exact expression, the relevant transaction or method, and the log filename with its timestamp and UTC offset. A future developer can then reproduce the same view rather than infer the original selection from a screenshot. Where the team uses chat during an Australian support handoff, retain the formal filter details in the ticket as the durable reference.

A checksum adds another layer of traceability. Record the SHA-256 value of the original capture with sha256sum on Unix-like systems or Get-FileHash debug.log -Algorithm SHA256 in PowerShell. Store that value beside the ticket and preserve the original file with its read-only access permissions. The hash does not explain the fault, but it establishes that the evidence examined later is the same evidence captured during the incident.

Make filtering a repeatable team workflow

A dependable Magik debugging routine starts with a preserved capture, creates a dated working copy, opens it in log-edit, and applies filters from broad to narrow. The resulting entry list should identify a method, collection, transaction, or runtime condition that can be tested independently. Saving the filter expression alongside the ticket converts a successful manual search into a repeatable procedure for the next developer.

This approach suits teams spread across Australian offices and customer sites. A Brisbane developer can hand a filtered transaction summary to a Melbourne colleague, while a Perth site contact checks the same transaction in the source system. Explicit offsets prevent timing confusion, and redacted excerpts keep commercially or personally sensitive information out of broadly shared messages.

Open the next redacted Magik debug log today, copy it to a dated working file, and apply one transaction-level filter before the next debugging session. Keep the original capture untouched, record the filter expression in the ticket, and use the visible entries as the starting point for the next reproducible test.