<marler8997_> had one that's about 3 years old and still going). The creator Walter is pretty set in his ways, he's very poor at maintaining a positive community and almost impossible to discuss language ideas with. He knows alot, but seems to only value features in the language that help his style of programming, which is very archaic. Zig has some really cool ideas that solve alot of the issues D has. It's currently not as "nice" to read and
<marler8997_> gonz_: I've written hundreds of thousands of lines of D code at this point. It's got some really cool features but also has a fair amount of issues. I've written my own standard library in D to combat some of those issues https://github.com/marler8997/mar but there are also issues in the language. It's also very static now, any changes to the language must go through a multi-year proposal process, a process which is broken (I've
<marler8997_> Never finished the C version :)
<marler8997_> I just finished converting my first project to zig. Fun stuff: https://github.com/bettertools/git-extra
<marler8997_> zig's varargs (currently used with the format function) is more like a tuple
<marler8997_> oh sure, I'm talking about zig's varargs
<daurnimator> marler8997_: I'm not sure where it is on the issue tracker. but varargs can't be removed: they're part of the C ABI and hence required for interoperation with C.
<marler8997_> I andrew say "No Tuples". I'm looking for the information on why that decision was made. I would love to see a place where we could see decisions made in the language and the reasons for them.
<marler8997_> at first glance it looks like a nice alternative to tuples
<marler8997_> that's pretty cool
<marler8997_> I see one advantage is it allows multiple varargs
<marler8997_> well thanks for the info, since the plan is to remove varargs I won't push a PR
<marler8997_> but maybe it would look fine with some "getting use to"
<marler8997_> it would be warn("hello {} you are {} years old", .{name, arg})
<marler8997_> instead of warn("hello {} you are {} years old", name, args)
<marler8997_> the syntax looks weird though
<marler8997_> it looks like the current plan is to remove varargs based on what I'm reading
<marler8997_> remove varargs meaning no more varargs?
<marler8997_> I'll make a PR so it can be discussed
<marler8997_> but I would think having a function to convert varags to an array would still be supported no matter what
<marler8997_> but I don't know for sure since I don't know where it's going
<marler8997_> yeah I figured, I was thinking that in any case this functionality would still be supported though
<marler8997_> maybe this is a candidate for inclusion in the standard library?
<marler8997_> thanks again for your help
<marler8997_> Here's my final solution:
<marler8997_> I couldn't figure out how to loop through a comptime index, thanks for this, it helps alot
<marler8997_> shoot that works
<mikdusan> marler8997_: here's my naive solution: https://gist.github.com/mikdusan/8377573c5a1659f975d6a86cbaae0fa2
<marler8997_> the function allocVarargs returns an array of the given variadic args
<marler8997_> I've got a solution but want to see if anyone has a better one
<marler8997_> here's the challenge, can you implemet this function? pub fn allocVarargs(comptime T: type, allocator: *std.mem.Allocator, args: ...) ![]T;
<marler8997_> my solution could use some improvement though
<marler8997_> then I just do an inline for loop through that "index array" of comptime_int
<marler8997_> I made a function that given a comptime_int, returns an array of comptime_int where each entry is it's own index
<marler8997_> found a way to loop through varargs
<marler8997_> k, I'll revert my change
<marler8997_> oh...so it could depend on zlib?
<marler8997_> but it still confuses me
<marler8997_> of course I can un-remove it
<marler8997_> oh I already removed it. I removed as it was confusing for me. I was trying to figure out what libraries LLVM was looking for
<andrewrk> marler8997_, please just leave it in - it's simpler to pass the argument for everything that is part of this "local root" path
<marler8997_> you need to locate llvm when you're building llvm?
<mikdusan> marler8997_: you probably have llvm-config in your default path. but not all OS (like macOS) have that and need a way to locate LLVM
<marler8997_> I just build LLVM without the -DCMAKE_PREFX_PATH option... I think it's only necessary for clang/zig but not for LLVM. I'll remove it from the wiki so long as no one has any objections?


<marler8997_> I would think you would only need that argument when building clang, so clang could find LLVM, but why does llvm include it?
<marler8997_> why does the example include -DCMAKE_PREFIX_PATH=$HOME/local in the LLVM example?
<marler8997_> Quick question, on the instructions to build llvm/clang from source (https://github.com/ziglang/zig/wiki/How-to-build-LLVM,-libclang,-and-liblld-from-source#posix)
<marler8997_> not sure if it applies to organizations though, might just be for companies
<marler8997_> that's exactly what trademark is for
<marler8997_> trademark :)


