00:24 <ltr_> hello

00:56 <MajorLag> Hi

01:00 <GitHub23> [zig] AndreaOrru pushed 2 new commits to master: https://git.io/vAjbO

01:00 <GitHub23> zig/master c18059a Andrea Orru: Merge branch 'master' of https://github.com/zig-lang/zig

01:00 <GitHub23> zig/master d062139 Andrea Orru: zen-specific: main -> _start

01:17 <MajorLag> Even after updating to an artifact after the comptime patch, it still manages to screw up looping.

04:20 <andrewrk> MajorLag: I just pushed a bug fix related to improperly caching comptime. Are you running latest master?

04:21 <andrewrk> Sorry just saw your message

04:22 <andrewrk> Apologies for the bug. I'm very interested in a test case

04:58 <MajorLag> Yeah, I still haven't nailed it down. I thought the patch fixed it because it fixed my original test case, but it was a no go.

05:06 <MajorLag> ok... this is weird. I've uncommented the code to work on it again and it is working now... only it shouldn't be, because I have a compileLog statement in the middle of a loop it has to go through.

05:07 <MajorLag> oh, nevermind. I forgot to disable some code that skips all the work if the source and destination encoding match.

05:19 <MajorLag> ok... it looks like it might have to do with taking a slice of a comptime slice. In which cast it is incendental that it happens inside of a loop.

05:46 <MajorLag> Ok, I think it's actually pretty simple. Taking a slice of a comptime var turns it into a const slice.

05:52 <MajorLag> ...no there's more to it than that...

06:08 <MajorLag> andrerk: #826. At comptime, a slice of a slice of an array is considered const. One fewer slice and it works fine.

07:19 <MajorLag> ...and after hacking around that it looks like there's something else causing comptime to fail at this. Something to deal with in the morning I guess.

07:41 <andrewrk> MajorLag: I really appreciate the test case. I know that was a pain to produce

07:42 <andrewrk> At least whenever I fix one of these, I add a test case. So these bugs are getting squashed permanently

15:54 <MajorLag> Happy to help, if I can. I should get around to getting interfaced with the debug SDK so we can do something about that COFF trace support. All my tedious work with the win32 api before should help, it seemed to include a lot of

15:54 <MajorLag> COM stuff.

15:58 <MajorLag> I just wanted to finish this first, a more complete unicode library. It supports UTF-32/16/8 with or without BOM in BE or LE. Comptime conversion is currently the only thing missing I think.

16:04 <MajorLag> well, that and some little things, cleanups, and WTF-8 support which would apparently be useful for interacting with certain systems.

16:42 <MajorLag> andrewrk: the latest comptime issue seems to be that it is memorizing the result of an iterator's next() function from the end of the previous invokation of the comptime function. I have some stuff to do for a few hours but I'll try to put together a test case later.

18:48 <ltr_> the tetris code has a problem , i dont know if it is cos im compiling it with the master version

18:49 <ltr_> z/tetris/src/static_geometry.zig:64:67: error: cast discards const qualifier, i was able to compile and run it changing the constants to variables

20:26 <ltr_> how can i add static libraries to an executable in the build.zig file?

20:30 <andrewrk> MajorLag, ok thanks, I'll look at your other issue now

20:34 <andrewrk> ltr_, fixed tetris

20:34 <ltr_> just comiled it using the docker image, and it works fine

20:35 <ltr_> the resulting docker image lacks gcc-6 libs

20:35 <ltr_> for crtbegin/end

20:37 <andrewrk> ltr_, for static libs, try addObjectFile

20:37 <ltr_> to the executable?

20:37 <andrewrk> that should maybe be renamed addObjectOrStaticLib

20:38 <ltr_> so instead of exe.linkSystemLibrary("png");

20:38 <ltr_> it should be exe.addObjectFile

20:38 <ltr_> or something like that

20:38 <andrewrk> exe.addObjectFile("libpng.a")

20:38 <andrewrk> yeah

20:38 <ltr_> tetris runs perfect

20:39 <ltr_> andrewrk: should i be able to use libuv now?

20:40 <andrewrk> you can add --verbose-link to `zig build` to make sure it links correctly

20:56 <MajorLag> andrewrk: the conditions for this case are not obvious. Could be a while before I have a test case. Something is really weird about it, the compileLog statements are not being output in the order I would expect.

20:57 <andrewrk> even if you have a large test case with multiple files, maybe you can push to a branch and tell me to check it out

21:00 <MajorLag> Might come to that. It's only two files, the unicode implementation and the tests.

21:00 <MajorLag> ....and the relvent tests could be easily included in the main file I suppose.

21:00 <ltr_> ?.c:1:1: note: 'uv_close_cb' depends on itself

21:02 <ltr_> I'm getting a lot of redefinition/invalid zig code generated/depends on it self errors using libuv, i suppose complex c unions and structs still have some problems

21:02 <andrewrk> ltr_, I'm working on a zig-native standard library event framework using async/await

21:02 <MajorLag> There's a known issue with "depends on itself" false positives.

21:03 <andrewrk> did you know we have async/await now?

21:03 <ltr_> yes, ill check it out, may be i can make the async part by my self not reliying on libuv

21:04 <andrewrk> to be useful you'll still need a userland event loop of some kind

21:04 <andrewrk> I need to solve https://github.com/zig-lang/zig/issues/821 and https://github.com/zig-lang/zig/issues/817 and then I think my proof-of-concept TCP server will work

21:11 <MajorLag> andrewrk, what precisely does it mean when @compileLog outputs "(runtime value)"? I have been assuming it means that @compileLog was enountered while compiling code for runtime instead of being run during comtime, is that correct?

21:13 <andrewrk> MajorLag, it means that you passed a value to @compileLog that was not known at compile time

21:13 <andrewrk> I think that's the same thing as what you said

21:15 <MajorLag> I don't know, my interpretation of what you said would mean that it shouldn't be logging "(runtime value)" unless I call something with @compileLog in it at run time. In my tests, it seems to always be the last value returned from a comptime var.

21:21 <MajorLag> Hmm... looks like comptime does weird things with error unions. Might be related. For instance, it can catch an error but it doesn't appear to execute the catch statement.

21:24 <MajorLag> Is it possible that the compiler could optimize out a @compileLog statement?

21:25 <MajorLag> `var x = func(); @compileLog(x); return x;` seems to ignore the log.

21:26 <MajorLag> ....except only in some cirucmstances... This is weird.

21:27 <MajorLag> I think I'm dealing with @compileLog bugs making it hard to work out the conditions for the comptime bug.