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
jacob22 has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
xcm has quit [Read error: Connection reset by peer]
xcm 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
_whitelogger has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
lritter has quit [Ping timeout: 268 seconds]
lritter_ has joined #pypy
CrazyPython has joined #pypy
_whitelogger has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
CrazyPython has joined #pypy
lritter_ has quit [Ping timeout: 258 seconds]
CrazyPython has quit [Read error: Connection reset by peer]
dddddd has quit [Remote host closed the connection]
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
<kenaan> rlamy py3.6 b195c68558a4 /pypy/: Add @pytest.mark.pypy_only to simplify skipping PyPy-specific app-level tests on CPython
<kenaan> rlamy py3.6 3811ac3540f6 /pypy/: hg merge default
_whitelogger has joined #pypy
zmt00 has quit [Ping timeout: 260 seconds]
zmt00 has joined #pypy
jacob22 has quit [Ping timeout: 268 seconds]
oberstet has joined #pypy
jacob22 has joined #pypy
jacob22 has quit [Client Quit]
jacob22 has joined #pypy
<kenaan> mjacob extradoc 64eca22e807a /sprintinfo/leysin-winter-2020/people.txt: Update dates.
kirma has joined #pypy
vstinner has joined #pypy
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
<Dejan> Interesting stuff
<cfbolz> Dejan: I agree with the critique of llvm
<cfbolz> But imo all these approaches don't solve the real problems of making dynamic languages fast
ronan has quit [Remote host closed the connection]
ronan has joined #pypy
<Dejan> sure
<Dejan> I can't even argue about these things as I am not competent enough, but I found the article interesting
<Dejan> I can't even use GCC JIT legally as it is GPL licensed
<Dejan> so from that perspective, it is a good thing to have some alternatives
<Dejan> Also, I kinda disagree about digression that people should not invest in developing compilers, that GCC 8s 16% speedup is miniscule compared to GCC 3.1
<Dejan> I think 16% is a lot
<Dejan> because EVERYTHING is compiled with GCC and nowadays with Clang
<Dejan> so EVERYTHING benefits from those microoptimizations
ambv has joined #pypy
<tos9> cfbolz: which problems are those
<cfbolz> tos9: late binding, boxing of primitives, high allocation rates, complicated semantics, branchy control flow
<Alex_Gaynor> large number of hash table lookups
jcea has joined #pypy
vstinner has left #pypy [#pypy]
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
adamholmberg has joined #pypy
dddddd has joined #pypy
Smigwell has joined #pypy
jvesely has quit [Quit: jvesely]
lritter_ has joined #pypy
lritter_ has quit [Remote host closed the connection]
lritter has joined #pypy
<antocuni> ouch, the latest version of pip broke manylinux2010 wheels on pypy :(
<antocuni> so, with pip 19.3.1 I can install a manylinux2010 wheel; with pip 20.0.1 I can't :(
<cfbolz> Grumble
<antocuni> with pypy 7.2.0
<Dejan> yes, do not upgrade to 20
* antocuni checks with pypy 7.3.0
<Dejan> keep pip at 19.3 for a while
<antocuni> Dejan: is it a known issue?
<Dejan> yep
<antocuni> link?
<Dejan> let me find it
<Dejan> You will see my comment there too from 1-2h ago
<antocuni> I can't find your comment
<antocuni> but it seems a different kind of issue
<Dejan> 20.0.1 is broken, no doubt about it
<antocuni> yeah, but I wonder if it's broken in many ways
<Dejan> i went there because I got a weird import error
<Dejan> trying to import a non-existent internal module
<Dejan> so i immediately downgraded to 19.3 ;)
<antocuni> yeah, that's what everyone is talking about. But here I have a different problem, which is that it doesn't recognize my wheel as valid, even if it is
<Dejan> your problem seems like a different bug, indeed
<Dejan> i wonder how they test pip... ;)
jvesely has joined #pypy
jacob22 has quit [Ping timeout: 265 seconds]
zmt01 has joined #pypy
zmt00 has quit [Ping timeout: 248 seconds]
<antocuni> I filed an issue: https://github.com/pypa/pip/issues/7629
<phlebas> does pypy reimplement the reference cycle breaking from cpython for cpyext, or do you do something else?
<antocuni> I fear we don't do anything at the moment
<antocuni> there is the cpyext-gc-cycle branch, but I'm not sure what is its status
<phlebas> aha, that's why i wasn't finding code related to that on tip :)
<antocuni> the author is Stefan Beyer, I think he was working on this for his (master?) thesis, but I can't remember his IRC nickname right now :)
<phlebas> btw, we finally have hpy running the ultrajson example you have running at the same performance as pypy - but warmup is much worse ;)
<antocuni> wow, amazing
<antocuni> are you compiling it with a custom hpy.h, or loading the universal .so?
<phlebas> we're compiling with the same hpy.h, but we cannot load the universal so, because we need the bitcode. the `.so` we produce should work on PyPy, but not vice versa
<antocuni> the llvm bitcode, I suppose?
<phlebas> (the way we compile it is to tell llvm to embed the bitcode with the normal so - and when we run on graal it we just ignore the native parts)
<phlebas> yes, llvm bitcode
<cfbolz> antocuni: the are never running untrusted assembly
<cfbolz> they
<antocuni> ah, I missed this part
<antocuni> so you convert llvm's bitcode to assembly on loading?
<phlebas> no, we interpret it and JIT :)
<antocuni> wow
<antocuni> method jit?
<phlebas> yes
<phlebas> it takes a looong time to warm up
<cfbolz> we need more oooooooooooooooooooooooooooooooooooooos
<antocuni> :)
<phlebas> its nice for small-ish C functions, because we can inline those
<phlebas> for stuff like numpy, it doesn't really help, there's so much C code that is just too much to inline into the python caller
<antocuni> can you also inline callbacks? I.e., calling a small C function which calls a small python callback?
<phlebas> yes
<antocuni> nice
<phlebas> some of the cpyext api is implemented by calling back up into python, that's fairly fast
<phlebas> s/the/our
<antocuni> is the bitcode interpreter/JIT a generic part of GraalVM, or did you write it specifically for graalpython?
<cfbolz> antocuni: it's generic
<cfbolz> called 'sulong'
<antocuni> we should do the same :)
infinite has quit [Read error: Connection reset by peer]
<phlebas> antocuni: that would be interesting :) i'm not convinced anymore that llvm bitcode is the best abstraction for this, though. it's just not meant for an interpreter to consume. but implementing all of C (and the other stuff llvm supports) still seems even worse.
xcm has quit [Remote host closed the connection]
<cfbolz> antocuni: supporting cython via some bytecode, or the new epython sounds more reasonable
xcm has joined #pypy
<phlebas> i'm not sure i get the appeal of epython as a generic tool. as a replacement for cython, yes, but I read the proposal as a replacement for the c api
<phlebas> isn't that just re-iterating cffi?
<antocuni> cfbolz: yes, cython sounds like a good starting point for having the "correct" level of abstraction
<cfbolz> phlebas: I don't get it completely either
<antocuni> I think that the best summary for EPython is "a better cython"
<cfbolz> it sounds like "just cython, with better technology"
<cfbolz> but then why not refactor cython
<antocuni> I think it's a possibility
<cfbolz> might be that it's harder to find funding for that
<antocuni> IIUC, EPython is still a "generic" project: they know what is the final goal, they haven't decided yet how to get there
_whitelogger has joined #pypy
oberstet has quit [Remote host closed the connection]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
mattip has joined #pypy
<mattip> fwiw, we did discuss the pip change from using pep425.py to packaging.tags in the issue
<mattip> I guess I should have tried out a pip 20 release candidate before the release
<mattip> that change was the reason I wanted to push forward with 7.3, especially on windows
<mattip> the "python tag" changed from pp272 (where "pp2" is pypy 2.7 and "72" is the pypy version) to pp27 for python 2.7
<mattip> one "solution" is to request that the few pypy packages on pypi and antonio's index release both pip19-compatible and pip20 compatible packages for a whiel
jvesely has quit [Quit: jvesely]
k1nd0f has joined #pypy
jvesely has joined #pypy
jvesely has quit [Quit: jvesely]
<antocuni> mattip: ah, I didn't realize that the "7" in pp27 and pp272 were different kind of 7s :)
<mattip> yeah, confusing
<antocuni> yes, I think it is reasonable to build pip20 wheels
<mattip> sorry for the mess, I think I only tried reaching out on IRC about the change, not on the mailing list
<antocuni> not your fault, such things happen
<antocuni> I was confused because I also tried to build&install a wheel locally, without using my wheels at all
<antocuni> but probably I built it with pip19 and tried to install with pip20, so I didn't realize that you get different names even when you build
<mattip> maybe. But maybe there really is an issue?
<antocuni> what do you mean?
<mattip> if you use latest pip and latest wheel does building a wheel locally work?
<antocuni> let me try
<mattip> thanks
<antocuni> nope :(
<antocuni> if I do "pip wheel psutil" with pypy2 7.3.0 and pip 20.1, I get "psutil-5.6.7-pp273-pypy_73-linux_x86_64.whl"
<antocuni> note the pp273
<mattip> :(
<mattip> is the problem with wheel?
<antocuni> I don't know who decides what is the filename
* antocuni investigates
* antocuni also wonders when/why he became one of the pypy guys taking care of packaging, a topic which he hates 🤷‍♂
<mattip> heh
<antocuni> and of course finding the place which decides the filename is a mess
k1nd0f has quit [Quit: Leaving]
<antocuni> mattip: found the problem, it's in 'wheel': https://github.com/pypa/wheel/blob/master/wheel/pep425tags.py#L56
<antocuni> we explicitly tag wheels using pypy_version_info.minor if we are on pypy
<mattip> +1, that should be updated for the new scheme and is a bug
<antocuni> do you feel like submitting an issue?
<mattip> there should be no special casing pypy there
<mattip> ok
<antocuni> what about old versions of pypy, though? Will they stop working? :(
<mattip> well, they should keep using pip 19
<antocuni> well, it's not only pip, it's the "wheel package now
Smigwell has left #pypy [#pypy]
<mattip> that is vendored into pip
<antocuni> but ok, we need to pin it as well
<antocuni> no, it's not
<antocuni> I had to pip install wheel explicitly in order to build a wheel
<mattip> building wheels - yes, but there is also a vendored version in pip for installing wheels
<mattip> in pip/_internal
<antocuni> yes, but the problem I pointed out is for building wheels
<mattip> right, sorry, so for wheel building we must pin pip and wheel
<antocuni> if we "fix" the package wheel and do "pip install -U wheel", older pypy's which are using pip19 will build wheels that cannot install
<antocuni> yes exactly
<antocuni> what a mess :(
dddddd has quit [Ping timeout: 258 seconds]
<antocuni> thanks
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
adamholmberg has quit [Remote host closed the connection]
mattip has quit [Ping timeout: 265 seconds]
mattip has joined #pypy