Please help me understand Zig, I am trying to not use AI

[formal tulip]

Wait, are you trying to make an emulator or run something on te gameboy

[compact sage]

make an emu

[onyx widget]

^

[stone jewel]

if this tests exists somewhere you should run it as a rom

[onyx widget]

I'm talking about your code

[compact sage]

the original one has a lot of forbidden regions/ mirrored regions, etc etc

[onyx widget]

show me a snippet of your code

what is the dang difference

[compact sage]

rn there isnt any difference, once I start implementing more it will break

[onyx widget]

the read methods are the same. the write methods are the same

what is diff

is it the values in bytes that will be diff?

[compact sage]

yeah only for now, because I havent started implementing the memory regions

[formal tulip]

Also, considering that the gameboy is in a different arch, why are you attempting to directly map its memory space to x86_64's memory space?

[compact sage]

yeah

[stone jewel]

The true validation on an emulator are test roms imo
I do that for my NES emulator

[onyx widget]

just initialize them differently for the test then

nbd

[compact sage]

test roms are there, but I am doing this https://github.com/singlesteptests/sm83

[formal tulip]

Wait, I think I understand what is going on now

[compact sage]

I cant test test roms until i have implemented more stuff

[onyx widget]

you can add it as test-only method to the struct, or you can just do it manually in the test - no private fields, take advantage :P

[formal tulip]

Yeah, there is no reason to test the emulator under a fake condition

It just makes the test unreliable

[onyx widget]

you bigly overthinking it

[compact sage]

initialization isnt the only different part, some regions are read only, some are mirrored. The mocked memory shouldnt have those

[compact sage]

this is just a cpu test, it doesnt test the entire emu

[formal tulip]

At best, it is not useful, at worst, it drives bad design decisions

[formal tulip]

The behaviour of the CPU is not independent of the memory space

[compact sage]

it is

i am trying to verify whether the cpu implemntation is working or not

not how it interacts with the rest of the system

[onyx widget]

what does it mean for something to be read-only. where is the information stored that says it is that

[stone jewel]

I agree it isn't, but you can only test it with real program imo
You are emulating, you don't really have the memory mock issue

[onyx widget]

is it stored in the mocked memory itself, or in the emulated hardware?

[compact sage]

prohibited regions

[onyx widget]

I am talking about the design of your program

I understand emulators, I am trying to understand what you are doing

because the problems you are describing don't make sense to me

[compact sage]

read only means I ignore writes in that address space

[onyx widget]

then why can't just do that for the real virtual mem structure

[stone jewel]

Nothing stops you to use prohibited regions if no one uses it for nothing btw
You can not emulate them (Wrong) or emulate them and have UB behaviour (Kinda ok) or search what happened in games on that region

[formal tulip]

You cannot make this claim without knowing the ISA

It may very well be the case that certain memory accesses correspond to different CPU behaviours

[compact sage]

my problem is simple:

• I have a component A which has a dependency B
• I need to mock the internals of dependency B for a specific test of A
  That is all I need

[formal tulip]

In an arch such as the Gameboy's, this would make sense

[stone jewel]

Why would you separate them

[compact sage]

talking about gameboy specific stuff or my emulator design is not the goal

[stone jewel]

is my question

[formal tulip]

As the whole system is very closely tied together

[compact sage]

how do i achieve this in zig

[stone jewel]

We generally don't like X Y questions =(

Because at hand here is a bigger issue

Why you need to mock them

It is not clear

Note, I have also written emulators, and I develop for the gba for fun

[formal tulip]

Anyways, you are designing an emulator, not a hardware component. Treating things as independent from each other is an unnecessary goal

[compact sage]

i need the component to behave differently in the test than it would do originally

[stone jewel]

Why?

[compact sage]

the test requires it

[formal tulip]

The point is to accurately run ROMs

[stone jewel]

Feels like outside the point

[formal tulip]

You do not need the component independence assumption for that

[compact sage]

can i do this in zig or not?

[stone jewel]

The test might require whatever, just skip the test, test yourself the same assumption if you want static guardrails

the answer is yes, but we see at as pointless

[onyx widget]

if you really want to do this: make it generic over the type. shitass solution, because then you're not really testing that it works. but go off

or make it a runtime vtable

pick yer poison

[formal tulip]

Not to mention that because Zig is not an HDL, you will most likely harm your program over this (in terms of performance)

[onyx widget]

to be clear, that is how "mocking" works in all languages

[compact sage]

I cant skip the test

[compact sage]

hmm not looking for a runtime perf impact so probably not that

[stone jewel]

This vtable would have minimal runtime perf hits

[onyx widget]

a mock is just a way to inject some code that does something differently. all other languages do this using things like interfaces, vtables, generics, w/e. zig does not do these in as "pretty" ways, so it's going to look as shitass as it is

[stone jewel]

but the better way is rewrite the test to your constraints

Or make CPU truly separate from memory and Create the Test Suite with Custom Memory types

But this is gonna make you write specific code as a handler for the CPU test

[compact sage]

making the cpu separate from memory like passing it explicitly everywhere?

[stone jewel]

And you will miss integration issues later on if you don't test those

Not necesarily

Just CPU is it's own type

and doesn't know about memory

it knows maybe about the BUS

[reef stirrup]

I think you should show roughly the code you want to run, the stage at which you encounter the problem and what is your expected desired outcome is. Otherwise, it is quite hard to help most of programmers are highly visual and need to see the code in front of them to understand what is going on precisely 👍

[compact sage]

https://github.com/kaezrr/zigb

its here

[stone jewel]

Less so than this, I think most of us understand it, is just... baffling ig

We won't provide code per se either

[formal tulip]

Tbh, I don't think designing things that independently frpm each other makes sense in an emulator

As i said, it is not hardware design

[stone jewel]

It is not, but it has it's merits

[compact sage]

idk why zig doesnt plan to have a more convenient way to do interfaces when its probably one of the most important concepts in programming since functions and classes

[stone jewel]

OOP is not an objective

[formal tulip]

Because there are a lot of ways to design interfaces

[stone jewel]

And interface design is important

there isn't a single prescribed way of doing so

[formal tulip]

And Zig should not prefer one over the other

[stone jewel]

Like ink said, an interface is a vtable in most langs

so

[formal tulip]

Because each one has its own merits

[onyx widget]

being important does not mean it has to be convenient to do. making it convenient to do means endorsing it, and zig doesn't endorse needless abstractions like the one you want

[stone jewel]

In this case for this specific code with the intentions of this specific user I would:

• Create a standalone CPU emulator with callbacks for memory writes
• Create a Test Handler for the CPU bit of the equation, it loads the test from the jsons and creates a highly standarized set of test
• Since Mem is abstracted as read/write via callbacks, the compiler can inline this calls easily, specially if it's comptime known
• You then create you Emulator that holds mem and cpu, CPU calls the callbacks of mem that you init at the start of your emulator

this way you get a closure over the set of memories

[compact sage]

I thought zig liked having a single way of doing things, instead of everyone doing stuff their own way

[formal tulip]

That applies to things that do not have actual reasons for being different

comptime polymorphism vs runtime polymorphism, for example, is not just a styling preference

each one has actual usecases and situations where it is preferable over the other

[onyx widget]

it aims to have one obvious way to use the language, not a singular way to do every single thing. programming is a field rife with seemingly minimally different, but importantly distinct approaches to many things, with lots of different tradeoffs. it is impossible to literally only have "one" way to do absolutely everything, and generics/interfaces/polymorphism is one where there are so many different tradeoffs that, even beyond the concern of not wanting to endores needless abstraction, it would be irresponsible as a low level language to endorse one specific model for this kind of abstraction, when such a wide berth of approaches exist

[compact sage]

I mean rust does this with Traits and dyn Traits, you can make it easier without having to put one path down

[onyx widget]

zig ain't rust

different design priorities

rust embraces super complex abstraction

zig encourages thinking about the particulars a lot before even considering abstractions

[plucky niche]

in this case rust locks you into one way to have the language take away from you how monomorphization and dynamic dispatch actually works

[stone jewel]

In this case, you can move on and just abstract over two functions (if you want you can pas the vtable at comptime)

[plucky niche]

I feel like zig is a lot about not taking away power from the user for no reason

[stone jewel]

Callbacks are fun

[plucky niche]

like closures, why do you need to take a ctx object by hand in zig? because look at rusts FN types and the issues and confusion it causes

[onyx widget]

and the hidden performance issues

[compact sage]

also is there a way to do inclusive range in for loops

[plucky niche]

a lot of zig is doing things by hand because the solution is NOT as obvious as a lot of languages make it seem

[formal tulip]

no. Just add one to your range

[stone jewel]

pub fn step(
        self: *Cpu, 
        comptime Memory:  type,
        comptime readFn: fn(ctx: *Memory, addr: u16) u8,
        comptime writeFn: fn(ctx: *Memory, addr: u16, val: u8) void,
        ctx: *Memory
    ) void {
        const opcode = readFn(ctx, self.pc);
        self.pc += 1;
        // handle opcode...
    }

[plucky niche]

use codeblocks

[stone jewel]

I fucking know

[plucky niche]

else this is unreadable

[stone jewel]

But shit is failing ok

an I am getting a tad mad =D

[onyx widget]

for (a..b + 1) |inclusive| {}

[compact sage]

hmmm

how do i see output in tests btw

[plucky niche]

i actually dislike this, the proximity makes it read as range + int for me

