01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/3837 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/5539 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/6817 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/3973 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-32/builds/5921 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/4688 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/build-pypy-c-jit-linux-armel/builds/2331 [py3.5]

01:00 <bbot2> Started: http://buildbot.pypy.org/builders/build-pypy-c-jit-linux-armhf-raspbian/builds/2092 [py3.5]

02:11 <bbot2> Success: http://buildbot.pypy.org/builders/build-pypy-c-jit-linux-armel/builds/2331 [py3.5]

02:12 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/5539 [py3.5]

02:13 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/4688 [py3.5]

02:16 <bbot2> Success: http://buildbot.pypy.org/builders/build-pypy-c-jit-linux-armhf-raspbian/builds/2092 [py3.5]

02:16 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-armhf-raspbian/builds/1784 [py3.5]

02:23 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/6817 [py3.5]

03:32 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/3837 [py3.5]

04:30 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-32/builds/5921 [py3.5]

04:40 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/5540 [mattip: force build, py3.6]

04:40 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/6818 [mattip: force build, py3.6]

04:41 <mattip> looking at py3.6, there are a number of lib-python tests that show missing DeprecationWarnings, but they work properly untranslated

04:42 <mattip> this one for instance

04:42 <mattip> python pytest.py pypy/module/_codecs/test/test_codecs.py -k test_warn_escape_decode

04:42 <mattip> passes untranslated, is marked as passiing translated -A, but fails for me when I run it

04:43 <mattip> python pytest.py -A pypy/module/_codecs/test/test_codecs.py -k test_warn_escape_decode --python=pypy3 # from py3.6

05:10 <mattip> it seems to be a unittest failure to properly catach the warning,

05:10 <mattip> pypy3 -W always -c "import codecs; codecs.escape_decode(b'\\A')"

05:10 <mattip> warns like it should

05:53 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/5540 [mattip: force build, py3.6]

06:05 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/6818 [mattip: force build, py3.6]

08:29 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/3973 [py3.5]

09:58 <cfbolz> mattip: a lot of the problems are like this

10:47 <thnee> arigato: Thanks for your response regarding FreeBSD. I definitely don't mind making a pull request. Just not sure what the solution should be. I am generally against hard coding paths like that, I would prefer that it relies on some system way of finding lib paths. That's why my question is which other parts are relevant to look at when debugging this. Unless there is a specific reason to hard code it for

10:47 <thnee> FreeBSD like that, but it seems there is not.

11:18 <mattip> cfbolz: yeah, just thinking out loud so when I come back to this I can remember how far I got

11:20 <cfbolz> mattip: sure. Just saying that imo a lot of the 3.6 features are actually implemented and tests fail for somewhat spurious reasons

12:03 <the_rat> I have a function with a single arg and no side effects that when benchmarked (with timeit, repeat calls with same arg) runs in ~5µs with CPython and ~100ns with PyPy JIT. If I run the same benchmark with @lru_cache I get ~270µs with CPython and ~160ns with PyPy. This might mean that lru_cache effectively slows things down in PyPy. Can someone explain-like-I'm-five what might be a plausible explanation for this?

12:04 <cfbolz> the_rat: what does the function do?

12:07 <cfbolz> the_rat: The cache makes it necessary to do a dictionary lookup every time you call the function. If the function is simple enough it is cheaper to actually do the computation instead of doing the lookup in the dictionary

12:08 <the_rat> cfbolz: the single arg is the root node of a graph, and it does some transformations and topological sorting and returns something a list of objects based on that

12:10 <the_rat> If it matters, the arg is effectively the same object

12:11 <cfbolz> the_rat: can you paste the code somewhere? It sounds like this is somewhat complicated. But I agree with Alex_Gaynor that maybe a more specific version of the decorator would improve this

12:13 <the_rat> Unfortunately I cannot share the code, it's tied to some proprietary stuff :( You all gave me very good input, I will try with a simpler caching decorator and with different input sizes

12:32 <the_rat> Very interesting! So, a simple dict lookup for id(arg) cut runtime for the cached case to be close to the uncached case for a small input size. The difference becomes noticeable for larger inputs. This means PyPy is extremely effective at eliminating most of the bloat overhead and getting the performance close to the raw algorithm performance. Exciting :)

12:38 <cfbolz> the_rat: why use id? to make it not keep the argument alive?

12:39 <the_rat> cfbolz: because I don't care about __eq__uality testing, only identity. Probably it would have worked the same because I have no __eq__ but I didn't want to think about it so it's more of a mental shortcut for this benchmark

12:40 <cfbolz> you could try something even more radical, like having a list of the last three results and not using a dict at all

12:41 <the_rat> Oh yes, good idea

13:08 <the_rat> That was a precious suggestion, shaved a few more ns. Thanks a lot.

13:09 <cfbolz> the_rat: cool

13:14 <cfbolz> Alex_Gaynor: wow, lru_cache is quite impressively heavy

13:14 <Alex_Gaynor> cfbolz: IIRC fijal also fought with it once before

13:14 <cfbolz> right

13:14 <cfbolz> locks, and linked lists, and indeed a lot of allocations

13:15 <cfbolz> make we wonder how useful it is even in CPython]

13:18 <LarstiQ> maybe better for avoiding network requests than small computations

13:31 <Alex_Gaynor> cfbolz: CPython is _very_ slow :-)

13:33 <cfbolz> yes yes

13:33 <cfbolz> Alex_Gaynor: for my own amusement I measured matrix multiplication recently: https://gist.github.com/cfbolz/caa8299ebd5ab4e1203be1614a64bb54

15:44 <ivh> Hi! I have a general newbie question on cffi (used with cpython3 for now, but cffi docs say to ask here): I simply want to use a handful of existing C-functions, spread over several files, with cffi out-of-line API-mode. When calling ffibuilder.set_source(), do I then need to give the contents of all files as second argument, or put all except the first into the sources=[] kwarg ?

18:06 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-armhf-raspbian/builds/1784 [py3.5]

20:33 <nanonyme> arigato, btw, does CFFI or are you considering it to support Python3 pathlib objects out of the box for library paths?

20:37 <cfbolz> nanonyme: that's probably an easy pull request

20:37 <nanonyme> Well, yes and no

20:38 <nanonyme> There's two separate implementations, one is in C and one is in Python

20:39 <nanonyme> I know this because this hits the exact same codepath I earlier filed a bug with getting Windows unicode paths being supported

20:40 <nanonyme> The Python-side is reasonably simple to fix, the C part might be painful

20:41 <nanonyme> Also CFFI needs to work on Python2 so you need glue code even for os.fspath

20:43 <nanonyme> (to be honest, I always thought it would be nicer if the inline and out-of-line ABI modes shared more code as Python code but anyway)

22:00 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-s390x/builds/959 [default]

23:25 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-s390x/builds/959 [default]