The playground lets anyone try the configuration language of Stellar Control in a browser, without an account and without installing anything. It opens the configuration repository of a template — a test bench, a fleet, a balloon, a laboratory, a pumping station or the satellite platform — and checks it as you type with the compiler of Stellar Control itself, compiled to WebAssembly. Nothing leaves the page: the repository lives in the browser.
It is on the onboarding of the online trial: https://control.stellar-systems.eu/#/playground, or
#/playground/<template> for one template.
What it does#
| Part | What it shows | As on the command line |
|---|---|---|
| Editor | The files of the repository, highlighted (YAML, steps and procedures); the problems underlined where they are, their message on hover | — |
| Problems | Each diagnostic: severity, message, file:line, code and help; a click opens the file at its place | stellar check |
| Repository | The hash of the snapshot, the catalogues, the topology, the libraries (steps, procedures, whether to lock again) and the simulations | stellar compile, stellar check |
| Simulation | The simulation of a platform written from its catalogue, each telecommand checked in simulated time, what is left to complete; Add to the repository puts it among the files. A simulation of the repository checked against its catalogue | stellar generate simulation, stellar sim check |
The snapshot is the same as stellar compile gives on the same files: the same hash, to the bit.
A check takes a few hundred milliseconds and runs in a Web Worker, so the editor stays responsive.
Reset gives the files of the template back; Get an environment goes on to the trial, where the
same configuration runs on simulated equipment, with the web console and its editor.
The playground does not run procedures: a dry run needs the services of the MCS and a NATS server. That is what an environment of the trial gives.
The WebAssembly module#
The playground is built on tooling/wasm (crate stellar-wasm): the part of stellar that only
computes on a configuration repository — the compiler, the code generators and the simulation
engine — compiled for wasm32-unknown-unknown. A repository is an object of texts, paths relative
to its root:
import { load } from './stellar.js'
const stellar = await load()
const files = { 'topology.yaml': '…', 'packages/lab-psu/catalogue.yaml': '…' }
const checked = stellar.check(files)
// { errors, warnings, diagnostics: [{ severity, code, message, help, file, range, rendered }],
// snapshot, catalogues, libraries, simulations, topology }
const written = stellar.generateSimulation(files, 'lab-psu')
// { path, yaml, todo, selftest: [{ telecommand, args, verdict, after_ms | reason }] }
const report = stellar.simCheck(files, 'lab-psu-sim')
const schema = stellar.schema('catalogue') // catalogue, library, topology, simulation| Function | Gives | Throws |
|---|---|---|
check(files) | Diagnostics, positions as in the Language Server Protocol (zero-based lines, columns in UTF-16 units) and as stellar check prints them (rendered); the summary of the repository; snapshot is null when an error was reported | — |
generateSimulation(files, catalogue, name?) | simulations/<name>.yaml (<package>-sim by default) and the check of each telecommand | The repository does not compile; no such catalogue |
simCheck(files, simulation) | The check of each telecommand of a simulation of the repository | The repository does not compile; no such simulation |
schema(kind) | The JSON Schema of a kind of file | Another kind |
version() | The version of Stellar Control of the module | — |
tooling/wasm/build.sh [OUT] builds it: the target wasm32-unknown-unknown, wasm-bindgen
(cargo install wasm-bindgen-cli at the version of Cargo.lock; the script refuses another) and,
when present, wasm-opt. It writes stellar_wasm_bg.wasm (about 4.8 MB, 1 MB compressed),
its glue stellar_wasm.js and the wrapper stellar.js to tooling/wasm/pkg. The onboarding
image builds it in a stage of its own.
What does not build for WebAssembly stays on the command line: the commands that talk to the API or to NATS (the web console does that in a browser), and dry runs.