03:10 <emekankurumeh[m]> andrewrk: is there a possible of large enough projects being "adopted" by the zig organization?

03:16 <andrewrk> emekankurumeh[m], explain?

03:19 <emekankurumeh[m]> the zig organization on github?

03:20 <andrewrk> I don't understand your question

03:22 <emekankurumeh[m]> by "adopted" i mean become official similar to how some python packages are adopted into the standard library.

03:25 <andrewrk> are you talking about the GitHub ziglang organization, or the Zig Standard Library?

03:26 <emekankurumeh[m]> well that was a bad question. i originally mean the the github organization.

04:05 <andrewrk> emekankurumeh[m], the scope of the ziglang github organization - I don't really have a good answer to that question. right now I see it as "the reference zig implementation, specification, and tools (vim syntax, vscode syntax, etc) that zig team members are willing to maintain"

04:23 <daurnimator> also should contain e.g. the zig homepage

05:31 <suirad> i could have sworn std.debug.assertError was a thing. how do I assert an error is raised inside a test?

05:32 <andrewrk> suirad, see this commit message: https://github.com/ziglang/zig/commit/c2db077574be841da586fa62d67619c901dd535d

05:33 <andrewrk> std.testing.expectError(expected_error, actual_value)

05:34 <suirad> andrewrk: ahh okay. i saw std.testing around but glossed over it assuming it was std.debug stuff

05:34 <andrewrk> assert() in normal code; std.testing in test code

05:41 <suirad> im wrapping up an idea I had for ensuring returned pointers are not pointing to variables in the current frame

05:46 <andrewrk> sounds interesting

06:10 <suirad> alright its done. should work for any arch that has a downward growing stack. however determining what direction the stack grows and working for either would be trivial to add.

06:10 <andrewrk> neat!

06:10 <suirad> https://github.com/suirad/zig-safe-return/blob/master/safe_return.zig

06:11 <andrewrk> what about if it puts a pointer somewhere such as a global, or writes through a pointer parameter

06:12 <andrewrk> you need some kind of escape analysis

06:12 <daurnimator> andrewrk: there's no guarntee that you detect everything

06:12 <daurnimator> andrewrk: but you can avoid common/easy mistakes

06:16 <suirad> if you could potentially send a pointer to a global or anywhere inappropriate, the safe return would still detect it. it just checks if what was passed in is in the current stack frame, then returns it back to the caller or an error.

06:18 <suirad> so something like: global_var = stack_var; would change to: global_var = safeReturn(@typeOf(stack_var), stack_var); and it would detect it. but only for the frame its called in.

06:25 <suirad> another neat thing is that you can defer the safeReturn check. So if you initialize your return variable, you can immediately defer the safeReturn call and be sure your return value will always be checked.

07:16 <andrewrk> suirad, isn't system programming fun? :)

07:22 <andrewrk> alright, got C pointers merged, and now I'm back on track with daily issue quotas

07:27 <andrewrk> knebulae, C pointers are merged into master. this was your biggest pain point I believe when trying to use @cImport. and it should be solved now

07:46 <tiehuis> happy to see the c pointer change, will be very nice to not have to type ptrCast everywhere now

07:47 <tiehuis> also quick note but now we have a dedicated c pointer type i wonder if it'd be worthwhile allowing an implicit cast from zig arrays to c pointers

07:48 <tiehuis> a particular use case is in gmp, which typedefs an mpz_t as a 1 item array to avoid having to take the address everywhere

07:48 <tiehuis> not sure how widespread this technique is and how it would affect other places negatively so i'll sit on it for a bit and see

07:48 <tiehuis> doing `&a[0]` isn't a big deal anyway right now

08:53 <knebulae> @andrewrk: You are a saint. I had the longest day, and I am about to have another. I will look at this later this afternoon / early evening.

11:26 <euantor> Looks like we now get spam to mailing lists... https://lists.sr.ht/~andrewrk/ziglang/%3C84562f83f2457853c6ba3bf5fb56837b%40datantify.com%3E

