00:13 <exarkun> arigato: But I have to guess what the compiler did when it built libc, right?

00:30 <arigato> yes it's not a portable solution

00:30 <arigato> using the ABI mode for a portable access to things like sockaddr_in is really not possible, because that's completely non-portable

01:18 <exarkun> makes sense, thanks

14:42 <cfbolz> I finally posted the "how is pypy tested?" blog post: https://www.pypy.org/posts/2022/04/how-is-pypy-tested.html

16:56 <Corbin> I liked the blog post.

17:00 <mattip> +1

18:14 <krono> neat post!

19:03 <Corbin> I have a problem and I'd like to make sure I understand my solution before implementing it, because I'm lazy. I have a functional environment where I build up a big thunk of functions representing an iterative process, and then evaluate the thunk on an input value.

19:05 <Corbin> This is slow, despite JIT. My JIT driver is on the loop which builds the thunk (and any other loop). The JIT sees me build the thunks. But it doesn't know that that iteration is related to the evaluation of the thunk. As a result, I get JIT traces in the thunk which include a guard after every iteration of the loop; I get a new JIT compilation for every new number of iterations taken before exiting the loop early.

19:07 <Corbin> My current hope is that I can compile to bytecode (CAM in my case, kind of like OCaml) and change my JIT driver to operate on bytecode with an instruction pointer, like other RPython interpreters. This would let the JIT uniformly see the entire process. Does this make sense?