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
forgottenone has quit [Quit: Konversation terminated!]
oberstet has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #pypy
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #pypy
dddddd has quit [Ping timeout: 256 seconds]
jcea has quit [Ping timeout: 240 seconds]
dddddd has joined #pypy
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #pypy
lritter has joined #pypy
_whitelogger has joined #pypy
tsaka__ has joined #pypy
forgottenone has joined #pypy
tsaka__ has quit [Ping timeout: 264 seconds]
tsaka__ has joined #pypy
tsaka__ has quit [Ping timeout: 240 seconds]
oberstet has joined #pypy
<mcon>
mattip: It turns out you were right... almost ;) cffi generates a standard C file that I can cross-compile, *but* in the function definition part (ffibuilder.cdef()) I am forced to define all `typedef`s since I cannot use preprocessor directives there (neither #include nor #if..#else..#endif) and thus I am forced to fix 32/64 bit (e.g.: `typedef unsigned int size_t;` versus `typedef long unsigned int size_t;`)
<mcon>
mattip: This make the whole package non-portable. What is the "best practice" for this situation?
panosl[m] has quit [Quit: Bridge terminating on SIGTERM]
toad_polo has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
astrojl_matrix has quit [Quit: Bridge terminating on SIGTERM]
<mattip>
use the platform includes from stdlib.h and stddef.h
<mattip>
which should typedef size_t for you
<mattip>
in your ffi.source string
<mcon>
mattip: Uhm, *how* can I do that? Any #include directive in cdef(...) raises an error.
<mcon>
mattip: In set_source() they are already there
<mattip>
show me
<mcon>
mattip: Sorry: I just got a Non Maskable Interrupt. I'll be back ASAP!
<mcon>
mattip: Thanks for the pointer. I had read it, but not with due diligence. All I had to do was to *remove* all `typedef`s since they are all covered by standard (beside a few `struct my_internal_struct`, of course). Now I have one residual problem, but probably that's not cffi: how do I convince FFI() to produce a plain ./ell/_ell.so instead of ./ell/_ell.cpython-38-x86_64-linux-gnu.so ?
<LarstiQ>
if you want python to load it, I don't think you want that changed. Put perhaps you want a split into two, a plain C library and the cffi one?
<mcon>
LarstiQ: Please bear with me: I'm really a newbie to cffi. I see that FFI() builds _ell.cpython-38-x86_64-linux-gnu.so while installing with pip produces _ell.abi3.so neither can be imported via `from _ell import *`. I can do that if I rename them to plain `_ell.so` (or make a symlink) what am I missing?
jcea has joined #pypy
jacob22_ has joined #pypy
jacob22 has quit [Ping timeout: 265 seconds]
<mattip>
LarstiQ: unclear what you are proposing
<mattip>
mcon: does that not work? Perhaps add a little CI via github actions that runs your setup.py and builds the library on various platforms
<mcon>
mattip: It does work, somehow, but *only* if I manually rename produced .so to plain _ell.so I am wondering if I am still missing something.
<tos9>
mcon: are you looking for a modern CFFI package setup / CI pipeline?
<mattip>
the cd is needed to keep from trying to import the source directory
<mcon>
mattip: Generic question: is it ok to have the cffi-generated lib (_ell) inside module that wraps it for a "more pythonic" interface (nobody is supposed to use ell._ell directly) or would it be better to have them at the same level?
<mattip>
I think that is great
<mattip>
the way you have it with an __init__.py and the c-extension module makes it simple
<mattip>
putting the c-extension module one level higher would be more complicated to distribute
<mcon>
mattip: That is rationale behind it. I wanted confirmation because I'm a real newbie to this and I'm unsure if I overlooked something (or simply did things in "non standard" way)
<mattip>
would you like to extend the documentation to cover the places you had problems getting started?
<mattip>
I think you ended up exactly where you should be, but your lack of confidence means the documentation needs a good example
<mattip>
or rather needs improvement around the example there is
<mattip>
it is a gitlab instance modified to use hg not git
<mattip>
so you can login with your github credentials and create an issue,
<mattip>
and then create a merge request on a branch off the default branch
<mattip>
the only weird thing is that personal forks are not supported, so you push to the main repo (origin from github terminology)
<mattip>
we need to give you "developer" status so you can push.
<mattip>
which is available for the asking, which is why I ask that you create an issue first (so we know who you are)
<mattip>
if this is too much, you can put a patch on some pastebin and we will create the merge request for you, but then you don't get the sweet sweet cffi cred
<mattip>
</speech>
<mcon>
mattip: ok I'in...
<mcon>
mattip: I created an issue (#487) Writing actual tutorial will *not* happen today, though ;)
<mattip>
thanks!
Taggnostr has quit [Quit: Switching to single player mode.]
Taggnostr2 has joined #pypy
tsaka__ has joined #pypy
<mattip>
nice blog post on flask, sanic, ORM and PyPy