c.im is one of the many independent Mastodon servers you can use to participate in the fediverse.
C.IM is a general, mainly English-speaking Mastodon instance.

Server stats:

2.9K
active users

#zig

26 posts16 participants0 posts today

Still learning #zig and #raylib. I know it's not much, but I now have a button supporting different graphics for idle, hovering and presses :D And callback function on click.
I'm still not 100% sure if this is a language I'll stick with, but so far I do like it. Fast compile times and small executables, and a very explicit code!

In #Zig, is it better to hold a slice of small objects and grow it when necessary, or is it better to just hold on to an ArrayList/MultiArrayList?

I guess the use case is important. Want to track the bullets on screen in a little shoot 'em up (Every new engine I try gets a little shmup, ever since I watched @krystman's wonderful pico 8 shmup videos) and figured I'd try for "proper" data-oriented design a la Andrew Kelley's talk.

My assumption is that the (multi)ArrayLists will be more effective at managing bursts of memory, but I figure it wouldn't be _that_ difficult to build a pooling system that allocates when it needs to but re-purposes when it has instances marked "off screen".

Or. . .maybe there's a pool-like system in the std library?

Can confirm that my #Zig-sty-five-oh-two emulator now correctly emulates all of the addressing modes for the baseline CPU. Yes, my friends, that does include the hardware bug with Indexed Indirect addressing on the zero page.

Tests are written, everything is green.

Plus, I have a cool debug viewer for the CPU!

Continued thread

THAT SAID. . .

I can't get #Zig's document generator to generate stuff for all of my zig files. Which, I guess, is fine, I know it's in preview, technically, but. . .ugh. It's SO CLOSE TO AWESOME.

Holy crap, #Zig documentation comments are awesome, too.

One of my favorite parts of the #DotNet ecosystem is the documentation system, where you get XMLdocs for free, and they have a first party tool for generating a docs web site.

For a while, though, I've been lamenting that weird HTML-based DSL from dotnet.

Not only do I not need to use another tool for Zig docs, I get to use MARKDOWN, like the gods intended.

Ooooooooooooh.

#Zig files are, themselves, structs.

This is awesome, and explains some of my confusion around namespacing and stuff.

Also: custom formatters for structs? So nice. Love the member accessing syntax.

Hot damn I haven't been this excited about a language in a few years.

Okay, Ziguanas, is this really the best we can do for "interfaces" in #Zig?

I can't think of another way to do it.

```zig
// The interface
pub const BusDevice = struct {
ptr: *anyopaque,
min_address: u16,
max_address: u16,
readFn: *const fn (ptr: *anyopaque, addr: u16) u8,
writeFn: *const fn (ptr: *anyopaque, addr: u16, value: u8) void,

fn read(self: BusDevice, addr: u16) u8 {
return self.readFn(self.ptr, addr);
}
fn write(self: BusDevice, addr: u16, value: u8) void {
self.writeFn(self.ptr, addr, value);
}
};

// The implementation
pub const Memory = struct {
min_address: u16,
max_address: u16,
physical_memory: []u8,

pub fn new(allocator: Allocator, min_address: u16, max_address: u16) !Memory {
const phys_mem = try allocator.alloc(u8, max_address - min_address);

for (phys_mem) |*address| {
address.* = 0;
}

return Memory{
.min_address = min_address,
.max_address = max_address,
.physical_memory = phys_mem,
};
}

pub fn write(self: *Memory, address: u16, value: u8) void {
self.physical_memory[address] = value;
}

pub fn read(self: *Memory, address: u16) u8 {
return self.physical_memory[address - self.min_address];
}

pub fn busDevice(self: *Memory) BusDevice {
return BusDevice{ .ptr = self, .min_address = self.min_address, .max_address = self.max_address, .readFn = self.read, .writeFn = self.write };
}
};
```

I've been attempting to rewrite some C code for a Wayland client in Zig using only the client API (via zig-wayland's scanner) and for some reason I can't grab the seat name when I set the listener, very frustrating

It's got to be the way Zig handles struct memory, I just don't know how... I doubt I actually need an extern struct but I bet if I can throw pointers around like it's C I'll figure out the rest later 😂
#C #Zig #Wayland

Okay, so, tonight's stream is going to be one of two things:

Me doing codeberg.org/ziglings/exercise

Or Me starting the porting of my 6502 #emulator to #Zig

I'm going to start with the latter, but if I run into any roadblocks I'm going to default to the former.

This will be a temporary thing, I'm just a little burned out on my C# projects right now and need something fresh.

If you'd like to support my shameless pursuance of useless programming language knowledge, head on over to twitch.tv/b4ux1t3 tonight at roughly 8:30 PM Eastern!

#LiveCoding

. . .

That's the end of the post, really. Just want to push the next bit below the fold.

. . .

On a more personal note, the proceeds from my channel are currently being put toward buying a new water heater. So, like, if you wanna help someone out for free, feel free to hop on the stream and leave it running in the background while you do much more important things like, I dunno, sleeping ;)

Additionally, I do have a neglected ko-fi account that I need to revamp: ko-fi.com/b4ux1t3

Generally the ko-fi is supposed to be for my kids' education, but we're making an exception since "hot water" is kind of important.

Thanks for reading below the fold. You are beautiful and worthy, and I hope you have a wonderful day.

Summary card of repository ziglings/exercises
Codeberg.orgexercisesLearn the ⚡Zig programming language by fixing tiny broken programs.

#Zig is the language teenage me would have written if teenage me had been any good at writing languages.

It literally addresses all of the problems I had with C.

Well, so far.