00:22 <MajorLag> yeah, it's a tweening library

00:39 <MajorLag> ...did I misunderstand somethig? isn't 0.2.0.cc35f085 supposed to have @field?

00:42 <MajorLag> oh nevermind, I think I extracted the wrong build accidentally

00:48 <MajorLag> works as advertised.

02:29 <relatingdata> in zig what is the way of declaring the constant C++ array of constant strings like const (char *) const months[12] = { "Jan", .... ,"Dec"}; ?

02:33 <MajorLag> `const months = []const []const u8{ "Jan", "Feb", ... };`

03:33 <relatingdata> Thanks :-) easier on the eye too :-)

06:21 <GitHub10> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpqaz

06:21 <GitHub10> zig/master 6e57243 Andrew Kelley: zig fmt: preserve comments in front of test blocks...

06:23 <heakins> OK now my AES-128 implementation can encrypt 155MB/s compared to 212MB/s for mbedTLS... getting closer

06:57 <GitHub118> [zig] harryeakins opened pull request #935: Improving throughput test (master...improving_throughput_test) https://git.io/vpqwO

10:42 <alexnask> Are there any docs on async/promises?

10:43 <alexnask> Nvm I'll look into the coroutines tests

10:48 <alexnask> What allocator is used when none is given to async?

11:16 <Hejsil> alexnask, I haven't done anything with coroutines, but I would guess that it would use the parent async functions allocator

11:16 <Hejsil> Aka, you have to provide an allocator if you're doing an async all from a non async function

11:19 <alexnask> Right, makes sense

13:47 <alexnask> Can I declare a comptime constant at global scope that will not get included in the binary?

14:36 <Hejsil> alexnask, if it isn't used at runtime, then it isn't compiled into the binary

14:37 <Hejsil> And for things like: const a = 2; fn a() u64 { return a; }, Im pretty sure the optimizer will take care of that

14:40 <alexnask> Right, good to know, I thought defining consts in global scope forced them into the binary

14:40 <alexnask> I got around my usecase a different way (that uses @field) anyways :)

14:41 <andrewrk> alexnask, I'm doing a proof of concept on a bunch of concurrency stuff and I'll write docs soon

14:48 <alexnask> Pretty nice, I just use a struct with function pointers (+ a global instance named gl) and a func that automatically loads all of them from OpenGL

14:48 <alexnask> Works like a charm

14:49 <andrewrk> alexnask, nice, is the code published somewhere?

14:49 <andrewrk> on windows, right?

14:49 <alexnask> Not yet, I guess I will upload it at some point

14:49 <alexnask> Yup it's on windows

14:50 <alexnask> This is basically it though: http://prntscr.com/j7vddo

14:50 <alexnask> Nice and simple

14:50 <andrewrk> oh wow that's beautiful

14:52 <andrewrk> alexnask, mind if I post this on twitter?

14:52 <alexnask> I'm going to work on @reflect/@reify this weekend btw

14:52 <alexnask> Ofc not, go ahead :)

14:53 <alexnask> Would you prefer that I delete all the current @typeId etc functions or should I make them post a deprecation warning?

14:53 <alexnask> I'll also make a std.meta package that exposes them like before so basically @<reflection_func> -> std.meta.<reflection_func>

14:54 <alexnask> (That will obviously use @reflect behind the scenes)

14:55 <andrewrk> alexnask, `comptime` in front of `const` is redundant

14:55 <andrewrk> maybe I can make a compile error for this

14:55 <alexnask> TIL

14:56 <andrewrk> or rather, it's equivalent to putting the comptime in front of the initializer expression. but @memberName is always comptime so that is redundant

14:57 <alexnask> Right, got it, I thought const meant that the value was always present at runtime while comptime forced it to only be used in a comptime context

14:57 <andrewrk> is wglGetProcAddress expecting a null terminated string?

14:57 <alexnask> Yes, I shpuld probably ++ []u8 { 0 } right?

14:58 <andrewrk> I believe you can simply change "gl" to c"gl"

14:58 <andrewrk> otherwise what you said should work fine

14:58 <alexnask> The compiler doesn't complain with c"gl", nice

15:02 <alexnask> Right, it appears I still need to add the null byte

15:02 <alexnask> Even with c"gl"

15:03 <andrewrk> ah ok. so zig decided that &const u8 and []const u8 would be resolved to []const u8, ignoring null terminators

