cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
lastmikoi has joined #pypy
nimaje has quit [Read error: Connection reset by peer]
<njs>
so here's a weird question: suppose I want to intentionally leak an object, to guarantee that it and its referent graph will never be collected or (most importantly) have their finalizers run. is there any better option for that than spawning a daemon=True thread that sleeps forever with a reference to that object on its stack?
<arigo>
njs: not sure there is a way that works reliably on both pypy and cpython. You could hack at the refcount on cpython, and on pypy simply storing it in the sys module should be enough
Rhy0lite has joined #pypy
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
<arigo>
cool, the wb_before_move branch removes the 10x slow-down in some cases when we shift items around in a gc array (like list.pop(0) or list.insert(0, x))
<antocuni>
cool
<antocuni>
what was the problem?
<arigo>
reading and writing all gc pointers manually, which is slow if the array is an old gc object with cards
<arigo>
unsure the fix is positive in all cases, though
<arigo>
it basically removes the cards in these pop(n) or insert() cases, so it may have a performance hit if you do a lot of list.insert(len(list)-2, x) or something like that
<arigo>
maybe we should still do an item-by-item copy if there's, say, less than 5% of the array involved?
<antocuni>
I'm not sure to understand enough of the problem to give a reasonable answer :)
<mattip>
trying to understand the terminology, this part of rpython seems relevant
adeln has quit [Remote host closed the connection]
adeln has joined #pypy
adeln has quit [Ping timeout: 258 seconds]
<ofir>
Hi, I have 2 libraries libfoo.so and libbar.so. For both I use cffi to build the Python wrappers with cdefs and set_source("_lib", "#include "foo.h""))
<ofir>
After calling ffibuilder, for the _foo.so ELF I do see libfoo.so in the dependencies list: readelf -d ./_foo.so
<ofir>
but for _bar.so there is no libbar.so (in ldd / readelf -d) and so I can't "import _bar" (because of missing symbols).
<ofir>
So the question is, any idea when the consumed library gets added to the ELF (i.e. NEEDED)?
xcm has quit [Remote host closed the connection]
adeln has joined #pypy
xcm has joined #pypy
Taggnostr has quit [Ping timeout: 256 seconds]
otisolsen70_ has quit [Quit: Leaving]
otisolsen70 has joined #pypy
adeln has quit [Ping timeout: 256 seconds]
<arigo>
ofir: maybe you forgot to list "bar" in the libraries=["bar"] argument to set_source()?
<ofir>
I'm passing it as extra_objects=[LIB_PATH]
<ofir>
that's the only way I could get around the linker directories
<arigo>
that's distutils/setuptools subtleties, I'm not sure what it does
<ofir>
it simply adds it to the linker command line
<arigo>
traditionally you'd pass it in libraries and use library_path or something
<ofir>
so it's like: gcc _foo.o /path/to/libfoo.so -shared -o _foo.so
<ofir>
as opposed to: gcc _foo.o -lfoo -shared -o _foo.so
<arigo>
yes, I guess so, but I'm not sure what this does inside gcc
<arigo>
sorry, it's library_dirs, not library_path
<ofir>
that's interesting, if I replace the .so with what CMake built vs what I built manually, all of a sudden it is added to the DT_NEEDED in the ELF
Taggnostr has joined #pypy
<ofir>
I work via VSCode and I use F7 (Build with CMake) to generate the SO's I consume
<ofir>
arigo: what is the equivalent in the kwargs for set_source for linker directories?
<arigo>
library_dirs
<ofir>
I would like the following: -l<lib> -L<dir>
<ofir>
ok let's try that
<ofir>
nope same thing (although a nicer syntax)
<ofir>
gcc/ the linker doesn't like what CMake produces
<arigo>
make sure to call ffibuilder.compile(verbose=True)
<arigo>
should help in debugging what's wrong
<ofir>
thanks, yeah good stuff
<ofir>
ok now I got it
thrnciar has quit [Ping timeout: 265 seconds]
<ofir>
it's the darn name mangling
<ofir>
or so it looks like, checking..
<ofir>
yeap
<ofir>
there should be a post on: "what your mama didn't tell you about extern "C""
<ofir>
the linker will happily link and produce a CFFI wrapper _foo.so for you but will not add the dependencies it needs if you do not expose an "extern C" interface
<ofir>
that's a bit counter-intuitive, I would've expected it to not find the mangled name and fail way earlier..
<ofir>
arigo: did you ever try to pass a C function pointer to a CFFI function?
<ofir>
I have my module.py that instantiates some memory allocator C++ class (MemAllocator) in _foo.so, and _bar.so needs to use that MemAllocator instance, so the Python becomes a pipe.
epony has quit [Ping timeout: 258 seconds]
adeln has joined #pypy
BPL has quit [Quit: Leaving]
adeln has quit [Ping timeout: 260 seconds]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<arigo>
ofir: you can pass C function pointers around, but I don't know if there are specific issues with C++
<njs>
arigo: does the daemon thread trick for leaking an object not work reliably in all python versions? obviously it's gross, but it seems like semantically it gives the right guarantees...