06:58 <BrotherLy> ok would you guys have anything against pull requests that improve compile speed?

10:07 <BrotherLy> ponyc /home/pc/ponyc/main.pony

10:07 <BrotherLy> Building builtin -> /home/pc/ponyc/packages/builtin

10:07 <BrotherLy> Error: internal failure not reported

11:40 <SeanTAllen> depends on how that improvement in compile speed were to come about BrotherLy_. We welcome PRs. If something were to improve compile times and have no other impact, it would be accepted. What do you have in mind?

11:44 <BrotherLy_> nothing in particular, i was just wondering if you would accept PRs that change a lot of code to improve compile speed

14:06 <SeanTAllen> We are looking to stabilize things and compile speeds are not a primary goal at the moment so "a lot code", probably not. It would be a matter of what are the pros, what are the cons.

20:46 <DanC_> SeanTAllen, I'm translating code from another language (with more complex pattern matching) to monte, and it would be convenient to be able to declare several variables at the beginning of a block and assign to them later.

20:46 <DanC_> I would still respect "no access to uninitialized variables"

21:59 <ponysaurus> quick one: what's an idiomatic way to get the sizeof, say I64 in bytes?

22:04 <ponysaurus> using bitwidth and dividing by 8?

22:06 <jemc> ponysaurus: yes, the byte size of an I64 is 64 / 8 (= 8 bytes)

22:07 <ponysaurus> i was hoping for something like a.num_bytes()

22:08 <ponysaurus> jemc: does it make sense to have something like that?

22:08 <ponysaurus> i am testing a writebuffer implementation, and was hoping for a nice way to get the sizeof a number

22:44 <jemc> ponysaurus: given the limited number of integer types, it doesn't seem like a big burden to me to use a `match` statement with the types and bytesizes listed out in your code

22:45 <jemc> however, given that we also have variable sized native types `ISize`, `USize`, `ILong`, and `ULong` - it may make sense to add a method like you suggest for this reason