00:00 <achambe> hmm, fiddle with core counts?

00:04 <achambe> andrewrk: not sure if possible, but perhaps there is a recording debugger that works with windows. I think firefox was doing something like using 'rr' to record every test run, and on failure dumping the trace.

00:04 <achambe> though windows...

00:05 <andrewrk> I want to rule out the possibilty that appveyor is hanging because we're requesting too much memory or CPU power or something like that

00:11 <andrewrk> oh wow look at this

00:11 <andrewrk> Be careful when using Sleep in the following scenarios:

00:11 <andrewrk> Threads that are under concurrency control. For example, an I/O completion port or thread pool limits the number of associated threads that can run. If the maximum number of threads is already running, no additional associated thread can run until a running thread finishes. If a thread uses Sleep with an interval of zero to wait for one of the additional associated threads to accomplish some work, the process might deadlock.

00:12 <andrewrk> hmm, that should be fine actually

00:20 <GitHub71> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpgnW

00:20 <GitHub71> zig/master c186cd1 Andrew Kelley: std.atomic - use AtomicOrder.SeqCst for everything...

01:00 <andrewrk> achambe, wow - I just watched appveyor be stuck on std.atomic.queue for 20 minutes and then finish it. And then the next time it got to that same test, it finished it right away

01:01 <andrewrk> I think this could be a matter of asking appveyor for too many CPU cycles

01:16 <andrewrk> my best guess right now is that appveyor runs in a guest VM with 1 core and spawning 6 threads that are thrashing each other will eventually work, but is very slow

01:17 <andrewrk> and we're running that slow test 12 times (an extra 6 times on accident because compiler-rt is inadvertently running the std tests)

01:35 <andrewrk> ok I'm convinced now. it really is just 1 core thrashing and being slow (which is intentional for the test) and it's just too slow for appveyor

01:37 <GitHub6> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpgWP

01:37 <GitHub6> zig/master 02c1b9d Andrew Kelley: fix compiler-rt tests accidentally running std tests...

01:43 <GitHub182> [zig] andrewrk closed pull request #972: Fixed inlining determination test (master...nested_func_comptime) https://git.io/vpucC

01:43 <GitHub33> [zig] andrewrk pushed 1 new commit to master: https://git.io/vpgWp

01:43 <GitHub33> zig/master 131c133 Alexandros Naskos: Fixed inlining determination test (#972)...

01:58 <andrewrk> alright I think we're done with those appveyor failures

02:20 <achambe> neat

02:23 <achambe> Hopefully sometime I can automate more operating system installs - I would love a CI platform that just provided you with ssh to all the different operating systems and that was it. Each new ssh connection it just trashes the old vm or something

02:24 <achambe> need windows + linux + freebsd + mac + openbsd

02:25 <achambe> * arm

02:32 <andrewrk> that would be great

02:32 <andrewrk> we could start passing tests one at a time

02:42 <GitHub21> [zig] andrewrk opened pull request #979: add ReleaseSmall mode in zig tests (master...test-release-small) https://git.io/vpg40

03:11 <andrewrk> alexnask, I'll get to your @typeInfo PR after dinner

14:01 <GitHub145> [zig] BraedonWooding opened pull request #981: ArrayList iterator, unifying API of HashMap and its derivatives (master...ArrayIteratorUnifiedSyntax) https://git.io/vp2ZW

15:47 <GitHub160> [zig] andrewrk closed pull request #979: add ReleaseSmall mode in zig tests (master...test-release-small) https://git.io/vpg40

15:47 <GitHub82> [zig] andrewrk pushed 1 new commit to master: https://git.io/vp2w7

15:47 <GitHub82> zig/master 7337029 Andrew Kelley: Merge pull request #979 from zig-lang/test-release-small...

16:50 <alexnask> andrewrk, were optional argument names in the callsite ever considered for zig?

16:50 <alexnask> I think it can add a lot for code readability in certain places

18:09 <andrewrk> alexnask, https://github.com/zig-lang/zig/issues/484

18:09 <andrewrk> what do you mean "in the callsite"?

18:11 <alexnask> I mean something like: 'mem.copy(u8, src: some_slice, dest: some_slice);'

18:11 <andrewrk> ohh

18:11 <alexnask> Assuming the parameter names for mem.copy are src and dest

18:11 <andrewrk> I'm not sure there's a formal issue open for this. I'm open to the idea

18:11 <alexnask> Default values was another one I was going to ask about but I figured we woudn't have them in zig

18:12 <andrewrk> there's a pretty reasonable case to be made about named args at callsite preventing bugs

18:12 <alexnask> right, it's useful when passing arguments with the same types about

18:13 <alexnask> + the function name + argument names used can give you an even better idea of what the func is doing

18:14 <andrewrk> I wonder how reasonable it would be to require named args if there were more than 1 of the same type in the parameter list

18:14 <alexnask> I think that would be kind of extreme :P

18:15 <andrewrk> yeah probably

18:15 <alexnask> I'll open an issue in a bit

18:16 <alexnask> perhaps it will be a good feature to get acquainted with the parsing stage of the compiler too

18:16 <alexnask> (if it's accepted that is)