17:29 <ronan> mattip: I'm looking at os.listdir()

17:37 <mattip> ronan: thanks. Willing to discuss it if any input is needed, or to try out a fix on a windows machine

17:38 <ronan> I'm just trying to remember how the whole traits/Path mess works for now

17:40 <arigo> I think I already tried to fix the windows situation for os.listdir() one or two months ago, but probably failing

17:45 <mattip> the thing is, there are two versions of rposix.listdir(), so

17:45 <mattip> 1) I don't think you can wrap it with the call_rpython decorator (correct name?)

17:45 <ronan> call_rposix

17:46 <ronan> and yes, that's what I just concluded as well

17:46 <mattip> 2) one returns a list of str, the other returns a list of unicode, so the annotator gets annoyed with newbyte_list and unicode

17:47 <mattip> I tried to unravel (2) in the win-listdir branch, but then hit (1)

17:47 <mattip> I am not sure if the fix is correct or not

17:47 <ronan> the annotator will already complain at result = rposix.listdir(path)

17:48 <ronan> because can't be both a list of str and of unicode

17:48 <ronan> *becuse result

17:48 <mattip> somehow it worked before ...

17:51 <mattip> 9757602c869f was the last successful build of py3.6 on win32

17:52 <ronan> yes, it worked because the paths for as_bytes == True and as_bytes == False were separate

17:53 <mattip> ah

17:54 <ronan> I guess separating them again should work

17:55 <mattip> annoying indeed

17:56 <mattip> at some point we should work out a utf8 strategy for these windows system calls, and get rid of all the unicode mess

18:38 <Ododo> Hello. i don't understand well how the addres mapping of the program works with cffi. I have a shared function witch returns a void *. When a print the pointer value in the c program before returning i have something like 0x7fffed857720, which becomes 0xffffffffed857725 in the cffi object repr. i would expect the repr to be something like 0x00007fffed857720 .

18:39 <Ododo> (shared function via cdef)

19:02 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8162 [ronan: force build, py3.6]

19:02 <bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-32/builds/2332 [ronan: force build, py3.6]

19:02 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6979 [ronan: force build, py3.6]

19:02 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5303 [ronan: force build, py3.6]

19:05 <bbot2> Exception: http://buildbot.pypy.org/builders/own-win-x86-32/builds/2332 [ronan: force build, py3.6]

19:58 <bbot2> Success: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8162 [ronan: force build, py3.6]

20:19 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6979 [ronan: force build, py3.6]

20:20 <mjacob> did we already discuss what https://pip.pypa.io/en/stable/development/release-process/#python-2-support means for us?

20:20 <mjacob> does it mean that pip support for pypy2.7 ends next january?

20:29 <cfbolz> mjacob: we didn't discuss it so far

20:29 <cfbolz> I don't think we have a plan

20:31 <tumbleweed> old pip would continue to work, give or take security shit

20:36 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5303 [ronan: force build, py3.6]

21:07 <tos9> also soon hopefully there will be a non-pip wheel installer

21:08 <tos9> which is a much smaller interface to have to deal with presumably, if some day old pip with no security stuff is a big issue