i would, even tho its pointless, write this as a..(b+1)

[onyx widget]

bre

[compact sage]

this doesnt feel clean

[formal tulip]

I mean, considering that range + int is not a valid operation in Zig, I don't see how one might come to the conclusion

[plucky niche]

because its not, the code looking clean doesnt make the implementation less complex

[onyx widget]

tests are not intended to emit output, they are intended to test conditions. if you want to debug stuff, you can use std.log.err (note that reaching a call to this will also mark the test as failed)

[plucky niche]

hiding complexity is not equal better code

if the complexity is relevant

my programming teacher always said "you cant hide complexity" it will show up somewhere

he religiously mentioned this every lesson

[formal tulip]

law of leaky abstractions moment?

[stone jewel]

You can also make CPU a generic that takes a memory type with a duck typed interface
But
This is as minimal you can get without incurring perf issues

The friction is because you are doing all this for a thing you can manually replicate in your own model and adapt

but you are not adapting, so we gotta get creative

[formal tulip]

I still do not get why you want to have all components be strictly separate

you are making an emulator to run ROMs, you are not designing hardware

[compact sage]

i mean i can just do it normal rn, the test will just break in future once the memory stuff gets more implementation

[formal tulip]

yes, that's the point of testing

or rather, the philosophy of testing

[onyx widget]

embrace the YAGNI mindset

do things when you need to

[compact sage]

YAGNI?

[plucky niche]

you aint gonna need it

[onyx widget]

You Aren't Going to Need It

[formal tulip]

you write a breaking test, you implement code until it works, then you write a breaking test again

that's the test driven development

[compact sage]

https://ziglang.org/documentation/0.16.0/ why cant i find any docs about std.json here

[formal tulip]

you should not design tests that pass implemented code

you should write code that passes created tests

[onyx widget]

that's the langref

[compact sage]

oh

[onyx widget]

if you look at the first paragraph, it links to the stdlib docs

[compact sage]

oh my bad

[onyx widget]

all good

you can also have them locally with zig std

(it runs a little local server that you can see in the browser)

[formal tulip]

tests, after all, represent the expectations over the code. They should treat the code like a black box

[stone jewel]

If you want, you can take the cpu tests and take the assumptions of memory out

and so make them your own

[formal tulip]

exposing implementation details like the degree of separation of components is simply bad test design

[compact sage]

its like 10000+ tests for each opcode (200+) so it will be hard

wait maybe not that many

[stone jewel]

They are JSON, you can parse them and out code based on it

[compact sage]

how do i create a formatted string?

trying to look into std.fmt

but cant find the exact function

[reef stirrup]

yeah, std.fmt.bufPrint

[onyx widget]

depends on where the string is going

[compact sage]

but isnt that print

[onyx widget]

if you need it to be dynamically allocated, you can use fmt.allocPrint

[formal tulip]

wdym

[reef stirrup]

it's print to buffer!

[compact sage]

i basically need to construct a filename and then check if that file exists

[formal tulip]

bufPrint does not perform a syscall

since it does not write data to a file

[compact sage]

i thought print meant print to a console

[coral violet]

Could always use std.mem.concat depending on what you actually need

[formal tulip]

no, print literally just means to print a human readable string

to either a fixed buffer or a file

or an array list

[coral violet]

the console is just a file descriptor at the end of the day

[onyx widget]

maybe in other langs. in zig we just use it to mean "uses std.Io.Writer.print"

[formal tulip]

I think for windows it is a bit weirder than that

[onyx widget]

and writers can print to anywhere, including to in-memory buffers

[coral violet]

Tell me, what isnt weird in windows?

[formal tulip]

fair

[coral violet]

Even getting stdout/stderr to the terminal is hell on earth

[onyx widget]

well, it ain't that bad, it's just silly

because it ain't embrace posixy things

[compact sage]

basically need this:

for i in 0..0xFF {
  file_name = "{i}.json";
  if file_name exists {
    read file_name and do stuff
  }
}```

[coral violet]

Linux/Mac/FreeBSD:

./x

Windows:

.\x.exe 2>&1 | %{if($_.Gettype().name -eq "ErrorRecord"){$_.Exception}else{$_}} | Tee-Object -FilePath ./log.txt

[onyx widget]

well, depending on what you're doing bash can be pretty similarly ass

but ye

[stone jewel]

I think is not the place in this user post =3

[coral violet]

Fair

[coral violet]

Yeah bufPrint is all you need then

[reef stirrup]

Getting the colors (ansi) to work in the terminal and making it comfortable to type was actually a nightmare true, but what a result!!

    try app_log.print(.info, .{ "built for ", .os_arch, " on ", .timestamp, .nl }, .{
        zterm.TagConst(.os_arch, "{s} {s}", comptime .{ @tagName(builtin.os.tag), @tagName(builtin.cpu.arch) })
            .setColor(zterm.pallete.sky_magenta),
        zterm.Tag(.timestamp, "{d:04}.{d:02}.{d:02}T{d:02}:{d:02}:{d:02}Z", .{
            irl_date.year,
            irl_date.mon,
            irl_date.day,
            irl_time.hour,
            irl_time.min,
            irl_time.sec,
        }).setColor(zterm.pallete.sky_magenta),
    });

[onyx widget]

const max = 0xFF;
for (0 .. max + 1) |i| {
    var path_buf: [std.fmt.count("{d}.json", .{max})]u8 = undefined;
    const path = std.fmt.bufPrint(&path_buf, "{d}.json", .{i}) catch unreachable;
    const file = try dir.openFile(io, path, .{});
    defer file.close(io);
    // whatever
}

[compact sage]

    var buf: [32]u8 = undefined;

    for (0..0x100) |ins| {
        const file_name = try std.fmt.bufPrint(buf, "{}.json", .{ins});
        std.log.err("{s}", file_name);
    }
``` is this how you use it? sorry kinda new to all this buffer and pointer stuff

[onyx widget]

that would work too ye

[coral violet]

Huh... i didnt know fmt.count was a thing...
Ima steal that

[compact sage]

oh thanks

[onyx widget]

I wrote it in a way that statically guarantees the buffer is exactly as big as it needs to be

and note: declaring the buffer inside or outside the loop doesn't matter

but I think it's nice to keep it close to where it's needed

[coral violet]

I see a potential bug.
He is not setting the buffer to undefined after each iteration

[compact sage]

❯ zig build test --summary all
test
└─ run test zigb
   └─ compile test zigb Debug native 2 errors
src/Cpu.zig:107:9: error: local variable is never mutated
    var file_name: [32]u8 = undefined;
        ^~~~~~~~~
