irclogs_io_bot has quit [Ping timeout: 252 seconds]
irclogs_io_bot has joined #pypy
xcm is now known as Guest81762
Guest81762 has quit [Killed (asimov.freenode.net (Nickname regained by services))]
xcm has joined #pypy
marky1991 has quit [Ping timeout: 272 seconds]
<tos9>
cfbolz: the u-bahn from dusseldorf center seems reasonably sane right :)? looks like a 25 minute ride-ish?
<tos9>
(if I choose to stay there, which I probably will)
Zaabtop has joined #pypy
Zaab1t has quit [Ping timeout: 272 seconds]
Zaabtop is now known as Zaab1t
<cfbolz>
Yep, it is
irclogs_io_bot has quit [Remote host closed the connection]
<tos9>
Cool.
<catern>
think I'm missing something obvious... in cffi, if I have a regular python bytes object, and I want to cast it into a cffi pointer to a struct, and have that pointer to a struct outlive the bytes object, what's the idiomatic way to do it?
<catern>
ffi.cast(ffi.from_buffer(data)) turns to garbage as soon as data goes out of scope
<fijal>
catern: *generally* it's your responsibility to keep data alive in this case
<fijal>
since from_buffer does not give you somehting with a handle (you have no idea how long will this stuff live in C)
<catern>
sure, but data is just a Python bytes object, I can't keep it alive without pointlessly passing it around along with the casted pointer
<catern>
I can't get a CFFI pointer that has a reference to the underlying Python bytes and keeps them alive?
<catern>
the docs for from_buffer state that it does keep the original object alive
<catern>
but I assume the issue is that the cast stops that
<fijal>
you need to make a copy
<fijal>
and there is also ffi.gc
<fijal>
but that's the other way around
<fijal>
catern: but also remember - you're storing it in a struct
<fijal>
there is no way to know how long struct is alive and by which mechanism it is freed
<fijal>
so where would you store the extra pointer? it can't be stored in that struct
<fijal>
it can be stored in a magic struct pointer, but we decided against such level of magic
<catern>
hm? I'm only casting these bytes to a struct so I can read the fields from Python
<catern>
the python cffi object certainly isn't just a struct pointer, it also has additional pointers and references to things
<catern>
unless you're saying the char[] returned by from_buffer is magical, in that it has the magic ability to keep another python object alive, and all other cffi pointers don't have that ability?
<catern>
not sure what you mean by "know how long struct is alive and by which mechanism it is freed" - there's no C code involved here for now, it's purely garbage collected
<catern>
in python
irclogs_io_bot has joined #pypy
antocuni has quit [Ping timeout: 246 seconds]
<fijal>
then why are you using cffi?
<fijal>
cffi struct is not magic - it's really a bunch of C pointers
<fijal>
but the cffi python object does keep the struct alive (as does char[] one)
<fijal>
but it does not keep extra python objects alive, like the fields referenced there
<catern>
well, I'm using cffi for other thingsin this program, and now I want to turn some bytes into a struct by casting them (I could alternatively reimplement a bunch of parsing logic but that seems like a waste), so that's why I am using cffi in this one specific instance even though there's no C involved
<catern>
in this case
<catern>
I see, you're saying that if I have a struct foo { void *bar; } and bar points to a python object, a cffi object pointing to a "struct foo*" won't keep the bar object alive?
<catern>
but that's not the situation I'm in
<catern>
I've just got struct quux { int a; int b; int c; }, and a python bytes object that's formatted that way, and I want to read the latter as the former
_whitelogger has joined #pypy
Zaab1t has quit [Quit: bye bye friends]
Rhy0lite has quit [Quit: Leaving]
demonimin has joined #pypy
amaury has joined #pypy
amaury is now known as Guest90598
Ai9zO5AP has quit [Quit: WeeChat 2.3]
<_aegis_>
cool gc post, I assume there's nothing I can do about calling a pypy function from C during a GC pause though
<atomizer>
catern: the result of ffi.cast is a reference, if the object dies it points to garbage
<atomizer>
i'd suggest casting at every consumer site instead of casting once and keeping bytes alive on the side