Release notes for Norscode

These are the release notes for Norscode, taken straight from the project's own changelog. Here you'll see what's new, what's been fixed, and — just as important — what was known to be limited in each version. We keep them honest: a release is a snapshot, and it also says what wasn't finished at the time.

In progress (not yet released)

The work under way is largely about release preparation and tools for verifying self-hosting locally:

• The new command nc local-green runs a local release preflight, the active surface, phase 0, the self-hosting tracks L1–L6 and the full test gate — without publishing anything.
• Stricter local gates with nc release-preflight --strict and nc local-green --strict, and local-green --list, which shows every step and every command without running them.
• Tighter git tracking for release tooling, tests, documentation and the changelog itself.
• INSTALL.md updated to use nc for installation, release packaging, release installation and app packaging, with app-release documentation for Linux, macOS and Windows.
• The release text has been tightened to describe verified self-hosting tracks, instead of broad production claims.

Version 1.0.1 — 6 June 2026

A pure bugfix release, focused on the module system (bruk import):

• Fixed: bruk std.math and other bruk <modul> could cause an infinite memory loop (OOM) at runtime. The cause was that the bundler passed a dictionary object to string replacement, which was serialised to "[verdi]"; the JSON parser could then keep adding nil to a list until memory ran out. The fix does the string replacement on raw JSON before functions are renamed.
• Fixed: the import search no longer tries to runtime-compile selfhost.* modules that are already precompiled into the binary.
• Fixed: the JSON parser has gained a defensive guard that skips past unknown tokens and prevents an infinite loop on malformed input.
• Verified: bruk std.math, bruk std.path and bruk std.math som alias work.

Version 1.0.0 — 6 June 2026

The first release with a verified self-hosting track: the compiler, the bytecode interpreter and the VM are written in Norscode for the core of the workflow, with the runtime boundary held explicit.

The self-hosting track

All the steps go through Norscode's own track, without the historical C backend as the owner of the workflow: lexer (tokenisation) → parser (syntax analysis) → semantic analysis (type checking and IR) → IR to bytecode → VM execution (stack-based).

Features in 1.0.0

• Core language: functions with type signatures, static typing (heltall, tekst, bool, lists and dictionaries), control flow (hvis, loops, returner), error handling (kast, prøv, fang), operators and expressions, imports and modules at the base level, and native ELF compilation.
• Bytecode VM: JSON-based NCB format, stack-based execution, deterministic output and a cache for precompiled modules.
• Standard library: json, std.path and std.env. Further module-system work and completion of the web framework were deliberately deferred to later phases.

Performance improvements

• 30–40 % faster bootstrap via precompiled modules
• 9 % faster lexer via optimisation of bounds checks
• 10–15× faster bundler via module precompilation
• 18 % smaller bytecode
• No known memory leaks in the bootstrap track

Test result at release

The core-language tests were at 27 of 35 passing (77 %) — the rest required the full module system that was planned for the next phase. The compiler, VM and bootstrap tracks were verified in the self-hosting track, and native compilation in the release track.

Known limitations in 1.0.0

We wrote them down at the time, and they're worth keeping for the record:

• Module aliases (bruk std.path som path) were missing — fixed in 1.0.1.
• The old C host ran out of memory on the largest file; Norscode's own self-hosting track was the fallback, and it was proven stable.
• Async/await, WebAssembly support and a package manager were planned for later phases.

How to read the notes

Each release lists what's new, what's been fixed, and what's known to be limited. The last is deliberate: we'd rather you know what isn't finished than discover it yourself. You get the runtime from downloads, and the full changelog comes with the source code.

Back to the overview