02:14 <vegecode> https://pastebin.com/br0nwU1D

02:14 <vegecode> Can someone please help me. I've tried everything I can think of to make this work.

02:15 <vegecode> I can't find any examples of something similar in the standard lib

02:17 <vegecode> Holy shit I think I just got it finally. It's literally been days.

02:19 <vegecode> Jesus. Got it finally.

02:21 <emekankurumeh[m]> I was planning on working on an inflate/deflate implementation but then zig broke on my system and upgraded to llvm8

02:32 <vegecode> I'm working off the static-base:llvm8-1 docker image. You can override the entry point and mount a volume in the container to access the files. That seems to be easier then trying to get all the dependencies working on your own laptop.

02:43 <mikdusan> vegecode: that’s like a nested union. do you need a nested switch? https://pastebin.com/FN1nk2ab

03:07 <vegecode> That's a great example. Thank you.

05:46 <andrewrk> vegecode, mikdusan, we have enum literals now too

05:48 <andrewrk> https://clbin.com/0k2I2

13:53 <mikdusan> andrewrk: enum literals 👍

16:50 <scientes> How do i enumerate the functions in a imported file?

16:50 <scientes> https://github.com/ziglang/zig/pull/2020

16:51 <andrewrk> scientes, https://ziglang.org/documentation/master/#typeInfo

16:57 <scientes> @memberName =>

16:57 <scientes> It does not include functions, variables, or constants.

16:57 <scientes> ahh

17:05 <scientes> it seems that the imported file really is an empty struct, without anything in it ?????

17:05 <andrewrk> what are you trying to do?

17:05 <scientes> call a function only if it exists

17:06 <andrewrk> why?

17:07 <scientes> Well that is a differn't issue, but here it goes....

17:08 <scientes> Linux process initialization includes a bunch of stuff, including environment variables, above the stack. If you use a beforeMain() to get what you want from this, you could re-use all this, instead of wasting all this space (about 2 pages on my Ubuntu machine, and a long file name would make that 4, because argv[0] is in there twice)

17:09 <scientes> but there is also this: https://github.com/ziglang/zig/issues/1439

17:10 <scientes> actually, I just realized such a feature would go against one of the zig rules: no hidden control flow

17:10 <scientes> a simpler thing would just be to call memunmap() on the memory, instead of jumping the stack backwards

17:11 <scientes> Linux will _eventually_ swap it, but it takes a while

17:12 <andrewrk> it's planned to be able to access the root source file with @import("root") or something like that. and then I think also planned is something like @hasField, which would exist because scanning over @typeInfo is O(N). combining these features pub fn panic can move to become a userland concept, and userland could introduce other things like this

17:13 <andrewrk> does that fit your use case?

17:13 <scientes> yes

17:14 <scientes> I'm revamping the startup code cause it could be leaner, but doing this beforeMain() thing would make it quite a bit leaner

17:14 <scientes> but maybe it would be rejected, because it is a second "special" function in root, and kinda goes against the hidden control flow rule

17:15 <scientes> but yeah, the @import("root") would allow it in user-space, instead of only in special/bootstrap.zig

17:16 <andrewrk> you can always provide the _start symbol yourself and bypass main. I believe this even works with build-exe

17:17 <scientes> it could easily be done after main()

17:17 <andrewrk> how is it leaner? it unmaps memory?

17:18 <andrewrk> so leaner in terms of resident memory, is that what you're talking about?

17:18 <scientes> yes

17:19 <scientes> It puts the stack on top of the environment variables (safely, except for the /proc/self/environ, but a prctl() can fix that)

17:19 <scientes> so you get another 8K or so of stack space, and because stack is allocated on demand, it frees memory

17:21 <andrewrk> allocating stack on demand goes against one of the main planned features of zig which is determining the stack upper bound at compile time and making sure the entire stack is reserved before beginning execution

17:21 <scientes> no, it doesn't change the stack size, i'm just talking about the way linux Virtual Memory works

17:21 <scientes> it doesn't allocate memory until it is touched

17:21 <scientes> but either way, it gives you "free" stack space

17:21 <andrewrk> right I'm saying that the default behavior will be to mlock the entire stack

17:22 <scientes> because the environment can take up up to 128KB of memory

17:23 <scientes> and after Linux 2.6.23, the environment can be up to 1/4 the size of the stack

17:24 <scientes> *allowed stack, as set in RLIMITS

17:24 <scientes> so even bigger