<marler8997> hey, looks like I was actually able to build zig on windows...having the pre-built llvm really helped
<marler8997> It's been a few years since I've built it, hopefully it's easier than it was :)
<marler8997> I'll see if I can build the compiler though, at some point I'll need to anyway
<marler8997> so I can't really test it
<marler8997> but I haven't built the compiler yet
<marler8997> I can create a patch
<scientes> marler8997, if you can prepare a patch that would be best
<marler8997> basically, they use GetCommandLine to get the arguments for argv[1]...
<marler8997> that's how windows' cruntime works
<marler8997> at least that's the convention
<marler8997> correct
<marler8997> lpApplicationName will get passed to ARGV[0]
<marler8997> I'm guessing the fix is to child_process.zig in the windowsCreateCommandLine function?
<marler8997> basically it looks like zig is calling CreateProcess the same way it calls execve, which is incorrect
<marler8997> talking about the correct way to call CreateProcess
<marler8997> yeah not talking about how to access it
<marler8997> whereas with execve, you do pass the exe path to both
<marler8997> basically, lpApplicationName shouldn't be included with lpCommandLine
<marler8997> lpApplicationName and lpCommandLine
<marler8997> I'm guessing that however `zig run` creates the command-line, it's adding the exe path to the "args" parameter as well, like you should for execve
<marler8997> but CreateProcess doesn't
<marler8997> execve passes the program to the first arg, and the array
<marler8997> Well, I know that CreateProcess and execve work differently
<marler8997> yeah definitely happening
<andrewrk> marler8997, are you sure it's a problem? that's how execve works
<marler8997> is this one known?
<marler8997> looks like `zig run` is passing the executable twice to the generated exe...


<marler8997> might not want to look at that kernel code too much...GPL issues


<marler8997> I'm using a few dozen windows functions that aren't in std, I'll probably make a PR to submit them at some point
<marler8997> Thanks Andrew, zig seems to be in a much better place than it was a few years ago. I've been testing the waters by porting my audio synthesizer to it...very impressed by it
<andrewrk> hey welcome back marler8997
<marler8997> cool stuff
<marler8997> have you gotten it working as a library yet?
<marler8997> interesting
<marler8997> so these would be comptim strings only?
<marler8997> ah
<marler8997> like, indexing a table from the length or...how does switch make it fast?
<marler8997> very performant?
<marler8997> right, because strings support opEquals
<marler8997> bringing us back to your switch feature, I suppose that's reason not to do it the same way as D does, by supporting it on any type that as a specific function
<marler8997> the point is, you want those powerful features to be in a small subset that everyone can understand
<marler8997> the language constructs themselves break the rules of zig
<marler8997> you have to start somewhere
<marler8997> and I definitely see the reason for that
<marler8997> gotcha
<marler8997> so I guess your point was, you don't want language constructs to implicitly call functions on types
<marler8997> right...meaning the control flow has to be apart of the language
<marler8997> again, which operator is being overloaded?
<marler8997> and which operator is being overloaded here?
<marler8997> well I'm not proposing it in zig, just explaining what D does
<marler8997> foreach (foo; bar) gets rewritten to for(; !bar.empty; bar.popFront) { auto foo = bar.front; ... }
<marler8997> any type that has the 'empty'/'front'/'popFront' methods, can be used to foreach
<marler8997> similar to how D does foreach
<marler8997> the equivalent would probably just be, any type that has an "equals" method
<marler8997> but you obviously wouldn't want to do that in zig
<marler8997> in D, the '=' operator reduces to opEquals
<marler8997> it's not necessarily operator overloading
<marler8997> I believe D can switch on any type that supports "opEquals"
<marler8997> Looks like you've got prebuilt windows binaries now. Very nice. I've got a project to port to zig and it's been going very well. The port has alot of benefits of the D version I've been noticing
<marler8997> Hey Andrew, it's been a couple years but I think I'm coming back


<marler8997> It's been a couple years but it looks like Zig is alot further along now. I'm converting my Audio Synthesis program to Zig and it's been going well.