Skip to content
KN-86 Deckline

loglens-core

What it is

Section titled “What it is”

loglens-core is “the lightning-fast, structured log parsing engine built in Rust” — a headless library, not an application. It does two things: (1) takes a raw log line and parses it into a structured record with zero configuration (auto-detecting JSON vs logfmt without a schema), and (2) evaluates a small query expression against that record to decide whether it matches. It deliberately ships no UI — it’s the engine that a separate CLI/TUI (or any other app) embeds. That core/UI split is the entire reason this entry routes to research/ rather than inspiration/: it’s an architecture reference, not a look reference.

Key takeaways for KN-86

Section titled “Key takeaways for KN-86”
  • The headless-engine / clean core split is the architectural lesson. loglens-core’s public API is essentially two functions — parse_log_line() (raw string → LogEntry, auto-detecting format) and evaluate() (structured value + query string → Result<bool, QueryError>) — and nothing about rendering, terminals, or I/O leaks into it. The same engine powers loglens’s own CLI/TUI and can be dropped into an unrelated app. This is the exact discipline KN-86 wants between its model/eval layer (Fe VM + nOSh state) and its render layer (display/oled/input): the engine reads strings and returns verdicts; the caller decides what to draw. It’s the log-query restatement of the same split sheetsui gets from ironcalc and csvlens gets from its run_csvlens() library form. Three Batch-8 entries independently converge on “make the data engine a separable, callable module” — that convergence is itself the finding.
  • The query language is a tiny embeddable expression evaluator — and a direct model for a KN-86 cart filter DSL. Queries look like level == "error" && latency > 500 (also latency > 500 && level is error), with comparison operators (==, >, is) and logical connectors (&&). It’s a small boolean expression language over named fields, evaluated against a parsed record. This is precisely the shape of a filter predicate a KN-86 table/log cart needs — and it’s the bridge to the cluster’s recurring Lisp angle: where loglens-core hand-rolls a mini expression parser + evaluator, KN-86 already has an expression evaluator (the Fe VM, per fe / ADR-0004), so a KN-86 cart gets (and (eq (field row 'level) "error") (> (field row 'latency) 500)) for free — no separate query-language parser, no QueryError type, just a Lisp predicate over the row. loglens-core is the worked example of the feature; the Fe VM is the reason KN-86 doesn’t have to build the parser half of it.
  • Zero-config format detection is a useful ingest pattern. parse_log_line() sniffs JSON vs logfmt and parses accordingly, returning a structured LogEntry without the caller declaring a schema. For a KN-86 cart that ingests data off the SD-card cartridge (logs, tables, save fragments), “detect the shape, parse it, hand back a structured record” is the right ingest ergonomic — the cart shouldn’t have to be told the format if it can be inferred. The pattern (sniff → parse → structured record → evaluate predicate) is a clean four-stage pipeline worth reusing.
  • The parse→evaluate pipeline is the reusable shape. Raw string → parse_log_line() → LogEntry::Structured(value) → evaluate(value, query) → bool. Each stage is independently testable and the boundary types are minimal. This is good model hygiene for the KN-86 cart runtime: keep parse, structure, and predicate-eval as distinct stages with small interfaces, so a cart can swap any one (different parser, different predicate language) without disturbing the others. The fact that loglens-core keeps its AST internal (the public API exposes evaluate(), not the parsed expression tree) is also a deliberate encapsulation choice worth copying — expose the verdict, hide the machinery.

Image

Section titled “Image”

No image — loglens-core is a headless library captured as an architecture/query-engine reference, not a visual one.

Notes

Section titled “Notes”
  • Batch 8. Routed to research/ (engine architecture), paired with logradar (the log-rendering side) — together they bracket the log-tooling problem: loglens-core is parse+query, logradar is cluster+visualize.
  • The single most-borrowable idea: the headless engine with a two-function surface (parse_log_line / evaluate). It’s the cleanest Batch-8 statement of the model/render split KN-86’s nOSh ↔ display boundary should hold.
  • Cross-link fe.md — the KN-86 expression evaluator that makes loglens-core’s hand-rolled query language redundant for carts; the Lisp predicate replaces the mini-DSL.
  • Cross-link sheetsui.md (ironcalc-as-dependency) and csvlens.md (library form) — the same separable-engine principle from the spreadsheet/CSV side.
  • Cross-link csvlens.md specifically on the filter-as-predicate idea — csvlens shows the interaction (point at a cell → get a filter), loglens-core shows the engine (a boolean expression over fields), and Fe is the evaluator that unifies them.