mirror of
https://github.com/logos-co/logos-tutorial.git
synced 2026-08-30 12:21:12 +00:00
feat/updateUiTutorialForQmlHotReloading
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dario LipicarandClaude Opus 5
|
efaa390484 |
docs: the widened Qt consumer surface (#84)
* 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
|
||
|
Dario Gabriel LipicarandClaude Opus 4.8
|
dbce6ad7ca |
tutorial-v4 release
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>
|
||
|
Dario LipicarandClaude Opus 4.7
|
c2cd6f09eb |
docs: LIDL-based dependency consumption + dependency_overrides (#65)
* 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> |
||
|
Dario LipicarandClaude Opus 4.8
|
c84322d50c |
Add "Composing Modules" tutorial: calc_aggregator core module (#63)
* 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> |