An Entity Component System API for Zig

From the README:

A delightful, statically typed programming language for writing reliable software. veb features algebraic data types, pattern matching, generics, classes (without inheritance), traits, flow-sensitive typing with type narrowing, trait-driven operator overloading and modules. Ergonomic features such as pipe and concat operators are also supported. Currently, the language runtime executes on a custom register-based virtual machine written in Zig.

Z80 chip emulator with classical games such as Pac-Man bundled

Convenience functions for easy integration with AFL++ for both Zig and C/C++ programmers!

A package manager for installing linux programs that are self contained

A package manager for installing linux programs that are self contained

From the README:

y3 is a wrapper for yabai that attempts to emulate i3 behavior and adds additional logic to improve the experience. It may not match 1:1, please let me know if something is missing or incorrect.

From the README:

Hexdump is designed to replace the standard Hexdump command. If you feel uncomfortable replacing it, simply rename the binary to something else.

Features

• ASCII sidebar
• Skipping bytes
• Specified length
• Multiple formats
• Colored output
• Output to file

From the README:

• Simple to use: Minimal and customizable keymaps with vim binding support.
• Image Previews: Preview images with Kitty terminal.
• File Previews: Preview contents of files directly in the terminal.
• Configurable Options: Customize settings via an external configuration file.

From the README:

Zig currently does not have a built-in, general purpose Set data structure at this point in time. Until it does, try this!

Rationale: It may be common knowledge that a dictionary or map or hashset can be used as a set where the value is basically void. While this is true, there's a lot to think about in terms of supporting all the common set operations in a performant and correct way and there's no good reason why a common module for this can't exist. After studying the Zig stdlib, I'm hoping this implementation can fill that gap and provide some value.

From the README:

This library is a friendly refactor of TigerBeetle's flags module that adds support for:

• subcommand specific help messages; and
• short options (-k=v).

From the README:

arbor

For the future of plugin development

Goals

• Dead-simple plugin development. Write <= 100 lines of code and have a runnable blank-slate plugin.

• Ideally only require Zig as a toolchain dependency, not as a programming language. You should be able to write plugins in C/C++/whatever and easily link that code to Arbor via a C API and the Zig build system.

  • Could also have a get_zig.sh that will download latest stable Zig if you don't already have it

• Easy cross-compilation. Compile to Mac/Linux/Windows from Mac/Linux/Windows, batteries included.

• Cross-platform graphics. A simple software renderer (like Olivec), but also native graphics programming, potentially using something like sokol, or making a thin wrapper around Direct2D/CoreGraphics for cross-platform graphics abstraction, giving the programmer a simple choice with little-to-no platform-specific considerations.

• Simple, declarative UI design. Possibly with the option of using a custom CSS-like syntax (or Ziggy) to declare, arrange, and style UI widgets at runtime or compile-time, all compiling to native code--not running in some god-forsaken web browser embedded in a plugin UI 🤮

Have:

• A nice abstraction layer over plugin APIs which should lend itself nicely to extending support to other APIs

• Easy comptime parameter generation

• Basic CLAP audio plugin supporting different types of parameters, sample-accurate automation

• A janky VST2 implementation that works in Reaper and mostly works in other DAWs

• Simple, portable software rendering using Olivec and a custom text rendering function with a bitmap font

From the README:

Ly is a lightweight TUI (ncurses-like) display manager for Linux and BSD.

[...]

Ly should work with any X desktop environment, and provides basic wayland support (sway works very well, for example).

From the README:

A Zig wrapper around md4c for parsing Markdown.

Exposes a single function that puts a parser type together from comptime-known Zig functions. The generalisation to using vtables is left as an exercise to the user.

From the README:

This library provides a simple and efficient way to generate and manipulate UUIDs (Universally Unique Identifiers) in Zig.

Features

• Generate UUIDs of all versions (1, 3, 4, 5)
• Parse UUIDs from strings
• Convert UUIDs to strings, 128-bit integers, and byte-arrays
• Access to parts of UUID (time_low, time_mid, node, etc.)

From the README:

Tuile is a Text User Interface library written in Zig.

The only currently supported backend is ncurses [...]

From the README:

z2d is a 2D graphics library primarily designed around rasterizing vector primitives like lines and cubic Beziers. In other words, it's designed around supporting operations that you would see in SVG or other vector languages like PostScript or PDF.

Our drawing model is (loosely) inspired by Cairo: most operations take place through the Context, which connect Patterns (pixel/color sources) and Surfaces (drawing targets/buffers). Paths contain the vector data for filling and stroking operations. Additionally, surfaces can be interfaced with directly.

From the README:

Derive command line parsers from union and struct types. Provides nested, context aware usage text similar to the zig compiler. Works with existing data structures you may not control.

Features

• field types

  • int, bool, enum, float, optional, array, slice
  • nested unions and structs

• help / usage

  • automatically printed on parsing errors
  • very customizable
  • nested and context aware, showing only one level of help info at once
  • written to parse_options.err_writer (default std.io.null_writer)
  • accessible from any print() method: std.debug.print("{help}", .{parse_result});

