On 2012-12-12 22:02, Maciek Wójcikowski wrote:
> I have simmilar problem building Trunk on CentOS 5:
>
> CMakeFiles/bindings_python.dir/python/openbabel-python.cpp.o: In
> function `_wrap_new_OBFreeGridPoint__SWIG_0':
> /mnt/lustre/home/maciek/openbabel/openbabel-svn/scripts/python/openbabel-python
I have simmilar problem building Trunk on CentOS 5:
CMakeFiles/bindings_python.dir/python/openbabel-python.cpp.o: In function
`_wrap_new_OBFreeGridPoint__SWIG_0':
/mnt/lustre/home/maciek/openbabel/openbabel-svn/scripts/python/openbabel-python.cpp:20526:
undefined reference to `OpenBabel::OBFreeGri
Hi,
On Wed, Dec 12, 2012 at 5:55 PM, Geoffrey Hutchison wrote:
>
> On Dec 12, 2012, at 11:44 AM, Noel O'Boyle wrote:
>
> > I can't find it on the Daylight website, or in the OpenSMILES spec,
> > but Roger has told me (the classic "appeal to authority" argument)
> ...
> > Certainly Daylight's Dep
On Dec 12, 2012, at 11:44 AM, Noel O'Boyle wrote:
> I can't find it on the Daylight website, or in the OpenSMILES spec,
> but Roger has told me (the classic "appeal to authority" argument)
...
> Certainly Daylight's Depict (http://www.daylight.com/daycgi/depict)
> does not accept c1nncc1, but is
I can't find it on the Daylight website, or in the OpenSMILES spec,
but Roger has told me (the classic "appeal to authority" argument)
that "For aromatic nitrogens in SMILES the number of implicit
hydrogens is always specified. [nH] and [nH+] indicate one, "n", [n]
and [n+] indicate zero." That "n"
Hi Noel,
> I've run into the problem that the current kekulization code (or at least
> that invoked by the SMILES reader) does not take into account the location of
> implicit Hs, rather it works it out itself independently of anything I do.
I think the problem has been not-quite-kosher SMILES.
On 11 December 2012 16:39, David van der Spoel wrote:
> On 2012-12-10 15:44, Geoffrey Hutchison wrote:
>>> The SSSR of buckyball has changed. Can I just update the energy in the
>>> appropriate test file?
>>
>> Yes. You can do that manually or run ffmff94 -g to re-generate the test file.
>>
> By t
Hi Geoff,
I've been implementing the SMILES valence model to set the number the
implicit hydrogens at the point of reading a SMILES string.
I've run into the problem that the current kekulization code (or at
least that invoked by the SMILES reader) does not take into account
the location of impli
The docs for OBMol &operator+= are currently as follows:
//! Copies atoms and bonds but not OBGenericData
OBMol &operator+=(const OBMol &mol);
So, mola += molb adds molb to mola but does not copy the stereo or
residue info (among others). Is there a rationale for this?
Shouldn't mola = molb