11:45 <knebulae> @euantor: nothing is sacred

12:31 <forgot-password> Is it possible to set the active tag of a union? Like this: https://pastebin.com/aMhmhBwh

12:33 <MajorLag> forgot-password: yes, but it is a hack. andrewrk says there's going to be a builtin function for it. Hold on, I'll dig up the code

12:33 <MajorLag> also, did you see my note yesterday about comptime struct fields?

12:33 <forgot-password> I'm not exactly sure, but I read a few answers to my question in the irc log

12:34 <MajorLag> I linked to some code I wrote a while back in a gist that did what I think you wanted, https://gist.github.com/tgschultz/e168cffd69003e4c788b6fd2ab1aea9e

12:34 <forgot-password> Oh I didn't see *that* message of yours, but I'll check it out now, thank you :)

12:35 <MajorLag> you have to work with it a bit differently than a normal struct, but it should compile to the same code.

12:36 <MajorLag> https://github.com/ziglang/zig/blob/master/std/io.zig#L1123

12:37 <MajorLag> I would have added that to std.meta except that @unionInit is a better solution, whenever it gets added.

12:37 <forgot-password> It's basically a linked list of structs, right?

12:38 <forgot-password> I'm referring to the link from yesterday

12:38 <MajorLag> no, there's no linking, it's recursively embedding structs. In the end, it will have the same memory layout and access as a normal struct.

12:39 <MajorLag> not recursively, I guess. just a chain of embedded structs. It's early, haven't had my tea.

12:39 <MajorLag> each struct in the chain has one field that is the previous struct and one field that is the actual data.

12:39 <forgot-password> I am aware of that, I just phrased it badly

12:40 <MajorLag> ok

12:41 <MajorLag> I think I dreamed it up as a solution to "given a json file, at comptime create a struct that matches".

13:09 <very-mediocre> MajorLag: that's an interesting approach. I tried something like that to emulate polymorphism, but ran into a dead end (can't remember what it was exactly).

13:10 <very-mediocre> wanted to specify the union type as the param in a function, but then you'd unbox it to get the specialized instance

13:11 <very-mediocre> zig has changed a lot since then and I've been away, I wonder if that would be feasible now. The gears in my head are spinning again. :]

13:13 <MajorLag> Sounds like there's some things Hejsil and I have added to std.meta that might come in handy, like retreiving the payload type of a union field from an enum, and various conveniences for type metadata.

13:14 <very-mediocre> Hm, I think the limitation was the inability to build the "base class" union throughout the codebase

13:15 <very-mediocre> as in, being able to define structs later and add them to the union

13:17 <very-mediocre> e.g. union called Shape, with 2 fields (`contents` and `next`) and later you might define, say, Circle and "append" that as the second field of Shape, and so on, recursively

