marler8997

#!/usr/bin/env python3
import sys
import os
import re
import argparse
import subprocess

def scan_path(defines, path):
    for entry_base in os.listdir(path):
        entry = os.path.join(path, entry_base)

marler8997

#include <windows.h>
#include <stdio.h>

#define logf(fmt,...) do { fprintf(stderr, fmt "\n", ##__VA_ARGS__); fflush(stderr); } while (0)

void MonitorDirectoryRecursively(const char* directoryPath) {
    HANDLE hChange = FindFirstChangeNotification(
        directoryPath,
        TRUE, // Watch the subtree
        FILE_NOTIFY_CHANGE_LAST_WRITE | FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_DIR_NAME

marler8997

const std = @import("std");
const mem = std.mem;
const testing = std.testing;

/// AnyWriter is an instance of std.io.Writer that is able to wrap
/// any other std.io.Writer type and forward data to it.
///
/// AnyWriter enables std.io.Writer to be used in places where concrete
/// types are required such as function pointer parameters or as a field
/// in a struct.

marler8997

const std = @import("std");
const Vm = @import("vm.zig").Vm;

const tokenizer = @import("tokenizer.zig");

pub fn lex(src: [:0]const u8, off: usize) tokenizer.Token {
    var t = @import("tokenizer.zig").Tokenizer{ .code = src, .idx = off };
    return t.next();
}

marler8997

fn changePitchOne(freq: u16, semitones: f32) u16 {
    if (freq == 0) return 0;
    const freq_f32 = @as(f32, @floatFromInt(freq));
    return @intFromFloat(@round(freq_f32 * std.math.pow(
        f32,
        @exp2(1.0 / 12.0),
        semitones,
    )));
}

marler8997

const std = @import("std");

fn fatal(comptime fmt: []const u8, args: anytype) noreturn {
    std.log.err(fmt, args);
    std.os.exit(0xff);
}

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

marler8997

Since people seem to enjoy making scripting languages so much (not meant to be a "dig", I like this)...here's a scripting language I'd be very interested in.

ZigScript

"A companion scripting language meant for Zig developers."

Zig is my language of choice, but I still reach for Python when I want to make something fast or "short lived". However, Python has downsides, it's hard to build the interpreter for it (especially a static executable), its packaging system is a mess and it's got some interesting syntax choices that would feel foreign to a native Zig developer, but overall I think the core of the language is brilliant. I imagine ZigScript as Python but in a "Zig Style" syntax with the problems fixed. Here are some features that come to mind:

marler8997

const std = @import("std");

const stdout = std.io.getStdOut().writer();

fn raw(s: []const u8) void {
    stdout.writeAll(s) catch |err| @panic(@errorName(err));
}
fn fmt(comptime spec: []const u8, args: anytype) void {
    stdout.print(spec, args) catch |err| @panic(@errorName(err));
}

marler8997

# A crude proof of concept to show how to import the environment variables created from
# a BATCH script.  You can use this to make your NuShell into a Visual Studio Command Prompt.
#
# The current solution passes the input as a command to CMD.exe and appends a couple commands
# to dump a marker and then all environment variables which are then parsed and added to
# the caller environment.  A better solution would be to not capture stdout/stderr in the
# child process and instead append a command that passes the resulting environment variables
# back to the NuShell process through a side-channel (i.e. named pipe maybe). It's probably
# best for NuShell to just support this natively as it's a common use case, maybe it can
# do so by just allowing the "source" command to accept BATCH files...and extra command-line

marler8997

Win32DPI and MonitorScale

In the win32 API, DPI doesn't actually mean "Dots Per Inch". Instead, it's just another way to represent the MonitorScale. I'll use the term "Win32DPI" to differentiate it from a real DPI. These two values have a one-to-one mapping:

Win32DPI = 96 * MonitorScale
MonitorScale = Win32DPI / 96

Since these values are just 2 different ways of looking at the same thing, if things get confusing you can always forget about one and just think about the other. MonitorScale is the value exposed to end users, controlled by going to "Display Settings" > "Scale and Layout" whereas Win32DPI is the value used by the win32 API. Monitor scaling was introduced to Windows to address programs becoming "too small" when resolution density increased. This means MonitorScale is always >= 100% which in turn also means Win32DPI >= 96.