src/Cpu.zig:107:9: note: consider using 'const'
src/Cpu.zig:110:26: error: array literal requires address-of operator (&) to coerce to slice type '[]u8'
        std.fmt.bufPrint(file_name, "{}.json", .{ins});```

[onyx widget]

that doesn't matta

[compact sage]

i get this error

[plucky niche]

that can never be the bug

[onyx widget]

ah, just need to &buf

arrays are values

[plucky niche]

because it doesnt matter if you access stale memory or undefined

both are bad

[onyx widget]

they don't implicitly coerce to slices until you take em by ref

[coral violet]

Hm... i wonder why i had issues with it in previous versions, but i digress

[plucky niche]

if it was 0 terminated then you may need to fill it with zeroes

but other than that

[onyx widget]

you're probably thinking of something else, like using the buf directly instead of the returned slice

[compact sage]

oh silly me

[coral violet]

Probably now that you mention it (why did i do it tho is beyond me rn)

[plucky niche]

even then only a zfill is sensible, not undefined

[compact sage]

i thought declaring outside wouldnt reallocate it every loop

[stone jewel]

No

[onyx widget]

it's just a stack buffer

[stone jewel]

Any buffer is safe to reuse, zig doesn't allocate behind your bag

so what you use is what you get

[onyx widget]

at worst, that would entail incrementing and decrementing the stack pointer

and realistically, it just doesn't do anything because the codegen will just allocate the whole stack frame needed

[compact sage]

oh ok

[plucky niche]

no?

[onyx widget]

no

it just don't matta

the previous contents are overwritten

[plucky niche]

i mean yeah, obviously you need neither zfill nor undefined fill if you know how large the thing you wrote is. i meant specifically when you use nullterm

[compact sage]

btw why do catch unreachable instead of try

[plucky niche]

if it was 0 terminated then you may need to fill it with zeroes
but other than that...

[stone jewel]

It's only problematic if you have memory assumptions in the system @plucky niche

[plucky niche]

yeah

[onyx widget]

because I wrote it in a way that the OutOfSpace error is veritably, and obviously impossible.

so I catch unreachable as an assertion of that fact

[plucky niche]

you never need to override for non terminell terminated stuff, that was my point

[compact sage]

whats dir and io here exactly? how do i access them inside a test

[onyx widget]

for tests, std.testing.io should suffice

dir is just the directory handle where you expect these json files to be inside

if they're in cwd, std.Io.Dir.cwd()

if they're in some subdir, you can open it with like std.Io.Dir.cwd().openDir

I would personally probably pass their path in as a build option

[compact sage]

cwd is where i run zig build run or where the file is

?

[onyx widget]

it is where you run the command in

your "current working directory"

[compact sage]

oh ok

[onyx widget]

once you run the command the file doesn't exist anymore, it's been compiled into the binary n allat

[compact sage]

how do i exactly do that?

[onyx widget]

it's a build system thingie, see b.addOptions()

https://ziglang.org/learn/build-system/, the "Options for Conditional Compilation" section

to be clear, I'm not saying you have to do this

[compact sage]

oh ok thank you

sorry for asking so many questions, I am very new to zig

[onyx widget]

but this is what I would do because I'm a perfectionist who doesn't like relying on relative paths in projects n all that

[compact sage]

it has a lot of things I have never used in any other languages

[onyx widget]

don't apologise, that's what this forum is for

I appreciate that you are using it in the first place

ever since I've founded it as a forum I get nothn but complaints about having to use it smh

[stone jewel]

I will complain more ink

=P

[compact sage]

its nice to have a place where people can focus on a topic without disrupting normal conversation in general

[stone jewel]

when Ink and I started helping on zig help back in 0.8 days, it was a single channel

it was awful have to say

[onyx widget]

yeah, very difficult to keep up with so many questions in one thread of conversation

(discord's forums aren't really perfect either tbh, I long for zulip threads)

[stone jewel]

And we were fast answerers lol

[onyx widget]

them's the days

[compact sage]

is there a way to define functions inside a test

test "something" {
  fn process_test_file(file_name: []u8) io.File.OpenError!void {
      const file = try dir.openFile(io, file_name, .{});
      defer file.close(io);
  }
  ...
}

cause this isnt working

[onyx widget]

same way as defining functions in any other functions

test "something" {
    const nice_name = struct { // like "helper" or something
        fn foo() void {}
    };
    nice_name.foo();
}

[compact sage]

oh ok

[reef stirrup]

imo, it would be even more unsettling if no one complaints...

[compact sage]

can anyone tell me how do i read a json file in zig

I am reading the documentation but its not clear to me

[fierce sage]

Are you talking abour reading file, or parsing JSON string?

[solid dock]

i assume reading a json file and parsing it

[compact sage]

so i read a File, its a json file, I need to work with it

so how do i do that

[solid dock]

do you know about reading a file already?

[compact sage]

yeah

        const file = dir.openFile(io, file_name, .{}) catch continue;
        defer file.close(io);

[fierce sage]

i suggest using this
https://ziglang.org/documentation/master/std/#std.json.static.parseFromTokenSourceLeaky

[compact sage]

how do i work with file as a json file

[solid dock]

do you want to fully load the file into memory before parsing?

[compact sage]

how do i use an allocator

[fierce sage]

well this might suite better
https://ziglang.org/documentation/master/std/#std.json.static.parseFromSlice

[compact sage]

hmm sure? idk

[solid dock]

you can either use the API function that takes in a std.Io.Reader (which is your file reader) or you can just parse the whole text once you have it in memory

[compact sage]

        fn process_test_file(file: std.Io.File) !void {
            // do stuff with file.json
        }

trying to implement it like this

[fierce sage]

i don't recommend passing File it self, as it needs IO to do anything on the file handle anyway

pass reader or raw bytes

[compact sage]

ummm how do i do that

[solid dock]

i fucking hate windows 11, my computer hard-froze

[compact sage]

I do not understand how to use an allocator

[fierce sage]

just pass allocator you have in init

[solid dock]

you either initialize an allocator at the start of your program and pass it down the rest of your program, or you take it off juicy main

you're probably gonna take it off juicy main (which is copying init.gpa)

[compact sage]

I am using this in a test

[fierce sage]

don't be scared of allocators, you don't even have to use it, just pass it where its necessary

[ancient marten]

std.testing.allocator

[solid dock]

then for the moment, it's best if you use std.testing.allocator, yeah

[compact sage]

oh ok

[solid dock]

i'm pretty sure the documentation has a section for picking your allocator, hang on

https://ziglang.org/documentation/master/#Choosing-an-Allocator

yup

[compact sage]

thanks

i dont understand something, why does dir.readFile take a buffer and also return a buffer

like what

[fierce sage]

bc it might read less than the size of buffer

so it returns smaller slice

[compact sage]

test "sm83-single-step-tests" {
    const io = std.testing.io;
    const dir = try std.Io.Dir.cwd().openDir(io, "tests/sm83-ssts/v1", .{});
    const allocator = std.testing.allocator;

    // load test .json;
    // for test in test.json:
    //     set initial processor state from test;
    //     set initial ram state from test;
    //
    //     for cycle in test:
    //         cycle processor
    //         if we are checking cycle-by-cycle:
    //             compare our r/w/mrq/address/data pins against the current cycle;
    //
    //     compare final ram state to test and report any errors;
    //     compare final processor state to test and report any errors;
    const helper = struct {
        fn process_test_file(file: []u8) !void {
        }
    };

    for (0..0xff + 1) |ins| {
        var path_buf: [32]u8 = undefined;

        const file_name = try std.fmt.bufPrint(&path_buf, "{x:02}.json", .{ins});
        const file = dir.readFile(io, file, ??? ) catch continue;
        helper.process_test_file(file);

        if (ins == 0xCB) {
            for (0..0xFF + 1) |sub| {
                const sub_file_name = try std.fmt.bufPrint(&path_buf, "{x:02} {x:02}.json", .{ ins, sub });
                const sub_file = dir.readFile(io, sub_file_name, ??? ) catch continue;
                helper.process_test_file(sub_file);
            }
        }
    }
}

this is basically what I am trying to do

am i doing it right?

[pliant hazel]

would you happen to know the usecase for brkallocator

i still dont get it

[zinc stump]

WASM and embedded

[compact sage]

    const file_buffer = try allocator.alloc(u8, 500 * 1024); // 500 KiB
    defer allocator.free(file_buffer);

    for (0..0xff + 1) |ins| {
        var path_buf: [32]u8 = undefined;

        const file_name = try std.fmt.bufPrint(&path_buf, "{x:02}.json", .{ins});
        const file = dir.readFile(io, file_name, file_buffer) catch continue;
        try helper.process_test_file(file);

        if (ins == 0xCB) {
            for (0..0xFF + 1) |sub| {
                const sub_file_name = try std.fmt.bufPrint(&path_buf, "{x:02} {x:02}.json", .{ ins, sub });
                const sub_file = dir.readFile(io, sub_file_name, file_buffer) catch continue;
                try helper.process_test_file(sub_file);
            }
        }
    }
``` ok this works nicely

am i using the allocator right?

[stone jewel]

yea

[compact sage]

test
└─ run test zigb
   └─ compile test zigb Debug native 1 errors