13:18 <very-mediocre> This is all probably useless, but fun as I currently have no use case for zig (professionally I'm stuck with PHP and JS for now...)

13:28 <MajorLag> Yeah, the fundamental limitation would be that there's such thing as a global comptime var. If there were, you could theoretically keep mutating it similar to how the pseudo-struct works, replacing the type each time a new ShapeType is evaluated. The issue with implementing that would probably be that everything dependant on that global variable type has to be re-evaluated every time you change it for it to work li

13:28 <MajorLag> ike a better way to solve that.

13:36 <very-mediocre> I thought I was being clever, since unions are in a sense polymorphic and with comptime, you could add "interface" functionality upon boxing/unboxing, but yeah, immutability poses an insurmountable wall.

13:37 <very-mediocre> And you wouldn't need allocation since it's recursive. Alas.

14:53 <gamester> andrewrk: vulkan has plenty of functions that take a pointer + length where C pointers would be ideal. For example, you might need to call vkQueueSubmit. That takes 1 or more VkSubmitInfo and it's easier to just create 1 rather than an array of 1. However, it gets better. Inside the VkSubmitInfo struct you have .waitSemaphoreCount and .pWaitSemaphores and you'll want to write ".pWaitSemaphores = &self.image_available_semaphore" but in other cases

14:53 <gamester> you'll want want to pass an array. There's endless examples of this in Vulkan. But outside of vulkan maybe rare.

14:55 <gamester> vkWaitForFences(device, 1, &frame.fence)

14:57 <gamester> though I do agree with labeling c pointers as something not to be used

17:10 <andrewrk> gamester, like this right? https://github.com/andrewrk/zig-vulkan-triangle/blob/8165e5ca6d3592eb977848173d4f0ef37ecf5342/src/main.zig#L1039

17:11 <andrewrk> alright let's get some of these pull requests merged

17:38 <schme245> what is the in-memory representation of `?u32`? is there some way that I can investigate these things myself through Zig without reading the compiler code?

17:39 <andrewrk> schme245, there is no guarantee on the layout of optionals

17:40 <andrewrk> if you want to know out of curiosity, you can do something like this: https://gist.github.com/andrewrk/5684434a2a8d4cbb08bb0d855c4f2ada

17:41 <andrewrk> or actually we can even use godbolt for that now I think

17:41 <andrewrk> https://godbolt.org/z/eD35Bi

17:42 <bwb_> wait. ya'll got godbold.org support

17:42 <bwb_> woah

17:43 <bwb_> ( andrewrk oh, hai, it bbrittain)

17:43 <andrewrk> hey :)

17:43 <schme245> huh, are there no unsigned ints in LLVM IR?

17:43 <andrewrk> schme245, correct - just signed/unsigned instructions

17:44 <schme245> interesting!

17:45 <schme245> so right now, `?u32` looks like a struct with a `i32` and an `i1` bitflag, correct?

17:45 <andrewrk> correct

17:46 <schme245> so here's what I'm curious about: what will the size of that struct be?

17:46 <schme245> cause there is no way the `i1` will actually take 1 bit, right?

17:47 <andrewrk> right. and the i32 needs to be aligned to 4 bytes (imagine if this struct were in an array)

17:48 <andrewrk> @sizeOf(i1) == 1. and then the struct gets 3 bytes of padding at the end, for a total of 8 bytes

17:49 <schme245> so there is a 2x overhead of using optionals for u32?

17:49 <andrewrk> yes

17:50 <andrewrk> note a few things though

17:50 <schme245> alright, that clears it up, thanks!

17:50 <andrewrk> if you use that type in a function and turn on optimizations, llvm knows how to break apart the struct into its logical components and just do the most efficient thing

17:51 <andrewrk> if you use it as a return type, (once copy elision branch is done) the non-null bit goes into a separate channel

17:52 <andrewrk> so really where it matters is if you put it into an array, or if you put it into a struct and allocate a lot of them

17:52 <schme245> when you say "separate channel", is that a figure of speech or an actual LLVM/compiler thing?

17:52 <schme245> just trying to figure out what I can Google for :D

17:53 <andrewrk> figure of speech. I mean the return type would actually be i1 and the optional payload would be passed as a secret pointer parameter

17:53 <schme245> gotcha

17:53 <andrewrk> and if at the callsite used `orelse` for example, there was never really a ?u32 in memory; the i1 was used for the branch and the function wrote the result directly to the callsite's memory

17:54 <schme245> that's cool!

17:54 <andrewrk> which is important semantically, if you cansider that in ?T , T could be a struct, and you'd have the guarantee in the function implementation that you're directly instantiating the memory of the callsite, and you could even rely on having struct fields point to each other, etc

17:55 <andrewrk> (note we do not have this guarantee in status quo zig)

17:55 <schme245> on the same note: would a `const A = packed struct { a: u1, b: u1, c: u1, };` have a size of 3 bytes, due to alignment/padding etc? or will it be 1 byte?

17:56 <andrewrk> 1 byte

17:57 <schme245> oooh nice, so you can use a packed struct instead of a u8 for bitflags?

17:57 <andrewrk> correct

17:58 <schme245> awesome, thanks for taking the time to explain these things andrewrk, appreciate it

17:59 <andrewrk> no problem! I hope you will stick around and teach the next generation :)