M9 0.24.0

The M9 compiler m9c, the runtime libm9rt.a, the standard library as M9 source, the module reference, the compiler's man page and the VS Code extension files. gcc is the only toolchain any of them needs.

One package per distribution, x86-64, each built ON that distribution (the Ubuntu 26.04 one on a real 26.04 machine rather than a VM) from the one source tarball attached here (m9-0.24.0.tar.gz, sha256 ddde3d252e28f76e5c1f4ceacdf659e4acd0ed5f11787dfba0abe4f01263692d), then installed there and made to compile and run an M9 program with an empty environment before it was allowed to leave the build machine.

That tarball is the same set of files as this repository -- the compiler, runtime, standard library, gates, man page and module reference -- and the release tooling refuses to cut one that is not, checked both against the list and against an independent deny-list of paths that must never be published.

distribution	package	install
Ubuntu 24.04 LTS	m9_0.24.0-1_amd64.ubuntu24.04.deb	sudo apt install ./m9_0.24.0-1_amd64.ubuntu24.04.deb
Ubuntu 26.04 LTS	m9_0.24.0-1_amd64.ubuntu26.04.deb	sudo apt install ./m9_0.24.0-1_amd64.ubuntu26.04.deb
Debian 13	m9_0.24.0-1_amd64.debian13.deb	sudo apt install ./m9_0.24.0-1_amd64.debian13.deb
Fedora 43	m9-0.24.0-1.fc43.x86_64.rpm	sudo dnf install ./m9-0.24.0-1.fc43.x86_64.rpm
Rocky 9 (RHEL 9, Alma 9)	m9-0.24.0-1.el9.x86_64.rpm	sudo dnf install ./m9-0.24.0-1.el9.x86_64.rpm
Arch	m9-0.24.0-1-x86_64.pkg.tar.zst	sudo pacman -U ./m9-0.24.0-1-x86_64.pkg.tar.zst

Windows — experimental

m9-0.24.0-windows-x86_64.zip (sha256 4736d0bd4221219a8baac8f75dfb463ed77e18124df08a15a3edcb065463db72) is one folder with everything in it: its own gcc (a subset of the MSYS2 UCRT64 toolchain, measured by tracing real builds), the compiler's bootstrap C, the standard library and tools as M9 source, the tutorial as pages, and an install.bat that compiles the compiler on your own machine — the same "gcc is the only toolchain" claim as above, with the gcc in the box. Unpack it anywhere and run install.bat from a terminal; it says what it will do and asks before it touches your PATH or your VS Code extensions.

Experimental means experimental. It is the same compiler as the Linux one — the runtime carries _WIN32 paths beside the POSIX ones and the generated C never names a platform — but it is verified on one Windows machine -- its receipt's smoke line names the Windows 11 build the sealed zip was installed, compiled with and its tutorial run on -- where Linux is tested across six distributions. One of the tutorial's twenty-nine examples does not work there yet: chapter 17 (it runs sort and uniq). The rest, netCDF, zarr over TLS and the threaded chapters included, runs.

macOS — experimental

brew tap atverm/m9 && brew install m9

installs this release on a Mac from the same source tarball, built there with Homebrew's gcc, and with OpenSSL, blosc and netCDF from Homebrew, so a program that opens an https URL, reads a zarr chunk or writes a netCDF file links on the first try. m9-0.24.0.rb (sha256 e4c689bd334ffa91762604d06b1c2328fd5c9c98a3117767e5ff9651e62e1e00) is the formula the tap carries; its receipt records the Mac it was installed and smoke-tested on (26.7.1 arm64, gcc-16 (Homebrew GCC 16.2.0) 16.2.0).

Experimental means experimental. It is the same compiler — every macOS difference in the runtime and the driver is under __APPLE__ or macos and the generated C never names a platform — verified on one Apple-silicon Mac, where Linux is tested across six distributions; Intel Macs are untested. The whole tutorial runs there, zarr over TLS and the threaded chapters included.

What changed since the previous release

• A name for a builtin scalar is a scalar in the view analysis. An element copied out of a SLICE OF Kind.FlexFloat (TYPE FlexFloat = F32) into a VAR record read as a borrow handed back, and the FLEXPART port's Getfields.Init and TimeManager.Run were asked for a KEPT that keeps nothing -- the two marks 0.23.0's notes said the port owed. It owes none: both of its trees build unchanged.
• 0.23.0's statement release no longer runs in a module body. There the marked arena is the module frame, which every module variable without IN uses as its pool, so a procedure called with a concatenation that appended to such a variable grew its buffer above the mark and the release freed it: a module-level out : PTR DynStr.DString filled from a Line procedure came back as NUL bytes (found by OneFlux). Procedures are unchanged.
• Nor is a statement released when it hands a VAR parameter anything that carries a pointer -- a STR, a slice, a record with one. A callee that assigned a new string to its VAR STR, line := line + datum, had it re-homed into the caller's arena above the statement's mark, and Add (a, 'cov(w_' + Name (j) + ')') left a reading freed bytes: EddyPro's header lines carried stale numbers (found by OneFlux).
• A call passes the hidden pool behind a VAR record parameter by the callee's own type. The generator read the parameter type's bare name in the caller's import order, so with two imported modules each declaring a record V, only one with pointers, the call could go without its pool and gcc refused it (OneFlux).
• A qualified variant with binders, | Frame.Data.F64s (v, m) :, is a pattern: its names were unknown, while the bare | F64s (v, m) compiled (OneFlux).
• An index out of range into a slice of records larger than 64 KB no longer writes past the runtime's out-of-bounds cell; such an element gets a cell of its own size (OneFlux's 100 KB record, which gcc's -Wstringop-overflow pointed at).

Each .receipt records the distribution the package was built on, its sha256, the tarball's sha256, the gcc that built it, and the smoke line. Nothing here was modified after it came back from the build machine except the 3 debs' file names, which carry their distribution because they would otherwise be the same name (dpkg reads the control file, not the name).

Chapter 0 of the tutorial (M9Tutorial, tutorial.modula9.net) covers installation from these and from source.