Re: [pypy-dev] cppyy and callbacks

Hi Alex, On Fri, 24 Jan 2014, Alex Stewart wrote: Speaking as somebody who is currently using cppyy to build a Python binding for a large already-existing third-party C++ library, I have to say I think that moving cppyy in that direction would be a substantial step *backwards*, making cppyy subs

Re: [pypy-dev] cppyy and callbacks

On Fri, Jan 24, 2014 at 12:41 PM, Armin Rigo wrote: > On Fri, Jan 24, 2014 at 6:56 PM, wrote: > > By default, there is memory tracking, auto-casting, overloading, template > > instantiation (with cling; partially with cint), etc. And if that is not > > desired, a Python layer can be written to

Re: [pypy-dev] cppyy and callbacks

Hi Armin, So you're basically answering "no" :-) no, I'm not saying no. (Okay, now I did twice. :) ) I did say that it was high on my wish list, after all. I know that there are many people who like to work the explicit way, which is why such an interface needs to be provided. And it can be d

Re: [pypy-dev] cppyy and callbacks

Hi Wim, On Fri, Jan 24, 2014 at 6:56 PM, wrote: > By default, there is memory tracking, auto-casting, overloading, template > instantiation (with cling; partially with cint), etc. And if that is not > desired, a Python layer can be written to do things differently. E.g. to > select a specific ov

Re: [pypy-dev] cppyy and callbacks

Hi Armin, I meant specifically the way the interface is to be used by the end programmer, ignoring its implementation for now. This would mean moving to more cffi-like idioms: removing the implicit ownership-tracking logic, not guessing too hard about which overloaded function is meant to be ca

Re: [pypy-dev] cppyy and callbacks

Hi Wim, On Fri, Jan 24, 2014 at 6:28 PM, wrote: > yes, it does. Is high on my wish list (and not just the programmer-facing > side, also the internals although there are several things that are close > but don't quite fit). I meant specifically the way the interface is to be used by the end pro

Re: [pypy-dev] cppyy and callbacks

Hi Armin, More generally, wouldn't it make some sense to try to bring cppyy closer to cffi? yes, it does. Is high on my wish list (and not just the programmer-facing side, also the internals although there are several things that are close but don't quite fit). At the top is cling, though, and

Re: [pypy-dev] cppyy and callbacks

