01:17 <GitHub82> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxdmb

01:17 <GitHub82> zig/master 4545be3 Andrew Kelley: fix std.io.readline to work on windows...

02:46 <relatingdata> reading documentation: is there a "do" - "while" in zig like "repeat" - "until" ? the for loop looks like a map over an array or range in languages like lisp/scheme/javascript ?

02:47 <achambe> andrewrk: was thinking about your http demo after reading some ipfs issues regarding unbounded memory growth. The explicit allocators in zig let you do some cool thing around upper memory limits on servers.

02:48 <achambe> max_concurrent_requests * max_memory_per_request = stable server

02:51 <achambe> really need to pick a small scale project to do in zig

02:52 <achambe> oh, comptime sqlite bindings would be cool too

02:52 <achambe> so many things :D

05:08 <heakins> What's the most concise way to perform a loop n times?

05:09 <heakins> I guess it's "var i: usize = 0; while(i < n) : (i+=1) {...}"

12:05 <MajorLag> I think I have nested comptime too deeply. A comptime struct initializer inside a comptime type generator inside a comptime type generator doesn't recognize itself as a valid return type.

12:08 <MajorLag> and @typeOf(this) as a substitute crashes.

12:24 <MajorLag> I can probably work around this with some refactoring, which I have to do anyway because the first pass way of doing things caused it to depend on itself anyway, messing up the entire API.

12:26 <MajorLag> for instance making things like this necessary: [][]const u8{"rotation"[0..]})[0..]

13:28 <alexnask> Is there any way to get a slice of the types of a vararg parameter at comptime?

13:34 <hopppetosse> alexnask: could you use @typeOf(args[n]) to get each individual type and build an array out of that?

13:36 <alexnask> Good point :P I wanted to use it to pass them to a return type function, e.g. a make_tuple function that would take varargs and return a Tuple([]type) from the varargs

13:36 <alexnask> I guess I could just use an intermediate function

13:36 <alexnask> Not sure, I'll give it a go

14:13 <commander> file:///run/media/commander/USB DISK/Zertifikat_SUAF_2016.docx

14:13 <commander> file:///run/media/commander/USB DISK/Zertifikat_SUAF_2017.docx

14:13 <commander> oops :D

14:14 <commander> sorry about that

15:01 <GitHub19> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxFCZ

15:01 <GitHub19> zig/master 477ded9 Andrew Kelley: add missing call in zig fmt to commit results to disk

15:22 <andrewrk> MajorLag, I'll get to your PR today. sorry about the delay

15:41 <MajorLag> no rush, it's just a bunch of syscalls.

16:17 <MajorLag> huh, more weird windows Debug issues. This time it works in release-safe when it shouldn't and crashes debug when I expect a panic.

16:28 <andrewrk> I would focus on the crash in debug mode first

16:34 <MajorLag> well I know why it's crashing I guess, I'd hoped it wouldn't but the problem with accessing memory for a guard value is that the region you're trying to access may not actually be mapped. I guess that explains why it works under other seemingly random conditions too.

17:19 <MajorLag> so I guess that whole saftey paradigm is flawed. I was hoping it would at least work for the stack.

18:24 <andrewrk> MajorLag, I still don't understand why your safety field doesn't work. because that field should be in a mapped page right?

18:25 <andrewrk> oh I'm looking at it again

18:26 <MajorLag> yeah, I'm not really certain how it is happening myself. Stack guards? If the interface gets separated from the parent, sometimes the stack happens to still have the parent there, other times it doesn't and something is catching that and throwing an OS exception.

18:26 <andrewrk> oh, yeah that makes sense

18:27 <MajorLag> but that seemingly random behavior doesn't make the pattern very useful, unfortunately.

18:47 <andrewrk> I wonder if there's another way to accomplish this kind of runtime safety in debug mode, if we were willing to add in some kind of extra runtime

18:56 <MajorLag> Maybe, it looks like LLVM implements the stack guard protections? Maybe there's a way to hook in to that. On the heap you'd need to deal with SEH on Windows and catching SIGSEGV on Linux.

18:59 <andrewrk> MajorLag, I'm thinking something more language level

19:00 <andrewrk> for example: since we don't guarantee struct size: every struct could contain an extra field which is a boolean, whether it was initialized in stack memory. The `return` statement could generate code that makes sure that if we're returning a pointer to a struct, the struct is not stack allocated

19:00 <andrewrk> there are flaws in this example, but that's the kind of thing I'm thinking of

19:05 <MajorLag> Hmm... couldn't you check the pointer at return to see that it isn't pointing to a stack frame that's about to disappear?

19:06 <andrewrk> that's a good idea

19:07 <andrewrk> I know we at least have ability to get the frame pointer. I wonder how to determine the end of the frame

19:07 <andrewrk> http://llvm.org/docs/LangRef.html#llvm-frameaddress-intrinsic

19:08 <andrewrk> oh, we could call a noinline function that returns @frameaddress()

19:08 <andrewrk> that one thing could catch a lot of mistakes

19:08 <andrewrk> this is a great idea

19:09 <MajorLag> I think your proposal about enforced cleanup semantics might be relevant too. If I init(), and don't deinit() or say that I'm going to do it later, that would be a catch at compile time that I'm probably doing something wrong. I don't particularly like the extra keywords and related additions to fn definitions, but I can see how it'd be useful here.

19:10 <andrewrk> yeah, you'd mark a function as "caller must acknowledge cleanup responsibility"