dddddd has quit [Remote host closed the connection]
<kenaan>
rlamy apptest-file 0cc7bfd94fd8 /pypy/doc/contributing.rst: fix option name
Kipras_ has joined #pypy
kipras has joined #pypy
Kipras_ has quit [Ping timeout: 245 seconds]
marky1991 has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
marky1991 has quit [Ping timeout: 248 seconds]
xcm has quit [Remote host closed the connection]
ionelmc has joined #pypy
<ionelmc>
is there anything to pretty print contents of cdata objects (from cffi)?
xcm has joined #pypy
rubdos has joined #pypy
marky1991 has joined #pypy
<arigato>
No
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
marky1991 has quit [Ping timeout: 246 seconds]
marky1991 has joined #pypy
<arigato>
ionelmc: sorry for the short answer. the longer one is the same: there is no built-in way to print, say, the content of an array of ints. Maybe try list(x), which turns such an array into a list
<BPL>
I've tried If I try to do `cffi_lib.foo(ctypes.POINTER(ctypes.c_float).from_buffer(my_python_array))` but I'll get "TypeError: initializer for ctype 'float *' must be a cdata pointer, not LP_c_float", any suggestion?
tsaka__ has quit [Ping timeout: 250 seconds]
<LarstiQ>
BPL: how about cffi_lib.foo(my_python_array)?
<LarstiQ>
"Working with pointers, structures and arrays"
<BPL>
LarstiQ: Hey, no, that wouldn't work, yeah, i've read briefly that section but didn't understand all the gritty details. Right now I was using ctypes directly but I'm getting some nice access violation reading when using something like this https://bpaste.net/show/5cZo
<LarstiQ>
I would stay far away from ctypes
<BPL>
sure, that was my intention... but i've got stuck with this trivial attempt to wrap a very little function so i thought it'd be good to check if casting with ctypes would be easier
<LarstiQ>
BPL: where does the array come from? How about `ffi.new("float[<length>]")`
<LarstiQ>
BPL: answer, no :)
<BPL>
LarstiQ: The real array would be a huge interleaved chunk of topological data. The whole idea would be casting that whole memory area in C with as little overhead as possible
<BPL>
anyway, let me paste my snippet using cffi... maybe you'll see what's the mistake
<BPL>
LarstiQ: Ok, here https://bpaste.net/show/LzE9 , line #28 will give this error => TypeError: initializer for ctype 'float *' must be a cdata pointer, not LP_c_float
<BPL>
LarstiQ: I'm gonna try that ffi.new("float[<length>]") suggestion... but this smells like it's gonna reallocate new memory and I'd like to avoid that (if possible)
<LarstiQ>
BPL: use that instead of the `from array import array` though
<LarstiQ>
that is what I was asking with "where does the array come from"
<LarstiQ>
maybe you snippet isn't representative for that?
<BPL>
LarstiQ: Ok, first thing first, using ffi.new would work out of the box. That said, my original code has a bunch of datatypes inheriting from array.array where the whole memory allocation is done... so my question is, isn't there any way to cast that memory to something suitable to cffi?
<BPL>
or in the worst case scenario, isn't there a fast memcpy from array.array=>cffi ?
<LarstiQ>
there might be
<BPL>
also... i'm still wondering why when using ctypes I'd get access reading violation with this code `foo(ctypes.cast(c_float_p.from_buffer(verts), c_float_p), len(verts))`
<LarstiQ>
BPL: I don't know, imo the right answer is nearly always "don't touch ctypes"
<LarstiQ>
if you really want to know you'd need to dig or talk to someone whos knows the cffi codebase
<BPL>
LarstiQ: Fair enough :) , actually for years I've been using swig... but today I feel I'd like to use directly the good old dlls with ctypes or cffi
<LarstiQ>
BPL: anyway, seems you have what you need now?
<BPL>
LarstiQ: Yeah, idd, tyvm... everything fine now... also, I'm thinking I seriously should learn more about this CFFI library, I've read the https://cffi.readthedocs.io/en/latest/using.html and it looks an awesome project
<BPL>
btw, what'd you say is the "cleanest" way to create python bindings for c++ classes using cffi? So far I've just seen this trivial example https://gist.github.com/tonyseek/7821993 . But it'd be cool to see some example dealing with more complex classes (templates/operators/...)
<BPL>
LarstiQ: Wow, awesome... reading now, i didn't know about this one at all :O ... and i thought i knew all existing python libraries to help you creating wrappers, ty!
<BPL>
LarstiQ: Sure, that's why i asked the "cleanest" way... although i guess exposing a C compatible API for a large project would involve automating the "C compatible API" creation somehow with some c++ parser
<LarstiQ>
and at that point "cppyy: Automatic Python-C++ bindings" starts sounding attractive :)
tsaka__ has joined #pypy
lritter has joined #pypy
Rhy0lite has quit [Quit: Leaving]
dddddd has joined #pypy
speeder39_ has quit [Quit: Connection closed for inactivity]
tsaka__ has quit [Quit: Konversation terminated!]
tsaka__ has joined #pypy
<ionelmc>
ooooof ... doesn't cffi support bitfield structs?
<BPL>
LarstiQ: Wow, I've been playing 5 minutes with the library you suggested me and I can just say that's a truly awesome project :O ... do you know if there is any irc channel available?