rokujyouhitoma has quit [Ping timeout: 240 seconds]
<arigato>
ok, pfff
<arigato>
curses on the build machine is somehow not the "wcurses"-ready version
<arigato>
even if I fix it to add #ifdef workarounds, it is still one more issue of distributing binaries
ArneBab has joined #pypy
Ubuntu-BR has joined #pypy
ArneBab_ has quit [Ping timeout: 260 seconds]
<arigato>
wrong, cpython 3.4 succeeds in getting the wchar version of functions on that same machine
amaury has quit [Ping timeout: 260 seconds]
<arigato>
ok, pfff
<arigato>
in order to get the header for a couple of extra functions like unget_wch()
<arigato>
we need to install an additional package,
<arigato>
libncursesw5-dev on ubuntu
<arigato>
and then include a different file
<arigato>
we don't need that on Arch linux
<arigato>
and I *know* that we'll need some different workaround on *all* platforms
<kenaan>
arigo py3.5 518cd1383456 /lib_pypy/_curses_build.py: Obscuuure. On Ubuntu specifically, for ncurses on pypy3 we need: (1) apt-get install libncursesw-dev (2) add an in...
<kenaan>
arigo default c290c73933b9 /pypy/doc/build.rst: This package is needed on Ubuntu for PyPy3
<kenaan>
arigo default 4aebe6f15c48 /pypy/doc/build.rst: Name "Ubuntu" in addition to "Debian"
vkirilichev has joined #pypy
bjs has quit [K-Lined]
JStoker has quit [K-Lined]
tito has quit [K-Lined]
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
bjs has joined #pypy
JStoker has joined #pypy
<njs>
arigato: I'm sure you'll be happy to learn that fedora no longer ships curses 5 by default; they've moved on to curses 6
<arigato>
that's fine, as long as it keeps compatibility
<tumbleweed>
this is ncurses 6, the soname is libncursesw5
cstratak has joined #pypy
cstratak has quit [Remote host closed the connection]
cstratak has joined #pypy
marr has joined #pypy
rokujyouhitoma has joined #pypy
oberstet has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
<fijal>
the_drow: yes, I was going to "fix" it, by silencing those
squeaky_pl has joined #pypy
rokujyouhitoma has joined #pypy
Ganwell has joined #pypy
<danchr>
pypy3 5.8 has segfaulted on me a couple of times today…
<danchr>
might be due to my choice of OS
<Ganwell>
Hi, how do I correctly raise a python exception from CFFI bound C code?
<antocuni>
Ganwell: you cannot raise a Python exception from C; what you can do is to write a python wrapper which checks the C return code and raises the appropriate exception
rokujyouhitoma has quit [Remote host closed the connection]
<Ganwell>
antocuni: Really? With C extensions it works (PyErr_SetString). Shouldn't there be something equal?
<Ganwell>
antocuni: In a C extension, you return, but before you set PyErr_SetString.
<antocuni>
nope; the goal of cffi is to wrap C libraries which are NOT tied to the CPython's API
<antocuni>
so, you cannot use and Py*
* danchr
FWIW MacPorts now has binary packages of both PyPy and PyPy3 5.8.0
<Ganwell>
antocuni: ok. I will set some global char* err and raise an exception with it, if it is set. Thanks alot.
<antocuni>
yes, that's how I also did in the past; beware that handling a global char* is tricky because you need to ensure a way to free it
<njs>
With apologies in advance for the annoyingness of this question... are there any plans yet for 3.6 support?
<njs>
(it turns out that __fspath__ is super useful!)
<cfbolz>
njs: it's probably easy to support fspath specifically, we use the correct internal APIs already. But there aren't any immediate plans at this point
<njs>
cfbolz: I guess the issue would be that to get __fspath__ support in, say, pathlib, then you need to start importing the 3.6 stdlib and that's a whole thing
nimaje1 has joined #pypy
nimaje1 is now known as nimaje
nimaje has quit [Killed (leguin.freenode.net (Nickname regained by services))]
<cfbolz>
njs: indeed
antocuni has quit [Ping timeout: 240 seconds]
mihaid has joined #pypy
<the_drow>
fijal: What's wrong?
<the_drow>
Do you know what the problem is?
<the_drow>
fijal: Should I open an issue anyway?
<mihaid>
cfbolz: hi, I have looked into the enabling flto as an option, but it seems it was already done in commits/c6a3a65. Seems that I have nothing more to add to the PR 553. Should we proceed like this and continue with clang, in another PR?
<cfbolz>
mihaid: yes, sounds good!
<the_drow>
danchr: Are you on Solaris or something?
amaury has quit [Ping timeout: 260 seconds]
<fijal>
the_drow: yes please
<fijal>
the_drow: I know how to silence it, not to fix it
<fijal>
(which means that any issue is useful)
<fijal>
cfbolz: one concrete step would be "let's see how exactly the call to dict lookup goes through the JIT"
<danchr>
pypy mostly works on OS X, although not quite as well as Linux
<fijal>
the_drow: thanks!
<danchr>
+on
<fijal>
danchr: it did improve since I started using OS X :)
<danchr>
fijal: awesome :)
<fijal>
danchr: what's the segfault?
<danchr>
erm, the crash report isn't terribly meaningful; I got it during a unittest of a flask app
<njs>
hooooboy
<danchr>
…and it's not consistent
<fijal>
:(
<njs>
I found a discrepancy in behavior between the ssl module in cpython and pypy, but it's enough of an edge case that I'm not sure whether it's a bug or not
<fijal>
danchr: I suspect flask doing some shit with ctypes
<fijal>
(we cought it multiple times)
<fijal>
caught even
<danchr>
could be flask, selenium or something else
<fijal>
yeah who knows
<fijal>
danchr: would be useful if you can get us some sort of traceback, ideally from a debug version
<fijal>
but I understand if it's too much to ask for
<danchr>
generally speaking I'd say pypy3 is development-quality on OS X
<fijal>
oh, pypy 3
<fijal>
yeah, very much so :)
<fijal>
danchr: a good start would be "what happens if you run pypy --jit off"
<danchr>
it works, but not well enough for production — although using PyPy in production seems a rather odd choice
<fijal>
pypy3 or pypy in general?
<danchr>
fijal: things get slow? ;)
<danchr>
on OS X, specifically
<fijal>
ah yes
<fijal>
I don't know why would you use OS X in production in the first place :)
<danchr>
IMHO you'd only do ‘production’ on OS X if doing app development, and PyPy seems an odd choice in that regards
<danchr>
preciesly
<fijal>
and indeed, under that scenario it seems odd
* danchr
would love to have PyObjC on PyPy, but that's two different kinds of black magic to fuse, so…
<fijal>
our major customers, generally have 100s if not 1000s of servers
<fijal>
danchr: python lost the frontend battle :-(
<fijal>
which I'm a bit sad for, as I have to program stuff in C#
<danchr>
that's quite simple, actually: the frontend is all about the toolkit, and most toolkits don't consider Python a native citizen
<danchr>
with PyQt as a possible exception…
<danchr>
or GTK, but that's mainly for Linux, and it truly lost that battle
commandoline has quit [Quit: Bye!]
<danchr>
anyway, nowadays we all welcome our new JavaScript overlords, don't we? ;)
<the_drow>
fijal: How do I ignore those errors? Disable the JIT?
<fijal>
the_drow: yeah that would do
<the_drow>
is there an environment variable that does it?
<ELFrederich>
anybody here develop packages which use cffi on PyCharm? I cannot get PyCharm to inspect my compiled libraries. All my .py files which import from the compiled module are underlined in red all over making it very distracting
<arigo>
ELFrederich: I would be happy with pull requests that fix this, but that's all I can say, not being a PyCharm user at all myself
Ubuntu-BR has quit [Ping timeout: 240 seconds]
yuyichao has joined #pypy
Ubuntu-BR has joined #pypy
<ELFrederich>
arigo: I'm not sure what is wrong actually. It finds the .pyd module and within it it seems to know there is a "ffi" object, but not a "lib" object
<ELFrederich>
arigo: I saw no errors in the PyCharm log files... for whatever reason it finds one variable but not others
yuyichao has quit [Ping timeout: 260 seconds]
<arigo>
the 'lib' object is built a bit more dynamically than usual in the C files
<arigo>
that's why I guess we need to teach PyCharm about it, maybe using some PyCharm-specific metadata?
<arigo>
though indeed, no clue about the details
yuyichao has joined #pypy
<ELFrederich>
arigo: I'm kind of curious how PyCharm is able to even index these things. Clearly it's not importing them right?... because what if you had shutil.rmtree('/') at the top level of your module.
<ELFrederich>
so it's not doing an import followed by a dir
oberstet has quit [Remote host closed the connection]
<ELFrederich>
okay... now I am seriously confused. I just reverted to a clean snapshot of my VM before even installing Python. I go to install my bindings and I get an error saying I need VS build tools, okay... I download them. Then my bindings build... WITHOUT CFFI?
oberstet has joined #pypy
<ELFrederich>
how does this happen?. I have generated .pyd files without having cffi installed. When I go to run it, it complains about no _cffi_backend
<ELFrederich>
okay... it seems to have downloaded some .eggs or something
<ELFrederich>
so I need to have cffi installed to be able to use API out-of-bound bindings?
arigato has joined #pypy
the_drow has joined #pypy
<arigato>
ELFrederich: yes, for _cffi_backend.pyd
<the_drow>
arigato: I just left reproduction instructions on #2576
<dstufft>
Is there any way to monkeypatch super() on PyPy? In CPython I did __builtins__["super"] = ..., but that is failing on PyPy3
<arigato>
the_drow: "running MacroPy's test suite" requires me to first install MacroPy and dig though READMEs to learn how to run its test suite. it might be easy, or involved. I'd prefer if you could write down the shell commands that we need, rather than embarking on a possibly long endeavour
<the_drow>
I did
<the_drow>
python run_tests.py
<the_drow>
that's it
<ELFrederich>
I had issues with my cython bindings when I try to bundle everything up using pyinstaller. I'm having similar issues now using cffi based bindings. The library I'm calling is noticing something different and behaving differently.
<arigato>
the_drow: cool. I don't see that though...
<ELFrederich>
I will try ABI level now and see what happens
<arigato>
dstufft: don't use __builtins__, as that may fail on CPython too depending on where exactly you write it
<arigato>
instead, import __builtin__ on Python 2
<arigato>
and I think it's "import builtins" on Python 3
<the_drow>
I copy/pasted this from the issue comment
<the_drow>
I can add it to the main issue description as well
<dstufft>
arigato: let me try that instead
<arigato>
the_drow: now I see the main issue description update. strange, I still don't see any previous comment
<ELFrederich>
can someone help explain to me this api/abi in-bound out-of-bound stuff. In the API out-of-bounds example I see a call to set_source, followed by a call to cdef. In the ABI out-of-bounds I see the same, a call to set_source, followed by a call to cdef, what am I missing? They both call compile() in __main__
<the_drow>
I had a screenshot ready just for the sake of it :P
<the_drow>
It's pretty easy to reproduce. I have no idea what's the problem though
<the_drow>
or how to debug it further for that matter
<arigato>
it's the same as another already-reported bug
<ELFrederich>
arigato: but looking at the code how can I tell which is which? I tried (what I think was) API and it didn't play nice with pyinstaller. Now I'd like to try ABI mode.
<ELFrederich>
is the difference the second argument to set_source()?... meaning whether you pass it source code or not?
commandoline has quit [Quit: Bye!]
commandoline has joined #pypy
<arigato>
ELFrederich: yes
<arigato>
a problem like yours, which is the same with CFFI in API mode and with Cython, would probably be the same when writing manually a CPython C extension too
<the_drow>
arigato: It works but there's another issue I think. With PyPy 5.7 I get the same test failure exactly as CPython 2.7. Now I get "ImportError: reload(): module macropy.core.test.exporters.pyc_cache not in sys.modules"
<the_drow>
So is it safe to close #2576 or do you want it open?
<arigato>
looks safe to close, yes
<arigato>
no clue about the reload() error
<arigato>
maybe you should open another issue about that (I can't look at it right now)
<the_drow>
No problem
<arigato>
thanks
<the_drow>
Will do today :)
yuyichao has quit [Ping timeout: 258 seconds]
arigato has quit [Read error: Connection reset by peer]
<ELFrederich>
with abi out-of-line is there a way to control what the ffi object is called? or does it always have to be `ffi`?
<ELFrederich>
I ask because I'd want to create a 1-to-1 set of bindings so I'd be importing a bunch of different ffi objects, one for each .dll file (there are many).
<ELFrederich>
from _foo import ffi as ffi_foo; lib_foo = ffi_foo.dlopen(ctypes.util.find_library('libfoo'))
<ELFrederich>
from _spam import ffi as ffi_spam; lib_spam = ffi_spam.dlopen(ctypes.util.find_library('libspam'))
<the_drow>
ELFrederich: does this help?
<ELFrederich>
let me check
<the_drow>
I'm not sure if it's "out of line" but it's ABI mode
<ELFrederich>
the_drow: yeah... that seems to be in-line
<ELFrederich>
that call to cdef will happen every time you open it. Not really an option for me. I'm exposing over 32k things. 9k functions, a ton of #defined integers, error codes, etc
<ELFrederich>
I wonder what the benefit to do libraries=['augeas'] is there on set_source? It's just doing a dlopen later on. Is that libraries= doing anything at all?
yuyichao has joined #pypy
<the_drow>
I don't really know. It works that way
<ELFrederich>
I looked at the source code for cffi, namely recompiler.py which generates the auto-generated file. It seems ffi = _cffi_backend.FFI(... is hard coded
<ELFrederich>
no worries
<LarstiQ>
dstufft: that looks fairly contained
rokujyouhitoma has quit [Remote host closed the connection]
cstratak has quit [Quit: Leaving]
Ubuntu-BR has quit [Ping timeout: 240 seconds]
jcea1 has joined #pypy
jcea has quit [Read error: Connection reset by peer]
jcea1 is now known as jcea
cstratak has joined #pypy
yuyichao has quit [Ping timeout: 246 seconds]
girish946 has quit [Quit: Leaving]
Ubuntu-BR has joined #pypy
<dstufft>
Tests take 3x longer on PyPy3.5-5.8.0 than CPython 3.5 :(
<arigo>
the_drow: found your comment as "may be a spam". fixed
<the_drow>
hehe
<the_drow>
strange :P
<LarstiQ>
in the bb ui?
<arigo>
yes
arigo is now known as arigato
cstratak has quit [Quit: Leaving]
<squeaky_pl>
dstufft, well tests tend to not warm up the jit.
<dstufft>
squeaky_pl: yea I know why it is, doesn't make it less painful tho :P
<squeaky_pl>
I would say passing them is a major success
<ELFrederich>
Well good news, if I do the ABI level bindings the app behaves correctly and I'm able to bundle it up using pyinstaller.
<dstufft>
squeaky_pl: oh sure, I'm just being a whiner :) I wants all the things and I wants them now!
marr has quit [Remote host closed the connection]
yuyichao has joined #pypy
rokujyouhitoma has joined #pypy
vkirilichev has quit [Remote host closed the connection]
rokujyouhitoma has quit [Ping timeout: 260 seconds]
antocuni has quit [Ping timeout: 240 seconds]
<Rotonen>
trying to report the zope.proxy 3.x installation issue, but will have to figure out my atlassian credentials sometime later, been a while since i've used their services (i'm in a reauth loop for whatever reason, poking their support)
yuyichao has quit [Ping timeout: 240 seconds]
<squeaky_pl>
Rotonen, if you publish a github gist or some paste thingy with the issue and reprod somebody can get it into issue tracker for you
<Rotonen>
i have patience and i'll just sort that out
<Rotonen>
more of a FYI / pingback on the discussion from friday(?)
jacob22_ has quit [Quit: Konversation terminated!]
jacob22_ has joined #pypy
rokujyouhitoma has joined #pypy
antocuni has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
pilne has joined #pypy
Ubuntu-BR has quit [Ping timeout: 240 seconds]
<mattip>
cfbolz: the talk went well, people liked the performance comparison (c-implementation of fractal to a pure python on PyPy 5.9.0)
<cfbolz>
mattip: cool!
<mattip>
TLDR - PyPY and C were neck and neck, but PyPy won by 15% or so
squeaky_pl has quit [Ping timeout: 255 seconds]
<cfbolz>
Nice! Any clue why?
<antocuni>
mattip: i.e., pure python is faster than pure C?
<antocuni>
or faster than "C-called-by-cffi"?
<Rotonen>
mattip: if pure c, compiler flags?
<mattip>
for this specific case, pure python in PyPy beat pure C, with -O3 flag, but without -fLTO
<antocuni>
impressive
<antocuni>
it's worth a blog post :)
<Rotonen>
that's reversing the old david beazley keynote finding, nice
<mattip>
maybe I should try to reproduce on a different machine
Ubuntu-BR has joined #pypy
<cfbolz>
+1 for the blog post
<Rotonen>
+1 for the reproductions across a variety of systems
<cfbolz>
I'd really like to understand what is happening
<mattip>
I think people might call foul on the C code, though, take a look tell me what you think
<Rotonen>
script it and i'll provide a few
<antocuni>
mattip: even if it's sub-optimal C, it's still a worthy result: it's what you get by an average C programmer vs an average Python programmer
<mattip>
Rotonen: it's all a github repo with a Jupyter notebook
<Rotonen>
github (or equivalent) it all, blogpost, invite people to root for their own champion via performnance enhancement pull requests?
<Rotonen>
cfbolz: with only one iteration there should not be anything drawn anyway?
<mattip>
cfbolz: hmm. checking, but in a bit
antocuni has quit [Ping timeout: 240 seconds]
<cfbolz>
mattip: I can debug a bit myself
<cfbolz>
Rotonen: no, it's not about the number of iterations
<Rotonen>
kk
<cfbolz>
it's whether you cross to C for every pixel, or only once for the whole img
<cfbolz>
mattip: can confirm, pypy is also faster for me
yuyichao has joined #pypy
oberstet has quit [Ping timeout: 255 seconds]
<nanonyme>
Rotonen, moi
<Rotonen>
nanonyme: yo
<cfbolz>
mattip: ok, got the problem ;-)
<cfbolz>
mattip: GCC does simply not optimize the complex type that well
<cfbolz>
if I rewrite using float ops, pypy stays the same, but C gets 3.5x faster
<Rotonen>
cfbolz: how's C with -O0?
tito has joined #pypy
tito has joined #pypy
tito has quit [Changing host]
tbodt has joined #pypy
<cfbolz>
Rotonen: with floats (not complex) C -O0 is still 40% faster than pypy
* mattip
back
<mattip>
cfbolz: I feared it was something like that
<cfbolz>
mattip: I need to switch to doubles before I make any more statements
rokujyouhitoma has joined #pypy
<cfbolz>
mattip: but it's still a cool result! because it shows that meta-tracing is nice, since we didn't have to do anything at all in our compiler to get this good support for complex numbers
Rhy0lite has quit [Quit: Leaving]
rokujyouhitoma has quit [Ping timeout: 240 seconds]
<cfbolz>
mattip: ok, with doubles in C PyPy is 2.5x slower than C
<cfbolz>
that still sounds like a pretty good result to me, tbh
Ubuntu-BR has quit [Ping timeout: 255 seconds]
<mattip>
cfbolz: thanks for the sanity check, your results make more sense than "PyPy is faster than C"
<cfbolz>
mattip: what is true is: our complex numbers are faster than GCC's complex numbers
<cfbolz>
which is awesome, imo!
<mattip>
I _did_ have to dig a bit to get complex numbers for gcc, the original implementation in C used floats
<Rotonen>
does cocos2d work on pypy?
<Rotonen>
that could yield some nice demos
vkirilichev has joined #pypy
Ubuntu-BR has joined #pypy
vkirilichev has quit [Remote host closed the connection]
<mattip>
cfbolz: fwiw, I fixed the blank image problem and pushed to the repo
<cfbolz>
cool
<cfbolz>
mattip: what was it?
<mattip>
jupyter seems to recreate the data1 when the allocation and use are in two different cells,
<mattip>
I simply merged the two cells in the cffi part
<cfbolz>
ah, ok
<mattip>
but that seems like a jupyter bug, so I'm not sure what is really going on
rokujyouhitoma has joined #pypy
<mattip>
the ctypes images were also empty, from a bad copy-paste that reinitialized self.data
<cfbolz>
yep
<cfbolz>
mattip: I still think this would be an interesting blog post, btw
rokujyouhitoma has quit [Ping timeout: 268 seconds]
<cfbolz>
write nice high level code in python, it's fast. if you write the same high level code in C it's not faster and you need to do the ugly manual improvement
<mattip>
maybe there are improvements to be made to the python code too?
<mattip>
surely the function interface using a pointer doesn't help performance,
<mattip>
but it was useful for a teaching example
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]