00:05 <alexnask> zig build fails in spawnChildEnvMap, specifically 'const term = child.spawnAndWait() catch |err|'

00:13 <alexnask> The child processe's handle is NULL so I guess it's having some trouble spawning zig for some reason

00:16 <MajorLag> Mine doesn't get that far. It compiles the obj, then it starts looking in the registry for the SDK path, which isn't in there, completely ignoring the commandline options I passed it, then it bails.

00:26 <alexnask> Is that with a build file or just calling zig build-exe?

00:26 <MajorLag> just calling the exe. I never got into the habit of using build files because there's basically no documentation for them and my early attempts just crashed.

00:27 <alexnask> Right, this is the first time I'm testing buildfiles on windows so maybe it's not a new issue

00:27 <alexnask> But we appear to be talking about different bugs

00:30 <MajorLag> yeah

00:32 <MajorLag> you're a lot farther a long in the build process. I think this used to work correctly, but looking back the only linking I did with C stuff involved SDL, which it turns out you don't need to link to C runtime to use so the compiler probably ignored those options anyway.

01:12 <MajorLag> ....there's an issue in the windows --release-safe/--release-fast code. sometimes calling warn throws an index out of bounds check (or crashes in release-fast)

01:37 <MajorLag> it has something to do with the float value I'm trying to print... weird.

01:48 <MajorLag> it happens in linux too, some kind of fmt vs float issue it seems.

01:48 <MajorLag> today has been a remarkably unproductive day

02:02 <andrewrk> MajorLag, I don't consider the std lib float implementation done yet. printing or parsing

02:17 <andrewrk> I have some W.I.P. code

02:32 <MajorLag> yep, my bad not checking for the dup

02:32 <andrewrk> sorry about the regression with lib dirs. I'm pushing a fix now

02:35 <GitHub24> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpJoo

02:35 <GitHub24> zig/master 96ebd8b Andrew Kelley: fix windows not respecting --msvc-lib-dir, --kernel32-lib-dir...

02:35 <andrewrk> MajorLag, is it convenient for you to test this? ^

02:35 <MajorLag> probably

02:58 <MajorLag> hmm.. closer. "Unable to determine ucrt path"

03:01 <MajorLag> passing that explicitly with -L doesn't seem to help

03:05 <MajorLag> interestingly, if I pass it as --libc-lib-dir it then complains about determining the kernel32 path.

03:08 <andrewrk> kernel32 path is --kernel32-lib-dir

03:12 <MajorLag> yeah, I know, that was in there too

03:13 <MajorLag> seems --libc-lib-dir takes priority and confuses it. As I understand it, that's a linux/posix parameter anyway

05:17 <relatingdata> has anyone considered a lambda stype syntax for functions so that rather than `fn foo(bytes: []u8) u32 {` we wold have `const foo: u32 = (bytes: []u8) => {` I have been using this in javascript and looks more natural to me :-) ;-)

10:41 <GitHub66> [zig] tiehuis opened pull request #930: Add float rounding and fix negative exponential cases (master...float-printing) https://git.io/vpUYy

13:02 <walac> Could someone explain me the role of comptime in this sentences https://github.com/zig-lang/zig/blob/master/test/cases/misc.zig#L170-L171 ?

13:03 <walac> What's the differences between this and surrounding them with a comptime block?

13:08 <MajorLag> walac, the first comptime ensures that the expression block to the right is evaluated at comptime. I'm not sure why the comptime in the assert exists, but if you were to wrap the whole thing in a comptime block that would mean the assert would have to happen at compile time. The construction as-is is testing at runtime that comptime expression block produces the correct value.

13:11 <walac> MajorLag: ah, now I got the picture. iirc, the comptime in both expressions is to make sure those expressions will be evaluated in compilation time, although in practice the compiler probably will even without them

13:19 <walac> Another topic: I would like to inspect the assembly code for the binary generated by zig test, but I see it ignores the --emit for test command. Is there any special reason for that?

13:26 <MajorLag> I don't work on the compiler, so someone else will have to answer that one. I think you could commment out the `test` line and replace it with `pub fn main() void` and do a build with --emit as a workaround.

13:30 <walac> MajorLag: thanks

15:19 <andrewrk> walac, you can use objdump on the generated binary

15:19 <andrewrk> which will (for now) be in zig-cache/test

15:23 <walac> andrewrk: I did it with gdb, but originally what I was looking for with --emit is assembly with source annotation. Anyway, I found out what I was looking for :)

15:25 <andrewrk> I'd love to have that feature built into an editor

15:25 <andrewrk> so I could see what my lines of code were producing as I typed them

15:36 <alexnask> Like godbolt but for zig?

15:41 <andrewrk> yes, and built into vim or an IDE or something like that

15:41 <andrewrk> tiehuis actually got godbolt working for zig

15:42 <andrewrk> https://github.com/tiehuis/compiler-explorer

16:51 <Hejsil> Wait, someone got compiler explore to work with zig!

16:53 <Hejsil> Anyways, just got my nds loading and saving working with no recursion!

16:53 <Hejsil> It's a good day today

18:18 <andrewrk> beautiful

18:41 <andrewrk> Hejsil, I've been thinking about figuring out how to allow recursion without giving up ability to determine stack upper bound size

18:42 <andrewrk> I was thinking that we could have something like @call(new_stack, function, args...). zig would identify loops in your call graph, and emit a compile error where you would have to use a new stack for a function call in order to address the recursion

19:02 <Hejsil> Hmmm. Interesting. Well, the refactor was needed anyways, so my work wasn't waisted :)

19:03 <andrewrk> certainly not

19:03 <Hejsil> How would you allocate more stack?

19:03 <Hejsil> Some builtin?

19:04 <andrewrk> any allocator, and you can defer a free before the call

19:04 <andrewrk> for example, you could use std.heap.DirectAllocator

19:04 <Hejsil> Iteresting

19:04 <andrewrk> and you would figure out how much bytes to allocate with the builtin function that tells you stack upper bound size for a given function

19:06 <Hejsil> And I guess this would address inferring error sets too? :)

19:07 <Hejsil> For recursion that is

19:07 <andrewrk> hmm I don't think it solves that\

19:07 <Hejsil> Well, If you can detect loops, can't you then also figure out all possible errors?

19:11 <andrewrk> I do think it's possible to make error set inference work even with recursive functions

19:12 <andrewrk> I kinda designed myself into a corner the c++ compiler though, and it would require a lot of rework to fix it

19:12 <andrewrk> which maybe I will do someday

19:14 <andrewrk> but first! my goals for the self hosted compiler: https://clbin.com/TbhE9

19:14 <andrewrk> actually I'll post this on an issue

19:19 <andrewrk> I've started on this

19:33 <Hejsil> The memory handling is interesting

19:33 <Hejsil> Looking forward to it

20:40 <MajorLag> `error: expected type '&Allocator', found '&Allocator'`

20:41 <MajorLag> I'm pretty sure that's just my fault for mixing `os` from git in with whatever version I'm using on this box.

20:42 <andrewrk> I've been meaning to improve that error by having it show the declaration sites of both types

20:43 <andrewrk> I'm gonna make an issue for that right now

20:44 <andrewrk> https://github.com/zig-lang/zig/issues/932