On 02/06/12 04:44, Greg Landrum wrote:
> Hi Paul,
>
> On Fri, Jun 1, 2012 at 1:41 PM, Paul Emsley<paul.ems...@bioch.ox.ac.uk>
> wrote:
>> I've been trying to read boost python docs and I am lost...
>>
>> I'd like to return a PyObject *. I have a RDKit::RWMol, say - or a
>> pointer to a new one if need be...
> If you are using a boost.python interface, and your function is
> exposed using boost::python::def, then the right thing happens
> more-or-less automatically if you have a function that returns an
> RDKit::RWMol *. I say more-or-less because you will probably also have
> to tell the library what to do about ownership of the pointer; you'll
> get a very informative compiler error here if you leave that out and
> it's required.
>
> Even if you're not using boost.python for the entire interface, it may
> be worth trying to use it for the functions where you want to return
> RDKit objects. I have no idea if this is possible, but it's worth a
> try.
>
> You'd do a function something like this:
>
> RDKit::ROMol *
> coot::regularize(RDKit::ROMol&mol) {
> .. do stuff ..
> // construct return value
> RDKit::RWMol *regularized_mol = new RDKit::RWMol(mol);
> update_coords(regularized_mol); // replace with refined positions
> return static_cast<ROMol *>(regularized_mol);
> }
>
> Notice how that has no reference to python objects in it; it's also
> conceivably useful from your C++ code.
> To expose to python, you have in the code for your wrapper module:
> boost::python::def("regularize",coot::regularize,(python::arg("mol")),
> "docs",
> boost::python::return_value_policy<boost::python::manage_new_object>());
>
> This (obviously) isn't tested in any way, shape, or form. It probably
> also won't work unless the whole thing is inside a module that's set
> up using the BOOST_PYTHON_MODULE macro, but it's worth a try.
>
> Having said all of that: this is starting to move in a very highly
> specialized direction that's maybe not interesting to most of the
> readers of rdkit-discuss (though it's fascinating to me :-). I'd
> suggest moving this discussion to rdkit-devel. Paul: if the above
> doesn't work, please post something to rdkit-devel along with a short
> description of how you're creating your python modules (are you using
> SWIG? wrapping them by hand? already using Boost.Python?) and I'll try
> to help more. A pointer to actual code would also help.
>
OK, thanks again.
I have done some reading about boost.python. I understand now (as you
imply) that the idea is not to (have to) use PyObject *s. OK, let's try
with that for the moment.
I have put the code for how I understand the boost interface should work
into the repo now, but it doesn't compile for me. I can't determine
what to do from the compile message - perhaps this is the informative
compiler message to which you refer.. :)
So my question is: is this the pointer ownership message to which you
refer? If so, what do I do? Please tell me to RTFM if appropriate...
relevant directory:
http://coot.googlecode.com/svn/branches/pyro-test/pyrogen/
I added restraints-boost.cc, which contains simply the def of a
simplified version regularize().
I have added the make log for compile restraints-boost too.
http://coot.googlecode.com/svn/branches/pyro-test/pyrogen/make.log
If/when we get this to work, I will try also passing a PyObject * (for
the target geometry description - that may not work - so I may also try
simply boosting my target geometry class - hmmm!)
Cheers,
Paul.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel
