Re: [Rdkit-devel] 2021.03.1 RDKit Release

[Greg Landrum]

Apologies, I forgot to remove the beta tag in a file in the release, so
I've deleted that tag and done a new one.
The new DOI is:
https://zenodo.org/record/4639764

Everything else remains the same.

sorry for the noise,
-greg
p.s. hopefully there are no other silly mistakes/oversights...

On Fri, Mar 26, 2021 at 4:13 PM Greg Landrum  wrote:

> Dear all,
>
> I'm pleased to announce that the 2021.03 version of the RDKit is released.
> We actually managed to get the .03 release done during March. Shocking! ;-)
> The release notes are below.[1]
>
> The release files are on the github release page:
> https://github.com/rdkit/rdkit/releases/tag/Release_2021_03_1
> The DOI for this release is:
> https://doi.org/10.5281/zenodo.4639022
>
> I do not plan to do conda builds for the Python wrappers in the rdkit
> channel for this release. The builds done as part of the conda-forge
> project are automated and cover more Python versions and operating systems
> than I could ever hope to do manually.
> Please install the rdkit using conda-forge:
> conda install -c conda-forge rdkit
> I believe that the conda-forge builds of the new version should appear
> over the next couple of days.
>
> I hope to finish the conda builds of the PostgreSQL cartridge for linux
> and the mac and have them available in the rdkit channel by later today
> or tomorrow.
>
> The online version of the documentation at rdkit.org (
> http://rdkit.org/docs/index.html) has been updated.
>
> Thanks to everyone who submitted code, bug reports, and suggestions for
> this release!
>
> Please let me know if you find any problems with the release or have
> suggestions for the next one, which is scheduled for September/October 2021.
>
> Best Regards,
> -greg
> [1] We probably should figure out some way to make the release notes a bit
> less verbose. ;-)
>
>
> # Release_2021.03.1
> (Changes relative to Release_2020.09.1)
>
> ## Backwards incompatible changes
> - The distance-geometry based conformer generation now by defaults
> generates
>   trans(oid) conformations for amides, esters, and related structures.
> This can
>   be toggled off with the `forceTransAmides` flag in EmbedParameters. Note
> that
>   this change does not impact conformers created using one of the ET
> versions.
>   (#3794)
> - The conformer generator now uses symmetry by default when doing RMS
> pruning.
>   This can be disabled using the `useSymmetryForPruning` flag in
>   EmbedParameters. (#3813)
> - Double bonds with unspecified stereochemistry in the products of chemical
>   reactions now have their stereo set to STEREONONE instead of STEREOANY
> (#3078)
> - The MolToSVG() function has been moved from rdkit.Chem to rdkit.Chem.Draw
>   (#3696)
> - There have been numerous changes to the RGroup Decomposition code which
> change
>   the results. (#3767)
> - In RGroup Decomposition, when onlyMatchAtRGroups is set to false, each
> molecule
>   is now decomposed based on the first matching scaffold which adds/uses
> the
>   least number of non-user-provided R labels, rather than simply the first
>   matching scaffold.
>   Among other things, this allows the code to provide the same results for
> both
>   onlyMatchAtRGroups=true and onlyMatchAtRGroups=false when suitable
> scaffolds
>   are provided without requiring the user to get overly concerned about the
>   input ordering of the scaffolds. (#3969)
> - There have been numerous changes to
> `GenerateDepictionMatching2DStructure()` (#3811)
> - Setting the kekuleSmiles argument (doKekule in C++) to MolToSmiles will
> now
>   cause the molecule to be kekulized before SMILES generation. Note that
> this
>   can lead to an exception being thrown. Previously this argument would
> only
>   write kekulized SMILES if the molecule had already been kekulized (#2788)
> - Using the kekulize argument in the MHFP code will now cause the molecule
> to be
>   kekulized before the fingerprint is generated. Note that becaues
> kekulization
>   is not canonical, using this argument currently causes the results to
> depend
>   on the input atom numbering. Note that this can lead to an exception
> being
>   thrown. (#3942)
> - Gradients for angle and torsional restraints in both UFF and MMFF were
> computed
>   incorrectly, which could give rise to potential instability during
> minimization.
>   As part of fixing this problem, force constants have been switched to
> using
>   kcal/degree^2 units instead of kcal/rad^2 units, consistently with the
> fact that
>   angle and dihedral restraints are specified in degrees. (#3975)
>
> ## Highlights
> - MolDraw2D now does a much better job of handling query features like
> common
>   quer

[Rdkit-devel] 2021.03.1 RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the 2021.03 version of the RDKit is released.
We actually managed to get the .03 release done during March. Shocking! ;-)
The release notes are below.[1]

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2021_03_1
The DOI for this release is:
https://doi.org/10.5281/zenodo.4639022

I do not plan to do conda builds for the Python wrappers in the rdkit
channel for this release. The builds done as part of the conda-forge
project are automated and cover more Python versions and operating systems
than I could ever hope to do manually.
Please install the rdkit using conda-forge:
conda install -c conda-forge rdkit
I believe that the conda-forge builds of the new version should appear over
the next couple of days.

I hope to finish the conda builds of the PostgreSQL cartridge for linux and
the mac and have them available in the rdkit channel by later today
or tomorrow.

The online version of the documentation at rdkit.org (
http://rdkit.org/docs/index.html) has been updated.

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for September/October 2021.

Best Regards,
-greg
[1] We probably should figure out some way to make the release notes a bit
less verbose. ;-)


# Release_2021.03.1
(Changes relative to Release_2020.09.1)

## Backwards incompatible changes
- The distance-geometry based conformer generation now by defaults generates
  trans(oid) conformations for amides, esters, and related structures. This
can
  be toggled off with the `forceTransAmides` flag in EmbedParameters. Note
that
  this change does not impact conformers created using one of the ET
versions.
  (#3794)
- The conformer generator now uses symmetry by default when doing RMS
pruning.
  This can be disabled using the `useSymmetryForPruning` flag in
  EmbedParameters. (#3813)
- Double bonds with unspecified stereochemistry in the products of chemical
  reactions now have their stereo set to STEREONONE instead of STEREOANY
(#3078)
- The MolToSVG() function has been moved from rdkit.Chem to rdkit.Chem.Draw
  (#3696)
- There have been numerous changes to the RGroup Decomposition code which
change
  the results. (#3767)
- In RGroup Decomposition, when onlyMatchAtRGroups is set to false, each
molecule
  is now decomposed based on the first matching scaffold which adds/uses the
  least number of non-user-provided R labels, rather than simply the first
  matching scaffold.
  Among other things, this allows the code to provide the same results for
both
  onlyMatchAtRGroups=true and onlyMatchAtRGroups=false when suitable
scaffolds
  are provided without requiring the user to get overly concerned about the
  input ordering of the scaffolds. (#3969)
- There have been numerous changes to
`GenerateDepictionMatching2DStructure()` (#3811)
- Setting the kekuleSmiles argument (doKekule in C++) to MolToSmiles will
now
  cause the molecule to be kekulized before SMILES generation. Note that
this
  can lead to an exception being thrown. Previously this argument would only
  write kekulized SMILES if the molecule had already been kekulized (#2788)
- Using the kekulize argument in the MHFP code will now cause the molecule
to be
  kekulized before the fingerprint is generated. Note that becaues
kekulization
  is not canonical, using this argument currently causes the results to
depend
  on the input atom numbering. Note that this can lead to an exception being
  thrown. (#3942)
- Gradients for angle and torsional restraints in both UFF and MMFF were
computed
  incorrectly, which could give rise to potential instability during
minimization.
  As part of fixing this problem, force constants have been switched to
using
  kcal/degree^2 units instead of kcal/rad^2 units, consistently with the
fact that
  angle and dihedral restraints are specified in degrees. (#3975)

## Highlights
- MolDraw2D now does a much better job of handling query features like
common
  query bond types, atom lists, variable attachment points, and link nodes.
It
  also supports adding annotations at the molecule level, displaying
brackets
  for Sgroups, rendering the ABS flag for stereochemistry, and a new "comic"
  mode.
- There are two new Contrib packages: NIBRStructureFilters and CalcLigRMSD
- There have been a number of improvements made to the R-Group Decomposition
  code which make it both more flexible and considerably faster

## Acknowledgements
Michael Banck, Christopher Von Bargen, Jason Biggs, Patrick Buder, Ivan
Chernyshov, Andrew Dalke, Xiaorui Dong, Carmen Esposito, Nicholas Firth,
Enrico
Gandini, James Gayvert, Gareth Jones, Eisuke Kawashima, Steven Kearnes,
Brian
Kelley, Mark Mackey, Niels Kristian Kjærgård Madsen, Luca Naef, Dan
Nealschneider, Jin Pan, Daniel Paoliello, António JM Ribeiro, Sereina
Riniker,
Braxton Robbason, Jaime 

[Rdkit-devel] Beta of the 2021.03 release available

[Greg Landrum]

Dear all,

The beta of the 2020.09 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2021_03_1b1

I'm doing a conda build for Python 3.7 on Linux now. If you would like to
test the new version and need a conda build for that, please let me know
and I can try to do builds for other python versions or platforms. The
conda builds use the beta label so that they do not install by default;
you'll need to run "conda install" as follows:

conda install -c rdkit/label/beta rdkit

Be sure to confirm that it's installing the right version when you are
prompted (if there's no build available, it will pick the current
production release instead).

The relevant section of the release notes is below (I still need to finish
the Highlights section), or you can see a nicely formatted version here:
https://github.com/rdkit/rdkit/releases/tag/Release_2021_03_1b1

As usual, if you have time to try out the new release I would love
feedback. If nothing major comes up, I plan to do the actual release
towards the end of next week.

Best,
-greg

# Release_2021.03.1
(Changes relative to Release_2020.09.1)


## Backwards incompatible changes
- The distance-geometry based conformer generation now by defaults generates
  trans(oid) conformations for amides, esters, and related structures. This
can
  be toggled off with the `forceTransAmides` flag in EmbedParameters. Note
that
  this change does not impact conformers created using one of the ET
versions.
  (#3794)
- The conformer generator now uses symmetry by default when doing RMS
pruning.
  This can be disabled using the `useSymmetryForPruning` flag in
  EmbedParameters. (#3813)
- Double bonds with unspecified stereochemistry in the products of chemical
  reactions now have their stereo set to STEREONONE instead of STEREOANY
(#3078)
- The MolToSVG() function has been moved from rdkit.Chem to rdkit.Chem.Draw
  (#3696)
- There have been numerous changes to the RGroup Decomposition code which
change
  the results. (#3767)
- There have been numerous changes to
`GenerateDepictionMatching2DStructure()` (#3811)
- Setting the kekuleSmiles argument (doKekule in C++) to MolToSmiles will
now
  cause the molecule to be kekulized before SMILES generation. Note that
this
  can lead to an exception being thrown. Previously this argument would only
  write kekulized SMILES if the molecule had already been kekulized (#2788)
- Using the kekulize argument in the MHFP code will now cause the molecule
to be
  kekulized before the fingerprint is generated. Note that becaues
kekulization
  is not canonical, using this argument currently causes the results to
depend
  on the input atom numbering. Note that this can lead to an exception being
  thrown. (#3942)

## Highlights

## Acknowledgements
Michael Banck, Christopher Von Bargen, Jason Biggs, Patrick Buder, Ivan
Chernyshov, Andrew Dalke, Xiaorui Dong, Carmen Esposito, Nicholas Firth,
Enrico
Gandini, James Gayvert, Gareth Jones, Eisuke Kawashima, Steven Kearnes,
Brian
Kelley, Mark Mackey, Niels Kristian Kjærgård Madsen, Luca Naef, Dan
Nealschneider, Jin Pan, Daniel Paoliello, António JM Ribeiro, Sereina
Riniker,
Braxton Robbason, Jaime Rodríguez-Guerra, Ricardo Rodriguez-Schmidt, Steve
Roughley, Vincent F. Scalfani, Nadine Schneider, Philippe Schwaller, Dan
Skatov,
Pascal Soveaux, Paolo Tosco, Kazuya Ujihara, Riccardo Vianello, Shuzhe Wang,
Piotr Wawrzyniak, Maciej Wójcikowski, Yutong Zhao
'driesvr', 'GintasKam', 'SPKorhonen', 'pkubaj', 'AnPallo', 'darintay',
'slchan3', 'Robins', 'sirbiscuit', 'amateurcat', 'noncomputable',
'yurivict',
'magattaca'

## Contrib updates:
  - Added NIBRStructureFilters: a set of substructure filters for hit-list
triaging together with python code for applying them. The filters are
described in the publication https://dx.doi.org/10.1021/acs.jmedchem.0c01332
   (github pull #3516 from NadineSchneider)
  - Added CalcLigRMSD: flexible python code for calculating RMSD between
pre-aligned molecules
   (github pull #3812 from cespos)

## Bug Fixes:
  - Casting int to uint in MorganFingerprintHelper leads to unexpected
behaviour.
 (github issue #1761 from SiPa13)
  - MolChemicalFeature.GetPos() returns value for molecule's default
conformer
 (github issue #2530 from greglandrum)
  - Unable to catch RDKit exceptions in linked library when compiling with
fvisibility=hidden
 (github issue #2753 from cdvonbargen)
  - Reaction rendering always shows molecules in aromatic form
 (github issue #2976 from greglandrum)
  - Reactions setting unspecified double-bond stereo to STEREOANY
 (github issue #3078 from ricrogz)
  - PDB output flavor&2 documentation change
 (github issue #3089 from adalke)
  - WedgeMolBonds() should prefer degree-1 atoms
 (github issue #3216 from greglandrum)
  - Error in ChemAxon SMILES "parsing"
 (github issue #3320 from IvanChernyshov)
  - Incorrect number of radical electrons calculated for metals
 (github issue #3330 from greglandrum)
  - Problem with lifetime linkage of 

[Rdkit-devel] 2020.09.1 RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the 2020.09 version of the RDKit is released.
The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_09_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 3.6, 3.7
Mac OS 64bit: python 3.6, 3.7
Windows 64bit: python 3.6, 3.7

I hope to finish the conda builds of the PostgreSQL cartridge and do the PR
to update conda-forge this weekend.

The online version of the documentation at rdkit.org (
http://rdkit.org/docs/index.html) has been updated.

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version
- The homebrew script

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for March/April 2021.

Best Regards,
-greg

# Release_2020.09.1
(Changes relative to Release_2020.03.1)


## Backwards incompatible changes
- We've added additional allowed valences for Cl (now 1, 3, 5), Br (now 1,
3,
  5), I (now 1, 3, 5), At (now 1, 3, 5), Xe (now 0, 2, 4, 6), and Po (now
2, 4,
  6). Molecules with atoms in the new valence states will no longer generate
  sanitization errors. Note that this has an impact on the chemistry of
  molecules containing 3-valent I and at least one implict H (present 24
times
  in ChEMBL 27): previously this was incorrectly assigned two implicit Hs,
now
  it has no implicit Hs.
- Aromaticity perception of molecules like `Cc1nnc2n1c1c1n1c(C)nnc12`
now
  correctly recognizes the full outer envelope, i.e. the bonds joining the
rings
  are now also aromatic.
- FindMCS() may return single atom MCSs, whereas previously it returned an
empty
  MCS unless there was at least one commond bond across the input
structures.
  So the MCS between molecules `CC` and `CO` is now `[#6]` rather than
being null.
- The fontSize()/setFontSize() (FontSize()/SetFontSize()) methods in
MolDraw2D
  now work in units of pixels (more or less) instead of the molecule units.
- The Open3DAlign functionality is now in its own separate library -
`O3AAlign`
  in cmake. If you are working in C++ and using O3A functionality, you'll
need
  to link against this library as well now.
- Due to improvements in the tautomer enumeration code, the method
  `TautomerEnumerator::enumerate` now returns a `TautomerEnumeratorResult`
  object instead of a vector of molecules. Note that if you are iterating
over
  the results of a call to `enumerate()` you shouldn't need to change your
code.
  If you want to invoke the old (and deprecated, see below) form from C++,
call
  `TautomerNumerator::enumerate(mol, nullptr)` or explicitly pass a
  `boost::dynamic_bitset*` to capture the modified atoms.
- The default precision setting for coordgen has been changed. The new
default
  was selected to greatly reduce the number of molecules for which it takes
a
  very long time to generate coordinates while still producing nice looking
  structures. We may continue to tweak this default value if/when problems
  with it are reported. If you would like to go back to the previous
setting, set
  CoordgenParams.minimizerPrecision to
CoordgenParams.sketcherStandardPrecision
  when you invoke rdCoordGen.AddCoords()
- Uncharger::uncharge() will now neutralize `[Cl,Br,I][O-],
[Cl,Br,I](=O)[O-],
  [Cl,Br,I](=O)(=O)[O-], [Cl,Br,I](=O)(=O)(=O)[O-], [O-]N=N[O-],
[N,P](=O)[O-],
  [N+](=O)([O-])[O-], P(=O)([O-])[O-], P(=O)([O-])([O-])[O-], S([O-])[O-],
  S(=O)([O-])[O-], S(=O)(=O)([O-])[O-], S(=O)(=O)([O-])OOS(=O)(=O)[O-]`.
  Previously not all of these inorganic acid counterions were consistently
  neutralized.
- The `None` value in the `RGroupCoreAlignment` enum was renamed to
`NoAlignment`
  in both C++ and Python, in order to avoid issues when attempting to
access it
  from Python.

## Highlights
- There's been another big improvement in the quality of molecule drawings:
  character and font handling is greatly improved thanks to the use of the
  FreeType library
- A new feature has been added to efficiently allow tautomer-insensitive
  substructure search.
- A new, much more accurate, algorithm is available for calculating CIP
labels
  on atoms and bonds.
- There's a new rdDeprotect module to allow automatically deprotecting
molecules
  before putting them into reactions
- Molecule and reaction metadata can now be added to PNG files generated by
  MolDraw2DCairo

## Acknowledgements
Shrey Aryan, Jinserk Baik, Francois Berenger, Cédric Bouysset, David
Cosgrove,
Ivan Chernyshov, Guillaume Godin, Manan Goel, Jan H. Jensen, Gareth Jones,
Maria
Kadukova, Eisuke Kawashima, Steven Kearnes, Brian Kelley, Joos Kiener,
Kenneth
Lum, Joshua Meyers, Rocco Moretti, Paul R Moses, Dan Nealschneider, Jin Pan,
Joann Prescott-Roy, Matthew 

[Rdkit-devel] Beta of the 2020.09 release available

[Greg Landrum]

Dear all,

The beta of the 2020.09 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_09_1b1

There are a couple more bug fixes and maybe one more feature expected
before the actual release, but I wanted to go ahead and get the beta out
there.

I've done conda builds for Python 3.7 on Mac, and Linux and will hopefully
have one done for Windows later this morning. These all use the beta label
so that they do not install by default; you'll need to run "conda install"
as follows:

conda install -c rdkit/label/beta rdkit

Be sure to confirm that it's installing the right version when you are
prompted (if there's no build available, it will pick the current
production release instead).

The relevant section of the release notes is below (I still need to finish
the Highlights section), or you can see a nicely formatted version here:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_09_1b1

As usual, if you have time to try out the new release I would love
feedback. If nothing major comes up, I plan to do the actual release either
later this week or early next week.

Best,
-greg

# Release_2020.09.1
(Changes relative to Release_2020.03.1)


## Backwards incompatible changes
- FindMCS() may return single atom MCSs, whereas previously it returned an
empty
  MCS unless there was at least one commond bond across the input
structures.
  So the MCS between molecules `CC` and `CO` is now `[#6]` rather than
being null.
- The fontSize()/setFontSize() (FontSize()/SetFontSize()) methods in
MolDraw2D
  now work in units of pixels (more or less) instead of the molecule units.
- The Open3DAlign functionality is now in its own separate library -
`O3AAlign`
  in cmake. If you are working in C++ and using O3A functionality, you'll
need
  to link against this library as well now.
- Due to improvements in the tautomer enumeration code, the method
  `TautomerEnumerator::enumerate` now returns a `TautomerEnumeratorResult`
  object instead of a vector of molecules. Note that if you are iterating
over
  the results of a call to `enumerate()` you shouldn't need to change your
code.
  If you want to invoke the old (and deprecated, see below) form from C++,
call
  `TautomerNumerator::enumerate(mol, nullptr)` or explicitly pass a
  `boost::dynamic_bitset*` to capture the modified atoms.
- The default precision setting for coordgen has been changed. The new
default
  was selected to greatly reduce the number of molecules for which it takes
a
  very long time to generate coordinates while still producing nice looking
  structures. We may continue to tweak this default value if/when problems
  with it are reported. If you would like to go back to the previous
setting, set
  CoordgenParams.minimizerPrecision to
CoordgenParams.sketcherStandardPrecision
  when you invoke rdCoordGen.AddCoords()
- Uncharger::uncharge() will now neutralize `[Cl,Br,I][O-],
[Cl,Br,I](=O)[O-],
  [Cl,Br,I](=O)(=O)[O-], [Cl,Br,I](=O)(=O)(=O)[O-], [O-]N=N[O-],
[N,P](=O)[O-],
  [N+](=O)([O-])[O-], P(=O)([O-])[O-], P(=O)([O-])([O-])[O-], S([O-])[O-],
  S(=O)([O-])[O-], S(=O)(=O)([O-])[O-], S(=O)(=O)([O-])OOS(=O)(=O)[O-]`.
  Previously not all of these inorganic acid counterions were consistently
  neutralized.
- We've added additional allowed valences for Cl (now 1, 3, 5), Br (now 1,
3,
  5), I (now 1, 3, 5), At (now 1, 3, 5), Xe (now 0, 2, 4, 6), and Po (now
2, 4,
  6). Molecules with atoms in the new valence states will no longer generate
  sanitization errors

## Highlights
- There's been another big improvement in the quality of molecule drawings:
character
  and font handling is greatly improved thanks to the use of the FreeType
library
- A new feature has been added to efficiently allow tautomer-insensitive
  substructure search.
- A new, much more accurate, algorithm is available for calculating CIP
labels on
  atoms and bonds.
- There's a new rdDeprotect module to allow automatically deprotecting
molecules
  before putting them into reactions

## Acknowledgements
Shrey Aryan, Jinserk Baik, Francois Berenger, Cédric Bouysset, David
Cosgrove,
Ivan Chernyshov, Guillaume Godin, Manan Goel, Jan H. Jensen, Gareth Jones,
Maria
Kadukova, Eisuke Kawashima, Steven Kearnes, Brian Kelley, Joos Kiener,
Kenneth
Lum, Joshua Meyers, Paul R Moses, Dan Nealschneider, Jin Pan, Joann
Prescott-Roy, Matthew Robinson, Jaime Rodríguez-Guerra, Ricardo
Rodriguez-Schmidt, Jeff van Santen, Roger Sayle Vincent F. Scalfani Eric
Taw,
Ansgar Schuffenhauer, Paolo Tosco, Ivan Tubert-Brohman, Riccardo Vianello,
Rachel Walker, Maciej Wójcikowski, Christopher Zou, daverona, hjuinj,
intrigus-lgtm, autodataming, paconius

## Bug Fixes:
  - Python tests fail when RDK_BUILD_COMPRESSED_SUPPLIERS is enabled
 (github issue #1888 from greglandrum)
  - ResonanceMolSupplier potentially stuck in infinite loop
 (github issue #2597 from tawe141)
  - ctest pythonTestDirChem failed
 (github issue #2757 from jinserk)
  - Issue with inversion/retention of 

Re: [Rdkit-devel] SDF String Generation Include Stereo information

[Greg Landrum]

Hi Emanuel,

The chirality bit doesn't have anything to do with double bond
stereochemistry.[1] So that's not what's going on here

The RDKit has the ability to pass the mol block provided directly to the
InChI code without interpreting it. I believe that the ChEMBL team is using
that to generate InChIs. In any case, where I use that to pass the molblock
downloaded from ChEMBL (
https://www.ebi.ac.uk/chembl/api/data/molecule/CHEMBL6223.sdf) to the InChI
code I get the same InChI that is found in ChEMBL.

In this particular case I believe the bug may be in the NAOMI code.

-greg
[1] According to the documentation it tells you about whether or not a
molfile with specified atomic stereochemistry represents a single
stereoisomer  (the one drawn) or that only the relative configurations of
the specified stereocenters is known and that the structure is either a
single diastereomer or a mixture of the two stereoisomers.

On Wed, Jul 29, 2020 at 11:17 AM Emanuel Ehmki 
wrote:

> Dear All,
>
> I am currently working with the RDKit generated SDF String that is stored
> in the ChEMBL COMPOUND_STRUCTURES table in the ChEMBL database release 26.
> My workflow is:
>
>- pull SDF (V2000) from SQL table
>- generate internal molecule representation (NAOMI ChemBio tool-kit if
>that means anything to you)
>- generate InChI string and key from molecule
>- compare with InChI string and key that are stored in the ChEMBL
>database
>
> When comparing the InChI string for the molecule with the id CHEMBL6223, I
> get two differing strings due to different stereochemistry (last characters)
>
> ChEMBL
> InChI: 
> InChI=1S/C16H13IO2/c17-10-12-8-9-15(16(18)19-12)14-7-3-5-11-4-1-2-6-13(11)14/h1-7,10,15H,8-9H2/
>*b12-10+*
> NAOMI InChI
> : 
> InChI=1S/C16H13IO2/c17-10-12-8-9-15(16(18)19-12)14-7-3-5-11-4-1-2-6-13(11)14/h1-7,10,15H,8-9H2/
> *b12-10-*
>
> While researching why that happens I realized that the SDF string doesn't
> make use of the chirality bit that can be set in the counts line.
> When digging deeper I found the disabled block in the MolFileWriter.cpp ->
> MolToMolBlock function
>
> https://github.com/rdkit/rdkit/blob/f14f8a60de0ecf4bf5294d73b177d19055e0096d/Code/GraphMol/FileParsers/MolFileWriter.cpp#L1395
>
> Do I understand correctly that RDKit does not store any information about
> chirality in V2000 and includes chiral information only in V3000 SDF format?
>
> Does anyone know when ChEMBL might switch to that version?
>
> Kind regards,
> Emanuel
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] PostgreSQL PGXS-style Makefile, and RDGeneral/export.h: No such file or directory

[Greg Landrum]

[Deleted the previous contents of the thread because it was causing
formatting problems for me in gmail, sorry]

One thing you might consider trying here is to build and install the RDKit
(without the cartridge or Python wrappers)
like a normal library using the standard RDKit build process.
This should install all the header files (include export.h) and libraries
you need. You can then put the cartridge source wherever is most convenient
for you and then make sure your Makefile for the cartridge has the relevant
-I and -L directives to point to where that install is.

I *think* this would end up making things a lot easier in the end.
-greg
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] PostgreSQL PGXS-style Makefile, and RDGeneral/export.h: No such file or directory

[Greg Landrum]

On Tue, Mar 31, 2020 at 12:24 AM Finnerty, Jim via Rdkit-devel <
rdkit-devel@lists.sourceforge.net> wrote:

> Thank you, Paolo.  I found a generated export.h in Oxygen, used that, and
> got past that issue.
>
>
>
> The CMake script enforces a minimum Boost version of Boost-1.56.0, whereas
> we’re on Boost-1.55.0.  Since I’m using a PGXS-style make now, I tried
> building on Boost-1.55.0, and make doesn’t fail.  What is it that depends
> on Boost-1.56.0 that would probably fail if we’re running on Boost-1.55.0?
>
>
That's an interesting question. I'm really not sure what the answer is at
this point. It may be that whatever new features are being used or
whichever boost bug fixes happened are in parts of the code that you won't
end up using. So I think the best thing to probably do is just try things
out and see what happens.
If the build works and the tests pass, you're probably ok.
As an aside: boost 1.55 is pretty ancient (Nov 2013). I realize that this
likely isn't in your control, but it might be worth seeing if you can
update that.
(I notice below that it looks like you're actually using RHEL5, which is
even more ancient and out of support, so I'm going to guess you can't
change anything there)



>
>
> The CMake process also replaces some strings in the rdkit--3.8.sql file.
> One looks odd, though.  In OPERATOR CLASS gin_bfp_ops, the replacement
> skips over “5”.  Is this expected?
>
>
>
> FUNCTION4   gin_bfp_consistent(internal, int2, bfp, int4,
> internal, internal, internal, internal),
>
>
> FUNCTION6   gin_bfp_triconsistent(internal, int2, bfp, int4,
> internal, internal, internal), -- jlf@RDKIT_GIN_BFP_TRICONSISTENT@
>
>
>

Yes, we don't define support function 5 for that operator. I don't have an
explanation for why not.


> Running with Boost-1.55.0 and using the definition above, without running
> CMake (and with a PGXS-style Makefile), rdkit.so does in fact build;
> however, when the extension is loaded it fails because symbol rdErrorLog is
> not defined.  How should I define it with my PGXS-style build process?
>
>
>
> postgres=# create extension rdkit;
>
> ERROR:  could not load library
> "/local/home/jfinnert/workspace/AuroraML/build/RDSManfredDev/RDSManfredDev-Development/RHEL5_64/DEV.STD.PTHREAD/build/RDSManfred/lib/postgresql/rdkit.so":
> /local/home/jfinnert/workspace/AuroraML/build/RDSManfredDev/RDSManfredDev-Development/RHEL5_64/DEV.STD.PTHREAD/build/RDSManfred/lib/postgresql/rdkit.so:
> undefined symbol: rdErrorLog
>
>
>

The symbol rdErrorLog should be defined in the library RDGeneral. Are you
linking against that?

-greg

>
>
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2020.03.1 RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit - 2020.03 - is
released. This time we even managed to get it out during the correct month!
:-) The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_03_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 3.6, 3.7
Mac OS 64bit: python 3.6, 3.7
Windows 64bit: python 3.6, 3.7

Conda builds of the PostgreSQL cartridge are also available:
Linux 64bit: postgresql 9.6, 10, 11
Mac OS 64bit: postgresql 9.6, 10, 11

The PR is in to switch conda-forge to the new version as well. There are
currently some non-RDKit-related build problems with conda-forge, but
hopefully that will be updated soon as well.

The online version of the documentation at rdkit.org (
http://rdkit.org/docs/index.html) has been updated.

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version
- The homebrew script

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for September/October 2020.

Best Regards,
-greg

# Release_2020.03.1
(Changes relative to Release_2019.09.1)

## Backwards incompatible changes
- Searches for equal molecules (i.e. `mol1 @= mol2`) in the PostgreSQL
cartridge
  now use the `do_chiral_sss` option. So if `do_chiral_sss` is false (the
  default), the molecules `CC(F)Cl` and `C[C@H](F)Cl` will be considered to
be equal.
  Previously these molecules were always considered to be different.
- Attempting to create a MolSupplier from a filename pointing to an empty
file,
  a file that does not exist or sometihing that is not a standard file (i.e.
  something like a directory) now generates an exception.
- The cmake option `RDK_OPTIMIZE_NATIVE` has been renamed to
`RDK_OPTIMIZE_POPCNT`

# Highlights:
- The drawings generated by the MolDraw2D objects are now significantly
improved
  and can include simple atom and bond annotations (#2931 and #3010)
- An initial implementation of a modified scaffold network algorithm is now
  available (#2911)
- A few new descriptor/fingerprint types are available - BCUTs (#2957),
Morse
  atom fingerprints (#1773), Coulomb matrices (#2993), and MHFP and SECFP
  fingerprints (#2643)
- There is a new, and greatly improved, version of the RDKit Cookbook
(#2884)
- There is a new version (v3) of the ETKDG conformer generator along with
  optional new terms for handling small rings and macrocyles (
http://doi.org/dqnh) (#2999)


## Acknowledgements:
Marcel Baltruschat, Jason Biggs, Eliane Briand, Ben Cornett, David Cosgrove,
Andrew Dalke, Tim Dudgeon, Zhenting Gao, Guillaume Godin, Manan Goel, Gareth
Jones, Zachary Kaplan, Eisuke Kawashima, Steven Kearnes, Brian Kelley, Maxim
Koltsov, Franziska Kruger, Mieszko Manijak, Dan Nealschneider, Daniil
Polykovskiy, Daniel Probst, Sereina Riniker, Matthew Robinson, Steve
Roughley,
Kevin Ryan, Vincent F. Scalfani, Ricardo Rodriguez Schmidt, Rim
Shayakhmetov,
Aryan Shrey, Nik Stiefl, Matt Swain, Paolo Tosco, Wiep van der Toorn,
Riccardo
Vianello, Shuzhe Wang, Piotr Wawrzyniak, Hsiao Yi, 'jasad1',
'luancarvalhomartins'


## Bug Fixes:
  - Mol rendering within DataFrames in a Jupyter Notebook is broken with
Pandas 0.25.1
 (github issue #2673 from mrcblt)
  - Removed RDKIT_SIMDIVPICKERS_EXPORT
 (github pull #2740 from ptosco)
  - - enable building RDKitRingDecomposerLib.dll under Windows
 (github pull #2742 from ptosco)
  - Do a windows DLL build as part of the Azure DevOps setup
 (github pull #2743 from greglandrum)
  - Fix data race in sascorer.py
 (github pull #2744 from skearnes)
  - Uncharger not properly setting explicit/implicit H count
 (github issue #2749 from greglandrum)
  - MSVC compile error: MolHash scoped enum cannot be redeclared as unscoped
 (github issue #2752 from mcs07)
  - Molecules whose Y size is very small won't display as SVG
 (github issue #2762 from ptosco)
  - Make the cartridge tests work with PostgreSQL 12
 (github pull #2767 from greglandrum)
  - Salt stripper should consider bond matches as well as atom matches
 (github pull #2768 from greglandrum)
  - Bismuth should count as an early element
 (github issue #2775 from greglandrum)
  - addHs() fails on atoms with "bad" valences
 (github issue #2782 from greglandrum)
  - Element symbol lookup for some transuranics returns incorrect results
 (github issue #2784 from LeanAndMean)
  - [cartridge] molecular equality should use do_chiral_sss setting
 (github issue #2790 from greglandrum)
  - uncharger removes Hs from carbocations instead of adding them
 (github issue #2792 from greglandrum)
  - Fix build without boost serialization library
 (github pull #2796 from maksbotan)
  - Using `SetBoundsMat` significantly slows 

[Rdkit-devel] (no subject)

[Greg Landrum]

Dear all,

The beta of the 2020.03 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_03_1b1

I've done conda builds for Python 3.6 and 3.7 for Mac, and Linux and I'm
working on the Windows builds now. These all use the beta label so that
they do not install by default; you'll need to run "conda install" as
follows:

conda install -c rdkit/label/beta rdkit

Be sure to confirm that it's installing the right version when you are
prompted (if there's no build available, it will pick the current
production release instead).

The relevant section of the release notes (which still may need a highlight
or two added) is below, or you can see a nicely formatted version here:
https://github.com/rdkit/rdkit/releases/tag/Release_2020_03_1b1

As usual, if you have time to try out the new release I would love
feedback. If nothing major comes up, I plan to do the actual release next
Monday.

Best,
-greg

# Release_2020.03.1
(Changes relative to Release_2019.09.1)

## Backwards incompatible changes
- Searches for equal molecules (i.e. `mol1 @= mol2`) in the PostgreSQL
cartridge
  now use the `do_chiral_sss` option. So if `do_chiral_sss` is false (the
  default), the molecules `CC(F)Cl` and `C[C@H](F)Cl` will be considered to
be equal.
  Previously these molecules were always considered to be different.
- Attempting to create a MolSupplier from a filename pointing to an empty
file,
  a file that does not exist or sometihing that is not a standard file (i.e.
  something like a directory) now generates an exception.
- The cmake option `RDK_OPTIMIZE_NATIVE` has been renamed to
`RDK_OPTIMIZE_POPCNT`

# Highlights:
- The drawings generated by the MolDraw2D objects are now significantly
improved
  and can include simple atom and bond annotations (#2931 and #3010)
- An initial implementation of a modified scaffold network algorithm is now
  available (#2911)
- A few new descriptor/fingerprint types are available - BCUTs (#2957),
Morse
  atom fingerprints (#1773), Coulomb matrices (#2993), and MHFP and SECFP
  fingerprints (#2643)


## Acknowledgements:
Marcel Baltruschat, Jason Biggs, Eliane Briand, Ben Cornett, David Cosgrove,
Zhenting Gao, Guillaume Godin, Gareth Jones, Zachary Kaplan, Eisuke
Kawashima,
Steven Kearnes, Brian Kelley, Maxim Koltsov, Mieszko Manijak, Dan
Nealschneider,
Daniil Polykovskiy, Daniel Probst, Steve Roughley, Kevin Ryan, Vincent F.
Scalfani, Ricardo Rodriguez Schmidt, Rim Shayakhmetov, Aryan Shrey, Matt
Swain,
Paolo Tosco, Wiep van der Toorn, Riccardo Vianello, Shuzhe Wang, Piotr
Wawrzyniak, Hsiao Yi, 'luancarvalhomartins'


## Bug Fixes:
  - Mol rendering within DataFrames in a Jupyter Notebook is broken with
Pandas 0.25.1
 (github issue #2673 from mrcblt)
  - Removed RDKIT_SIMDIVPICKERS_EXPORT
 (github pull #2740 from ptosco)
  - - enable building RDKitRingDecomposerLib.dll under Windows
 (github pull #2742 from ptosco)
  - Do a windows DLL build as part of the Azure DevOps setup
 (github pull #2743 from greglandrum)
  - Fix data race in sascorer.py
 (github pull #2744 from skearnes)
  - Uncharger not properly setting explicit/implicit H count
 (github issue #2749 from greglandrum)
  - MSVC compile error: MolHash scoped enum cannot be redeclared as unscoped
 (github issue #2752 from mcs07)
  - Molecules whose Y size is very small won't display as SVG
 (github issue #2762 from ptosco)
  - Make the cartridge tests work with PostgreSQL 12
 (github pull #2767 from greglandrum)
  - Salt stripper should consider bond matches as well as atom matches
 (github pull #2768 from greglandrum)
  - Bismuth should count as an early element
 (github issue #2775 from greglandrum)
  - addHs() fails on atoms with "bad" valences
 (github issue #2782 from greglandrum)
  - Element symbol lookup for some transuranics returns incorrect results
 (github issue #2784 from LeanAndMean)
  - [cartridge] molecular equality should use do_chiral_sss setting
 (github issue #2790 from greglandrum)
  - uncharger removes Hs from carbocations instead of adding them
 (github issue #2792 from greglandrum)
  - Fix build without boost serialization library
 (github pull #2796 from maksbotan)
  - Using `SetBoundsMat` significantly slows down conformer generation
process.
 (github issue #2800 from hjuinj)
  - rdkit.Ched.rdFMCS.FindMCS generates invalid smarts
 (github issue #2801 from luancarvalhomartins)
  - Remove confId from *FFOptimizeMoleculeConfs Python docs
 (github issue #2805 from ptosco)
  - Hybridization queries on dummy atoms not written properly to SMARTS
 (github issue #2814 from greglandrum)
  - Charge range queries not properly written to SMARTS
 (github issue #2815 from greglandrum)
  - RDKit segfaults in MMFFOptimizeMoleculeConfs()
 (github issue #2820 from ptosco)
  - Trusted Smiles holder doesn't handle ring queries
 (github issue #2830 from bp-kelley)
  - Fix windows substructure crash
 (github pull #2836 from greglandrum)
  - Fix YAeHMOP build
 (github pull #2838 from ptosco)
  

Re: [Rdkit-devel] Fwd: [Boost-users] [Graph] Large incoming changes to Boost.Graph master.

[Greg Landrum]

Thanks for forwarding that Emanuel.

I just tried the dev version out (as John describes) with the RDKit and
everything looks good: the code builds and the tests all pass

-greg


On Thu, Jan 9, 2020 at 7:47 AM Emanuel Ehmki 
wrote:

> Dear all,
>
> is that something to consider?
>
> Kind regards,
> Emanuel
>
> -- Forwarded message -
> From: John Maddock via Boost-users 
> Date: Wed, Jan 8, 2020, 18:57
> Subject: [Boost-users] [Graph] Large incoming changes to Boost.Graph
> master.
> To: , 
> Cc: John Maddock 
>
>
> Dear all,
>
> Boost.Graph has had no maintainer for some time, but the CMT has been
> busy fixing bugs none the less.  Unfortunately, other than some trivial
> fixes to docs and some directory refactoring, nothing much has been
> merged to master in a good while .
>
> On the plus side, develop is now in a better tested tested state than
> IMO it has ever been, however the change set is rather large so the
> potential to mess up somebodies code is certainly there:
> https://github.com/boostorg/graph/pull/196.
>
> So... this is both a heads up, and a plea: if you have any mission
> critical code using the Graph library, could you please test against
> current develop and report any problems?  If you don't want to mess
> about with git, download from
> https://github.com/boostorg/graph/archive/develop.zip and place
> zipfile-contents/libs/graph/include in your include path ahead of that
> for Boost-1.72.
>
> Many thanks, John.
>
> ___
> Boost-users mailing list
> boost-us...@lists.boost.org
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] molecular representation underlying the postgresql cartridge for rdkit

[Greg Landrum]

Hi Peter,

On Mon, Dec 2, 2019 at 10:11 AM Peter Schmidtke <
peter.schmid...@discngine.com> wrote:

>
> I have a question regarding the underlying molecular representation used
> in the rdkit cartridge for postgresql.
> I didn't dig yet too much into the underlying source code of the
> cartridge. Is it a normal rdkit like molecule used to store molecules?
>

Yes, the internal representation is currently the usual RDKit serialized
molecule.


> What I want to make sure especially that it's not stored as smiles string!
>

Not currently. Why are you concerned about this?


-greg
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2019.09.1 RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit - 2019.09 - is
released. The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2019_09_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 3.6, 3.7
Mac OS 64bit: python 3.6, 3.7
Windows 64bit: python 3.6, 3.7

Conda builds of the PostgreSQL cartridge are also available:
Linux 64bit: postgresql 9.6, 10, 11
Mac OS 64bit: postgresql 9.6, 10, 11

I believe that conda-forge will also switch to the new version in the near
future.

The online version of the documentation at rdkit.org (
http://rdkit.org/docs/index.html) has been updated.

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version
- The homebrew script

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for March/April 2020.

Best Regards,
-greg

# Release_2019.09.1
(Changes relative to Release_2019.03.1)

## Important
- The atomic van der Waals radii used by the RDKit were corrected/updated
in #2154.
  This leads to different results when generating conformations, molecular
volumes,
  and molecular shapes.

## Backwards incompatible changes
- See the note about atomic van der Waals radii above.
- As part of the enhancements to the MolDraw2D class, we changed the type of
  DrawColour from a tuple to be an actual struct. We also added a 4th
element to
  capture alpha values. This should have no affect on Python code (the alpha
  value is optional when providing color tuples), but will require changes
to C++
  and Java/C# code that is using DrawColour.
- When reading Mol blocks, atoms with the symbol "R" are now converted into
  queries that match any atom when doing a substructure search (analogous
to "*"
  in SMARTS). The previous behavior was to only match other dummy atoms
- When loading SDF files using PandasTools.LoadSDF(), we now default to
  producing isomeric smiles in pandas tables.  To reproduce the original
  behavior, use isomericSmiles=False in the call to the function.
- The SMARTS generated by the RDKit no longer contains redundant wildcard
  queries. This means the SMARTS strings generated by this release will
generally
  be different from that in previous releases, although the results
produced by
  the queries should not change.
- The RGroupDecomposition code now removes Hs from output R groups by
default.
  To restore the old behavior create an RGroupDecompositionParameters
object and
  set removeHydrogensPostMatch to false.
- The default values for some of the new fingerprint generators have been
changed so
  that they more closely resemble the original fingerprinting code. In
  particular most fingerprinters no longer do count simulation by default
and
  the RDKit fingerprint now sets two bits per feature by default.
- The SMARTS generated for MCS results using the ringMatchesRingOnly or
  completeRingsOnly options now includes ring-membership queries.

## Highlights:
- The substructure matching code is now about 30% faster. This also
improves the
  speed of reaction matching and the FMCS code. (#2500)
- A minimal JavaScript wrapper has been added as part of the core release.
(#2444)
- It's now possible to get information about why molecule sanitization
failed. (#2587)
- A flexible new molecular hashing scheme has been added. (#2636)

## Acknowledgements:
Patricia Bento, Francois Berenger, Jason Biggs, David Cosgrove, Andrew
Dalke,
Thomas Duigou, Eloy Felix, Guillaume Godin, Lester Hedges, Anne Hersey,
Christoph Hillisch, Christopher Ing, Jan Holst Jensen, Gareth Jones, Eisuke
Kawashima, Brian Kelley, Alan Kerstjens, Karl Leswing, Pat Lorton, John
Mayfield, Mike Mazanetz, Dan Nealschneider, Noel O'Boyle, Stephen Roughley,
Roger Sayle, Ricardo Rodriguez Schmidt, Paula Schmiel, Peter St. John,
Marvin
Steijaert, Matt Swain, Amol Thakkar Paolo Tosco, Yi-Shu Tu, Ricardo
Vianello,
Marc Wittke, '7FeiW', 'c56pony', 'sirbiscuit'


## Bug Fixes:
  - MCS returning partial rings with completeRingsOnly=True
 (github issue #945 from greglandrum)
  - Alternating canonical SMILES for fused ring with N
 (github issue #1028 from greglandrum)
  - Atom index out of range error
 (github issue #1868 from A-Thakkar)
  - Incorrect cis/trans stereo symbol for conjugated ring
 (github issue #2023 from baoilleach)
  - Hardcoded max length of SMARTs string cut of input query for FragCatlog
 (github issue #2163 from 7FeiW)
  - VSA_EState {1, ..., 10} calculated by rdkit doesn't seem correct.
 (github issue #2372 from c56pony)
  - MolStandardize: FragmentRemover should not sanitize fragments
 (github issue #2411 from greglandrum)
  - MolStandardize: combinatorial explosion in Normalizer
 

[Rdkit-devel] Beta of the 2019.09 release available

[Greg Landrum]

Dear all,

The beta of the 2019.09 RDKit release has been tagged in github:

https://github.com/rdkit/rdkit/releases/tag/Release_2019_09_1b1

There are a couple more bug fixes and hopefully one more feature expected
before the actual release, but I wanted to go ahead and get the beta out
there.

I've done conda builds for Python 3.6 and 3.7 for Mac, and Linux and I'm
working on the Windows builds now. These all use the beta label so that
they do not install by default; you'll need to run "conda install" as
follows:

conda install -c rdkit/label/beta rdkit

Be sure to confirm that it's installing the right version when you are
prompted (if there's no build available, it will pick the current
production release instead).

The relevant section of the release notes is below, or you can see a nicely
formatted version here:

https://github.com/rdkit/rdkit/releases/tag/Release_2019_09_1b1

As usual, if you have time to try out the new release I would love
feedback. If nothing major comes up, I plan to do the actual release
towards the end of next week.

Best,
-greg

# Release_2019.09.1
(Changes relative to Release_2019.03.1)

## Important
- The atomic van der Waals radii used by the RDKit were corrected/updated
in #2154.
  This leads to different results when generating conformations, molecular
volumes,
  and molecular shapes.

## Backwards incompatible changes
- See the note about atomic van der Waals radii above.
- As part of the enhancements to the MolDraw2D class, we changed the type of
  DrawColour from a tuple to be an actual struct. We also added a 4th
element to
  capture alpha values. This should have no affect on Python code (the alpha
  value is optional when providing color tuples), but will require changes
to C++
  and Java/C# code that is using DrawColour.
- When reading Mol blocks, atoms with the symbol "R" are now converted into
  queries that match any atom when doing a substructure search (analogous
to "*"
  in SMARTS). The previous behavior was to only match other dummy atoms
- When loading SDF files using PandasTools.LoadSDF(), we now default to
  producing isomeric smiles in pandas tables.  To reproduce the original
  behavior, use isomericSmiles=False in the call to the function.
- The SMARTS generated by the RDKit no longer contains redundant wildcard
  queries. This means the SMARTS strings generated by this release will
generally
  be different from that in previous releases, although the results
produced by
  the queries should not change.
- The RGroupDecomposition code now removes Hs from output R groups by
default.
  To restore the old behavior create an RGroupDecompositionParameters
object and
  set removeHydrogensPostMatch to false.
- The default values for some of the new fingerprint generators have been
changed so
  that they more closely resemble the original fingerprinting code. In
  particular most fingerprinters no longer do count simulation by default
and
  the RDKit fingerprint now sets two bits per feature by default.
- The SMARTS generated for MCS results using the ringMatchesRingOnly or
  completeRingsOnly options now includes ring-membership queries.

## Highlights:

## Acknowledgements:
Patricia Bento, Francois Berenger, Jason Biggs, David Cosgrove, Andrew
Dalke,
Thomas Duigou, Eloy Felix, Guillaume Godin, Lester Hedges, Anne Hersey,
Christoph Hillisch, Christopher Ing, Jan Holst Jensen, Gareth Jones, Eisuke
Kawashima, Brian Kelley, Alan Kerstjens, Karl Leswing, Pat Lorton, John
Mayfield, Mike Mazanetz, Dan Nealschneider, Noel O'Boyle, Stephen Roughley,
Roger Sayle, Ricardo Rodriguez Schmidt, Paula Schmiel, Peter St. John, Matt
Swain, Amol Thakkar Paolo Tosco, Ricardo Vianello, Marc Wittke,
'7FeiW', 'c56pony', 'msteijaert', 'sirbiscuit'


## Bug Fixes:
  - MCS returning partial rings with completeRingsOnly=True
 (github issue #945 from greglandrum)
  - Alternating canonical SMILES for fused ring with N
 (github issue #1028 from greglandrum)
  - Atom index out of range error
 (github issue #1868 from A-Thakkar)
  - Incorrect cis/trans stereo symbol for conjugated ring
 (github issue #2023 from baoilleach)
  - Hardcoded max length of SMARTs string cut of input query for FragCatlog
 (github issue #2163 from 7FeiW)
  - VSA_EState {1, ..., 10} calculated by rdkit doesn't seem correct.
 (github issue #2372 from c56pony)
  - MolStandardize: FragmentRemover should not sanitize fragments
 (github issue #2411 from greglandrum)
  - MolStandardize: combinatorial explosion in Normalizer
 (github issue #2414 from greglandrum)
  - MCS code doesn't return envelope MCS if CompleteRingsOnly is true
 (github issue #2420 from greglandrum)
  - RemoveHs() does not remove all hydrogens.
 (github issue #2422 from paulaju)
  - Incorrect assignment of explicit Hs to Al+3 read from mol block
 (github issue #2423 from greglandrum)
  - Cannot set maxProducts > 1000 in 

[Rdkit-devel] CI Update

[Greg Landrum]

Dear all,

I just realized that I haven't really said anything here about the changes
that we've been making to the CI (continuous integration) system that we're
using for the RDKit.

In case you have no idea what I'm talking about or use CI in a different
way: every pull request or code change that's done on the RDKit github repo
triggers a number of automated processes that build and test the the code
and then report back whether or not they succeeded.

Up until recently we had been using two different systems for this:
TravisCI (https://travis-ci.com/ for Linux and Mac builds) and Appveyor (
https://www.appveyor.com/ for Windows builds). These companies provide a
great service to the open-source community by providing free access to
their systems for open-source projects. This is just a fantastic thing. The
Appveyor and TravisCI builds have really helped us ensure that the RDKit is
still passing all of the tests what we've written.

In the reasonably recent past (to be honest, I'm not quite sure when),
Microsoft started providing a similar service, Azure DevOps (
https://azure.microsoft.com/en-us/services/devops/), that has the very nice
property that it supports Linux, Windows, and Mac. Back in April Ricardo
(@ricrogz for those of you watching github) figured out how to make the
RDKit builds work with Azure DevOps and submitted the PR to make it all
work. Since then every PR and code change pushed is also sent to Azure
DevOps where the code is built and tested on all three operating systems.
I'm really happy to have everything in one place (particularly since the
build scripts and configuration are pretty easy to modify now that Ricardo
got the initial version working).

We just extended the Azure DevOps build matrix so that it automatically
builds and tests the Java wrappers on Linux and the Mac, which is going to
be a big help for me when it comes to release time. We'll be adding a
Windows version of that as well (testing both the Java and the C#
wrappers). If things go well we can also add tests for the cartridge builds
in the near future. This is great stuff!

Given that we now have good Windows CI through the Azure services and that
the Appveyor RDKit builds have always been kind of second-rate (this isn't
an Appveyor problem: the RDKit is a bit too big for what is available as a
free service from Appveyor), I just disabled the Appveyor integration.

-greg
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] GSoC-2019 RDKit-Neo4J project

[Greg Landrum]

Hi Evgeny,

Thanks for introducing yourself! I'm really working forward to working with
you on this project and seeing what we can do in order to allow people to
use the RDKit together with Neo4j.

I've created a github repo for this project here:
https://github.com/rdkit/neo4j-rdkit
and I encourage anyone who's interested to keep an eye on that.

Best,
-greg



On Thu, May 9, 2019 at 5:27 PM Evgeniy Sorokin <
evgeniy.inpl.soro...@gmail.com> wrote:

> Hello everyone,
> I am Evgeny Sorokin from Russia and I study in Innopolis University (3rd
> year). It is a new city and a new university that appeared less than 6
> years ago. I am mainly Java/Python developer with additional experience in
> finance/blockchain/ml projects.
> This is my second time I participate in GSoC, previously I worked with
> Tomas Pluskal on MSDK/MZMine projects.
>
> During this summer will be working on RDKit-Neo4J project
> <https://docs.google.com/document/d/1rXUbY3di_YSW1LWTraa3cJEapRtEOrcBc1otZV56FMc/edit#>
>  with
> Greg Landrum, Christian Pilger and Stefan Armbruster (neo4j core
> developer).
> The project will be focused on development of extension for neo4j graph
> database for querying knowledge graphs storing molecular and chemical
> information. This RDKit functionality is already implemented and works with
> Postgres db, the same result is expected to be accomplished during this
> summer for neo4j.
> Best regards, Evgeny Sorokin
> --- @evgerher in telegram, github
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] [Rdkit-announce] 2019.03.1 RDKit Release

[Greg Landrum]

Thanks for that feedback; when I am back in the office this weekend I will
take a look at the Mac conda  install and see if we can fix this with some
specified dependencies

On Wed, 10 Apr 2019 at 01:20, Drew Gibson 
wrote:

> Hi,
>
> I'm using the 2019-03.1 conda build of the new version of rdkit-postgresql
> on macOS Mohave 10.14.4.
>
> just FYI, I got the following error when trying to create the cartridge
> extension in a postgresql chembl_25 instance in the conda build -
>
> chembl_25=# create extension if not exists rdkit;
> ERROR:  could not load library
> "/Users/drew/anaconda3/envs/rdkit-psql-2019/lib/rdkit.so":
> dlopen(/Users/drew/anaconda3/envs/rdkit-psql-2019/lib/rdkit.so, 10):
> Library not loaded: @rpath/libboost_system.dylib
>   Referenced from: /Users/drew/anaconda3/envs/rdkit-psql-2019/lib/rdkit.so
>   Reason: image not found
>
> I couldn't see "libboost_system.dylib" in my conda environment /lib
> directory, so I installed anaconda boost and it fixed the problem - (from
> within the conda environment)
>
> conda install -c anaconda boost
>
> chembl_25=# create extension if not exists rdkit;
> CREATE EXTENSION
> chembl_25=#
>
> I then followed the other commands in the rdkit docs to create some
> fingerprints and build the similarity search index - all seems to be
> working ok.
>
> Cheers,  Drew
>
>
>
>
>
> On Tue, 9 Apr 2019 at 04:42, Greg Landrum  wrote:
>
>> Dear all,
>>
>> I'm pleased to announce that the next version of the RDKit - 2019.03 - is
>> released. The release notes are below.
>>
>> The release files are on the github release page:
>> https://github.com/rdkit/rdkit/releases/tag/Release_2019_03_1
>>
>> Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
>> The available conda binaries for this release are:
>> Linux 64bit: python 3.6, 3.7
>> Mac OS 64bit: python 3.6, 3.7
>> Windows 64bit: python 3.6, 3.7
>>
>> I believe that conda-forge will also switch to the new version in the
>> near future.
>>
>> Please note that the RDKit no longer supports Python 2.7. More details on
>> this here:
>>
>> https://www.mail-archive.com/rdkit-discuss@lists.sourceforge.net/msg08354.html
>>
>> I plan to put conda builds of the PostgreSQL cartridge up in the near
>> future.
>>
>> The online version of the documentation at rdkit.org (
>> http://rdkit.org/docs/index.html) has been updated.
>>
>> Some things that will be finished over the next couple of days:
>> - The conda build scripts will be updated to reflect the new version
>> - The homebrew script
>>
>> Thanks to everyone who submitted code, bug reports, and suggestions for
>> this release!
>>
>> Please let me know if you find any problems with the release or have
>> suggestions for the next one, which is scheduled for October 2019.
>>
>> Best Regards,
>> -greg
>>
>> # Release_2019.03.1
>> (Changes relative to Release_2018.09.1)
>>
>> ## REALLY IMPORTANT ANNOUNCEMENT
>> - As of this realease (2019.03.1) the RDKit no longer supports Python 2.
>> Please
>>   read this rdkit-discuss post to learn what your options are if you need
>> to
>>   keep using Python 2:
>>
>> https://www.mail-archive.com/rdkit-discuss@lists.sourceforge.net/msg08354.html
>>
>> ## Backwards incompatible changes
>> - The fix for github #2245 means that the default behavior of the
>> MaxMinPicker
>>   is now truly random. If you would like to reproduce the previous
>> behavior,
>>   provide a seed value of 42.
>> - The uncharging method in the MolStandardizer now attempts to generate
>>   canonical results for a given molecule. This may result in different
>> output
>>   for some molecules.
>>
>> ## Highlights:
>> - There's now a Japanese translation of large parts of the RDKit
>> documentation
>> - SGroup data can now be read from and written to Mol/SDF files
>> - The enhanced stereo handling has been improved: the information is now
>>   accessible from Python, EnumerateStereoisomers takes advantage of it,
>> and it
>>   can be read from and written to CXSmiles
>>
>> ## Acknowledgements:
>> Michael Banck, Francois Berenger, Thomas Blaschke, Brian Cole, Andrew
>> Dalke,
>> Bakary N'tji Diallo, Guillaume Godin, Anne Hersey, Jan Holst Jensen,
>> Sunhwan Jo,
>> Brian Kelley, Petr Kubat, Karl Leswing, Susan Leung, John Mayfield, Adam
>> Moyer,
>> Dan Nealschneider, Noel O'Boyle, Stephen Roughley, Takayuki Serizawa,
>> Gianluca
&

Re: [Rdkit-devel] 2019_03_1b1: lots of undefined references to libboost_iostreams functions

[Greg Landrum]

Hi Gabriele,

I haven't tried a boost 1.70 build yet, so I can't confirm that it works.
Could you please try 1.69 and see if that helps?
If not, please send the exact cmake command you used and what the output
was.

Thanks,
-greg


On Sat, Apr 6, 2019 at 3:53 PM  wrote:

> hello,
>
> there seems to be a glitch in the 2019_03_1b1 build process, where a lot
> of link steps fail for me with undefined references to
> libboost_iostreams functions. Eg:
>
> 8<
> /usr/bin/ld: lib/libRDKitmaeparser.so.1.2019.03.1b1: undefined
> reference to `boost::iostreams::zlib::deflated'
> /usr/bin/ld: lib/libRDKitmaeparser.so.1.2019.03.1b1: undefined
> reference to `boost::iostreams::detail::zlib_base::before(char const*&,
> char const*, char*&, char*)'
>
> [...]
>
> /usr/bin/ld: lib/libRDKitmaeparser.so.1.2019.03.1b1: undefined
> reference to `boost::iostreams::zlib::default_compression'
> collect2: error: ld returned 1 exit status
> >8
>
> I can make my build complete successfully only with:
> export LDFLAGS="-lboost_iostreams"
> Is this to be expected or is there a problem with the build process?
> (all previous releases didn't need that)
>
> I can add that ./External/CoordGen/CMakeLists.txt
> ./Code/GraphMol/FileParsers/CMakeLists.txt and
> ./Code/RDStreams/CMakeLists.txt do actually contain a:
>set (link_iostreams ${Boost_LIBRARIES})
> definition, but apparently link_iostreams is eventually empty (but I
> might not have followed correctly the logic of the cmake files)
>
> Building on linux vs boost-1_70_0_rc1
>
> thanks a lot
> ciao
> gabriele
>
>
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2018.09.1 RDKit Release

[Greg Landrum]

I'm pleased to announce that the next version of the RDKit - 2018.09 - is
released. The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2018_09_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 2.7, 3.6
Mac OS 64bit: python 2.7, 3.6
Windows 64bit: python 3.6

I hope to be able to do python 3.7 binaries sometime in the not-too-distant
future.

The missing binary for python 2.7 on windows is explained here:
https://www.mail-archive.com/rdkit-discuss@lists.sourceforge.net/msg07850.html

Please note that this is the last feature release of the RDKit which will
support Python 2.7. More details on this here:
https://www.mail-archive.com/rdkit-discuss@lists.sourceforge.net/msg08354.html

I've also put conda builds of the PostgreSQL cartridge up for Linux and the
Mac.

The online version of the documentation at rdkit.org (
http://rdkit.org/docs/index.html) has been updated. Note that because of
the move away from epydoc, the structure of the documentation has changed a
bit and old URLs may not work.

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version
- The homebrew script

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for April 2019.

Best Regards,
-greg


# Release_2018.09.1
(Changes relative to Release_2018.03.1)

## Highlights:
- This release includes two contributions from the Google Summer of Code:
   - A new generalized fingerprint generator.
   - An integration/port of MolVS to the core RDKit.
  The API on both of these may change a bit with future releases.
- The rdkit.Chem.Draw module now includes functions for depicting
fingerprint
  bits. Morgan and RDKit fingerprints are currently supported.

## Deprecations
- As part of the changes and cleaning up done for #1836 many of the
`#defines`
  used in the RDKit have been renamed.
- `USE_BUILTIN_POPCOUNT` -> `RDK_OPTIMIZE_NATIVE`
- `RDK_THREADSAFE_SSS` -> `RDK_BUILD_THREADSAFE_SSS`
- `BUILD_COORDGEN_SUPPORT` -> `RDK_BUILD_COORDGEN_SUPPORT`
- `BUILD_AVALON_SUPPORT` -> `RDK_BUILD_AVALON_SUPPORT`
- `BUILD_INCHI_SUPPORT` -> `RDK_BUILD_INCHI_SUPPORT`
- `BUILD_SLN_SUPPORT` -> `RDK_BUILD_SLN_SUPPORT`
- `RDK_CAIRO_BUILD` -> `RDK_BUILD_CAIRO_SUPPORT`

## Documentation updates
We have moved to using Sphinx's autodoc to create the Python API
documentation.
`epydoc`, the tool we used to use, is no longer actively developed and only
supports
Python2. There will undoubtedly be problems associated with the change; if
you notice
anything missing in the documetation or something that's really badly
formatted,
please either let us know or submit a PR with a fix.

## Backwards incompatible changes
This release includes a set of changes to make the default arguments to
common
functions less error prone (github #1679).
- GetAtomSmiles() now generates isomeric SMILES by default.
- The ringMatchesRingOnly option to the FindMCS() function now applies to
  atom-atom matches as well as bond-bond matches.
- The Python functions EmbedMolecule() and EmbedMultipleConfs() now use the
  ETKDG algorithm by default instead of standard distance geometry.

## Acknowledgements:
Boran Adas, Francois Berenger, Thomas Blaschke,  Brian Cole, Andrew Dalke,
Guillaume Godin,
Brice Hoff, Brian Kelley, Karl Leswing, Susan Leung, Pat Lorton, Josh
Meyers, Hirotomo Moriwaki,
Dan Nealschneider, Noel O'Boyle, Pavel Raiskup, Sereina Riniker, Ricardo
Rodriguez Schmidt,
Stephen Roughley, Roger Sayle, Takayuki Serizawa, Rim Shayakhmetov, Gregory
Simm, Jon Sorenson,
Matt Swain, Kiran Telukunta, Paulo Tosco, Alain Vaucher, Maciej
Wójcikowski, '0xDECAFC0FFEE',
'jaechanglim', 'paconius'

## Contrib updates:
- The FastCluster code has been updated.

## New Features and Enhancements:
  - expose MolChemicalFeature.{get,set}ActiveConformer()  to python
 (github issue #1636 from greglandrum)
  - added Scripts/create_deb_packages.sh
 (github pull #1655 from UnixJunkie)
  - Start to use Catch2 for new tests
 (github pull #1732 from greglandrum)
  - Switch DbCLI scripts from optparse to argparse
 (github issue #1778 from greglandrum)
  - Add EEM partial charges
 (github pull #1828 from greglandrum)
  - Add header file providing access to RDKit compile time flags
 (github issue #1836 from greglandrum)
  - add control over the coordinate precision to coordgen
 (github pull #1847 from greglandrum)
  - Add Properties interface to ChemicalReactions
 (github pull #1848 from greglandrum)
  - Switch Python API documentation generation over to Sphinx autodoc
 (github pull #1849 from greglandrum)
  - expose MolOps::assignStereochemistryFrom3D() to Python
 (github issue #1850 from greglandrum)
  

[Rdkit-devel] [Question] Ok to switch to conda-forge for RDKit builds?

[Greg Landrum]

Dear all,

TL;DR: Now that RDKit builds are available on conda-forge, I would like to
stop doing builds on the rdkit conda channel. I'm looking for feedback
about that here.

Thanks to the persistence of Peter St John and Matt Swain, the RDKit is now
available on conda-forge:
https://anaconda.org/conda-forge/rdkit/files
If you take a look, you'll find builds for Mac, Linux, and Windows together
with multiple versions of Python. The build/deployment steps are all
automated. It's really cool!

Given that these packages now exist, I don't see much value in continuing
to also host standard RDKit builds in the rdkit conda channel. So I would
propose that we switch to using conda-forge as the primary channel for
doing RDKit builds/distributions. Having the automated process available
would save me a lot of time and remove the chance for me to make a mistake
while doing the builds.[1]
If we go this way, I will update the documentation to point to conda-forge
and will only do the occasional nightly or beta build in the rdkit conda
channel.

Does anyone have any objections to this or see any problems that it might
cause?

Many thanks to Matt and Peter for making the conda-forge builds happen!

-greg
[1] As fun as these are, I think I can live without them. ;-)
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Beta of the 2018.09 release available

[Greg Landrum]

Dear all,

The beta of the 2018.09 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2018_09_1b1

I will try to get some conda builds for python 3.6 up over the next day or
so. These will use the beta label so that they do not install by default;
you'll need to run "conda install" as follows:

conda install -c rdkit/label/beta rdkit python=3.6

Be sure to confirm that it's installing the right version when you are
prompted (if there's no build available, it will pick the current
production release instead).

You can check to see if a build is available for your platform/python
version here:
*https://anaconda.org/rdkit/rdkit/files?version=2018.09.1b1.0
*

The relevant section of the release notes is below.

As usual, if you have time to try out the new release I would love
feedback. If nothing major comes up, I plan to do the actual release
sometime next week.

Best,
-greg

# Release_2018.09.1
(Changes relative to Release_2018.03.1)

## Deprecations
- As part of the changes and cleaning up done for #1836 many of the
`#defines`
  used in the RDKit have been renamed.
- `USE_BUILTIN_POPCOUNT` -> `RDK_OPTIMIZE_NATIVE`
- `RDK_THREADSAFE_SSS` -> `RDK_BUILD_THREADSAFE_SSS`
- `BUILD_COORDGEN_SUPPORT` -> `RDK_BUILD_COORDGEN_SUPPORT`
- `BUILD_AVALON_SUPPORT` -> `RDK_BUILD_AVALON_SUPPORT`
- `BUILD_INCHI_SUPPORT` -> `RDK_BUILD_INCHI_SUPPORT`
- `BUILD_SLN_SUPPORT` -> `RDK_BUILD_SLN_SUPPORT`
- `RDK_CAIRO_BUILD` -> `RDK_BUILD_CAIRO_SUPPORT`

## Backwards incompatible changes
This release includes a set of changes to make the default arguments to
common
functions less error prone (github #1679).
- GetAtomSmiles() now generates isomeric SMILES by default.
- The ringMatchesRingOnly option to the FindMCS() function now applies to
  atom-atom matches as well as bond-bond matches.
- The Python functions EmbedMolecule() and EmbedMultipleConfs() now use the
  ETKDG algorithm by default instead of standard distance geometry.

## Highlights:
- This release includes two contributions from the Google Summer of Code:
   - A new generalized fingerprint generator.
   - An integration/port of MolVS to the core RDKit.
  The API on both of these may change a bit with future releases.
- The rdkit.Chem.Draw module now includes functions for depicting
fingerprint
  bits. Morgan and RDKit fingerprints are currently supported.

## Acknowledgements:
Boran Adas, Francois Berenger, Thomas Blaschke,  Brian Cole, Andrew Dalke,
Guillaume Godin, Brice Hoff, Brian Kelley, Karl Leswing, Susan Leung, Pat
Lorton, Josh Meyers, Hirotomo Moriwaki, Dan Nealschneider, Noel O'Boyle,
Pavel Raiskup, Sereina Riniker, Ricardo Rodriguez Schmidt, Stephen
Roughley, Roger Sayle, Rim Shayakhmetov, Gregory Simm, Jon Sorenson, Matt
Swain, Kiran Telukunta, Paulo Tosco, Alain Vaucher, Maciej Wójcikowski,
'0xDECAFC0FFEE', 'jaechanglim', 'paconius'

## Contrib updates:
- The FastCluster code has been updated.

## New Features and Enhancements:
  - expose MolChemicalFeature.{get,set}ActiveConformer()  to python
 (github issue #1636 from greglandrum)
  - added Scripts/create_deb_packages.sh
 (github pull #1655 from UnixJunkie)
  - Start to use Catch2 for new tests
 (github pull #1732 from greglandrum)
  - Switch DbCLI scripts from optparse to argparse
 (github issue #1778 from greglandrum)
  - Add EEM partial charges
 (github pull #1828 from greglandrum)
  - Add header file providing access to RDKit compile time flags
 (github issue #1836 from greglandrum)
  - add control over the coordinate precision to coordgen
 (github pull #1847 from greglandrum)
  - Add Properties interface to ChemicalReactions
 (github pull #1848 from greglandrum)
  - Switch Python API documentation generation over to Sphinx autodoc
 (github pull #1849 from greglandrum)
  - expose MolOps::assignStereochemistryFrom3D() to Python
 (github issue #1850 from greglandrum)
  - bivariate_normal deprecation in mlab.py of matplotlib
 (github issue #1851 from telukir)
  - Expose minAtomRingSize() and minBondRingSize() to Python wrappers
 (github pull #1859 from mwojcikowski)
  - enable building DLLs on Windows
 (github pull #1861 from ptosco)
  - Fix compatibility with Boost 1.67+
 (github pull #1864 from mcs07)
  - Don't manually set RDConfig paths in conda env
 (github pull #1865 from mcs07)
  - Make svg xmlns prefix use more consistent
 (github pull #1866 from mcs07)
  - Add custom 3D Descriptors
 (github pull #1867 from greglandrum)
  - Add initial Maestro format Supplier using maeparser library
 (github pull #1872 from lorton)
  - add queryAtomNonHydrogenDegree() query operation
 (github issue #1873 from greglandrum)
  - Add an auto-populated file with cmake config options
 (github pull #1874 from greglandrum)
  - Custom property VSA
 (github pull #1884 from sriniker)
  - Swap maeparser and coordgen dependencies to use releases
 (github issue #1887 from greglandrum)
  - expose 

Re: [Rdkit-devel] The RDKit Travis builds

[Greg Landrum]

The good news is that I didn't end up needing to do anything: after the
first build failed strangely the others worked normally. Yay! So we're now
migrated to travis-ci.com:
https://travis-ci.com/rdkit/rdkit

The bad news is that the intermittent, non-reproducible build failures seem
to still be an issue. Gr

-greg
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] The RDKit Travis builds

[Greg Landrum]

Just a quick FYI that I asked the folks at Travis-CI to switch us over to
their newer setup (Travis-ci.com instead of Travis-ci.org) today.[1] This
has broken the build, as one would expect. :-S

I will spend some time on it over the next day or so to get things working
again.

-greg
[1] there were intermittent and non-reproducible build failures on the old
system and I am hoping this will help. It needs to happen eventually anyway.
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit 2018.03.1 Build and Installation

[Greg Landrum]

cmake is finding boost v1.67, not the system boost.


On Wed, May 16, 2018 at 2:34 PM alb greg <agparis7dide...@gmail.com> wrote:

> Ubuntu 16.04
>
> *CmakeMessages :*
>
> -- The C compiler identification is GNU 5.4.0
> -- The CXX compiler identification is GNU 5.4.0
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check if the system is big endian
> -- Searching 16 bit integer
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of unsigned short
> -- Check size of unsigned short - done
> -- Using unsigned short
> -- Check if the system is big endian - little endian
> -- Found PythonInterp: /usr/bin/python3 (found version "3.5.2")
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.5m.so (found
> version "3.5.2")
> -- Found Eigen3: /usr/include/eigen3 (Required is at least version
> "2.91.0")
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_create
> -- Looking for pthread_create - not found
> -- Looking for pthread_create in pthreads
> -- Looking for pthread_create in pthreads - not found
> -- Looking for pthread_create in pthread
> -- Looking for pthread_create in pthread - found
> -- Found Threads: TRUE
> -- Boost version: 1.67.0
> -- Found the following Boost libraries:
> --   serialization
> == Done updating pains files
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/user/src/rdkit/rdkit/build
>
> *CmakeErrors :*
>
> CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725
> (message):
>   Imported targets not available for Boost version 106700
> Call Stack (most recent call first):
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:763
> (_Boost_COMPONENT_DEPENDENCIES)
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332
> (_Boost_MISSING_DEPENDENCIES)
>   CMakeLists.txt:194 (find_package)
>
>
> CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725
> (message):
>   Imported targets not available for Boost version 106700
> Call Stack (most recent call first):
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:763
> (_Boost_COMPONENT_DEPENDENCIES)
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332
> (_Boost_MISSING_DEPENDENCIES)
>   CMakeLists.txt:194 (find_package)
>
>
> PYTHON Py_ENABLE_SHARED: 1
> PYTHON USING LINK LINE: -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
> -Wl,-Bsymbolic-functions -Wl,-z,relro
> CMake Warning at /usr/share/cmake-3.5/Modules/FindBoost.cmake:725
> (message):
>   Imported targets not available for Boost version 106700
> Call Stack (most recent call first):
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:763
> (_Boost_COMPONENT_DEPENDENCIES)
>   /usr/share/cmake-3.5/Modules/FindBoost.cmake:1332
> (_Boost_MISSING_DEPENDENCIES)
>   CMakeLists.txt:303 (find_package)
>
>
> == Using strict rotor definition
> -- Found MAEParser source in
> /home/labbe/src/rdkit/rdkit/External/CoordGen/maeparser
> -- Found coordgenlibs source in
> /home/labbe/src/rdkit/rdkit/External/CoordGen/coordgenlibs
> == Updating Filters.cpp from pains file
> -- Found RapidJSON source in /home/labbe/src/rdkit/rdkit/External
>
>
>
>
>
> 2018-05-16 13:05 GMT+02:00 Greg Landrum <greg.land...@gmail.com>:
>
>> On Wed, May 16, 2018 at 12:53 PM alb greg <agparis7dide...@gmail.com>
>> wrote:
>>
>>> I followed the instructions in this dockerfile but it failed with an
>>> error 2 during "make -j3 .. install" command.
>>>
>>>
>> In order to be able to help I need a bit more information than that. What
>> was the error you encountered? What version of Ubuntu? etc.
>>
>> -greg
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit 2018.03.1 Build and Installation

[Greg Landrum]

On Wed, May 16, 2018 at 12:53 PM alb greg  wrote:

> I followed the instructions in this dockerfile but it failed with an error
> 2 during "make -j3 .. install" command.
>
>
In order to be able to help I need a bit more information than that. What
was the error you encountered? What version of Ubuntu? etc.

-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit 2018.03.1 Build and Installation

[Greg Landrum]

For what it's worth:
I put together a Dockerfile to demonstrate how to build the RDKit under
Ubuntu 16.04 here:
https://github.com/rdkit/rdkit_containers/blob/master/docker/ubuntu_xenial/Dockerfile

Aside from the RDkit itself, this uses only software that is part of the
Ubuntu distribution (including the Ubuntu-supplied versions of boost and
Python).

-greg


On Thu, May 3, 2018 at 6:44 PM alb greg  wrote:

> Hello everyone,
>
> I'm an IT and I'm writing in connection with the installation process of
> RDKit.
>
> I have to install the latest version of RDKit (2018.03.1) on several
> workstations running on Ubuntu 16.04 but the building sequence systematically
> went wrong on the "cmake .." step (see logs below).
>
> I installed cmake, python-dev, libsqlite3-dev, NumPy and Boost as required.
>
> I tried to specify options like boost and python directories but it didn't
> solve anything.
>
> Could you please take a look on my logs and give me some help?
>
> Thanks you very much.
>
> Best regards
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Apologies for the delays processing pull requests

[Greg Landrum]

Dear all,

There's something of a backlog of unprocessed pull requests for the RDKit.
Putting (what I hope were) the final touches on the release ended up being
a time consuming slog and didn't leave me much time for looking at PRs. I'm
sorry for this; it's great to have the contributions coming in and I feel
bad about not being able to process them in a timely manner.

Having said that, it's going to get a bit worse before it gets better.
After finishing the release, I'm going to celebrate by giving myself a
short "vacation" from bug fixes, the vagaries of conda, and such tings.I
plan to spend the next week or so using my "RDKit time" to work on a fun
project or two.

Best,
-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2018.03.1 RDKit release

[Greg Landrum]

 I'm pleased to announce that the next version of the RDKit - 2018.03 - is
released. The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2018_03_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 2.7, 3.5, 3.6
Mac OS 64bit: python 2.7, 3.5, 3.6
Windows 64bit: python 3.5, 3.6

The missing binary for python 2.7 on windows is explained here:
https://www.mail-archive.com/rdkit-discuss@lists.sourceforge.net/msg07850.html

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version and
new conda builds will be available in the RDKit channel at anaconda.org (
https://anaconda.org/rdkit).
- The homebrew script
- The online version of the documentation at rdkit.org (I'm traveling this
week, so this is unlikely to be done before next weekend).

Thanks to everyone who submitted code, bug reports, and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for Octobera 2018.

Best Regards,
-greg

# Release_2018.03.1
(Changes relative to Release_2017.09.1)

## C++11 notes

Starting with this release, the RDKit core C++ code is written in modern
C++;
for this release that means C++11. This means that the compilers used to
build
it cannot be completely ancient. Here are the minimum tested versions:
- g++ v4.8: though note that the SLN parser code cannot be built with v4.8.
It
  will automatically be disabled when this older compiler is used.
- clang v3.9: it may be that older versions of the compiler also work, but
we
  haven't tested them.
- Visual Studio 2015: it may be that older versions of the compiler also
work,
  but we haven't tested them.

## Backwards incompatible changes

This release includes a set of changes to make the default arguments to
common
functions less error prone (github #1679).
- MolToSmiles() now generates isomeric SMILES by default.
- The embedding code now uses the ETKDG method by default.
- MolToMolBlock() will now by default generate a set of 2D coordinates for
  molecules when the includeStereo option is set to True. The changes are
made
  to a copy of the molecule; the molecule itself will not be modified.
- The Mol file (and SDF) parser now determines atomic stereochemisty based
on
  the 3D coordinates provided (if 3D coordinates are provided).
- The SMILES parser now supports CXSMILES by default (assuming that
additional
  text that looks like CXSMILES extensions is there).

In every case the old behavior can be obtained by providing an optional
argument
to the function(s) mentioned.

## Acknowledgements:
Boran Adas, José Emilio Sánchez Aparicio, Patrick Avery, Jason Biggs, Brian
Cole, Andrew Dalke, JW Feng, Peter Gedeck, Guillaume Godin, Richard Hall,
Thomas
Heavy, Gareth Jones, Brian Kelley, Karl Leswing, Susan Leung, Chris Morris,
Dan
Nealschneider, Noel O'Boyle, Axel Pahl, Pavel Polishchuk, Sereina Riniker,
Jeff
van Santen, Roger Sayle, Martin Šícho, Matt Swain, Paolo Tosco, Sam Webb,
Maciej
Wójcikowski, Nicola Zonta, 'clinntt', 'hjuinj', 'iwatobipen',

## Highlights:
  - An initial version of an integration with Schrodinger's coordgen
library is
included. This produces much better 2D coordinates for complex
molecules.
  - Thanks to the move to modern C++ the RDKit is now faster and uses less
memory
  - A number of improvements were made to the PDB reader
  - v2 of the ETKDG torsions and potentials is now available

## Contrib updates:
  - Implementation of Peter Ertl's IFG method for identifying functional
groups
from Guillaume Godin and Richard Hall
  (github pull #1813 from thegodone)

## New Features and Enhancements:
  - Support InChi 1.05
 (github issue #1533 from greglandrum)
  - Update CPack to create .deb files correctly
 (github pull #1580 from psavery)
  - Initial commit of EnumerateHeterocycles
 (github pull #1588 from coleb)
  - Version 2 of ETKDG
 (github pull #1597 from sriniker)
  - GetMolFrags now optionally returns atom indices along with mols
 (github pull #1602 from ptosco)
  - NP Likeness with confidence value
 (github pull #1608 from apahl)
  - Adding an option to EnumerateStereoisomers to only return unique isomers
 (github pull #1612 from coleb)
  - Add function wedgeBond()
  (github issue #1615 from greglandrum)
  - Dev/substructlibrary docs
 (github pull #1620 from bp-kelley)
  - Turns off exception throwing for certain classes Rlabel sanitization.
 (github pull #1621 from bp-kelley)
  - Add an "MDL" aromaticity model
 (github issue #1622 from hjuinj)
  - Add support for %(NNN) notation for ring closures
 (github pull #1624 from baoilleach)
  - Enable windows build that uses cairo
 (github pull #1628 from greglandrum)
  - [MRG] Fix PDB reader + add argument to toggle proximity bonding
 (github pull #1629 from 

Re: [Rdkit-devel] [Rdkit-discuss] Some larger-scale RDKit C++ code changes

[Greg Landrum]

Thanks for raising this Markus. It had been on my list of things to look
into for a while and I had been kind of dreading it.[1]

I did a bit of googling and experimentation and it looks like this approach
works well:
https://stackoverflow.com/questions/5956300/merging-two-very-divergent-branches-using-git
Given that it also (at least to me) makes sense, I think that this is how
I'll proceed.

-greg
[1] this is where I usually point to this xkcd: https://xkcd.com/1597/ and
make a joke about no longer being able to just walk over and ask Nadine how
to solve the problem. :-)

On Wed, Apr 4, 2018 at 1:20 PM, Markus Sitzmann <markus.sitzm...@gmail.com>
wrote:

> Have you tried a merge (after branching the master to something like
> master-test-merge and then merge modern_cxx) ? How horrible does it look?
> It might be quiet okay. Or do you really have a lot of changes in the
> current master you don't have/want to have in modern_cxx and the future
> master. And well, it just was a concern by me that avoiding "early" horrors
> might cause bigger horrors later :-). Renaming the master in a GIT
> repository is something I wouldn't do easily - I would regard it more like
> a very, very last resort because if the master is renamed (or replaced by
> another branch), any branch in any remote repository by anybody who ever
> branched from master (including the RDKit github repository) becomes
> potentially (very likely) invalid by this step. Only if this is a small
> concern, I would do it (I doubt it is in case of RDKit).
>
> Markus
>
> On Wed, Apr 4, 2018 at 11:56 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
>
>>
>>
>> On Wed, Apr 4, 2018 at 11:27 AM, Markus Sitzmann <
>> markus.sitzm...@gmail.com> wrote:
>>
>>> Hi Greg,
>>>
>>> >  Concretely what this means in github is that the current master
>>> branch will be renamed to legacy and the modern_cxx branch will be renamed
>>> to master.
>>>
>>> I hope you are not actually just renaming it - although I am not
>>> affected personally, that might be a call for trouble because it
>>> invalidates any remote repository of rdkit.
>>>
>>
>> If you have suggestions for how to do a large-delta change like that in a
>> non-horrible manner, I would love to hear them :-)
>>
>> -greg
>>
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] [Rdkit-discuss] Some larger-scale RDKit C++ code changes

[Greg Landrum]

On Wed, Apr 4, 2018 at 11:27 AM, Markus Sitzmann 
wrote:

> Hi Greg,
>
> >  Concretely what this means in github is that the current master branch
> will be renamed to legacy and the modern_cxx branch will be renamed to
> master.
>
> I hope you are not actually just renaming it - although I am not affected
> personally, that might be a call for trouble because it invalidates any
> remote repository of rdkit.
>

If you have suggestions for how to do a large-delta change like that in a
non-horrible manner, I would love to hear them :-)

-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Some larger-scale RDKit C++ code changes

[Greg Landrum]

NOTE: If you don't work with the RDKit at the C++ level or build the code
yourself from source, you probably don't need to read this email.

TL;DR: When we do the beta for the 2018.03.1 release we're going to switch
the C++ backend to use modern C++ (=C++11). For people who can't switch to
use that code, we will continue to provide bug fixes for the 2017.09
release for at least another 6 months.

--
# What's happening?

As part of the upcoming 2018.03 release, we will start using modern C++ for
the RDKit - this means C++11 at the moment, the goal is that you should be
able to build the code with g++ v4.8. I've been talking about this for a
while, blogged about it (https://medium.com/@greg.land
rum_t5/the-rdkit-and-modern-c-48206b966218), and posted to the rdkit-devel
list (https://sourceforge.net/p/rdkit/mailman/message/35811216/), now it's
finally happening.

Concretely what this means in github is that the current master branch will
be renamed to legacy and the modern_cxx branch will be renamed to master.

# Who does this affect?

This should only affect people who need to build the RDKit C++ code
themselves. If you use a binary version of the RDKit like the ones
available inside of Anaconda Python or KNIME, this change should have no
impact upon you.

# What about people who can't use up-to-date compilers?

We realize that some people on older operating systems will not be able to
switch to start using a compiler that supports C++11. In order to continue
to support this subset of developers, we will continue to apply bug fixes
to the current Release_2017_09 branch and do occasional patch releases.
Since this is intended for people who need to build the code themselves
anyway, we won't do builds of these releases any more.

We will keep doing these patch release at least until the 2018.09 release.
Whether or not we continue past that date will depend on demand, so if you
are using these releases please let us know.

# Why are you doing this?

There's a long, rambling answer to this, but I'm not going to give it here.
:-)
The simplest explanation is that we think that the core of the RDKit should
be using a modern and (reasonably) up-to-date version of the language that
it's written in. The developer experience is better and, happily, the code
ends up being faster.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] problem building rdkit

[Greg Landrum]

hmm, I'm stumped.
I'm going to have to try to reproduce the problem on a linux box.
Since I'm traveling this week (at the ACS in New Orleans), this may take a
while.

-greg


On Mon, Mar 19, 2018 at 8:41 AM, TJ O'Donnell <t...@acm.org> wrote:

> I grep'd with a slight mod to your suggestion and got these few lines.
> There are many others with all lower case boost_thread and boost_serial
>
> tj@vmmint:~/RDKit/rdkit/build$ grep Boost_SERIAL CMakeCache.txt
> Boost_SERIALIZATION_LIBRARY_DEBUG:FILEPATH=/usr/lib/x86_
> 64-linux-gnu/libboost_serialization.so
> Boost_SERIALIZATION_LIBRARY_RELEASE:FILEPATH=/usr/lib/x86_
> 64-linux-gnu/libboost_serialization.so
> //ADVANCED property for variable: Boost_SERIALIZATION_LIBRARY_DEBUG
> Boost_SERIALIZATION_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
> //ADVANCED property for variable: Boost_SERIALIZATION_LIBRARY_RELEASE
> Boost_SERIALIZATION_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
>
> tj@vmmint:~/RDKit/rdkit/build$ grep Boost_THREAD CMakeCache.txt
> Boost_THREAD_LIBRARY_DEBUG:FILEPATH=/usr/lib/x86_64-
> linux-gnu/libboost_thread.so
> Boost_THREAD_LIBRARY_RELEASE:FILEPATH=/usr/lib/x86_64-
> linux-gnu/libboost_thread.so
> //ADVANCED property for variable: Boost_THREAD_LIBRARY_DEBUG
> Boost_THREAD_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
> //ADVANCED property for variable: Boost_THREAD_LIBRARY_RELEASE
> Boost_THREAD_LIBRARY_RELEASE-ADVANCED:INTERNAL=1
>
> The case-insensitive search has lines like this and many more:
>
> tj@vmmint:~/RDKit/rdkit/build$ grep -i boost_SERIAL CMakeCache.txt
> rdqueries_LIB_DEPENDS:STATIC=general;GraphMol;general;
> RDGeometryLib;general;DataStructs;general;RDGeneral;
> general;RDBoost;general;/usr/lib/x86_64-linux-gnu/libpython2.7.so
> ;general;/usr/lib/x86_64-linux-gnu/libboost_python.
> so;general;/usr/lib/x86_64-linux-gnu/libboost_thread.so;
> general;/usr/lib/x86_64-linux-gnu/libboost_system.so;
> general;/usr/lib/x86_64-linux-gnu/libpthread.so;general;/
> usr/lib/x86_64-linux-gnu/libboost_serialization.so;
> rdtrajectory_LIB_DEPENDS:STATIC=general;Trajectory;
> general;RDGeometryLib;general;RDGeneral;general;GraphMol;
> general;/usr/lib/x86_64-linux-gnu/libpython2.7.so;general;/
> usr/lib/x86_64-linux-gnu/libboost_python.so;general;/
> usr/lib/x86_64-linux-gnu/libboost_thread.so;general;/
> usr/lib/x86_64-linux-gnu/libboost_system.so;general;/
> usr/lib/x86_64-linux-gnu/libpthread.so;general;/usr/
> lib/x86_64-linux-gnu/libboost_serialization.so;
>
>
>
>
> On Mon, Mar 19, 2018 at 3:27 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
>
>> Well, I don't see anything obvious there to explain why the serialization
>> library is being treated differently from the others.
>>
>> Could you please look at (and send) the output of;
>> grep boost_THREAD CMakeCache.txt
>> grep boost_SERIAL CMakeCache.txt
>>
>> Best,
>> -greg
>>
>>
>>
>> On Sun, Mar 18, 2018 at 10:31 PM, TJ O'Donnell <t...@acm.org> wrote:
>>
>>> FYI I cloned  https://github.com/rdkit/rdkit.git
>>> and get the same error
>>>
>>> TJ
>>>
>>> On Sun, Mar 18, 2018 at 7:31 PM, TJ O'Donnell <t...@acm.org> wrote:
>>>
>>>> Thanks for the quick reply, Greg.  I just did a git pull and it merged
>>>> in lots of files.
>>>> I may try a clone to a "fresh" folder and see how that goes.
>>>> Anyway, here's the output from  VERBOSE=1 make FilterCatalog
>>>>
>>>> tj@vmmint:~/RDKit/rdkit/build$ VERBOSE=1 make FilterCatalog
>>>> /usr/bin/cmake -H/home/tj/RDKit/rdkit -B/home/tj/RDKit/rdkit/build
>>>> --check-build-system CMakeFiles/Makefile.cmake 0
>>>> make -f CMakeFiles/Makefile2 FilterCatalog
>>>> make[1]: Entering directory `/home/tj/RDKit/rdkit/build'
>>>> /usr/bin/cmake -H/home/tj/RDKit/rdkit -B/home/tj/RDKit/rdkit/build
>>>> --check-build-system CMakeFiles/Makefile.cmake 0
>>>> /usr/bin/cmake -E cmake_progress_start 
>>>> /home/tj/RDKit/rdkit/build/CMakeFiles
>>>> 9
>>>> make -f CMakeFiles/Makefile2 Code/GraphMol/FilterCatalog/CM
>>>> akeFiles/FilterCatalog.dir/all
>>>> make[2]: Entering directory `/home/tj/RDKit/rdkit/build'
>>>> make -f Code/RDGeneral/CMakeFiles/RDGeneral.dir/build.make
>>>> Code/RDGeneral/CMakeFiles/RDGeneral.dir/depend
>>>> make[3]: Entering directory `/home/tj/RDKit/rdkit/build'
>>>> cd /home/tj/RDKit/rdkit/build && /usr/bin/cmake -E cmake_depends "Unix
>>>> Makefiles" /home/tj/RDKit/rdkit /home/tj/RDKit/rdkit/Code/RDGeneral
>>>> /home/tj/RDKit/rdkit/build /home/tj/RDKit/r

Re: [Rdkit-devel] problem building rdkit

[Greg Landrum]

uct
>> /home/tj/RDKit/rdkit/build/Code/GraphMol/Substruct/CMakeFile
>> s/SubstructMatch.dir/DependInfo.cmake --color=
>> make[3]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> make -f Code/GraphMol/Substruct/CMakeFiles/SubstructMatch.dir/build.make
>> Code/GraphMol/Substruct/CMakeFiles/SubstructMatch.dir/build
>> make[3]: Entering directory `/home/tj/RDKit/rdkit/build'
>> make[3]: Nothing to be done for `Code/GraphMol/Substruct/CMake
>> Files/SubstructMatch.dir/build'.
>> make[3]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> /usr/bin/cmake -E cmake_progress_report /home/tj/RDKit/rdkit/build/CMa
>> keFiles
>> [ 88%] Built target SubstructMatch
>> make -f Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/build.make
>> Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/depend
>> make[3]: Entering directory `/home/tj/RDKit/rdkit/build'
>> cd /home/tj/RDKit/rdkit/build && /usr/bin/cmake -E cmake_depends "Unix
>> Makefiles" /home/tj/RDKit/rdkit 
>> /home/tj/RDKit/rdkit/Code/GraphMol/FilterCatalog
>> /home/tj/RDKit/rdkit/build 
>> /home/tj/RDKit/rdkit/build/Code/GraphMol/FilterCatalog
>> /home/tj/RDKit/rdkit/build/Code/GraphMol/FilterCatalog/CMake
>> Files/FilterCatalog.dir/DependInfo.cmake --color=
>> make[3]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> make -f Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/build.make
>> Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/build
>> make[3]: Entering directory `/home/tj/RDKit/rdkit/build'
>> Linking CXX shared library ../../../lib/libRDKitFilterCatalog.so
>> cd /home/tj/RDKit/rdkit/build/Code/GraphMol/FilterCatalog &&
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/FilterCatalog.dir/link.txt
>> --verbose=1
>> /usr/bin/c++  -fPIC  -mpopcnt -Wno-deprecated -Wno-unused-function
>> -fno-strict-aliasing -Wall -Wextra -fPIC -O3 -DNDEBUG   -shared
>> -Wl,-soname,libRDKitFilterCatalog.so.1 -o 
>> ../../../lib/libRDKitFilterCatalog.so.1.2018.03.1.dev1
>> CMakeFiles/FilterCatalog.dir/Filters.cpp.o 
>> CMakeFiles/FilterCatalog.dir/FilterCatalog.cpp.o
>> CMakeFiles/FilterCatalog.dir/FilterCatalogEntry.cpp.o
>> CMakeFiles/FilterCatalog.dir/FilterMatchers.cpp.o
>> CMakeFiles/FilterCatalog.dir/FunctionalGroupHierarchy.cpp.o
>> ../../../lib/libRDKitSubgraphs.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitSubstructMatch.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitSmilesParse.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitGraphMol.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitRDGeometryLib.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitCatalogs.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitRDGeneral.so.1.2018.03.1.dev1
>> -lBoost::serialization ../../../lib/libRDKitDataStructs.so.1.2018.03.1.dev1
>> ../../../lib/libRDKitRDGeneral.so.1.2018.03.1.dev1 -lboost_thread
>> -lboost_system -lpthread -Wl,-rpath,/home/tj/RDKit/rdkit/build/lib:
>> /usr/bin/ld: cannot find -lBoost::serialization
>> collect2: error: ld returned 1 exit status
>> make[3]: *** [lib/libRDKitFilterCatalog.so.1.2018.03.1.dev1] Error 1
>> make[3]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> make[2]: *** [Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/all]
>> Error 2
>> make[2]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> make[1]: *** [Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/rule]
>> Error 2
>> make[1]: Leaving directory `/home/tj/RDKit/rdkit/build'
>> make: *** [FilterCatalog] Error 2
>>
>> On Sun, Mar 18, 2018 at 3:48 PM, Greg Landrum <greg.land...@gmail.com>
>> wrote:
>>
>>> Hi TJ,
>>>
>>> Hrm, that's ugly. Just to confirm: Are you building the master branch
>>> from github?
>>> It looks like there's no fundamental problem with master; at least the
>>> travis builds pass: https://travis-ci.org/rdkit/rdkit
>>>
>>> To help track this down, can you please send the results of doing:
>>> VERBOSE=1 make FilterCatalog
>>>
>>> Best,
>>> -greg
>>>
>>>
>>> On Sun, Mar 18, 2018 at 11:27 PM, TJ O'Donnell <t...@acm.org> wrote:
>>>
>>>> I'm trying to build rdkit from the latest git source.
>>>> Linux Mint 17
>>>>
>>>> I get this error
>>>> [ 57%] Building CXX object Code/GraphMol/FilterCatalog/CM
>>>> akeFiles/FilterCatalog.dir/FunctionalGroupHierarchy.cpp.o
>>>> Linking CXX shared library ../../../lib/libRDKitFilterCatalog.so
>>>> /usr/bin/ld: cannot find -lBoost::serialization
>>>> collect2: error: ld returned 1 exit status
>>>> make[2]: *** [lib/libRDKitFilterCatalog.so.1.2018.03.1.dev1] Error 1
>>>> make[1]: *** [Code/GraphMol/FilterCatalog/C
>>>> MakeFiles/FilterCatalog.dir/all] Error 2
>>>> make: *** [all] Error 2
>>>>
>>>> but cmake seemed to find this lib OK
>>>> cmake .. -DRDK_BUILD_INCHI_SUPPORT=ON
>>>> -- The C compiler identification is GNU 4.8.4
>>>> -- The CXX compiler identification is GNU 4.8.4
>>>> 
>>>> -- Found Threads: TRUE
>>>> -- Boost version: 1.54.0
>>>> -- Found the following Boost libraries:
>>>> --   thread
>>>> --   system
>>>> -- Boost version: 1.54.0
>>>> -- Found the following Boost libraries:
>>>> --   serialization
>>>> == Using strict rotor definition
>>>> == Updating Filters.cpp from pains file
>>>>
>>>> Can you help me figure out how to get past this?
>>>>
>>>> Thanks,
>>>> TJ
>>>>
>>>> 
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> ___
>>>> Rdkit-devel mailing list
>>>> Rdkit-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>>>
>>>>
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] problem building rdkit

[Greg Landrum]

Hi TJ,

Hrm, that's ugly. Just to confirm: Are you building the master branch from
github?
It looks like there's no fundamental problem with master; at least the
travis builds pass: https://travis-ci.org/rdkit/rdkit

To help track this down, can you please send the results of doing:
VERBOSE=1 make FilterCatalog

Best,
-greg


On Sun, Mar 18, 2018 at 11:27 PM, TJ O'Donnell  wrote:

> I'm trying to build rdkit from the latest git source.
> Linux Mint 17
>
> I get this error
> [ 57%] Building CXX object Code/GraphMol/FilterCatalog/
> CMakeFiles/FilterCatalog.dir/FunctionalGroupHierarchy.cpp.o
> Linking CXX shared library ../../../lib/libRDKitFilterCatalog.so
> /usr/bin/ld: cannot find -lBoost::serialization
> collect2: error: ld returned 1 exit status
> make[2]: *** [lib/libRDKitFilterCatalog.so.1.2018.03.1.dev1] Error 1
> make[1]: *** [Code/GraphMol/FilterCatalog/CMakeFiles/FilterCatalog.dir/all]
> Error 2
> make: *** [all] Error 2
>
> but cmake seemed to find this lib OK
> cmake .. -DRDK_BUILD_INCHI_SUPPORT=ON
> -- The C compiler identification is GNU 4.8.4
> -- The CXX compiler identification is GNU 4.8.4
> 
> -- Found Threads: TRUE
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   thread
> --   system
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   serialization
> == Using strict rotor definition
> == Updating Filters.cpp from pains file
>
> Can you help me figure out how to get past this?
>
> Thanks,
> TJ
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Two 'Labute' descriptors seem to be always returning 0.0

[Greg Landrum]

Hi Jeff,

On Thu, Mar 15, 2018 at 10:26 PM, jeff godden  wrote:
>
>
> First and foremost thank you for your excellent offering of a singularly
> useful set of molecular descriptors!
>

Thanks for the kind words. :-)


> As one of the authors cited by Dr Labute (http://www.chemcomp.com/journ
> al/vsadesc.htm)
> ​,​
> i've appreciated RDKit's implementation of the "Labute descriptor" set.
> So i've noticed that two particular descriptors in that set, specifically
> SlogP_VSA9 and SMR_VSA8, appear to always return a value of 0.0 no matter
> which of a
> ​substantial ​
> set of small molecules are tested via:
>
> from rdkit.Chem import Descriptors
> Descriptors.SlogP_VSA9(molecule)
> Descriptors.SMR_VSA8(molecule)
>

Let's look at the first one. SlogP_VSA9 is the sum of the VSA contributions
of atoms whose contribution to SlogP falls into bin 9. In the case of the
RDKit this is means an atomic SlogP contribution of between 0.3 and 0.4 (I
believe that this is the same as the definition in the original paper. This
RDKit bins are not always the same as the original publication, in this
case they are). So we need to look for atom types that have an SlogP
contribution between 0.3 and 0.4. Curiously, there don't seem to be any of
these. Going back to the original Wildman and Crippen paper (the source of
these values), there aren't any there either. This is "a bit" strange since
the Labute article says that they picked the bins in order to have evenly
distributed values.

So I don't think you're doing anything wrong; there's an oddity in the
definition of the bins and it looks like that descriptor is basically
always going to be zero. Thanks for pointing it out.

Since I have found the various "MOE like" descriptors to be quite useful in
the past, it's worth considering doing another version of them where the
bin definitions have been adjusted based on a larger set of molecules.
Something to think about for a future version...

Thanks for the great question,
-greg



>
> All other descriptors i've tried seem to produce sensible results (with
> those same molecules)
>
> Of course it's always possible that it's something i've mis-coded.  I'm
> attaching a simple python program which returns the anomalous descriptor
> values for me.
>
> Thank you very much for all your efforts!
> --
> jeff godden
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2017.09.1 RDKit release

[Greg Landrum]

I'm pleased to announce that the next version of the RDKit -- 2017.09 -- is
released. The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2017_09_1

Binaries have been uploaded to anaconda.org (https://anaconda.org/rdkit).
The available conda binaries for this release are:
Linux 64bit: python 2.7, 3.5, 3.6
Mac OS 64bit: python 2.7, 3.5, 3.6
Windows 64bit: python 2.7, 3.5, 3.6

I left out the Win32 python2.7 build this time. If that's important to
someone, let me know and I'll see if I can get it working again.

Some notes on the conda builds:
- These builds are tested with conda v4.3.25 and, as of the release date,
are very unlikely to work with anything newer than that. This thread has
more information on that: https://www.mail-archive.com/rdkit-discuss@lists.
sourceforge.net/msg07315.html
- The conda builds now depend on numpy 1.13 instead of 1.11.
- The Mac and Linux builds now use v1.63 of boost. The rdkit conda channel
has the appropriate binaries.

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version and
new conda builds will be available in the RDKit channel at anaconda.org (
https://anaconda.org/rdkit).
- The homebrew script
- The online version of the documentation at rdkit.org

Thanks to everyone who submitted bug reports and suggestions for this
release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for March 2018.

Best Regards,
-greg

# Release_2017.09.1
(Changes relative to Release_2017.03.1)

## Important
- The fix for bug #1567 changes the way fragment SMILES are canonicalized.
  MolFragmentToSmiles() and canonicalizeFragment() will now often return
  different results
- The fix for bug #1604 changes the behavior of QueryAtom::setQuery(), which
  now deletes the current query before setting the new value. If you are
using
  QueryAtom::setQuery() from C++ (or possibly Java), be sure that you are
not
  also deleting that memory.

## Acknowledgements:
Brian Cole, Peter Gedeck, Guillaume Godin, Jan Halborg Jensen, Malitha
Kabir,
Tuomo Kalliokoski, Brian Kelley, Noel O'Boyle, Matthew O'Meara, Pavel
Polishchuk, Cameron Pye, Christian Ribeaud, Stephen Roughley, Patrick
Savery,
Roger Sayle, Nadine Schneider, Gregor Simm, Matt Swain, Paolo Tosco, Alain
Vaucher, Sam Webb, 'phenethyl', 'xiaotaw'

## Highlights:
- The new R-Group decomposition code provides a flexible and powerful tool
for
  building R-group tables or datasets look in $RDBASE/Docs/Notebooks for
  example notebooks showing how to use this.
- Drawing of chemical reactions has been greatly improved and is now done
using
  the C++ rendering code.
- The MaxMinPicker is dramatically faster.
- New descriptors: the QED descriptor has been added as have a large
collection
  of new 3D descriptors and implementations of the USR and USRCAT
fingerprints.

## New Features and Enhancements:
  - Bring back USR and USRCAT descriptors
 (github pull #1417 from greglandrum)
  - Generate a warning for conflicting bond directions
 (github issue #1423 from greglandrum)
  - expose and test GetDrawCoords()
 (github pull #1427 from greglandrum)
  - Improvement suggestions for SaltRemover
 (github issue #1431 from ribeaud)
  - Remove obsolete scripts from Scripts dir
 (github pull #1440 from greglandrum)
  - Support drawing reactions from C++
 (github pull #1444 from greglandrum)
  - QED code with unit test file
 (github pull #1445 from gedeck)
  - Add support for other datatypes to  ConvertToNumpyArray
 (github issue #1447 from pyeguy)
  - - updated FindCairo.cmake
 (github pull #1455 from ptosco)
  - - fixes PgSQL CMakeLists.txt to enable conda build on Windows
 (github pull #1457 from ptosco)
  - Some cleanups to make Travis builds faster
 (github pull #1464 from greglandrum)
  - ExplainPairScore does not support includeChirality=True
 (github issue #1466 from xiaotaw)
  - Add a collection of new 3D descriptors
 (github pull #1467 from greglandrum)
  - Update cartridge documentation to use ChEMBL 23
 (github issue #1491 from greglandrum)
  - First entry of the SubstructLibrary module
 (github pull #1493 from bp-kelley)
  - assorted fixes to get the current master branch to build on Windows
 (github pull #1495 from ptosco)
  - Support assignment of stereochemistry tags to bonds from 3D structure
 (github issue #1497 from gncs)
  - Support black and white molecule drawing
 (github issue #1510 from greglandrum)
  - Missing def_readwrite for backgroundColour in rdMolDraw2D.cpp
 (github issue #1519 from goraj)
  - Adds canonicalization of atom maps
 (github pull #1521 from bp-kelley)
  - Implement stereoisomer enumeration
 (github pull #1531 from greglandrum)
  - Add a MolBundle class
 (github pull #1537 from greglandrum)
  - Provide support for color palettes in MolDraw2D
 (github pull #1546 from greglandrum)
  - A few reaction 

Re: [Rdkit-devel] drawing amino acids

[Greg Landrum]

Hi Igor,

Could it be that you didn't generate coordinates for the molecule?

BTW: rdMolDraw2D.PrepareMolForDrawing() is a useful function to know about.

-greg


On Thu, Sep 7, 2017 at 2:16 PM, Igor Filippov 
wrote:

> Dear Colleagues,
>
> I seem to remember there already was a discussion about this,
> but I cannot find the relevant email thread, nor recall what was the
> conclusion.
>
> When I try to draw the following molecule I am getting an image of a few
> pixels in size, quite
> unusable.
>
> NC(=O)C(N)[NH3+]
>
> Has anyone else seen this problem?
>
> Best regards,
> Igor
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Adding RDKit::ROMol *s to a boost::python::list

[Greg Landrum]

It's been a while since I've seen one of these, but could it be that you
either haven't imported rdkit.Chem (in Python) before calling the function
that returns the RDKit molecule or that your extension module is linked
against a different rdkit library than the rdkit extension module that
you're using?

-greg


On Sun, Jul 16, 2017 at 4:40 PM, Paul Emsley 
wrote:

>
> Hi,
>
> I'd like to bring to python a function that returns a list (or vector?) of
> RDKit molecules. But I am lost in boost::python.
>
> BOOST_PYTHON_MODULE(pyrogen) {
>def("extract_ligands_from_coords_file", coot::extract_ligands_from_coo
> rds_file);
> }
>
> boost::python::list
> coot::extract_ligands_from_coords_file(const std::string _name) {
>
>boost::python::list rdkit_mols_list;
>std::vector mols_vec = my_get_mols(file_name);
>for(unsigned int i=0; i   rdkit_mols_list.append(mols_vec[i]);
>}
>return rdkit_mols_list;
> }
>
> When I try to use it:
>
> >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb')
> TypeError: No to_python (by-value) converter found for C++ type:
> RDKit::ROMol
>
> I am not sure what I should do (instead). At a guess, maybe I need to
> convert/wrap the mols_vec[i] before using it in append()? Please advise.
>
> Thanks,
>
> Paul.
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] travis build timeouts

[Greg Landrum]

On Tue, Jun 13, 2017 at 3:24 PM, Brian Kelley <fustiga...@gmail.com> wrote:

> I'm unsure if that staging will help, aren't the builds and tests already
> done in parallel effectively?
>

Kind of. There are currently two jobs that run in parallel:
- job 1: build the core library, the python 2.7 wrappers, and the java
wrappers and test everything
- job 2: build the core library, the python 3.5 wrappers, and the java
wrappers and test everything

Those have no dependencies on each other. I would hope that by pulling the
core library and test builds out into a separate job and then using the
artifacts (=libraries) from that for the python and java builds we could
shorten the individual jobs.

-greg




> On Tue, Jun 13, 2017 at 9:20 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
>
>> Given that the current variability is almost a factor of two I don't
>> think smaller changes are going to help.
>>
>> What I'm likely going to try is doing staged builds:
>> - stage 1: build and test core library
>> - stage 2a: build and test python 2.7 wrappers
>> - stage 2b: build and test python 3.5 wrappers
>> - stage 2c: build and test java wrappers
>>
>> the three "stage 2" things can run in parallel.
>>
>> From the bit of reading I did on the train this morning, it looks like
>> this is not that horrible to do in jenkins; just need to invest a bit of
>> time.
>>
>> -greg
>>
>>
>> On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fustiga...@gmail.com>
>> wrote:
>>
>>> I tried using ninja for the builds in stead of make, after an evening of
>>> not building I successfully had two builds:
>>>
>>> https://travis-ci.org/bp-kelley/rdkit/builds/242399233
>>>
>>> Commit:
>>>
>>> https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f6641301
>>> 1aed239413fe74da3388/.travis.yml
>>>
>>> Note that the default ninja build is #cores + 2 which blew out the
>>> memory on the VMs so I used -j3 we could try this in the makefile as well.
>>>
>>> I also think we could shave off a few minutes by
>>>
>>>   1. building in the root conda env
>>>   2. having only one conda install for *everything*
>>>
>>> If you like I can try these fixes.
>>>
>>> Cheers,
>>>   Brian
>>>
>>> On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <greg.land...@gmail.com>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> We're getting more and more timeouts with RDKit builds on travis. I'm
>>>> reasonably sure that this is due to some variability in the performance of
>>>> the VMs that the builds end up running on. A good demonstration of that is
>>>> this particular build (on a branch where I'm playing with simplifying the
>>>> travis builds), which works fine for py35 but times out for py27:
>>>> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc
>>>> e=email_medium=notification
>>>>
>>>> If you look into the details you'll see that the main compile "only"
>>>> takes 1475 seconds for the python 3.5 build but it is killed after 2541
>>>> seconds in the python2.7 build. Given that it's the same code being built,
>>>> it seems like this more or less has to be infrastructure variability.
>>>>
>>>> I'll continue to explore, particularly breaking the build into stages,
>>>> but if anyone has suggestions on how to improve this please let me know.
>>>>
>>>> -greg
>>>>
>>>>
>>>> 
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> ___
>>>> Rdkit-devel mailing list
>>>> Rdkit-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>>>
>>>>
>>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] travis build timeouts

[Greg Landrum]

Given that the current variability is almost a factor of two I don't think
smaller changes are going to help.

What I'm likely going to try is doing staged builds:
- stage 1: build and test core library
- stage 2a: build and test python 2.7 wrappers
- stage 2b: build and test python 3.5 wrappers
- stage 2c: build and test java wrappers

the three "stage 2" things can run in parallel.

>From the bit of reading I did on the train this morning, it looks like this
is not that horrible to do in jenkins; just need to invest a bit of time.

-greg


On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fustiga...@gmail.com> wrote:

> I tried using ninja for the builds in stead of make, after an evening of
> not building I successfully had two builds:
>
> https://travis-ci.org/bp-kelley/rdkit/builds/242399233
>
> Commit:
>
> https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f66413011aed239413
> fe74da3388/.travis.yml
>
> Note that the default ninja build is #cores + 2 which blew out the memory
> on the VMs so I used -j3 we could try this in the makefile as well.
>
> I also think we could shave off a few minutes by
>
>   1. building in the root conda env
>   2. having only one conda install for *everything*
>
> If you like I can try these fixes.
>
> Cheers,
>   Brian
>
> On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
>
>> Dear all,
>>
>> We're getting more and more timeouts with RDKit builds on travis. I'm
>> reasonably sure that this is due to some variability in the performance of
>> the VMs that the builds end up running on. A good demonstration of that is
>> this particular build (on a branch where I'm playing with simplifying the
>> travis builds), which works fine for py35 but times out for py27:
>> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc
>> e=email_medium=notification
>>
>> If you look into the details you'll see that the main compile "only"
>> takes 1475 seconds for the python 3.5 build but it is killed after 2541
>> seconds in the python2.7 build. Given that it's the same code being built,
>> it seems like this more or less has to be infrastructure variability.
>>
>> I'll continue to explore, particularly breaking the build into stages,
>> but if anyone has suggestions on how to improve this please let me know.
>>
>> -greg
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Rdkit-devel mailing list
>> Rdkit-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] travis build timeouts

[Greg Landrum]

Dear all,

We're getting more and more timeouts with RDKit builds on travis. I'm
reasonably sure that this is due to some variability in the performance of
the VMs that the builds end up running on. A good demonstration of that is
this particular build (on a branch where I'm playing with simplifying the
travis builds), which works fine for py35 but times out for py27:
https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_source=email_medium=notification

If you look into the details you'll see that the main compile "only" takes
1475 seconds for the python 3.5 build but it is killed after 2541 seconds
in the python2.7 build. Given that it's the same code being built, it seems
like this more or less has to be infrastructure variability.

I'll continue to explore, particularly breaking the build into stages, but
if anyone has suggestions on how to improve this please let me know.

-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] The RDKit and modern C++ (finally)

[Greg Landrum]

Dear all,

Now that the 2017_03 release cycle has started, I am *finally* ready to
start the modern C++ work that I've discussed before. Here's a blog post on
the topic:
https://medium.com/@greg.landrum_t5/the-rdkit-and-modern-c-48206b966218

To that end I created a new branch this morning:
https://github.com/rdkit/rdkit/tree/modern_cxx

This was created from the current status of the master branch using the
clang-modernize tools that are provided as part of the clang-tidy suite.
The results have been hand tweaked based on a review done on an earlier
version of this.

I want to maintain as much backwards compatibility as possible so this
isn't a "damn the torpedos" approach. My current target for legacy support
is that it should be possible to build the code under CentOS6 using gcc
4.8, which is provided by the Developer Toolset v2.1 distributed by CERN (
http://linux.web.cern.ch/linux/devtoolset/). This seems like a pretty
conservative choice given that CERN provides even more recent versions of
gcc in later Developer Toolsets.

There's still more testing to be done before I'm comfortable that this
really is stable and ready to go, but I've been able to do at least basic
builds and tests on Linux (Ubuntu 16.04 and Centos 6 using g++-4.8), macOS,
and Windows, so I think we're off to a good start.

As always, I'm happy to hear feedback, positive or negative, on this as
well as suggestions on better ways to proceed.

I'm really looking forward to finally getting to use (at least some of) the
new features that modern C++ brings.

Best,
-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2017.03 (Q1 2017) RDKit Release

[Greg Landrum]

I'm pleased to announce that the next version of the RDKit -- 2017.03
(a.k.a. Q1 2017) -- is released. The release notes are below.

The release files are on the github release page:
*https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1
*

We are in the process of updating the conda build scripts to reflect the
new version and uploading the binaries to anaconda.org (https://anaconda
.org/rdkit).
The plan for conda binaries for this release is:
Linux 64bit: python 2.7, 3.5, 3.6
Mac OS 64bit: python 2.7, 3.5, 3.6
Windows 64bit: python 2.7, 3.5, 3.6
Windows 32bit: python 2.7

Some things that will be finished over the next couple of days:
- The conda build scripts will be updated to reflect the new version and
new conda builds will be available in the RDKit channel at anaconda.org (
https://anaconda.org/rdkit).
- The homebrew script
- The online version of the documentation at rdkit.org

Thanks to everyone who submitted bug reports and suggestions for this
release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for September 2017.

Best Regards,
-greg

# Release_2017.03.1
(Changes relative to Release_2016.09.1)

## Important
- The fix for bug #879 changes the definition of the layered fingerprint.
  This means that all database columns using layered fingerprints as well as
  all substructure search indices should be rebuilt.
- All C++ library names now start with RDKit (see #1349).

## Acknowledgements:
Brian Cole, David Cosgrove, JW Feng, Berend Huisman, Peter Gedeck, 'i-tub',
Jan Holst Jensen, Brian Kelley, Rich Lewis, Brian Mack, Eloy Felix
Manzanares,
Stephen Roughley, Roger Sayle, Nadine Schneider, Gregor Simm, Matt Swain,
Paolo Tosco, Riccardo Vianello, Hsiao Yi

## Highlights:
  - It's now possible (though not the default) to pickle molecule properties
  with the molecule
  - There's a new, and still in development, "Getting started in C++"
document.
  - A lot of the Python code has been cleaned up

## New Features and Enhancements:
  - Add removeHs option to MolFromSmiles()
 (github issue #554 from greglandrum)
  - support a fixed bond length in the MolDraw2D code
 (github issue #565 from greglandrum)
  - Pattern fingerprint should set bits for single-atom fragments.
 (github issue #879 from greglandrum)
  - Reviewed unit tests of rdkit.ML - coverage now 63.1%
 (github pull #1148 from gedeck)
  - Reviewed unit tests of rdkit.VLib - coverage now 67.1%
 (github pull #1149 from gedeck)
  - Removes exponetial numBonds behavior
 (github pull #1154 from bp-kelley)
  - Exposes normalize option to GetFlattenedFunctionalGroupHierarchy
 (github pull #1165 from bp-kelley)
  - Expose RWMol.ReplaceBond to Python
 (github pull #1174 from coleb)
  - Review of rdkit.Chem.Fraggle code
 (github pull #1184 from gedeck)
  - Add support for dative bonds.
 (github pull #1190 from janholstjensen)
  - Python 3 compatibility (issue #398)
 (github pull #1192 from gedeck)
  - 1194: Review assignments of range in Python code
 (github pull #1195 from gedeck)
  - Moved GenerateDepictionMatching[23]DStructure from Allchem.py to C++
 (github pull #1197 from DavidACosgrove)
  - Review rdkit.Chem.pharm#D modules
 (github pull #1201 from gedeck)
  - Find potential stereo bonds should return any
 (github pull #1202 from coleb)
  - Gedeck coverage sim div filters
 (github pull #1208 from gedeck)
  - Gedeck review unit test inchi
 (github pull #1209 from gedeck)
  - Coverage rdkit.Dbase
 (github pull #1210 from gedeck)
  - Coverage rdkit.DataStructs
 (github pull #1211 from gedeck)
  - UnitTestPandas works on Python3
 (github pull #1213 from gedeck)
  - Cleanup and improvement to test coverage of PandasTools
 (github pull #1215 from gedeck)
  - Cleanup of rdkit.Chem.Fingerprints
 (github pull #1217 from gedeck)
  - Optimization of UFF and MMFF forcefields
 (github pull #1218 from ptosco)
  - Support for ChemAxon Extended SMILES/SMARTS
 (github issue #1226 from greglandrum)
  - Improved test coverage for rdkit.Chem.Fingerprints
 (github pull #1243 from gedeck)
  - Adding a few tests for coverage utils
 (github pull #1244 from gedeck)
  - Make Pandastools modifications to generic RDkit functionality more
obvious
 (github pull #1245 from gedeck)
  - Rename test file and cleanup
 (github pull #1246 from gedeck)
  - Review of rdkit.Chem.MolKey
 (github pull #1247 from gedeck)
  - Review tests in rdkit.Chem.SimpleEnum
 (github pull #1248 from gedeck)
  - Move execution of DocTests in rdkit.Chem into a UnitTest file
 (github pull #1256 from gedeck)
  - Review code in rdkit.Chem.Suppliers
 (github pull #1258 from gedeck)
  - Add python wraps
 (github pull #1259 from eloyfelix)
  - Rename file UnitTestDocTests in rdkitChem
 (github pull #1263 from gedeck)
  - Gedeck rdkit chem unit test surf
 (github pull #1267 from gedeck)
  - cleanup rdkit.Chem.Lipinski and rdkit.Chem.GraphDescriptors
 (github pull 

[Rdkit-devel] Beta of Q1 2017 release now up

[Greg Landrum]

[apologies for the date of this... it's not an April Fools joke]
Dear all,

I have tagged a beta of the next RDKit release here:
https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1b1

The release notes are on the release page linked above. Note that the list
of people in the acknowledgement section was mostly created automatically
from github. If you feel like I missed you, or if I got your name wrong,
please let me know so that I can update the release notes before the actual
release.

To make testing easier, I've done conda builds for 64bit linux (python 3.5
and python 2.7) and windows (just python v3.5 for the beta, there were some
problems with the python 2.7 build that will be fixed for the release).
Since this is still a beta, I've labelled them "testing", so you need to
install them like this:
conda install -c rdkit/label/testing rdkit

Unless major problems are found, I plan to do the actual release in 2-3
weeks. I'm going to be travelling for the next couple of weeks so the usual
beta period is a bit longer. Between now and then I hope to get another bug
or two fixed but this should otherwise be it for features..

Best,
-greg
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] InChI 1.05

[Greg Landrum]

Thanks Igor! I was not looking forward to getting this working, so it's
great that someone else managed to.

I need to do a bit more tweaking in order to get the download to work using
the cmake code instead of the download_inchi.sh script, but I should be
done with that pretty quickly.

I'll have a branch up for review soon (assuming that nothing goes wrong)

-greg


On Thu, Feb 23, 2017 at 4:55 AM, Igor Filippov 
wrote:

> As InChI 1.05 is officially out I've tinkered with RDKit build system a bit
> to include the new version. Two updated files - CMakeLists.txt   and
> download-inchi.sh
> from External/INCHI-API/ are attached in case it may be useful to others.
>
> Best regards,
> Igor
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit Python wrappers

[Greg Landrum]

My two cents:- Brian got the big one: boost allows you to produce pythonic 
bindings and, as long as you're doing them at the same time you are writing the 
original code it's not that big of a deal to write the wrappers by hand.- Back 
when I started this SWIG was a complete disaster in terms of how it handled C++ 
code.- the documentation is, IMO, much better than the SWIG documentation the 
moment you need to do anything that isn't fairly trivial. 
Neither is simple (the task itself is complex), but I still think that boost is 
the right choice for the RDKit





On Thu, Dec 1, 2016 at 7:09 PM +0100, "Brian Kelley"  
wrote:










I expect the technical reason is that the boost wrapping was done well in 
advance of the swig.

Having used both, I think that boost wrappers are far more pythonic, compile 
faster, do docstrings better and finally handle exceptions between c++ and 
Python far better.

The downside is that when you get a compile error, it is several pages long.

While doing the same is possible in swig, it would require a serious rewriting 
that is one whole bunch of "not fun".

Brian Kelley

> On Dec 1, 2016, at 12:39 PM, David Cosgrove  wrote:
> 
> Hi All,
> 
> Having failed miserably to understand boost::python last week when trying to 
> add some new functions, I am wondering if there's a technical reason to 
> prefer it over swig?  Given there are swig wrappings for java and c#, it 
> feels logical to do the python wrapping that way as well. It would remove 
> some complexity from the maintenance, perhaps.  OTOH, if the end result isn't 
> as good, then that wouldn't be worth it, and I'll just have to try harder 
> with boost::python.
> 
> Cheers,
> Dave
> 
> --
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

--
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel





--
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit Python wrappers

[Greg Landrum]

You can always just ask...






On Thu, Dec 1, 2016 at 9:14 PM +0100, "David Cosgrove" 
 wrote:










Ok, I'm convinced. I assumed there was probably a good reason, but sometimes 
it's worth asking the question just in case. I'm not anti boost, but, as with 
many of their libraries I have looked at, I found the documentation 
impenetrable at first reading. I will persevere. 

Cheers,
Dave

On Thu, 1 Dec 2016 at 20:03, Maciek Wójcikowski  wrote:
One big thing on pros side: boost::python supports serialization natively, and 
SWIG does not.

Pozdrawiam,  |  Best regards,
Maciek Wójcikowski
mac...@wojcikowski.pl


2016-12-01 20:46 GMT+01:00 Gianluca Sforna :
On Thu, Dec 1, 2016 at 7:09 PM, Brian Kelley  wrote:

> Having used both, I think that boost wrappers are far more pythonic, compile 
> faster, do docstrings better and finally handle exceptions between c++ and 
> Python far better.

>

> The downside is that when you get a compile error, it is several pages long.



While we are at this, I stumbled few days ago on this project:



https://github.com/pybind/pybind11



That claims to work mostly like boost::python, just without the boost part.



If we were to try removing the boost dependency, I think it could be useful.


--

___

Rdkit-devel mailing list

Rdkit-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/rdkit-devel


--

___

Rdkit-devel mailing list

Rdkit-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/rdkit-devel







--
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Boost and cmake version survey

[Greg Landrum]

Well, that answers at least part of the question. I certainly am interested in 
having you able to do the builds for centos and rhel.



_
From: Gianluca Sforna <gia...@gmail.com>
Sent: Wednesday, November 9, 2016 12:36 PM
Subject: Re: [Rdkit-devel] Boost and cmake version survey
To: Greg Landrum <greg.land...@gmail.com>
Cc: RDKit Developers List <rdkit-devel@lists.sourceforge.net>


On Wed, Nov 9, 2016 at 11:41 AM, Greg Landrum <greg.land...@gmail.com> wrote:

> This decision shouldn't matter to most users since they will be getting
> pre-built binaries either via their OS's package manager or conda.

If you want to make it easy on people with RHEL/CentOS 7, they have in
the repos cmake 2.8 and boost 1.53 (and, for that matter, gcc 4.8.5)

If requirements are beyond this, it is not possible to build rdkit for
EPEL (one thing I have in my TODO); of course, interested parties may
still build it for themselves, but not without additional pain...


-- 
Gianluca Sforna

http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2016.03 (Q1 2016) RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit -- 2016.03
(a.k.a. Q1 2016) -- is released.

The release notes are below.

The release and binary files are on the github release page:
*https://github.com/rdkit/rdkit/releases/tag/Release_2016_03_1
*
Unless there's serious demand for it, I do not plan to duplicate these on
the sourceforge download page.

I have uploaded 32-bit and 64-bit Windows binaries for Python 2.7 along
with 32-bit and 64-bit Windows binaries for Java.

Gianluca's binary RPMs for Fedora 20, 21 and RHEL/Centos 6, 7 will be
available from
this repository:
https://copr.fedoraproject.org/coprs/giallu/rdkit/

The conda build scripts have been updated to reflect the new version and
new conda builds are mostly available in the RDKit channel at anaconda.org (
https://anaconda.org/rdkit). We're still working on the python2.7 build.

The homebrew recipe is currently broken, but I'm working on that.

The online version of the documentation at rdkit.org will be updated today.

Thanks to the everyone who submitted bug reports and suggestions for this
release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for September 2016.

Best Regards,
-greg

# Release_2016.03.1
(Changes relative to Release_2015.09.2)

## Important
In order to build the RDKit, it is now necessary to have at least v1.7 of
numpy installed.

## Acknowledgements:
Note: The RDKit has the wonderful "problem" that there are a lot of
contributors and it's tough for me to capture them all to put together
release
notes. I don't even know many of the contributors (which is *awesome!*)
The names here come largely from what I pull in an automated way from
github.
In cases where there's no real name listed in github, I either guessed
or used just the github alias in quotes. If I got it wrong, please let me
know!

Josep Arus, Nik Bates-Haus, Andrew Dalke, 'DoliathGavid', 'elcaceres', Peter
Gedeck, James Jeffryes, Brian Kelley, Juuso Lehtivarjo, Rich Lewis, Daniel
Lowe,
'maddogcz', Kozo Nishida, Michal Nowotka, Axel Pahl, Steven Roughley,
Alexander
Savelyev, Nadine Schneider, Gianluca Sforna, Teague Sterling, Nik Stiefl,
Matt
Swain, Eric Ting, Paolo Tosco, Samo Turk, Riccardo Vianello

## Highlights:
- Improvements to the build system: it's now much easier to build with InChI
  and/or Avalon support since cmake now knows how to fetch the appropriate
  source code for you. Building the PostgreSQL cartridge is now integrated
into
  normal build process.
- Some improvements to molecule rendering and Jupyter notebook integration:
The
  new `Draw.PrepareMolForDrawing()` function takes care of standard tasks
like
  wedging bonds, kekulization, and adding chiral Hs.
`Draw.MolsToGridImage()`
  can generate SVGs and uses the new molecular drawing code for PNGs when
  possible. The Jupyter notebook integration uses the new drawing code when
  possible.
- Error and warning messages from the C++ core can now be displayed in the
  Jupyter notebook

## Bug Fixes:
  - Sanitizer rejects higher valency halides
 (github issue #115 from dan2097)
  - Bad E/Z assignment from ctab
 (github issue #188 from greglandrum)
  - bad E/Z assignment from ctab
 (github issue #192 from greglandrum)
  - Documentation is still python2 specific.
 (github issue #374 from greglandrum)
  - SVG export - Python 3 support
 (github issue #398 from maddogcz)
  - FragmentOnBonds() producing incorrect chirality
 (github issue #511 from greglandrum)
  - Rings containing all dummy atoms with single bonds are flagged as
aromatic
 (github issue #518 from greglandrum)
  - IPython integration broken with latest Jupyter
 (github issue #666 from samoturk)
  - Added missing include/forward declarations
 (github pull #668 from ptosco)
  - Fixes a memory leak in fragmentMol
 (github pull #669 from bp-kelley)
  - resetVect option being ignored by reaccsToFingerprint()
 (github issue #671 from greglandrum)
  - failure in AddHs when addCoords is true and coords are all zero
 (github issue #678 from greglandrum)
  - 404 error for the link to Installation instructions
 (github issue #679 from EricTing)
  - Fix java8 build
 (github pull #681 from greglandrum)
  - Smiles containing "[as]" do not parse.
 (github issue #682 from greglandrum)
  - SMARTS reaction triggers invariant violation on chiral compounds
 (github issue #685 from JamesJeffryes)
  - partially specified chiral substructure queries don't work properly
 (github issue #688 from bp-kelley)
  - ExactMolWt ignoring the mass of the electron
 (github issue #694 from greglandrum)
  - Bad 1-4 bounds matrix elements in highly constrained system
 (github issue #696 from greglandrum)
  - More ChEMBL molecules that fail bounds smoothing
 (github issue #697 from greglandrum)
  - Molecule serialization doesn't read/write atomic numbers above 128
 (github issue #713 from greglandrum)
  - AddHs cip rank 

Re: [Rdkit-devel] More build fun with RHEL 6

[Greg Landrum]

On Fri, Apr 15, 2016 at 1:18 PM, Gianluca Sforna <gia...@gmail.com> wrote:

> On Fri, Apr 15, 2016 at 11:20 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
> > The problem here is that the rdkit doesn't really support Python 2.6
> > anymore. I don't remember at the moment which pieces we used, but there
> are
> > 2.7+ bits in there
>
> Then I guess the Software Collections approach mentioned by Riccardo
> is best, so I can pick up an updated dep.
>

That would be excellent if it's possible


> By the way, the build succeeded except for the cartridge, apparently
> the makefile is broken for older versions (8.x);


Correct, support for 8.x was removed with the 2015_09 release.

Would you be comfortable with me doing the release based on the current
state of the code (once that PR is merged, of course)?

-greg
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] More build fun with RHEL 6

[Greg Landrum]

On Friday, 15 April 2016, Gianluca Sforna <gia...@gmail.com> wrote:

> On Fri, Apr 15, 2016 at 4:41 AM, Greg Landrum <greg.land...@gmail.com
> <javascript:;>> wrote:
> > Now that I have a Centos6 box available, I'm realizing that it has python
> > 2.6
> > Are you also installing Python 2.7 on those machines when you build the
> > RDKit?
>
> No, there are a few methods for getting 2.7 as RPMs, but the deafult
> build sticks to what Red Hat provides in the repo.
>
>

The problem here is that the rdkit doesn't really support Python 2.6
anymore. I don't remember at the moment which pieces we used, but there are
2.7+ bits in there

-greg
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] More build fun with RHEL 6

[Greg Landrum]

This PR: https://github.com/rdkit/rdkit/pull/864
has a version that builds a python wrapper for me on Centos6 with python2.7
installed manually.

FWIW, I've attached the bootstrap.sh that I used to configure the vagrant
box (clearly still a work in progress: it doesn't bring in the requirements
for the java wrappers or postgreSQL yet).

-greg


On Fri, Apr 15, 2016 at 4:41 AM, Greg Landrum <greg.land...@gmail.com>
wrote:

> Now that I have a Centos6 box available, I'm realizing that it has python
> 2.6
> Are you also installing Python 2.7 on those machines when you build the
> RDKit?
>
> On Thu, Apr 14, 2016 at 12:18 PM, Gianluca Sforna <gia...@gmail.com>
> wrote:
>
>> For the records, Build with RHEL/CentOS 7 succeded, this leaves us
>> with only one platform where it fails; if we think the older boost
>> version cannot be supported, I can just stick to an older release for
>> EL6
>>
>> On Thu, Apr 14, 2016 at 11:47 AM, Gianluca Sforna <gia...@gmail.com>
>> wrote:
>> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum <greg.land...@gmail.com>
>> wrote:
>> >> Which version of boost are you using?
>> >
>> > RPMs are built against the packages in the repositories (stock+updates).
>> >
>> > Right now it means 1.41.0 for RHEL6, 1.53 for RHEL 7 (building now,
>> > will let you know how it goes)
>>
>>
>>
>> --
>> Gianluca Sforna
>>
>> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>> Tinker Garage - http://tinkergarage.it
>>
>
>


bootstrap.sh
Description: Bourne shell script
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] More build fun with RHEL 6

[Greg Landrum]

Now that I have a Centos6 box available, I'm realizing that it has python
2.6
Are you also installing Python 2.7 on those machines when you build the
RDKit?

On Thu, Apr 14, 2016 at 12:18 PM, Gianluca Sforna <gia...@gmail.com> wrote:

> For the records, Build with RHEL/CentOS 7 succeded, this leaves us
> with only one platform where it fails; if we think the older boost
> version cannot be supported, I can just stick to an older release for
> EL6
>
> On Thu, Apr 14, 2016 at 11:47 AM, Gianluca Sforna <gia...@gmail.com>
> wrote:
> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
> >> Which version of boost are you using?
> >
> > RPMs are built against the packages in the repositories (stock+updates).
> >
> > Right now it means 1.41.0 for RHEL6, 1.53 for RHEL 7 (building now,
> > will let you know how it goes)
>
>
>
> --
> Gianluca Sforna
>
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
> Tinker Garage - http://tinkergarage.it
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] More build fun with RHEL 6

[Greg Landrum]

That'd be awesome.. thanks. :-)

On Thu, Apr 14, 2016 at 1:44 PM, Brian Kelley <fustiga...@gmail.com> wrote:

> The fix is buried here:
>
> https://github.com/rdkit/rdkit/pull/677/files
>
> It is in the BOOST_PYTHON_SUPPORT_SHARED_CONST
>
> The reason we didn't merge is was the problem with the exported defines,
> however I can tie it into the boost version in the FilterCatalog header
> file.  We had initially thought this only affected RHEL5 so it was a lower
> priority, I can have a PR by the end of the day (maybe even the Basel day :)
>
>
>
> On Thu, Apr 14, 2016 at 7:01 AM, Greg Landrum <greg.land...@gmail.com>
> wrote:
>
>> Under any circumstances: if we only support more recent versions we
>> should indicate that in the CMakeLists.txt, which claims to support back to
>> boost 1.39 with python2 and 1.45 with python3.
>>
>> I will take a look
>>
>> On Thu, Apr 14, 2016 at 12:58 PM, Brian Kelley <fustiga...@gmail.com>
>> wrote:
>>
>>> I think I have seen this before in FilterCatalog, I can try to patch it
>>> for boost 1.41 but I will say that version of boost is getting pretty long
>>> in the tooth.
>>>
>>> 
>>> Brian Kelley
>>>
>>> On Apr 14, 2016, at 6:43 AM, Greg Landrum <greg.land...@gmail.com>
>>> wrote:
>>>
>>> I'd like to have it work on EL6; that's still pretty common.
>>> I will make some time to investigate either this evening or tomorrow.
>>>
>>> Thanks for narrowing it down so much.
>>> -greg
>>>
>>>
>>> On Thu, Apr 14, 2016 at 12:18 PM, Gianluca Sforna <gia...@gmail.com>
>>> wrote:
>>>
>>>> For the records, Build with RHEL/CentOS 7 succeded, this leaves us
>>>> with only one platform where it fails; if we think the older boost
>>>> version cannot be supported, I can just stick to an older release for
>>>> EL6
>>>>
>>>> On Thu, Apr 14, 2016 at 11:47 AM, Gianluca Sforna <gia...@gmail.com>
>>>> wrote:
>>>> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum <
>>>> greg.land...@gmail.com> wrote:
>>>> >> Which version of boost are you using?
>>>> >
>>>> > RPMs are built against the packages in the repositories
>>>> (stock+updates).
>>>> >
>>>> > Right now it means 1.41.0 for RHEL6, 1.53 for RHEL 7 (building now,
>>>> > will let you know how it goes)
>>>>
>>>>
>>>>
>>>> --
>>>> Gianluca Sforna
>>>>
>>>> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>>>> Tinker Garage - http://tinkergarage.it
>>>>
>>>
>>>
>>> --
>>> Find and fix application performance issues faster with Applications
>>> Manager
>>> Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> your business applications. It resolves application problems quickly and
>>> reduces your MTTR. Get your free trial!
>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>>
>>> ___
>>> Rdkit-devel mailing list
>>> Rdkit-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>>
>>>
>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] last test failing with python3

[Greg Landrum]

Hi Gianluca,

It looks like that function is not available with pycairo for Python3:
http://cairographics.org/documentation/pycairo/3/reference/surfaces.html#cairo.ImageSurface.create_for_data
It is (or should be) available in cairocffi:
https://pythonhosted.org/cairocffi/api.html#cairocffi.ImageSurface.create_for_data

If both pycairo and cairocffi are installed, the code will prefer cairocffi
with python3.

-greg


On Thu, Dec 3, 2015 at 4:13 PM, Gianluca Sforna  wrote:

> Hi all,
> my attempt to build and test python3 bindings in the rpm package is
> one tiny test away from success...
>
> Specifically, I see test 101 fails with:
>
> 101: ==
> 101: ERROR: testCairoImage (__main__.TestCase)
> 101: --
> 101: Traceback (most recent call last):
> 101:   File "UnitTestDraw.py", line 91, in testCairoImage
> 101: img=Draw.MolToImage(self.mol,size=(300,300))
> 101:   File
> "/builddir/build/BUILD/rdkit-Release_2015_09_2/python3/rdkit/Chem/Draw/__init__.py",
> line 94, in MolToImage
> 101: img,canvas=_createCanvas(size)
> 101:   File
> "/builddir/build/BUILD/rdkit-Release_2015_09_2/python3/rdkit/Chem/Draw/__init__.py",
> line 50, in _createCanvas
> 101: canvas = Canvas(img)
> 101:   File
> "/builddir/build/BUILD/rdkit-Release_2015_09_2/python3/rdkit/Chem/Draw/cairoCanvas.py",
> line 86, in __init__
> 101: image.size[0], image.size[1], stride)
> 101: NotImplementedError: Surface.create_for_data: Not Implemented yet.
>
> Any idea how this could happen? If you need any additional info, just
> let me know
>
>
> --
> Gianluca Sforna
>
> http://morefedora.blogspot.com
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911=/4140___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] seg faults running tests on a mac

[Greg Landrum]

Hi Cyrus,

I'm glad you were able to find something that works. If I had to guess, I
would say that the root cause of all of this was the homebrew version of
python confusing things.

-greg

On Sat, May 16, 2015 at 7:27 PM, Cyrus Harmon cyrushar...@gmail.com wrote:

 Ok, I think I've solved (or at least worked around) my python woes. The
 following seems to do the trick:

 export RDBASE=/Users/sly/projects/rdkit
 export PYTHONPATH=/usr/local/:${RDBASE}:
 export
 DYLD_LIBRARY_PATH=/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources:${RDBASE}/lib:/usr/local/lib:

 # running cmake:
 cmake \
   -D PYTHON_EXECUTABLE=/usr/local/bin/python \
   -D
 PYTHON_INCLUDE_DIR=/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Headers
 \
   -D
 PYTHON_LIBRARY=/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
 \
   ..

 # build it
 make -j4

 # install
 make install

 # test
 ctest



 Now onto the next problem...


 On Sat, May 16, 2015 at 3:20 PM, Cyrus Harmon cyrushar...@gmail.com
 wrote:

 Following up on my own message...

 I noticed that the python executable and python libraries found by cmake
 don't match. cmake finds the homebrew installed python binary, but the
 system installed libraries.

 If I remove the homebrew python I can at least get the tests to pass (but
 run into problems with various other missing python packages).  A step in
 the right direction.

 On Sat, May 16, 2015 at 10:11 AM, Cyrus Harmon cyrushar...@gmail.com
 wrote:

 Hi Greg,

 Sorry it's been a while since I first reported my troubles on a Mac. I
 continue to have problems on my MacBook Pro, but things seem to work fine
 on linux for me.

 The problem is that many of the tests fail with a segfault and there
 doesn't seem to much information in any of the log files about the problem.
 In an effort to figure out what's going on here, I've been trying to run
 things under gdb.

 If I run the testBV.py test under gdb I see the following:

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x
 0x0001029e7cb9 in PyInt_FromLong ()
 (gdb) bt
 #0  0x0001029e7cb9 in PyInt_FromLong ()
 #1  0x000102844908 in
 boost::python::detail::keywords1ul::operator=int ()
 #2  0x00010284277a in init_module_rdBase ()
 #3  0x000102b2f391 in boost::python::handle_exception_impl ()
 #4  0x000102b303b9 in boost::python::detail::init_module ()
 #5  0x0001000a04ea in _PyImport_LoadDynamicModule ()
 #6  0x0001000a01d2 in import_submodule ()
 #7  0x00010009fd9c in load_next ()
 #8  0x00010009df99 in PyImport_ImportModuleLevel ()
 #9  0x000100083459 in builtin___import__ ()
 #10 0x0001e3b6 in PyObject_Call ()
 #11 0x00010008dd9b in PyEval_CallObjectWithKeywords ()
 #12 0x00010008a0b7 in PyEval_EvalFrameEx ()
 #13 0x000100087df9 in PyEval_EvalCodeEx ()
 #14 0x00010008786f in PyEval_EvalCode ()
 #15 0x00010009ca46 in PyImport_ExecCodeModuleEx ()
 #16 0x00010009f731 in load_source_module ()
 #17 0x00010009f9f2 in load_package ()
 #18 0x0001000a01d2 in import_submodule ()
 #19 0x00010009fd9c in load_next ()
 #20 0x00010009df99 in PyImport_ImportModuleLevel ()
 #21 0x000100083459 in builtin___import__ ()
 #22 0x0001e3b6 in PyObject_Call ()
 #23 0x00010008dd9b in PyEval_CallObjectWithKeywords ()
 #24 0x00010008a0b7 in PyEval_EvalFrameEx ()
 #25 0x000100087df9 in PyEval_EvalCodeEx ()
 #26 0x00010008786f in PyEval_EvalCode ()
 #27 0x0001000a7a2a in run_mod ()
 #28 0x0001000a7acd in PyRun_FileExFlags ()
 #29 0x0001000a766a in PyRun_SimpleFileExFlags ()
 #30 0x0001000b8d6f in Py_Main ()
 #31 0x7fff947ec5c9 in start ()

 So it looks to me like things are sort of working for a while, but that
 somewhere along the line I'm getting a segfault, which may in turn be
 triggered by a problem loading a dylib.

 I'm guessing that part of the problem is that there are a lot of moving
 parts here:

 1. RDKIT -- I'm using the latest git head as of today
 2. Python
  a. version 2 or version 3?
- I'm trying to get things working with python2, but python3 would be
 nice at some point
  b. system installed, hombrew, or self-installed?
- I'm trying to use the homebrew-installed python2. Perhaps this is a
 mistake.
 3. Python libraries (installed via pip)
 4. Homebrew libraries
 5. System libraries
 6. Environment variables
 7. etc...

 What a mess...

 speaking of environment variables, one thing that might be problematic
 for me is that I am trying to use the following environment variables:

 export PYTHONPATH=/Users/sly/projects/rdkit/
 export RDBASE=/Users/sly/projects/rdkit/
 export
 DYLD_LIBRARY_PATH=/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources:/Users/sly/projects/rdkit/lib:/usr/local/lib:

 If I don't add the system ImageIO path, cmake fails with:

 dyld: Symbol not found: 

[Rdkit-devel] The RDKit and modern C++

[Greg Landrum]

Dear all,

I would like to start allowing the use of modern C++ (by which I mean C++
11/14) in the RDKit. I think this is an important step both for code
quality in the toolkit itself and for allowing us (the developers) to
continue to learn and use modern tools. Who knows, it may even help with
performance. :-)

This move would, of course, break compatibility with some older compilers.
Here's one view of compiler support for C++11 and some of C++14:
http://en.cppreference.com/w/cpp/compiler_support

It looks like g++ 4.8+ and VC++ 2013 are both fine with most/all C++11
features.
VC++ 2015 does even better and g++5 is very solid. Clang, which is the
default on the Mac and available for both windows and linux, has great
support.

The thing I am most concerned about is that RHEL6 only includes g++ 4.4.
RHEL7 is fine, but I would guess that most large organizations aren't that
up-to-date yet. I know of at least one (ahem) that is hasn't even finished
the move to RHEL6. It looks like an enterprise alternative here is to use
the RedHat Developer Toolset, but I don't have personal experience with
that yet. Clang is always an option, but it something people will have to
install on their own.

Here's how I would propose that we proceed:
 - If no fundamental objections come up here, we'll create a document
listing the C++ features that should not be used (yet) due to compiler
compatibility. We'll also agree on a new baseline version of Boost that can
be assumed to be present.
 - I will create a compatibility branch based on the current master. Bug
fixes will be ported back onto this branch for the next release or two, but
new features will not be added.
 - We can start using modern C++ on master.

Best,
-greg
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Beta of Q1 2015 release now up

[Greg Landrum]

Dear all,

I have tagged a beta of the next RDKit release here:
https://github.com/rdkit/rdkit/releases/tag/2014_09_1beta1

The relevant section of the release notes is below.

I will try to get windows binaries up in the next few days.

Unless major problems are found, I plan to do the actual release in about
two weeks.

Best,
-greg

**  Release_2015.03.1 ***
(Changes relative to Release_2014.09.2)

!! IMPORTANT !!

 - This release has a new algorithm for canonical atom ordering. This
   means that canonical SMILES generated with the new version will be
   different from those generated with previous versions.

Acknowledgements:
David Cosgrove, Andrew Dalke, JP Ebejer, Niko Fechner, Igor Filippov,
Patrick Fuller, David Hall, J Bach Hardie, Jan Holst Jensen, Brian
Kelley, Rich Lewis, John May, Sereina Riniker, Alexander Savelyev,
Roger Sayle, Nadine Schneider, Paolo Tosco, Samo Turk, JL Varjo,
Riccardo Vianello

Highlights:

  - A new algorithm for generating canonical atom orders. The new
algorithm is faster and more robust than the old one.
  - C++-based molecule drawing code, allows consistent molecule
renderings from C++, Java, and Python. This will become the
default renderer in the next release.
  - General performance improvements and reduction of memory usage.
  - Torsion Fingerprints for comparing 3D conformations to each other
  - MCS code now available from the PostgreSQL cartridge

Bug Fixes:

  - fmcs: use the zero bond type instead of other
(github issue #368 from AlexanderSavelyev)
  - bug fixed in TorsionFingerprints.GetTFDMatrix
(github issue #376 from sriniker)
  - rdkit.Chem.MolDb.Loader_sa does not work with python3.4
(github issue #390)
  - ChemReactions: Bugfix/Memleak-fix in runReactants
(github issue #394 from NadineSchneider)
  - TorsionConstraint bug fix
(github issue #395 from ptosco)
  - Fixed LoadSDF to keep 3D info
(github pull #401 from samoturk)
  - Incorrect expected absolute stereochemistries in a test
(github issue #407)
  - GetSubstructMatches() consumes all available memory
(github issue #409)
  - Bugfix in the chirality handling of chemical reactions
(github pull #410 from NadineSchneider)
  - fixed two minor bugs in MMFF code
(github issue #416 from ptosco)
  - Varied sanitise rejection with hydrogen representation
(github issue #418)
  - Fixed two trivial bugs
(github issue #419 from ptosco)
  - RDKit learns how to roundtrip MOLFile values.
(github issue #420 from bp-kelley)
  - cairoCanvas.py python3 compatibility
(github issue #426 from bach-hardie)
  - Chem.FragmentOnSomeBonds() should update implicit H count on aromatic
heteroatoms when  addDummies is False
(github issue #429)
  - Chem.FragmentOnSomeBonds() crashes if the bond list is empty
(github issue #430)
  - Increase limit for smallest ring size
(github issue #431 from cowsandmilk)
  - Problems caused by heteroatoms with radicals in aromatic rings.
(github issue #432)
  - Metals in mol2 blocks handled incorrectly
(github issue #438)
  - Fixed a few tests failing when the Windows git client is used
(github pull #439 from ptosco)
  - Fixed tests failing on Windows when retrieving sources through the
 Windows git client
(github pull #440 from ptosco)
  - Conformers not copied correctly in renumberAtoms
(github issue #441)
  - Radicals are not correctly assigned when reading from SMILES
(github issue #447)
  - moving RDBoost/Exceptions.h to RDGeneral
(github pull #458 from rvianello)
  - Add code to accept blank SMILES input.
(github issue #468 from janholstjensen)
  - Accept empty SMILES and SMARTS
(github issue #470)
  - Fix MolFile Atom Line List Writer
(github issue #471 from bp-kelley)
  - Moved 3D ipython renderer to dependency
(github pull #472 from patrickfuller)
  - Windows build/test failure fixes
(github issue #473 from ptosco)

New Features:

  - Isomeric fix in PandasTools
(github issue #369 from samoturk)
  - added SaveXlsxFromFrame - first version
(github issue #371 from samoturk)
  - New feature: Torsion fingerprints
(github issue #372 from sriniker)
  - Add function to extract a molecule with a single (particular) conformer
from a multiconf mol
(github issue #384)
  - Added C++ and Python helpers to retrieve force-field parameters
(github issue #387 from ptosco)
  - Support providing all options to SWIG-wrapped FMCS
(github issue #397)
  - Add function to request if calling UpdatePropertyCache is necessary
(github issue #399)
  - Add function to test if UpdatePropertyCache is necessary
(github issue #400 from NadineSchneider)
  - Substructure highlighting in pandas dataframe (fixes #362)
(github issue #403 from nhfechner)
  - Added SDF Export to PandasTools and adjusted SDF Import
(github issue #404 from nhfechner)
  - support count-based avalon fingerprint
(github issue #408)
  - New C++ drawing code

[Rdkit-devel] 2014.03 (Q1 2014) RDKit release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit -- 2014.03
(a.k.a Q1 2014) -- is released. This is a bit late, but it turned out
that it takes longer to get a 6-month release together than it did a
3-month release. Who ever would have anticipated that? ;-)

The release notes are below.

The release and binary files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2014_03_1
as well as the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q1_2014/

I have uploaded 32-bit and 64-bit Windows binaries for Python 2.7 and, in
response to a couple of requests, 32-bit and 64-bit Windows binaries for
Java.

The online version of the documentation at rdkit.org has been updated.

Thanks to the everyone who submitted bug reports and suggestions for this
release!

Please let me know if you find any problems with the release or have
suggestions for the next one, which is scheduled for September 2014.

Best Regards,
-greg

**  Release_2014.03.1 ***
(Changes relative to Release_2013.09.2)

!! IMPORTANT !!
 - Due to a bug fix in the rotatable bonds definition, the default
   rotatable bond calculation returns different values than before.
   This also affects MQN descriptor #18.

Acknowledgements:
Paul Czodrowski, James Davidson, Markus Elfring, Nikolas Fechner, Jan Holst
Jensen, Christos Kannas, Sereina Riniker, Roger Sayle, Paolo Tosco, Samo
Turk, Riccardo Vianello, Maciej Wójcikowski, Toby Wright

Bug Fixes:
- Dict::DataType declaration causing problems with C++11 std::lib
 (github issue 144)
- Pre-condition Violation in AllChem.Compute2DCoords
 (github issue 146)
- GetSimilarityMapForFingerprint() fails when similarity is zero
 (github issue 148)
- PatternFingerprint failure for substructure matching
 (github issue 151)
- query atoms don't match ring queries
 (github issue 153)
- Incorrect SMILES generated after calling MMFF parameterization
 (github issue 162)
- Problems with Xe from SDF
 (github issue 164)
- Radicals not being used in atom--atom matches
 (github issue 165)
- Cannot skip sanitization while reading PDB
 (github issue 166)
- Distance Geometry embedding not thread safe
 (github issue 167)
- O3A::align() and O3A::trans() now return true RMSD value
 (github pull 173)
- RangeError when pre-incrementing or decrementing AtomIterators
 (github issue 180)
- ctabs do not contain wedged bonds for chiral s
 (github issue 186)
- ctabs do not contain A when appropriate
 (github issue 187)
- Problems round-tripping Al2Cl6 via CTAB
 (github issue 189)
- Don't merge Hs onto dummies
 (github issue 190)
- Wavy bonds to Hs in CTABs should affect the stereochemistry of attached
double bonds
 (github issue 191)
- Rendering binary compounds as ClH, FH, BrH or IH rather than putting H
first.
 (github issue 199)
- Fixed data race condition in Code/GraphMol/MolAlign/testMolAlign.cpp
 (github pull 202)
- Re-prepared SDF/SMILES files of the MMFF validation suite + a fix
 (github pull 205)
- Problems round-tripping P with non-default valence.
 (github issue 206)
- Added a stricter definition of rotatable bonds as a new function in the
...
 (github pull 211)
- Code/GraphMol/AddHs patch proposal
 (github pull 212)
- Fix: Changed getNumReactantTemplates to GetNumReactantTemplates.
 (github pull 219)
- aromatic B (b) causes errors from SMARTS parser
 (github issue 220)
- Segmentation fault for MMFF optimization with dummy atoms
 (github issue 224)
- isMoleculeReactantOfReaction() and isMoleculeProductOfReaction() not
useable from SWIG wrappers
 (github issue 228)
- cartridge: mol_from_ctab() ignores argument about keeping conformers
 (github issue 229)
- Reaction not correctly preserving chirality on unmapped atoms.
 (github issue 233)
- AllChem.AssignBondOrdersFromTemplate() fails with nitro groups
 (github issue 235)
- Fix molecule dataframe rendering in pandas 0.13.x
 (github pull 236)
- Dummy labels copied improperly into products
 (github issue 243)
- Two bugfixes in MMFF code
 (github pull 248)
- seg fault when trying to construct pharmacophore with no conformation
 (github issue 252)
- EmbedMolecule() should not create a conformer for molecules that have
zero atoms
 (github issue 256)
- cartridge: dice similarity calculation does not use USE_BUILTIN_POPCOUNT
flag
 (github issue 259)
- cartridge: similarity calculations wrong for maccs fps when
USE_BUILTIN_POPCOUNT flag is set
 (github issue 260)

New Features:
- Expose gasteiger charge calculation to SWIG
 (github issue 152)
- Added additional functionality to PandasTools
 (github pull 155)
- Add MMFFHasAllMoleculeParams() to SWIG interface
 (github issue 157)
- O3A code should throw an exception if the parameterization is not
complete.
 (github issue 158)
- Support zero order bonds
 (github issue 168)
- Add attachmentPoint argument to ReplaceSubstructs
 (github issue 171)
- Forcefield constraints (distances, angles, torsions, positions)
 (github pull 172)
- Add kekulize flag to 

[Rdkit-devel] 2013.09.2 (Q3 2013) RDKit release

[Greg Landrum]

Dear all,

I've just created the files for the 2013.09.2 release of the RDKit. This is
purely a bug-fix release and contains no new features.

The release notes are below.

The source release is on the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q3_2013/
and directly from github:
https://github.com/rdkit/rdkit/archive/Release_2013_09_2.tar.gz

Google code no longer accepts new uploads, so the files are not accessible
from there.

I will uploaded 32-bit and 64-bit Windows binaries for Python 2.7 and Java
to the sourceforge page later today.

Thanks to the everyone who submitted bug reports and patches for this
release!

Best Regards,
-greg

**  Release_2013.09.2 ***
(Changes relative to Release_2013.09.2)

Acknowledgements:
Andrew Dalke, JP Ebejer, Daniel Moser, Sereina Riniker, Roger Sayle, Manuel
Schwarze, Julia Weber

Bug Fixes:
- cannot pickle unsanitized molecules
  (github issue 149)
- Problems reading PDB files when locale is DE
  (github issue 170)
- calling RWMol::clear() leaves property dict empty
  (github issue 176)
- zero atom molecule generates exception in MolToSmiles when
  rootedAtAtom is provided
  (github issue 182)
- bond orders not being set when PDB files are read
  (github issue 194)
- GenMACCSKeys() raises an exception with an empty molecule
  (github issue 195)
- left-justified SDF bond topology of 0 raises an unexpected
  exception
  (github issue 196)
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Beta of Q3 2013 release available

[Greg Landrum]

On Thu, Oct 24, 2013 at 11:35 AM, Gianluca Sforna gia...@gmail.com wrote:

 Tried to rebuild the RPMs for Fedora 20, fails at the cartridge with:

 g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
 -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -m64 -mtune=generic -Wno-unused-function
 -I/usr/local/include
 -I/builddir/build/BUILD/Release_2013_09_1beta1/Code
 -DRDKITVER='007100' -I/usr/local/include
 -I/builddir/build/BUILD/Release_2013_09_1beta1/Code
 -DRDKITVER='007100'   -I. -I. -I/usr/include/pgsql/server
 -I/usr/include/pgsql/internal -D_GNU_SOURCE -I/usr/include/libxml2
 -fPIC -c -o adapter.o adapter.cpp
 adapter.cpp:32:32: fatal error: GraphMol/RDKitBase.h: No such file or
 directory
  #include GraphMol/RDKitBase.h
 ^
 compilation terminated.


Is the source actually present in
 /builddir/build/BUILD/Release_2013_09_1beta1/Code?

The makefile uses (the equivalent of) -I$RDBASE/Code and assumes that
GraphMol is under that.

-greg
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] 2012.12 (Q4 2012) RDkit release

[Greg Landrum]

Thanks Gianluca!

On Tue, Jan 22, 2013 at 10:26 AM, Gianluca Sforna gia...@gmail.com wrote:
 On Tue, Jan 22, 2013 at 6:00 AM, Greg Landrum greg.land...@gmail.com wrote:
 I'm very happy to announce that the next version of the RDKit --
 2012.12 (a.k.a Q4 2012) -- is released.

 Thanks to Greg, I can offer again binary RPMs for Enterprise Linux 6
 (RHEL, CentOS, etc) and Fedora 18, both at 64bit.

 grab them from: http://giallu.fedorapeople.org/rdkit-2012.12/


 --
 Gianluca Sforna

 http://morefedora.blogspot.com
 http://identi.ca/giallu - http://twitter.com/giallu

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] [Rdkit-discuss] PBF Code

[Greg Landrum]

Dear all,


On Mon, Oct 29, 2012 at 10:57 AM, Nicholas Firth
nicholas.fi...@icr.ac.ukwrote:

 Hi Guys,
 I have managed to be allowed to open source the code from my paper. Greg I
 couldn't work if I was supposed to add this to the contrib or if you do it,
 so I've just attached it to the email. The code is a 'working'
 implementation although the error handling is not my finest work.


Nick and I did some revisions of his code. The most recent version is now
checked into $RDBASE/Contrib/PBF
It's C++ only at the moment.

Many thanks to Nick for the contribution.

-greg
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Question: Does anyone still need the Windows python 2.6 RDKit build?

[Greg Landrum]

Dear all,

Starting with the 2012.12 release, I would like to stop doing python
2.6 builds of the RDKit for Windows. In addition to the
administrative overhead of having to do the build, package it, and
upload it, having a second Python installation on my Windows machine
is making the process of configuring and running the build more
complex than I think it needs to be. This has an impact on my ability
to update and simplify the windows build instructions (one of my ToDo
items from the UGM).

The Python 2.6 binaries are downloaded a lot less often than the 2.7
versions, so it seems like this is unlikely to cause major problems,
but I'm willing to keep doing the builds for at least a few more
releases if they are important to someone here.

Best,
-greg

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2012.09 (Q3 2012) RDKit release

[Greg Landrum]

I'm very happy to announce that the next version of the RDKit --
2012.09 (a.k.a Q3 2012) -- is released.

The release notes are below.

The source release is on the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q3_2012/
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list
The binaries for Windows, Python 2.6 and Python 2.7, have also been uploaded.

The online version of the documentation at rdkit.org has been updated.

Thanks to the everyone who submitted bug reports and suggestions for
this release!

Please let me know if you find any problems with the release or have
suggestions for the next one.

-greg

**  Release_2012.09.1 ***
(Changes relative to Release_2012.06.1)

!! IMPORTANT !!
 - Some of the bug fixes affect the generation of SMILES. Canonical
   SMILES generated with this version of the RDKit will be different
   from previous versions.
 - The fix to Issue 252 (see below) will lead to changes in calculated
   logP and MR values for some compounds.
 - The fix to Issue 254 (see below) will lead to changes in some
   descriptors and geometries for sulfur-containing compounds.
 - The fix to Issue 256 (see below) has changed the name of the
   optional argument to mol.GetNumAtoms from onlyHeavy to
   onlyExplicit. For compatibility reasons, Python code that uses
   explicitly uses onlyHeavy will still work, but it will generate
   warnings. This compatibility will be removed in a future release.

Acknowledgements:
Gianpaolo Bravi, David Cosgrove, Andrew Dalke, Fabian Dey, James
Davidson, JP Ebejer, Gabriele Menna, Stephan Reiling, Roger Sayle,
James Swetnam

Bug Fixes:
- The molecules that come from mergeQueryHs() now reset the RingInfo
  structure. (issue 245)
- The output from MurckoScaffold.MakeScaffoldGeneric no longer
  includes stereochemistry or explicit Hs. (issue 246)
- D and T atoms in CTABs now have their isotope information
  set. (issue 247)
- Some problems with ring finding in large, complex molecules have
  been fixed. (issue 249)
- The rootedAtAtom argument for FindAllSubgraphsOfLengthN is now
  handled properly. (issue 250)
- Bonds now have a SetProp() method available in Python. (issue 251)
- A number of problems with the Crippen atom parameters have been
  fixed. (issue 252)
- Ring closure digits are no longer repeated on the same atom in
  SMILES generated by the RDKit. (issue 253)
- Non-ring sulfur atoms adjacent to aromatic atoms are no longer set
  to be SP2 hybridized. This allows them to be stereogenic. (issue
  254)
- The combineMols() function now clears computed properties on the
  result molecule.
- A couple of problems with the pickling functions on big endian
  hardware were fixed.
- The molecule drawing code now uses isotope information
- Superscript/Subscript handling in the agg canvas has been improved.
- SKP lines in CTABS are now propertly handled. (Issue 255)
- The name of the optional argument to mol.GetNumAtoms has been
  changed from onlyHeavy to onlyExplicit. The method counts the number
  of atoms in the molecular graph, not the number of heavy
  atoms. These numbers happen to usually be the same (which is why
  this has taken so long to show up), but there are exceptions if Hs
  or dummy atoms are in the graph. (Issue 256)
- Unknown bonds in SMILES are now output using '~' instead of '?'. The
  SMILES parser now recognizes '~' as an any bond query. (Issue 257)
- Lines containing only white space in SDF property blocks are no
  longer treated as field separators.
- Transition metals and lanthanides no longer have default valences
  assigned.

New Features:
- The RDKit now has a maximum common substructure (MCS) implementation
  contributed by Andrew Dalke. This is currently implemented in Python
  and is available as: from rdkit.Chem import MCS Documentation is
  available as a docstring for the function MCS.FindMCS and in the
  GettingStarted document.
- A few new functions have been added to rdkit.Chem.Draw:
  MolsToImage(), MolsToGridImage(), ReactionToImage()
- CalcMolFormula() now provides the option to include isotope
  information.
- The RDKit and Layered fingerprinters both now accept fromAtoms
  arguments that can be used to limit which atoms contribute to the
  fingerprint.
- Version information is now available in the Java wrapper.
- The descriptor NumRadicalElectrons is now available.
- The PyMol interface now supports a GetPNG() method which returns the
  current contents of the viewer window as an PIL Image object.
- Molecules (ROMol in C++, rdkit.Chem.Mol in Python) now have a
  getNumHeavyAtoms() method.
- Component-level grouping (parens) can be used in reaction SMARTS.


New Database Cartridge Features:
- support for molecule - pickle conversion via the functions
  mol_to_pkl, mol_from_pkl, and is_valid_mol_pkl.
- support for bit vector - binary text conversion via the functions
  bfp_to_binary_text, bfp_from_binary_text

New Java 

[Rdkit-devel] Speeding up SMILES parsing

[Greg Landrum]

Over the past couple of days I've spent some time doing some tuning of
the RDKit's SMILES parser.

I made a couple of minor changes here and there and saw some
improvement before making a change in the YACC grammar used to
generate the parser. This made the parser source a bit more difficult
to read, but had a pretty significant impact on performance.

In order to just measure performance of the SMILES parser, I did a
benchmark using ~560K molecules from ZINC where I generated a molecule
from SMILES without any sanitization.
Here are the timings on my linux box for that benchmark:

RDKit_2011_06_1: 50.6s
RDKit_2012_03_1: 49.6s
RDKit_2012_06_1: 57.6s  [ - I'm not sure I understand this outlier]
svn: 30.6s

I'm pretty pleased about that last number. :-)

For those who are interested, here's the commit:
https://sourceforge.net/p/rdkit/code/2159/
and the specific grammar changes that made the difference:
https://sourceforge.net/p/rdkit/code/2159/tree//trunk/Code/GraphMol/SmilesParse/smiles.yy?diff=502dda6571b75b41b4b10063:2158

-greg

--
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/
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] New MolDrawing.h

[Greg Landrum]

On Wed, Aug 15, 2012 at 6:04 AM, Greg Landrum greg.land...@gmail.com wrote:

 On Tue, Aug 14, 2012 at 1:20 PM, David Cosgrove
 davidacosgrov...@gmail.com wrote:

 As for the Qt demo, if it's convenient for you to do so, please do add the
 standard licence to the top of the files. I assume the copyright transfers
 to you as the RDKit owner?  That's no problem, I just wasn't sure exactly
 what to put.

 I'll make those updates and get the code checked in. Thanks for
 contributing the examples!

I just realized that I hadn't done this.
The qt demo code is now in $RDBASE/Code/Demos/RDKit/Draw/qtDemo

Best,
-greg

--
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/
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] symbol(s) not found on Mac OS X 10.7.3

[Greg Landrum]

Hi Andrew,

On Wed, Aug 22, 2012 at 12:17 PM, Andrew Dalke
da...@dalkescientific.com wrote:
 On Aug 17, 2012, at 11:35 AM, Greg Landrum wrote:
 Here is, hopefully, the last update on this topic. Apologies for the 
 verbosity.

 I'm trying to build the latests from the new repository. Here's
 the message I get:

 [  4%] Building CXX object 
 Code/RDGeneral/CMakeFiles/testDict.dir/testDict.cpp.o
 Linking CXX executable testDict
 ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a directory
 Undefined symbols for architecture x86_64:
   boost::any RDKit::Dict::toanystd::vectorstd::vectorint, 
 std::allocatorint , std::allocatorstd::vectorint, std::allocatorint  
   (std::vectorstd::vectorint, std::allocatorint , 
 std::allocatorstd::vectorint, std::allocatorint   ) const, referenced 
 from:
   void RDKit::Dict::setValstd::vectorstd::vectorint, 
 std::allocatorint , std::allocatorstd::vectorint, std::allocatorint  
   (std::string const, std::vectorstd::vectorint, std::allocatorint , 
 std::allocatorstd::vectorint, std::allocatorint   ) in testDict.cpp.o
   std::vectorint, std::allocatorint  
 RDKit::Dict::fromanystd::vectorint, std::allocatorint  (boost::any 
 const) const, referenced from:
   void RDKit::Dict::getValstd::vectorint, std::allocatorint  
 (std::string const, std::vectorint, std::allocatorint ) const in 
 testDict.cpp.o
   boost::any RDKit::Dict::toanystd::vectorint, std::allocatorint  
 (std::vectorint, std::allocatorint ) const, referenced from:
   void RDKit::Dict::setValstd::vectorint, std::allocatorint  
 (std::string const, std::vectorint, std::allocatorint ) in 
 testDict.cpp.o
   int RDKit::Dict::fromanyint(boost::any const) const, referenced from:
   void RDKit::Dict::getValint(std::string const, int) const in 
 testDict.cpp.o
   boost::any RDKit::Dict::toanyint(int) const, referenced from:
   void RDKit::Dict::setValint(std::string const, int) in 
 testDict.cpp.o
 ld: symbol(s) not found for architecture x86_64
 clang: error: linker command failed with exit code 1 (use -v to see 
 invocation)


Nikolas Fechner, who has a MacBookPro running Lion, and I just got
this figured out.
There's a test at line 4 of $RDBASE/Code/RDGeneral/CMakeLists.txt:

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANG)
# Dict.cpp behaves badly if compiled with optimization under g++
SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
endif()

apparently neither of those two variables is set under Lion. The
fix, which I will check in later today, is:

if(NOT MSVC)
# Dict.cpp behaves badly if compiled with optimization under g++
SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
endif()

After making this change we were able to complete an RDKit build on
Niko's machine.

I will try to remember to do a longer explanation of why the above is
necessary later, but right now I have to run to a meeting.

Hope this helps,
-greg

--
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/
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] updating the rdkit project on sourceforge

[Greg Landrum]

Ok, the change I mentioned below has been made; we're now using the
new sourceforge tools.

I've update the links on www.rdkit.org.

The svn migration is still ongoing, so at the moment svn is unavailable.
Once the migration is complete, people who are using the RDKit svn
repository will need to change their local copies.
I'll send information about how to do this once the migration has finished.

-greg


On Thu, Aug 16, 2012 at 5:24 AM, Greg Landrum greg.land...@gmail.com wrote:
 Dear all,

 Sourceforge has new backend software that they are encouraging
 everyone to switch their projects too.
 Based on the descriptions
 (https://sourceforge.net/p/allura/wiki/Features/) it sounds like a
 good idea to me, so I plan to go ahead and initiate the update in the
 next couple of days (unless one of you has a strong opinion that it
 would be a bad idea).

 Aside from a more modern web experience and the new features described
 above, the only real significant change that you should see is that
 the URLs for the svn repository will change. I will send updated info
 about this after the switch (when I know the new urls).

 For those interested, there are some details about the upgrade process
 here: https://sourceforge.net/p/upgrade/

 Best,
 -greg

--
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/
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] updating the rdkit project on sourceforge

[Greg Landrum]

Here is, hopefully, the last update on this topic. Apologies for the verbosity.

One unfortunate thing about this update is that the svn repository has
moved. If you have a version of the source checked out via svn, you
need to change the repository URL.
You have a few choices:
1) checkout a fresh copy (instructions for how to do that are here:
http://sourceforge.net/p/rdkit/code)
2) switch your existing copy. The method for the switch depends on how
you checked out the code in the first place, but this is what I just
did :
svn switch --username glandrum --relocate
https://rdkit.svn.sourceforge.net/svnroot/rdkit/trunk
https://svn.code.sf.net/p/rdkit/code/trunk
I'm not quite sure why, but this worked for me on linux, but not on the Mac.
3) If you have unchecked-in changes that you want to keep, you can do
something like this:
   - cd $RDBASE
   - svn update
   - cd ..
   - svn diff $RDBASE  rdk.patch
   - mv $RDBASE $RDBASE.old
   - do a fresh rdkit checkout as directed in option 1 above, make
sure it goes into the directory $RDBASE
   - patch -p0  ./rdk.patch

Best,
-greg




On Fri, Aug 17, 2012 at 8:25 AM, Greg Landrum greg.land...@gmail.com wrote:
 Ok, the change I mentioned below has been made; we're now using the
 new sourceforge tools.

 I've update the links on www.rdkit.org.

 The svn migration is still ongoing, so at the moment svn is unavailable.
 Once the migration is complete, people who are using the RDKit svn
 repository will need to change their local copies.
 I'll send information about how to do this once the migration has finished.

 -greg


 On Thu, Aug 16, 2012 at 5:24 AM, Greg Landrum greg.land...@gmail.com wrote:
 Dear all,

 Sourceforge has new backend software that they are encouraging
 everyone to switch their projects too.
 Based on the descriptions
 (https://sourceforge.net/p/allura/wiki/Features/) it sounds like a
 good idea to me, so I plan to go ahead and initiate the update in the
 next couple of days (unless one of you has a strong opinion that it
 would be a bad idea).

 Aside from a more modern web experience and the new features described
 above, the only real significant change that you should see is that
 the URLs for the svn repository will change. I will send updated info
 about this after the switch (when I know the new urls).

 For those interested, there are some details about the upgrade process
 here: https://sourceforge.net/p/upgrade/

 Best,
 -greg

--
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/
___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel