00:26 <unique_id> scientes: if is comptime if its condition is comptime

00:26 <scientes> whats the syntax?

00:27 <unique_id> just the normal if syntax

00:27 <scientes> if (comptime foo) {]?

00:27 <unique_id> if (foo)

00:27 <scientes> but I want to put it in the if

00:27 <scientes> to make it clean

00:28 <scientes> like #ifdef HAVE_BAR

00:28 <unique_id> Example from documentation, this is comptime: const separator = if (builtin.os == builtin.Os.windows) '\\' else '/';

00:29 <scientes> having the comptime keyword there would improove readability IMHO

00:29 <scientes> like assert()

00:35 <andrewrk> scientes, that doesn't make sense from a scoping perspective

00:35 <andrewrk> you can put comptime in front of the if, but then the body of the if has to be 100% comptime

00:35 <scientes> I just want the if to be comptime

00:35 <andrewrk> whereas you probably want the branch to be comptime but put runtime code in each prong

00:35 <scientes> the condition

00:36 <scientes> its like #ifdef/#else/#endif

00:42 <unique_id> if (comptime expr) works

00:42 <unique_id> reminds me of c++: if constexpr(expr)

00:42 <scientes> oh ok

00:42 <unique_id> I just tried it, didn't know before :)

00:42 <scientes> should be in the docs

00:43 <scientes> (should have tried myself)

00:44 <scientes> is there a const for endianness?

00:45 <scientes> I can't find it in the source or docs

00:47 <unique_id> There's an entry in the docs called "Compile-Time Expressions" but it just shows this syntax: comptime {}, but there's a test case that shows "comptime expr" syntax. It does say that in the global scope all expressions are implicitly comptime

00:49 <unique_id> scientes: there is, one sec

00:51 <unique_id> if (builtin.endian == builtin.Endian.Little)

00:51 <unique_id> Little/Big

00:51 <unique_id> const builtin = @import("builtin");

00:53 <unique_id> it is in the docs btw :)

01:07 <scientes> oh there it is

01:46 <scientes> ugggh @memcpy() type checking is too much

01:46 <scientes> i'll go back to for () ||

01:46 <scientes> inline for () ||

02:38 <andrewrk> hm I think those docs are wrong

02:38 <andrewrk> nvm

02:39 <andrewrk> I might change @memcpy to allow non-u8 pointers

04:40 <scientes> andrewrk, yeah I think @memcpy should allow arbitrary pointers, its already unsafe with the non-overlap

04:41 <scientes> but yeah I don't need to use it

04:41 <scientes> I wrote a chacha20 implementation but there is still a bug or two cause i'm not getting the right results

05:45 <andrewrk> scientes, btw did you see std.mem.copy?

06:05 <kristate> back online from tokyo university

06:05 <kristate> 15pm JST

06:52 <kristate> andrewrk: thinking about breaking-up the loop into separate files for each platform. importing event.loop will import the correct implementation for each OS and we will test the unified API in several test blocks inside of event.loop -- there is just too much custom code between the platforms and with threads, I want to make sure we get this right.

06:53 <kristate> andrewrk: it's not as bad as you might imagine. only downside is if we find a bug in one implementation, we will have to make sure to track it down for each other files -- BUT, if we add the appropriate test case for that bug, we should be able to run against all implementations and if the bug does not show, then so be it

06:54 <kristate> andrewrk: I think that this is going to be important as we go forward -- defining the interface as tests in an index file, and then making sure the tests pass in each implementation

07:20 <andrewrk> kristate, I implemented the darwin file system stuff (not the watching yet) in my async-fs branch

07:20 <andrewrk> I went the other direction with it - not having different files

07:20 <kristate> andrewrk: yes, I see that -- but when we add FS watching in, things will get messy with CFLoopRun

07:20 <andrewrk> I think it's better to have the same function definitions and types in one file, and that can switch out and import os-specific files if necessary

07:23 <andrewrk> kristate, I see, alright my mind is open to your way

07:23 <andrewrk> sorry I gotta get some sleep, I'll be back in ~8 hours

07:24 <kristate> okay, yeah -- please rest well. I will try to get something hacked out with FS watch

09:09 <kristate> rebased on andrew's #1294 and reimplemented some things -- FSWatch is coming next ( https://github.com/ziglang/zig/pull/1333 )

14:02 <kristate> so I got the cfrunloop to loop with a C callback

14:02 <kristate> now I need to stuff the posixFsRun code into that callback, and if successful, we can start to do FSWatch specific functions

14:03 <kristate> all in the same thread

14:13 <kristate> Okay, it's working now inside of the loop -- need some way to add coreFoundation to every build

15:30 <kristate> andrewrk: morning!

15:40 <kristate> andrewrk: if one thread's promise handle is resumed in another thread -- what happens?

16:00 <andrewrk> kristate, morning

16:01 <andrewrk> it works - you can think of resume like a function call

16:03 <andrewrk> I looked at the core foundations stuff

16:03 <andrewrk> I don't think we need it. I think kqueue gives us everything we need

16:03 <andrewrk> and that works on the BSDs too

16:04 <kristate> don't get me wrong, I like kqueue and dislike having to do things apple-like

16:05 <kristate> kqueue can track individual files, but cannot track directories

16:06 <andrewrk> I'm pretty sure kqueue can track directories

16:08 <kristate> https://github.com/libuv/libuv/issues/387

16:13 <andrewrk> kristate, alright I caught up reading about this, looks like you're a step ahead of me

16:14 <kristate> I just want to implement the feature in the best and performant method, with the least amount of dependancies

16:15 <andrewrk> same

16:20 <kristate> https://github.com/emcrisostomo/fswatch#limitations

16:25 <andrewrk> kristate, alright so now the problems we need to solve are: ability to build against core foundation when cross compiling, and only depending on it when it's used

16:26 <kristate> andrewrk: agreed. I patched link.cpp, but I think we can do better

20:43 <MajorLag> hmm... TypeInfo doesn't have a []Type for Fn arguments. Have to use @ArgType still.

22:05 <MajorLag> man, comptime caching really ruins a lot of complex use cases.

22:05 <MajorLag> not even really that complex actually.

22:06 <MajorLag> things like "iterate over the pub defs of struct A and see if they have a matching name and type pub def in struct B"

22:47 <scientes> there is an avoidance of @import("std") in the standard library, so that it refers to its own version. However this has the problem that all the test are always run