<marler8997> I could run a simple "build-exe" and "build-obj" and read/parse the options from zig's output
<marler8997> Or if there was a way I could pull the libc options from zig
<marler8997> And then I can provide any clang options I want, along with the options for libc
<marler8997> but it seems to me that the simplest way to support all the options would be to have a way to invoke zig's clang with libc
<marler8997> right now yes
<daurnimator> marler8997: so trying to map `gcc -E` invocations?
<marler8997> right, I'm at the preprocessor point right now
<daurnimator> marler8997: note that your "c compiler" like gcc/clang is several tools in one: it's a preprocessor, compiler, linker and more: it's probably useful to break down the operations as such.
<marler8997> I've looked at what the compiler does when C files are added to the command-line. I assume it's the same result
<daurnimator> marler8997: have you looked at the implementation of std/build's addCSource?
<marler8997> I wrote a small tool that will translate basic options to zig...but now I need to be able to inoke the preprocess (-E)
<marler8997> The end goal is to be able to call zig like it's a normal C compiler
<marler8997> I've got a bunch of different ideas to get this to work but I'm just not sure the right path at this point
<daurnimator> marler8997: zig libc is more like a couple of select pieces of `gcc -dumpspecs`
<marler8997> looks like there is a "zig libc" command, but it doesn't seem to print the same paths that I see when compiling C code with --verbose-cc
<marler8997> clang+libc
<marler8997> "except after libc is built and with the arguments that are required to include it"
<daurnimator> marler8997: like via `zig cc`?
<marler8997> I think in general, I'm going to need the ability to invoke clang, except after libc is built and with the arguments that are required to include it
<marler8997> next step is to be able to invoke the C preprocessor
<marler8997> any idea if there is an equivalent for -g?
<marler8997> ok
<daurnimator> marler8997: --strip is more the equivalent of -Wl,--strip-debug
<marler8997> I'm just trying to translate GCC command-line to the equivalent zig command-line
<daurnimator> marler8997: I think zig always emits debug info; and then removes it from the linker.
<marler8997> so, is "--strip" the opposite of "-g" in gcc?


<gonz_> marler8997: Are you including `--strip` & using `strip` after on the executable?
<marler8997> Looks like an empty zig file built with "zig build-obj" comes out to 518K? touch foo.zig && zig build-obj foo.zig
<marler8997> how would I do a "zig build-obj --c-source foo.c"? It can't find the C header files unless I add --library c, but then if I add that then it tries to link libc into the object file
<marler8997> hmmmm, looks like it's more complex, zig is building libc dynamically
<marler8997> it looks like, in order to get zig to behave like a normal C compiler, we just have to add the arguments for libc....does that sound right?


<marler8997> yeah
<andrewrk> thanks marler8997
<marler8997> to "draw one"?
<marler8997> If that was supported, we could even use zig to build llvm :)
<marler8997> yeah
<marler8997> right
<marler8997> sure thing
<marler8997> I could create a translation program, but wondering if any work/design exists for this already
<marler8997> I'm trying to use zig as the c-compiler to build other C projects using their build system
<andrewrk> marler8997, that doesn't exist currently. `zig cc` has no system awareness. it's unclear whether that will ever exist
<marler8997> so other build tools don't know how to use it
<marler8997> I can't just do "zig cc hello.c"
<marler8997> but it doesn't work like a normal C compiler
<scientes> marler8997, zig cc does that....
<marler8997> I'm trying to use zig like a regular C compiler where it recognizes C-command-line arguments and other build tools can use it like a c-compiler.


<marler8997> ok, back to the vacation for now
<marler8997> I'm on vacation on the Oregon coast so not as available as I would be normally
<marler8997> andrewrk: got on irc for a bit in case you wanted to chat about the PR


<andrewrk> marler8997, yes it will follow the system guidelines
<marler8997_> shouldn't we support the basic well-defined officially supported interface first?
<daurnimator> marler8997_: yes and no...
<marler8997_> Sounds like an interesting project, but in the immediate, providing a socket library that supports the BSD style socket API also makes sense in my opinion
<marler8997_> oh, very interesting
<marler8997_> windows is quite odd, it provides a userspace C ABI rather than exposing the kernel interfaces
<marler8997_> cool, some inside look into how windows operates
<marler8997_> ?? then how do you know this?
<daurnimator> marler8997_: uh. no I don't think so
<daurnimator> marler8997_: not that it'll help you find info, but AFD stands for "Advanced Function Driver"
<marler8997_> is there docs on this?
<marler8997_> not much coming up on google
<marler8997_> never heard of the AFD driver...what is that?
<marler8997_> you mean they aren't files like on linux?
<marler8997_> I could be remembering wrong though, it's been a few years
<marler8997_> I recall IOCP being the most scallable and most efficient variant...
<marler8997_> it's been a few years since I've used this stuff...
<marler8997_> IOCP is terrible?
<marler8997_> you still need a socket library for everything else
<marler8997_> overlapped IO is just how you send/receive data
<daurnimator> marler8997_: huh?
<marler8997_> sure but you still need the socket api, it's not a replacement
<daurnimator> marler8997_: on windows it's all io submission requests underneath
<marler8997_> at least parts of it
<marler8997_> it relies on the socket api as well
<marler8997_> it's not a replacement for the socket api
<marler8997_> I am familair with overlapped IO though
<marler8997_> I'll have to read up on this. I've done alot of socket programming but am not familiar with "command buffer api"
<daurnimator> marler8997_: on linux, you'd instead build on top of uring (see http://kernel.dk/io_uring.pdf)
<marler8997_> is there an example, or can you elaborate?
<daurnimator> marler8997_: in that file yes. but a fast and efficient one wouldn't
<marler8997_> Everything I'm looking at looks like it works on top of the socket api
<daurnimator> marler8997_: in that link have a look at `so_exec`
<daurnimator> marler8997_: no. a fast/efficient command buffer api would need to bypass that socket api...
<marler8997_> Also, for any higher level API, I would think it could work on top of the socket api right?
<marler8997_> Is there a library that you could reference that uses such a commmand buffer approach?
<daurnimator> marler8997_: you might find https://github.com/ziglang/zig/issues/2383 interesting


<hryx> marler8997_: [*c] should only be generated from translate-c, not written by hand
<marler8997_> oh...interesting
<marler8997_> So is [*c]u8 supposed to be the latest version of [*]null u8?
<marler8997_> I think the discussion is fine, but I don't like seeing people get so riled up. I don't know why but us humans can get very passionate about things that really don't matter. Wish I knew why.
<marler8997_> well that was an interesting 15 minutest reading through the whitespace discussion. It surprises me how passionate people get about such trivial things
<marler8997_> ah thanks
<marler8997_> just ran my "downloadlatest" script and noticed there was a new update....are updates to ziglan.org/download automatically pushed once a day or are they manual or both?
<marler8997_> So in that case, head-const and non-head-const parameters would have different semantic meaning, thus not redundant in that case either
<marler8997_> still thinking on this...if we look at the function parameter case, head-const could be used to make parameters mutable/const without needing copy the parameter into a local variable. The compiler would essentially generate the "var fooVar = fooParam" when the parameter is declared as mutable
<marler8997_> but of course, there could be other ways, just saying that this is a case where having it in the type would not be redundant
<marler8997_> however, in the case of struct members, since there's not way currently to declare a member as head-const, the type could be used in this case to declare whether or not it's head const
<marler8997_> from what I'm gathering at the moment, whether or not a type is head-const can usually be inferred from it's location, so including it in the type would be redundant
<marler8997_> I've read that making things "const" reduces strain on the developer and the argument has been used for other features
<marler8997_> any research/discussion on that?
<marler8997_> is there a way in zig to declare a struct member as head-const?
<marler8997_> I'm thinking about the consequences of not including head-const in the type, one use case that comes up is struct members
<marler8997_> I'm not sure whether that's a good or bad choice, just trying to understand the reasoning
<marler8997_> it looks like in Zig, head-const is determine by the variables location, and tail-const is stored in the type
<marler8997_> andrew doesn't think that makes sense and I'd like to understand why that is
<marler8997_> but we weren't saying it would include it's location, just that it's location could modify the type
<marler8997_> yeah that would be the extreme side of it, that each value has it's own type
<marler8997_> you could have the type know it's location, who owns it, whether it's a pointer that ends with a null value, etc
<marler8997_> if you think about it, you can put any information you want into a type, of course whether or not you should is another question
<marler8997_> why not?
<marler8997_> sure, but the type could reflect the mutability of it's location as well
<marler8997_> can you elaborate on that one andrew?
<marler8997_> that example was in D, not Zig
<marler8997_> in zig, it doesn't modify the type
<marler8997_> const foo = 0; (typeof foo is (const int))
<marler8997_> well D has that too, but it modifies the type
<marler8997_> I should say "head const" is handled differently
<marler8997_> D handles const completely differenty. It's always a type modifier. Whereas in zig, it's a type-modifier when you're talking about pointers and arrays, but it's also associated with other things such as whether it's a parameter/loop variable
<marler8997_> so you can't even do what I'm proposing anyway
<marler8997_> hmmmm, I'm still learning these new semantics, you can't specify (const u8) in a function parameter
<marler8997_> not making the parameter mutable
<marler8997_> that's irrelevant to my point, I'm talking about putting const on the parameter type now
<marler8997_> it doesn't have an explicit type like a function does
<marler8997_> that one doesn't have a type
<andrewrk> marler8997_, it's consistent with all the other capture variables
<marler8997_> sure, but what about the use case I talked about. It's still const even if you don't include const
<marler8997_> what if you required the function to declare it as const?
<marler8997_> one thing that's confusing is that the type of the parameter looks mutable even though it's const
<marler8997_> since it would be fairly rare
<marler8997_> but probably not a big deal
<marler8997_> hmmm, I think ideally those would be treated differently
<marler8997_> are extern C function parameters also forced const?
<marler8997_> yeah
<andrewrk> marler8997_, you can use e.g. "{*}" and `&tpInMain` and it will print pointer format
<marler8997_> I'm just use to C, so this is very different
<marler8997_> it sounds like the reason is because parameters aren't necessarily a copy
<marler8997_> not complaining about optimization, I'm asking why parameters are alwayas immutable
<andrewrk> marler8997_'s example shows pointer addresses to show whether or not copies occur and it's notable whether they happen in debug builds
<marler8997_> because I'm taking the address of the data?
<marler8997_> so it got passed by reference
<marler8997_> hmmm interesting
<marler8997_> I'm working on one
<marler8997_> if you needed to modify it?
<scientes> marler8997_, do you have a godbolt paste to show?
<marler8997_> if the parameter is able to be mutable, then wouldn't you have one less copy?
<marler8997_> yet it's still doing 2 copies
<marler8997_> but it says "no performance cost"
<scientes> marler8997_, also if it is only 16 bytes its probably getting passed in registers in which case the copy is quite cheap
<marler8997_> that's what I'm not understanding
<marler8997_> oh?
<marler8997_> but isn't the parameter already a copy?
<marler8997_> but I don't want to modify the caller's copy
<marler8997_> I need to be able to modify it
<marler8997_> I am using an aggregate type
<scientes> marler8997_, LLVM is SSA
<marler8997_> why force the user to have to move the data twice?
<marler8997_> depends on the ABI, but the question still applies
<marler8997_> one MOV from the caller to the function frame, and one MOV from the function frame to a local variable
<marler8997_> does that result in 2 copies? one copy from the caller and one copy inside the call?
<marler8997_> is that an LLVM-ism?
<marler8997_> no performance cost?
<marler8997_> > If you need a mutable parameter, var foo = param; is an easy, reasonable way to get it, that comes at no performance cost.
<hryx> marler8997_: I asked that once in an issue and got a good response, let me find the link for you
<marler8997_> Why are function parameters always const?


<marler8997> since zig is already getting anonymous structs, maybe that could already be leveraged?
<marler8997> basically lowers to creating an anonymous struct and passing all the variables to the lambda/function
<marler8997> something like c++ closures might be a good proposal
<marler8997> this doesn't seem to bad `while (y.next()) |x| { ...}`
<marler8997> pretty much the same thing in D, but I think andrewrk will respond with zig's idea of no hidden code/allocations


<scientes> yeah its only applicable from inside the compiler marler8997_
<scientes> marler8997_, ?
<marler8997_> scientes: not sure what you're talking about, can you provide an example function?


<marler8997_> marler


<andrewrk> marler8997_, hmm, it might be time to reel in memory usage of stage1
<tgschultz> marler8997_ it may be an infinite import loop. I've encountered something similar before. The solution at the time was to cd into std and run the test from there.
<marler8997_> I just rebooted, ran it again and now it's completely hung again
<marler8997_> whoa....running ./bin/zig test ../std/meta.zig seems to be completely locking up my linux box
<marler8997_> ok thanks for confiming
<Hejsil> marler8997_ Only memory locations can be 'const'. This means declarations and pointers.
<marler8997_> why doesn't the Array TypeInfo have an "is_const" field?
<marler8997_> is there a way to pass a "const type" to a function? i.e. "const usize"?


<marler8997> logging is a very hard problem in general
<marler8997> seems like a good start
<marler8997> I see it now :)
<marler8997> oh woops
<marler8997> seems like the info/warn/err/fatal functions should call a common function, which could also be configured by root
<marler8997> I haven't, I'll look it up
<andrewrk> ah yes marler8997 did you see my log proposal?
<marler8997> this is something I've wanted to have in other languages but never have, excited to explore it
<marler8997> allowing root to declare logging mechanisms may also be another one
<marler8997> if (@hasDecl(@import("root"), "defaultAllocator")) ...?
<marler8997> @import("root") could open up some interesting semantics
<marler8997> that was my first thought
<daurnimator> marler8997: new module 'std.iterator'?
<marler8997> I don't see the `Chain` and `OneItemIterator` types anywhere in zig standard library. Should I add them? and if so, where would they go?
<marler8997> SamTebbs33: sounds like an interesting question...I'd have to think about that one. Do you have a use case in mind, might help provide some insight
<marler8997> oh nice, now there's one global directallocator
<marler8997> Looking for something like this: https://pastebin.com/pCM1xmaN
<marler8997> I want to iterate over multiple iterators
<daurnimator> marler8997: what do you mean? can you not just call .next on the parent iterator within *your* iterator?
<marler8997> quick question, is there a way in the standard library to chain multiple iterators?


<marler8997_> does zig have a way to divide and get remainder (divmod) in one operation?


<marler8997_> note that at some point I'll probably submit these windows functions to zig std library
<marler8997_> cool, thanks for the tip
<marler8997_> maybe a better solution as it sort of signals to the developer that they really need to know what they are doing
<marler8997_> yes that would work as well
<marler8997_> you're saying a usize, not *usize
<marler8997_> oh right
<marler8997_> so long as it fits in a usize
<marler8997_> correct, it also doesn't have to be a pointer
<marler8997_> In my case it points to a struct
<marler8997_> it could point to anything
<marler8997_> it's a pointer provided by the user
<marler8997_> it's not a pointer to a u32 or a usize
<marler8997_> sure, but how does that help?
<marler8997_> ok, thought I'd check to make sure that was the right way to go
<marler8997_> it's not a pointer to either one
<marler8997_> It doesn't matter whether it's usize or u32
<marler8997_> yes, user-data parameters
<marler8997_> zig no longer knows where that pointer came from
<marler8997_> but once I get the pointer back inside the callback, the type information is gone
<marler8997_> I do fullfull it
<marler8997_> and I get it back in the callback
<marler8997_> so `instance` is a just a "pass-through" pointer that gets passed to the function where I set the callback
<marler8997_> instance: *u32, param1: *u32, param2: *u32) void {
<marler8997_> stdcallcc fn midiInputCallback(handle: HMIDIIN, msg: u32,
<marler8997_> woops, that was after I changed it, it should be:
<marler8997_> instance: *usize, param1: *u32, param2: *u32) void {
<marler8997_> stdcallcc fn midiInputCallback(handle: HMIDIIN, msg: u32,
<marler8997_> it's a windows callback function
<andrewrk> marler8997, alignment errors more likely point to an actual bug rather than needing to cast
<marler8997_> it may or may not have the same alignment as a uszie
<marler8997_> you don't know how big Foo is
<marler8997_> so how do you recommend I tell it to skip the alignment check
<marler8997_> but when I get the pointer back in the callback, zig doesn't know it's aligned
<marler8997_> the pointer is already aligned
<marler8997_> it's gotta work on both platforms
<marler8997_> is there another pointer type I could use that would allow me to cast it to pointers with large align types?
<marler8997_> just matched the windows function definition
<marler8997_> hand-crafted
<marler8997_> dumpbin tells me x64
<marler8997_> FILE HEADER VALUES
<marler8997_> 8664 machine (x64)
<marler8997_> not sure actually
<mikdusan1> marler8997_: are you doing a 32-bit or 64-bit binary?
<marler8997_> so I need to cast it accordingly
<marler8997_> that's the callback signature, the 3rd parameter `DWORD_PTR dwInstance` is a pointer to a struct
<marler8997_> need to cast from a *u32 to a *Foo
<marler8997_> looks like that just aligns a pointer
<marler8997_> looks like @intToPtr(*Foo, @ptrToInt(ptr)) works, but I'm sure there's a better way
<marler8997_> getting a pointer from a windows function callback, but zig won't let me ptrCast it "cast increases pointer alignment"...any suggestions?


<marler8997_> the json format is a bit weird though
<marler8997_> using the json format is much nice, removed like 20 lines of python parse code
<marler8997_> my script is getting further now, looks like it's disabled now
<andrewrk> marler8997, I believe that setting is disabled now
<marler8997_> best practices right? :)
<marler8997_> the html response I got
<marler8997_> silly
<marler8997_> the server is denying download access from the python urllib downloader because it hasn't enabled cookies :)
<marler8997_> why does the ziglang.org site redirect all http requests to https?
<marler8997_> andrewrk: no, thanks for the info, I'll update my tool to use that


<andrewrk> marler8997, are you aware of the json version of the download page?
<marler8997> Yeah I'm pretty sure -I allows both types of includes
<marler8997> having the zig compiler binary and standard library as separate files doesn't really bother me, but maybe it would make distribution easier for others
<daurnimator> marler8997: something I've suggested for windows in particular is a fully-self-contained zig binary
<marler8997> maybe there's a way to ask choco/scoop to install the latest master, but haven't seen a way
<marler8997> yeah, sounds like chocelatey and scoop are a different use case than what my script does, which is just to download the latest bleeding edge compiler from ziglang.org/download
<marler8997> it probably doesn't make since to push every build of zig to a package manager's metadata
<marler8997> I downloaded chocoloatey but not able to figure out how to download the latest compiler from master
<marler8997> you can download the latest zig compiler with these? from master?
<marler8997> does it let you download the latest zig compiler?
<marler8997> after running this tool, you should be able to execute the latest zig compiler, you don't even need to update your PATH
<marler8997> currently requires curl, but planning on adding support for more http download clients
<marler8997> python3 downloadlatest
<marler8997> I've just finished a tool that will download the latest zig compiler on windows: https://github.com/marler8997/zigbuild
<marler8997_> der
<marler8997_> oh you know what, I'm an idiot....the sha is right there in the filename
<marler8997_> Is there a way to know which commit the packages were generated from on the download page?
<marler8997_> also no tabs
<marler8997_> Have you tried nix?


<marler8997_> weird, but cool :)
<marler8997_> cool
<marler8997_> sounds similar to adding support to be able to run android apps on linux or something
<marler8997_> interesting, I know very little when it comes to apple's development tools/environment
<marler8997_> what's macabi?
<marler8997_> And Zig's solution: while (range.next()) |value| { // code }
<marler8997_> Input Ranges in D: for (; !range.empty; range.popFront) { auto value = range.front; // code }
<marler8997_> looking through some zig code, I just realized that D's input range interface (empty/front/popFront) can be emulated in zig with one function (next)


<gamester> marler8997_: Now that C#/.NET is becoming open source, does that place C# as a competitor to D?
<gamester> marler8997_: Wow a heavy D user, nice! Many eons ago I was writing an application that needed to load and unload DLLs at runtime. I considered D but it had no ability to handle this simple task, at least without leaking memory. It struck me as a really weird thing to not have figured out for a language that seemed back then to be focused on systems programming. I've never grokked what D is trying to be.
<marler8997_> I think the differences are.
<marler8997_> is missing some features, but the core of the language seems to be going in the right direction, and it's still young enough to make breaking changes and move in a new direction if it's deemed a better one (i.e. varargs vs tuples vs anonymous structs). I have alot more to say on the subject but I have to go for now. I was thinking of making a post about my experience porting a couple of my projects from D to Zig and explaining what