<cfbolz>
mattip: I think it started as a fork of the shootout
<cfbolz>
when they stopped running more than one implementation per language
<mattip>
it seems this is more "permissive" in terms of implementations
<mattip>
I see cython and even some cffi
<cfbolz>
mattip: yes, the shootout used to run pypy etc as well. but then somebody annoyed the maintainer and he ripped every "alternative" implementation out
<mattip>
Is this now the home of the shootout (renamed to "game")?
<antocuni>
TL;DR: they suggest to use cachegrind to get consistent results instead of real-world hardware. It seems that sqlite is using this to drive their performance
<antocuni>
I wonder how this applies to pypy
<fijal>
ugh
<fijal>
that seems... wrong?
<fijal>
like if it's slower on cachegrind, how much does that have of a real world predictive power?
<fijal>
(it does not aply to pypy because we run it on real hardware would be my answer)
<antocuni>
the article suggests to combine the number of cpu instructions + L1 cache misses + L3 cache misses using some formula which gives a reasonable approximation of real world performance
<antocuni>
maybe, but we also see a lot of variation between runs, which makes it hard to detect small improvements or slowdowns
lritter has joined #pypy
Atque has quit [Quit: ...]
<cfbolz>
there is recent research that is better at estimating cycles
<cfbolz>
but not sure it's a usable tool yet
<cfbolz>
I mean, turning cycles into seconds
Atque has joined #pypy
Julian has quit [Quit: leaving]
gef has quit [Read error: Connection reset by peer]
gef has joined #pypy
<mattip>
how much slower than real-time is the cachegrind emulation?
<mattip>
I guess you could use emulation for micro-benchmarks, but not for larger ones
stkrdknmibalz has quit [Ping timeout: 258 seconds]
jacob22 has quit [Quit: Konversation terminated!]
yuiza has quit [Remote host closed the connection]
yuiza has joined #pypy
Corbin has joined #pypy
Julian has joined #pypy
ronan has joined #pypy
yuiza has quit [Remote host closed the connection]
gef_ has quit [Ping timeout: 240 seconds]
Julian has quit [Ping timeout: 245 seconds]
Julian has joined #pypy
Julian has quit [Client Quit]
gef has quit [Ping timeout: 268 seconds]
Dejan has joined #pypy
gef has joined #pypy
gef_ has joined #pypy
yuiza has joined #pypy
yuiza has left #pypy [#pypy]
mathieu1 has quit [Ping timeout: 240 seconds]
ronan__ has joined #pypy
ronan has quit [Ping timeout: 245 seconds]
mattil has joined #pypy
ronan__ is now known as ronan
gef_ has quit [Ping timeout: 240 seconds]
gef has quit [Ping timeout: 245 seconds]
gef has joined #pypy
gef has quit [Ping timeout: 258 seconds]
<mattip>
there are 4 test files with 10 or more failures on py3.8:
<mattip>
should we drop idle from the release? Is it commonly used with pypy?
<mattip>
most of the unittest ones are "AssertionError: RuntimeWarning not triggered" in something around async
gef has joined #pypy
gef_ has joined #pypy
jacob22 has joined #pypy
mathieu1 has joined #pypy
<mattip>
ahh, that happens when the coroutine is finalized, so probably a missing gc.collect()
gef_ has quit [Ping timeout: 245 seconds]
gef has quit [Ping timeout: 248 seconds]
gef has joined #pypy
gef_ has joined #pypy
Guest27 has joined #pypy
<Guest27>
please don't drop IDLE from Py-3.8, better a buggy IDLE than no IDLE (and maybe no Tcl/Tk)
<Guest27>
py-3.8 nightly with Tcl/tk works ok enough with my pet package, sqlite_bro,
<Guest27>
and for basic stuff, like creating and runnin g a file with print("say : Please PyPy don't drop me out!"[5:]), IDLE works
<cfbolz>
Guest27: thanks, that's helpful
<cfbolz>
Guest27: would you be up to looking into the tk test failures though?
<Guest27>
how do I run them on my PC ?
<cfbolz>
Guest27: pypy3 -m test.test_idle
<cfbolz>
With a nightly from the 3.8 branch
<Guest27>
ok, on nightly from Juy29th, I get (failures=35, errors=8, skipped=1) for 579 tests
<Dejan>
There is one from few days ago
<Guest27>
on PyPy-7.3.5 same testing I get (failures=34, errors=6, skipped=1) for 566 tests.
<Guest27>
so I don't understand your sudden doubt about shipping IDLE with Py-3.8, as it passes more test than with Py-3.7
<Guest27>
as said, whatever the issues, they seem edge cases. and Tcl/Tk is already working well enough so I don't see an abvious problem in a pure Tcl/Tk/Ttk application
ronan has quit [Read error: Connection reset by peer]
<Guest27>
when I run the pypy3 -m test.test_idle , it's like if I was clicking on all buttons at non-human speed, so it can triggers bug that we don't meet in practice
lritter has quit [Ping timeout: 240 seconds]
ronan has joined #pypy
otisolsen70 has joined #pypy
Julian has joined #pypy
otisolsen70 has quit [Quit: Leaving]
<mattip>
Guest27: we could really use help figuring out what is failing. I don't think it is because of the speed.
<mattip>
Guest27: there is something a touch off in our cffi-based wrappers
mattil has quit [Quit: Leaving]
Julian has quit [Quit: leaving]
mathieu1 has quit [Ping timeout: 245 seconds]
stkrdknmibalz has joined #pypy
<Guest27>
cffi and Hpy requires an expertise I don't think I have.
Guest27 has quit [Quit: Connection closed]
<mattip>
Guest27: (for the logs), ok, thanks
<nimaje>
seems like idlelib.idle_test.test_help_about.LiveDialogTest.test_printer_buttons is just broken on pypy, because you only have one line for {licene,credits}._Printer__lines instead of the full text and the test considers less than 2 lines as fail (no idea why)