Hi, On Thu, Jan 23, 2014 at 10:36 PM, wrote: >> I was considering the possibility of taking an index or id() of the object >> and just casting it into "void*" form, and then converting it back and >> using it to look up objects in a list/dict somewhere.. > > Alex Pyattaev did this (is in the pyp

Re: [pypy-dev] cppyy and callbacks

Hi Alex, (I'm a little unclear what it means to represent "void*" as an array (array of what?), exactly. A PyCObject is useless by design (but lacking in PyPy AFAICT, other than in cpyext, which use would be slow), as is an array of void. It is the best equivalent I could come up with ... I f

Re: [pypy-dev] cppyy and callbacks

> > Some code is in, on the reflex-support branch (to be merged once it is > documented): void* is represented as an array (I didn't see a PyCObject or > PyCapsule outside of cpyext), both for returns and data members. There is > a special case cppyy.gbl.nullptr (C++11 style), which is a unique obj

Re: [pypy-dev] cppyy and callbacks

Hi Alex, Out of curiosity, how much work do you expect the cppyy part of things to be? (I'd offer to help, but I suspect it's all way over my head..) the work it self is mostly transliterating code. Cleaning it up and removing dependencies is a different matter. This does also beg another q

Re: [pypy-dev] cppyy and callbacks

Hi Alex, That would be awesome, if it's not too much trouble.. well, void* is trouble by definition, but it has to be dealt with. Doing something with it, is actually not that hard, but getting it consistent is. Some code is in, on the reflex-support branch (to be merged once it is documented

Re: [pypy-dev] cppyy and callbacks

> > sorry for not responding earlier; had a bit of rough week at work. No worries.. I'm used to some lists where people can take a week or more to respond, so this is actually a refreshing change :) But I'll first start implementing void* now. > That would be awesome, if it's not too much troub

Re: [pypy-dev] cppyy and callbacks

Hi Alex, sorry for not responding earlier; had a bit of rough week at work. So I actually worked around this problem by not using "void *" at all and passing around intptr_t values instead, Yes, I was going to suggest that. :) But I'll first start implementing void* now. Later, Wim -- w

Re: [pypy-dev] cppyy and callbacks

> > Ok, so I think I'm really close to having something working now, except > for one thing: I can't figure out how to access/pass a void pointer via > cppyy? > So I actually worked around this problem by not using "void *" at all and passing around intptr_t values instead, which actually works b

Re: [pypy-dev] cppyy and callbacks

> > For global functions, I've found helper with void* + cffi (the way you've > described in your mail) enough. Ok, so I think I'm really close to having something working now, except for one thing: I can't figure out how to access/pass a void pointer via cppyy? If I declare a C++ function/meth

Re: [pypy-dev] cppyy and callbacks

Hey Wim, Thanks for all the useful info on the status of things! > Overriding of virtual functions can only be done with a helper class > deriving from the callback interface on the C++ side. There's no other > (portable) way. Yeah, I kinda figured this would be required regardless, and that b

Re: [pypy-dev] cppyy and callbacks

> > On a sidenote - can you please subscribe to pypy-dev so I don't have > to authorize every single one of your mail? I'm a bit confused.. I've been subscribed to pypy-dev (and receiving list mail) since some time in August. (I just went to the mailman page for the list and logged in with my pa

Re: [pypy-dev] cppyy and callbacks

Hi Alex, I'd looked around a bit but could only find vague references to CINT, and it wasn't even clear to me whether a full CINT backend really existed or it was just a hack/experiment. it's quite alive; in high energy physics, Reflex is only used by mapping Reflex information into CINT, then

Re: [pypy-dev] cppyy and callbacks

Hi Dimitri, Where could I find the current state of the cling backend implementation? remember, I only just started (as in: a couple of days ago); the code does not currently compile, let alone run a single test. When it gets there, it'll appear here: https://bitbucket.org/pypy/pypy/branch/

Re: [pypy-dev] cppyy and callbacks

and callbacks (Maciej Fijalkowski) >> >> >> -- >> >> Message: 1 >> Date: Fri, 10 Jan 2014 09:13:05 +0200 >> From: Maciej Fijalkowski >> To: Alex Stewart >> Cc: PyPy Deve

Re: [pypy-dev] cppyy and callbacks

On Fri, Jan 10, 2014 at 1:58 AM, Alex Stewart wrote: > I'd looked around a bit but could only find vague references to CINT, and it > wasn't even clear to me whether a full CINT backend really existed or it was > just a hack/experiment. Is it actually suitable for general-purpose use? > > If so,

Re: [pypy-dev] cppyy and callbacks

I'd looked around a bit but could only find vague references to CINT, and it wasn't even clear to me whether a full CINT backend really existed or it was just a hack/experiment. Is it actually suitable for general-purpose use? If so, I'd certainly be happy to try it.. how would one go about swit

Re: [pypy-dev] cppyy and callbacks

Hi Ryan, What about the CINT backend? the way we "jit" code with CINT, is by generating a temporary file, then running the dictionary generator over it, and pulling everything through the C++ compiler. Works, but ... Also, the CINT backend carries more dependencies than strictly necessary, fo

Re: [pypy-dev] cppyy and callbacks

Hi Alex, I have to say, I'm pretty impressed with how smoothly it all works! good to hear. The one main issue I'm left with at this point, however, is that for any sort of real application, Bullet makes substantial use of callbacks (both in the form of some global C++ function pointers as we

Re: [pypy-dev] cppyy and callbacks

What about the CINT backend? https://bitbucket.org/pypy/pypy/src/52bbec630c1faec5ea0c1772872411de541d507f/pypy/module/cppyy/test/test_cint.py On Thu, Jan 9, 2014 at 12:14 P