ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk>
because zig has no memory management, C FFI has no overhead
<jzelinskie>
so basically everything from C FFI is &u8?
<MajorLag>
every c string is
<MajorLag>
other things are appropriate mappings. zig has c_int, c_long, etc to ensure you match the native abi
<jzelinskie>
structs?
<MajorLag>
are just structs
<andrewrk>
`extern struct` guarantees C ABI
<jzelinskie>
awesome
<andrewrk>
same with union
<jzelinskie>
i remember you saying that now
<andrewrk>
we also have `packed struct` where you get exactly the fields you list, in exactly that order, no padding, and you can use integer types smaller than 8 bits to get bit fields
zesterer_ has quit [Ping timeout: 264 seconds]
noonien has quit [Quit: Connection closed for inactivity]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
davr0s has quit [Client Quit]
sand-witch has quit [Remote host closed the connection]
<hobomatic>
i know this isn't actually a good way to do this (endianness) and there is mem.readInt, but it seems like this should be possible
<hobomatic>
but I am pretty stupid about machine numbers and alignment and packing and all that, so maybe not
<MajorLag>
that's odd
<MajorLag>
if you move the var to global scope it works. also `var n32 = *@ptrCast(&i32, @alignCast(@alignOf(i32), &n8[0]));` works.
<MajorLag>
actually wait, no, in global scope it gives a different value.
<hobomatic>
haha
<hobomatic>
spooky
<MajorLag>
yeah, it's definitely just hitting uninitialized memory when you put the var in global scope
<hobomatic>
yeah for me it gives a different number and the test fails for some reason, i guess a segfault or something equivalent. No panic stacktrace like an assertion failure.
<hobomatic>
(using var in global scope)
<hobomatic>
yeah its a segfault when i run the test executable from zig-cache
accidental has joined #zig
<MajorLag>
it happens even if it is an array of a single u32. So I think var arrays must be special, probably have a size prefix or something?
<accidental>
hey all, I'm going through documentation and don't think this is possible, but is there a way to define an implicit cast?
<MajorLag>
and @bitCast isn't aware of that I guess
<MajorLag>
the docs just say that @bitCast asserts the types have the same size, and indeed [4]u8 has the same size as i32.
<MajorLag>
and it works for const.
<accidental>
specifically, I'd like to be able to use std.fmt with a custom type, and as far as I can tell the only non-built in formatter is for things that can be implicitly converted to []u8
<MajorLag>
oh, that's what you mean.
<MajorLag>
I don't think that's currently possible, but I think there's a plan to have a way of extending std.fmt at least.
<accidental>
hrm ok cool - kinda what I thought after skimming source but didn't know if it was a thing
<accidental>
I can wrap printf to do something similar, or I guess you could have a third party formatting library that could handle it, but yeah
<MajorLag>
it's pretty easy to write a comptime function for formatting custom types. I did an experiment a while back where I wrote something to inspect and print an entire struct: https://paste.ubuntu.com/p/tSgNvwRBNX/
<accidental>
oh sweet, I'll definitely take a look at that, thanks
<accidental>
so looking through that
<accidental>
it's pretty much what the current format stuff does, in that it's comptime hardcoding types (switch on @typeId, has to be known types)
<accidental>
is there a way to comptime dispatch to some type specific function?
<MajorLag>
Ultimately everything is a known type. It takes a struct, any struct, and decomposes it into primitive types.
<MajorLag>
yeah, you can just switch on the type. switch(@typeOf(whatever)) { TypeA => ... TypeB => ....}
<accidental>
I guess I want to be able to extend that switch in a different library
<accidental>
module
<accidental>
introduce a TypeC I guess, you know?
<accidental>
sorry, if I'm being dense
<sand-witch>
Are global variables known to be not working? https://pastebin.com/raw/Eia7y8WZ -- This is not the only mysterious error I'm getting.
<sand-witch>
dont pay attention those file path names though..misleading nonsense at this point
<sand-witch>
Sigh, I was going to clean this code better up. It's just doing nonsense. Important part is that it thinks there's a redefinition of ptr.
<MajorLag>
accidental: Yeah, I see what you're saying. I can think of ways to do that, but they're pretty involved, returning comptime types and stuff.
<MajorLag>
sand-witch, huh, I would think you'd be able to shadow... actually I think there might be an issue for this...
<MajorLag>
andrewrk, was the other isse that came up last night with the shadowing a bug or intentional?
<andrewrk>
MajorLag, it's intentional that global variable shadowing is not allowed
<andrewrk>
the reasoning for this is that it provides a helpful guarantee when reading code
<andrewrk>
sand-witch, zig does not allow shadowing of global variables. what else were you running into?
<andrewrk>
the one with "unable to evaluate constant expression" - you are trying to execute malloc at compile time, which is impossible since the heap is not available until runtime
<andrewrk>
zig does not have static initializers - global variable declarations at top level scope are executed at compile time
<andrewrk>
it's so nice when people are running into completely intentional compile errors with correct messages, instead of bugs :)
sand-witch has quit [Read error: Connection reset by peer]
sand-witch has joined #zig
<Hejsil>
It's kinda rare to find a bug in Zig that doesn't crash the compiler :)
<Hejsil>
Or maybe I've just been writing to much comptime code
<Hejsil>
That's like the easiest way to hit asserts
<andrewrk>
sorry Hejsil :(
<andrewrk>
I'm going to take a much more disciplined approach when coding the self hosted compiler comptime stuff
<andrewrk>
the current c++ code was experimental and I changed strategies several times
<MajorLag>
I find the same when doing fancy comptime tricks Hejsil. But I rarely run into runtime bugs, so it's ok.
<andrewrk>
we used to go straight from AST to LLVM IR
<Hejsil>
It's a lot better to crash that have a runtime bug
<andrewrk>
how's the pokemon randomizer going? looks like it works for pokemon emerald?
<Hejsil>
I have trainer randomization working on Emerald.
<Hejsil>
Most US versions of generation 3 games probably works now
<Hejsil>
But no testing
<andrewrk>
I bet if you did a writeup of this project with some demos and stuff it would be pretty popular in tech news
<Hejsil>
I have loading of nds roms nearly working. This will allow me to randomize gen4 and 4 games
<Hejsil>
It's not really ready yet though :)
<andrewrk>
fair :)
<MajorLag>
I'd read it. From what I understand, Pokemon code has a lot of tricks for size reduction, so I'm curious how it's dealt with.
<Hejsil>
It's hard when you have a competitor that is fully featured for gen 1-5 games
<Hejsil>
My biggest challenge so far have been loading the file system from the nds rom format
<Hejsil>
There is a lot of tricks
Hejsil has quit [Quit: Page closed]
hobomatic has joined #zig
mattw has quit [Ping timeout: 260 seconds]
jjido has joined #zig
zesterer_ has quit [Remote host closed the connection]
Hejsil has joined #zig
jjido has quit [Read error: Connection reset by peer]
jjido has joined #zig
davr0s has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jacobdufault>
andrewrk: does zig depend on more than just libclang? Because I've found libclang has some issues, ie, it doesn't use the same compiler driver as clang so command line parsing is a bit of a mess (re https://github.com/zig-lang/zig/issues/490)
steveno_ has quit [Remote host closed the connection]
steveno_ has joined #zig
Hejsil has quit [Ping timeout: 260 seconds]
daemol has joined #zig
jjido has quit [Ping timeout: 264 seconds]
SimonNa has quit [Remote host closed the connection]
SimonNa has joined #zig
<andrewrk>
jacobdufault, no, it only depends on libclang. that's good to note, thanks. I'll have to experiment with it and update the issue
<andrewrk>
the Grand Bootstrapping Plan is still ok thought, because you can substitute using zig as a c++ compiler with just using the clang binaries that we produced from the previous steps
Ichorio has joined #zig
Ichorio has quit [Client Quit]
Ichorio has joined #zig
davr0s has joined #zig
steveno_ has quit [Quit: Leaving]
daemol has left #zig [#zig]
cenomla has joined #zig
accidental has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
accidental has quit [Ping timeout: 240 seconds]
Ichorio has quit [Ping timeout: 260 seconds]
<MajorLag>
andrewrk: there's no way to um.. `catch` a compile error right? I'm thinking that if there were, or if there was a way to introspect a type's namespaced functions, it'd be really trivial to add cutsom formatters. It'd be useful in general for ducktyping with `var`, I think.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag>
actually... there might be a better way...