04:40 <andrewrk> new zig 0.3.0 schedule based on updated prediction of LLVM 7.0.0 release: https://clbin.com/gK31O

04:41 <andrewrk> llvm 7 rc3 had a regression, so they have to do an rc4 which I'm hoping will be out tomorrow or monday, followed by final on or before friday

05:48 <kristate> okay

05:48 <kristate> hopefully llvm gets there stuff together

13:28 <bheads> I keep missing the live stream

16:31 <MajorLag> andrewrk, is there any way to get a better idea of what EvalBranchQuota should be set to? When I exceed the default I just start adding zeroes until it works. Seems like their aught to be a way to better estimate what a section of code should actually require, but I can't piece together what it is actually counting.

16:32 <andrewrk> MajorLag, I think adding zeroes is the right idea

16:33 <andrewrk> it's really just a way to make sure the compiler gets into an infinite loop without you knowing why

16:33 <andrewrk> *does not get into an infinite loop

16:34 <andrewrk> it's counting backwards branches and function calls

16:34 <andrewrk> did you see this example? https://ziglang.org/documentation/master/#setEvalBranchQuota

16:35 <MajorLag> define a backwards branch. From what I can tell, these are straight-forward loops.

16:35 <andrewrk> at the end of the while body, it branches back to the while condition

16:36 <MajorLag> I see, so it actually does count every run through every loop.

16:36 <andrewrk> yes

16:36 <andrewrk> and comptime function calls

16:37 <MajorLag> alright, well, I'll just keep doing it this way I guess.

16:39 <andrewrk> are you being forced to do something silly?

18:38 <MajorLag> No, I just felt like I must be doing something wrong by just increasing EvalBranchQuota by an order of magnitude every time I ran into it.

20:19 <unique_id> Is it dumb to store 32KB values inside a hash map instead of storing a pointer? I figure a hash map would have to be designed for that use case for it to be efficient. Like not storing key and value together? And of course in many cases I'd want a ptr to the value before constructing it, so in std.HashMap's case I'd use internalPut

20:21 <unique_id> So I guess I'll just store a ptr to heap allocated 32KB values and make use of a nice allocator :)

20:23 <unique_id> SIgh, one of my sentences is really unclear. I need to stop doing this. The reason you want to use internalPut if storing huge values is so that you do not need to have an unecessary copy. But it's not like HashMap was designed for huge values, so it doesn't need to expose that I don't think.

20:27 <MajorLag> If you know the number of 32KB values you'll need to store within an order of magnitude, you could allocate an array of that size of 32KB blocks and just store an index, though depending on your use and what you're optimizing for it's probably still better to store the pointer directly.

20:29 <MajorLag> Is there a reason it would be advantageous to store the values directly?

20:50 <unique_id> MajorLag: No, it's just less effort and kind of the default thing one does.

21:01 <andrewrk> unique_id, did you see the getOrPut function?

21:02 <andrewrk> that should help with avoiding unnecessary copies. other than that, I guess you'd just have to bench mark it to see what's faster. Probably just go with whatever semantics are easier to maintain, unless you find a bottleneck of performance there

21:11 <unique_id> I missed it, that's indeed the function that I should use. I'll store by value for now. Most dynamic entities will actually be looking up into this a lot of the time, so at some point I'll benchmark this.

21:12 <andrewrk> unique_id, I'm sure that hash map implementation could be better

21:12 <unique_id> yeah, no worries :)

23:37 <tiehuis> andrewrk: watch the stream from yesterday just now

23:38 <tiehuis> here is a small thing about the samll executables for anyone interested: https://clbin.com/OegpT

23:38 <tiehuis> the larger amount of code is usually always related to the large default panic handler, as i'm sure you know

23:39 <tiehuis> wasn't aware of the failed ability of llvm to omit the argument construction on program entry though, which would be cool to see

23:43 <tiehuis> ahh, of course i watch a bit more and you go over some of the actual flow through the calls anyway