00:00
yuyichao has quit [Quit: Konversation terminated!]
00:00
yuyichao has joined #pypy
00:46
jamesaxl has quit [Quit: WeeChat 1.9.1]
01:00
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
01:10
tbodt has joined #pypy
01:14
pilne has joined #pypy
01:21
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
01:24
jcea has quit [Remote host closed the connection]
01:24
mat^2 has quit [Ping timeout: 240 seconds]
01:26
antocuni_ has quit [Ping timeout: 265 seconds]
01:38
tbodt has joined #pypy
01:44
SunDwarf has quit [Remote host closed the connection]
01:44
marr has quit [Ping timeout: 255 seconds]
01:44
SunDwarf has joined #pypy
01:44
Civil has quit [Remote host closed the connection]
01:45
nimaje is now known as Guest94872
01:45
nimaje1 has joined #pypy
01:45
Guest94872 has quit [Killed (weber.freenode.net (Nickname regained by services))]
01:45
nimaje1 is now known as nimaje
01:46
marvin_ has quit [Ping timeout: 248 seconds]
01:48
Civil has joined #pypy
01:52
marvin_ has joined #pypy
02:23
pilne has quit [Quit: Quitting!]
02:54
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
03:17
ArneBab has joined #pypy
03:22
ArneBab_ has quit [Ping timeout: 268 seconds]
03:36
astronavt has joined #pypy
03:46
tbodt has joined #pypy
03:53
dddddd has quit [Remote host closed the connection]
03:55
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
03:57
dcrosta has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:57
tbodt has joined #pypy
03:58
nimaje has quit [Read error: Connection reset by peer]
03:58
tbodt has quit [Client Quit]
04:00
tbodt has joined #pypy
04:00
nimaje has joined #pypy
04:10
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
04:17
Garen has joined #pypy
04:19
abrown has joined #pypy
04:30
nimaje has quit [Read error: Connection reset by peer]
04:32
nimaje has joined #pypy
04:35
dcrosta has joined #pypy
04:40
exarkun has quit [Ping timeout: 265 seconds]
04:40
exarkun has joined #pypy
04:44
tbodt has joined #pypy
04:46
tbodt has quit [Client Quit]
04:47
tbodt has joined #pypy
04:48
tbodt has quit [Client Quit]
04:55
astronavt has quit [Quit: Leaving...]
04:57
tbodt has joined #pypy
05:07
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
05:12
tbodt has joined #pypy
05:13
abrown has quit [Ping timeout: 260 seconds]
05:35
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
05:37
tbodt has joined #pypy
05:38
tbodt has quit [Client Quit]
05:47
tbodt has joined #pypy
05:49
tbodt has quit [Client Quit]
05:50
tbodt has joined #pypy
05:56
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
05:56
tbodt has joined #pypy
05:57
tbodt has quit [Client Quit]
06:00
tbodt has joined #pypy
06:11
* arigato
implements os.scandir() on windows
06:14
<
pjenvey >
and there was much rejoicing
06:14
<
njs >
not by arigato I'm guessing
06:15
<
pjenvey >
definitely not by arigato
06:17
<
arigato >
pjenvey: also, the mmap-for-sharing branch won't be merged for the release
06:18
<
arigato >
it has a not-understood memory impact on running a full translation
06:18
<
pjenvey >
arigato: I saw it was increasing memory usage for translation. pretty weird
06:19
exarkun has quit [Ping timeout: 248 seconds]
06:19
<
arigato >
what is the executable "t32.exe" that distutils tries to locate when doing "python -mensurepip"??
06:19
<
pjenvey >
we could make it an optional gc env flag.. but le sigh
06:20
exarkun has joined #pypy
06:22
<
arigato >
uh, on windows when distutils installs an "executable script", it prepends a magic line containing "\full\path\to\t32.exe"
06:22
<
arigato >
apparently?
06:23
<
arigato >
right, I actually find it in my installed C:\Python35-32\Lib\site-packages\pip\_vendor\distlib
06:23
<
arigato >
also in C:\Python27\Lib\site-packages\pip\_vendor\distlib
06:25
<
pjenvey >
IIRC setuptools had a similar exe for launching scripts, this must be the same but different
06:25
<
arigato >
but there's no way the same exe can invoke pypy instead of cpython
06:26
<
arigato >
how does it work on pypy2? I guess it doesn't
06:27
<
njs >
arigato: does pypy2 -m virtualenv give you a myvenv\bin\python like it does on posix?
06:27
tayfun26 has joined #pypy
06:27
<
pjenvey >
I think it's a hack that reads shebang lines to pretty much emulate posix behavior
06:28
<
arigato >
right now it prevents "pypy3-c.exe -m ensurepip" from completing
06:28
<
arigato >
I have no clue why, but "pypy-c.exe -m ensurepip" completes
06:29
<
njs >
is the README, and describes the .exe's behavior
06:30
<
arigato >
I'm fine with continuing to ignore this exe if we did so far, but I'd like to understand why ensurepip fails on pypy3
06:31
<
pjenvey >
yea it's a total hack
06:31
<
arigato >
if you do repeatedly "pypy3-c.exe -m ensurepip", the third time it works
06:31
<
pjenvey >
what does the shebang line in question look like I would first wonder
06:32
<
njs >
I have absolutely no idea what ensurepip even does or how it relates to the executable so
06:32
<
arigato >
well, doing "pypy{2 or 3
06:33
<
arigato >
well, doing "pypy{2 or 3}-c.exe -m virtualenv venv" fails on both pypy2 and pypy3
06:33
<
njs >
(I mean I know what it's supposed to accomplish, I just have no idea how it works)
06:38
<
arigato >
I guess it wouldn't be hard to add to the buildbot "try to run this series of commands"
06:41
<
kenaan >
arigo default c1c8d16890dd /lib-python/2.7/subprocess.py: Make virtualenv work on Windows too
06:45
<
kenaan >
arigo py3.5 fd74b9439261 /lib-python/3/subprocess.py: Port of c1c8d16890dd
06:54
<
arigato >
none of the cpython tests work because "import faulthandler" is not here on pypy3-c.exe
06:58
<
arigato >
yes, I know it doesn't work on Windows
06:58
<
arigato >
I didn't know that "import faulthandler" was done unconditionally inside the test suite
07:00
<
kenaan >
arigo py3.5 3c8c318aa8d4 /lib_pypy/faulthandler.py: Add a dummy faulthandler.py for the CPython test suite
07:06
<
kenaan >
arigo py3.5 cffba7a52fb2 /lib_pypy/_ssl/__init__.py: Add a dummy enum_certificates() function, for now
07:12
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:18
tbodt has joined #pypy
07:27
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:29
tbodt has joined #pypy
07:41
<
dstufft >
njs: basically the same thing as ``pip install pip``
07:41
<
dstufft >
njs: through some hacks
07:45
<
njs >
dstufft: ah cool
08:00
exarkun has quit [Ping timeout: 264 seconds]
08:01
exarkun has joined #pypy
08:15
mat^2 has joined #pypy
08:46
antocuni_ has joined #pypy
08:52
mat^2 has quit [Ping timeout: 265 seconds]
09:01
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
09:02
kenaan has quit [Write error: Connection reset by peer]
09:16
Jellyg00se has joined #pypy
09:27
marr has joined #pypy
09:50
Garen has quit [Read error: Connection reset by peer]
09:51
Garen has joined #pypy
09:53
mattip_away has joined #pypy
09:54
<
mattip_away >
arigato: did you want to commit the scandir changeset?
09:57
antocuni_ is now known as antocuni
09:58
<
antocuni >
so apparently my fix fixed translation on s390x but not on ARM? How is it possible? :(
09:59
<
antocuni >
ah wait! How does translation on ARM work? Is it native or cross-translation?
10:00
<
antocuni >
I am checking the CPU by doing 'import platform; platform.machine() in ("i686", "x86_64")'
10:00
<
antocuni >
maybe I should use rffi_platform instead?
10:01
<
arigato >
mattip_away: yes, coming soon
10:01
<
mattip_away >
to both of you
10:03
<
antocuni >
buildbot says the the builddir is "/home/buildslave/bot_cross_armel/", so it seems it's indeed a cross-compilation
10:03
<
antocuni >
the question now is: how am I supposed to check what is the CPU of the target?
10:05
<
mattip_away >
how does it choose a jit backend?
10:06
<
antocuni >
good question, /me looks
10:08
<
mattip_away >
—platform=arm as a translation arg
10:09
<
antocuni >
there is also jit.backend.detect_cpu, which seems to have logic to handle both cross and non-cross translations
10:09
<
antocuni >
although I have no idea how all this mess interacts with e.g. tests
10:09
<
antocuni >
we assume that this info is in the global state, while it is not at all :(
10:10
<
mattip_away >
tests are not run cross platform
10:11
<
antocuni >
yes, but it's still not a good reason for having this mess
10:11
<
antocuni >
anyway, I suppose it's too late to fix it now
10:16
mattip_away has quit [Remote host closed the connection]
10:16
kenaan has joined #pypy
10:16
<
kenaan >
antocuni default b1b0f51304ce /rpython/rlib/rvmprof/cintf.py: this method of determining the CPU is broken in presence of cross-translations (like we do e.g. on ARM). Try to ...
10:32
jacob22__ is now known as jacob22
11:15
<
kenaan >
arigo py3.5 4bb7cf3fd5a1 /: In-progress: os.scandir() on Windows
11:15
<
kenaan >
arigo py3.5 6deed1172830 /: Enough os.scandir() to pass our own tests on Windows
11:15
<
kenaan >
arigo py3.5 2bd764ec6d22 /rpython/annotator/binaryop.py: Obscure annotation fixes: propagate no_nul a tiny bit more
11:15
<
kenaan >
arigo py3.5 c45c28743766 /: Translation fixes
11:19
antocuni has quit [Ping timeout: 264 seconds]
11:20
exarkun has quit [Ping timeout: 264 seconds]
11:21
exarkun has joined #pypy
11:22
oberstet has joined #pypy
11:57
jcea has joined #pypy
11:58
AndrewBC has quit [Ping timeout: 265 seconds]
12:01
raynold has quit [Quit: Connection closed for inactivity]
12:43
antocuni has joined #pypy
12:45
<
antocuni >
cool, it seems that ARM translation works again
12:45
<
antocuni >
mattip: ^^^
12:53
<
antocuni >
arigato: sometimes I think that we should switch to a more "configure-like" system for rpython
12:54
<
antocuni >
in which we do a configure step which gathers all the info about the target platform (and store them e.g. inside a config.py)
12:55
<
antocuni >
but I know that it's probably a huge project which nobody feels like to do :)
13:04
<
antocuni >
since we are talking about ambitious projects which will never be done, another possibility would be to do something like cython, in which the C code produced is always the same, and the platform-specific parts are enabled using #ifdefs
13:07
<
arigato >
ronan: ah, right
13:07
<
ronan >
having the arch in the tag is linux-specific in CPython
13:07
<
arigato >
it's just that the change was wrong
13:07
<
arigato >
but does platform.architecture() always return the right thing on linux?
13:07
<
ronan >
probably not
13:08
<
ronan >
the definitions are irregular, they come from configure.ac
13:08
<
arigato >
sorry, .machine()
13:08
<
arigato >
indeed, no
13:08
<
arigato >
platform.machine() returns 'x86_64' even in a 32-bit chroot
13:10
<
antocuni >
arigato: are you talking about pypy or cpython?
13:10
<
arigato >
testing with CPython 3.x
13:10
<
antocuni >
because on the 32-bit chroot which we have on tannit, platform.machine() returns 'i686' for both cpython2.7 and pypy 5.0
13:10
<
ronan >
platform.machine() calls uname
13:10
<
arigato >
right, it's not actually a chroot I'm testing here
13:11
<
arigato >
just the 32-bit version of python that comes with arch linux, I think
13:11
<
arigato >
which lives not in a chroot
13:11
<
ronan >
well, platform.machine() doesn't know anything about its own executable
13:12
<
arigato >
it's rather sad, the failing test you pointed to shows that it's possible for 32-bit libraries to end in "x86_64-linux"
13:12
<
arigato >
which imho defeats the point completely
13:13
<
ronan >
huh, yes, "x86_64-linux-gnux32.so"?!?
13:14
<
arigato >
sorry, missed the x32 part
13:15
<
arigato >
so there is still a point, and we should still do the same
13:15
<
arigato >
(we can ignore x32 as an unsupported platform)
13:17
<
arigato >
how is it on windows, btw?
13:17
<
arigato >
do the .pyd also get two names depending on 32- or 64-bit?
13:17
<
ronan >
is uses a completely separate logic
13:18
<
ronan >
EXT_SUFFIX is just .pyd
13:22
<
fijal >
arigato: I wrote the release announcement. Should I wait for something/help with something?
13:22
<
arigato >
we're busy fixing details
13:22
<
fijal >
I guess I can create the 2.7 release branch (and bump the versions etc.)
13:22
<
fijal >
I can see that, that's why I'm asking :-)
13:23
<
arigato >
this particular detail will be fixed in 10 minutes, but I have no clue about how many others there are :-)
13:23
<
fijal >
is this the next step to try to get ssl running?
13:26
<
arigato >
I think that ssl should work already
13:28
<
arigato >
ensurepip crashes, but if you just have to try again two more times: at the third time it works
13:28
<
arigato >
I know what the problem is but I have no clear clue about how to fix it
13:28
<
arigato >
it's inside code that gets downloaded
13:30
<
kenaan >
arigo py3.5 92a3e28a4aef /pypy/module/imp/importing.py: Another attempt at this logic
13:32
dddddd has joined #pypy
13:32
<
kenaan >
arigo py3.5 1dd2914caff4 /pypy/module/imp/test/test_import.py: fix test
13:35
<
kenaan >
rlamy py3.5 def83ef09f31 /pypy/module/posix/: listxattr returns a list of str, not of bytes
13:38
dddddd has quit [Ping timeout: 240 seconds]
13:43
<
fijal >
(about the ensure pip crashing twice)
13:44
<
fijal >
arigato: should we file a bug report?
13:44
<
fijal >
I'm sure we can get it sorted quickly
13:44
adamholmberg has joined #pypy
13:45
<
arigato >
I don't know what the correct thing is
13:45
<
fijal >
"not crash" :-)
13:45
<
arigato >
I'd need to investigate what the "t32.exe" executable really is
13:45
<
arigato >
and how it is used
13:46
<
arigato >
for now, yes, we can suggest that if the "t32.exe" executable is not found, it falls back to doing something sane instead of crashing with an obscure AttributeError
13:47
<
arigato >
or TypeError
13:47
<
Rotonen >
IIRC those are distlib glue to adhere to PEP 397
13:48
<
fijal >
arigato: that's unfortunately the name of the game for those tools
13:48
<
kenaan >
arigo py3.5 934eabf72b5c /pypy/module/imp/importing.py: Still use machine.platform() to know if we're on a x86 or not at all
13:48
<
fijal >
ideally it would not crash like that at all, but for now maybe "it does not crash if you do everything exactly right" is a start
13:49
<
arigato >
fijal: easy: "don't use windows"
13:52
<
arigato >
Rotonen: thanks a lot
13:53
<
arigato >
so we should ideally make the same t32.exe (etc.) executables
13:53
<
arigato >
that would load libpypy-c.dll instead
13:53
dddddd has joined #pypy
13:54
<
Rotonen >
arigato: the whole thread is a bit tiresome to read, but does go into some depth on those
13:54
<
arigato >
I'd love to answer "so, not now"
13:55
<
fijal >
arigato: :]
13:55
<
arigato >
that's really functionality that we can report to the future, but ensurepip fails
14:01
marky1991 has joined #pypy
14:01
<
kenaan >
rlamy py3.5 0c9668c522b1 /pypy/module/posix/: Fix error reporting from posix.*xattr functions
14:01
<
arigato >
Rotonen: can you help me locate the source code for t32.exe? I'm failing
14:02
<
Rotonen >
i'd suppose it's the visual studio projects from vinay sajip, iirc somewhere on bitbucket or google code or somesuch
14:03
<
arigato >
ah, it's included as already-compiled binary inside the file ./Lib/ensurepip/_bundled/pip-7.1.2-py2.py3-none-any.whl
14:03
<
arigato >
that's great
14:03
<
LarstiQ >
<OutputFile>dist\t32.exe</OutputFile>
14:04
<
arigato >
ok then I have no clue why t32.exe is not simply unpacked from that .whl like it is on CPython (it wouldn't work but nobody tries to run it so far)
14:31
<
kenaan >
rlamy py3.5 e5552dd110c1 /pypy/doc/whatsnew-pypy3-head.rst: document branch
14:36
<
ronan >
numpy still works (with 28 failures, but they're all known issues)
14:52
yuyichao has quit [Ping timeout: 248 seconds]
15:05
demonimin has quit [Ping timeout: 276 seconds]
15:11
yuyichao has joined #pypy
15:19
<
arigato >
aaAaah trying to debug it but if I unpack the .whl to add a pdb.set_trace(), then it works fine
15:19
dcrosta has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:24
tayfun26 has quit [Quit: tayfun26]
15:24
<
antocuni >
arigato: you can start your program using python -m pdb foo.py
15:24
<
arigato >
ok it's because somehow we look for 'pip/_vendor/distlib\t32.exe' in the zip, but the index only contains '\'-separated names
15:24
<
antocuni >
then you get a pdb prompt beofe the program starts
15:24
<
arigato >
antocuni: haha naive
15:25
<
antocuni >
and from there you can use the "break" command to set a breakpoint
15:25
<
arigato >
of course somebody catches the exception to display it nicely
15:25
<
arigato >
antocuni: but thanks anyway for the reminder
15:26
<
antocuni >
arigato: but the exception is somehow not displayed?
15:26
<
arigato >
no, it is
15:26
<
arigato >
but in red
15:30
<
arigato >
narrowing the problem to zipimporter
15:34
<
ronan >
arigato: ah, ISTR that when I last hacked on zipimporter, I thought "windows makes my head hurt, I'll just ignore it"
15:42
<
arigato >
it's because python files inside a zip have a
__file__ with '/' instead of '\'
15:43
<
arigato >
on pypy3 only, on pypy2 it works
15:45
demonimin has joined #pypy
15:47
<
antocuni >
arigato: about 934eabf72b5c: hasn't it got the same problem I hit earlier today? I.e., that cross-compiled ARM builds will be confused
15:48
<
arigato >
right, you have a point
15:49
<
arigato >
what's the solution?
15:49
<
antocuni >
I used jit.backend.detect_cpu.autodetect()
15:49
<
antocuni >
it seems to have logic to handle cross-compilation
15:49
<
antocuni >
although I didn't dig to understand how it works
15:50
<
antocuni >
I wonder whether we should move e.g. to rffi_platform, and ensure that we use it everywhere
15:50
<
arigato >
could you fix this too? I'm digging on a different machine right now
15:50
<
antocuni >
arigato: I fixed it blindly and then started the buildbot, I don't have a phisical machine where to try it
15:50
<
arigato >
...test_zipimport fails on windows on py3.5 precisely because that
15:51
<
arigato >
antocuni: same here
15:52
<
arigato >
though I think I installed an arm virtual machine some time ago (somewhere else)
15:53
<
antocuni >
I
*think* that what buildbot does is to run translation on a normal x86 CPU, but using a cross-compiling SDK
15:53
<
antocuni >
so, no need for an arm virtual machine
15:54
<
arigato >
then, I don't have the cross-compiling SDK I fear
15:54
<
antocuni >
try to login to the buildslave, maybe?
15:55
<
antocuni >
"Cross Translation builder for ARM softfp ARMv7 builds"
15:56
<
antocuni >
no idea how to ssh into it, though
15:58
<
arigato >
same here
16:03
<
kenaan >
arigo py3.5 5a865516f947 /pypy/module/zipimport/interp_zipimport.py: Fix for test_package. This might fix the next issue for "pypy3 -m ensurepip".
16:03
<
kenaan >
arigo py3.5 d8113c2982af /pypy/module/zipimport/interp_zipimport.py: merge heads
16:09
realitix has joined #pypy
16:26
Jellyg00se has quit [Quit: Leaving]
16:44
<
kenaan >
arigo py3.5 50aa133f3ee9 /pypy/module/posix/: Test and fix (for lib-python/3/pathlib): 'os.symlink' must exist, even if it can raise NotImplementedError on Windows
16:56
<
kenaan >
rlamy py3.5 74f1be327b1d /pypy/: Cache the wrapped code.co_filename: space.newfilename() is expensive
16:59
tbodt has joined #pypy
16:59
marky1991 has quit [Remote host closed the connection]
17:00
realitix has quit [Quit: realitix]
17:01
marky1991 has joined #pypy
17:06
marky1991 has quit [Ping timeout: 272 seconds]
17:07
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
17:17
tbodt has joined #pypy
17:24
mattip has joined #pypy
17:26
marky1991 has joined #pypy
17:28
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
17:34
marky1991 has quit [Ping timeout: 264 seconds]
17:59
<
ronan >
pff, there's a segfault in the pandas test suite, but that's because they call PyBytes_AS_STRING on a str
18:00
<
ronan >
also, pandas master doesn't compile, but the last release works
18:05
marky1991 has joined #pypy
18:17
<
mattip >
ronan: is that from cython?
18:18
<
ronan >
no, it's C code that was badly ported to py3 AFAICT
18:18
jamesaxl has joined #pypy
18:19
marky1991 has quit [Remote host closed the connection]
18:20
marky1991 has joined #pypy
18:21
antocuni has quit [Ping timeout: 260 seconds]
18:49
<
tos9 >
I like the "at the moment" in the exception message
18:49
<
tos9 >
Clearly the TypeError version of a "hang up and try again later"
18:50
<
mattip >
nice. The compilation problem seems to be an abuse of PyDateTime_* macros, right?
19:03
<
ronan >
yes, something like that
19:05
oberstet has quit [Ping timeout: 256 seconds]
19:07
tbodt has joined #pypy
19:19
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
19:20
tbodt has joined #pypy
19:23
tbodt has quit [Client Quit]
19:31
oberstet has joined #pypy
19:33
tbodt has joined #pypy
19:39
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
20:00
tbodt has joined #pypy
20:05
tbodt has quit [Client Quit]
20:10
<
kenaan >
mattip cpyext-avoid-roundtrip 5db9d141c474 /pypy/module/cpyext/src/object.c: quiet warnings
20:10
<
kenaan >
mattip cpyext-avoid-roundtrip f428c66de212 /pypy/module/cpyext/: test, fix PySequence_GetItem allows negative indices
20:12
<
mattip >
fijal: if default builds pass, I will create a release branch for py2.7-v5.10
20:15
mattip has left #pypy ["bye"]
20:25
marky1991 has quit [Ping timeout: 264 seconds]
20:32
marky1991 has joined #pypy
20:36
raynold has joined #pypy
20:45
dowwie_ has joined #pypy
20:55
dowwie_ has quit [Read error: Connection reset by peer]
20:55
dowwie has joined #pypy
21:03
tbodt has joined #pypy
22:01
marky1991 has quit [Remote host closed the connection]
22:02
marky1991 has joined #pypy
22:02
<
kenaan >
rlamy py3.5 9ae4bd0c4555 /pypy/module/cpyext/: Fix 'errors' arg in PyUnicode_Decode()
22:11
adamholmberg has quit [Remote host closed the connection]
22:11
adamholmberg has joined #pypy
22:19
jamesaxl has quit [Quit: WeeChat 1.9.1]
22:39
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
22:41
oberstet has quit [Ping timeout: 240 seconds]
23:03
adamholmberg has quit [Remote host closed the connection]
23:03
adamholmberg has joined #pypy
23:06
tbodt has joined #pypy
23:08
adamholmberg has quit [Ping timeout: 256 seconds]
23:47
mat^2 has joined #pypy
23:48
<
njs >
obviously this is stuff that should have migrated back upstream into distutils and platform, but they don't find it any easier to fix the stdlib than you do...
23:56
guilherme has joined #pypy
23:56
guilherme has quit [Client Quit]