* test(doctests): `lm` publishes the LIDL contract vocabulary, not Qt names
A universal module's `getMethods()` comes from the cdylib backend's
`lidlInterfaceJson()` (logos-plugin-qt's glue forwards
`logos_module_get_methods` verbatim), and that now answers in the LIDL
contract spelling. `lm methods`, `lm events` and `logoscore module-info`
print those strings straight through, so every listing in Part 1 changed:
qlonglong add(qlonglong a, qlonglong b) -> int add(int a, int b)
QString libVersion() -> tstr libVersion()
void versionReady(QString version) -> void versionReady(tstr version)
Six `expect_contains` in tutorial-wrapping-c-library.test.yaml were pinned
to the Qt spellings and now fail.
HOW THIS WAS ALMOST MISSED, because the trap will recur. The hand-pinned
`outputs/tutorial-wrapping-c-library.md` already showed `int add(int a, int b)`
and `add(int,int)` — a stale snapshot from an earlier era that happened to
read as "already LIDL, nothing to do". CI runs the ASSERTIONS in
`tests/*.test.yaml`; it never diffs the outputs tree. Clearing a file by
reading `outputs/` proves nothing.
Every replacement string is derived mechanically rather than by hand: the
tutorial's own `src/calc_module_impl.h` + `metadata.json` were run through
`logos-cpp-generator --from-header --backend cdylib`, the emitted
`lidlInterfaceJson()` was parsed back into JSON, and that JSON was rendered
through logos-module's own printer (`cmd/main.cpp`) and logoscore's
(`src/client/output.cpp`). The displayed blocks in BOTH trees now compare
byte-identical to that render.
Two accuracy fixes fall out of doing that, both pre-existing drift in the
blocks being rewritten:
* the derived identity methods `name()` / `version()` DO appear in every
listing (nothing filters `derived` on the read side) and were missing
from the shown output;
* the `module-info` block said `libVersion() -> QString` and
`versionReady(version: QString)`.
The C++-type table gains a column. "On the wire (Qt)" conflated two
different questions; it is now "LIDL contract type" — what the module
publishes, what Step 5 prints, what a Rust or Nim binding sees — and "A Qt
consumer sees", which is only the C++/Qt caller's spelling.
Also here, same cause:
* tutorial-composing-modules and tutorial-interface-dependencies had the
same "shows up as QString ... the wire types the generated glue exposes"
prose. Their assertions are name-only, so they did not fail — but they
described the listing wrongly. `LogosMap` publishes as `{tstr: any}`,
verified by generating calc_aggregator's glue.
* logos-developer-guide.md's `lm methods --json` example was a
handwritten-Qt listing (`initLogos(LogosAPI*)`) presented as the general
case. It now shows both publishers and says which is which: a universal
module publishes its contract, a handwritten Qt plugin publishes what its
QMetaObject says.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(guide): the plugin path needs the module's contract, not just its plugin
`logos-cpp-generator <plugin> [--module-only]` is documented here as a way to
generate a module's consumer wrapper, and the examples pass only the plugin.
That is now a trap for any module built with `interface: "universal"` or
`"cdylib"`: its published `getMethods()` answers in the LIDL contract
vocabulary — the same change d963871 pinned in the `lm` listings — while the
wrapper emitter reads Qt type names and falls back to QVariant / LogosMap for
anything else. The wrapper would compile and have lost every type.
The generator now takes the METHODS from the `.lidl` contract named by
`--events-from` (the flag keeps its name; the file always was the whole
contract), and REFUSES a LIDL-spelled listing when no contract was given rather
than emitting the untyped wrapper. Nix builds already pass the flag —
buildHeaders.nix finds `<module>/share/logos/<name>.lidl` — so only hand-run
invocations, which is what this section documents, had to change.
Both examples gain the flag, a second example shows the handcrafted-Qt case
that legitimately omits it, and the synopsis in the CLI reference lists it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Update artifacts for tutorial-v4. Regenerate outputs/ against the 0.2.0
release tags: every {release} reference (logos-basecamp, logos-logoscore-cli,
logos-module-builder, logos-package-manager, logos-module) now resolves to
0.2.0 in both the generated .md tutorials and the example module flake.nix
files.
- Add the missing {release} placeholder to the advanced flake.nix examples in
tutorial-wrapping-c-library and tutorial-interface-dependencies so they pin
consistently.
- run.sh: clean now also removes the .logoscore persistence dirs; --release
examples updated from tutorial-vN to 0.2.0 (repos carry semver tags;
logos-tutorial carries the tutorial-vN tag).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: document LIDL-based dependency consumption + dependency_overrides
Tutorial-sync for "concrete dependencies via LIDL":
- Developer guide §9.2: explain that each module publishes a cheap LIDL
interface contract (packages.<sys>.lidl) and that consuming a dependency
generates modules().<dep> from that LIDL WITHOUT building the dependency's
plugin — only the standalone-app run (#run) bundles/builds deps. Notes the
cross-language pipeline (Rust -> LIDL -> C++) and the transitional fallback
for deps that don't yet expose a `lidl` output.
- Document the new `dependency_overrides` metadata field (§9.2 + field table).
- Composing Modules tutorial: correct the prose that said the builder "fetches
calc_module's headers" — it now reads calc_module's published LIDL contract
and does not build calc_module's plugin at the aggregator build step.
Depends on logos-cpp-sdk#77, logos-plugin-qt#9, logos-module-builder#110 (the
described behavior ships with those).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* address review: regenerate composing tutorial md; reconcile §8.2/§9.2
- Regenerate outputs/tutorial-composing-modules.md so the committed markdown
matches the updated YAML prose (it had stale "fetch headers" / "exported
interface" wording). Verified identical to `doctest generate`.
- Developer guide §9.2: add a note tying the LIDL-contract dependency wrapper
generation to §8.2 — it's the same logos-cpp-generator driven by the dep's
LIDL/.h contract (like interface_dependencies) rather than inspecting a
compiled plugin (the manual/standalone path), so the two sections no longer
read as conflicting mechanisms.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add "Composing Modules" tutorial: calc_aggregator core module
New executable tutorial (tests/tutorial-composing-modules.test.yaml) that
builds calc_aggregator, a core (universal) module depending on calc_module,
showcasing every LogosModuleContext capability end-to-end via logoscore:
- modulePath / instanceId / instancePersistencePath getters
- durable per-instance persistence (a run counter that survives a restart),
wired up in onContextReady()
- typed sync dependency calls (computeReport composes five calc_module calls
into one map)
- typed async dependency call (fibonacciAsync with a callback)
- typed event subscription (onVersionReady on calc_module's versionReady)
Driven entirely from the logoscore daemon (no UI), mirroring Part 1's flow.
Also:
- README: list the tutorial and the calc_aggregator example module
- run.sh: build the module into outputs/ via --workdir (reusing the chain's
calc_module, no rebuild) and clean its calc-data/ persistence dir
- ci.yml: run the new spec and verify its markdown generation
- outputs/: rendered tutorial + cleaned module source
The typed event subscriber requires logos-cpp-sdk PR #72 (LIDL parser: accept
reserved words as identifiers in name positions) so calc_module's versionReady
event sidecar round-trips; the doctest's event step stays red against published
deps until that lands and the module builder bumps its SDK pin.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* rerun
* Address review: warn about SDK dependency, make CI non-blocking
- prerequisites + event step: explicit toolchain note that the typed event
subscriber needs logos-cpp-sdk#72 (calc_module's `version` event param
collides with a reserved word), with a workaround (pin a fixed
logos-module-builder, or skip the event step — everything else works on
the released toolchain).
- ci.yml: split the Composing Modules spec out of the blocking UI-chain run
into its own `continue-on-error: true` step so it doesn't block merges
until #72 lands; a comment says to fold it back in once the dep ships.
- regenerate outputs/tutorial-composing-modules.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Re-enable Composing Modules as a blocking CI tutorial
logos-cpp-sdk#72 (LIDL parser: reserved words usable as identifiers) is merged
and logos-module-builder has bumped its SDK pin, so calc_module's versionReady
event sidecar now round-trips and the typed onVersionReady subscriber builds on
the published toolchain.
- ci.yml: fold the spec back into the blocking UI-chain run (and the published
two-column report); drop the temporary continue-on-error step.
- spec: remove the now-obsolete toolchain prerequisite note and the event-step
heads-up.
- regenerate outputs/tutorial-composing-modules.md.
Verified end-to-end against the published toolchain: 77/77 doctest steps pass,
including the build and the full event round-trip.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Khushboo Mehta