n8r/zig-dynamic-playground
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

janet WIP

Browse Source
This commit is contained in:
Nathan Anderson
2026-05-26 20:26:15 -06:00
commit 8ecd316f0c
14 changed files with 60358 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.envrc
+1
View File
@@ -0,0 +1 @@
use flake
.gitignore
+5
View File
@@ -0,0 +1,5 @@
.direnv/**
.envrc
**/zig-out/**
**/.zig-cache/**
AGENTS.md
+50
View File
@@ -0,0 +1,50 @@
# AGENTS.md
## Project Context
This is a comparison playground for C-embeddable scripting languages (Lua, Janet, Wren, Squirrel, Tcl) hosted in Zig. The goal is to evaluate the feel and ergonomics of each language's embedding API by building the same small project in each: a configuration-driven task scheduler where the host exposes fake hardware primitives and the script defines timed behavior.
The host exposes three functions to each scripting VM:
- `log(message)` — print a string
- `set_pin(pin, value)` — simulate setting a GPIO pin
- `read_sensor(pin)` — returns a fake random float
Scripts define named tasks with intervals. The host ticks the scheduler and calls into the script to dispatch due tasks.
Raw C APIs only — no wrapper libraries. This is intentional; API ergonomics are part of what's being evaluated.
## Developer Profile
Late-20s software developer, experienced in Go, Dart, Python, some Zig. Currently deepening Zig knowledge. New to embedded scripting language embedding. Motivated by genuine understanding, not task completion.
## Your Role
You are a mentor, not an implementor. The developer wants to do the actual coding. Your job is to make sure they understand what they're doing and why.
**Do not write production code and hand it over.** If you find yourself about to implement a complete solution, stop and back up to an earlier rung on the help ladder.
## Help Ladder
Every task should start at the top and only descend when the developer explicitly asks for more help, or is clearly stuck.
1. **Orient** — Explain what the task is asking for conceptually and why it matters. Point to the relevant documentation section.
2. **Explain** — Clarify the underlying concept in a different way, with an analogy or diagram if useful.
3. **Example** — Provide a minimal example in a *different* context than the task (so it can't be directly copy-pasted). Require the developer to re-express it for the actual task.
4. **Scaffold** — Provide a skeleton with meaningful gaps: function signatures, comments describing intent, `@panic("implement me")` stubs. Developer fills it in.
5. **Answer** — Provide the working solution, but require the developer to delete it, close the conversation, and rewrite it from memory before moving on.
Always tell the developer which rung you're on.
## Behavioral Rules
- Give one step at a time. Do not front-load the full solution broken into steps.
- Ask one question at a time when clarification is needed.
- Do not explain what you're about to do. Just do it.
- If the developer asks you to "just do it" or similar, acknowledge the request, do it, then remind them of rung 5 and ask them to rewrite it.
- Prefer questions that make the developer reason aloud before you explain anything.
- When the developer gets something wrong, ask them to explain their reasoning before correcting them. The error is often more instructive than the correction.
- Never be sycophantic. No "great question" or "exactly right."
## What Good Looks Like
The developer finishes this project understanding why each API is shaped the way it is, what the memory implications of each boundary crossing are, and which language felt most natural. They should be able to recreate any part of it without reference.
flake.lock
Generated
+160
View File
@@ -0,0 +1,160 @@
{
"nodes": {
"flake-compat": {
"flake": false,
"locked": {
"lastModified": 1696426674,
"narHash": "sha256-kvjfFW7WAETZlt09AgDn1MrtKzP7t90Vf7vypd3OL1U=",
"owner": "edolstra",
"repo": "flake-compat",
"rev": "0f9255e01c2351cc7d116c072cb317785dd33b33",
"type": "github"
},
"original": {
"owner": "edolstra",
"repo": "flake-compat",
"type": "github"
}
},
"flake-utils": {
"inputs": {
"systems": "systems"
},
"locked": {
"lastModified": 1731533236,
"narHash": "sha256-l0KFg5HjrsfsO/JpG+r7fRrqm12kzFHyUHqHCVpMMbI=",
"owner": "numtide",
"repo": "flake-utils",
"rev": "11707dc2f618dd54ca8739b309ec4fc024de578b",
"type": "github"
},
"original": {
"owner": "numtide",
"repo": "flake-utils",
"type": "github"
}
},
"nixpkgs": {
"locked": {
"lastModified": 1779560665,
"narHash": "sha256-tpyBcxPpcQb8ukyNF7DoCwfSY3VPsxHoYwj00Cayv5o=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "64c08a7ca051951c8eae34e3e3cb1e202fe36786",
"type": "github"
},
"original": {
"owner": "NixOS",
"ref": "nixos-unstable",
"repo": "nixpkgs",
"type": "github"
}
},
"root": {
"inputs": {
"flake-utils": "flake-utils",
"nixpkgs": "nixpkgs",
"zig-overlay": "zig-overlay",
"zls": "zls"
}
},
"systems": {
"locked": {
"lastModified": 1681028828,
"narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
"owner": "nix-systems",
"repo": "default",
"rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
"type": "github"
},
"original": {
"owner": "nix-systems",
"repo": "default",
"type": "github"
}
},
"systems_2": {
"flake": false,
"locked": {
"lastModified": 1681028828,
"narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
"owner": "nix-systems",
"repo": "default",
"rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
"type": "github"
},
"original": {
"owner": "nix-systems",
"repo": "default",
"type": "github"
}
},
"zig-flake": {
"inputs": {
"nixpkgs": [
"zls",
"nixpkgs"
]
},
"locked": {
"lastModified": 1776183664,
"narHash": "sha256-lmTMKC0Rc0L1GChNEAkn+hV/iaFMU4B2C9NkQqydumo=",
"owner": "silversquirl",
"repo": "zig-flake",
"rev": "2c9eec04c4a27ca54addd9e6c28a5a64906cba0a",
"type": "github"
},
"original": {
"owner": "silversquirl",
"repo": "zig-flake",
"type": "github"
}
},
"zig-overlay": {
"inputs": {
"flake-compat": "flake-compat",
"nixpkgs": [
"nixpkgs"
],
"systems": "systems_2"
},
"locked": {
"lastModified": 1779715393,
"narHash": "sha256-T7Tsv+waWpxu+1njV5wZickZ5wbRWgCICSKoXSx1CN0=",
"owner": "mitchellh",
"repo": "zig-overlay",
"rev": "9e22f8604704aeabf7241159de81f65e2dd2e401",
"type": "github"
},
"original": {
"owner": "mitchellh",
"repo": "zig-overlay",
"type": "github"
}
},
"zls": {
"inputs": {
"nixpkgs": [
"nixpkgs"
],
"zig-flake": "zig-flake"
},
"locked": {
"lastModified": 1776368637,
"narHash": "sha256-k0xWObsw9K12BKfK+UB5TieWDFEFfBQhN1X1NO35fWk=",
"owner": "zigtools",
"repo": "zls",
"rev": "494486203c3a48927f2383aa3d5ce5fca112186d",
"type": "github"
},
"original": {
"owner": "zigtools",
"ref": "0.16.0",
"repo": "zls",
"type": "github"
}
}
},
"root": "root",
"version": 7
}
flake.nix
+33
View File
@@ -0,0 +1,33 @@
{
description = "Zig flake with ZLS";
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
flake-utils.url = "github:numtide/flake-utils";
zig-overlay.url = "github:mitchellh/zig-overlay";
zig-overlay.inputs.nixpkgs.follows = "nixpkgs";
zls = {
url = "github:zigtools/zls/0.16.0";
inputs.nixpkgs.follows = "nixpkgs";
};
};
outputs = {
flake-utils,
nixpkgs,
zig-overlay,
zls,
...
}:
flake-utils.lib.eachDefaultSystem (system: let
pkgs = import nixpkgs {inherit system;};
zig = zig-overlay.packages.${system}."0.16.0";
in {
devShell = pkgs.mkShell {
buildInputs = with pkgs; [
zig
zls.packages.${system}.zls
# utils
lldb
];
};
});
}
implementation.md
+5
View File
@@ -0,0 +1,5 @@
# The project
Zig host exposes some low-level functions `log(message) void` `set_pin(pin, value) bool`, and `read_sensor(pin) value`.
Embedded language client that does some task registration
janet/build.zig
+159
View File
@@ -0,0 +1,159 @@
const std = @import("std");
// Although this function looks imperative, it does not perform the build
// directly and instead it mutates the build graph (`b`) that will be then
// executed by an external runner. The functions in `std.Build` implement a DSL
// for defining build steps and express dependencies between them, allowing the
// build runner to parallelize the build automatically (and the cache system to
// know when a step doesn't need to be re-run).
pub fn build(b: *std.Build) void {
// Standard target options allow the person running `zig build` to choose
// what target to build for. Here we do not override the defaults, which
// means any target is allowed, and the default is native. Other options
// for restricting supported target set are available.
const target = b.standardTargetOptions(.{});
// Standard optimization options allow the person running `zig build` to select
// between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. Here we do not
// set a preferred release mode, allowing the user to decide how to optimize.
const optimize = b.standardOptimizeOption(.{});
// It's also possible to define more custom flags to toggle optional features
// of this build script using `b.option()`. All defined flags (including
// target and optimize options) will be listed when running `zig build --help`
// in this directory.
// This creates a module, which represents a collection of source files alongside
// some compilation options, such as optimization mode and linked system libraries.
// Zig modules are the preferred way of making Zig code available to consumers.
// addModule defines a module that we intend to make available for importing
// to our consumers. We must give it a name because a Zig package can expose
// multiple modules and consumers will need to be able to specify which
// module they want to access.
const mod = b.addModule("janet", .{
// The root source file is the "entry point" of this module. Users of
// this module will only be able to access public declarations contained
// in this file, which means that if you have declarations that you
// intend to expose to consumers that were defined in other files part
// of this module, you will have to make sure to re-export them from
// the root file.
.root_source_file = b.path("src/janet.zig"),
// Later on we'll use this module as the root module of a test executable
// which requires us to specify a target.
.target = target,
.link_libc = true,
});
mod.addIncludePath(b.path("c_src"));
mod.addCSourceFile(.{ .file = b.path("c_src/janet.c"), .flags = &.{}, .language = .c });
// Here we define an executable. An executable needs to have a root module
// which needs to expose a `main` function. While we could add a main function
// to the module defined above, it's sometimes preferable to split business
// logic and the CLI into two separate modules.
//
// If your goal is to create a Zig library for others to use, consider if
// it might benefit from also exposing a CLI tool. A parser library for a
// data serialization format could also bundle a CLI syntax checker, for example.
//
// If instead your goal is to create an executable, consider if users might
// be interested in also being able to embed the core functionality of your
// program in their own executable in order to avoid the overhead involved in
// subprocessing your CLI tool.
//
// If neither case applies to you, feel free to delete the declaration you
// don't need and to put everything under a single module.
const exe = b.addExecutable(.{
.name = "janet",
.root_module = b.createModule(.{
// b.createModule defines a new module just like b.addModule but,
// unlike b.addModule, it does not expose the module to consumers of
// this package, which is why in this case we don't have to give it a name.
.root_source_file = b.path("src/main.zig"),
// Target and optimization levels must be explicitly wired in when
// defining an executable or library (in the root module), and you
// can also hardcode a specific target for an executable or library
// definition if desireable (e.g. firmware for embedded devices).
.target = target,
.optimize = optimize,
// List of modules available for import in source files part of the
// root module.
.imports = &.{
// Here "janet" is the name you will use in your source code to
// import this module (e.g. `@import("janet")`). The name is
// repeated because you are allowed to rename your imports, which
// can be extremely useful in case of collisions (which can happen
// importing modules from different packages).
.{ .name = "janet", .module = mod },
},
}),
});
// This declares intent for the executable to be installed into the
// install prefix when running `zig build` (i.e. when executing the default
// step). By default the install prefix is `zig-out/` but can be overridden
// by passing `--prefix` or `-p`.
b.installArtifact(exe);
// This creates a top level step. Top level steps have a name and can be
// invoked by name when running `zig build` (e.g. `zig build run`).
// This will evaluate the `run` step rather than the default step.
// For a top level step to actually do something, it must depend on other
// steps (e.g. a Run step, as we will see in a moment).
const run_step = b.step("run", "Run the app");
// This creates a RunArtifact step in the build graph. A RunArtifact step
// invokes an executable compiled by Zig. Steps will only be executed by the
// runner if invoked directly by the user (in the case of top level steps)
// or if another step depends on it, so it's up to you to define when and
// how this Run step will be executed. In our case we want to run it when
// the user runs `zig build run`, so we create a dependency link.
const run_cmd = b.addRunArtifact(exe);
run_step.dependOn(&run_cmd.step);
// By making the run step depend on the default step, it will be run from the
// installation directory rather than directly from within the cache directory.
run_cmd.step.dependOn(b.getInstallStep());
// This allows the user to pass arguments to the application in the build
// command itself, like this: `zig build run -- arg1 arg2 etc`
if (b.args) |args| {
run_cmd.addArgs(args);
}
// Creates an executable that will run `test` blocks from the provided module.
// Here `mod` needs to define a target, which is why earlier we made sure to
// set the releative field.
const mod_tests = b.addTest(.{
.root_module = mod,
});
// A run step that will run the test executable.
const run_mod_tests = b.addRunArtifact(mod_tests);
// Creates an executable that will run `test` blocks from the executable's
// root module. Note that test executables only test one module at a time,
// hence why we have to create two separate ones.
const exe_tests = b.addTest(.{
.root_module = exe.root_module,
});
// A run step that will run the second test executable.
const run_exe_tests = b.addRunArtifact(exe_tests);
// A top level step for running all tests. dependOn can be called multiple
// times and since the two run steps do not depend on one another, this will
// make the two of them run in parallel.
const test_step = b.step("test", "Run tests");
test_step.dependOn(&run_mod_tests.step);
test_step.dependOn(&run_exe_tests.step);
// Just like flags, top level steps are also listed in the `--help` menu.
//
// The Zig build system is entirely implemented in userland, which means
// that it cannot hook into private compiler APIs. All compilation work
// orchestrated by the build system will result in other Zig compiler
// subcommands being invoked with the right flags defined. You can observe
// these invocations when one fails (or you pass a flag to increase
// verbosity) to validate assumptions and diagnose problems.
//
// Lastly, the Zig build system is relatively simple and self-contained,
// and reading its source code will allow you to master it.
}
janet/build.zig.zon
+81
View File
@@ -0,0 +1,81 @@
.{
// This is the default name used by packages depending on this one. For
// example, when a user runs `zig fetch --save <url>`, this field is used
// as the key in the `dependencies` table. Although the user can choose a
// different name, most users will stick with this provided value.
//
// It is redundant to include "zig" in this name because it is already
// within the Zig package namespace.
.name = .janet,
// This is a [Semantic Version](https://semver.org/).
// In a future version of Zig it will be used for package deduplication.
.version = "0.0.0",
// Together with name, this represents a globally unique package
// identifier. This field is generated by the Zig toolchain when the
// package is first created, and then *never changes*. This allows
// unambiguous detection of one package being an updated version of
// another.
//
// When forking a Zig project, this id should be regenerated (delete the
// field and run `zig build`) if the upstream project is still maintained.
// Otherwise, the fork is *hostile*, attempting to take control over the
// original project's identity. Thus it is recommended to leave the comment
// on the following line intact, so that it shows up in code reviews that
// modify the field.
.fingerprint = 0x9b91c47ad8f37d9c, // Changing this has security and trust implications.
// Tracks the earliest Zig version that the package considers to be a
// supported use case.
.minimum_zig_version = "0.16.0",
// This field is optional.
// Each dependency must either provide a `url` and `hash`, or a `path`.
// `zig build --fetch` can be used to fetch all dependencies of a package, recursively.
// Once all dependencies are fetched, `zig build` no longer requires
// internet connectivity.
.dependencies = .{
// See `zig fetch --save <url>` for a command-line interface for adding dependencies.
//.example = .{
// // When updating this field to a new URL, be sure to delete the corresponding
// // `hash`, otherwise you are communicating that you expect to find the old hash at
// // the new URL. If the contents of a URL change this will result in a hash mismatch
// // which will prevent zig from using it.
// .url = "https://example.com/foo.tar.gz",
//
// // This is computed from the file contents of the directory of files that is
// // obtained after fetching `url` and applying the inclusion rules given by
// // `paths`.
// //
// // This field is the source of truth; packages do not come from a `url`; they
// // come from a `hash`. `url` is just one of many possible mirrors for how to
// // obtain a package matching this `hash`.
// //
// // Uses the [multihash](https://multiformats.io/multihash/) format.
// .hash = "...",
//
// // When this is provided, the package is found in a directory relative to the
// // build root. In this case the package's hash is irrelevant and therefore not
// // computed. This field and `url` are mutually exclusive.
// .path = "foo",
//
// // When this is set to `true`, a package is declared to be lazily
// // fetched. This makes the dependency only get fetched if it is
// // actually used.
// .lazy = false,
//},
},
// Specifies the set of files and directories that are included in this package.
// Only files and directories listed here are included in the `hash` that
// is computed for this package. Only files listed here will remain on disk
// when using the zig package manager. As a rule of thumb, one should list
// files required for compilation plus any license(s).
// Paths are relative to the build root. Use the empty string (`""`) to refer to
// the build root itself.
// A directory listed here means that all files within, recursively, are included.
.paths = .{
"build.zig",
"build.zig.zon",
"src",
// For example...
//"LICENSE",
//"README.md",
},
}
janet/c_src/janet.c
+57303
View File
File diff suppressed because it is too large Load Diff
janet/c_src/janet.h
+2455
View File
File diff suppressed because it is too large Load Diff
janet/src/janet.zig
+3
View File
@@ -0,0 +1,3 @@
pub const janet = @cImport({
@cInclude("janet.h");
});
janet/src/main.zig
+83
View File
@@ -0,0 +1,83 @@
const std = @import("std");
const Io = std.Io;
const janet = @import("janet");
pub fn main(init: std.process.Init) !void {
// Prints to stderr, unbuffered, ignoring potential errors.
std.debug.print("All your {s} are belong to us.\n", .{"codebase"});
// This is appropriate for anything that lives as long as the process.
const arena: std.mem.Allocator = init.arena.allocator();
// Accessing command line arguments:
const args = try init.minimal.args.toSlice(arena);
for (args) |arg| {
std.log.info("arg: {s}", .{arg});
}
// In order to do I/O operations need an `Io` instance.
const io = init.io;
// Stdout is for the actual output of your application, for example if you
// are implementing gzip, then only the compressed bytes should be sent to
// stdout, not any debugging messages.
var stdout_buffer: [1024]u8 = undefined;
var stdout_file_writer: Io.File.Writer = .init(.stdout(), io, &stdout_buffer);
const stdout_writer = &stdout_file_writer.interface;
_ = janet.janet.janet_init();
try stdout_writer.flush(); // Don't forget to flush!
}
// test "simple test" {
// const gpa = std.testing.allocator;
// var list: std.ArrayList(i32) = .empty;
// defer list.deinit(gpa); // Try commenting this out and see if zig detects the memory leak!
// try list.append(gpa, 42);
// try std.testing.expectEqual(@as(i32, 42), list.pop());
// }
// test "fuzz example" {
// try std.testing.fuzz({}, testOne, .{});
// }
// fn testOne(context: void, smith: *std.testing.Smith) !void {
// _ = context;
// // Try passing `--fuzz` to `zig build test` and see if it manages to fail this test case!
// const gpa = std.testing.allocator;
// var list: std.ArrayList(u8) = .empty;
// defer list.deinit(gpa);
// while (!smith.eos()) switch (smith.value(enum { add_data, dup_data })) {
// .add_data => {
// const slice = try list.addManyAsSlice(gpa, smith.value(u4));
// smith.bytes(slice);
// },
// .dup_data => {
// if (list.items.len == 0) continue;
// if (list.items.len > std.math.maxInt(u32)) return error.SkipZigTest;
// const len = smith.valueRangeAtMost(u32, 1, @min(32, list.items.len));
// const off = smith.valueRangeAtMost(u32, 0, @intCast(list.items.len - len));
// try list.appendSlice(gpa, list.items[off..][0..len]);
// try std.testing.expectEqualSlices(
// u8,
// list.items[off..][0..len],
// list.items[list.items.len - len ..],
// );
// },
// };
// }
notes.md
+5
View File
@@ -0,0 +1,5 @@
# Notes
Location for any thoughts I have along the way in implementing the various embedded language projects.
psuedocode.txt
+15
View File
@@ -0,0 +1,15 @@
led_pin = 16
sensor_pin = 2
led_on = false
register-task("blink", 500):
if led_on:
set-pin(led_pin, 0)
else:
set-pin(led_pin, 1)
led_on = !led_on
register-task("sense", 1000):
val = read-sensor(sensor_pin)
log(val)