Contribute to Tatin¶

Tatin is published under the MIT license, and you are welcome to contribute to it.

Tatin is not owned by anybody; it is a community project.

Requirements¶

To work on Tatin you need

Git and a GitHub account
Dyalog 18.2 Unicode or better (Classic is not supported)
.NET installed and Link activated
Cider

Operating system Linux, macOS, or Windows. AIX is not supported. The Raspberry Pi is not officially supported but might work anyway.

You can develop on any operating system, but building a new version is currently supported only on Windows. This restriction is likely to be lifted in a later version.

Managed by Cider¶

Tatin is managed by the Cider project management tool. If you are new to Cider, spend some time playing with it before using it for serious work. An hour or two should be enough.

Working without Cider

While it is possible to make changes or add code to Tatin without Cider, using Cider makes it significantly easier. And the build process requires Cider.

That said, you are not required to build a new version before submitting a pull request, so you might get away without Cider, but using Cider is certainly recommended.

Get started¶

On GitHub, make your own fork of Tatin and clone it to your local machine, say at /path/2/Tatin.
Launch Dyalog and open the project
```
]CIDER.OpenProject /path/2/Tatin
```

Now you have a working version of Tatin on your machine and you can start contributing.

No need to save a workspace

Every function, operator, class, interface or namespace script changed in #.Tatin is automatically saved to disk by Link.

Code¶

To modify the source code:

Open an issue on the GitHub repository and declare what you intend to do. GitHub will assign an ID number to your issue.
On your local machine, create a branch of main and name it after your issue. For example, if your issue is Foo is failing in bar and has ID 123, name your branch 123-fix-foo-bar.
Before finishing, confirm your branch 123-fix-foo-bar passes the Tatin tests.
On GitHub, sync your fork with the source repo. On your local machine, pull the main branch from your GitHub fork; then merge main into 123-fix-foo-bar.
Push 123-fix-foo-bar to your fork, and submit a pull request.

Documentation¶

If you find parts of this guide confusing, outdated, unclear or incomplete, change it. That might well be your first valuable contribution.

A minor edit to the documentation usually does not require its own issue and branch; it can be made in the main branch. This table might be useful:

Change type	Issue?	Branch?
Typo, grammar, broken link	No	Often not necessary
Small factual correction	Usually no	Usually yes
New documentation section	Often yes	Yes
Behavioural or design clarification	Yes	Yes

Build documentation¶

The documentation is generated by Zensical from Markdown sources in docs/source/, and deployed to GitHub Pages by the workflow in .github/workflows/ci.yml on every push to main.

To build the same site locally, use a Python virtual environment so the toolchain matches CI:

python3 -m venv .venv
source .venv/bin/activate
pip install -r docs/requirements.txt

Build:

cd docs
zensical build --clean

The output appears under docs/site/ (gitignored). For live-reload while editing, run zensical serve instead.

Submit your changes¶

When you have improved the documentation, fixed a bug, or added a feature, create a pull request (PR). The project team will check your contribution.