flame 0.7.1

flame 0.7.1 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.7.1/flame 3fa1833dc7937301797f45309ab496d7f260bbcbd98c878ad289e1073e25ca88
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Build against Pyrocosm 0.7.0 (#34)

Moves to Pyrocosm 0.7.0.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.7.1.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.7.1

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh and install.ps1, which https://propensive.dev/flame serves. Each executable
externalizes the libraries above, resolving further dependencies from the Soundness and proscala
releases and from Maven Central on first run.

flame 0.7.0

flame 0.7.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.7.0/flame ccfb8c22261a694153b4ff0ba849bfdc0b718fcdaad919be36a8d69e53c225b6
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Pass the signing seed to the release workflow (#33)

Releases now receive the signing seed, so they can sign their executables.
The release job runs in the release environment, which holds UPGRADE_SIGNING_SEED, but it still saw the secret as empty and refused to release:

release: etc/keys/release.pub exists, but UPGRADE_SIGNING_SEED is not set; it is the secret of the `release` environment

A reusable workflow sees only the secrets its caller passes, even those of an environment its own job names. This passes them with secrets: inherit, as Pyrocosm's release workflow already does for PROPAGATE_TOKEN. The seed is still an environment secret, so only a version tag can reach it, and only after a reviewer approves the job.

actionlint is clean on the workflow. The next tagged release is the real test, and it stops before publishing anything if the seed is still missing.

Take the version from the release tag alone (#32)

A release's version is now declared once, by its tag. There is no flameVersion to bump before tagging, so a tag can no longer disagree with build.mill and fail the release.

• settings.version gives FLAME_RELEASE_VERSION when a release or snapshot sets it. Otherwise it gives the patch after the latest release tag reachable from HEAD: 0.7.1 after 0.7.0, which sorts after that release and before whichever follows. Where no release tag is reachable, as in CI's shallow checkout, it gives 0.0.1.
• publishVersion is that version, and buildVersion is that version plus the tree hash outside a release.
• The launcher resolves flame-client at client.publishVersion(). In a release that is the tag's version, which is the coordinate Burdock must externalize against.
• make snapshot takes its base from ./mill show flame.client.publishVersion, so a snapshot after 0.7.0 is 0.7.1-<hex>.
• The release instructions in the Makefile and docs no longer ask for a bump. release.sh already skips its pin check when build.mill declares no version.

A development build's publishLocal also no longer installs jars under a released version, where they could shadow the real release in ~/.ivy2/local.

Verified locally:

• ./mill show flame.client.publishVersion gave the patch after the latest local tag.
• With FLAME_RELEASE_VERSION=9.8.7, publishVersion and the launcher's mvnDeps both gave 9.8.7.
• buildVersion gave the next version with the tree hash.

Recovery and release keys (#31)

Package with xek 1.3.0, and release in the release environment (#30)

Packages flame with xek 1.3.0, and prepares its releases for signed executables that can upgrade themselves.

• etc/xek.tsv pins xek 1.3.0. Its digest matches xek's published 1.3.0.SHA256SUMS.
• make flame runs dist/xek build, since every xek command line from 1.1.0 begins with a subcommand.
• etc/github-ref moves to the shared scripts with propensive/.github#34 and #35. Those scripts build with the build subcommand, and sign the executables once etc/keys is committed. They also attach upgrade.tsv to every release and write install.ps1 with xek installer. etc/shared takes the canonical copy, which differs only in a comment.
• release.yml runs the release in the release environment, which holds the signing seed.

propensive/.github#34 and #35 are merged, and etc/github-ref pins their merge commit. Create the release environment with bin/settings apply flame before the next tag; otherwise GitHub creates it on the first release with no protection.

With this alone, the next release is built and published unkeyed, with a note saying so. It becomes the first signed release once etc/keys/release.pub and recovery.pub are committed.

Also:

• make flame builds with --java-min 25 --java 25, as released executables now do: an installed Java older than 25 is passed over, and Java 25 downloaded.

Run fume 0.7.0, flair 0.6.0, flame 0.6.0 (#29)

Moves etc/tools to the latest releases of the tools this repository runs: fume 0.7.0, flair 0.6.0, flame 0.6.0.
fume 0.7.0, flame 0.6.0 and flair 0.6.0 are built against Soundness 0.71.0 and Pyrocosm 0.6.0. Nothing else changes.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.7.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.7.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh and install.ps1, which https://propensive.dev/flame serves. Each executable
externalizes the libraries above, resolving further dependencies from the Soundness and proscala
releases and from Maven Central on first run.

flame 0.6.0

flame 0.6.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.6.0/flame 9c893c9f49643de18baeff736fb7aaf2d07ab60a89c0358d85060303a8528a60
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Release 0.6.0 against Soundness 0.71.0 and Pyrocosm 0.6.0 (#28)

Builds flame against Soundness 0.71.0 and Pyrocosm 0.6.0, and prepares release 0.6.0.
This pull request was opened by Pyrocosm 0.6.0's release, to move the Pyrocosm pin. Soundness 0.71.0 needed more than that:

• The toolchain moves to Proscala 3.9.1-dev-p17 (was 3.9.0-p16), the compiler Soundness 0.71.0 is built with.
• DaemonService[?] is now Resident.
• flameVersion moves to 0.6.0, the version the next tag will release.

The tests pass under plain java and under fume.

Run fume 0.6.0, flair 0.5.0 and flame 0.5.0 (#27)

The tools this repository runs move to fume 0.6.0, flair 0.5.0 and flame 0.5.0, the releases built against Soundness 0.70.0 and packaged with xek 1.0.0.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.6.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.6.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh, which https://propensive.dev/flame redirects to. Each executable externalizes
the libraries above, resolving further dependencies from the Soundness and proscala releases and
from Maven Central on first run.

flame 0.5.0

flame 0.5.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.5.0/flame 96f6ab199f32aa35712d06f2f148a3f9f4655f001e6ae808036efdcf707b99c4
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Release 0.5.0 against Soundness 0.70.0 and Pyrocosm 0.5.0 (#26)

flame 0.5.0 is built against Soundness 0.70.0 and Pyrocosm 0.5.0, from releases rather than snapshots, and its executables are packaged with xek 1.0.0. It shows raster images and SVG drawings as media in the web front-end, wraps diagnostics without breaking types or code samples, and lets a submitted line go ahead of pending completions.
The builder pin is now etc/xek.tsv, fetched into dist/xek by make xek-fetch, and make flame packages with the xek 1.0.0 command line.

Wrap diagnostics with Flow, holding types and code samples whole (#25)

Compiler diagnostics in the terminal are word-wrapped at 80 columns, but a highlighted type or code sample must never be split, so SemanticRender.flow tracked columns by hand. Soundness #1992 (propensive/soundness#2121) taught tessellate's Flow.wrap about unbreakable spans, and flame now uses it: the message's pieces are concatenated, each type's and code sample's extent noted, and Flow wraps the prose around them — the same wrap the plain-message path already used.

• Diagnostics wrap exactly as before, with types and code samples kept whole; a type such as Map[String, Int] is now protected as a span rather than as an atomic word, with the same result.
• A multi-line code sample's own newlines remain hard breaks.

Snapshot debt. etc/refs pins Soundness 0.70.0-781ba6058e92 (commit 689be6c03c, main after #2121), published as the pre-release snapshot-781ba6058e92. A snapshot pin is a debt: this repository cannot be released until a Soundness release containing #2121 exists and the pin is bumped to it. The bump also retired the one aspire in the tests for aspirationally (probably #2101).

Let a submitted line go ahead of pending completions, and coalesce them (#24)

A line you submit is no longer held up by completions. Completions arrive with every keystroke and each costs a compile under the session's compiler mutex, so when one probe was slow a whole burst of them queued behind it, with the submitted line at the back: a daemon was seen with 24 completions and 2 evaluations parked on the lock, which made both front-ends look frozen.
Now each completion takes a ticket, and one that is no longer the latest when its turn at the compiler comes answers with nothing (the front-ends already discard a stale reply by generation), so a burst of keystrokes costs one compile. And a completion stands aside while a submission is pending, so an evaluation never waits on a probe.

The underlying slowness — the compiler stating the /home/runner/… source paths recorded in release TASTy, which an autofs-mounted /home on macOS makes ~10,000× slower than an ordinary miss — is for Soundness to fix by compiling with -sourceroot (propensive/soundness#2117); this change keeps the REPL responsive regardless.

Show images, drawings and tree-shaped data as media in the web front-end (#23)

In the browser, a result that is a hallucination Raster (Raster in Png, Raster in Jpeg, or one of no format, carried as PNG) now shows as an image, and a savagery Svg as an inline drawing, in place of their toStrings. The terminal client draws the image in colour, cropped to the terminal's width, and describes the drawing. Hallucination and savagery are on the REPL classpath, so import soundness.* is enough to build them.
A Json, Yaml, Cbor, Xml or Tel value shows as an expandable tree, one node per container or leaf, labelled in the format's own notation: the root and its children start open and anything deeper closed, each node can be opened or closed by clicking it, and those choices survive as the transcript grows. The terminal shows the whole tree. CBOR (breviloquence) and YAML (ypsiloid) join the REPL classpath.

Rendering goes through Pyrocosm's Presentable as before; the media instances come from pyrocosm-media, and each exhibited line imports them inside its own @experimental initializer, so they resolve in every session, experimental or not. The tree instances live in Pyrocosm's model and need no import.

Debt: this pins the Pyrocosm snapshot 0.4.0-ac7462379798 (propensive/pyrocosm#39). Pyrocosm has to be released, and the pin bumped to that release, before flame can be.

Pin the propensive/.github commit that fetches xek's releases (#22)

Moves etc/github-ref to the propensive/.github commit whose xeq-fetch.sh finds the builder under xek's release naming (xek-<version>/xek) as well as the old one. The next xek release can then be pinned here, and executables packaged with it, without another change. The same commit's release.sh can also propose a release to the repositories named in etc/downstream; this repository names none, so its releases are otherwise unchanged.

Run fume 0.5.0, flair 0.4.0 and flame 0.4.0 (#21)

Moves etc/tools to fume 0.5.0, flair 0.4.0 and flame 0.4.0, the releases built against Soundness 0.69.0 and Pyrocosm 0.4.0. fume 0.5.0 reads the 0.69.0 test-event schema, so the suite runs through its event stream rather than fume 0.4.1's legacy fallback. No source changes.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.5.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.5.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh, which https://propensive.dev/flame redirects to. Each executable externalizes
the libraries above, resolving further dependencies from the Soundness and proscala releases and
from Maven Central on first run.

flame 0.4.0

flame 0.4.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.4.0/flame 0b64f69628bf9d45d78a12d04c99cf566fee1cef423b914a4e9fbdd264e1ad95
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Release 0.4.0 against Soundness 0.69.0 and Pyrocosm 0.4.0 (#20)

Pins Soundness 0.69.0 and Pyrocosm 0.4.0, bumps flameVersion to 0.4.0, and moves etc/xeq.tsv from xeq-0.6 to xeq-0.9, the runner Soundness 0.69.0 packages with. The sources follow four 0.69.0 changes, with no behaviour change: the UTF-8 codec givens are renamed (charEncoders.utf8Encoder → codepages.utf8Codepage); highlighting.typecheckedScala moved out of harlequin-core into harlequin-typed, which is now a dependency; the removed stratiform-binary module is dropped, BinTEL now living in stratiform-core; and the removed delicious.semantic extension on Notice is replaced by its own definition, notice.markup.let(SemanticMessage.parse(_)). Pyrocosm 0.4.0 exhibits a thrown exception as a Block.Trace, which the test suite's text helpers now read.
The tests run under fume 0.5.0 (with flair 0.4.0 alongside in etc/tools): fume 0.4.1 reads Soundness 0.68.0's test-event schema, so a suite built against 0.69.0 would fall back to its legacy run. The suite passes on CI, 163 of 163 (plus one aspiration).

Locally on macOS, the three scope-inspection tests and the stack-trace exhibit exceed their time budgets: the released 0.69.0 jars record /home/runner/… source paths in their TASTy, and every stat under /home goes through the automounter on macOS (~10 ms each), which the compiler's source lookups multiply into tens of seconds. Snapshot jars built on this machine never had that, and Linux CI does not either.

Update the tool pins, and configure fume, flair and flame (#19)

Brings the tool pins up to the current releases and adds the per-project configuration each tool looks for, so that fume, flair and flame all run in this repository with no arguments.

Tool pins

etc/tools moves to fume 0.4.1 and flair 0.3.0, and gains flame 0.3.0. A tool is always a release and never gates one, so this is free of the release graph.

Adding flame is what makes make tools install the REPL alongside the other two.

Configuration

.pyrocosm/flame/config.tel is new. Flame resolves it upwards from the invocation directory exactly as .git is found, so flame works from any subdirectory, and it puts this project on the REPL classpath — the jar make test builds, which is the widest classpath the project has. Note that flame resolves a relative classpath entry against the project root (the directory holding .pyrocosm), where fume resolves its own against the invocation directory; the two tools genuinely differ, and the file says so.

The presence of .pyrocosm/flame/ is also how a project opts into persistent prompt history, so .pyrocosm/flame/history is gitignored.

A gitignore bug worth knowing about

The ignore patterns here were unanchored — a bare out, dist/ and the name of the built executable. A bare pattern matches a path component at any depth, not just the repository root, so .pyrocosm/flame/ was ignored wholesale and its config.tel could not be committed at all. They are now anchored (/out, /dist/, …), matching what fume already did.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.4.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.4.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and flame-windows-x64.exe); flame, the polyglot
bootstrap — a small any-shell script, to be renamed flame.bat or flame.ps1 on Windows, which
downloads the right executable, verifies its checksum, replaces itself and re-invokes; and
install.sh, which https://propensive.dev/flame redirects to. Each executable externalizes
the libraries above, resolving further dependencies from the Soundness and proscala releases and
from Maven Central on first run.

flame 0.3.0

flame 0.3.0 — the flame command for Linux, macOS and Windows, its installer, and
flame-client, flame-core and flame-web, the libraries it is built from.

Installing

curl -fsSL https://propensive.dev/flame | sh

Or, without trusting the redirect, from this release alone — a 106-byte POSIX-shell bootstrap
which downloads the flame script below, checks it against the digest given here, and runs it:

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.3.0/flame 9135016ae7aa6bbe9916b43b12b90ac076aba0333ade6fbd567e1cea75ac40e6
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF

Changes

Pin the propensive/.github commit that replaces a stale staged jar (#18)

Pins the commit of propensive/.github that fixes a staged sync doing nothing at all.
install treated an unknown digest as proof that whatever already sat at the coordinate was current, and staged assets carried no digest — so sync_releases.py --staged was inert whenever ~/.ivy2/local was already populated. That is exactly the case for a release: CI publishes this repository's own modules with publishLocal and caches the ivy2 layout under a key that does not change between a PR run and a release run, and those jars share the released coordinates without the POM and ivy.xml that release.stage embeds.

The launcher therefore compiled against jars that were not the ones being released, Burdock recorded their digests, and every one of this repository's libraries was inlined instead of externalized. propensive/.github#19 computes the digest, so the stale jar is repaired.

etc/shared runs shared scripts at the commit pinned in etc/github-ref, so nothing here picks that up until this one-line bump lands.

Update dependencies (#17)

Release by tagging rather than by make (#16)

Releases are no longer cut by hand with make release VERSION=X.Y.Z; pushing a signed tag publishes the release instead, through one shared script that every repository in the ecosystem now uses, and the release notes are generated from the pull requests that went into it.
To release flame, bump flameVersion in build.mill, merge it, wait for CI to go green on that commit, and then:

git tag -s X.Y.Z && git push --tags

The tag is the trigger. It fires .github/workflows/release.yml — fourteen lines calling the reusable scala-release.yml in propensive/.github — which runs release.sh at the commit pinned in etc/github-ref. What flame needs beyond the common path is declared in the new etc/release; the library list and the version pin are not declared there, because the script derives them from release.stage and from build.mill.

Nothing is published until every gate has passed: the tag is signed and verified by GitHub; CI is already green on that exact commit, so a release never re-runs the suite; flameVersion equals the tag; and deps.py check finds every pin, transitively, a published release. If a later step fails, the release and the tag are deleted from origin, so a retry is git tag -d X.Y.Z && git tag -s X.Y.Z && git push --tags.

The published release is unchanged in shape: the three library jars first, then — once GitHub has indexed their digests — the repackaged flame executables, the polyglot bootstrap and the installer, with the script refusing to upload an executable that inlined a library instead of referring to the release.

The readme's install line is also corrected to https://propensive.dev/flame, following the hosting change in propensive/.github#16.

Release notes are now generated

Every release's notes are assembled the same way, and the Changes section is built from the body of each pull request merged since the previous tag — the summary paragraph and the user-facing notes that pull_request_template.md has always asked for. What goes in a PR body is now what users read on the release. A hand-written overview can be added as doc/notes/<version>.md; it is optional and nothing gates on it.

Show a prompt marker before the REPL's field, and import confirmations as notices (#15)

Summary

• Prompt marker: the web REPL's field shows a Powerline `` prompt, in the accent tone while the line reads as Scala and the info tone once it reads as natural language. Settled entries, unknown commands and natural-language lines are echoed past the marker's width (Blocks.indented), so a line keeps the column it was typed at.
• Import confirmations: Imported foo.* becomes imported foo.* (Repl.messages.imported / importedClause), and the web front-end shows each as a muted notice with the clause highlighted as Scala (Blocks.imported).
• Five new tests in flame_test.scala.

Dependency

etc/refs pins pyrocosm 0.3.0-bbe78f934c26 (b9d0a9e), from the field-prompt branch, which adds Control.Field.Decoration's prompt. That's still open as propensive/pyrocosm#20. Once it merges, this should be repinned to a pyrocosm main snapshot.

Serve the web REPL in Pyrocosm's default theme (#14)

Flame's own web theme is gone: its Zed colours for code now live in Pyrocosm's default theme, so every Pyrocosm tool's pages look alike, and the web REPL takes the default.

Snapshot debt

etc/refs pins Pyrocosm at 0.3.0-dee893e2baaa (propensive/pyrocosm's web-style PR) and Soundness at 0.68.0-b963c9733024 (propensive/soundness#2038). Both must be released, and the pins bumped, before this repository can be. The Pyrocosm snapshot is not yet published; CI will resolve it once it is.

Adopt Pyrocosm's standard command line, through pyrocosm-cli (#13)

Flame now gets its housekeeping from Pyrocosm's new pyrocosm-cli module (propensive/pyrocosm#17): a Flame descriptor (Tool(t"flame", prose, web = FlameWeb)) wraps the unchanged arguments match dispatch in Flame.standard, which handles flame about, flame --version / -v, flame install (now the manpage as well as the completions, --force to overwrite) and flame quit before falling through to flame's own arms, including the flag-first ones (flame --basic, --host, the settings flags).
What goes: the Install subcommand and installCompletions, and Workspace's locator, parser and stat cache, replaced by Flame.repoFile and Flame.repoConfig (flame keeps its typed Config over the shared document, and its own upward walk for the .pyrocosm/flame history directory). The stale duplicate .fume/config.tel goes too; the real one is .pyrocosm/fume/config.tel.

What comes: the version is a META-INF/pyrocosm/flame/version resource the build writes (FLAME_RELEASE_VERSION when a release or snapshot is published, which make release now exports; otherwise the pinned version with the filtered tree hash and -dirty); a user configuration file at ~/.config/flame/config.tel alongside the repository's; and FlameWeb, so that serve and port in a configuration file bring the web REPL up in the daemon on the first invocation and keep it until flame quit. Interactive flame serve is unchanged, with its default port now read from FlameWeb.port. The flag-name collision guard in the tests gains version and force.

Verified on the built launcher (with a private XDG_RUNTIME_DIR, so the installed flame's socket directory was never touched): about, --version, -v, install (and its refusal to overwrite without --force), quit killing the daemon, flame --basic still reaching the REPL prompt, the config-driven web REPL answering on its port and stopping on quit, flame serve, and tab-completion of the standard subcommands with flame's own. Tests: 159/159 after rebasing onto main (an earlier run had one order-dependent failure, d97ea6, which also occurs on main and passes alone).

The pyrocosm pin is the published snapshot 0.3.0-980213367721: a debt, since pyrocosm 0.3.0 must be released and the pin bumped before flame can be.

Configure flair, and pin it as a tool (#12)

.pyrocosm/flair/config.tel checks every source against Consequent Style, with the licence header (now kept in etc/header.txt, extracted from the sources, which all begin with it; one file still said 0.1.0 and is fixed), and measures casts and the imperative constructs; make check runs it with the released flair 0.2.1 pinned in etc/tools. 1032 warnings across 26 files today; CI does not run the check until that is zero.

Run the tests with fume 0.4.0, in CI as locally (#11)

The shared workflow now installs the fume pinned in etc/tools (bumped to 0.4.0) and runs the suites in the test assembly with it, so test_main goes from the CI workflow; make test names the assembly explicitly, as CI does. The duplicate .fume/config.tel goes. Verified locally with make test.

Assets

flame-client, flame-core and flame-web, each attached as <artifactId>-0.3.0.jar, with
its POM and ivy.xml embedded under META-INF/maven/ — the jar alone is enough for a consumer
to resolve it. Depend on this release by pinning it in etc/refs:

propensive/flame	0.3.0

make sync-deps installs the set into a local ivy repository, transitively; see
propensive/.github for the scheme.

Also attached: one flame executable per platform (flame-linux-x64, flame-linux-arm64,
flame-macos-x64, flame-macos-arm64 and `flame-wind...

flame 0.2.0

Install (any POSIX shell):

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.2.0/flame 90e6553ba633e752a0b88b0ca6d794faa3ad96a5b7072d0cc69c865633418b4d
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF
```The `flame` polyglot bootstrap (a small any-shell script — rename to `flame.bat` or `flame.ps1` on Windows — which downloads the right executable below, verifies its checksum, replaces itself and re-invokes), one `flame` executable per platform, and the `flame-core`, `flame-web` and `flame-client` libraries each executable externalizes, resolving further dependencies from the Soundness and proscala releases and Maven Central on first run.

flame 0.1.3

Install (any POSIX shell):

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.1.3/flame ffe0594a951ce9169bf3760880e9e47e96d200a496cea6ed43c442e244e52e48
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF
```The `flame` polyglot bootstrap (a small any-shell script — rename to `flame.bat` or `flame.ps1` on Windows — which downloads the right executable below, verifies its checksum, replaces itself and re-invokes), one `flame` executable per platform, and the `flame-core`, `flame-web` and `flame-client` libraries each executable externalizes, resolving further dependencies from the Soundness and proscala releases and Maven Central on first run.

flame 0.1.2

Install (any POSIX shell):

openssl base64 -d <<EOF | sh -s -- https://github.com/propensive/flame/releases/download/0.1.2/flame 9b0a1773c36f236e03743b173e7b09bf7a857e3c32a5b7425aba27d2c59c5d10
Zj1gbWt0ZW1wYDtjdXJsIC1zTG8gJGYgJDF8fHdnZXQgLXFPICRmICQxO2Nhc2UgYG9wZW5zc2wg
ZGdzdCAtc2hhMjU2ICRmYCBpbiAqJDIpY2htb2QgK3ggJGY7ZXhlYyAkZjtlc2Fj
EOF
```The `flame` polyglot bootstrap (a small any-shell script — rename to `flame.bat` or `flame.ps1` on Windows — which downloads the right executable below, verifies its checksum, replaces itself and re-invokes), one `flame` executable per platform, and the `flame-core`, `flame-web` and `flame-client` libraries each executable externalizes, resolving further dependencies from the Soundness and proscala releases and Maven Central on first run.

flame 0.1.1

The flame polyglot bootstrap (a small any-shell script — rename to flame.bat or flame.ps1 on Windows — which downloads the right executable below, verifies its checksum, replaces itself and re-invokes), one flame executable per platform, and the flame-core, flame-web and flame-client libraries each executable externalizes, resolving further dependencies from the Soundness and proscala releases and Maven Central on first run.