00:17 <jacobdufault> andrewrk: I fixed the issue where there was no output

00:17 <jacobdufault> now everything is unresolved, not sure why

04:10 <GitHub191> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxvLT

04:10 <GitHub191> zig/master 49c3922 Andrew Kelley: fix incorrect setEvalBranchQuota compile error...

09:31 <hoppetosse> andrewrk: is there a way for the compiler to output the code / memory dump with all the compile time evaluations applied?

09:39 <GitHub49> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxv4A

09:39 <GitHub49> zig/master 1bf2810 Andrew Kelley: fix comptime slicing not preserving comptime mutability...

10:11 <andrewrk> hoppetosse: can you elaborate? Are you trying to debug something?

10:18 <hoppetosse> The equivalent of outputting c source with all macros applied

10:19 <hoppetosse> Not yet, but I imagine I will

10:29 <hoppetosse> or maybe closer to outputting the template expansions in c++

10:33 <hoppetosse> I'm writing a text editor and eventually I'd like to be able to inspect comptime values while editing

10:34 <hoppetosse> I'm trying to plan how I'd do it and I thought that would be a very convenient way of having it

10:35 <hoppetosse> you could make a build, save the results as a zig file + data (or some sort of literal repr of the data in the source file)

10:35 <hoppetosse> and then it's just parsing

11:25 <andrewrk> hoppetosse, aha, ok you shall have that ability, but I think there's an even better way

11:25 <hoppetosse> There probably is =)

11:26 <andrewrk> the current plan is to have zig act as a server, providing the ability for tools such as editors to subscribe to updates

11:26 <hoppetosse> There's a bunch of other thoughts there - I eventually want to add a repl so another way would be to be able to query the comptime state

11:26 <hoppetosse> A zig server is pretty awesome XD

11:27 <hoppetosse> The thing I miss most is a little squiggle under the code when I forget a gosh darned semicolon

11:28 <andrewrk> indeed

11:37 <MajorLag> Interestingly, since I've stopped working with an IDE I find I don't really miss that at all. Guess I'm weird like that.

11:38 <andrewrk> MajorLag, I fixed comptime slice of slice and comptime slice of pointer dropping mutability. was there still another bug beyond that?

11:41 <MajorLag> Yeah, I saw. Thanks for that. Unfortunately yes, there's still something with, I think, memorizing values it shouldn't. So far my tests to reproduce it in simpler code have failed but I only put about half an hour into it. I rewrote the function to avoid calling the iterator and just do things itself and that works fine, but I kept the old code for testing. Also noticed this this morning: try is ignored at comptime

11:41 <MajorLag> wrap.

11:42 <MajorLag> `error: expected type '[]const u8', found '@typeOf(Iterator_consumeBOM).ReturnType.ErrorSet'

11:42 <MajorLag> _ = try iterSrc.consumeBOM();`

11:42 <andrewrk> what's the fn signature of consumeBOM() ?

11:43 <MajorLag> `pub fn consumeBOM(self: &Iterator) !u3`

11:44 <andrewrk> and you get that compile error when consumeBOM returns an error?

11:45 <andrewrk> the problem with inferred error sets at compile time is that the analysis doesn't find all the possible errors. it either finds the value that it returns, or it finds the one error that it returns

11:46 <MajorLag> yeah, in this case I believe it is throwing an error for the iterator position being wrong for consuming a BOM, which I'm thinking is because the pos has been memorized accross instances.

11:48 <MajorLag> ...actually that can't be true because the error is that it's expecting []const u8, so it must be being thrown farther down.

11:51 <MajorLag> ...except it is. replacing try with a catch @compileError reveals: error: UnicodeIteratorInvalidBOMPosForConsume

11:51 <andrewrk> MajorLag, 6db9be89 makes it so that if a function has any parameters whose type would allow mutating state (such as a non-const pointer), then it won't try to memoize it

11:53 <MajorLag> consumeBOM only takes a self: &Iterator, which has a member `pos`, and it only throws that error if pos > 0 when you run consumeBOM. So it's memorizing it for some reaosn.

11:53 <andrewrk> hmm I just thought of something else. let me try something.

11:54 <MajorLag> I'm really curious why it is expecting []const u8 from a !u3 if I use try though... that I don't get.

11:55 <andrewrk> that seems like a bug, at the very least for being a confusing compile error

11:57 <andrewrk> MajorLag, I think one of the problems you're hitting is this: https://clbin.com/w6Tru

11:57 <andrewrk> I'll type up an issue

11:59 <MajorLag> Maybe, though it should be using different instances of the struct. I'll be off to work in a few, I think that `try` problem at least I can write a trivial test case for.

11:59 <andrewrk> ok great. I'll get that and this fixed and then we can see where we're at

12:00 <andrewrk> hopefully I can get you through this comptime gauntlet into happy land

12:42 <GitHub105> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxvyQ

12:42 <GitHub105> zig/master 5834ff0 Andrew Kelley: don't memoize comptime fn calls that access comptime mutable state...

12:42 <andrewrk> MajorLag, ^ I think this might have fixed a lot of issues for you

13:24 <MajorLag> Sounds right. Let me check it out

13:27 <MajorLag> Huh, no, that doesn't seem to have done it.

13:27 <andrewrk> it's still getting memoized?

13:28 <MajorLag> it looks like that's the case, I'm still getting the same error as before.

13:28 <MajorLag> I'll see if I can narrow down the conditions.

15:16 <MajorLag> Every time I think I know what the problem is, a test case stubbornly refuses to fail.

15:17 <andrewrk> sorry, I know it's frustrating

15:18 <andrewrk> the small test cases are really nice, but I also don't mind looking at a bigger one

15:37 <MajorLag> I've got it pretty small now. I think I'm almost there. It looks like it has to do with passing references vs values. In runtime code you can't pass structs by value, but it looks like it works differently at comptime?

15:44 <MajorLag> Oh yeah, this is definitely it. Should have a pretty minimal test in a minute.

15:54 <andrewrk> exciting

15:54 <andrewrk> sounds related to #733

15:54 <andrewrk> which is blocking on the Pointer Reform issue

15:54 <andrewrk> I think Pointer Reform is going to be the first thing I do after releasing 0.2.0

15:59 <MajorLag> #828

15:59 <MajorLag> I'm excited about pointer reform.

16:56 <GitHub193> [zig] andrewrk pushed 1 new commit to master: https://git.io/vxfBz

16:56 <GitHub193> zig/master bcce777 Andrew Kelley: some return types disqualify comptime fn call caching...

16:56 <andrewrk> MajorLag, ^

17:24 <MajorLag> Yep, that seems to have done it. Thanks.

17:25 <andrewrk> now it's just the try / error set thing, yes?

17:26 <MajorLag> oh right, I forgot to make a test case for that. It isn't stopping my current code from working, it was just making it harder to debug. I'll get on that in a bit.

17:27 <andrewrk> ok great, glad to hear you are unblocked