Re: [Rdkit-discuss] Python argument types did not match C++ signature
On Oct 14, 2014, at 8:41 PM, Greg Landrum greg.land...@gmail.com wrote: The first thing that comes to mind, and I'm not sure that this has any relevance at all, is that it could be an import order thing. Does Bill import Chem before he imports your code? The next possibility that I can come up with is that there was something different in the build of your code and the RDKit on Bill's machine. I’ve just completely rebuilt everything to ensure all are built with exactly the same compiler. The error persists. As a positive control, I can create a SMILES structure within (the same) RDKit, and manipulate (add/remove) the hydrogens. Either different compiler versions were used or different RDKit versions or different boost versions. This somehow ends up being enough to screw up the type recognition between the two extension modules. A check here is to be sure that they were built using the same environment, that Python is using the one you think it is, and that DYLD_LIBRARY_PATH is set such that the correct RDKit libs are being found. As far as I am able to tell, all of this is true (as mentioned, the paths are hard-coded, but I also tried with manually setting $DYLD_LIBRARY_PATH, just in case it mattered. It didn’t). I’ll poke around some more. Thanks. William G. Scott http://scottlab.ucsc.edu/~wgscott -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Rdkit-discuss mailing list Rdkit-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
[Rdkit-discuss] Python argument types did not match C++ signature
Hi RDKitters,
I'm a bit lost with boost::python/RDKit/MacOSX.
I have a boost::python function:
RDKit::ROMol *hydrogen_transformations(const RDKit::ROMol r);
which is exposed like this:
BOOST_PYTHON_MODULE(pyrogen) {
def(hydrogen_transformations, hydrogen_transformations,
return_value_policymanage_new_object());
}
When I run this on my computers (RHEL6, Ubuntu, Fedora), it compiles and runs
fine fine. When Bill Scott tries on his Mac, at run-time he gets:
File /sw/lib/python2.7/site-packages/coot/pyrogen.py, line 607, in
make_restraints
sane_H_mol = pyrogen_boost.hydrogen_transformations(m_H)
Boost.Python.ArgumentError: Python argument types in
pyrogen_boost.hydrogen_transformations(Mol)
did not match C++ signature:
hydrogen_transformations(RDKit::ROMol)
Where m_H is created like this:
m_H = AllChem.AddHs(m)
and has type:
class 'rdkit.Chem.rdchem.Mol'
I'm not following why a Mol is not an RDKit::ROMol.
I'd appreciate any insight.
We are using slightly different versions of Boost (1.54 vs boost1.53.python27)
and RDKit_2014_03_1.
Thanks,
Paul.
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
Re: [Rdkit-discuss] Python argument types did not match C++ signature
Hi Paul,
On Tue, Oct 14, 2014 at 11:22 PM, Paul Emsley pems...@mrc-lmb.cam.ac.uk
wrote:
I'm a bit lost with boost::python/RDKit/MacOSX.
I have a boost::python function:
RDKit::ROMol *hydrogen_transformations(const RDKit::ROMol r);
which is exposed like this:
BOOST_PYTHON_MODULE(pyrogen) {
def(hydrogen_transformations, hydrogen_transformations,
return_value_policymanage_new_object());
}
That all looks fine.
When I run this on my computers (RHEL6, Ubuntu, Fedora), it compiles and
runs fine fine. When Bill Scott tries on his Mac, at run-time he gets:
File /sw/lib/python2.7/site-packages/coot/pyrogen.py, line 607, in
make_restraints
sane_H_mol = pyrogen_boost.hydrogen_transformations(m_H)
Boost.Python.ArgumentError: Python argument types in
pyrogen_boost.hydrogen_transformations(Mol)
did not match C++ signature:
hydrogen_transformations(RDKit::ROMol)
Where m_H is created like this:
m_H = AllChem.AddHs(m)
and has type:
class 'rdkit.Chem.rdchem.Mol'
I'm not following why a Mol is not an RDKit::ROMol.
Don't get hung up on that bit; it's the usual way that those error messages
are worded. The first bit tells you the python type name, the second the
C++ type name. The problem here is that it seems to not recognize that it
should be able to translate the Mol into the ROMol.
I'd appreciate any insight.
ooof... insight's going to be tough... how about guesses? ;-)
The first thing that comes to mind, and I'm not sure that this has any
relevance at all, is that it could be an import order thing. Does Bill
import Chem before he imports your code?
The next possibility that I can come up with is that there was something
different in the build of your code and the RDKit on Bill's machine. Either
different compiler versions were used or different RDKit versions or
different boost versions. This somehow ends up being enough to screw up the
type recognition between the two extension modules. A check here is to be
sure that they were built using the same environment, that Python is using
the one you think it is, and that DYLD_LIBRARY_PATH is set such that the
correct RDKit libs are being found.
-greg
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
Re: [Rdkit-discuss] Python argument types did not match C++ signature
On Oct 14, 2014, at 8:41 PM, Greg Landrum greg.land...@gmail.com wrote:
Hi Paul,
On Tue, Oct 14, 2014 at 11:22 PM, Paul Emsley pems...@mrc-lmb.cam.ac.uk
wrote:
I'm a bit lost with boost::python/RDKit/MacOSX.
I have a boost::python function:
RDKit::ROMol *hydrogen_transformations(const RDKit::ROMol r);
which is exposed like this:
BOOST_PYTHON_MODULE(pyrogen) {
def(hydrogen_transformations, hydrogen_transformations,
return_value_policymanage_new_object());
}
That all looks fine.
When I run this on my computers (RHEL6, Ubuntu, Fedora), it compiles and runs
fine fine. When Bill Scott tries on his Mac, at run-time he gets:
File /sw/lib/python2.7/site-packages/coot/pyrogen.py, line 607, in
make_restraints
sane_H_mol = pyrogen_boost.hydrogen_transformations(m_H)
Boost.Python.ArgumentError: Python argument types in
pyrogen_boost.hydrogen_transformations(Mol)
did not match C++ signature:
hydrogen_transformations(RDKit::ROMol)
Where m_H is created like this:
m_H = AllChem.AddHs(m)
and has type:
class 'rdkit.Chem.rdchem.Mol'
I'm not following why a Mol is not an RDKit::ROMol.
Don't get hung up on that bit; it's the usual way that those error messages
are worded. The first bit tells you the python type name, the second the C++
type name. The problem here is that it seems to not recognize that it should
be able to translate the Mol into the ROMol.
I'd appreciate any insight.
ooof... insight's going to be tough... how about guesses? ;-)
The first thing that comes to mind, and I'm not sure that this has any
relevance at all, is that it could be an import order thing. Does Bill import
Chem before he imports your code?
The next possibility that I can come up with is that there was something
different in the build of your code and the RDKit on Bill's machine. Either
different compiler versions were used or different RDKit versions or
different boost versions. This somehow ends up being enough to screw up the
type recognition between the two extension modules. A check here is to be
sure that they were built using the same environment, that Python is using
the one you think it is, and that $DYLD_LIBRARY_PATHis set such that the
correct RDKit libs are being found.
-greg
Hi Greg:
Thanks for the feedback.
The main likely differences are
1. I am using Apple’s clang++
2. I am using (fink’s) boost1.53.python27 to build (fink’s) RDkit (vers
2014.03.1). It was kind of an ordeal to get it working, so there is a distinct
possibility I f-ed something up.
$DYLD_LIBRARY_PATH is by fink policy unset, but the library paths are all
correctly hard-coded, and (in my case at least) I don’t have any other set of
libs for it to find.
Thanks.
Bill
William G. Scott
http://scottlab.ucsc.edu/~wgscott
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
