01:20 <MajorLag> So here's a weird thing: `while(true){ warn("A"); }`. In win32 in a `test` block, does what you'd expect, but in linux there's no output. wrap it in a `main` instead and it acts as expected.

01:25 <MajorLag> hmm... it's probably something wrong with my environment. compilation takes a lot longer than it should too.

02:46 <achambe> anyone here use apparmour on nixos?

04:37 <andrewrk> MajorLag: do you have a nonstandard installation? Is that working around an issue or something?

04:40 <achambe> oh sorry, wrong chat .. dug

04:40 <achambe> duh'

11:24 <MajorLag> andrewrk: my linux environment is a pretty bog-standard ubuntu installation, but it is on a VM with rather contrained resources. My windows environment has a non-standard setup for BS build tools though.

12:22 <MajorLag> *VS

16:18 <GitHub87> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpIGw

16:18 <GitHub87> zig/master f1f998e Andrew Kelley: improve cmpxchg...

16:24 <MajorLag> andrewrk: I've built a std.os.time, but have some questions. What's the policy on tests that consume real time? And I made an effort to provide functionality for iOS/Darwin, but have no way of testing it, so I'm not sure I should include it at all.

16:25 <andrewrk> that's a good question

16:25 <andrewrk> you could try collecting time twice and assert that the 2nd one is >= the 1st one

16:25 <andrewrk> go ahead and include the darwin code and I'll test it on my laptop tonight

16:26 <andrewrk> oh, also travis CI will test your darwin code

16:43 <MajorLag> That's more or less what I'm doing. I suppose I don't need to wait a full second to check.

20:20 <MajorLag> I have a function that needs to do different things based on the OS. In some OSs it can fail and it is appropriate to return an error, in others it can't. The compiler is unsatisfied with this. I feel like changing the return type based on the OS is a bad idea, because it means everywhere you use that function you'll have to switch on the OS, so I feel like I have to trick the compiler. Is their something I'm missi

20:20 <MajorLag> le this?

20:20 <andrewrk> MajorLag, the pattern for this is to create an explicit error set that includes errors from all OSes

20:22 <andrewrk> here's an example: https://github.com/zig-lang/zig/blob/f1f998e07124f141312289ff82e0ad8d99af1cf7/std/os/file.zig#L18

20:24 <andrewrk> I'm not 100% satisfied with this. I might relax that compile error and allow functions with inferred error sets to not return an error. and then we would need to address the problem of switching on an error code where some of the switch prongs only applied to some OSes

20:25 <andrewrk> this is related to multibuild, which apparently I still haven't typed up an issue for

20:30 <MajorLag> Oh, I see, it isn't a problem as long as I'm explicit about the error set.

21:16 <GitHub141> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpI7f

21:16 <GitHub141> zig/master ca4341f Andrew Kelley: add --no-rosegment cli option...

22:58 <GitHub148> [zig] tgschultz opened pull request #933: Std.os.time (master...std.os.time) https://git.io/vpIjq

22:59 <MajorLag> does travis do x86 linux too or just x64?

23:18 <MajorLag> andrewrk: according to process monitor, zig still completely ignores --kernel32-lib-dir and --msvc-lib-dir, it always just looks at `<drive>:\Lib\(null)\<assumed VS path>`. I've had to create reparse points at that location to make it happy.

23:19 <MajorLag> ...only it still isn't happy, it just exits silently with code 1

23:22 <MajorLag> `18:19:47.1495265zig.exe11248QueryOpenE:\experimental\VC\BuildTools\lib\x64" --kernel32-lib-dir e:\experimental\VC\BuildTools\umlib\x64"\vcruntimed.libNAME INVALID`

23:22 <MajorLag> that's um... strange

23:26 <MajorLag> ok, so that apparently is because it can't parse the quoted paths correctly. But even without the quotes it fails (silently, exit code 1), even though now it does seem to be finding everything it is looking for.