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)"
dddddd has quit [Remote host closed the connection]
tbodt has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
raynold has joined #pypy
energizer has quit [Quit: Leaving]
energizer has joined #pypy
energizer has quit [Client Quit]
energizer has joined #pypy
dustinm has quit [Ping timeout: 268 seconds]
dustinm has joined #pypy
<nanonyme>
mattip, fresh install of VS2017 with no prior VS2015 on machine, try to compile CFFI for Python3.5 fails unless vcvarsall.bat is manually run
<nanonyme>
mattip, if you meant that. No big deal imo
<Rotonen>
nanonyme: you're not supposed to compile with vs2017, though
<arigato>
mattip: I also keep getting the same vcvarsall.bat error message with cpython 2.7, I eventually fixed it by defining VS90COMNTOOLS
<arigato>
after looking through the source code
inhahe has quit []
inhahe has joined #pypy
<mattip>
arigato, nanonyme: there is "import setuptools" before "import distutils" ?
<mattip>
in the setup.py
<mattip>
it seems cffi/setup.py calls uses_msvc() ->get_config() -> "import distutils" before "import setuptools"
<nanonyme>
mattip, sounds like setuptools doesn't do it right either then
<nanonyme>
Rotonen, why not? It works fine
<nanonyme>
arigato, any chance of getting the second fix and release done soonish? I can probably backport to ours as necessary
<arigato>
mattip: ah, it's an issue of import order *in addition to* being an issue of monkey-patching? the setuptools/distutils is a complete hack
<nanonyme>
arigato, root cause why your fix doesn't work is there's two FFI().dlopen's, one is in Python-side, one is in C-side (latter is for out-of-order ABI which I use)
<nanonyme>
Both need the unicode treatment
<mattip>
arigato: in the case I pointed out there is no import of setuptools before compiling
<nanonyme>
The C-cide dlopen doesn't call load_module at all
<nanonyme>
Erm, load_library or whatever it was that you fixed
<nanonyme>
arigato, IOW you might have noticed sys.getfilesystemencoding() == "mbcs" until 3.6 on Windows. This is a crazy hack that tries to encode things to be usable through ANSI API's and sometimes works \o/
<arigato>
head <-> wall interaction
<nanonyme>
It gets to some extent worse with 3.6 since then sys.getfilesystemencoding() is "utf-8" so it will 1) never fail to encode 2) never work properly with ANSI API's
<nanonyme>
As in, the UTF-8 string is *valid* through ANSI API, it just will not point to any existing file
<nanonyme>
I suspect it might fail more consistently over different codepages then though
<kenaan_>
arigo cffi/cffi 5448f4eca09c /: More Windows support for ffi.dlopen(), this time the out-of-line version
<arigato>
"maybe"
energizer has quit [Ping timeout: 256 seconds]
energizer has joined #pypy
jacob22__ has joined #pypy
<nanonyme>
I know :(
<nanonyme>
Also I just realized while on lunch that while it might fail more consistently, it will display total bonkers since you'll see the correct path since your console is UTF-8 and filesystem encoding is UTF-8 but this is not at all how Windows interpreted it when you passed it to the ANSI API
<nanonyme>
So IOW 3.6 will blatantly lie to you that the filename is ok
<nanonyme>
(visually)
energizer has quit [Ping timeout: 256 seconds]
lritter_ has quit [Quit: Leaving]
Taggnostr has quit [Remote host closed the connection]
Taggnostr has joined #pypy
ronan has quit [Ping timeout: 260 seconds]
<nanonyme>
Anyhow, time to test your changes again, I guess
<nanonyme>
arigato, sorry for causing all this hassle
<nanonyme>
arigato, to be honest, I'm not 100% sure if it even makes sense to fallback to ANSI-style LoadLibrary rather than to try to decode with filesystem encoding and then call wide version. That might or might not be backwards-incompatible though. Anyhow, current thing works for me nicely now :)
<hams>
looking for some advice on CFFI... i have some code which i can hide most of the complexity but it will return some complex data structures which invovle several structs
<hams>
is this a reasonable usage for CFFI and is there a best practice for using it?
marr has joined #pypy
marky1991 has quit [Remote host closed the connection]
energizer has quit [Disconnected by services]
energizer has joined #pypy
energizer has quit [Remote host closed the connection]
energizer has joined #pypy
Rhy0lite has quit [Quit: Leaving]
marky1991 has joined #pypy
<arigato>
hams: yes, that's reasonable for CFFI
<hams>
arigato: thanks. i'm giving it a try... surprised to find that search for libraries does not honor LD_LIBRARY_PATH until python3.6
<arigato>
unsure what you mean
<arigato>
(that's because you can use cffi in various ways, so I've no clue which one you are using. also, I'm pretty sure there is nothing python3.6-specific)
marky1991 has quit [Ping timeout: 256 seconds]
forgottenone has quit [Remote host closed the connection]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
jamesaxl has quit [Quit: WeeChat 2.0.1]
jacob22__ has joined #pypy
<hams>
does cffi allow C functions to return blocks of memory? v = ffi.new("int *"); lib.some_c_call(v); x = v[1] doesn't appear to work as it says only element 0 is addressable?
adamholm_ has quit [Remote host closed the connection]