<tumbleweed>
hexology-: yeah, I just bootstrap with cpython these days
<tumbleweed>
(for debian)
<tumbleweed>
we used to have a pypy (2.7) package, and I built pypy3 with that while it existed, to save memory. But that isn't worth the effort if we don't provide pypy 2.7 to users
<tumbleweed>
it still builds fast enough, and memory isn't currently a problem
<hexology->
tumbleweed: i didn't realize pypy 2.7 was no longer provided publicly
<hexology->
how long / how much memory does it take on a modern machine? perhaps an m1 macbook at the office :)
hexology- is now known as hexology
jcea has quit [Ping timeout: 246 seconds]
<tumbleweed>
hexology: I mean, it isn't available publicly in Debian
<tumbleweed>
it'll build comfortably on 4GiB RAM machines
<tumbleweed>
that used to be a lot on the more embedded architectures, but now it's not something I worry about
<hexology>
tumbleweed: good to know. got a sense of how long it takes?
<tumbleweed>
the majority of the build is the test suite, these days. 2hrs total
<Guest60>
It's not a big deal for me at this point, because the JIT still manages to come in within a factor of 2 of handwritten rpython, but I was wondering if there are any known workarounds (or declarations?) that would enable me to suggest to the JIT that if it generates one code path, it might as well trace and generate bridges for sibling code paths
<Guest60>
while it's at it?
Guest60 has quit [Quit: Client closed]
commandoline has quit [Quit: Bye!]
commandoline has joined #pypy
commandoline has quit [Client Quit]
commandoline has joined #pypy
<cfbolz>
Guest60: two things you should do: IntBox also needs _attrs_ = []
<cfbolz>
Guest60: and could use a @jit.elidable
Dejan has joined #pypy
Dejan has quit [Client Quit]
<cfbolz>
Guest60: sorry, that was truncated! *fail* could use a @jit.elidable
Guest60 has joined #pypy
<Guest60>
aha, thanks for the clarification. will try later today
<Guest60>
I hadn't noticed `fail` in the traces and had assumed it was automatically getting elided due to `pc` being green. but I guess it's the call_i with a numeric identifier?