cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
speeder39_ has quit [Quit: Connection closed for inactivity]
jvesely has quit [Quit: jvesely]
<tumbleweed>
fijal: looks like that aarch64 jit issue is GC-related, the assertion is: RPyAssert(1, "'contains_weakptr' specified for a large object");
<arigato>
no, that really means "some random piece of code corrupted data"
<arigato>
or more likely, the traceback you're getting is bogus, because RPyAssert(1) cannot fail
xorAxAx has quit [Quit: Idle timeout reached: 172800s]
Ai9zO5AP has joined #pypy
jacob22_ has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
bendlas has quit [Write error: Connection reset by peer]
edd[m] has quit [Read error: Connection reset by peer]
agates[m] has quit [Write error: Connection reset by peer]
jacob22_ has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
bendlas has joined #pypy
tazle has quit [Ping timeout: 252 seconds]
tazle has joined #pypy
ekaologik has quit [Read error: Connection reset by peer]
mvantellingen has quit [Ping timeout: 246 seconds]
CrazyPython has joined #pypy
edd[m] has joined #pypy
agates[m] has joined #pypy
dddddd has joined #pypy
CrazyPython has quit [Remote host closed the connection]
CrazyPython has joined #pypy
tazle has quit [Ping timeout: 246 seconds]
tazle has joined #pypy
CrazyPython has quit [Remote host closed the connection]
gracinet has joined #pypy
<mattip>
so do we release without aarch64 py3.6?
jvesely has joined #pypy
CrazyPython has joined #pypy
<arigato>
I guess so
<arigato>
fijal is unlikely to have time and I'm not home until next weekend
<kenaan>
Yannick_Jadoul py3.7 02a99370f6b3 /pypy/: Implemented __mro_entries__ from PEP 560
<kenaan>
Yannick_Jadoul py3.7 01b4c2af5928 /pypy/: Fixed annotation errors related to fixed-sized lists, and added a test checking __orig_bases__ is only set w...
<kenaan>
rlamy py3.7 dff15039dbab /pypy/interpreter/: Merged in Yannick_Jadoul/pypy/py3.7-pep562 (pull request #670) Implementation of PEP 562, adding __getattr__ and __d...
<kenaan>
Yannick_Jadoul py3.7-pep562 bb000a053f9f /pypy/interpreter/: Implementation of PEP 562, adding __getattr__ and __dir__ for modules
<simpson>
Does anybody have any reading on the design of object layers? I've read PyPy's, but I'm still chewing through the general non-Python-specific concepts.
<arigato>
I have no clue about this one
<arigato>
I'm fine if you ignore aarch64 on py3.6
<arigato>
we can always add it later
<Alex_Gaynor>
simpson: you can go read topaz's if you want to see a ruby from a few years ago
<mattip>
if it is fixable, it would be better to delay the release
<arigato>
unsure I agree, but that will have to wait next weekend from my side
<simpson>
Alex_Gaynor: Oh yeah, that's another codebase I've read some of. Good idea, thanks.
<mattip>
hmm. Anyone else have an opinion?
<simpson>
mattip: From the downstream distro side, maintainers are quite okay with marking packages as broken/not-building/different-flags on aarch64.
<mattip>
simpson how do we let them know? I think once we tag the release, the downstream maintainers just pull that and build, no?
<mattip>
maybe a question for tumbleweed ^^^
<simpson>
mattip: If it fails hard enough, then yeah, maintainers will figure it out. It's still good to let people know what doesn't work.
<arigato>
and there's always the possibility that the two problems appear on aarch64 but is actually general, it just didn't show up so far
<cfbolz>
mattip: i am +0 to not shipping aarch64 3.6 and releasing soonish
<cfbolz>
We should document it in the release notes
<mattip>
arigato: agreed, that makes sense. Something about alignment checks that are creating collectable objects?
<mattip>
(not clear to me what the difference is between a function that triggers collection and one that doesn't, so ignore if that makes no sense)
<arigato>
not impossible
<arigato>
a function that triggers collection is just a function that gets a "malloc" operation in the end
<arigato>
in this case, the function returns a 4-tuple, but it should be inlined---but in this case it isn't
<mattip>
looking at that function, there is (misaligned_is_fine or (rffi.cast(lltype.Signed, addr_in) & 7) == 0)
<mattip>
but how can that cause a malloc?
<mattip>
ok, so agreeing with cfbolz. Let's see if I can formulate a "no aarch64 python3" messasge for the release note that does not convey "aarch64 is not ready"
<mattip>
something about "it works on the hardware we could test on" or so