Dear Wim, wlavrij...@lbl.gov writes: > I'll just quickly answer here first, get into more detail later on the > private e-mail (although that won't be for today anymore).
Sure. My comments here will also be mostly general (regarding what you've written below). I've suspected that most of what you write is the case, so thanks for clarifying that -- in particular regarding cppyy/PyCling/refactoring (this is fairly clear once you play with the various parts!). I also agree that is it very interesting, and I've also been wondering about the automated Pythonization bits; I agree that the automated bindings just give you something clunky. From my own point of view, I would again be very keen to work on something like that -- not only because it sounds rather fun, but also because it would save me a lot of work regarding PyViennaCL in future! I'm quite interested in the gory details and the fine-tuning, and think I could make quite a good GSoC proposal about this. It's also quite convenient that there is scope to work on it under the aegis of both PyPy and CERN, since that maximises the chances of organisation acceptance (not that it is likely, it seems to me, that either would be rejected). I look forwad to your e-mail tomorrow! Best, Toby > We actually have cppyy on CPython with Cling as a backend. The nice thing > about a C++ interpreter is that you can do things like: > > $ python > Python 2.7.7 (default, Jun 20 2014, 13:47:02) [GCC] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > using my private settings ... > >>> import cppyy > >>> from cppyy.gbl import gInterpreter > >>> gInterpreter.Declare("template<class T> class MyClass { public: T m_val; > };") > True > >>> from cppyy.gbl import std, MyClass > >>> v = std.vector(MyClass(int))(1) > >>> v[0].m_val > 0 > >>> v[0].m_val = 2 > >>> v[0].m_val > 2 > >>> > > Clearly, it then also allows to build a 'cppffi' as Armin has asked for. > > The catch is that there is a boat load of refactoring to be done. The heavy > lifting in the above module is in libCore, libCling, and libPyROOT, for > example, which are all part of ROOT. (cppyy in PyPy is properly factored.) > > When we refer to 'PyCling', we mean the above, but refactored. To first > order, that can be done by stripping all ROOT bits out of PyROOT, but better > would be that it utilizes the same backend as does cppyy in PyPy. (You can > also use the AST directly, in theory, leaving only clang/llvm as dependency, > but we tried that, but it doesn't work. I can get you all the gory details.) > > There is more fun to be had then that, though. E.g. cppffi as already > mentioned. But beyond, fully automatically generated bindings get you 95% > of the way only. Yes, you get everything bound, but it smells like C++ and > is sometimes clunky. Pythonizations get you to 99%, e.g. the above session > can be continued like so: > > >>> for m in v: > ... print m.m_val > ... > 2 > >>> > > b/c the PyROOT code recognizes the begin()/end() iterator paradigm. Smart, > reflection-based pythonizations are a project in themselves. > > Then to get to 100%, requires some proper hooks for the programmer to > fine tune behavior, and although PyROOT has some of that, it's rather ad > hoc (e.g. settings for memory ownership and GIL handling) and I've never > taken to time to think that through, so that could be another fun project. > > As said, I'll get to the other e-mail tomorrow. > > Best regards, > Wim -- Toby St Clere Smithe http://tsmithe.net _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev