06:01 <arigo> mjacob: however, we'd loose other general optimizations on bytearray, which would make some pure python codes perform worse

06:02 <arigo> notably jit-related

06:02 <arigo> so I don't think it's a good idea

06:04 <arigo> or maybe you have in mind to use internally lltype.Array when translating for revdb, but keep the rlist otherwise?

06:05 <arigo> might work with enough translation-time if's

06:06 <arigo> and full testing of course

06:08 <arigo> for revdb, the noticeable difference would be that all data read from *all* bytearrays would always be logged; it might be fine though

06:10 <arigo> what I had in mind was something meta (so no changes in bytearrayobject.py) applied at translation-time to the special kind of rlist present in bytearrays, where it would keep a flag that says "I've taken the raw address of this", and then it would record reads from the bytearray only if the flag is set

07:29 <mattip> I changed the format of the header at buildbot.pypy.org to squeeze in the 3.9 build summary link

09:46 <Dejan> 👍

10:46 <mattip> if I recall correctly, speed.pypy.org cannot show more than one pypy version in the bar graph at the bottom

10:46 <mattip> it would be nice to see pypy3.7, pypy3.8, pypy3.9

11:24 <Dejan> wow, only 13 faled, own tests for 3.9, impressive :)

11:31 <cfbolz> Dejan: the lib-python ones are the important ones ;-)

11:33 <Dejan> yea, those do not look bad either, just 130F

13:30 <cfbolz> Yeah, we've done the first 90%, what is missing are the other 90%

14:52 <mjacob> arigo: yes, i was assuming that there's a good reason for using rlist, so i thought of doing this only when running revdb. but of course your idea is nicer and much more pypy-like.

22:48 <mattip> on pypy, int[int] raises an AttributeError about no __class_getitem__

22:49 <mattip> on cpython, even 3.8, maybe earlier, this raises a TypeError 'type' object is not subscriptable