00:05 <daurnimator> andrewrk: hooray, more copy ellision

00:05 <andrewrk> up to 500/521 behavior tests passing

00:11 <daurnimator> andrewrk: not many left now

00:11 <daurnimator> andrewrk: how long do you think is left?

00:13 <andrewrk> I was really hoping to be already done by now

00:13 <andrewrk> I think I've solved all the problems now though. hopefully. going to try to merge within 2 weeks

00:14 <andrewrk> there are a lot more tests to fix besides the behavior ones

00:14 <andrewrk> and more coverage needed. the unfortunate downside of copy elision is that it does complicate the compiler implementation quite a bit

00:18 <MajorLag> fmt parameter should just be what appears between the braces, yes.

02:27 <daurnimator> andrewrk: not much going on this last week in terms of the repo

02:43 <andrewrk> daurnimator, I'm putting all my effort into finishing this branch

02:44 <daurnimator> k; slow progress I guess?

02:45 <andrewrk> yes. I pretty much had to rewrite all the compiler guts

02:49 <daurnimator> I've been watching the commits as they come through

02:54 <andrewrk> 501 behavior tests passing is nothing to sneeze at though

08:30 <Hejsil> Hmm. I'm hitting EAGAIN writing to stderr through std.debug.warn

08:31 <Hejsil> I'll see if i can get a small test case

08:32 <Hejsil> (the reason why EAGAIN is a problem https://github.com/ziglang/zig/blob/404c87b06afbeebfea6c839665918c7bd1328d74/std/os/index.zig#L377)

15:56 <forgot-password> Why is the offset of a StructField an optional usize? Does it return null for the first field of a struct?

16:02 <Hejsil> forgot-password, because 0 sized types don't have offsets

16:02 <forgot-password> Right, that makes sense

16:03 <forgot-password> Are the @memberCount/Type/Name function going to be deprecated? @typeInfo seems to be a lot easier to use when you can extract the fields from a struct/union/enum

16:05 <Hejsil> They are

16:05 <halosghost> @typeInfo is so cool

16:05 <Hejsil> I think there are even more builtins that are deprecated

16:05 <halosghost> probably

16:07 <forgot-password> Yes, but some are marked as deprecated

16:07 <forgot-password> That's why I was wondering

16:08 <forgot-password> halosghost: Indeed, my code looks a lot cleaner after replacing the @member* functions with it ^^

16:08 <MajorLag> the std.meta package is meant for that purpose. @TypeInfo gave use the ability to replace a lot of builtins and special "pseudo-fields" in unserland. Work is not yet complete. One holdup is that we can't mark a function as comptime at the declaration site so you end up having to do it at the callsite a lot, which is inconvenient. For instance: `u32.bit_count` vs `comptime meta.bitCount(u32);`

16:09 <halosghost> sure

16:12 <forgot-password> MajorLag, I already had a few encounters with std.meta.trait, where do you guys plan on going with that?

16:17 <MajorLag> see: https://github.com/ziglang/zig/issues/1669 which references related issues.

16:18 <MajorLag> but even without any of that it is generally useful for generic code.

19:12 <vegecode> Hello all, my lunch break is ending, but I have a question. I am trying to recreate the termios structure from <bits/termios.h> and the definition has "unsigned int" parameters. If I want portability to linux on arm, should I use the c_uint type?

19:14 <vegecode> I see that the msghdr struct in the zig std lib uses u32, while musl uses plain "int". I'm just looking for what is the most portable. It would definitely be preferable if the compiler handled that for me.

19:15 <vegecode> A pointer to the struct gets passed in a syscall so it needs to match whatever the kernel uses.

19:16 <vegecode> If you could please respond, I will check the logs when I get off of work. Also, a forum or someplace to ask questions would be nice. Maybe we should use Reddit?

20:03 <MajorLag> c_uint is guarenteed to be whatever the native C "unsigned int" type is.

20:09 <andrewrk> vegecode, you can use the mailing list: https://lists.sr.ht/~andrewrk/ziglang

20:09 <andrewrk> you can also use stack overflow with the zig tag

20:16 <vegecode> thanks

20:18 <MajorLag> ugh, it's a real pain that empty errorsets don't count for inferrence. actually, I'm finding I spend a lot more time dealing with the limitations of error sets than I ever get use out of them. Could just be because of all the code I'm breaking in std right now.

20:18 <vegecode> is it good practice though? the std library hard codes it. if I'm making the termios libc file, i might as well do it right so it can be part of that issue to have a full libc replacement

20:20 <andrewrk> MajorLag, I want to change how empty error sets are handled

20:20 <andrewrk> there are a few things that can be better

20:29 <MajorLag> Yeah. I thought I could clean up some of this error set stuff in the Stream interfaces, but the empty error set thing is just making it worse.

20:44 <andrewrk> I consider the design flaw demonstrated by streams to be a 1.0-blocking problem

20:44 <andrewrk> the design flaw with error sets

20:44 <andrewrk> I don't have a plan for this release or even the next, but it's a huge problem

22:52 <MajorLag> Streams actually aren't a problem under the new pattern, except for the inferrence not working on empty errorsets. You either take var and infer the errors or you take InStream/OutStream and errors are anyerror. The one exception I've found is in queue, which has a recursive inner function that can't be inferred.

23:14 <andrewrk> MajorLag, interesting, I see. I'll take a closer look at that soon