Big one this week: NLP Engine version 3 is out, and the headline feature is the new -COMPILE flag.
Compile your analyzer and KB straight from the command line
Up until now, getting from NLP++ source to a compiled analyzer meant going through the full VisualText analysis pipeline. Now you can run the engine with -COMPILE and it will skip the analysis step entirely and just generate the C++ code for your analyzer and knowledge base. That’s a much faster loop if all you want is the compiled artifact — useful for build pipelines, packaging, or just checking that your grammar compiles cleanly without running it against a corpus.
I also updated the --help text so -COMPILE (and the existing -SILENT default behavior) are documented properly — small thing, but I want the CLI help to actually match what the engine does.
On the VS Code side, the extension now has a compile analyzer and KB action that wraps this new flag with cross-platform C++ build support, so you can trigger a compile from inside the editor instead of dropping to a terminal. There was some cleanup here too — reverted a stray JS artifact edit that snuck in, keeping the change scoped to the TypeScript compile logic. The extension’s README and release metadata now talk about Version 3 and the compiled analyzer/KB workflow, so new users landing on the marketplace page get the real story.
CI and release plumbing
A good chunk of the week went into hardening the pipes that get build artifacts from CI into actual releases:
- The
move-assetsworkflow was pulling artifacts from workflow runs that had already expired or didn’t have everything it needed. I tightened this up: it now only selects a run when all the required artifacts actually exist, and the required-artifact lists are centralized instead of scattered across the workflow, which makes it easier to keep in sync. - Bumped artifact retention to 30 days on the producer workflows so we’re not racing expiration windows before assets get moved to a release.
- Refactored the run-id resolver to be more robust and documented how workflow path matching works, so the next person touching this doesn’t have to reverse-engineer it.
- Fixed the Windows build to use
windows-latestand updated the vcpkg submodule to fix a macOS ICU build failure — that one had been silently breaking the mac pipeline. - Also fixed the trigger and naming on the “Move Assets to Release” workflow itself, so it’s clearer what it does and when it runs.
None of this is glamorous, but it’s the kind of thing that determines whether “cut a release” is a five-minute button press or a stressful afternoon of debugging Actions logs. It’s in much better shape now.
Small housekeeping on the extension side too: fixed a couple of README typos and bumped fast-uri for a dependency fix via Dependabot.
What’s next
With -COMPILE in and the release pipeline more trustworthy, next up is putting the compiled-analyzer workflow through its paces on some real grammars and seeing what rough edges show up. If you try v3, let me know how the compile flow feels — especially from the VS Code side.