03:51 <Dimenus> andrewrk: That should be resolved my work yes, will have more chance to finish it up tomorrow morning.

03:52 <Dimenus> *by my work

03:54 <Dimenus> Microsoft re-split the CRT again, so really they've done two major architecture changes in the last two version. It would be pretty hacky to support 2013 and earlier in the compiler. If needed, we could just write a zig program to cover those edge cases, no?

05:25 <andrewrk> dimenus: I say, for now, support 2015 and later

05:26 <andrewrk> And yes, if a project wanted to add their own support for 2013 they could use zig build and write their own detection code

10:26 <tiehuis> andrewrk: is there any specific reason that '*' is used to denote references in a while/for loop capture instead of '&'

16:56 <dimenus> andrewrk: When you have a moment, I'm curious is to why you have separate Bufs on codegen for msvc/kernel32

16:56 <dimenus> rather than keeping them all in a ZigList

16:56 <dimenus> since you pass the linker the path and the libs separately anyway

16:56 <dimenus> **curious as to

16:57 <dimenus> the scenario I'm running into is that msvc or the 'crt' on windows is actually 3 separate libs now, and it's in two separate directories

16:59 <pupppp> Can you point me to the exact place in the code? I'm just curious, don't know anything about zig.

16:59 <dimenus> are you talking to me?

16:59 <pupppp> yes

16:59 <dimenus> which part?

17:00 <pupppp> >separate Bufs on codegen for msvc/kernel32

17:00 <dimenus> all_type.hpp:1464

17:07 <pupppp> I hope zig wouldn't depend on crt at all. I'm not sure why it does now.

17:07 <dimenus> it doesn't

17:07 <dimenus> but you need the ability to link to the crt if you link to libs that depend on the crt

17:08 <pupppp> need to rewrite libraries to not depend on crt then. I wonder what's necessary for it.

17:08 <dimenus> that's going to take awhile

17:08 <dimenus> plus you won't always have someone's source code

17:09 <dimenus> so the compiler still needs the ability to link the crt appropriately

17:09 <pupppp> what crt even does, copies memory and transforms strings?

17:10 <dimenus> it does a lot of early setup within a process, but yes if you link one of the c standard headers

17:10 <dimenus> by default that patches in the crt

17:10 <dimenus> what programming languages are you familiar with?

17:10 <pupppp> asm, c, python

17:13 <pupppp> linker in zig is currently working weirdly, doesn't throw away all code

17:13 <pupppp> https://github.com/zig-lang/zig/issues/541

17:13 <pupppp> https://github.com/zig-lang/zig/issues/54

17:14 <pupppp> not sure what to do with it, not familiar with lld at all

17:14 <pupppp> doing other stuff at the moment instead

17:14 <pupppp> learning libraries

17:24 <andrewrk> tiehuis: my reasoning is that the value in the capture is a value, so if you want the reference, you use "*ptr" and "*ptr" is the value so if you leave off the * then it's a pointer

17:24 <andrewrk> I'd be willing to switch to the rust syntax using `ref` if people like that better

17:26 <tankfeeder> dont do that

17:26 <tankfeeder> keep as is

17:26 <andrewrk> dimenus, on my windows 10 laptop, vcruntime.lib and kernel32.lib were in different places

17:35 <dimenus> there's 4 libs we need to link in order to use the CRT on windows

17:35 <dimenus> two from visual studio, two from the windows sdk

17:36 <dimenus> I was thinking of storing the paths (3 separate paths) in a ziglist off codegen

17:36 <dimenus> since we just pass the paths to lld anyway and the lib names are separate arguments

17:40 <dimenus> static linking works on windows as well

17:40 <dimenus> well, at least with the crt

17:40 <dimenus> :D

17:44 <dimenus> how do I use c macros?

18:40 <pupppp> probably better to use inline functions and const instead of macros

19:02 <dimenus> Not looking to create new macros, just testing the importing of existing macros