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
tsaka__ has quit [Read error: Connection reset by peer]
tsaka__ has joined #pypy
nimaje has quit [Quit: WeeChat 2.7.1]
nimaje has joined #pypy
<Dejan>
Only 36 failed "own" tests in the 3.7 branch, that is quite impressive
<Dejan>
(linux64)
<Dejan>
you guys rock!
tsaka__ has quit [Ping timeout: 260 seconds]
Guest41 has joined #pypy
Guest41 has quit [Remote host closed the connection]
dddddd has joined #pypy
bitbit has quit [Quit: Leaving]
jacob22_ has quit [Read error: Connection reset by peer]
jacob22_ has joined #pypy
suhdonghwi has joined #pypy
suhdonghwi has left #pypy [#pypy]
suhdonghwi has joined #pypy
Smigwell has joined #pypy
<suhdonghwi>
Hello, I have a question. If I run a JIT RPython program with PYPYLOG flags, the log file is created, but it is just empty. Is there any solution for this?
<antocuni>
suhdonghwi: what is the exact value of PYPYLOG?
<suhdonghwi>
this is my command: `PYPYLOG=jit-log-opt,jit-backend,jit-summary:logfile ./target-c test.hn`
<antocuni>
what happens with PYPYLOG=:logfile ?
adamholmberg has joined #pypy
<suhdonghwi>
Oh, running with `PYPYLOG=:logfile` gives me some result. Thank you @antocuni !
<antocuni>
does it include jit-log-opt&co. sections?
<suhdonghwi>
ah it seems like it only includes GC result
<antocuni>
then the most likely explanation is that your test program does not start the JIT
<antocuni>
maybe it runs for too little time?
<suhdonghwi>
Program itself runs for about 60 seconds.. so maybe my JIT code is not correct?
<antocuni>
I don't know but it's a reasonable explanation
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
jcea has joined #pypy
jvesely has quit [Quit: jvesely]
<suhdonghwi>
Still, my JIT log is empty, but I cannot find what is wrong with my JIT code. Is there any way to check current JIT status?
<antocuni>
yes, by looking at PYPYLOG :)
<suhdonghwi>
that's a sad fact..
<antocuni>
how do you use jit.hint? And, are you sure to have enabled jit during translation?
<suhdonghwi>
What do you mean by jit.hint?
<suhdonghwi>
like jit_merge_point?
<suhdonghwi>
and yes, i have enabled jit with --opt=jit flag
<antocuni>
yes sorry, I meant jit_merge_point
<suhdonghwi>
yes, i placed it at the start of the loop
<antocuni>
one possibility is that you are not reaching it often enough, or that you are calling it with "wrong" arguments so that the JIT never sees the same merge point enough times
<suhdonghwi>
and i also used can_enter_jit hint
<suhdonghwi>
oh, that is reasonable. maybe i abused green and red variables. thank you!
<antocuni>
the JIT kicks in when it sees the same green variables N times (where N is 1039 by default, I think)
<antocuni>
also, you should be able to write a test which JITs your programming language WITHOUT requiring a full translation
<suhdonghwi>
in those kind of tests, how can i check if JIT is running as I expected?
<antocuni>
suhdonghwi: you can put print statements and pdb.set_trace() in various parts of rpython/jit/metainterp/
camelCaser has quit [Ping timeout: 265 seconds]
<antocuni>
a good starting point is e.g. warmstate.py:maybe_compile_and_run
camelCaser has joined #pypy
<antocuni>
which calls bound_reached when you hit the threshold
<antocuni>
although it has been years since the last time I looked into that code, so please verify that what I say it's true :)
<suhdonghwi>
now looking at warmstate.py and i think you are still correct :D thank you again!
<antocuni>
you're welcome
YannickJadoul has quit [Quit: Leaving]
suhdonghwi has quit [Remote host closed the connection]
<mattip>
tumbleweed: any thoughts on how to update virtualenv to avoid the too-old-pip bug?
<tumbleweed>
I don't see anything obviously wrong in that bug description
<mattip>
the problem is that python2-pip on 16.04 is so old it cannot ignore the python3-only setuptools
<mattip>
so it pulls down a too-new setuptools that doesn't support python2 anymore
<mattip>
virtualenv -> install and upgrade pip/setuptools via pip -> gets the wrong setuptools
<mattip>
so either virtualenv should limit the setuptools it installs, or python2-pip needs an upgrade
oberstet has quit [Remote host closed the connection]
oberstet has joined #pypy
<tumbleweed>
ah, I didn't know pip knew how to ignore that
<mattip>
yeah, the key is "the system pip is too old to respect Python-Requires"
jvesely has joined #pypy
<tumbleweed>
not a whole lot we can do about that
<tumbleweed>
updating pip would certainly break things for some users, too
<tumbleweed>
so, it probably has to be an optional update, like a backport
<mattip>
well, virtualenv is definitely broken now. Can you change it to pin setuptools?
<tumbleweed>
why do you say it's definitely broken now? It's just not doing the right thing if you say pip install setuptools. But it's behaving exactly as it behaved in 2016f
<mattip>
it is installing a different version of setuptools into the fresh virtual environment than it did two months ago
<tumbleweed>
it shouldn't be doing that
<mattip>
by default
<mattip>
right, that is where the issue started: before the Jan 2020 release of setuptools/pip, everythin just worked. Now it is broken
<tumbleweed>
wait
<tumbleweed>
the virtualenv already has a setuptools
<tumbleweed>
the user is trying to install a newer one
<tumbleweed>
but doesn't need to be doing that
<mattip>
the issue report is misleading: pip install setuptools should be "pip install pytest"
<tumbleweed>
ah, but it has 45, which is from 2020
<mattip>
the point is two lines down:
<mattip>
Requirement already satisfied: setuptools in /venv/lib/python2.7/site-packages (45.0.0)
<tumbleweed>
yeah, but that's entirely expected behavior
<tumbleweed>
pip install pytest works just fine
<mattip>
hang on, I want to check what I understood: that "virtualenv venv" installs setuptools 45.0.0
<tumbleweed>
it appears to, yes
<tumbleweed>
but 45.0.0 is fine. The user is claiming it installs 45.2.0, which would be less fine
<mattip>
ahh, got it, thanks.
<mattip>
so users should change their workflow to not do "pip install setuptools": either pin setuptools or upgrade pip before hand
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<tumbleweed>
mattip: pip is already the latest version
<tumbleweed>
I really don't know what the user is expecting here, but everything seems to be working
<mattip>
weird
<tumbleweed>
my best guess is that they want pip install setuptools to noop
<tumbleweed>
aha, no 45.0.0 is not supposed to be compatible with 2.7
<mattip>
that makes more sense
<mattip>
so virtualenv is installing a setuptools that python cannot use
<tumbleweed>
well, theoretically
<tumbleweed>
in practice, it seems to work for installing packages
<mattip>
right, but not for building packages with c-extensions
<mattip>
or using cython, or ..
<tumbleweed>
yeah, haven't tried any of those
<tumbleweed>
I assumed when it was installing 45.0.0 rather than 45.2.0 that that meant it was checking Python-Requires
shunning has joined #pypy
<shunning>
hey guys, just want to ask what is the de facto way to copy an rbigint
<shunning>
result = rbigint(digits[:], sign)
oberstet has quit [Remote host closed the connection]
<shunning>
or just `result = rbigint( source.digits[:], source.sign, source.size)`
shunning has quit [Ping timeout: 260 seconds]
shunning has joined #pypy
<shunning>
i did not find any code in the whole pypy repo that copies an rbigint directly
__pv has quit [Remote host closed the connection]
<cfbolz>
shunning: usually you don't need to
shunning has quit [Remote host closed the connection]
lritter has quit [Quit: Leaving]
Smigwell has left #pypy [#pypy]
SunDwarf has quit [Ping timeout: 265 seconds]
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
SunDwarf has joined #pypy
adamholmberg has quit [Ping timeout: 255 seconds]
CrazyPython has joined #pypy
CrazyPython has quit [Remote host closed the connection]