antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
<ctismer>
but I can't find a mention of it in the blog. In their stuff I find something, but it sounds very wrong, PyPy-wise
<antocuni>
ctismer: hi, long time no see :)
<antocuni>
yes, nuitka approach is very different than pypy's one; also, AFAIK it's a one man effort
<ctismer>
antocuni yeah, I thought to say "Hello": Hello
<antocuni>
what he managed to do is impressive
<antocuni>
but still, it's basically yet another instance of the pattern "almost python but not completely"
<ctismer>
ok, so for one man this is great. Ah, is that so? He made some 1005 claim, which I didn't believe...
<ctismer>
100%
<antocuni>
yes, I also don't believe 100% claim, but I have to admit I didn't try
<antocuni>
also, last time I heard about it was like 2 or 3 years ago, not sure what happened in between
<ctismer>
anyway, I've read your marvellous "How to make your code 80 times faster".
<antocuni>
thanks :)
<ctismer>
Ok, so I can ignore it, thanks :)
<ctismer>
I mean Nuitka. Probably way more compliand than Cython, but no alternative to PyPy.
deadc0de has joined #pypy
<antocuni>
what are you doing nowadays, btw?
<deadc0de>
heya - got a windows cffi issue, hoping someone can help me out :)
<deadc0de>
I've created a wrapper for a .a/.lib that I want to use in python, got it working on OSX and Linux, on Windows however I get an error about unresolved external symbols
<deadc0de>
the issue seems to be that cffi generates an __imp__foo() with two _ before the fn name, whereas the exported name in the .lib is __imp_foo()
<deadc0de>
has anyone seen this before and know how to fix it?
exarkun has quit [Read error: Connection reset by peer]
<ctismer>
antocuni Well, I'm the maintainer of PySide2, the bridge between Qt5 and Python. I did the initial port for Autodesk, and then I got a contract with QtC, because the project became a first-class citizen of Qt land :)
<antocuni>
deadc0de: sorry, no clue about windows stuff. You should probably ask arigato when he's here
<antocuni>
ctismer: cool thing about pyside. Please port it to PyPy :)
<LarstiQ>
ctismer: alongside PyQt, or did it take over?
<deadc0de>
antocuni: C on windows is a massive nightmare, don't understand why people keep doing it ...
* antocuni
off for lunch, see you later
<ctismer>
antocuni that's my hope, of course. But will take a looong route. Probably a loose interface that does not accelerate
exarkun has joined #pypy
<ctismer>
LarstiQ it parallels PyQt. It gets direct support by three Qt people + me, so it is trying to get over its 5-years waiting for someone to pick up (me). We have lots of work and will do the first release in mit 2018.
<ctismer>
mid
<LarstiQ>
awesome!
antocuni has quit [Ping timeout: 250 seconds]
<ctismer>
LarstiQ In the end, I think we will take PyQt not only by providing an affordable license, but we will try to do better. There are actually spots where we are far more correct. And I implemented full __signature__ support, that almost no known C(++) extension seem to have, yet (Cython has)
<deadc0de>
can anyone point me to how to tell cffi to build a 64 bit windows library?
<deadc0de>
I'm trying to link to a 64bit windows lib and it blows up
deadc0de has quit [Quit: leaving]
Rhy0lite has joined #pypy
hubert0 has quit [Remote host closed the connection]
antocuni has joined #pypy
cstratak has quit [Remote host closed the connection]
<ctismer>
antocuni I am sad to read that STM was dismissed. But it is good to know that it is a quite costly idea.
<ctismer>
I did not expect that the GIL would be seriously tackled. Whow great ;-)
<antocuni>
you should talk with arigato about this, I don't really know much about STM
<antocuni>
about the GIL, there is another branch to try a completely different approach, which basically boils down to "we remove the GIL and then you are on your own"
slackyy has quit [Ping timeout: 240 seconds]
<antocuni>
ctismer: how does pyside2 work? Does it use a binding generator to create the CPython extension?
<ctismer>
antocuni Yes, it uses "shiboken", which is a bit like PyQt's "sip". Unfortunately written in C++
<antocuni>
ah, shiboken is the same as PySide, isn't it?
<ctismer>
shiboken creates PySide
<antocuni>
yes, and PySide2 uses shiboken as well
<antocuni>
got it
<ctismer>
Yes. it runs through all C++ headers, uses a complicated data structure and generates ugly source code.
infernix has quit [Ping timeout: 240 seconds]
<antocuni>
ok
<ctismer>
would be an interesting challenge to create PyPy wrappers instead of Python wrappers, to avoid the refcount-dance
<ctismer>
but maybe that would be like NumPyPy? A PyPySide2...
mattip_away has joined #pypy
<antocuni>
I see two main options
<antocuni>
1) generate cffi bindings instead of bindings based on CPython C-API
<antocuni>
2) use cpyext to import them as-are
<antocuni>
note that cpyext is becoming more and more compatible and fast nowadays
infernix has joined #pypy
<antocuni>
and that e.g. now we recommend using the upstream numpy instead of numpypy
<fijal>
ctismer: hi christian!
<ctismer>
fijal Hi Maciej!
<fijal>
ctismer: see private message
<ctismer>
antocuni Oh really! You are very very far...
<fijal>
antocuni, ctismer: we have a plan to remove the GIL less crazy
<fijal>
but it would need to be expensive
<fijal>
antocuni: 3) use cppyy
tos9 has quit [Read error: Connection reset by peer]
<ctismer>
fijal aha :-D
<fijal>
our general take is "if it's not worth 100-200k to anyone, then it's not really a problem"
<ctismer>
good point! And you have reached that state? Great
<fijal>
Well it's not worth that much to anyone
<fijal>
Seems
<fijal>
And it would be quite a hassle to do too
<mattip_away>
deadc0de: (for the logs) use a 64 bit python, you cannot link 64 bit dlls into a 32 bit python
hubert0 has quit [Remote host closed the connection]
hubert0 has joined #pypy
hubert0 has quit [Ping timeout: 240 seconds]
zmt00 has quit [Ping timeout: 260 seconds]
marky1991 has quit [Read error: Connection reset by peer]
marky1991 has joined #pypy
zmt00 has joined #pypy
<kenaan>
rlamy py3.5 1233d5aa782f /pypy/objspace/std/stringmethods.py: Bail early in .startswith() and .endswith() is start is past the end of the string. This prevents an overflow, follo...
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
mattip has joined #pypy
hubert0 has quit [Remote host closed the connection]
hubert0 has joined #pypy
thisch has left #pypy [#pypy]
yuyichao has quit [Ping timeout: 258 seconds]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
hubert0 has quit [Ping timeout: 248 seconds]
<mattip>
dw: could you take the osx-10.9-x64-dw build slave off line - it cannot translate in its current condition
<dw>
mattip: done. btw i've still got that draft mail half finished ;) busy with other stuff just now
<mattip>
thanks, whenever you can get it back online would be greatly appreciated
marky1991 has quit [Ping timeout: 268 seconds]
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
hubert0 has joined #pypy
marky1991 has quit [Remote host closed the connection]
yuyichao has joined #pypy
tbodt has joined #pypy
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<mattip>
general question about weakrefs, in connection with matplotlib's connect_event('motion_notify_event', <bound method>)
<mattip>
connect_event ends up storing a weakref.ref(<bound method>.im_func) in a table,
<mattip>
but on PyPy that im_func dies after a while (shows up as <weakref at 0x00000000043a5640; to <dead>)
<mattip>
is this a new issue or expected behaviour? No cpyext is involved, these are pure python classes and methods
<mattip>
whoops - connect_event ends up storing a weakref.ref(<bound method>.im_self) in a table,
traverseda has quit [Ping timeout: 240 seconds]
yuyichao has quit [Ping timeout: 240 seconds]
traverseda has joined #pypy
yuyichao has joined #pypy
nunatak has quit [Quit: Leaving]
hubert0 has quit [Remote host closed the connection]
hubert0 has joined #pypy
hubert0 has quit [Ping timeout: 258 seconds]
slackyy has joined #pypy
yuyichao has quit [Ping timeout: 250 seconds]
<njs>
mattip: posted on your numpy PR, finally
<njs>
mattip: sorry for being so incredibly slow here, and thanks for your patience
<mattip>
np, thanks for picking it up
* mattip
working through the comments
<mattip>
njs: I guess I need to rebase, which will wipe out all the review history? Is that "best practices" for this situation?
<njs>
mattip: uh, not sure (either about whether it's best practice, or whether it wipes out review history)
<njs>
mattip: honestly I tend to just merge from master, though some people hate that for some reason
<njs>
I'm at a workshop for a academic data scientists, and hearing a lot of folks mentioning pybind11. should I be pointing them to cppyy instead? :-)
<mattip>
njs: ok, I will leave that for after approval
<mattip>
njs: my impression of pybind11 is like a modern boost python with all the layers and reflection, cppyy is built for speed
<njs>
ctismer: qt-on-pypy is a major blocker for getting the scientific python stack working on pypy... maybe at this point, the biggest/only major blocker?