19:06 <skyfex> andrewrk: Btw, the reason I asked about the self hosting compiler vs C++ source... i was thinking about trying to contribute, but wasn't sure which one would be best to work on

19:13 <andrewrk> skyfex: well the self hosted one would certainly be the most fun :-)

19:13 <andrewrk> I think the self hosted one because it's not super complicated yet

19:13 <andrewrk> And it doesn't have arbitrary decisions in it that make it hard for people to understand the code

19:14 <andrewrk> Whereas I've allowed the c++ code to accumulate some cruft

19:14 <andrewrk> E.g we could work towards zig fmt in the self hosted compiler pretty easily

19:16 <skyfex> Once the self-hosting compiler is done, have you thought about generating C code from Zig code, instead of maintaining the C++ version? There is this WIP LLVM C backend I think

19:17 <andrewrk> skyfex, I don't think that solves the problem it purports to solve

19:18 <andrewrk> one of the reasons to keep the c++ source and never delete it is for package maintainers that want to bootstrap the compiler, proving that there is no backdoor

19:18 <andrewrk> http://wiki.c2.com/?TheKenThompsonHack

19:19 <skyfex> ah, good point

19:19 <andrewrk> rust has a crazy complicated bootstrap process that involves dozens of steps

19:19 <andrewrk> in zig it will always be the 3 steps outlined in the current README

19:20 <andrewrk> the downside is we forever have to maintain the c++ compiler

22:08 <jfo> andrewrk: got that error test to work! I really would like something like `expect` though for asserting errors in testing

22:08 <andrewrk> we probably will never have that

22:08 <jfo> https://github.com/jfo/zigf/blob/master/bf_tests.zig#L65-L85

22:09 <jfo> why not? will you stick with just assert?

22:09 <andrewrk> that looks pretty good

22:09 <andrewrk> jfo, you should panic if you get OutOfBounds when you expected Overflow

22:09 <andrewrk> and vice versa

22:10 <jfo> ok

22:10 <andrewrk> error.OutOfBounds => @panic("wrong error")

22:10 <jfo> couldn't I `else` that if I didn't need to treat different errors differently?

22:10 <andrewrk> it seems like running a bf program should probably only have the OutOfBounds error right?

22:11 <andrewrk> yeah you could, unless you want to assert to the compiler that these 2 are the only possible errors

22:11 <jfo> yes but the overflow happens before that would happen since the index gets decremented before I use it as an index

22:11 <jfo> whereas the upper bound doesn't overflow, so they are different errs

22:11 <andrewrk> error.Overflow is coming from std.math.sub. You could just do this: ptr = sub(u16, ptr, 1) catch return error.OutOfBounds;

22:12 <jfo> a distinction I wouldn't have considered without zig's pedantry :)

22:12 <jfo> ah yeah that's a good point

22:12 <jfo> gtg brb

22:19 <jfo> that's interesting how the og thrown error is an overflow but my program can treat it as an out of bounds, the errors are really malleable huh?

22:19 <jfo> I decide how I want to treat the throw

22:19 <andrewrk> exactly

22:19 <andrewrk> it's just an enum value

22:20 <andrewrk> using "try" to bubble up error codes is good for prototyping something. then when you get closer to finalizing an API, think more carefully about the possible errors you're returning

22:21 <jfo> can you talk about why you wouldn't want something like `expect(thing, error.Error)` to be shorthand for unwrapping the error and dealing with it in this way? Just in testing, of course. Somewhere you said we might get assert(err == error.Error), is that off the table too?

22:22 <andrewrk> assert(err == error.Foo) works now

22:22 <andrewrk> oh you mean if `err` is an error union and not an error set

22:23 <jfo> I fuzzy on the difference

22:23 <jfo> but in the first case, I would still have to unwrap it first, right?

22:23 <jfo> I'm* fuzzy

22:24 <andrewrk> you could write expect in userland

22:25 <jfo> not a bad way to say WONTFIX :)

22:25 <jfo> anyway, looking forward to the compiler thing tomorrow, do you have some thoughts on what you're covering?

22:28 <andrewrk> yeah I'm going to start with an overview of the pipeline, then do a round of questions, then show off a bunch of features

22:29 <andrewrk> I was thinking maybe I could get you on the phone, and pipe the audio into the stream

22:30 <jfo> maybe! I'm happy to play the idiot questioner. I'll be watching from a hacker space here, I might not have good privacy though

22:30 <jfo> I'll definitely be on the chat at the least

22:31 <jfo> I'm most interested in how the zig compiler interacts with llvm, and how and where they touch each other

22:32 <jfo> that and a general overview of the compiler structure

22:32 <jfo> brb

22:32 <andrewrk> yeah, I'll make that clear