00:07 <scientes> the only reason it can't be in the set at the same time is because we are using EPOLLONESHOT

00:08 <scientes> in which you have to re-arm the epollfd

00:08 <andrewrk> that's necessary so that only one thread from the pool receives the coroutine handle

00:09 <andrewrk> that's where the multiplexing happens

00:12 <scientes> so co-routines introduce that limitation

00:13 <andrewrk> what's the limitation? what alternative are you comparing it to?

00:13 <scientes> you can only do one event at a time for one fd

00:14 <scientes> oh, i guess that is the case anyways

00:14 <scientes> because of the way fds work

00:15 <scientes> yeah this co-routine stuff is really complicated

00:15 <scientes> i can think about threads, but havn't quite wrapped my mind around co-routines

00:16 <andrewrk> it gets complicated to implement, but once the pieces are in place, the API is easy to reason about

00:17 <andrewrk> I want to make it more explicit where the coroutine frame memory goes though

00:18 <scientes> I'm still more confortable with a go threading model, where everything feels like a thread

00:18 <andrewrk> it's suboptimal

00:27 <scientes> There is a leak where the `coroutine_handle` is never resumed, because it is no longer in the epoll set.

00:29 <andrewrk> in order for it to leave the epoll set it would have to get resumed, or the code removing it will cancel the coroutine

00:42 <scientes> I don't think you have it figured out either

00:43 <scientes> but i won't understand it until i understand await fully

00:44 <unique_id> ..

00:45 <scientes> unique_id, https://github.com/ziglang/zig/issues/1363

00:54 <scientes> i'm not there either

00:56 <unique_id> well I hope you guys figure it out. Maybe I'll save some of these chats to understand coroutines better myself :)

00:56 <andrewrk> I would recommend the docs instead: https://ziglang.org/documentation/master/#Coroutines

00:57 <scientes> yeah my lack of knowledge is distracting

00:58 <scientes> https://docs.python.org/3/library/asyncio-task.html#asyncio.Future

00:58 <scientes> > This class is not thread safe.

00:58 <andrewrk> https://github.com/ziglang/zig/blob/a11e73bee2266d4c568bdf9b23c891ac1365bb09/std/event/future.zig#L13

00:59 <andrewrk> this is thread safe

00:59 <andrewrk> the docs on each functions tells if it is thread safe

02:33 <andrewrk> hmm should we remove @maxValue? since it can be implemented in userland

02:36 <MajorLag> Makes sense to me.

02:48 <andrewrk> MajorLag, I think your second test on 906 is a bug

02:48 <MajorLag> And here I was pretty convinced it wouldn't be.

02:49 <MajorLag> Because a lot of the things I blamed on 906 went away when I started tagging functions as `comptime` at the callsite.

02:52 <andrewrk> yeah it fixes it if you put `comptime isSliceType(FieldType)`

02:52 <andrewrk> but it should work without that

02:53 <MajorLag> Interesting. I've taken to tagging all trait.zig calls comptime at the callsite due to issues like this. If this is a bug and it gets fixed maybe I can stop doing that. It'd make it a little nicer.

02:54 <andrewrk> also related is https://github.com/ziglang/zig/issues/425

02:54 <MajorLag> yeah, that'd probably help. Even when I wrap the entire function body in a comptime block it isn't enough.

02:57 <andrewrk> I think I see the problem

02:57 <andrewrk> this is a really good test case

02:57 <andrewrk> ok so count is a comptime var right

02:58 <andrewrk> this means that every store to count must be a comptime known value, and every load from count must be to a comptime value

02:58 <andrewrk> however the expression `isSliceType(FieldType)` is a runtime known value

02:59 <andrewrk> and so when we do `if (isSliceType(FieldType)) count += 1`, there's a load and store with a comptime value *inside a runtime branch*

02:59 <andrewrk> this is unsound, so there should be a compile error for it, but there is not

03:00 <andrewrk> in other words we need to do count += 1 at comptime, but we're actually doing it at runtime. that should be impossible

03:00 <andrewrk> it actually fixes the test case if you remove `comptime` from `var count = usize(0)`

03:03 <MajorLag> I didn't think type was ever a thing that actually existed at runtime.

03:04 <andrewrk> it's not - FieldType is a comptime value

03:04 <andrewrk> but isSliceType returns a bool

03:16 <MajorLag> Which is effectively a constant. But if I understand what you're saying, then because optimization hasn't happend yet any code that is conditionally run based on that value still exists and is evaluated?

03:16 <MajorLag> At least, that's the problem in the first test case?

03:17 <andrewrk> correct

03:19 <andrewrk> imagine that every block of code is colored red for comptime or blue for runtime. count += 1 must happen in a red block, but it's happening in a blue block

