[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    Re: [pypy-dev] GSoC 2015: cpyext project?
From:       Toby St Clere Smithe <mail () tsmithe ! net>
Date:       2014-12-03 21:14:09
Message-ID: 87lhmoiggu.fsf () tsmithe ! net
[Download RAW message or body]

Dear Wim,

wlavrijsen@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
[prev in list] [next in list] [prev in thread] [next in thread]