| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The code for reporting errors became quite verbose after writegate.
Reporting to stderr is very common, so this wrapper provides a default,
buffered way to report to a file.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #149
|
| | |
|
| |
|
| |
The readme was also reflowed to 100 cols. I probably should have put that in a separate commit but oh well. The comments were not subjected to reflowing (yet).
|
| | |
|
| |
|
|
|
|
| |
In order to get the more precise `ParseIntError.InvalidCharacter` error
instead of `ParseIntError.Overflow` when a negative number is passed to
a usize, uX typed argument, I use the `fmt.parseUnsigned` function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
For `Values.one` positionals will be of type `?T`
For `Values.many` positonals will be of type `[]const T`
|
| |
|
|
| |
This is my new preferred style of programming Zig :)
|
| |
|
|
|
|
|
|
| |
This option makes `clap.parse` and `clap.parseEx` stop parsing after
encountering a certain positional index. Setting
`terminating_positional` to 0 will make them stop parsing after the 0th
positional has been added to `positionals` (aka after parsing 1
positional)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The installation section no longer assumes that all developers use
the master branch of Zig. Instead if provides different steps
depending on which Zig version developers are using.
Related #61
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
A complete solution would be to count grapheme clusters, but that would
require adding a dependency on something like zg.
Counting codepoints will ensure that typical non-ASCII text is
supported, but you can still throw it off with more complex Unicode
constructions, which might not be so useful in help text.
Fixes #75
|
| | |
|
| | |
|
| |
|
|
|
|
| |
See https://github.com/ziglang/zig/pull/19847
Compatibility with Zig 0.13.0 remains unchanged
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
related #122
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Gyro is dead. Rest in peace.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a `zig build docs` step that builds the documentation website
and writes it to zig-out/docs.
It further includes a GitHub Workflow that publishes this website
to GitHub Pages. The GitHub Workflow is divided into two jobs:
- build: builds the documentation and uploads it
- publish: downloads the documentation and publishes it
These are separate jobs to minimize permissions available
to the build job.
This workflow runs on two events:
- after every push to master
- `workflow_dispatch`: this allows manually running the workflow
from its *Actions* page if something went wrong
---
**Important pre-merge steps:**
If this PR is accepted, the following steps should be taken
before merging the PR:
1. Go to **Settings** for the repository
2. Select **Pages** on the left under *Code and automation*
3. Under *Build and deployment* set **Source** to **GitHub Actions**
4. Merge the PR.
If the steps are missed, the PR will merge just fine,
but the docs job will fail immediately on merge.
This can be remedied by following steps 1-3 above,
and either adding a new commit on master,
or manually firing the workflow from the Actions > API Reference page.
|