cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<mattip>
ronan: is array.array required by a python c-extension module?
<ronan>
mattip: scikit-learn cimports it
<mattip>
bummer
<mattip>
maybe we could use PyBuffer* to work around it, but it would be a large chunk of PyPy only code
<kenaan>
tdziopa py3.6 d3ffc4376fe9 /pypy/interpreter/pyparser/parsestring.py: (tdziopa) fix warnings for PyString_DecodeEscape Recent PR introduced a bug with undefined variable ch being acces...
<kenaan>
tdziopa py3.6 bc678f7e35f0 /pypy/interpreter/pyparser/parsestring.py: (tdziopa) fix default value for first_escape_error_char As RPython doesn't allow having int and None in the same v...
<WhatisRT_>
hi! using cffi, is it possible to call a function by its address? I have a function that returns a void *, and I want to call the function this points to
<arigato>
that string is the C type meaning "pointer to function with one arg of type int, returning int"
<arigato>
note just in case, I see handles in what you asked earlier. If the "void *" is actually a handle obtained with ffi.new_handle(), it won't work
<arigato>
with such a "void *" you can only do "ffi.from_handle(ptr)"
<WhatisRT_>
arigato: cool, thanks!
<WhatisRT_>
no, this is unrelated to handles in this case
<WhatisRT_>
but if you know how to get the address of a handle, that would be awesome too
<arigato>
hum, a handle *is* already an address, as in, a "void *" object
<WhatisRT_>
well, I'm literally using int(re.search(r'0x([0-9]|[a-f]|[A-F])*', str(callback_handle)).group(), 16)
<arigato>
if you want to cast a "void *" to an integer you can do: int(ffi.cast("intptr_t", ptr))
<WhatisRT_>
if I try to cast the address, I get a different value
<arigato>
it's a handle over a Python object that happens to be a cdata object, which is a strange thing to do
<arigato>
handles are meant to be used when you need to temporarily hide a Python object inside C code, and get it back later
<WhatisRT_>
ok
<simpson>
WhatisRT_: We might be at the point where you tell us what you're gonna do with the extracted address.
<WhatisRT_>
simpson: nothing scary, just passing it around through some custom stuff
<arigato>
ffi.new_handle() really returns a "void *" which hides the Python object. The actual value of the "void *" is meaningless and it can only be used in ffi.from_handle()
<WhatisRT_>
but maybe my problems might be somewhere else: I just tried the conversion to uintptr_t again on my debian system, and it works there
<idnar>
ah, yes, the hex string in that repr is the address of the cdata pointed to by the handle (it's from the inner <cdata …>), not the handle itself
<arigato>
precisely, that's why you get two different addresses
<WhatisRT_>
ok, that makes sense
<arigato>
it's a handle that contains a Python object that happens to be a cdata object with a type and a value, and that value is 0x101feb080
<arigato>
if you want to pass around to C code something that is already a cdata value, then you might just cast it to a "void *" and back when needed, with ffi.cast("void *", ptr)
<WhatisRT_>
is the address of a handle really useless? I'm passing the address to my c code and it works
<arigato>
yes, you can't do anything with it apart from ffi.from_handle()
<WhatisRT_>
in python? or generally?
<arigato>
generally
<arigato>
it's just an opaque value with no meaning
<WhatisRT_>
so my code shouldn't work
<arigato>
it doesn't point anywhere
<arigato>
I can't explain why it seems to work without seeing your code :-)
<WhatisRT_>
maybe it's because the function has a @ffi.def_extern() attribute?
<WhatisRT_>
so I'm getting a handle to lib.callback
<arigato>
and doing what with it?
<WhatisRT_>
getting its address and giving it to c code
<arigato>
ah, "getting its address" as in with the regular expression
<WhatisRT_>
yes
<arigato>
which doesn't get the address of the handle at all
<arigato>
it returns the address of lib.callback
<WhatisRT_>
ok, so I imagine this is supposed to work
<arigato>
so it happens to work, by accident
<arigato>
you should directly pass lib.callback to C code, and forget about handles
<WhatisRT_>
ah, ok
<WhatisRT_>
that makes everything much nicer
<arigato>
what you were doing is similar to: I have an integer x, I want to pass it, so I pass int(re.search("\d+", repr({'foo': x})))
<arigato>
the handle object plays the same role as the dictionary in this example :-)
<WhatisRT_>
ok, I think now I also understand why some other related stuff was not working
<WhatisRT_>
where I got the handle to a function, and I was extracting the address in the same fashion
tbodt has joined #pypy
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mattip>
nice. more python is better for us anyway
amaury has quit [Ping timeout: 256 seconds]
amaury has joined #pypy
<amaury>
Hi
<amaury>
ronan: I implemented ssl.Session
<ronan>
amaury: cool!
<amaury>
This cffi port is very easy to develop
<kenaan>
amauryfa py3.6 e82fec399c34 /lib_pypy/_cffi_ssl/_stdssl/__init__.py: Add support for PROTOCOL_TLS_CLIENT and PROTOCOL_TLS_SERVER (CPython Issue #28085)
<kenaan>
amauryfa py3.6 2271eaab22b2 /lib_pypy/_cffi_ssl/_stdssl/__init__.py: Return a dummy .session to let more SSL tests pass.
<kenaan>
amauryfa py3.6 fc92860d2c30 /lib_pypy/_cffi_ssl/_stdssl/__init__.py: Apply the rest of CPython Issue 28043. This part is not well tested...
<kenaan>
amauryfa py3.6 869382060075 /lib_pypy/_cffi_ssl/_stdssl/__init__.py: Complete the implementation of PROTOCOL_TLS_CLIENT: host names are checked.
<kenaan>
amauryfa py3.6 2360f76c2d3c /lib-python/3/test/test_ssl.py: Is it only on my machine? 10% of the time, the test fails because the error is: '[SSL: NO_SHARED_CIPHER] error:140...
<kenaan>
amauryfa py3.6 3f675393a946 /lib_pypy/_cffi_ssl/_stdssl/__init__.py: The session.id is a bytes string with NULs, use ffi.unpack() instead of ffi.string()
<mattip>
amaury: feel like implementing win32 enum_certificates ?
<amaury>
I don't have any win32 machine to test one
<mattip>
ok, thanks for Session.
energizer has quit [Remote host closed the connection]
energizer has joined #pypy
energizer has quit [Read error: Connection reset by peer]
energizer has joined #pypy
lritter has joined #pypy
energizer has quit [Read error: Connection reset by peer]