/usr/lib/zig/std/mem/Allocator.zig:444:50: error: access of union field 'pointer' while field 'union' is active
    const slice_info = @typeInfo(@TypeOf(memory)).pointer;
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
/usr/lib/zig/std/builtin.zig:550:18: note: union declared here
pub const Type = union(enum) {
                 ^~~~~```

what does this error mean

        fn process_test_file(file: []u8) !void {
            const value = try std.json.parseFromSliceLeaky(std.json.Value, allocator, file, .{});
            defer allocator.free(value);
        }

I am just doing this

[peak widget]

value is not a pointer. I think you're not supposed to free a json.Value, you pass an arena allocator and deinit/reset it

[compact sage]

my program just gets stuck idk why

[peak widget]

(value is not a pointer, so allocator.free(value) can't compile)

[compact sage]

no i took care of that

 fn process_test_file(file: []const u8) !void {
    const parsed = try std.json.parseFromSlice(std.json.Value, allocator, file, .{});
    defer parsed.deinit();

    std.log.err("{}", .{parsed.value.array.items.len});
}

just trying to print length and this gets stuck

no idea why

test "sm83-single-step-tests" {
    const io = std.testing.io;
    const dir = try std.Io.Dir.cwd().openDir(io, "tests/sm83-ssts/v1", .{});
    const allocator = std.testing.allocator;

    // load test .json;
    // for test in test.json:
    //     set initial processor state from test;
    //     set initial ram state from test;
    //
    //     for cycle in test:
    //         cycle processor
    //         if we are checking cycle-by-cycle:
    //             compare our r/w/mrq/address/data pins against the current cycle;
    //
    //     compare final ram state to test and report any errors;
    //     compare final processor state to test and report any errors;
    const helper = struct {
        fn process_test_file(file: []const u8) !void {
            const parsed = try std.json.parseFromSlice(std.json.Value, allocator, file, .{});
            defer parsed.deinit();

            std.log.err("{}", .{parsed.value.array.items.len});
        }
    };

    const file_buffer = try allocator.alloc(u8, 500 * 1024); // 500 KiB
    defer allocator.free(file_buffer);

    for (0..0xff + 1) |ins| {
        var path_buf: [32]u8 = undefined;

        const file_name = try std.fmt.bufPrint(&path_buf, "{x:02}.json", .{ins});
        const file = dir.readFile(io, file_name, file_buffer) catch continue;
        try helper.process_test_file(file);

        if (ins == 0xCB) {
            for (0..0xFF + 1) |sub| {
                const sub_file_name = try std.fmt.bufPrint(&path_buf, "{x:02} {x:02}.json", .{ ins, sub });
                const sub_file = dir.readFile(io, sub_file_name, file_buffer) catch continue;
                try helper.process_test_file(sub_file);
            }
        }
    }
}

can you find any issues?

[peak widget]

stuck where?

(use a debugger or add log()s to see what the code does)

[compact sage]

its inside a test so my logs arent working

[peak widget]

maybe change test { to pub fn main(init: std.process.Init) !void { and zig build-exe?

[compact sage]

ok nvm its not stuck its just slow af

[compact sage]

there's so many minor inconveniences while using zig

[onyx widget]

those are shrimply the complexities that other languages hide that zig makes you handle in the pursuit of writing better software

[compact sage]

I understand the first part, I don't necessarily see how the 2nd part holds

[onyx widget]

ignoring and abstracting away those complexities is what makes most software un-robust. most of the best software that is robust and stable gets to be that way only after years of manually applying discipline and lessons - of course, zig isn't a silver bullet to achieving this, but it outlines the areas where such discipline will be needed from the outset

[compact sage]

there are many things that you can abstract away and never have to worry about them

[onyx widget]

the most basic example is memory allocation

in basically most languages, memory allocation is basically shuffled under the radar

even in C, the manual memory management language, basically mostly treats it like it can't happen by default

even most of the best C codebases probably started with such an assumption, and had to manually evolve to handle those failures gracefully

[compact sage]

who is ultimately zig for?

[stone jewel]

people that want control over their program

[onyx widget]

systems programmers, and people who like writing robust software in the same way systems programmers do

[inland blaze]

People who like C/C++, but don't like C/C++

[stone jewel]

Wouldn't say that

[compact sage]

I want a hobby language to make cool stuff with, I make stuff gaming adjacent so I want performance, ease of use and easy portability across platforms

[stone jewel]

Not everybody here like or know how to program C or C++

[compact sage]

I don't like C/C++ I find them quite primitive

[onyx widget]

ease of use is kind of relative

I find zig very easy to use

[compact sage]

also the documentation sucks guys

sorry to say

it's like, so bad

[onyx widget]

I mean, no apologies needed, it does suck

[inland blaze]

Heh

[compact sage]

compared to rusts docs

[onyx widget]

we are aware of this

[stone jewel]

We are aware

[onyx widget]

it's basically the top 2 complaints

from beginners and veterans

[stone jewel]

And there is not much that can be done with the language moving

[compact sage]

I spent so much time manually figuring out how to read a json file

[onyx widget]

yea

again, we know

we've heard it a billion times

[stone jewel]

To be fair, enter into json.zig and read the code

no fr

[inland blaze]

I know but it somewhat represents me hehe, I find Zig a middle point between Go, Rust and C

[stone jewel]

Read the Source

Test usually tell you how to use the thing you need to use

[onyx widget]

in another sense, zig is for people who are comfortable with re-inventing the wheel (though without actually obligating you to do so), and reading the source code for what you're using (which it makes much easier to do compared to C/C++ and Rust)

[compact sage]

I like the rich type system of Rust, the way you can guarantee so many things at compile time, you never have to even think about it at runtime.

[onyx widget]

you do have to think about it at runtime

the idea that you don't is wildly incorrect

[compact sage]

It's not gonna be unexpected

anyways your code can fail is always explicit in Rust

[onyx widget]

the static guarantees model a subset of your program's invariants

[stone jewel]

Rust only promises you that your code takes that shape (In that sense any type system can expres this with more or less pain) and that their memory safety guarantees are correct

The runtime invariants are still for you to handle

[onyx widget]

nope, allocation failure is almost always covered up, and failures are often swallowed with unwraps and expects

[stone jewel]

including panics and the sorts

[compact sage]

unwraps and expects are an explicit opt in by the programmer that "ok I can crash here idc", and easy to find out when it does

[onyx widget]

integer overflow is also implicit - and in the likely event zig gains ranged integers, even arithmetic in zig will only be able to fail explicitly, vs in rust where it is implicit

[onyx widget]

okay, by that logic all failures in zig are exlipict too, so?

[compact sage]

zig doesn't make it as easy as rust to do it so

everything is manually imperatively done

[onyx widget]

Because rust hides more than zig

[stone jewel]

Zig doesn't believe in automagic

[onyx widget]

Because rust is less explicit

[compact sage]

obviously both are turing complete languages, you can do anything in anything. But the type system of Rust is far far superior by default

[onyx widget]

Not for raw pointers

[fierce sage]

fr

[onyx widget]

Zig excels by far in any endeavour that requires unsafe wrt type systems

[compact sage]

I don't think 90% of people who use rust have to deal with raw pointers

for example, I never did, in any of the applications i used

[onyx widget]

Sure, hence they have different audiences

Rust seccludes systems. Zig embraces them

[compact sage]

you model the reality of your problem in the way Rust wants it

[onyx widget]

You can still only model a subset of it

You must still evaluate the actual behavior at runtime

[inland blaze]

Just like Ada/SPARK

Safety yay

[compact sage]

obviously not everything is runnable at comptime

[onyx widget]

I mean in the sense of what you can model

[compact sage]

but you can guarantee how those runtime systems will interact at compile time

[inland blaze]

Same, I really want to contribute to both docs and the web docs mostly

[onyx widget]

In order to perfectly model your program in the type system, you would have to write a finite state machine

[inland blaze]

The one feature I really to see is the one by Mitchell, for multiple or descriptions on doctests

[onyx widget]

And model your program entirely at comptime

With tne runtime merely being a mirror of it

By this fact, rust does not guarantee any logical correctness, only the specific invariants you care about

[compact sage]

I just don't see the pros I gain from using zig, are that worth it compared to the cons of not using rust.

[onyx widget]

Like I said, different audiences

If I used rust, I would largely be programming in unsafe, which is just not worth it compared to using plain old C

[stone jewel]

There is this I heard once in my doom scrooling, it goes along the line of:
"The major burden of knowing magic is that there is no longer moment of quiet wonder, or moments of luck, you got to manage it yourself"

[fierce sage]

well, you forgot one important thing, and thats lack of experience in writing Zig, its easy to judge language you don't properly know

learning zig is ruff

[compact sage]

yeah I am just judging it as a newcomer, there's like so much friction trying to learn zig

[fierce sage]

and indeed not super welcoming, as best src is source code anyway

[compact sage]

interacting with anything outside zig with zig is super tough

like io and files and stuff

[onyx widget]

If we're talking about friction to newcomers, I don't think rust is earning any awards there :P

[compact sage]

atleast with rust, the docs are great

[inland blaze]

Aside that, I like to consider the backing each language had, Rust had a whole Mozilla and team of research, and it's already stable. Zig on the other hand it's purely on Andrews vision and community.

[onyx widget]

Again, pre-1.0 language. Im certain the rust docs pre-1.0 were nothing to write home about either

[compact sage]

also not to mention the zls lsp is not that good, it doesn't show literally most of the errors

[onyx widget]

Can I ask, what is your point here? Why have you attempted to learn zig when you have near zero enthusiasm for it?

[fierce sage]

i would refer to tutorials or guides maybe as docs are not really that bad, you can search any function and check what it even does or check how its used in std

[onyx widget]

You know it's pre-1.0, but seem to expect a 1.0 experience. Seems like misaligned expectations

[compact sage]

I want to learn zig, I find rust has a lot of stuff that I like but a lot of features I don't use, and it's a very complex language. I was attracted to Zig because I thought it was a very simple language with a very small set of syntax and features you need to know.

But my learning process has been full of friction and hurdles trying to the even the most basic stuff like reading a file or printing to stdout

[inland blaze]

Same dilemma I had with all Rust, Go and Zig

[onyx widget]

The language being simple means you do have to do more work

[compact sage]

but i find it not so simple actually, it has so many builtin functions, that increase the language complexity a lot for me

[onyx widget]

Fewer abstractions between you and the reality of the code means you become the master of orchestrating what other languages would for you

[inland blaze]

More than simple I find it verbose/explicit

Which is entirely Zigs goal

[stone jewel]

Found the damn quote:

“Look, a shooting star!”
“I’ll pass.”
“What?”
“Wizards can’t wish on shooting stars. Or anything else, really.”
“Why not?”
“That’s how it works. The price for learning magic is that you become responsible for your own magic. No more lucky breaks, no more synchronicity, no more spontaneous moments of quiet wonder – you have to do it all yourself. And in exchange, you get to shoot fireballs out of your hands.”
“... was it worth it?”
“Fuck yes.”

Thanks tumblr

[onyx widget]

Not really. Compared to other languages, it has relatively few, it's just that most languages hide them. Zig makes them explicit.

Hell, even Rust's format syntax is a builtin, whereas zig's is userland

[fierce sage]

well first 12h were tuff for me, once you get into it its not that bad tbh, i never used lowe level language before but the concepts in zig are pretty straightforward and simple compared to C++ and even Rust

[stone jewel]

You can build your own std, and is what big projects usually do (And some crazy people)

There is nothing magical about std

[inland blaze]

Zig Boost

[coral violet]

And a lot of zig builtins are just things that other languages provide on the std in less optimal ways like @abs

[coral violet]

As far as im aware you cant even replicate it in user land there

[onyx widget]

Even those are often secretly intrinsics, with the compiler explicitly recognizing them and replacing them with its secret intrinsic

[ancient marten]

In modern CPUs these are often single instructions so it makes sense to provide them as first class citizens

[onyx widget]

You maybe could with proc macros, but that's ass

[coral violet]

Well yeah, thats the point of them, they cant be part of the std exactly because of those properties

[compact sage]

I think the main issue for me is it's hard to get info on "how do I do X in zig" google is useless for the most part, LLMs too. My only options remain are reading the subpar documentation or ask stuff here and wait for others

[fierce sage]

indeed

i agree with that

[stone jewel]

Mostly true.
I enjoyed learning zig without google

There is the langref, there is the code

Figure it out

[onyx widget]

Yeah, that's pre-1.0 lang experience, esp today. We've all been through it, and some learn better with different ways. I just read the langref in a few days and rawdogged it for a week

[stone jewel]

If you want an LLM to do it, I do recommend you to get a local one read your zig std and ask it to research it

[fierce sage]

tbh its ruff, but after 12h of zigging you start anyjoying it trust me, maybe start with simplier projects or something

[coral violet]

You are looking for the wrong thing, you shouldnt ask "how to do x" you should ask "how does x work" and actually learn the concepts, once you do, zig cleanly maps the ideas out for you to use

[stone jewel]

Took me 1 month doing a GBA game that I stopped to learn zig

[compact sage]

I feel like the rate at which I can learn zig is being limited by a lot of external factors outside my control.

With Rust I learnt it pretty fast, because the linters are great, compiler error messages are state of the art. and LLMs work well for the most part and docs are also pretty good.

I know "Zig isnt 1.0" etc but just stating my experience

[ancient marten]

I think it will be good for you in general if you keep going. You can learn most of Zig from just the language reference, the stdlib docs and some digging in the code. You'll learn to work with fewer resources which is important

[onyx widget]

Well, depepends on how you measure. I obviously wasn't an expert after a week

[stone jewel]

lol, tbf, true

[fierce sage]

maybe that looks like it but Zig has verbose error messages, i think you just lack the docs you are looking for

[coral violet]

Zig's moto "Favor reading code over writing code" very much applies here

[stone jewel]

I think your method of approaching it is the one stopping yourself 😅

[onyx widget]

Yeah idk Zig's error messages are pretty good today

They used to be kinda crap

[stone jewel]

0.7...

[onyx widget]

But now you just need to read them

[fierce sage]

and after all that, my BinarySerializer is smaller than same code written in JS 😭

[coral violet]

There are still some odd balls out but they will eventually get addressed

[onyx widget]

A bit before my time I tnink

[onyx widget]

Yeah, few n far between

[compact sage]

yeah I don't have trouble with language features a lot. It's mostly figuring out stuff like stdlib, builtins, and allocators and pointer related stuff

[stone jewel]

lol, it didn't improve much until a few ver ago

[coral violet]

I have my own binary serialization and it cant even map to js properly (language with no enums/unions and no proper integer formats)

[stone jewel]

builtins are on the langref
Allocators and stuff is a conceptual thing https://zig.guide/standard-library/allocators/

https://www.youtube.com/watch?v=vHWiDx_l4V0

Oldie but useful

[onyx widget]

A damn classic

[coral violet]

Zig SHOWTIME is still a rly good source for concept explanation, wish they made more

[compact sage]

oh this is good

[ancient marten]

Not Zig but also helpful(from the creator of Odin) https://www.gingerbill.org/series/memory-allocation-strategies/

[stone jewel]

Sad his troll ass just comes to meme nowadays xD

[stone jewel]

Nothing changed <3

[onyx widget]

Eh, he did his part

[stone jewel]

I know, I am memeing

[compact sage]

stuff like reflection and having to use it for generics is very new to me, I have never used stuff like that in any language

it feels very hacky, seeing a language refer to itself

[stone jewel]

Ruby does that, and does rust

Well

for metaprogramming

iinstead of Generics

but still

[compact sage]

macros kinda have their own language, proc macros work with the token and ast itself so it feels hacky to me somehow

idk its just what I am used to i guess

I do not like macros in rust a lot, proc macros tho are very cool

[stone jewel]

Ruby reflects on itself and you can create generics that way =3
is indeed just different

[compact sage]

since you can basically do very cool stuff like embedded html/SQL etc and validate them at comptime

[coral violet]

C++ can have reflections if you really want to
Lets not even start on functional languages too

[compact sage]

btw, how can I convert a u16 to a packed struct(u16)?

[stone jewel]

bitcast

[ancient marten]

Zig is actually pretty robust at reflecting, it's just that it makes no effort to try to hide any magic from you, so you end up with the "guts" of fancy generic code exposed directly to you. Other languages hide it away

[stone jewel]

const data: u16 = @bitCast(packed);

[coral violet]

Why would you validate sql at comptime? Just create the statements at startup and the db will do that for you, its such a waste of compute to do validation on top of validation on top of validation for no reason at all

[stone jewel]

And is slow because sql is a weird lang in itself

[coral violet]

And if you are mergings strings instead of using statements you are just using sql wrong

[compact sage]

oh ok, it can just derive the type too

[compact sage]

not only syntax validation but it can do schema validation, so that your complex query actually match up with the table schemas

[coral violet]

not to mention that btw, sqlite supports dealing with raw pointers, good luck doing comptime validation on that

[coral violet]

A sql table is a schema wtf
Did you by chance come from the js world? That would explain a lot

[compact sage]

the main benefit of this is rust-analyzer can just hints and errors while writing code. You don't have to compile or run your sql engine to figure out when some large query you wrote went wrong

[stone jewel]

That is just asking for problems imo

[coral violet]

You know you can just use .sql files and use a sql lsp right?

[compact sage]

I am unable to explain it you properly, you should take a look at the sqlx crate in rust

[onyx widget]

yeah am aware of that package, I wouldn't be comfortable with my tooling running directly to interact with an arbitrary database automatically

[stone jewel]

You should if possible do:
Bring data -> Transform it into your program domain data -> Deal with your own data -> Send message to something that will insert it or deal with the interaction on your data/db

[coral violet]

Not to mention most sql lsps allow for testing queries on the fly with ide shortcuts

[compact sage]

but I don't need to, the rust compiler itself can validate my inline sql queries

[stone jewel]

That's so dirty to me ugh

[coral violet]

I guarantee you i can write queries that would fail inline validation yet work perfectly fine in sqlite

[onyx widget]

whatever, no sense arguing about it. some people like control over their tools, and others like em to run wild

[stone jewel]

Yea

[compact sage]

I mean if you had something like rust-analyzer you understand why its beneficial

[onyx widget]

I have used it

[compact sage]

and also not using an ide

[onyx widget]

rust analyzer is quite a piece of technology

[coral violet]

You dont need it; its a bandaid for bad development practices

[onyx widget]

I just hate using rust

[stone jewel]

x2

[onyx widget]

and think that the things rust does are anathema to what I value

[stone jewel]

but anything that is a bandaid for bad practices is bad software for me

(Not rust analyzer itself, but things like in-code validation of other languages...)

[coral violet]

The biggest downfal of rust was it getting so web-piled and doing all the same mistakes and awful practices those people do

[compact sage]

what? an lsp?

[coral violet]

Inline validation for external languages that have their own way better tooling (with no impact on compilation speeds either)

Especially given that just because a sql query is valid in mysql doesnt mean its valid in postgress, the rabbit hole of sql is so big there is no concievable way that rust's inline checking actually works properly

[compact sage]

I just told you rust gives you the tools powerful enough to do that if you want, you aren't forced to use it?

[coral violet]

So powerful they wont even work for real use cases

Not to mention they will explode the slow compilation speeds to a whole new magnitude for no reason at all

[compact sage]

without proc macros, stuff like clap and serde won't be so good at all

[coral violet]

Again, i will just stand by this and go use my time on something more productive

[compact sage]

I mean is the downfall in the room with us? to me it seems like it's one of the fastest growing languages out there

[onyx widget]

I think they mean wrt the quality of software

[coral violet]

Actually, last take:
Serde is garbage, and any lib that tries to be like it is just worthless. Its literally web mentality at its peek and doesnt fit in a native performance-driven environment

[compact sage]

have you used clap?

[onyx widget]

sure have, and no thanks

[stone jewel]

https://github.com/OrlovEvgeny/serde.zig / https://github.com/Hejsil/zig-clap

Still no thanks

[onyx widget]

I know it may be hard to grasp, but just as much as you seem to think we don't understand your perspective, you seem to lack any grasp of ours

[coral violet]

Using text protocols for native development is the stupidest shit ever and i hate how much rust is polluting the space with it

All the "fast text parsers" can be beaten by the most lazy half assed binary protocol implementation

[inland blaze]

If not zig clap, what do you guys use, if you do

[coral violet]

Just do what zig does, StaticStringMap and handle it manually

[stone jewel]

zig std.cli nowadays, zig-args historically

[inland blaze]

There's a cli namespace?

[coral violet]

Still have to look at zig.cli, heard that the progress stuff is amazing tho

Or is that std.progress?? I forgot (the thing they use for the build system)

[inland blaze]

So basically

No external library

Just strings

[peak widget]

std.progress is zig's fancy progress "bar"

[compact sage]

I mean I get it, you guys want things to be as barebones and handwritten as C, but then I don't know how Zig is a modern language, apart from having some stuff like Optionals and Err sum types

[peak widget]

unrelated to parsing CLI arguments

[stone jewel]

well is args

args just works so it's easy to handle it

[inland blaze]

Oh

[coral violet]

Yeah, there is no need to, unless you need more than 40 options or some fancy graphical stuff libraries will just tie you to their constrains and be generally slower

[inland blaze]

I was wondering for external library mostly

[onyx widget]

we don't want = C, zig approaches the problems tackled by C from first principles. in some cases that means coming to the same conclusions as C, but in many other respects it means reaching novel conclusions and approaches to software design

[coral violet]

bun had a lot of issues because they were using clap and couldnt do the features they wanted to (this before the AI slop, like 0.3 days)

[inland blaze]

On Zig?

They were using zig clap?

That's so silly

[coral violet]

Yep, they were in the early days and instantly regretted it, tho honestly that seems to be the entire thing about bun, ship as fast as possible and regret everything later

[compact sage]

I mean if Zig is just C+ then idk why people wouldn't just use either C++ or C, with their 40+ years of libraries and knowledge base

[stone jewel]

C++ sucks

[coral violet]

Serde, Clap and a bunch of web-driven libs are well within that mentality

[stone jewel]

As someone that uses it for fun

[inland blaze]

I don't really get serde

[stone jewel]

C is good, but C sucks to write modern software in

That's just it

[inland blaze]

I see a point in Rust via macros but

[onyx widget]

C++ sucks, and C is chained by its baggage and committees. that aside, that's literally not even what I said. "tackling the same problems from first principles" does not evaluate to "it is C+"

[inland blaze]

I don't understand how is it beneficial in Zig

[stone jewel]

My C nowadays looks like zig, why not use zig?

[halcyon marten]

I work professionally in C++, Zig's toolchain is just a dream to have compared to what the ecosystem in C++ provides

[stone jewel]

You seem to work in black and white my dear, we are working a bit in the middle

We don't think zig is perfect, but it accomplish exactly what we expect

[onyx widget]

a 3D middle

it's not like there's a spectrum that goes C, C++, Rust

[stone jewel]

that's what keeps us comming back

[coral violet]

So let me get this straight.
You complain that zig has "to many builtins" yet you are saying that people would prefer to use a language that has 5x the keywords and builtins? Im failing to see the logic here.

Zig is lower level than C while providing some high level abstractions (like defer) that C doesnt, it also doesnt have some pitfalls that C does (goto hell) and is exicit about its intent; thats what makes it modern and a C alternative

And on the topic of libraries; all C & C++ libs can be used seamlessly in zig with a simple translateC step on the build file

[onyx widget]

yeah, putting all of your criticisms together mostly just makes it sound like "Zig isn't Rust"

I'm sure you don't intend that

but that's pretty much where this is heading

[halcyon marten]

nitpicking, you can't translate C++ libs without a C interface available first

[inland blaze]

I feel you are a bit forcing yourself into Zig

[coral violet]

C sucks to write any complex software in especially if your program is heavy on control flow or matching

[stone jewel]

Nah, I think you can write complex software, it will just be difficult

[coral violet]

Yes but it can be used seamlessly (you dont have to deal with the pain that is compiling C++ libs yourself)

[onyx widget]

if for every point about zig you just say "but rust does it this way which is good", then you should just use rust. you shouldn't use zig just because it conceptually represents an appealing aesthetic called "simplicity"

[lofty bear]

oh nice, this thread looks like an average quick question in #zig

[coral violet]

I didnt say you cant, i just said it sucks

[halcyon marten]

eh, I wrote a Zig binding for a C++ ish library, I don't agree with "can be used seamlessly"

[compact sage]

my main reason for using zig is just that it's a "simpler" language that lacks a lot of features, which maybe forces me to learn new stuff and implement some stuff from scratch, but I am contemplating why not just learn C at that point

[coral violet]

Hmm i think i see what you are talking about, but i cant think of another word to describe my experience with it tbh

[stone jewel]

go for it

[onyx widget]

well, learning C would very likely make you appreciate many of the things Zig does :P

[stone jewel]

you will either love it, or learn why we stay here xD

Or both!

(Or neither but that's the bad end)

[compact sage]

my main deterrent for C is the lack of generics and no proper build system (I hate cmake)

[inland blaze]

I saw you wanted to try to build RE2 with Zig, did you manage it?

[coral violet]

Zig forces you to learn how your machine works and what it is actually doing under all the abstraction layers and gives you all the tools to explicitly make it do what you want it to do not what the language secretly wants it to do

[lofty bear]

their bio is fitting for this decision

[onyx widget]

that is fair, CMake does suck. although, you could always use build.zig :P

[halcyon marten]

nope, didn't even try, I don't have a usecase for Regex in Zig

[onyx widget]

but you should try it anyway

[stone jewel]

Use zig as the build system

[onyx widget]

lacking generics is a good lesson in the very fundamentals of abstraction

[stone jewel]

Yes

Or you can use their Generic Keyword, is so nice lol

[onyx widget]

very quickly forces you to learn type erasure and writing agnostic algorithms without a compiler to copy paste your code

[inland blaze]

Sob, I was gonna ask how did you handle Abseil in that case, thanks still

[stone jewel]

or learn how to do OOP in C

that's a nice lesson

[coral violet]

good, lets keep regex away from zig

[stone jewel]

There is a zig re2 like lib

[onyx widget]

bespoke lexers >> regex

[stone jewel]

agreed

[inland blaze]

What's wrong with regex now

[stone jewel]

I should make a post about it

[compact sage]

I mean without generics you just write macros I guess, and that's just wild foot shotgun territory atp

[stone jewel]

Nothing, but bespoke lexers are the better solution

[onyx widget]

well, not necessarily just macros

there are many avenues of abstraction

[stone jewel]

you can use vtables and other abstracions

[onyx widget]

type erasure and agnostic algos among them

and good old DOD

[stone jewel]

Message Passing

[onyx widget]

yems

[halcyon marten]

I had a look, decided it's not worth it, moved on and be happy

[coral violet]

Ungodly slow, leads to bugs without you even noticing them (cloudflare would know) abd when its present people want to use it for everything

[stone jewel]

Slot based systems

[coral violet]

I'd rather waste a day writting a parser for my use case than touch regex ever again

[stone jewel]

Command based abstractions

[onyx widget]

which, to be clear, you can also learn all these things in zig. but if the point is to learn new lessons through restriction, C is certainly the ultimate logical conclusion

[coral violet]

Personally, i think Zig is a better teacher than C for low level as you actually learn about managing memory, C just hides it all away in its functions

[onyx widget]

you certainly seem to be capable of committing yourself to gritting your teeth and learning a language you think isn't that beneficial, so if you're going to do that, I do really suggest trying out C

[onyx widget]

this is true, but C forces you to be more creative in certain ways to write general purpose code

because it sucks

[compact sage]

the main thing I need for a perfect C is rust enums and generics, that would be the perfect language for me. a good build system would be nice to have too

[halcyon marten]

merely the fact that Zig has different pointer types, that's enough to force people to think about pointer better than C

[onyx widget]

is the goal learning or finding a perfect language?

[stone jewel]

There is no perfect language, something will always stick out

[onyx widget]

because earlier you said you were chiefly using zig to learn

[inland blaze]

There's no perfect language

[compact sage]

I am just theory crafting

like perfect for what I am looking for

[inland blaze]

So me

[coral violet]

True, you can still do it, its just a completely different beast new people will never want to touch

[stone jewel]

Since we are at it, try vale, I do wanna see someone testing it

[inland blaze]

Crystal

[onyx widget]

lmaooo

kaezrr we're apparently giving you homework

[coral violet]

Pointers not being optional by default is a godsent, you can actually feel safe when using them and inherently just treat them like any other type (excluding its potential mutability/side effects concerns that is)

[compact sage]

well yeah that too, but ultimately I just wanna write cool software that's easily portable and efficient.

[inland blaze]

Go

[onyx widget]

well, zig certainly gets the easily portable and efficient stuff down

[lofty bear]

learn ATS for bulletproof low level lang

[stone jewel]

Ada is another bulletproof one

[lofty bear]

but is it C level?

[stone jewel]

yea

[coral violet]

Zig is the best for that, it just takes some elbow grease and willingness to learn how computers work and drive them to do what you want without hidden magic or handholding

[stone jewel]

They have native memory pools that are basically arenas for memory sections @lofty bear

[inland blaze]

Spark

[compact sage]

Also I am doing it mostly as a hobby so it has to be fun and kinda approachable, good tooling and dev ux helps in that

[coral violet]

Good tooling will never happen in a pre 1.0 language; zls is pretty much worthless with generic code.
DX is very subjective and depends on how you think about software

Some people think anonymous functions & colosures are good DX, others hate them and their hidden magic properties

[lofty bear]

ruby apparently is DX dream until you wake up in macro hell

[inland blaze]

Java 😋

[compact sage]

DX that strikes a good balance between convenience but without affecting the end result. For example not languages like javascript that trade dx for everything

[lofty bear]

how come most graph related tools are written in Java, annoying

[compact sage]

what about jai

[halcyon marten]

i like anonymous functions (no captures, no fancy features, just purely inline function definition)

[inland blaze]

PlantUML

[lofty bear]

is it even released? i don't look at closed source langs

[coral violet]

Its still subjective, for me and i imagine most people that like and use zig daily it has amazing DX and maps perfectly to the way we think.
But for you it might not; just have to accept it and try odin instead

[coral violet]

Just purely for inlining i also dont mind them but depending on their implementation they can be hard to debug (im pretty sure this was a point Andrew brought up against implementing them)

[compact sage]

nope it's in closed beta

[coral violet]

Try odin, maybe a rust piled brain will like it more given it has concepts that resemble traits and also has explicit function overloading

[inland blaze]

C3

[onyx widget]

odin and C3 are pretty neat choices too, yeah

both a bit more C-spirited than Zig

but also go a bit further in what you might call "modernization"

ie Odin was mostly developed for gamedev

[inland blaze]

Neater than Zig tho?

[onyx widget]

not imo

but to each their own

[halcyon marten]

right... but struct {fn f() void{}}.f is fine...

[onyx widget]

I don't ever write that, I just name the struct

[coral violet]

Odin especially with how they do function overloading its actually pretty neat and probanly the best implemenation of that feature i have ever seen and in a way kinda resembles what we can do with comptime

[compact sage]

odin does too much, C3 I have never heard of

[onyx widget]

const helper = struct {
    fn foo() void {}
};
helper.foo();

also lets you write multiple of them in there

[onyx widget]

odin does too much?? bru

[coral violet]

Well that is named properly which goes against the definition of anonymous but yeah im on your side there

[coral violet]

What? Odin is more barebones than Rust and is far more explicit in its overloading syntax

[compact sage]

no like it has a pretty huge stdlib right

has sdl and everything directly in the stdlib or something

[inland blaze]

vendored libraries

[coral violet]

Thats because it includes things like sdl and raylib on its std but its an std you dont use it all and like any decent language it doesnt compile it all into your program

[inland blaze]

it's trying to be like Ruby i guess

joy of programming goal type

[compact sage]

it's also very game dev domain focused, I don't want that

[coral violet]

Odin is to gamming what Go used to be for networking (Go is turning into a shitshow lately)

[inland blaze]

https://c3-lang.org/

[lofty bear]

then time to pull off Andrew's trick and write yet another language

[coral violet]

I remember that my entire reasoning to not use this language was as simple as c++ ptsd

[inland blaze]

I still admire the amount of code quality checks it has (Golang CI stuff), just some, not all of course

[onyx widget]

it's very C inspired, so obviously you get all the suckiness associated with that, but ey

fn void main

[coral violet]

Go's tooling is indeed amazing but the language is starting to go south sadly... the devs are not standing on the principles the language was started on

[compact sage]

also like I want the language to be somewhat popular and have a community around it, otherwise I can't really discuss stuff or ask for help

[onyx widget]

any language you'll hear about has at least some community around it

just depends on the degree to which that is the case

[coral violet]

Even OCamll has a community

[compact sage]

first time hearing about c3 tbh

ocaml I have heard a lot in the functional programming groups

[inland blaze]

Scala, Kotlin, Gleam, Elixir

[onyx widget]

you've heard about it now

[coral violet]

I just see gleam the way i see mojo, not a language, just a not so useful extension to another language

[inland blaze]

Poor 🔥

[compact sage]

functional programming must be the anthesis to everything you guys stand for isnt it, the most abstracted abstractions of all abstractions

[inland blaze]

why doesn't zig work with .z

[onyx widget]

generally speaking, yes

can appreciate many of its concepts

hell, a lot of modern language features are inspired from FP

but the core values of FP are quite antithetical to zig yes

[inland blaze]

You should try F#

[coral violet]

.z is already a taken extension in unix systems

[inland blaze]

boooooooo

[onyx widget]

(the features I refer to are stuff like optionals and error unions, with operators that make them very akin to monads)

[compact sage]

yeah like personally I really like functional programming, I think if there weren't any performance detriments, any pure FP language would be my ideal hobby language for building stuff

[coral violet]

The only thing i can agree on with the entire FP movement: keep your functions as pure as possible

[onyx widget]

I mean, I would ask, what's really the harm in the perf cost if what you're designing is primarily hobby stuff?

[zinc stump]

What was that FP lang with the zig backend called?

[inland blaze]

Haskell

[onyx widget]

pf

man I didn't know they rewrote haskell in zig

[compact sage]

it makes a lot of the stuff I build have unacceptable performance

[onyx widget]

like wot

[lofty bear]

GHC's haskell has relatively low performance overhead, it's just harder to reason about algorithmic complexity + their toolchain is large

[onyx widget]

if'n you don't mind me asking

[compact sage]

like game engines, emulators, etc

[onyx widget]

fair enough

well, if you want the performance, you do also gotta accept the restrictions that come with it

[zinc stump]

Write your own dream language

[coral violet]

The entire issue with haskell is that you can override symbols
You can make + mean literally anything globally (its an even worse system than overloading)

[inland blaze]

I feel this became a

[lofty bear]

forth is very FP like and low level

[inland blaze]

#programming-discussion more than understanding Zig now

[lofty bear]

yea, the language extensions are aids

[onyx widget]

tbf, in this sense it's akin to lisp, where the symbols are not very strongly tied to the language

[inland blaze]

Thread closed because too much heat idk me no english

[coral violet]

If you want modern FP with decent performance, Elixir is the way (tho its more geared for networking than anything)

[zinc stump]

philosophical discussion about as to what @compact sage is looking for in zig, and in any programming language in general?

[compact sage]

I was basically looking for Rust--

but feel like Zig is C*

[zinc stump]

For me personally, zig is that rust--

[lofty bear]

it get's worse with language extensions, where they can introduce whole new syntax rules. so to read arbitrary haskell code, it is not enough to know the base language, but you need to know about how each language extension affects the code

[compact sage]

I mean I still haven't given up on zig, I will finish my current project before ultimately deciding if its for me

but yeah, I will complain here

[onyx widget]

that's fine, just also expect us to pushback :P

[compact sage]

that's fine, most of my complains are due to being unfamiliar with this stuff and seeing it for the first time

[onyx widget]

imdeed

[zinc stump]

If you find zig is not for you, try C, and if you also don't like that, I suggest you try zig again and see how you feel after having experienced C!

[compact sage]

I mean I already know the annoyances of C, I would rather learn zig than deal with them

[onyx widget]

knowing C certainly does elucidate many of Zig's decisions

[compact sage]

I learnt C as part of my college course, never built anything serious in it

[onyx widget]

well, I would personally argue that building something a bit more serious (ie requires sitting down and thinking about how to design stuff without necessarily having a direct answer simply available to you) is an important part of fully learning a language

[compact sage]

btw, when I do !void as the return type, how does zig know whats the error type

[onyx widget]

but fair enough

it analyzses the function body, and based on the runtime code, puts all the possible errors together

ie, if it sees you do return error.Foo in one reachable branch, and try foo() on another function with an error set error{Bar,Baz}, the IES would be error{Foo,Bar,Baz}

[compact sage]

oh it creates an error type on the fly

[onyx widget]

"on the fly"-ish

it is lazy about it

in reality it doesn't resolve the error set until it has to

ie, it can't do it when you declare the function

[compact sage]

errors can be any type or have to part of an error enum?

[stone jewel]

and only works with functions with bodies (so no over function pointers)

[onyx widget]

it does it when you query info about the function type, and when you call it

[onyx widget]

errors gotta be an error set, yeah

[stone jewel]

errors are a single big set with all possible errors

[compact sage]

so I can't just return a number let's say? as an error?

[stone jewel]

Error types are just subsets of said set

[onyx widget]

non

[stone jewel]

For that we have diagnostic pattern

[onyx widget]

just to clarify something: errors and error unions are not like rust's result type

[stone jewel]

https://ziggit.dev/t/applying-the-diagnostics-pattern-in-practice/3042

[onyx widget]

they are more like a tool for controlling control flow, and distinguishing between the happy path and error path

[compact sage]

so like in rust the result type can have anything as an error right, is that not possible in zig

[stone jewel]

I think it marks error paths as cold too iirc

[onyx widget]

non, like I said, they don't serve the same purpose

[stone jewel]

See related

[onyx widget]

I thought this too for a long time, and was corrected by mlugg

I swear it must have been the case a long time ago in an older version

[stone jewel]

Then I remember mlugg saying it didn't V=

[compact sage]

oh that's pretty complex

[stone jewel]

and retro-actively said, it doesn't matter

[stone jewel]

Simpler than it seems

[coral violet]

There is always a first time, and if you aint ready its gonna be painful to take it in

[stone jewel]

https://github.com/Deecellar/bottom-zig/blob/daddy/src/main.zig#L45-L151

[onyx widget]

if you have more complex data to handle, or something where "this is an 'error' case with more data to deliver and handle", then it shouldn't be thrown away into the error path, and you should handle it like a normal path. or, if it really is just part of the error path, then using the diagnostics pattern is the most appropriate thing to do

[coral violet]

I need to do this for my markdown parser...

[onyx widget]

dewit

[stone jewel]

is a pattern for "Need to push something as an error outside with extra data"

[compact sage]

can't the error enum be a tagged union and contain payload data that way?

[stone jewel]

that means you have used all your correct resources and need explicit user handling

[onyx widget]

non

it doesn't make sense with the way zig has designed them

if it was like that, you couldn't simply try errors

since all errors would need to be distinct and closed sets

[zinc stump]

Can always use an out pointer to get some more information

[coral violet]

Still got some features to implement gonna do it afterwards (the entire goal is to no stop parsing on errors so diagnostics will need some thinking)

[onyx widget]

but the way they actually work is that all error sets are just subsets of the global error set (which can be referred to as anyerror)

it's very akin to the C approach to error codes

in fact that's kinda what andrew modelled it based off

[coral violet]

No, errors are meant for control flow not to pass data around

[compact sage]

also how do you guys debug your zig programs

[stone jewel]

gdb, lldb, and prints

[onyx widget]

printf debugging most of the time, every now and then lldb

[stone jewel]

depends on the kind of bug

[zinc stump]

There's an lldb fork that adds better zig support iirc

[onyx widget]

can't beat the classics

[coral violet]

Pain & suffering when dealing with wasm

[compact sage]

lldb and gdb which one is better? idk how to use both

[stone jewel]

I never had much problem debugging wasm

[coral violet]

Debugging wasm panics on the web is actual hell on earth

[zinc stump]

std.debug.print + lotta tests helps

[stone jewel]

both are around the same ballpark

lldb can be better with zig thanks to llvm

[coral violet]

I had a rant about this yesterday in #gui-dev

[onyx widget]

lldb has usually worked better for me

gdb is always kinda finnicky

[compact sage]

wait but didn't zig ditch llvm or something

[onyx widget]

no

[stone jewel]

Kindof

[coral violet]

Can say lldb works rly well, just can be a pain to setup in some environments

[stone jewel]

The true answer is NO

[onyx widget]

it's divorcing it from the codebase, but zig will always support emitting LLVM

[stone jewel]

The General bit is that the codebase is not dependent of llvm to generate code

But LLVM is the faster backend

[onyx widget]

I love andrew but man, we are going to always have to deal with that damn misconception for years onwards

[coral violet]

And even then, debug symbols are quite different from emitting full llvm ir

[stone jewel]

I hate andrew, but man....
Kidding

[zinc stump]

Depends in what sense you mean :p

[stone jewel]

not compiling ofc

When zig actualy puts nice Dwarf itself, debugging with gdb or lldb will be a as good as the tooling around zig for those tools

[coral violet]

Sadly using llvm seems to be the only way to get crypto/hashing code to not slow to a crawl...

[onyx widget]

yeah

[stone jewel]

Oh and tracy your stuff, adding metadata into your program helps
and for the graphical side, renderdoc

[onyx widget]

we are forced to use llvm at work still

can't use self-hosted at all still

hopefully someday

[compact sage]

for logging, is std.log enough or do you guys use third party solutions

[stone jewel]

( I consider performance as a kind of bug so tracy is technically debugging)

[coral violet]

The same code that takes less than 500ms to run using llvm can take more than 6 seconds with the zig backend... (for crypto that is) its quite the pain rn

[stone jewel]

I write my own if I need more

[onyx widget]

it's usually enough yeah

[zinc stump]

std.log is very customizable, never felt the need to use something else tbh

[stone jewel]

Only had to for multiple sinks

[onyx widget]

we use a custom logger at work, but that's for a bunch of reasons, like wanting more log level granularity, and wanting to pass around a logger interface thingie that can make scopes required, and also because we do a bunch of IPC stuff that it simplifies the data flow of

[stone jewel]

since multiple sinks is kinda bad in current std.log api

[coral violet]

never use third party libs for logging in a library when using zig.
If you are the final point of the code you can use a lib but ofc one that provides overrides for std.log is ideal

[compact sage]

How do you configure the log levels while running the problem? is there a env variable

[onyx widget]

you override the logfn to something that respects a runtime log level

[compact sage]

is there no cli flag

[onyx widget]

no

[stone jewel]

never print in a library
Make a event pump for errors =P

[coral violet]

You can make your own

[compact sage]

yeah i am writing a binary project

[coral violet]

[onyx widget]

where would it even get the CLI flag from

you are the one writing the main entry point

[stone jewel]

I am not sane, but I am quite the perfectionist

[compact sage]

no like rust has RUST_LOG env variable that a lot of logging crates respect

[coral violet]

Thats not a flag

[onyx widget]

yeah naur, we don't be doin that in zig

and yeah, that not a flag, that's called an env var

[compact sage]

yeah

[zinc stump]

I presume they also want -q and -v

[coral violet]

Environment variables and flags are 2 different concepts and serve different purposes.
But zig doesnt generally introduce things on a whim, you can do it with your own abstraction but there is no reason to when you can make use of comptime and proper build flags for this

[stone jewel]

having a general env variable that your program currently have is a choice... (for libraries)

I don't like personally exposing envs that could be an API that the user can use to implement said logic

[onyx widget]

This is the Way

[coral violet]

I dont like env vars at all, build time flags are superior and more controlable

[lofty bear]

almost at 2k messages, i wonder how much that would cost in LLM tokens

[stone jewel]

Sometimes needed

Like, you want to make a choice between wayland and X11 or Arcan in Linux

(Curse you @lofty bear )

[coral violet]

Yeah its a necessary evil for things like terminal color detection but especially if you look at the web people you will see them passing sensitive credentials via env vars and its just awful

[stone jewel]

you also don't want them on the binary, you want to pass them via a secure network at startup

[coral violet]

Or a configuration file that gets loaded on startup

[onyx widget]

truly

human token-maxing out here

[stone jewel]

That's still an env var in my eyes

and way too insecure

But I use both so

[onyx widget]

yeah, implicit config files only make sense as an explicit choice for an application, not a language's runtime

(and should be overridable)

[coral violet]

Eeh, not really, there have been some vulneravilities caused by exploiting env vars before; with a file they would have been avoided

[onyx widget]

*replaced with other vulns :P

any implicit liabilities can be exploited

anyway

[stone jewel]

that's why I said I would prefer using cloud secrets api, at least there I can blame google ;3

[coral violet]

Well, env vars can be used to escalate permissions, a file cannot if its put in a protected place

But actually, how would you guys load secrets if not via a configuration file?

[onyx widget]

to be clear, I do agree config file is generally better than putting everything in env vars

just don't think it's a silver bullet

[coral violet]

I know its not, which is why im curious to what other ways people recommend doing it

[onyx widget]

the most powerful tool for avoiding the vulnerability in the first place is having keen awareness of those liabilities

[onyx widget]

I recommend doing it with intention, proper documentation, and clear policy :P

and always as a decision of the end-programmer, before it's delivered to the end-user, never as an implicit part of a toolchain or tech stack

[stone jewel]

Using runtime api to read the configs that uses proper secret communication
A file that you have to open with a key
A config file
Env vars

that's my order

I use the second one in my own personal hobby server

[coral violet]

Can you explain what you mean with a file that you need a key to open? (Especially on an environment that cannot make requests to another server)

[onyx widget]

should probably carry on discussion elsewhere

[coral violet]

Good idea

[stone jewel]

Already did

[coral violet]

Ping me in #programming-discussion

[inland blaze]

155 messages dear god let this thread become a new channel already

[analog forge]

It's always good to know C

[analog forge]

😭

[ancient marten]

Odin is actually meant to be general purpose, it's just that it ships with a bunch of libraries useful for gamedev. But gamedev is a very wide domain of programming(consisting of graphics, UI, systems, networking etc etc) so "a language for gamedev" isn't really possible without being general purpose

Bill is working on adding an http implementation to core

we may also see an sqlite module(though he doesn't plan on adding other databases since that would imply creating some kind of cross database abstraction)

[ancient marten]

It's not "domain focused" but it is quite focused on "feel" and pragmatics. Odin feels very nice to use and fits very nicely in my hand

Odin does generally try to nudge you towards a "data-oriented" style though(with stuff like ZII, soa, using etc). But data-oriented design isn't really specific to games either, It's basically the way to write really fast code(see Andrew Kelly's talk on applying data-oriented design in the Zig compiler)

I also personally think it looks beautiful compared to Zig(which is quite verbose)

[subtle helm]

Comments about Odin "being for gamedev" always make me laugh. When you actually look at the language its just a general purpose language. It's got a bunch of types and math built in that happen to be good for game dev, but that's more coincidence than anything. Bill has said he included it because it's the main stuff people want function overloading for. So just build it in.

[ancient marten]

The math stuff is actually a really genius idea. The only reason to ever have operator overloading is to support math types, so why not just add the math types?

You just solve the problem you have instead of creating more problems

[subtle helm]

Yeah I really like how pragmatic the language is. Frankly I would probably lean toward it over Zig except for two things. I really like having access to structs + functions, and Zigs C interopt is just so nice. I don't have to write any wrapper code, just a couple lines in the build system and import like normal.

[ancient marten]

do you mean like methods?

[subtle helm]

Yes and no. Zigs solutions of them just being functions that use the dot operator I really like. So Vec2.add(v1,v2) and v1.add(v2) are equivalent

[coral violet]

zig is going to have more math types in the future so...

[fierce sage]

also .add(v1, v2) if you infer the type

so nesting is really clean

[subtle helm]

That being said, in the case of vectors, I do really wish I could just type v1 + v2. Composing a bunch of functions together gets friggin' old. And I'm only doing simple 2d stuff.

[coral violet]

we will get them soon™

[subtle helm]

"soon"

[coral violet]

yes, before 1.0

[ancient marten]

methods do generally encourage a bit of over-organization imo. Should it be weapon.attack(monster) or monster.hitby(weapon)? Odin is opinionated on discouraging you from over-organizing your code. You just have perform_attack(monster, weapon) without it "belonging" to either type

[coral violet]

in zig it doesnt have to belong either, you just have the option to do it

[halcyon marten]

Zig is ... not opinionated enough?

[ancient marten]

It's definitely not as opinionated as Odin lol

[subtle helm]

I know, I'm aware of the arguments, and I'm not complaining Odin made the choice it did, but for me the upsides outweigh the downsides

[ancient marten]

It's kinda interesting that Odin doesn't have a standard formatter given the design

only odin strip-semicolon

[subtle helm]

I don't know if it's less opinionated. Just different opinions

[ancient marten]

hmm that's also it. "Reusability" is what characterizes Zig for me compared to other low-level languages

[subtle helm]

Not sure I follow. Zig focuses more on reusability?

[subtle helm]

I'd have to write more Odin to know, but I think I always end up thinking along these lines to some degree anyway. I'd just be explicitly passing it as the first parameter all the time lol