00:34 <emekoi> does the example hello_libc work currently?

00:38 <emekoi> because if you export main in your root file and link libc doesn't the main in bootstrap also get exported?

01:34 <unique_id> I'm going to stop using "use @import". For some reason I was stuck in the ways of C/C++ but I now see how much better zig's recommended way of doing things is. Also, though I don't think I'm using many globals, it kinda makes them less terrible because it's more obvious when code is using globals (a global from another file isn't referred to in the same ways as local variables).

02:54 <testuser678> What allocator should I be using in "production" code? Do people lean on the debug.global_allocator?

03:09 <daurnimator> testuser678: depends..... are you writing a library? or an application? do you want to use the libc allocator? are you linking against libc?

03:30 <MajorLag> debug.global_allocator is a fixed-size buffer that never frees. Absolutely should not be used in production. Generally speaking, use DirectAllocator and layer an appropriate allocator for each problem on top of it.

03:38 <MajorLag> Well, ok, global_allocator is just a FixedBufferAllocator, so as long as you never need more than the fixed buffer size (10MiB IIRC) you'll be ok, but you should probably just use your own defined fixed buffer and FixedBufferAllocator.

03:47 <daurnimator> MajorLag: it's not a terrible choice for short lived scripts.

03:48 <daurnimator> (or misc small purpose command line tools)

03:49 <MajorLag> I suppose not, but you can accomplish the same thing using your own FBA and it won't have the smell of depending on something in the debug namespace.

03:51 <andrewrk> I think std.debug.global_allocator is too easy to abuse. certainly libraries should not use it, not even in library tests. because you don't know how much memory other libraries will use

03:53 <andrewrk> it's handy for writing unit tests for applications, but then you have to have the discipline to rewrite your passing unit test with a fixed buffer allocator

03:54 <andrewrk> I don't have plans to yank it from standard library, but I would consider it deprecated for internal use in the standard library

14:54 <forgot-password> Why is it, that when I access the field of a struct via a variable I need to get a pointer to that field? Do the values get copied otherwise?

14:55 <andrewrk> I'm not sure what you're talking about

14:55 <andrewrk> do you have a code example?

14:56 <forgot-password> Say I have a value of type A, which has a field of type B: var a = A { .field = B { .value = 42 } };

14:56 <forgot-password> Then I want to modify a.field.value like this: var field = a.field; field.value = 0;

14:56 <forgot-password> But that didn't work, I had to do it like this: var field = &a.field; field.value = 0;

14:57 <forgot-password> Does a.field get copied into my stack in the first example, instead of having a reference to a.field?

14:58 <forgot-password> Well, I guess that makes sense, since I then have a pointer to a B, right?

14:58 <andrewrk> that's right. when you use `var` you are declaring a memory location. so the field `field` was copied into the variable `field`'s memory. Then your next statement modifies the variable `field`s memory

14:59 <andrewrk> when you use a variable that is a pointer, you're still declaring a memory location. but then the memory location you are declaring is the pointer bytes, not the actual data bytes

15:01 <andrewrk> your pointer variable can probably be const

15:03 <forgot-password> If I were writing C I would have to set the value of that pointer via `field->value = 42;`, correct?

15:03 <forgot-password> Not the value of the pointer, I meant the value of the struct the pointer is referencing

15:04 <forgot-password> the value of the field*, to be 100% correct

15:23 <andrewrk> forgot-password, no, you'd have the same issue in C

15:23 <andrewrk> you'd still have to use a pointer

15:23 <andrewrk> but then yes, to access fields from pointers in C you have to use ->

15:23 <forgot-password> No wait, I was already assuming to have a pointer

15:24 <forgot-password> Alright, thanks. :)

15:24 <andrewrk> sorry, I misunderstood

15:24 <forgot-password> No worries, I didn't make it easy to understand :p

16:17 <forloveofcats[m]> Is there some way to convert instances of builtin types to strings? I am trying to write a usize to the console and I cannot just cast to u8 as that would output an ASCII character instead of the value "as" a string.

16:18 <andrewrk> forloveofcats[m], have you seen the family of functions in std.fmt?

16:18 <andrewrk> what OS are you targeting?

16:18 <forloveofcats[m]> Oooooh that looks nice

16:18 <forloveofcats[m]> I am currently on Windows but usually use GNU/Linux

16:19 <andrewrk> std.debug.warn("here is my usize: {}\n", x);

16:21 <forloveofcats[m]> Ok apparently I'm just dumb. I saw that trick for warn but I thought that warn only worked with compile-time values as I had had errors with it before, turns out I needed to remove the `try`...

16:31 <forloveofcats[m]> Is there any documentation for the standard library?

16:31 <forloveofcats[m]> if so where may I find it?

16:31 <andrewrk> no: https://github.com/ziglang/zig/issues/21

17:51 <Hejsil> andrewrk, fun-with-zig would probably be a good test repo for copy elision

17:51 <andrewrk> Hejsil, ah yes of course. I'll be sure to look at that one

18:02 <MajorLag> Wasn't someone working on draft std docs? Or was it more of a doc generator?

18:47 <andrewrk> I believe hryx started the effort

18:47 <andrewrk> it's a big project though

19:14 <andrewrk> hmm, I just noticed that the logic for the return type of functions in @typeInfo is very questionable. I missed it in code review

20:11 <testuser678> I'm writing some code that is decoding binary structures from a byte slice - what's the safest way to reinterpret the bytes? In C I'd check that the number of bytes is sizeof(MyStruct) and cast a pointer to it - is there an idiomatic way to do that in Zig?

20:34 <Hejsil> testuser678, if you have a slice of bytes, you can do: if (bytes.len != @sizeOf(T)) return; const t = @bytesToSlice(T, bytes);

20:35 <Hejsil> @bytesToSlice(T, bytes)[0]*

21:22 <MajorLag> andrewrk: I'm not surprised, @typeInfo is really useful but it strikes me as needing quite a bit of cleanup.

21:23 <MajorLag> not to mention we still have to figure out the situation with generic parameters and return types...

22:36 <andrewrk> 497 / 521 behavior tests passing in copy elision branch

23:59 <n3t> Hi \o