• diagnostics which clearly point to parsing errors

• easily dump parse results

  • from any print() method: std.debug.print("{}", .{parse_result});

• derive short names by setting clarp_options.derive_short_names and override them with FieldOption.short

• apply clarp_options to types you don't control with parseWithOptions()

• rename long names with FieldOption.long

• long and short options can be parsed with any of these forms:

  | Long | Short | | ------------- | ---------- | | --foo value | -f value | | --foo=value | -f=value | | --foovalue | -fvalue |

Overview

Union types create alternative commands. Commands match field names exactly.

Struct types create sequences of options. Options match field names with leading dashes such as --text_color for field text_color. Named options can be parsed out of order. Unnamed, positional parsing may be enabled by setting clarp_options.fields.<field_name>.positional.

Tuple types create unnamed sequences and are parsed strictly by position.

Bool fields create 'flags' and may be specified as --flag or true/false when unnamed. They are always optional and default to false.

Slice fields require an allocator and consume input until an argument is found which starts with '-' or end of arguments. clarp_options.end_marker may also be used to mark the end of field's arguments. This may be necessary with unnamed, positional fields. An Allocator can be passed as ParseOptions.allocator.

Zig version

This package was developed against zig version 0.12.0-dev.3594+355cceebc

Usage

You can find many examples in the tests.

Add clarp dependency

Fetch

console $ zig fetch --save=clarp https://github.com/travisstaloch/clarp/archive/<commit-hash>.tar.gz This will add the following zig // build.zig.zon .dependencies = .{ .clarp = .{ .url = "https://github.com/travisstaloch/clarp/archive/<commit-hash>.tar.gz", .hash = ..., }, },

Modify build.zig

zig // build.zig pub fn build(b: *std.Build) void { const clarp = b.dependency("clarp", .{}).module("clarp"); const exe = b.addExecutable(.{...}); exe.root_module.addImport("clarp", clarp); }

Full Example

This program creates a parser and dumps the result to stderr. It is available here and can be run with $ zig build test-demo -- args. ```zig const std = @import("std"); const clarp = @import("clarp");

pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator();

const ArgParser = clarp.Parser(union(enum) { cmd1: struct { foo: []const u8, pub const clarp_options = clarp.Options(@This()){ .fields = .{ .foo = .{ .desc = "Foo desc." }, }, }; }, cmd2: struct { enum { a, b } = .a }, pub const clarp_options = clarp.Options(@This()){ .fields = .{ .cmd1 = .{ .desc = "Cmd1 desc.", .short = "c1" }, .cmd2 = .{ .desc = "Cmd2 desc.", .short = "c2" }, }, }; }, .{});

const args = try std.process.argsAlloc(allocator); const parsed = ArgParser.parse(args, .{ .err_writer = std.io.getStdErr().writer().any(), }) catch |e| switch (e) { error.HelpShown => return, else => return e, }; std.debug.print("{}\n", .{parsed}); } ```

clarp_options

When a struct or union contains a pub const clarp_options declaration, it changes parsing behavior. Nested structs and unions may declare their own clarp_options.

ParseOptions

Runtime parsing options. The second argument to clarp.Parser(T).parse().

ParserOptions

Comptime global parsing options. The second argument to clarp.Parser().

help flags

By default, if an arg is help, --help or -h context aware usage is displayed. You may change the help flags by passing an enum type for ParserOptions.help_type.

```console $ zig-out/bin/testexe help Usage: testexe [command]

Commands:

cmd1, c1 Cmd1 description. cmd2, c2 Cmd2 description.

General Options:

help, --help, -h Print command specific usage. ```

Notice how this message is derived from the union(enum) passed to clarp.Parser() above and that its clarp_options declaration affects the output, adding the c1 and c2 shorts and descriptions.

Command specific help

```console $ zig-out/bin/testexe cmd1 help Usage: testexe cmd1 [options]

Cmd1 description.

Options:

--foo: string Foo description.

General Options:

help, --help, -h Print command specific usage. ```

Command line examples

Here are some results from the ArgParser we defined above in Full Example.

Long names

```console $ zig-out/bin/testexe cmd1 --foo 'opt1 value'

cmd1: foo: "opt1 value" ```

Short names

```console $ zig-out/bin/testexe c1 --foo 'opt1 value'

cmd1: foo: "opt1 value"

$ zig-out/bin/testexe c2 b

cmd2: 0: b ```

Diagnostics

```console $ zig-out/bin/testexe foo Usage: testexe [command]

Commands:

cmd1, c1 Cmd1 description. cmd2, c2 Cmd2 description.

General Options:

help, --help, -h Print command specific usage.

error at argument 1: foo ^~~ error: UnknownCommand #... stack trace omitted ```

From the README:

Tiny and efficient rect packer. The algorithm is very similar to and is heavily inspired by rectpack2D and the blog post it's based on.

From the README:

ziglo is a Zig interface to liblo, an implementation of the Open Sound Control protocol. ziglo provides Zig types for liblo primitives and convenience functions for adding and querying message contents leveraging Zig’s comptime.