[pypy-dev] Automated binding generation (and maintenance)

Shaheed Haque srhaque at theiet.org
Thu Sep 14 04:02:13 EDT 2017


Hi Wim,

On 14 September 2017 at 01:04,  <wlavrijsen at lbl.gov> wrote:
> Shaheed,
>
>> One issue I am struggling to find a good solution for is to generate an
>> accurate list of the objects (classes, functions, variables etc) in a
>> given
>> header file in order to populate the selection .XML.
>
>
> that option exists, but apparently no-one has ever used it, as it is clearly
> broken. :P It should be:
>
> <selection>
>    <class     pattern="*" file_name="SomeHeader.h" />
>    <enum      pattern="*" file_name="SomeHeader.h" />
>    <function  pattern="*" file_name="SomeHeader.h" />
>    <variable  pattern="*" file_name="SomeHeader.h" />
> </selection>
>
> genreflex exists for backwards compatibility, underneath it's rootcling,
> which accepts this:
>
>   #pragma link C++ defined_in "SomeHeader.h";

Ah, I had not realised rootcling existed. I've seen that I can invoke
it using Python version-specific paths...is this the correct way to
invoke it:

ROOTCLING=/usr/local/lib/python3.6/dist-packages/cppyy_backend
LD_LIBRARY_PATH=$ROOTCLING/lib $ROOTCLING/bin/rootcling -h

or is there a recommended wrapper?

> and that does work ... I'll dig a bit, see what goes wrong with genreflex;
> should be no more than proper rule registration.
> But if not restricting selection, what errors are you seeing?
>

With this:

======
    <selection>
       <class pattern="*" />
       <function pattern="*" />
       <variable pattern="*" />
       <enum pattern="*" />
    </selection>
======

I actually get some warnings and then the error:

======
Warning: Class or struct
basic_string<char16_t,char_traits<char16_t>,allocator<char16_t>
>::_Alloc_hider was selected but its dictionary cannot be generated:
this is a private or protected class and this is not supported. No
direct I/O operation of
basic_string<char16_t,char_traits<char16_t>,allocator<char16_t>
>::_Alloc_hider instances will be possible.
Warning: Class or struct
basic_string<char32_t,char_traits<char32_t>,allocator<char32_t>
>::_Alloc_hider was selected but its dictionary cannot be generated:
this is a private or protected class and this is not supported. No
direct I/O operation of
basic_string<char32_t,char_traits<char32_t>,allocator<char32_t>
>::_Alloc_hider instances will be possible.
Warning: Class or struct
basic_string<_CharT,_Traits,_Alloc>::_Alloc_hider was selected but its
dictionary cannot be generated: this is a private or protected class
and this is not supported. No direct I/O operation of
basic_string<_CharT,_Traits,_Alloc>::_Alloc_hider instances will be
possible.
Warning: Class or struct string::_Alloc_hider was selected but its
dictionary cannot be generated: this is a private or protected class
and this is not supported. No direct I/O operation of
string::_Alloc_hider instances will be possible.
Warning: Class or struct
basic_string<wchar_t,char_traits<wchar_t>,allocator<wchar_t>
>::_Alloc_hider was selected but its dictionary cannot be generated:
this is a private or protected class and this is not supported. No
direct I/O operation of
basic_string<wchar_t,char_traits<wchar_t>,allocator<wchar_t>
>::_Alloc_hider instances will be possible.
Warning: Class or struct ios_base::_Callback_list was selected but its
dictionary cannot be generated: this is a private or protected class
and this is not supported. No direct I/O operation of
ios_base::_Callback_list instances will be possible.
Warning: Class or struct ios_base::_Words was selected but its
dictionary cannot be generated: this is a private or protected class
and this is not supported. No direct I/O operation of ios_base::_Words
instances will be possible.
Error in <CloseStreamerInfoROOTFile>: Cannot find class __pthread_mutex_s.
======

The command line in use is:

