00:34 <andrewrk> g-w1, all known deadlocks are now fixed

00:41 <g-w1> thanks, when the next tarball comes hopefully its fixed!

00:52 <mikdusan> hey gang, macOS question here: anyone know if we use/expect zig's os semantic versioning (ie. os.version_range.semver.min / max) where 10.16.* is expected for Big Sur? or can we simply represent Big Sur as 11.minor.patch ?

01:43 <andrewrk> hi mikdusan! yep, 11.x.y is big sur

02:03 <mikdusan> not sure if it's been mentioned but there is a caveat here. Apple in their wisdom has decided that based on SDK you build with,

02:04 <mikdusan> that dictates what is returned by sysctl("kern.osproductversion", ...).

02:05 <mikdusan> example: on Big Sur, I can use SDK 10.15.x or probably even older. or I can use SDK 11.x . pre 11.x SDK returns "10.16" and 11.x SDK returns "11.1"

02:47 <marler8997> congrats on fixing the deadlock...not an easy task

03:41 <andrewrk> thanks

03:41 <andrewrk> mikdusan, hmm and that's what we're using to detect the OS version?

03:45 <mikdusan> andrewrk: yes, currently we do sysctl on MIB kern.osproductversion then fallback if that fails (ie. older releases than 10.13.6) to essentially a table using key from MIB kern.osversion. this fallback is less and less important as Zig is unlikely to run on such old versions,

03:46 <mikdusan> #5125 outline that we could just quick-parse /System/Library/CoreServices/SystemVersion.plist and grab the key ProductVersion

03:46 <mikdusan> and I'm about ready to do that now that Big Sur is forcing our hand

03:50 <mikdusan> but boy is Apple funny how they implemented this compatibility version thing. ie: old SDK return 10.16, otherwise 11.1 or whatever; but it looks like parsing that .plist file is off the table now too. dammit apple:

03:50 <mikdusan> https://github.com/ziglang/zig/pull/5125#issuecomment-751422536

03:50 <andrewrk> oof

03:51 <mikdusan> and yes, a binary that is built with older SDK that opens the same file... you guessed it... it returns a compatibility version string 10.16,

03:51 <fengb> Schrodingers OSX

03:51 <mikdusan> I found this out the hard way because my `cat` was from macports that I built on 10.15 lol....

05:00 <andrewrk> cCCCCcccccCCc, idk if you saw but all known deadlock issues are now resolved

06:50 <pixelherodev> Hooray! Nice work!

08:41 <pixelherodev> andrewrk: thanks for having a grammar already, really makes my life easier :)

09:22 <pixelherodev> I think I might use string interning...

11:16 <cCCCCcccccCCc> andrewrk: I just tested it a moment ago and hopped on to let you know it works great. Thanks for all the hard work over the holidays, you're a legend!

14:39 <g-w1> andrewrk: the deadlock is fixed!!!!!!!! time to compile all the c code! tysm

16:02 <protheory8-new-m> Is there something like `std.atomic.Queue` but with a function that blocks the thread if there is no nodes in the queue?

16:35 <protheory8-new-m> Like a blocking `get` function or something

16:38 <companion_cube> You can do one with a mutex and condition, if not

17:32 <scientes> protheory8-new-m, you mean it is full?

17:32 <scientes> that is a semaphore, not a mutex

17:33 <scientes> (but they are similar)

17:33 <scientes> or similar to go channels

17:33 <scientes> buffered channels

17:47 <protheory8-new-m> scientes: No, I mean when there are 0 zero elements in the queue

17:48 <scientes> go buffered channels do that too

17:48 <scientes> and the unbuffered too...

17:49 <semarie> hum. I need to allocate data with alignment know at runtime. but Allocator interface seems to only have alignment configurable at compile-time. any idea how to proceed ?

17:50 <scientes> semarie, generally you would use the largest alignment

17:50 <scientes> unless you are writing an allocator

17:51 <scientes> semarie, because you need to compile the code for every alignment

17:52 <semarie> I am implemention emutls. the alignment is know at runtime and the system will expect found allocated data with requested alignment

17:53 <semarie> else, I would need to directly call posix_memalign()

18:07 <companion_cube> scientes: no, you don't need a semaphore to implement that

18:12 <justin_smith> semarie: I guess the tedious but flexible approach is to @pointerCast to an array of the smallest alignment, and walk by bytes and fill? I guess this is error prone also

18:12 <justin_smith> I might be missing something obvious

22:18 <oats> if I want to compare pointers (i.e., less than, greater than, etc.) do I have to convert them to ints first?

22:19 <oats> gotta say, I was a little disappointed I can't do comparison on [*]T pointers :P

22:20 <ikskuh> oats, i think it's reasonable to convert to int first

22:21 <oats> fair enough

23:26 <fengb> Hmm... the underlying allocator implementations only receive a runtime alignment. I’m curious why the interface enforces comptime

23:33 <g-w1> I have a question about inferred error sets in stage1, on analyze.cpp:4826, in resolve_inferred_error_set, analyze_fn_body is called which calls analyze_fn_ir, which calls ir_analyze which seems to just analyze the function. where does actually returning an error type add to the error set? and am I missing something or does trying to use an inferred_error_set with resolve_inferred_error_set just

23:33 <g-w1> analyze the function in the body to get the error set, or does it add it to some type of resolve_queue? thanks

23:43 <andrewrk> fengb, https://github.com/ziglang/zig/issues/7172