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)"
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<nanonyme>
arigato, ping, I'm resulting in tons of strangeness here with out-of-line ABI-mode. Specifically 'utf-8' codec can't decode byte on library name though it's supposed to be a unicode object (Python3). The strangeness is I don't see anything from within CFFI in my traceback, only my own code
<nanonyme>
I guess the dlopen hits C code immediately, would that explain why the traceback looks so weird?
<arigato>
I can't really say anything without a way to reproduce the problem myself
<nanonyme>
I don't think you can reproduce it easily without having Windows
<arigato>
I do have Windows nowadays
<nanonyme>
Ah
<nanonyme>
Basically what repros this for me is I have a path containing ™ symbol and DLL is inside it
<arigato>
ah, simply
<arigato>
I can give it a try
<nanonyme>
I don't know if it repros in other setups than out-of-line ABI mode
<nanonyme>
It's possible I could sort this out by just upgrading to Python3 and passing it a UTF-8 bytestring since 3.6 changed filesystem encoding to UTF-8
<nanonyme>
But I'd totally prefer CFFI would work consistently with unicode objects :)
jcea has joined #pypy
<Rotonen>
nanonyme: get yourself a C ide - visual debuggers with mouse hover of everything at debug runtime greatly help
<Rotonen>
much easier to keep mental track of things than parsing a textual locals table
<Rotonen>
YMMV etc.
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 240 seconds]
<nanonyme>
arigato, right, so looks like CFFI on Python3 on Windows without "PEP 528 and PEP 529, Windows filesystem and console encoding changed to UTF-8." is just broken
<nanonyme>
arigato, I tried pre-encoding to UTF-8 and got garbage back meaning it most likely tried to decode with mbcs. You cannot encode with mbcs because it doesn't support all valid Windows path characters
<nanonyme>
Pre-encoding trick starts with Python3 assuming that feature because then decoding with filesystem encoding results in original unicode object
<nanonyme>
Meh, looks like the workaround doesn't help either, something is still breaking the path preventing the DLL load
inad922 has joined #pypy
raynold has quit [Quit: Connection closed for inactivity]
Taggnostr has quit [Quit: No Ping reply in 180 seconds.]
Taggnostr has joined #pypy
adamholmberg has joined #pypy
jcea has quit [Quit: jcea]
jcea has joined #pypy
jcea has quit [Client Quit]
marky1991 has joined #pypy
jcea has joined #pypy
<kenaan_>
cfbolz py3.5 ff6a031587c2 /pypy/objspace/std/: fix mapdict-size-limit on pypy3
<kenaan_>
cfbolz default 87ece4f2df4d /pypy/objspace/std/mapdict.py: re-enable on default as well
dddddd has joined #pypy
demonimin has joined #pypy
<nanonyme>
arigato, had a chance to test?
<cfbolz>
mattip (logs): cpyext-datetime2 didn't add a single test. did you forgot to add the test file or something?
<cfbolz>
I suspect the code is broken on py3.5, because the changes to datetime.py didn't get merged (that's not automatic, the file is in a different location in py3.5 :-( )
<cfbolz>
if you add the test, I will fix stuff on py3.5
<nanonyme>
Rotonen, my main difficulty is tracing through the Python<->C boundary when I'm not totally sure what C functions are getting called when something that looks like a class gets instantiated and a method is called
<Rotonen>
visual studio is actually rather good at diving in when something crashes
<Rotonen>
dunno with pypy, though
<Rotonen>
but cpython provides some hook so the windows crash dialog lets you debug desymbolicatedly if have the source in the correct location (something like c:\cpython35 or such, hardcoded as far as i can see)