======
genreflex /usr/include/KF5/kjs/kjsinterpreter.h -s selection.xml -o
tmp3/kjsinterpreter.cpp -I/usr/include/x86_64-linux-gnu/qt5
-I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/KF5/kjs
-I/usr/include/KF5/wtf
======

I did wonder if I was missing some "-isystem" includes, and tried
adding them but the --debug output from genreflex seemed to suggest
they were being ignored.

>> Short of running Clang directly to generate the names, what options do I
>> have?
>
>
> If using PyPy (not yet CPython), you can load all files in a header, include
> that, and simply start looping over dir(cppyy.gbl). (This is one of a set of
> things that I still have to equalize between PyPy/cppyy and CPython/cppyy.)
>
>> Also, as I looked around for approaches to this issue, I noted that the
>> cppyy backend v610 5 source code has a "getAllClasses" whereas PyPI has
>> 6.10.0.2.
>
>
> That getAllClasses was a hack for compatibility reasons that doesn't do what
> the name supposes it does: there can always be more classes that could be
> found through a mapping file, but haven't yet. Hence a functional dir() is a
> better approach.

Ack. My driver code is exactly intended to handle this kind of thing
by walking the directories and invoking genreflex/rootcling. One issue
is that I've been experimenting with directly using cppyy.gbl.gROOT
et. al. to try to identify only the classes (and later variables etc)
directly in kjsinterprter.h by looking at
cppyy.gbl.gInterpreter.ClassInfo_FileName() for the relevant class
name with something roughly like this:

ci = cppyy.gbl.gInterpreter.ClassInfo_Factory('KJSInterpreter')
cppyy.gbl.gInterpreter.ClassInfo_FileName(ci)

What is interesting, and might possibly throw light on the selection
filter issue, is that the file name for the classes in
kjsinterpreter.h itself is always the empty string ''. Classes that
come from included files return non-empty strings such as
'kjsobject.h' for 'KJSObject'.

BTW, the reason for doing this is that lots of KDE code has multiple
classes and even namespaces in a single header file. Now, for
discoverability of the loaded objects, I find the incremental "pop
into cppyy,gbl on demand" somewhat limiting and I wanted to play about
with that. I could also workaround the filter issue if I precomputed
the needed names in a precursor pass.

Finally, and most importantly given the fidelity with which cppyy
renders the C++ code, I'm think about how Pythonisation customisation
might be handled: e.g. a Python wrapper layer to allow a
pointer-plus-size to render as a Python list/tuple, or generate a dict
mapping fora QSet, and so on. (I'm dimly aware of the
boost-recognition logic you have alluded to, this is specifically more
about Qt-specific patterns and ad-hoc scenarios).

>> I'm not sure of the mapping of versions, but what is the cadence for
>> updates to PyPI?
>
>
> It's only since a few months that I split everything off into a standalone
> package (there's a reason the first version digit is still 0) and I'm still
> sitting on some restructuring to separate things that update often from
> things that don't. The backend part is expected to update every half year
> or so, once packaging stabilizes (that's the cling schedule).
>
>> [1] https://marc.info/?l=kde-core-devel&m=150464598710128&w=2
>
>
> Just a few minor points in response to that message. E.g. yes, overloads
> end up as a single Python function, but if you don't want that, then you
> can use __disp__("signature") to pick out the ones you want. Those are
> first-class objects, and allow any kind of restructuring that Python
> allows.
>
> As for needing cling, that's only if you need the dynamic features. It is
> also possible to use it to generate bindings to be used for cffi. You need
> to pre-instantiate templates and such, but that's already the case for any
> other bindings tool. And for that matter, at that level you could use it
> to generate what you need for SIP, too.

Thanks for the kind hints, but you've only managed to whet my appetite
to get cppyy working as it is exactly things like the handling of
overloads and template instantiation that I want most!

Thanks, Shaheed

P.S. Please note that after today, I'll likely not have much Internet
access for a couple of weeks, so any responses may be limited.

> Best regards,
>            Wim
> --
> WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net


More information about the pypy-dev mailing list