00:30 <MajorLag> ok, so a literal divided by a literal is apparently assumed to be an int literal if there's no decimals? `math.pow(f32, x, 1/2);` is 1;

00:32 <MajorLag> I ask because not sure if bug or intended.

04:00 <andrewrk> MajorLag, that's correct

04:01 <andrewrk> interesting example

04:59 <uptown> anyone have trouble running the tests after compiling the source code on mac os?

05:06 <aiwakura> andrewrk, thanks for looking into the inlining problem

05:14 <aiwakura> andrewrk, not sure this is worth an issue, maybe there's a quick workaround

05:14 <aiwakura> cursor |= zen.inb(0x3D5) << u3(8);

05:14 <aiwakura> integer value 8 cannot be implicitly casted to type 'u3'

05:14 <aiwakura> it really should :)

06:33 <hobomatic> u3 would only be 0-7 though. 8 states, but one of them is 0

06:33 <hobomatic> (or maybe i'm missing something)

06:38 <aiwakura> oh, I see what's happening.

06:39 <aiwakura> so if you do just "zen.inb(0x3D5) << 8" it gives you the same error message

06:39 <aiwakura> because the type of "zen.inb(0x3D5" is u8, and you can only shift up to 7

06:40 <aiwakura> casting "zen.inb(0x3D5)" to usize solves the issue ;)

06:42 <relatingdata> talking of signed and unsigned entities I can thing of A->D and D->A converters that are i10 and i12 in size are the smaller than i8 and i4 worth the trouble to implement or is it relatively painless with a bit of judicious bit masking and shifting?

06:46 <GitHub68> [zig] Hejsil pushed 1 new commit to master: https://git.io/vxANY

06:46 <GitHub68> zig/master 0d8646d Jimmi Holst Christensen: std.zig.parser now parses alignment of functions...

10:40 <GitHub33> [zig] tiehuis opened pull request #915: Revise self-hosted command line interface (master...self-hosted-cli) https://git.io/vxxcL

11:24 <MajorLag> andrewrk, I guess zig has spoiled me by a) not making me explicitly put decimals on float literals and b) usually catching my mistakes during compilation.

14:34 <andrewrk> MajorLag, the only thing I can think of to address this situation is deleting the `/` operator for integers and forcing to use one of the @div* functions

14:34 <andrewrk> I feel like that might be a little harsh though

14:34 <andrewrk> we already do this for signed integers

14:41 <MajorLag> Yeah, I'm not saying there's a good way to catch it. You could, in that specific situation of two literals which could be either int or float and where the result would differ depending on which way they went, force the programmer to be more explicit, but that seems like a cumbersome hack.

20:41 <GitHub189> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxpwQ

20:41 <GitHub189> zig/master 373b358 Andrew Kelley: inline functions must be stored in const or comptime var...

20:42 <aiwakura> @andrewrk thanks

20:44 <andrewrk> thank you for the report

20:45 <andrewrk> and the generous patreon pledge

20:49 <aiwakura> my pleasure