NOCLIP/demo/demo.zig

174 lines
6.3 KiB
Zig
Raw Normal View History

2022-11-20 12:54:26 -08:00
const std = @import("std");
const noclip = @import("noclip");
const Choice = enum { first, second };
2025-02-21 23:15:59 -07:00
const U8Tuple = struct { u8, u8 };
const Main = struct {
pub const description =
\\The definitive noclip demonstration utility.
\\
\\This command demonstrates the functionality of the noclip library. cool!
\\
\\> // implementing factorial recursively is a silly thing to do
\\> pub fn fact(n: u64) u64 {
\\> if (n == 0) return 1;
2025-02-21 23:15:59 -07:00
\\> return n * fact(n - 1);
\\> }
\\
\\Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
\\incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
\\nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
\\Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore
\\eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident,
\\sunt in culpa qui officia deserunt mollit anim id est laborum.
2025-02-21 23:15:59 -07:00
;
pub const options: noclip.CommandOptions = .{};
pub const parameters = struct {
// pub const tuple: noclip.Option(U8Tuple) = .{
// .short = 't',
// .long = "tuple",
// .env = "NOCLIP_TEST",
// .description = "tuple test option",
// };
pub const choice: noclip.Option(Choice) = .{
.short = 'c',
.long = "choice",
.env = "NOCLIP_CHOICE",
.description = "enum choice option",
};
pub const string: noclip.Option(noclip.String) = .{
.short = 's',
.long = "string",
2025-03-06 00:45:36 -07:00
.env = "NOCLIP_STRING",
2025-02-21 23:15:59 -07:00
.description = "A string value option",
};
pub const default: noclip.Option(u32) = .{
.name = "default",
2025-03-06 00:45:36 -07:00
.description = "default value integer option",
2025-02-21 23:15:59 -07:00
.short = 'd',
.long = "default",
2025-03-06 00:45:36 -07:00
.env = "NOCLIP_DEFAULT",
2025-02-21 23:15:59 -07:00
.default = 100,
2025-03-06 00:45:36 -07:00
// .nice_type_name = "uint",
};
pub const counter: noclip.Counter(u32) = .{
.name = "default",
2025-02-21 23:15:59 -07:00
.description = "default value integer option",
2025-03-06 00:45:36 -07:00
.short = 'd',
.long = "default",
.env = "NOCLIP_DEFAULT",
// .nice_type_name = "uint",
2025-02-21 23:15:59 -07:00
};
pub const multi: noclip.Option(noclip.Accumulate(u8)) = .{
.name = "multi",
.short_tag = 'm',
.long_tag = "multi",
.description = "multiple specification test option",
};
2025-03-06 00:45:36 -07:00
pub const flag: noclip.BoolGroup = .{
2025-02-21 23:15:59 -07:00
.name = "flag",
.truthy = .{ .short = 'f', .long = "flag" },
.falsy = .{ .short = 'F', .long = "no-flag" },
.env = "NOCLIP_FLAG",
.description = "boolean flag",
};
// pub const multiflag: noclip.Flag = .{
// .name = "multiflag",
// .truthy = .{ .short = 'M' },
// .description = "multiple specification test flag",
// .multi = .accumulate,
// };
pub const env_only: noclip.Option(u8) = .{
.env = "NOCLIP_ENVIRON",
.description = "environment variable only option",
};
// pub const group: noclip.Group(bool) = .{
// .parameters = struct {
// pub const a: noclip.Flag = .{
// .truthy = .{ .short = 'z' },
// };
// },
// };
};
pub const subcommands = struct {
pub const subcommand = Subcommand;
pub const deeply = struct {
pub const info: noclip.CommandInfo = .{ .description = "start of a deeply nested subcommand" };
pub const subcommands = struct {
pub const nested = struct {
pub const info: noclip.CommandInfo = .{ .description = "second level of a deeply nested subcommand" };
pub const subcommands = struct {
pub const subcommand = struct {
pub const info: noclip.CommandInfo = .{ .description = "third level of a deeply nested subcommand" };
pub const subcommands = struct {
pub const group = struct {
pub const info: noclip.CommandInfo = .{ .description = "final level of a deeply nested subcommand" };
pub fn run() void {
std.debug.print("but it does nothing\n");
}
};
};
};
};
};
};
};
};
2025-02-21 23:15:59 -07:00
pub fn run(args: noclip.Result(Main)) void {
if (args.choice) |choice| {
std.debug.print("You chose: {s}\n", .{@tagName(choice)});
} else {
std.debug.print("You chose nothing!\n", .{});
}
}
pub fn err(report: noclip.ErrorReport) void {
_ = report;
}
2022-11-20 12:54:26 -08:00
};
2025-02-21 23:15:59 -07:00
const Subcommand = struct {
pub const info: noclip.CommandInfo = .{
.name = "subcommand",
.description =
parser: shove an arena allocator in there Stay a while and listen to my story. Due to the design of the parser execution flow, the only reasonable way to avoid leaking memory in the parser is to use an arena allocator because the parser itself doesn't have direct access to everything it allocates, and everything it allocates needs to live for the duration of whatever callbacks are called. Now, you might say, if the items it allocates are stored for the lifetime of whatever callbacks, then that means that the items it allocates stay allocated for effectively the entire life of the program. In which case there's really not much point in freeing them at all, as it's just extra work on exit that the OS should normally clean up. And you'd be right, except for two details: if the user uses the current GeneralPurposeAllocator, it will complain about leaks when deinitialized, which simply isn't groovy. The other detail is that technically the user can run any code they want after the parser execution finishes, so forcing the user to leak memory by having an incomplete API is rude. The other option would be, as before, forcing the user to supply their own arena allocator if they don't want to leak, but that's kind of a rude thing to do and goes against the "all allocators look the same" design of the standard library, which is what makes it so easy to use and create allocators with advanced functionality. That seems like an ugly thing to do, so, instead, each parser gets to eat the memory cost of storing a pointer to its arena allocator (and the heap cost of the arena allocator itself). In theory, subcommands could borrow the arena allocator of their parent command to save a bit of heap space, but that would make a variety of creation and cleanup-related tasks less isomorphic between the parents and the subcommands. I like the current design where commands and subcommands are the same thing, and I'm not in a rush to disturb that. I don't think the overhead cost of the arena allocator itself, which can be measured in double digit bytes, is a particularly steep price to pay.
2023-07-20 23:15:37 -07:00
\\Demonstrate subcommand functionality
\\
parser: shove an arena allocator in there Stay a while and listen to my story. Due to the design of the parser execution flow, the only reasonable way to avoid leaking memory in the parser is to use an arena allocator because the parser itself doesn't have direct access to everything it allocates, and everything it allocates needs to live for the duration of whatever callbacks are called. Now, you might say, if the items it allocates are stored for the lifetime of whatever callbacks, then that means that the items it allocates stay allocated for effectively the entire life of the program. In which case there's really not much point in freeing them at all, as it's just extra work on exit that the OS should normally clean up. And you'd be right, except for two details: if the user uses the current GeneralPurposeAllocator, it will complain about leaks when deinitialized, which simply isn't groovy. The other detail is that technically the user can run any code they want after the parser execution finishes, so forcing the user to leak memory by having an incomplete API is rude. The other option would be, as before, forcing the user to supply their own arena allocator if they don't want to leak, but that's kind of a rude thing to do and goes against the "all allocators look the same" design of the standard library, which is what makes it so easy to use and create allocators with advanced functionality. That seems like an ugly thing to do, so, instead, each parser gets to eat the memory cost of storing a pointer to its arena allocator (and the heap cost of the arena allocator itself). In theory, subcommands could borrow the arena allocator of their parent command to save a bit of heap space, but that would make a variety of creation and cleanup-related tasks less isomorphic between the parents and the subcommands. I like the current design where commands and subcommands are the same thing, and I'm not in a rush to disturb that. I don't think the overhead cost of the arena allocator itself, which can be measured in double digit bytes, is a particularly steep price to pay.
2023-07-20 23:15:37 -07:00
\\This command demonstrates how subcommands work.
,
2025-02-21 23:15:59 -07:00
.options = .{ .parse_error_behavior = .exit },
};
2022-11-20 12:54:26 -08:00
2025-02-21 23:15:59 -07:00
pub const parameters = struct {
2025-03-06 00:45:36 -07:00
pub const flag: noclip.BoolGroup = .{
2025-02-21 23:15:59 -07:00
.truthy = .{ .short = 'f', .long = "flag" },
.falsy = .{ .long = "no-flag" },
2025-03-06 00:45:36 -07:00
.env = "NOCLIP_SUBFLAG",
2025-02-21 23:15:59 -07:00
};
pub const first_arg: noclip.Argument(noclip.String) = .{};
pub const second_arg: noclip.Argument(noclip.String) = .{
.description = "This is an argument that doesn't really do anything, but it's very important.",
};
};
};
2022-11-20 12:54:26 -08:00
pub fn main() !u8 {
parser: shove an arena allocator in there Stay a while and listen to my story. Due to the design of the parser execution flow, the only reasonable way to avoid leaking memory in the parser is to use an arena allocator because the parser itself doesn't have direct access to everything it allocates, and everything it allocates needs to live for the duration of whatever callbacks are called. Now, you might say, if the items it allocates are stored for the lifetime of whatever callbacks, then that means that the items it allocates stay allocated for effectively the entire life of the program. In which case there's really not much point in freeing them at all, as it's just extra work on exit that the OS should normally clean up. And you'd be right, except for two details: if the user uses the current GeneralPurposeAllocator, it will complain about leaks when deinitialized, which simply isn't groovy. The other detail is that technically the user can run any code they want after the parser execution finishes, so forcing the user to leak memory by having an incomplete API is rude. The other option would be, as before, forcing the user to supply their own arena allocator if they don't want to leak, but that's kind of a rude thing to do and goes against the "all allocators look the same" design of the standard library, which is what makes it so easy to use and create allocators with advanced functionality. That seems like an ugly thing to do, so, instead, each parser gets to eat the memory cost of storing a pointer to its arena allocator (and the heap cost of the arena allocator itself). In theory, subcommands could borrow the arena allocator of their parent command to save a bit of heap space, but that would make a variety of creation and cleanup-related tasks less isomorphic between the parents and the subcommands. I like the current design where commands and subcommands are the same thing, and I'm not in a rush to disturb that. I don't think the overhead cost of the arena allocator itself, which can be measured in double digit bytes, is a particularly steep price to pay.
2023-07-20 23:15:37 -07:00
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa.deinit();
const allocator = gpa.allocator();
2025-02-21 23:15:59 -07:00
const args = try std.process.argsAlloc(allocator);
defer std.process.argsFree(allocator, args);
var env = try std.process.getEnvMap(allocator);
defer env.deinit();
2022-11-20 12:54:26 -08:00
2025-02-21 23:15:59 -07:00
try noclip.execute(Main, .{ .args = args, .env = env });
return 0;
2022-11-20 12:54:26 -08:00
}