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>
it seems you should use PyObject_GetAttr, PyObject_SetAttr and not directly call the tp_* functions
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
tayfun26 has joined #pypy
drolando has quit [Remote host closed the connection]
<lazka>
it's while chaining up in tp_setattro
drolando has joined #pypy
<lazka>
so I have to use tp_ I think
<kenaan>
mattip cpyext-subclass-setattr dc1bf38e9aed /pypy/module/cpyext/test/: test places that use is_cpytype, reomve noisy print statements
<lazka>
some context: we just have a custom __dict__ to check if the object gets any state, so we have to keep the wrapper around in case we wrap the same C object again later
<WhatisRT>
hi, I'm trying to use the cffi library and am running into problems
<WhatisRT>
I'm trying to link a c library which was built for x86_64, but for some reason it wants a library for i386
<WhatisRT>
there are flags -arch i386 -arch x86_64 passed to cc
<simpson>
Hm. And which CPU are you running on? I haven't seen this before.
<WhatisRT>
some recent i5 CPU on a mac
<WhatisRT>
ld: warning: ignoring file ./libfoo.dylib, file was built for x86_64 which is not the architecture being linked (i386): ./libfoo.dylib
<WhatisRT>
that's the exact error message
<simpson>
Oh, I don't know anything about OSX, sorry.
<WhatisRT>
do you know how I could get rid of the -arch i386 flag?
<WhatisRT>
if I execute the command manually without it, it works
<simpson>
Nope, I don't know what's choosing both of those flags.
illume has joined #pypy
raynold has joined #pypy
<WhatisRT>
ok, now I have the next issue: I've built my example code but it does not find the library that lies in the same folder
<WhatisRT>
ImportError: dlopen(..../python/_example.so, 2): Library not loaded: @rpath/libfoo.dylib
<WhatisRT>
I have passed extra_link_args=['-L.'] to set source so it would accept this library
<WhatisRT>
putting the library in my PATH does not help
<mattip>
__pv: "hitting this" - so you see the leak?
<mattip>
WhatisRT: on linux you need to set LD_LIBRARY_PATH not PATH, dunno if that works on macOS too
<cfbolz>
mattip: I assume they reported the bug
tayfun26 has quit [Quit: tayfun26]
<WhatisRT>
mattip: thanks, I think that worked (i.e. the issue I'm having now seems unrelated to cffi)
<mattip>
WhatisRT: cool
drolando has quit [Remote host closed the connection]
drolando has joined #pypy
<mattip>
working on issue 2776, it seems cpython always calls ioctl(fd, op, arg) with at least 1024 bytes in arg
<mattip>
according to "man ioctl", the number of bytes is actually encoded in the op, and ioctl.h says it is encoded in the "lower 14 bits of the upper 16 bits"
<mattip>
do we take the pragmatic "do what cpython does" or the correct "parse the arg size from op" ? I think the pragmatic :)
<njs>
mattip: pretty sure trying to parse op would be totally non-portable
<njs>
mattip: I think what the man page means is "the kernel will look at the operation and then figure out how much data to read from userspace using a totally ad hoc method invented by some random driver author"
<njs>
I wouldn't be surprised at all to see an ioctl with a variable-length arg
stduolc has joined #pypy
<mattip>
njs: yes, pragmatic beats correct in this case
<njs>
mattip: the options are literally "pragmatic but not 100% correct" or "impractical and also wrong" so I think you're ok :-)
<njs>
https://lwn.net/Articles/48354/ <-- apparently the size encoded in the op is entirely advisory, and for historical reasons involving a disagreement over who was supposed to call sizeof, lots of ioctls have a size field of "4"