On May 1, 2012, at 10:04 PM, Geoff Hutchison wrote:
>
> What version of SWIG are you using?
>
I have SWIG Version 2.0.6
Compiled with /usr/bin/clang++ [i386-apple-darwin11.4.0]
Configured options: +pcre
On May 2, 2012, at 5:27 AM, Noel O'Boyle wrote:
> Are you comparing 32-bit builds?
>
No, both 64-bit builds, I think.
My homebrew build formulae are at
https://github.com/rwest/homebrew/blob/open-babel-head/Library/Formula/open-babel.rb
Perhaps they need tweaking, in which case I'd be glad of advice.
Version 2.2.3 ( `brew install
https://raw.github.com/rwest/homebrew/open-babel-head/Library/Formula/open-babel.rb
--python`) gives this:
> RWests-iMac: rwest$ otool -hv
> /usr/local/Cellar/open-babel/2.2.3/lib/libopenbabel.dylib
> /usr/local/Cellar/open-babel/2.2.3/lib/libopenbabel.dylib:
> Mach header
> magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 13 1928 NOUNDEFS
> DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
> RWests-iMac: rwest$ otool -hv
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so:
> Mach header
> magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> MH_MAGIC_64 X86_64 ALL 0x00 BUNDLE 12 1832 NOUNDEFS
> DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK
>
> RWests-iMac: rwest$ otool -h
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so:
> Mach header
> magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> 0xfeedfacf 16777223 3 0x00 8 12 1832 0x00018085
> RWests-iMac:2.2.3 rwest$ otool -L
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so
> /usr/local/Cellar/open-babel/2.2.3/lib/python2.7/site-packages/_openbabel.so:
> /usr/local/Cellar/open-babel/2.2.3/lib/libopenbabel.3.dylib
> (compatibility version 4.0.0, current version 4.3.0)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 52.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 159.1.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> 1094.0.0)
And the HEAD (`brew install
https://raw.github.com/rwest/homebrew/open-babel-head/Library/Formula/open-babel.rb
--HEAD`) gives this:
> RWests-iMac:rwest$ otool -hv
> /usr/local/Cellar/open-babel/HEAD/lib/libopenbabel.dylib
> /usr/local/Cellar/open-babel/HEAD/lib/libopenbabel.dylib:
> Mach header
> magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 13 1928 NOUNDEFS
> DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK NO_REEXPORTED_DYLIBS
> RWests-iMac: rwest$ otool -hv
> /usr/local/Cellar/open-babel/HEAD/lib/python2.7/site-packages/_openbabel.so
> /usr/local/Cellar/open-babel/HEAD/lib/python2.7/site-packages/_openbabel.so:
> Mach header
> magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
> MH_MAGIC_64 X86_64 ALL 0x00 BUNDLE 14 1976 NOUNDEFS
> DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK
> RWests-iMac:2.2.3 rwest$
>
> RWests-iMac: rwest$ otool -L
> /usr/local/Cellar/open-babel/HEAD/lib/python2.7/site-packages/_openbabel.so
> /usr/local/Cellar/open-babel/HEAD/lib/python2.7/site-packages/_openbabel.so:
>
> /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/Python
> (compatibility version 2.7.0, current version 2.7.0)
> /usr/local/Cellar/open-babel/HEAD/lib/libopenbabel.4.dylib
> (compatibility version 4.0.0, current version 4.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 159.1.0)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
> 1.2.5)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 52.0.0)
Thanks,
Richard
> - Noel
>
> On 1 May 2012 23:36, Richard West <r.h.w...@gmail.com> wrote:
> Hi all,
> I think that at some point between v 2.2.3 and the current svn trunk, the
> result of OBAtom.GetAtomicNum() in Python changed from type 'int' to 'long'.
> Is this an intentional change to the API that I missed, or an unintentional
> consequence of some change to how the bindings are built? If the former,
> it's easy enough for me to update my python scripts to expect 'long', but I
> thought I'd mention it in case the latter is the case.
> Thanks,
> Richard
>
> Example from IPython:
> In [1]: import pybel
> In [2]: pybel
> Out[2]: <module 'pybel' from
> '/usr/local/lib/python2.7/site-packages/pybel.py'>
> In [3]: m=pybel.readstring("smi","CC")
> In [4]: m.atoms[1].OBAtom.GetAtomicNum()
> Out[4]: 6L
> In [5]: type(_)
> Out[5]: long
>
> Using 2.2.3 you would have got
> Out[4]: 6
> Out[5]: int
>
> --
> Richard H. West, Ph.D. r.w...@neu.edu
> Assistant Professor, Chemical Engineering Department,
> Northeastern University, 360 Huntington Ave, Boston, MA 02115
> http://neu.edu/comocheng Phone: 617-373-5163
> ------------------------------------------------------------------------------
> 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/
> _______________________________________________
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
------------------------------------------------------------------------------
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/
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
