* 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>
* docs: --module-dir was removed from logos-cpp-generator
The generator now refuses the flag (exit 2) instead of accepting it, so both
places the guide spelled it were about to become instructions that hard-error.
Replaced with the supported form: `--general-only` plus one
`--dep <name>=<name>.lidl` per dependency, which generates each wrapper from
that dependency's contract rather than by loading its built plugin.
Tutorial Sync Rule; the code change is in logos-cpp-sdk
(cpp-generator/legacy/main.cpp).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(dev-boost): name an artifact the toolchain can still produce
The CMake block listed calc_wrap_qt_glue.h and calc_wrap_dispatch.cpp in
logos_module(SOURCES …). Those were emitted by --backend qt, which is deleted;
a module now emits <name>_cdylib_glue.{h,cpp} and Qt-plugin packaging is a
downstream step.
Nothing goes red — logos-tutorial has no dev-boost doctest — so this would have
stayed wrong silently. It was likely already stale (logos-dev-boost contains no
_qt_glue string at all), but the deletion turns "out of date" into "permanently
unbuildable", which the Tutorial Sync Rule exists to prevent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
The guide had no Windows content at all, and `lgpm` grew a `--platform` flag
(logos-package-manager 1ac7963) that nothing documented. Three additions, all
places the guide already made a claim that is now incomplete or wrong for
Windows:
* The variant-naming table gains `x86_64-windows`, with a note that the spelling
is `windows-x86_64` and — unlike Linux, which accepts both `linux-x86_64` and
`linux-amd64` — it has NO alias, so a package labelled `windows-amd64` simply
will not install.
* 5.1 documents `--platform`, including why the default refusal exists. lgpm
derives the variant from the machine it runs on and fail-closes otherwise;
that refusal is the protection against installing a package built for one
platform onto another, so the opt-out is explicit and never inferred, applies
to install/list/info alike, and prints to stderr when active.
With an explicit warning NOT to use it for a dev/portable mismatch: forcing
that installs a package the runtime cannot load, trading a clear install-time
error for a confusing load-time one.
* "Cross-platform builds" said to build on each target platform separately.
That cannot be done for Windows — there is no Nix daemon for Windows, so it is
cross-built from Linux (or from WSL2, which is Linux) and copied across.
Branched from master rather than the checked-out fix/ui-doctest-launch-timeout
so this carries none of that branch's work.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Adds the metadata flag row + §1.6 explaining single vs multi, the per-language
thread-safety contract (Rust &self + Send + Sync / C++ self-synchronize), and the
"how it works" model: the module owns concurrency behind the ordinary callMethod
(pending sentinel + completion event) with NO provider/host ABI change, so an old
daemon/app loads + forwards a multi module unmodified. Protocol 0.2 (additive
minor). Notes the event-ordering caveat and the pre-0.2-caller caveat.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add the new `.#generate` output (runs every code generator and emits a
ready-to-build module source tree) to the build-outputs section of the
developer guide.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs: replace logoscore inline (-c) mode with daemon/client workflow
logos-logoscore-cli's inline mode (`logoscore -m <dir> -l <mod> -c
"mod.method(args)" --quit-on-finish`) has been removed. Update the developer
guide and the wrapping-a-C-library tutorial to use the daemon + client
workflow instead:
logoscore -D -m ./modules -l my_module & # start a daemon, pre-load module
logoscore call my_module doSomething hello # call (positional args; @file ok)
logoscore stop # stop when done
- §5.1 "Inline Mode (Legacy)" → "One-shot execution" (daemon + `call`), with a
note that inline mode was removed and a daemon-startup flags table.
- CLI quick-reference: drop the inline one-liner; show daemon pre-load instead.
- Troubleshooting "quick check": load-module + call + stop.
- tutorial-wrapping-c-library spec + its rendered output: "inline (legacy)
mode" → "the full daemon/client workflow".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs: address review — fix §6.1 anchor, daemon readiness waits, document --config-dir
- Fix the "Running with logoscore" link anchor: #51 → #61 (the section is 6.1;
the old anchor 404s). In both the wrapping-c-library spec and its output.
- Daemon examples background `-D` then call immediately, which can race daemon
startup. Wait for readiness (`until logoscore status; do sleep 0.2; done`) in
the §6.1 one-shot example and the troubleshooting quick-check; background the
previously-foreground openmetrics `-D` snippet too.
- Document `--config-dir` (and `--persistence-path`) in the daemon startup flags
table, since the openmetrics example uses `--config-dir`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs: daemon starts clean — drop -l, load modules via load-module
Follow-up to dropping inline mode: logoscore's daemon now starts clean (the
-l/--load-modules autoload flag is removed). Update the §6.1 one-shot example
and CLI quick-reference to start a clean daemon and load modules with
`load-module`; drop the -l row from the daemon startup flags table.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <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>
* feat: dependency interfaces tutorial (executable)
Add tests/tutorial-interface-dependencies.test.yaml — an executable
logos-doctest tutorial that builds calc_via_interface: a module declaring a
`calculator` interface and binding it to calc_module at runtime. Covers typed
sync/async/event calls, the no-validation rule, and the cross-repo interface
form. Registered in run.sh and CI (run + generate). Documents
interface_dependencies + bind_<interface> in the developer guide.
Depends on logos-cpp-sdk#74, logos-module-builder#108, logos-plugin-qt#8 —
the published flakes must carry these before the tutorial runs green in CI
(same release gating as the Composing Modules tutorial).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* address review: self-valid interface header + accurate CI step
- Interface calculator.h includes logos_module_context.h so the logos_events
token is defined (valid C++ standalone); prose updated accordingly.
- CI step name/comment now reflect the third tutorial leaf
(tutorial-interface-dependencies), not just the UI chain + Composing Modules.
(Copilot review, PR #64.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* rerun
* rerun
* fix(tutorial): correct the no-validation negative test
Binding to a module that isn't loaded does NOT return a silent default — the
inner remote call fails and propagates, so `logoscore call ... sumVia
no_such_module` exits non-zero with RPC_FAILED. The step asserted "result":0
and let the non-zero exit fail the doctest step. Reframe it accurately: a bad
bind surfaces as an ordinary RPC failure (not a crash); absorb the exit with
`|| true`, capture stderr, and assert `"status":"error"`. Fix the prose and the
recap row to match.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. removes adding standalone-app as dependency from the ui modules they
get it out of the box when using module-builder
2. just using latest version of standalone app and now we have all
dependecies auto packaged and installed
1. Adapt to changed made in standalone app to use capability module
directy so it doesnt have to be loaded manually
2. adapt to using nix deriuvation for lgx packages directly from modules
