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
jcea has quit [Remote host closed the connection]
adamholmberg has joined #pypy
jcea has joined #pypy
CrazyPython has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
jcea has quit [Ping timeout: 245 seconds]
adamholmberg has quit [Remote host closed the connection]
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
lritter has quit [Ping timeout: 250 seconds]
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
<kenaan> rlamy py3.6 17dfad3241f2 /pypy/interpreter/test/: Move app-level tests from test_generator.py to apptest_generator.py and simplify them
<kenaan> rlamy default 72f3423c43e5 /pypy/interpreter/test/: Move app-level tests from test_generator.py to apptest_generator.py
<kenaan> rlamy py3.6 94a7a1568272 /pypy/interpreter/test/: dummy merge from default
jvesely has joined #pypy
jvesely has quit [Client Quit]
jvesely has joined #pypy
adamholmberg has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
shodan45 has joined #pypy
inhahe has joined #pypy
<mattip> I think the linxu32 docker image is working well
<mattip> time to try it with the bencher4 linxu645 buildslave
jvesely has quit [Ping timeout: 250 seconds]
kipras`away has quit [*.net *.split]
eregon has quit [*.net *.split]
norox has quit [*.net *.split]
Lightsword has quit [*.net *.split]
trfl has quit [*.net *.split]
the_rat has quit [*.net *.split]
catern has quit [*.net *.split]
norox has joined #pypy
kipras`away has joined #pypy
catern has joined #pypy
eregon has joined #pypy
Lightsword has joined #pypy
trfl has joined #pypy
the_rat has joined #pypy
catern has quit [Max SendQ exceeded]
<mattip> the bencher4 machine is running debian7, which was EOL April 2016 and passed LTS support in May 2018
<mattip> before I start installing docker and building the image, do we want to request that they update the base OS?
<mattip> cfbolz any tohughts?
<cfbolz> We could ask ebarrett how annoying it is
ronan has quit [Ping timeout: 252 seconds]
catern has joined #pypy
kenaan has quit [Read error: No route to host]
oberstet has joined #pypy
<mattip> sent
<ebarrett> mattip: hi
_whitelogger has joined #pypy
kipras`away has quit [*.net *.split]
norox has quit [*.net *.split]
eregon has quit [*.net *.split]
the_rat has quit [*.net *.split]
Lightsword has quit [*.net *.split]
trfl has quit [*.net *.split]
Ninpo has quit [*.net *.split]
jerith has quit [*.net *.split]
gsnedders has quit [*.net *.split]
danilonc has quit [*.net *.split]
mwhudson has quit [*.net *.split]
michelp has quit [*.net *.split]
ccamel has quit [*.net *.split]
ammar2 has quit [*.net *.split]
danchr has quit [*.net *.split]
JStoker has quit [*.net *.split]
stillinbeta has quit [*.net *.split]
starlord has quit [*.net *.split]
mvantellingen has quit [*.net *.split]
Alex_Gaynor has quit [*.net *.split]
lauren has quit [*.net *.split]
nopf has quit [*.net *.split]
glyph has quit [*.net *.split]
antocuni has quit [*.net *.split]
rubdos has quit [*.net *.split]
samth has quit [*.net *.split]
ebarrett has joined #pypy
eregon has joined #pypy
Lightsword has joined #pypy
trfl has joined #pypy
kipras`away has joined #pypy
norox has joined #pypy
the_rat has joined #pypy
gsnedders has joined #pypy
jerith has joined #pypy
Ninpo has joined #pypy
danilonc has joined #pypy
panni__ has joined #pypy
simpson has joined #pypy
dnshane has joined #pypy
rubdos has joined #pypy
tazle has joined #pypy
bbot2 has joined #pypy
tsaka__ has joined #pypy
hsaliak has joined #pypy
holdsworth has joined #pypy
Dejan has joined #pypy
iko has joined #pypy
idnar has joined #pypy
Cheery has joined #pypy
dustinm has joined #pypy
danyspin97 has joined #pypy
mjacob has joined #pypy
fryguybob has joined #pypy
Kronuz has joined #pypy
SunDwarf has joined #pypy
wallet42 has joined #pypy
msjyoo has joined #pypy
petronny has joined #pypy
samth has joined #pypy
commandoline has joined #pypy
ctismer has joined #pypy
bogner has joined #pypy
webmeister has joined #pypy
DarkUranium has joined #pypy
<ebarrett> mattip: might also be worth doing an audit of running services
<ebarrett> rabbitmq and apache are running
<ebarrett> and some nfs-related stuff (idmapd)
krono has joined #pypy
<krono> Hi all.
<krono> For RSqueak, we are using a frame object (ContextPartShadow) with virtualizables.
<krono> In most pypytraces, we see several force_token, enter_portal_frame, and leave_portal_frame op combinations
<krono> how could I explain these three ops to somebody not too accustomed with RPython (I have already explained guards…)
<antocuni> krono: {enter,leave}_portal_frames are used only as markers by vmprof to reconstruct the python stack frame given a certain position in the assembler code
<krono> A cool. So I can declare them as noops "similar" to debug_mergepoint
<antocuni> they don't generate any assembler instruction, yes
<antocuni> look e.g. at jjt/backend/llsupport/assembler.py:enter_portal_frame
<krono> thanks :)
<antocuni> force_token... I never really understood what it does 😂
<krono> he
<mattip> ebarrett: sorry was away a bit. OK, and thanks for the mail
<ebarrett> np, let me know if you need anything
<arigato> "p1 = force_token()" returns the address of the jitframe into p1
<krono> that's necessary if something escapes, right?
<mattip> antocuni, arigato: do you mind if I update bencher4 to debian 10?
<arigato> mattip: sure, no problem from me
<arigato> krono: that's used only for the virtualizables and virtualrefs
<arigato> but yes, we store the current jitframe inside some special data structure in case something unexpectedly escapes
<krono> Thought so. I think in my explanation I will handle them in the same category as guards (as opposed to debug noops, arithmetic, and memory ops)
<krono> thanks y'all
<mattip> antocuni: ping
kenaan has joined #pypy
<kenaan> mattip buildbot ad9098b06ba1 /bot2/pypybuildbot/builds.py: aarch64 has timeout failures
lritter has joined #pypy
jvesely has joined #pypy
adamholmberg has joined #pypy
Rhy0lite has joined #pypy
<antocuni> mattip: pong
jcea has joined #pypy
<mattip> antocuni: do you have any issue with upgrading bencher4 to debian 10 (from debian 7)?
<antocuni> nope
<antocuni> I'm happy about it, I always have issues with sw on bencher4 being very old
<antocuni> I had to install my own version of gcc lately :)
<mattip> ok. Will it mess up your hpy progress if I do it over the next week or so?
<mattip> hmm, maybe I should do it the other way around: find some box where I can set up a docker-based linux64 build slave,
<mattip> get that working,
<mattip> only then take the bencher4 buildslave off line and upgrade it
<antocuni> I won't be working on hpy next week since I'll be in London
<mattip> ok. enjoy!
<antocuni> but in general, feel free to do it when you can/prefer. I only use bencher4 to make translations and benchmarks to avoid using my laptop
<antocuni> thanks
dddddd has joined #pypy
<arigato> slowly getting somewhere
<arigato> I think it's a deadlock caused by the import lock
<arigato> something like, you have multiple threads, thread 1 holds the import lock, thread 2 forks
<arigato> then in the subprocess created from the fork, the import lock is still held
<mattip> wasn't there already something like that once?
<arigato> yes
<mattip> probably more than once :)
<arigato> maybe :-)
<mattip> numpy also hangs in testing every couple of days on pypy3.6, it seems to happen during tests that are supposed to be single threaded
<mattip> maybe not connected at all
<arigato> :-/
<mattip> ronan had a small reproducer somewhere, in a gist
<arigato> we might have to blame 61469 (not sure yet)
<arigato> it adds logic in importing.reinit_lock()
<arigato> which looks a bit strange
<mattip> that was a while ago
<arigato> yes
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
jvesely has quit [Quit: jvesely]
<arigato> ...ok, wat
<arigato> importlib/_bootstrap.py implements *again* its own lock
<arigato> I have no clue how it's supposed to work in the presence of forking
<arigato> the word "fork" does not appear even in comments in the whole lib-python/3/importlib/
<antocuni> uh, I just discovered about "namespace packages" (PEP 420). I'm undecided whether they are a good idea or something which will result into a mess
<mattip> from 2009, an issue about forking and locks in stdlib, still open https://bugs.python.org/issue6721
<arigato> right
<arigato> so "importlib" is just broken in CPython too, as far as I can tell
<mattip> maybe I missed it, but I did not see a mention of importlib there
<arigato> probably just because it is older than importlib
<mattip> in 2019 they moved the discussion to https://bugs.python.org/issue36533, but still discussing mainly the logging module
<mattip> and here is one from ronan about importlib and test_threaded_import https://bugs.python.org/issue38095
<mattip> with no triage at all
jvesely has joined #pypy
ronan has joined #pypy
<arigato> AttributeError: module '_collections' has no attribute 'defaultdict'
<arigato> at the start of translation
<arigato> any clue?
<antocuni> arigato: _collections is a pure-python module in pypy, so maybe there is some circular import?
<antocuni> (assuming you are using pypy to run the translation)
<antocuni> I see it is importing threading
<arigato> ah, eventually understood it
<arigato> very very very indirect error
<antocuni> what was it?
<arigato> if you make some function in importlib/_bootstrap raise a TypeError, you get that
<arigato> or an AttributeError, more precisely
<antocuni> obvious
<antocuni> uh? Running a single cpyext test (test_boolobject:test_toint) takes ~30 seconds on default at ~2 minutes on py3.6
<antocuni> is it known/expected? If so, why it takes so much?
<arigato> it's known
<arigato> I don't know
<antocuni> it makes it basically impossible to do any kind of "iterative testing" :(
<arigato> the first thing I did when I was working on the py3.6 mozilla grant was speed up a lot running tests *everywhere*, they were taking forever too
<arigato> but I never got around to digging inside cpyext tests, which are slow for more reasons
<antocuni> I suspect issues related to the fact that importlib is at applevel and/or that it needs to import encodings, and things like that
lastmikoi has joined #pypy
<antocuni> btw, I'm trying to run "test_cpy_compat.py" in the hpy branch. I think that somehow I need to test machinery to compile an hpy module which includes the pypy's Python.h and then to somehow link it to cpyext's functions
<kenaan> arigo py3.6 21d58e234583 /pypy/module/imp/importing.py: Add comment
<arigato> I would probably try to make my own machinery without looking at what is in cpyext, but that may not be the best solution
<antocuni> well, we NEED to call inside cpyext (e.g. test_frompyobject calls PyList_New()), so we probably want the same logic to initialize all the stuff etc
<mattip> It would be really good to speed up the py3.6 tests
<antocuni> ah, it seems that cpyext's magic is done inside cpyext.api.load_extension_module
<antocuni> ah no, this is not very much, it's the "standard" function which loads .so modules even after translation
<antocuni> ah ok, the real magic is cpyexpt.api.build_bridge
<antocuni> impressive: it seems to be enough to just use the correct include file (which #define PyXXX to cpyexttestXXX) and to add 'cpyext' to usemodules and things seems to just work
<antocuni> apart the fact that now hpy tests take 2 minutes as well
tsaka__ has quit [Ping timeout: 276 seconds]
asmeurer has joined #pypy
tsaka__ has joined #pypy
Rhy0lite has quit [Quit: Leaving]
asmeurer has quit [Quit: asmeurer]
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
asmeurer_ has joined #pypy
jvesely has quit [Quit: jvesely]
marky1991 has quit [Ping timeout: 240 seconds]
marky1991 has joined #pypy
CrazyPython has joined #pypy
ronan has quit [Ping timeout: 276 seconds]
asmeurer_ has quit [Quit: asmeurer_]
marky1991 has quit [Ping timeout: 246 seconds]
jvesely has joined #pypy
CrazyPython has quit [Remote host closed the connection]
jcea1 has joined #pypy
jcea has quit [Read error: Connection reset by peer]
jcea1 is now known as jcea
marky1991 has joined #pypy
<energizer> i remember reading that __slots__ doesn't make much of a difference in pypy compared do cpython, is that generally right?
<simpson> Right. PyPy will enforce __slots__ behaviors, IIUC, but whether a class can be slotted is usually detected automatically at runtime.
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
<energizer> er i meant to ask, "does __slots__ cause a memory usage reduction in pypy comparable to the large reduction from __slots__ in cpython"
ronan has joined #pypy
<simpson> IIUC no, you should see the memory usage reduction just by using PyPy. For some pathological cases, __slots__ might still be desirable.
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
CrazyPython has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]