* Fixes#1929
* add a tests to make sure bogus template directories work
* add a combined atomic number + aromaticity query operation to speed up SMARTS matches
Still needs to be recognized by the SMARTS writer, serialization, and no doubt a few other places.
* add a combined query for the single/aromatic bond query that shows up in SMARTS
* Stop using a dead pointer in the when parsing Marvin SMARTS in a CTAB
* At this point all tests pass on windows
* debugging info back in
* update the bison output
* boost::thread mostly gone... still need to get rid of once
everything compiles
* replace boost::call_once
* remove link-time dependency on boost::thread
* first pass at using async
* switch to using async everywhere
* Removes ATOM/BOND_SPTR in boost::graph in favor of raw pointers
* Actually delete atoms and bonds...
* RWMol::clear now calls destroy to handle atom/bond deletion
* Changes broken Atom lookup for windows/gcc
* Adds tests for running with valgrind
* Adds test designed for valgrind and molecule deletions
* Removes RNG, actually tests bond deletions
* update swig wrappers
* deal with most recent changes on the main branch
* add queries for the number of heteroatom neighbors
* support cactvs "z" extension
this includes support for range queries on z that could
be extended to other query types as well
* extend range query extension to other SMARTS primitives
* add the less-than and greater-than versions of the range queries
* updates and new tests
* update .cmake files
* support [#6] in SMILES
* document SMILES extensions (such as they are)
* Add support for cactvs's Z queries
* add support for ^4 and ^5
* get tests running
doc update
* book updates
* update .cmake files
* handle the heavy-atom degree queries differently
* Fixes#1563
* add a test for the heavy atom degree option
* Support (and test) adjustHeavyDegree in the cartridge too.
* test results
* add a SmilesParserParams object to prepare for this
* add a SmilesParserParams object to prepare for this
* add tests for the SmilesParseParmas
* support name parsing, should it be the default?
* rename CXNSmiles to CXSmiles;
add a spirit parser for CXSmiles coordinate that is at least syntax correct
* abandon boost::spirit for now; crude atom token parser
* support params in smiles parser (not tested, may not build)
* can read coords and atom labels along with mol names; crude, but works
* read coordinate bonds
* remove some compiler warnings with VS2015
* remove a bunch of compiler warnings on windows
* remove more warnings on windows
* remove more warnings on windows
* backup commit: first pass at parsing query features
* radical spec parsing
* handle attachment points using atom mapping
* switch to a named property for atom labels
* fix handling of the "A" atom query
* add functions to construct A and Q queries (needs more work)
* fix a problem created while cleaning up warnings earlier
* add some additional convenience functions for making generic atoms.
Still need M and to recognize these while writing CXSMILES
* add M queries; update some tests
* fix a linux compile problem
* get the cxsmiles stuff working in python; basic testing
* support "M" in CXSMILES
* atoms: radical electrons and presence of a chiral tag
* bonds: presence of stereo
* add new atom queries to python wrapper
* add queries for missing atom chiral tags
* Remove a bunch of warnings
The biggest change here is to treat the boost includes as system libraries.
This causes g++ to ignore warnings from boost.
This change still needs to be tested with clang and on Windows
* suppress a bunch of warnings on clang
smarts queries run faster (like vector bindings). Though there is an addition to the smarts parser
exposed here, I do not recommend using it in client code.
instead of using the property map interface.
A nice side-effect is that the wart of having to use property maps to loop over bonds or atom neighbors
is now gone.
This potentially breaks lots of client C++ code.
http://sourceforge.net/tracker/index.php?func=detail&aid=1968930&group_id=160139&atid=814650
In order to fix the problem, the value of the query function for atomMass queries
is being multiplied by a constant factor (currently 1000) before converting
to an int. This allows distinguishing between things like [CH4] (where the
C has mass 12.011) and [12CH4] (where the C has mass 12.000).