Project Norebo is a build tool for building/bootstrapping Wirth's Project Oberon 2013.
If you're not familiar with Oberon-the-system or Oberon-the-language, know that Project Oberon 2013 itself is a small, single user operating system written in the Oberon programming language, that the latter is a major inspiration for Go (cf Griessemer and Pike), and that the UI for the latter—the Oberon system—even inspired the acme shell Rob Pike created for Plan 9 at Bell Labs, which Russ Cox demonstrates here in the video of A Tour of the Acme Editor.
Back to Norebo and then the showcase for this post: Terobo.
Project Norebo, as Peter de Wachter explains in the README, is a hack for cross-compiling Project Oberon. The standard Oberon compiler is itself written in the Oberon language, which means you'll need some other Oberon compiler to build it. What's more, though, is that existing binaries come in the form of object files that expect to run within the Oberon system—or at least inside something implementing the Oberon system interfaces.
So not only are we faced with the classic bootstrapping problem for self-hosted compilers, but the trough of despair descends one layer deeper than that:
We want to compile Project Oberon, so
We want to run the Oberon compiler, so
We want to compile the Oberon compiler, so
We want to run the Project Oberon system.
This is where Project Norebo comes into play. It's meant both to bootstrap the compiler and to build the Oberon system from source, emitting a disk image that can run on the Oberon RISC emulator. Norebo is implemented partly in Python for the high-level build steps, partly in C for the native runtime that allows UNIX-like systems to emulate both the Oberon hardware and the core Oberon system APIs, and partly in the Oberon language as a bridge to the C runtime from within a locally hacked version of the Oberon system meant to run embedded on the aforementioned C runtime.
This is fine if you have a C compiler, the right Python installed, and if your system is otherwise sufficiently close to match the (possibly unknown) latent assumptions that need to be satisfied in order for the build to go off without a hitch.
Or, as Joe Armstrong relates in a similar anecdote:
So I Googled a bit and I found a project that said you can make nice slide shows in HTML and they can produce decent PDF. And so I downloaded this program, and I followed the instructions, and it said I didn't have grunt installed! […] So I Googled a bit, and I found out what grunt was. Grunt's—I still don't really know what it is, but...
[Then] I downloaded this thing, and I installed grunt, and it said grunt was installed, and then I ran the script that was gonna make my slides... and it said "Unable to find local grunt"[…]
Since Oberon is a small system, we should be able to achieve our build goals from virtually anywhere, Python or no Python. As it turns out, we can do better. Here's a preview:
Terobo and TeroBuild are together a re-implementation of Project Norebo's
C-and-Python infrastructure, respectively, but written in the triple script
dialect instead. As a triple script, this gives us deterministic builds
through Terobo, which is pretty much guaranteed to run on any consumer-grade
computer, regardless of what process a person is (or isn't) willing to go
through to make sure the right toolchain is set up beforehand. This is
because triple scripts require no special toolchain be set up—not even
something that seems as pedestrian (or "standard") as /usr/bin/python or a C
compiler. A triple script is its own toolchain. In other words, the repo
is the IDE.
Neither Terobo, Norebo, or anything involving Oberon is the real focus here. This is personal milestone and a demonstration of the power behind the philosophy of triple scripts, more than anything else.
Stay tuned for more developments related to triplescripts.org. The latter has been my main side project for the better part of a year, and even though I missed the anticipated launch in the early part of this year—due to long illness and then, subsequent to that, a car accident—I'm going to continue plugging away. I truly expect triplescripts.org to become kind of a Big Deal and, as I've characterized it in the past, to end up winning if for no other reason than through sheer tenacity and the convenience it will afford both software maintainers and potential contributors alike.
Further viewing/reading: