#
GIF
Recent searches
Search options
Administered by:
#zig
22 posts13 participants3 posts today
Well... I went on the deepest of dives today to fix the link error I've been tangling with while working on tigerbeetle-hs!
First, GHC passes `-lm` near the beginning of the linker flags it generates when compiling an executable. Pretty normal.
Unless you're linking a shared object file compiled from Zig.
Zig's build tool chain vendors it's own versions of libc for the various target platforms. When you call 'linkSystemLibrary2` and tell it to link `"m"` and tell Zig that's it's needed... well, it ignores you.
Zig's build tool sees that you asked to link a system library once and it links libc... and nothing else.
All of this means that if you pass `-lm` before you link the Zig shared object, you get a relink error. Because Zig helpfully provides an implementation for the libc symbol (in my case, `sin`) and the linker already has an implementation for that symbol... in libm.
It looks like Zig's tool chain doesn't include any of the GNU library paths in the RPATH of the elf header and so the linker asks you to relink the library against libm... which you can't actually do with Zig's build tools.
Trying out a hack with nix's `patchelf` to add the RPATH's into the nix store for the glibc so that the object file can declare its dependency on libm's implementation and will have to work through the community to see how we can get Zig to play nicer with systems.
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!
#Zig has the easiest FFI support I have ever seen! #programming
Building Statically Linked Go Executables with CGO and Zig
calabro.ioBuilding Statically Linked Go Executables with CGO and Zig - Jim CalabroJim Calabro
Building Statically Linked Go Executables with CGO and Zig https://lobste.rs/s/va0h3b #go #zig
https://calabro.io/zig-cgo
lobste.rsBuilding Statically Linked Go Executables with CGO and Zig | Lobsters
Tonight, at roughly 8:30 PM Eastern, I'll be going live to continue work on my 6502 #emulator!
Come for the #Zig stay for the. . .Zig. :D
You can check out the progress so far on Codeberg: https://codeberg.org/b4ux1t3/zigsty-five-oh-two
Twitchb4ux1t3 - TwitchA software developer and gamer of pretty freaking average proportions!
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
Going live! Rebuilding my 6502 #emulator in #Zig!
Come for the bad #CSharp, stay for the worse Zig!
#LiveCoding #RetroTech #RetroComputing
Slight plug: Support me on Ko-Fi! https://ko-fi.com/b4ux1t3
Twitchb4ux1t3 - TwitchA software developer and gamer of pretty freaking average proportions!
Okay, so, tonight's stream is going to be one of two things:
Me doing https://codeberg.org/ziglings/exercises
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 https://twitch.tv/b4ux1t3 tonight at roughly 8:30 PM Eastern!
. . .
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: https://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.
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.
So. . .if I print a pointer for an array in #Zig, I can see the whole array. If I print an individual value, I see the address (And datatype, which is cool).
Do arrays work significantly differently in zig from C? Like, i the pointer to the array the same as the pointer to the value, but the compiler is injecting some magic into the format string?
![A screenshot of some code on a cli:
Code: const std = @import("std");
pub fn main() void {
const myNums: [4]u8 = [_]u8{ 0, 1, 2, 3 };
const a: *const [4]u8 = &myNums;
const b: *const u8 = &myNums[0];
std.debug.print("{d}\n{d}\n", .{ a, b });
}
Output:
{ 0, 1, 2, 3 }
u8@1025f60](https://media.hachyderm.io/media_attachments/files/114/220/812/006/832/587/original/8caf1306b19635fc.png "A screenshot of some code on a cli:
Code: const std = @import(\"std\");
pub fn main() void {
const myNums: [4]u8 = [_]u8{ 0, 1, 2, 3 };
const a: *const [4]u8 = &myNums;
const b: *const u8 = &myNums[0];
std.debug.print(\"{d}\n{d}\n\", .{ a, b });
}
Output:
{ 0, 1, 2, 3 }
u8@1025f60")