15:03 <andrewrk> this will be solved with pointer reform

15:03 <alexnask> Here's a new screenshot if you want it ;) http://prntscr.com/j7vkpy

15:35 <andrewrk> MajorLag, I'm happy to take over the std.os.time PR from you and do whatever needs to be done to get it merged this weekend

15:35 <andrewrk> thanks for spearheading that work

15:36 <andrewrk> I looked into the aux vector thing on linux too; I think I can make static linux binaries use the vdso

15:46 <MajorLag> Cool. I'd be really surprised if darwin works on the first attempt. If it weren't for the merge conflict CI could have helped me get that right first.

15:46 <MajorLag> How would that work w/ vdso?

16:05 <alexnask> std.mem.eql appears not to be working at comptime

16:06 <alexnask> Nvm, I think it's not std.mem.eql

16:12 <andrewrk> MajorLag, there's an "auxilery vector" given to programs, even static ones, which contains the address of the vdso. so then you just have to find the function address and jump to it, or something like that

16:18 <MajorLag> yeah, that's how it works. It's an elf image, so you have to do a lookup in the symbol table. What I mean is, how is the compiler doing that? vdso may or may not exist at runtime. Or did you just mean adding support for vDSO to os.time? That shouldn't be too tricky, though there is the problem of first determining if vDSO is available or not.

16:20 <andrewrk> I mean adding support in the std lib for accessing the auxilery vector, and then yes having std.os.time use the vdso, if available

16:22 <alexnask> I hate WinAPI so much >.<

16:24 <MajorLag> anything in particular?

16:32 <alexnask> I'm struggling to find any parts I don't hate :p

16:34 <andrewrk> I think the audio api is better than linux

16:34 <andrewrk> that's a pretty low bar though

16:34 <alexnask> The one that triggered me right now is all the juggling to create a rendering context, then load OpenGL functions just to make a modern OpenGL enabled rendering context

16:34 <andrewrk> I would be curious to see a minimal example

16:34 <alexnask> Just give me the best version of OpenGL you can handle man :P

16:35 <andrewrk> I wonder if a cross platform abstraction for creating a window + opengl context makes sense to be in std

16:36 <alexnask> Only if nice OpenGL bindings are also available

16:36 <alexnask> But then people would ask for sound and inputs too etc

16:36 <alexnask> And in the end you are just remaking SDL

16:37 <andrewrk> true. I think we just need to have a great package manager, and trust users to create high quality packages

16:38 <alexnask> Right, the package manager would be great

16:39 <andrewrk> working on it! self-hosted compiler is underway, plus I have some networking proof of concept code working

16:56 <MajorLag> oh, yeah, win32 kind hates opengl > 1.1. Otherwise I have pretty much the oposite opinion and find Win32 API makes a lot more sense to me than posix.

16:57 <MajorLag> but posix is a pretty low bar too, I guess.

17:03 <MajorLag> as far as the context thing, what casey does in hmh is create a whole new window and opengl context just for loading extensions, then throw them away when he's done.

17:04 <MajorLag> alexnask: https://paste.ubuntu.com/p/X8tzhTQvdQ/

22:23 <alexnask> @MajorLag I do something similar

23:06 <GitHub145> [zig] tiehuis pushed 2 new commits to master: https://git.io/vpYI7

23:06 <GitHub145> zig/master eef4bbb Harry Eakins: Changed all MB to MiB

23:06 <GitHub145> zig/master b229aff Harry Eakins: Readability improvements and bug-fix to std/crypto/throughput_test.zig

23:06 <GitHub199> [zig] tiehuis closed pull request #935: Improving throughput test (master...improving_throughput_test) https://git.io/vpqwO

23:07 <achambe> andrewrk: as far as network applications go, I had the thought a memcached compatible server might be an appropriate showcase people can use - I had the impression memcached has a simple protocol, but not certain.

23:11 <achambe> also, maybe a jerk comment, but be careful how much time you spend writing crypto code in zig, its just a bottomless pit of work with not that much payoff if zig has a C compiler built in.

23:11 <achambe> crypto libraries can probably be bundled with no dependency on libc anyway.

23:12 <achambe> doing that will mainly just attract people complaining the implementations are not constant time

23:12 <achambe> or not fast enough

23:12 <achambe> etc etc.

23:13 <achambe> go ahead if it is just for fun though.