cryptocode

joined 1 year ago
MODERATOR OF
 

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.)
 

The code in this video can be found here: https://codeberg.org/dude_the_builder/zig_master

 

From the announcement:

Regular expressions follow the PCRE syntax. This update has a full regex parser and finite-state-automaton generator that builds parsing trees at comptime. All parsing trees are stateless and have @sizeOf(T) == 0.

To use Regex, just look for the fluent.match function and provide your expression string and source string: fluent.match("[abc]\d+", str)

It’s an on going process, but it’s at a point where people can start using them and be on the lookout for more updates!


Fluent can be found on Github: https://github.com/andrewCodeDev/Fluent

 

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

$ zig fetch --save=clarp https://github.com/travisstaloch/clarp/archive/<commit-hash>.tar.gz

This will add the following

// build.zig.zon
.dependencies = .{
    .clarp = .{
        .url = "https://github.com/travisstaloch/clarp/archive/<commit-hash>.tar.gz",
        .hash = ...,
    },
},

Modify build.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.

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.

$ 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

$ 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

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

cmd1: 
  foo: "opt1 value"

Short names

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

cmd1: 
  foo: "opt1 value"

$ zig-out/bin/testexe c2 b

cmd2: 
  0: b

Diagnostics

$ 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
view more: ‹ prev next ›