OEOmegaConfTest has been created specifically for output from
OMEGA. This conftest ignores invertible nitrogen stereochemistry that OMEGA
freely adjusts in order to allow these conformers to be read into the same
OELibraryGen.SetValidateKekule added to set
whether alternative Kekulé forms are enumerated until a valid form
is identified before returning a product.
oemolithread.GetMolData method added to return
a generator over all the molecules of a file in their string
representation in the source format.
The oemolthreadbase.GetMol method for
oemolithread class will now return chunks of
molecule files that can be directly written to files to enable faster
tokenization of a molecule file. Before this release, this method
would often not return whitespace that was necessary to delineate
boundaries between molecules.
OEPerceiveResidues had a bug introduced in the
2012.Feb release that could cause crashes or strange
data to be written to the OEAtomBase.GetName
field whenever OEAtomBase.GetAtomicNum returned
0. Atoms with an atomic number of 0 will now be given the
name of `` UNK`` (note, the leading space to match PDB style
OEAssignAromaticFlags no longer takes an
OEAroModel, which was a unsignedshort* typedef, but takes
an integer from the OEAroModel namespace
instead. Global constants prepended with OEAroModel* are now
deprecated. This works around a serious bug that would sometimes
cause OEAssignAromaticFlags to not do anything to
the molecule. This may break source-level backwards compatibility
for strongly typed languages (C++, Java, and C#) if a global
constant prepended with OEAroModel* was stored as a
Python code should continue to work due to dynamic typing. The only
change for python is that the following OEAroModel* global
constants are now deprecated.
OEParseCommandLine will now call exit(0) if
the internal call to OECheckHelp returns
true that a --help parameter is found. That is, program
execution with the --help parameter should not be considered
abnormal program termination.
OESystem::OEBitVector::ToHexString documentation has been
corrected to explain their behavior with respect to bit vector
lengths and the handling of non-hexadecimal digits in the
OEPlatform::oeifstream::getline would sometimes cause
buffer overflows whenever max characters were actually in the
line. The documentation was not very clear what this max
parameter meant, it used to be the line size, not including the null
terminator. Now it means the size of available memory in the buffer
passed in, including the null terminator, and the documentation is
now more clear on the subject.
OEPlatform::oeifstream::append will now close the previous
file before openning the next file. Before, calling the append
method in a loop could lead to the process easily running out of a
available file descriptors.
The macros OE32BIT and OE64BIT were improperly set on 64-bit