How to get in touch

If you are a member of the CodeHub Bristol meet-up Slack workspace, please drop in on the #nutmeg channel for a chat. We want to widen participation and there will be a lot to do, so there is a very good chance you can find something that meets your interests and learning goals.

Building and testing

Pre-requisites

• .NET Core 3.1+
• Python 3.7+, earlier versions are likely to work
• SQLite 3.19+, earlier versions are likely to work

Locally

Currently, the builds yield only Python and .NET Core programmes. Builds for self-contained binaries are TBD but are expected.

To run tests on compile-time tools:

• All compile tools are written in Python, with tests written in pytest
• Inside the PyCharm IDE, use Preferences > Tools > Python Integrated Tools and set the unit test runner to pytest.

To run tests on the NutmegRunner:

• We are using xunit as the unit test framework.
• Currently we run the unit tests inside the Visual Studio IDE by running Run > Run Unit Tests.

Pipeline

TBD

Locations

Work in progress for language principles and design is in the Pinboard. This material will be fleshed out in this wiki as the language is implemented.

The Nutmeg run-time source code is written in C#, located in NutmegRunner.

Tests are structured as follows ...

The rest of the toolchain is written in Python, located in the repo root.

Tests are structured as follows ...

Development workflow

Based on the notes in the Pinboard, stories are prepared as issues. They are tracked in the Kanban. Work on a story can start when it meets the Definition of Ready.

To implement a story, create a feature branch off integration for each story. Once the work meets the Definition of Done, rebase the feature branch from integration and create a pull request to merge it.

Branch naming convention for stories: v{version}/{issueNumber}_{descriptiveTitle}, where the version number is the version we are working towards.

Mitigation for slow turnaround of pull-request reviews

At this early stage of development of a compiler, features tend to be heavily interlinked, each building on the progress made in the previous pull-request. Since we're working at low-intensity, review times can be very extended. To prevent long review times impacting on progress, I have the following mitigations:

• Very simple changes are made directly to the integration branch and the review-process is skipped. For example, @Phil pointed out the source of the deprecated use of regex flags in tokenizer.py, which was a single-line update. So even if things go wrong, fixing it is no biggie.
• Dependent user-stories are branched from the feature-branch in review rather than the integration branch (!).
• When it is time to check-in a feature-on-feature branch, the pull-request for the parent feature-branch is timed out. That avoids a wobbly chain building up any further.
• When a feature-branch is timed out we have the following ritual: pull integration; checkout feature branch and pull; rebase feature-branch against the integration branch; rerun tests; force push with lease; complete pull-request; checkout integration branch & pull; checkout feature-on-feature branch; rebase on integration branch; force push with lease (if already pushed).
• If any rebase fails or has conflicts, a simple merge is used instead.

Once we have the bread-and-butter features nailed down, the user-stories will become less inter-dependent and there won't be any need for mitigation.