tgschultz has quit [Read error: Connection reset by peer]
SimonNaa has joined #zig
SimonN has quit [Ping timeout: 268 seconds]
mikdusan1 has joined #zig
mikdusan has quit [Ping timeout: 272 seconds]
mikdusan1 is now known as mikdusan
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
* daurnimator
waves
<fengb>
Hi
<daurnimator>
Anyone in for a day of pairing?
darithorn has joined #zig
mmx870 has quit [Ping timeout: 245 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
mmx870 has joined #zig
plumm has joined #zig
<plumm>
i notice that I can't call c functions in comptime areas, any way around this?
<daurnimator>
plumm: no... because the C functions only exist on the target. not on the build system
<plumm>
ah, didnt know comptime was in the build system
kristoff_it has quit [Ping timeout: 272 seconds]
<plumm>
goot to know; by alternative i mean how do i emulate said functionality? im not a c programmer so i dont know the gotos
<plumm>
I just need to initialize some global constant
darithorn has quit [Quit: Leaving]
<daurnimator>
plumm: huh? when I meant "the build system" I meant on the machine that is doing the compilation
<daurnimator>
plumm: initialise what to what?
<plumm>
daurnimator: its mac os specific, basically the timing function returns the value in cpu ticks and we can call in (and cache) a steady_rate value from the kernel
<plumm>
since the ticks might mean different slices of time, confusing i know
<daurnimator>
plumm: you need to call it from e.g. an .init method. not at comptime
<plumm>
hm, ok :)
<daurnimator>
also doesn't OSX have clock_gettime for like 4 years now?
<plumm>
yes but thats limited to millisecond granilurity
<plumm>
granularity
<plumm>
mach_absolute_time has nanosecond granularity ("mach/mach_time.h")
<daurnimator>
plumm: clock_gettime should have nanosecond granularity
<marler8997>
trying to track down a segfaul in analyze.cpp, in the function "resolve_llvm_types_union" I'm getting a case where tag_type is NULL...anyone have any idea if that is valid and/or if it should be handled? Right now it's causing a segfault further down the callstack