03:20 <andrewrk> but if you remove `comptime` from `comptime var count ...` then it can happen in a red or blue block

03:20 <andrewrk> `inline` on a `for` turns the `for` from blue to red

03:34 <MajorLag> Ultimately it was the same issue then, which is my failure to understand that the return of an fn(type) is not necessarily red, even if `type` must be, which is why count is marked comptime. It just happened that I also stumbled on a legit bug.

03:37 <andrewrk> here's a simple example of that kidn of function: var global: usize = 0; fn foo(comptime T: type) { global += @sizeOf(T); }

03:38 <andrewrk> throw a correct return type and `return global` in there

05:05 <andrewrk> MajorLag, I think I changed my mind about whether this is a bug

14:43 <zyzzy> Hey! I'm playing around with zig and have a problem to start with: https://pastebin.com/raw/P8PgHawx

14:43 <andrewrk> zyzzy, looks like you need to add --library c to your build command

14:43 <andrewrk> since you are depending on the c allocator

14:44 <zyzzy> Ah, I missed that. Thanks, that works.

14:44 <andrewrk> I think we can make that automatic in the future, or at least a direct error that tells you what you need to do

19:03 <MajorLag> andrewrk, if I understand your reponse in #906 correctly, then the fact that isSliceType returns a runtime value causes both branches to be analyzed, and because `count` is a comptime var `count += 1` takes effect when it is analyzed. If I replace `isSliceType` with `false`, however, I get the expected result of 0 since `false` is known to be constant during the analysis. If I replace the guts of `isSliceType` with `return false` the origi

19:03 <MajorLag> al behavior returns because the result of `isSliceType`, though known at compile time, is not known during the analysis of `countSliceMembers`. Is this a correct understanding?

19:06 <andrewrk> MajorLag, the first part is correct

19:06 <andrewrk> if you replace the guts of `isSliceType` with `return false` I don't think that changes anything

19:06 <MajorLag> Right, it behaves identically to the original test.

19:06 <andrewrk> because at the callsite of isSliceType, the result is a runtime value

19:07 <andrewrk> I'm going to experiment with a new compile error that would take effect for 906 and see if it breaks anything in std

19:31 <andrewrk> I'll turn my idea into a proposa

19:38 <andrewrk> https://github.com/ziglang/zig/issues/1470

19:38 <andrewrk> MajorLag, this is similar to the concept of modifying global data at comptime

19:39 <andrewrk> which would be an argument in favor of making it an error

19:39 <andrewrk> ultimately, I think that if making it a compile error does not break any valid use cases, then I'm in favor of it

19:50 <unique_id> I need to get myself a lock-free reader writer queue, single-producer, single-consumer. C or Zig. Or I could try converting a C++ one!

19:50 <unique_id> or just create a c interface for it..

19:51 <andrewrk> fixed size element buffer?

19:51 <unique_id> I think so

19:51 <andrewrk> lock free programming is incredibly difficult

19:52 <unique_id> yeah that's why I'm going to rely on other peoples solutions :)

19:52 <andrewrk> there's still a verification problem for other people's solutions though

19:52 <unique_id> it's for communicating between a 'control' thread and a 'render' (audio) thread

19:52 <unique_id> web audio API, which I'm porting to Zig. Using webkit/labsound code.

19:53 <unique_id> libsoundio at the bottom :)

19:53 <andrewrk> not to discourage you - I'm just observing that you're about to do something difficult

19:54 <unique_id> using a queue isn't difficult. here's one: https://github.com/cameron314/readerwriterqueue

19:54 <unique_id> this one is will known

19:54 <andrewrk> I think the bug fix I just pushed is going to make comptime programming in zig a lot easier for people

19:54 <unique_id> but c++ :(

19:54 <andrewrk> it would be pretty straightforward to translate that

19:54 <andrewrk> by hand, I mean

19:55 <unique_id> yeah I think I'll try that

21:48 <andrewrk> llvm 7.0.0 got delayed by a week so here's the new zig 0.3.0 schedule: https://clbin.com/tgA5r

22:07 <andrewrk> anyone know a blake2b single file C implementation?

22:12 <andrewrk> nvm I found the reference impls

22:50 <wink_> andrewrk: why is memdupe not named memdup, were you trying to trick someone?

22:51 <andrewrk> it's named after strdup

22:51 <andrewrk> that's subject to change before 1.0.0

22:52 <wink_> which isn't named strdupe, correct?

22:54 <wink_> Anyway, would you accept a rename now if I create a PR?

22:56 <wink_> I count 30 lines with dupe in it

23:25 <andrewrk> let's wait and do a big batch of renames at once

23:26 <andrewrk> I'm not sure that dupe will be the final name, or whether it will be std.mem.dupe