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
&

[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 Rodríg

[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 m

[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 Robinso

[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 stereoche

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 do

[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
 (github

[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 Run

[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

[Rdkit-devel] 2019.03.1 RDKit Release

[Greg Landrum]

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
Sforna, Ricardo Rodriguez Schmidt, Gianluca Sforna, Matt Swain, Paolo
Tosco,
Ricardo Vianello, 'John-Videogames', 'magattaca', 'msteijaert', 'paconius',
'sirbiscuit'

## Bug Fixes:
  - PgSQL: fix boolean definitions for Postgresql 11
 (github pull #2129 from pkubatrh)
  - update fingerprint tutorial notebook
 (github pull #2130 from greglandrum)
  - Fix typo in RecapHierarchyNode destructor
 (github pull #2137 from iwatobipen)
  - SMARTS roundtrip failure
 (github issue #2142 from mcs07)
  - Error thrown in rdMolStandardize.ChargeParent
 (github issue #2144 from paconius)
  - SMILES parsing inconsistency based on input order
 (github issue #2148 from coleb)
  - MolDraw2D: line width not in python wrapper
 (github issue #2149 from greglandrum)
  - Missing Python API Documentation
 (github issue #2158 from greglandrum)
  - PgSQL: mol_to_svg() changes input molecule.
 (github issue #2174 from janholstjensen)
  - Remove Unicode From AcidBasePair Name
 (github pull #2185 from lilleswing)
  - Inconsistent treatment of `[as]` in SMILES and SMARTS
 (github issue #2197 from greglandrum)
  - RGroupDecomposition fixes, keep userLabels more robust
onlyMatchAtRGroups
 (github pull #2202 from bp-kelley)
  - Fix TautomerTransform in operator=
 (github pull #2203 from bp-kelley)
  - testEnumeration hangs/takes where long on 32bit architectures
 (github issue #2209 from mbanck)
  - Silencing some Python 3 warning messages
 (github pull #2223 from coleb)
  - removeHs shouldn't remove atom lists
 (github issue #2224 from rvianello)
  - failure round-tripping mol block with Q atom
 (github issue #2225 from rvianello)
  - problem round-tripping mol files that include bond topology info
 (github issue #2229 from rvianello)
  - aromatic main-group atoms written to SMARTS incorrectly
 (github issue #2237 from greglandrum)
  - findPotentialStereoBonds() stopping too early
 (github issue #2244 from greglandrum)
  - MinMax Diversity picker seeding shows deterministic / non-random
behaviour
 (github issue #2245 from sroughley)
  - Fix to serialize binary strings
 (github pull #2264 from bp-kelley)
  - Recognize N in three-membered rings as potentially chiral
 (github issue #2268 from greglandrum)
  - Failure when parsing mol block with M  PXA
 (github issu

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] Beta of the 2019.03 release available

[Greg Landrum]

Dear all,

The beta of the 2019.03 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2019_03_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.6 and 3.7 for Windows, Mac, and Linux.
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_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 early
next week.

Best,
-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, 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
Sforna, Ricardo Rodriguez Schmidt, Matt Swain, Paolo Tosco, Ricardo Vianello,
'John-Videogames', 'magattaca', 'msteijaert', 'paconius', 'sirbiscuit'

## Bug Fixes:
  - PgSQL: fix boolean definitions for Postgresql 11
 (github pull #2129 from pkubatrh)
  - update fingerprint tutorial notebook
 (github pull #2130 from greglandrum)
  - Fix typo in RecapHierarchyNode destructor
 (github pull #2137 from iwatobipen)
  - SMARTS roundtrip failure
 (github issue #2142 from mcs07)
  - Error thrown in rdMolStandardize.ChargeParent
 (github issue #2144 from paconius)
  - SMILES parsing inconsistency based on input order
 (github issue #2148 from coleb)
  - MolDraw2D: line width not in python wrapper
 (github issue #2149 from greglandrum)
  - Missing Python API Documentation
 (github issue #2158 from greglandrum)
  - PgSQL: mol_to_svg() changes input molecule.
 (github issue #2174 from janholstjensen)
  - Remove Unicode From AcidBasePair Name
 (github pull #2185 from lilleswing)
  - Inconsistent treatment of `[as]` in SMILES and SMARTS
 (github issue #2197 from greglandrum)
  - RGroupDecomposition fixes, keep userLabels more robust onlyMatchAtRGroups
 (github pull #2202 from bp-kelley)
  - Fix TautomerTransform in operator=
 (github pull #2203 from bp-kelley)
  - testEnumeration hangs/takes where long on 32bit architectures
 (github issue #2209 from mbanck)
  - Silencing some Python 3 warning messages
 (github pull #2223 from coleb)
  - removeHs shouldn't remove atom lists
 (github issue #2224 from rvianello)
  - failure round-tripping mol block with Q atom
 (github issue #2225 from rvianello)
  - problem round-tripping mol files that include bond topology info
 (github issue #2229 from rvianello)
  - aromatic main-group atoms written to SMARTS incorrectly
 (github issue #2237 from greglandrum)
  - findPotentialStereoBonds() stopping too early
 (github issue #2244 from greglandrum)
  - MinMax Diversity picker seeding shows deterministic / non-random behaviour
 (github issue #2245 from sroughley)
  - Fix to serialize binary strings
 (github pull #2264 from bp-kelley)
  - Recognize N in three-membered rings as potentially chiral
 (github issue #2268 from greglandrum)
  - Failure when parsing mol block with M  PXA
 (github issue #2277 from greglandrum)
  - query-query matching failing for atoms constructed from SMARTS
 (github issue #2299 from greglandrum)
  - SMILES parsing fails for dative ring closures
 (github issue #2303 from greglandrum)
  - Missing Dict.h overload: std::string Dict::getVal
 (github issue #2308 from

[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 Mol

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] Failing tests in Visual Studio build

[Greg Landrum]

Hi Juuso,

Thanks for letting us know about this.

-greg


On Wed, May 30, 2018 at 10:28 AM Juuso Lehtivarjo <
juuso.lehtiva...@gmail.com> wrote:

> Hi All,
>
> Just wanted to inform all Visual Studio users of some weirdness that
> we encountered after updating Visual Studio 2017 to version 15.7.2,
> that was, on release config, the following tests failed:
>
> 1> 53 - pyChemReactions (SEGFAULT)
> 1> 60 - pyFilterCatalog (SEGFAULT)
> 1> 72 - pyMolDescriptors (SEGFAULT)
> 1>114 - pyGraphMolWrap (SEGFAULT)
>
> What caused the segfaults was direct touching of the __doc__ property
> of the python wrapper functions. The underlying reason for this was
> that at O2 level optimization, boost::python produced corrupted
> wrappers, apparently due to some changes in the VS optimizer. There is
> now a PR in boost/python for this issue at
> https://github.com/boostorg/python/pull/208.
>
> My setup was Python 3.6.5 and Boost 1.67.0.
>
> Cheers,
> Juuso
>
>
> --
> 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 2018.03.1 Build and Installation

[Greg Landrum]

You should be able to use Python 2.7 as well, but I do strongly recommend
Python 3 if you can possibly use it.

-greg


On Tue, May 22, 2018 at 2:01 PM alb greg  wrote:

> Hi Greg,
>
> I'd like to know one thing : is it mandatory to use python 3 to install
> RDKit (as in your dockerfile) or is there a similar process in python 2.7 ?
>
> BR
>
>
>
> 2018-05-17 19:20 GMT+02:00 alb greg :
>
>> Thanks, Greg!
>>
>> Installation is okay now but ctest ends with these 2 failed :
>>
>> 118 - pyGraphMolWrap (Failed)
>> 136 - pythonTestDirChem (Failed)
>>
>> Any idea?
>>
>>
>>
>> 2018-05-16 15:08 GMT+02:00 Greg Landrum :
>>
>>> Yeah, the dockerfile that I pointed you to installs the ubuntu version
>>> of boost. That is what ends up being used to build the RDKit.
>>> You have a copy of boost 1.67 installed; this is too new for the version
>>> of cmake you have (and has additional problems anyway); the system boost
>>> solves this problem.
>>>
>>> On Wed, May 16, 2018 at 3:03 PM alb greg 
>>> wrote:
>>>
>>>> The system boost? You're talking about libboost?
>>>>
>>>>
>>>>
>>>> 2018-05-16 14:54 GMT+02:00 Greg Landrum :
>>>>
>>>>> cmake is finding boost v1.67, not the system boost.
>>>>>
>>>>>
>>>>> On Wed, May 16, 2018 at 2:34 PM alb greg 
>>>>> 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):
>>>>>>   Impor

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

[Greg Landrum]

Yeah, the dockerfile that I pointed you to installs the ubuntu version of
boost. That is what ends up being used to build the RDKit.
You have a copy of boost 1.67 installed; this is too new for the version of
cmake you have (and has additional problems anyway); the system boost
solves this problem.

On Wed, May 16, 2018 at 3:03 PM alb greg  wrote:

> The system boost? You're talking about libboost?
>
>
>
> 2018-05-16 14:54 GMT+02:00 Greg Landrum :
>
>> cmake is finding boost v1.67, not the system boost.
>>
>>
>> On Wed, May 16, 2018 at 2:34 PM alb greg 
>> 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 i

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  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 :
>
>> 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]

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

Re: [Rdkit-devel] bivariate_normal deprecation

[Greg Landrum]

Thanks Kiran!

On Fri, May 4, 2018 at 5:08 PM Kiran Telukunta <
kiran.teluku...@indiayouth.info> wrote:

> Hello Greg,
>
> I have created the ticket <https://github.com/rdkit/rdkit/issues/1851>.
>
> Thanks,
> Kiran
>
> On 4 May 2018 at 09:13, Greg Landrum  wrote:
>
>> Hi Kira,
>>
>> I would rather not introduce a dependency on scipy (which is rather
>> large) here. I think it probably makes more sense to just add an RDKit
>> reimplementation of the function and use that.
>>
>> I need to check, but I would guess that the license on matplotlib would
>> probably allow us to just grab their current implementation and use that.
>>
>> Regardless, there should be an RDKit GitHub ticket for this. Do you want
>> to create that or shall I?
>>
>> Best,
>> -greg
>>
>>
>>
>> On Fri, 4 May 2018 at 06:19, Kiran Telukunta <
>> kiran.teluku...@indiayouth.info> wrote:
>>
>>> Hi All,
>>>
>>>
>>> What is the best way to rewrite in rdkit.Chem.Draw import SimilarityMaps
>>>
>>> def calcAtomGaussians(mol, a=0.03, step=0.02, weights=None):
>>>
>>> As  mlab.bivariate_normal
>>> <https://matplotlib.org/api/mlab_api.html#matplotlib.mlab.bivariate_normal>
>>> ​​
>>> is deprecated.
>>>
>>> Should we use scipy multivarate function
>>> <https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.stats.multivariate_normal.html#scipy.stats.multivariate_normal>
>>> or is there any other best method?
>>>
>>> I was trying to use SimilarityMaps.GetSimilarityMapForFingerprint, and
>>> got the error:
>>>
>>> home/kiran/anaconda3/envs/rdkit-2018_03_1/lib/python3.5/site-packages/rdkit/Chem/Draw/__init__.py:285:
>>> MatplotlibDeprecationWarning: The bivariate_normal function was deprecated
>>> in version 2.2.
>>>   Z = mlab.bivariate_normal(X, Y, a, a, mol._atomPs[0][0],
>>> mol._atomPs[0][1]) * weights[0]
>>> /home/kiran/anaconda3/envs/rdkit-2018_03_1/lib/python3.5/site-packages/rdkit/Chem/Draw/__init__.py:287:
>>> MatplotlibDeprecationWarning: The bivariate_normal function was deprecated
>>> in version 2.2.
>>>   Zp = mlab.bivariate_normal(X, Y, a, a, mol._atomPs[i][0],
>>> mol._atomPs[i][1])
>>>
>>> I was using latest RDKit 2018.03.1.
>>>
>>> Thanks,
>>> Kiran
>>>
>>>
>>> --
>>> 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
>
--
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] bivariate_normal deprecation

[Greg Landrum]

Hi Kira,

I would rather not introduce a dependency on scipy (which is rather large)
here. I think it probably makes more sense to just add an RDKit
reimplementation of the function and use that.

I need to check, but I would guess that the license on matplotlib would
probably allow us to just grab their current implementation and use that.

Regardless, there should be an RDKit GitHub ticket for this. Do you want to
create that or shall I?

Best,
-greg



On Fri, 4 May 2018 at 06:19, Kiran Telukunta <
kiran.teluku...@indiayouth.info> wrote:

> Hi All,
>
>
> What is the best way to rewrite in rdkit.Chem.Draw import SimilarityMaps
>
> def calcAtomGaussians(mol, a=0.03, step=0.02, weights=None):
>
> As  mlab.bivariate_normal
> 
> ​​
> is deprecated.
>
> Should we use scipy multivarate function
> 
> or is there any other best method?
>
> I was trying to use SimilarityMaps.GetSimilarityMapForFingerprint, and got
> the error:
>
> home/kiran/anaconda3/envs/rdkit-2018_03_1/lib/python3.5/site-packages/rdkit/Chem/Draw/__init__.py:285:
> MatplotlibDeprecationWarning: The bivariate_normal function was deprecated
> in version 2.2.
>   Z = mlab.bivariate_normal(X, Y, a, a, mol._atomPs[0][0],
> mol._atomPs[0][1]) * weights[0]
> /home/kiran/anaconda3/envs/rdkit-2018_03_1/lib/python3.5/site-packages/rdkit/Chem/Draw/__init__.py:287:
> MatplotlibDeprecationWarning: The bivariate_normal function was deprecated
> in version 2.2.
>   Zp = mlab.bivariate_normal(X, Y, a, a, mol._atomPs[i][0],
> mol._atomPs[i][1])
>
> I was using latest RDKit 2018.03.1.
>
> Thanks,
> Kiran
>
>
> --
> 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 2018.03.1 Build and Installation

[Greg Landrum]

This is indeed almost certainly due to the version of boost being “too new”
for the version of cmake. I took advantage of a new cmake feature without
fully thinking through the consequences of how picky cmake is about it.

I’m going to revert this change to the build system before the 2018.03.2
release, which will happen sometime in the next couple of weeks. This
should allow older 3.x versions of cmake to work with newer boost versions.

-greg

On Thu, 3 May 2018 at 19:10, Andrew Dalke  wrote:

> On May 3, 2018, at 18:44, alb greg  wrote:
> > 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.
>
> > CMake Error at Code/cmake/Modules/RDKitUtils.cmake:57 (add_library):
> >   Target "maeparser_static" links to target "Boost::boost" but the
> target was
> >   not found.  Perhaps a find_package() call is missing for an IMPORTED
> >   target, or an ALIAS target is missing?
> > Call Stack (most recent call first):
> >   External/CoordGen/CMakeLists.txt:21 (rdkit_library)
>
>
> That looks similar to a problem I had when I tried to build the most
> recent RDKit.
>
> The problem for me was the installed version of cmake on my system was too
> old.
>
> Once I upgraded from 3.7.2 to 3.11.1, the problem went away.
>
> What version of cmake did you install? Use "cmake --version" to find out.
>
> Cheers,
>
> Andrew
> da...@dalkescientific.com
>
>
>
>
> --
> 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] 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 

[Rdkit-devel] The 2018.03 release, python 2.7, and Windows

[Greg Landrum]

Dear all,

In finalizing the details for the 2018.03.1 release, I hit a problem with
python v2.7 on Windows that is likely to result in there being no conda
builds available for the Windows version of python 2.7.

The problem is that extension modules for python 2.7 “are supposed to be”
built with a 10+ year old version of visual C++. This ancient compiler
can’t handle modern C++ and thus can no longer build the RDKit. It is
possible, though somewhat risky, to use other compilers, but conda-build
makes that challenging.

I have already spent a fair amount of time on this without making
significant progress, so I’m going to give up with apologies to anyone who
is still using Python 2.7 on Windows. I may have end up having alternate
ideas to try out later, but if anyone else knows how to force recent
versions of conda-build to use a more modern compiler on Windows, I’d love
to hear about it.

A reminder for people who are still using python 2.7: it's a very good idea
to read this and start figuring out a plan for migrating to Python 3:
https://python3statement.org


 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] [Rdkit-discuss] [Announcement] 7th RDKit UGM in Cambridge UK

[Greg Landrum]

The optional training events will have separate registration pages (or
maybe just one). I will post the link for those "soon" (hopefully in the
next week).

-greg


On Tue, Apr 10, 2018 at 11:03 AM, Paul Czodrowski <
paul.czodrow...@merckgroup.com> wrote:

> Great idea about the optional training on the day before.
>
>
>
> However, I could not see any link (on the eventbrite page) regarding this
> event. There was an option for the dinner & reception, but no training..
>
>
>
> Or is the “main UGM registration” a different place than the evenbrite
> page?
>
>
>
>
>
> Paul
>
>
>
> *Von:* Greg Landrum [mailto:greg.land...@gmail.com]
> *Gesendet:* Samstag, 7. April 2018 07:14
> *An:* RDKit Discuss ; RDKit
> Developers List 
> *Cc:* Andreas Bender, PhD 
> *Betreff:* [Rdkit-devel] [Announcement] 7th RDKit UGM in Cambridge UK
>
>
>
> Dear all,
>
>
>
> This year's RDKit User Group Meeting will take place from 19-21 September
> in Cambridge, UK and is being hosted by Andreas Bender at Cambridge
> University.
>
>
>
> Registration for the RDKit UGM is free:
>
> https://www.eventbrite.com/e/7th-rdkit-ugm-2018-tickets-44883066460
>
>
>
> We will once again mostly stick to what has become a tried and true format:
>
> Days 1 and 2: Talks, lightning talks, roundtable(s), discussion, poster
> sessions, and talktorials. For those who haven’t attended before,
> talktorials are somewhere between a talk and a tutorial, they cover
> something interesting done with the RDKit and include the code used to do
> the work. During the presentation you'll give an overview of what you did
> and also show the pieces of the code that are central to the work. The idea
> is to mix the science up with the tutorial aspects.
>
>
>
> Day 3 will be a hackathon: those who choose to stay will spend an intense
> day working in small groups to produce useful artifacts: new bits of code,
> KNIME nodes, KNIME workflows, tutorials, documentation, IPython notebooks,
> etc. We will once again try to structure this a bit by collecting a bunch
> of ideas for things to work on in advance. Two years ago we also did
> extended tutorials on Day 3; if there are volunteers to do tutorials and
> people interested in attending them, we'll repeat that this year as well.
>
>
>
> As an experiment this year there will be an optional training day on
> Tuesday the 18th. Andrew Dalke (Dalke Scientific) will offer a course on
> Python and the RDKit and Daria Goldmann (KNIME) will offer a course on
> KNIME and the RDKit. Space for both of these is limited, so we'll do
> separate registrations for them (links will be included on the main UGM
> registration page). Many thanks to Andrew for coming up with the idea to do
> this!
>
>
>
> There will also be, of course, social activities. This year we have the
> special opportunity to have the dinner on the 19th in the Old Library of
> Pembroke College. I can't wait for that. :-)
>
>
>
> A more detailed announcement with additional information about place,
> hotels and logistics will follow soon.
>
>
>
> We are looking for people who are willing to do presentations, talktorials
> or posters on the first two days. If you're interested in contributing,
> please send Greg and Andreas an email.
>
>
>
> Lightning talks don't need to be arranged too far in advance; we will
> start collecting the list of people interested in doing those shortly
> before the event.
>
>
>
> Best Regards,
>
> Greg and Andreas
>
>
>
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not the intended recipient,
> you must not copy this message or attachment or disclose the contents to
> any other person. If you have received this transmission in error, please
> notify the sender immediately and delete the message and any attachment
> from your system. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not accept liability for any omissions or errors in this
> message which may arise as a result of E-Mail-transmission or for damages
> resulting from any unauthorized changes of the content of this message and
> any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
> subsidiaries do not guarantee that this message is free of viruses and does
> not accept liability for any damages caused by any virus transmitted
> therewith.
>
>
>
> Click http://www.merckgroup.com/disclaimer to access the German, French,
> Spanish and Portuguese versions of this disclaimer.
>
> 
> 

[Rdkit-devel] [Announcement] 7th RDKit UGM in Cambridge UK

[Greg Landrum]

Dear all,

This year's RDKit User Group Meeting will take place from 19-21 September
in Cambridge, UK and is being hosted by Andreas Bender at Cambridge
University.

Registration for the RDKit UGM is free:
https://www.eventbrite.com/e/7th-rdkit-ugm-2018-tickets-44883066460

We will once again mostly stick to what has become a tried and true format:
Days 1 and 2: Talks, lightning talks, roundtable(s), discussion, poster
sessions, and talktorials. For those who haven’t attended before,
talktorials are somewhere between a talk and a tutorial, they cover
something interesting done with the RDKit and include the code used to do
the work. During the presentation you'll give an overview of what you did
and also show the pieces of the code that are central to the work. The idea
is to mix the science up with the tutorial aspects.

Day 3 will be a hackathon: those who choose to stay will spend an intense
day working in small groups to produce useful artifacts: new bits of code,
KNIME nodes, KNIME workflows, tutorials, documentation, IPython notebooks,
etc. We will once again try to structure this a bit by collecting a bunch
of ideas for things to work on in advance. Two years ago we also did
extended tutorials on Day 3; if there are volunteers to do tutorials and
people interested in attending them, we'll repeat that this year as well.

As an experiment this year there will be an optional training day on
Tuesday the 18th. Andrew Dalke (Dalke Scientific) will offer a course on
Python and the RDKit and Daria Goldmann (KNIME) will offer a course on
KNIME and the RDKit. Space for both of these is limited, so we'll do
separate registrations for them (links will be included on the main UGM
registration page). Many thanks to Andrew for coming up with the idea to do
this!

There will also be, of course, social activities. This year we have the
special opportunity to have the dinner on the 19th in the Old Library of
Pembroke College. I can't wait for that. :-)

A more detailed announcement with additional information about place,
hotels and logistics will follow soon.

We are looking for people who are willing to do presentations, talktorials
or posters on the first two days. If you're interested in contributing,
please send Greg and Andreas an email.

Lightning talks don't need to be arranged too far in advance; we will start
collecting the list of people interested in doing those shortly before the
event.

Best Regards,
Greg and Andreas
--
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] Beta of the 2018.03 release available

[Greg Landrum]

 Dear all,

The beta of the 2018.03 RDKit release has been tagged in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2018_03_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.03.1.b1

About the builds:
- These will be done using the most recent version of conda.
- I will do the conda builds somewhat differently than I've done them
before due to the transition to modern C++ on the backend. If you encounter
problems with the beta builds, particularly the windows or linux builds,
please let me know. It is, of course, also really nice to hear if you try
things and they work!

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.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, Thomas Heavy, Gareth
Jones, Brian Kelley, Karl Leswing, Susan Leung, Chris Morris, Noel
O'Boyle, Axel Pahl, Pavel Polishchuk, Sereina Riniker, Jeff van
Santen, Roger Sayle, Matt Swain, Palo Tosco, Sam Webb, Maciej
Wójcikowski, Nicola Zonta, 'clinntt', 'hjuinj', 'iwatobipen',

## Highlights:
  - A number of improvements were made to the PDB reader
  - Thanks to the move to modern C++ the RDKit is now faster and uses
less memory

## 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 mwojcikowski)
  - Improve AddHs for molecules read from PDB
 (github pull #1647 from mwojcikowski)
  - Improved regression test for ETKDG version 2
 (github pull #1640 from sriniker)
  - RDKit interpretation of atom stereo SMILES is different from 4
other toolkits
 (github issue #1652 from coleb)
  - Treat bonds in PDB CONECT records explicitly, but make blacklisted
ones zero-order.
 (github pull #1

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

[Greg Landrum]

This change has now been made.
The RDKit master branch (the default one in github) has been moved to
modern c++.
The previous status of master is captured here:
https://github.com/rdkit/rdkit/tree/legacy/master

Hopefully this doesn't cause horrible problems for anyone with active
forks, but I figure there are likely to be at least a few bumps. Hopefully
they aren't too large.

-greg


On Thu, Apr 5, 2018 at 8:46 AM, Greg Landrum  wrote:

> 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  > 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 
>> 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]

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 
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 
> 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

Re: [Rdkit-devel] Where's the 2018.03 release?

[Greg Landrum]

On Wed, Apr 4, 2018 at 10:30 AM, Maciek Wójcikowski 
wrote:

>
> I don't know if it is of any help, but we have fixed recent conda (linking
> against Python library) for OpenBabel by adding additional linker
> parameters for Mac in cmake config, see Matts patch here:
> https://github.com/openbabel/openbabel/pull/1807/files
>

Thanks for pointing that out. Matt has also done a similar PR against the
RDKit (https://github.com/rdkit/rdkit/pull/1805), and that helps, but we've
gotten some feedback that this isn't the best solution to the problem.
There's another active PR where we're close to having an alternate fix
(amusingly, the same number as the OB fix:
https://github.com/rdkit/rdkit/pull/1807).

I think we're very close.
-greg



> 
> Pozdrawiam,  |  Best regards,
> Maciek Wójcikowski
> mac...@wojcikowski.pl
>
> 2018-04-04 5:39 GMT+02:00 Greg Landrum :
>
>> Dear all,
>>
>> As you may have noticed, the new release (2018.03) is late.
>>
>> This is not, as you might expect, connected to my previous email about
>> the backend code changes. It turned out to be much more difficult than
>> anticipated to straighten out the problems we were having with newer
>> versions of conda, particularly on the Mac, and we didn't want to do a
>> release until those were taken care of.
>>
>> It looks like we're almost there. Hopefully we will be able to do a beta
>> of the 2018.03 release by the end of the week.
>>
>> 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
>>
>>
>
--
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] Where's the 2018.03 release?

[Greg Landrum]

Dear all,

As you may have noticed, the new release (2018.03) is late.

This is not, as you might expect, connected to my previous email about the
backend code changes. It turned out to be much more difficult than
anticipated to straighten out the problems we were having with newer
versions of conda, particularly on the Mac, and we didn't want to do a
release until those were taken care of.

It looks like we're almost there. Hopefully we will be able to do a beta of
the 2018.03 release by the end of the week.

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] 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  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 
> 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  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  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/rdkit/build/Code/RDGene

Re: [Rdkit-devel] problem building rdkit

[Greg Landrum]

>> Makefiles" /home/tj/RDKit/rdkit /home/tj/RDKit/rdkit/Code/GraphMol/Substruct
>> /home/tj/RDKit/rdkit/build /home/tj/RDKit/rdkit/build/Code/GraphMol/Substruct
>> /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 
>> 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  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 drawin

[Rdkit-devel] Beta of the 2017.09 release available

[Greg Landrum]

Dear all,

This morning I tagged the beta of the 2017.09 RDKit release in github:
https://github.com/rdkit/rdkit/releases/tag/Release_2017_09_1b1

I will try to get some conda builds 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=2017.09.1.b1

Note that I've done the conda linux builds using a Centos7 system - in the
past I've used Centos6 - if this causes compatibility problems or if you
think that this is a bad idea please let me know and I will switch back to
Centos6 for the builds.

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 a week
from today.

Best,
-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

## Acknowledgements:
Brian Cole, Peter Gedeck, Guillaume Godin, 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, 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 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 drawing tweaks
 (github pull #1549 from greglandrum)
  - R group improvements
 (github pull #1552 from greglandrum)
  - Add a canned Atom query for heavy atom degree
 (github issue #1563 from greglandrum)
  - Adds FreeSASA adapter
 (github pull #1565 from bp-kelley)
  - Added C++ version of getBestRMS()
 (github pull #1568 from psavery)
  - SMILES lexer optimization/enhancement
 (github pull #1575 from greglandrum)
  - Update IPythonConsole and PandasTools to use new drawing code
 (github pull #1577 from greglandrum)
  - Squashes warnings on cygwin
 (github pull #1578 from bp-kelley)
  - Support continuous highlighting in drawMolecules().
 (github pull #1579 from greglandrum)
  - Enhanced Similarity Maps depiction
 (github pull #1594 from gerebtzoff)

## Bug Fixes:
  - RDKit gets stuck on PubChem CID 102128817
 (github issue #1281 fr

Re: [Rdkit-devel] drawing amino acids

[Greg Landrum]

On Fri, Sep 8, 2017 at 2:10 PM, Igor Filippov 
wrote:

>
>>
>> Could it be that you didn't generate coordinates for the molecule?
>>
>> The result is the same for me whether I load the molecule from an SD file
> with coordinates, or generate 2D or 3D coordinates on the fly.
> Does it display correctly for you?
>

Yeah, This snippet:

In [21]: m = Chem.MolFromSmiles('NC(=O)C(N)[NH3+]')

In [22]: nm = Draw.PrepareMolForDrawing(m)

In [23]: d = Draw.MolDraw2DCairo(200,200)

In [24]: d.DrawMolecule(nm)

In [25]: d.FinishDrawing()

In [26]: open('blah.png','wb+').write(d.GetDrawingText())
Out[26]: 2730


Produces the png file that's attached.


> BTW: rdMolDraw2D.PrepareMolForDrawing() is a useful function to know
>> about.
>>
> I am doing it from c++, is there an equivalent there?
>

Sure, here's some testing code that uses it:
https://github.com/rdkit/rdkit/blob/9af90524a41825b67ffb19cdbff9b363d5a7ca7e/Code/GraphMol/MolDraw2D/test1.cpp#L987

There are a bunch of other examples in that file too.

-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] 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 &file_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  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 
> 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 
>> 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 
>>> 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&utm_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  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 
> 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&utm_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&utm_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

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

[Greg Landrum]

This is now resolved: the boost-1.56 build for python 3.6 on 64bit linux
(the only python3.6 build that's currently done) is in place.
--
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] 2017.03 (Q1 2017) RDKit Release

[Greg Landrum]

Right you are.
I will push those too


From: Maciek Wójcikowski 
Sent: Friday, April 21, 2017 4:37:30 PM
To: Greg Landrum
Cc: RDKit Discuss; rdkit-annou...@lists.sourceforge.net; RDKit Developers List
Subject: Re: [Rdkit-devel] 2017.03 (Q1 2017) RDKit Release

Hi Greg,

Just FYI rdkit for Python 3.6 requires boost 1.56 which has no Python 3.6 
version in your repo. I just tested Linux packages, but it should be the same 
for other platforms.


Pozdrawiam,  |  Best regards,
Maciek Wójcikowski
mac...@wojcikowski.pl<mailto:mac...@wojcikowski.pl>

2017-04-21 6:36 GMT+02:00 Greg Landrum 
mailto:greg.land...@gmail.com>>:
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<http://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<http://anaconda.org/> (https://anaconda.org/rdkit).
- The homebrew script
- The online version of the documentation at rdkit.org<http://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-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 #1268

[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] RDKit installation

[Greg Landrum]

Gayathree,

Those instructions are for installing a binary version of the RDKit. They
are not well suited for setting up an environment where you build from
source.

For the purposes of getting something done quickly while you're preparing
your GSoC application (there's not a lot of time left), I would suggest
that you go ahead and use the binary install and that you make your changes
there. Once you've tested them and think that they are ready for others to
see, you can submit your proposed changes here by just emailing the files
that you changed. This isn't the normal way of doing a submission, and
we'll have to make sure that you have a proper github checkout if your
application is accepted, but it allows you to get going quickly.

The next step would be to find the files that conda install created and
start working with them. Where these files are depend on the details of
your anaconda installation and you'll have to poke around a bit to find
them. Here's where my rdkit source ends up when I conda install it into an
environment named "py35_rdkit":
~/anaconda3/envs/py35_rdkit/lib/python3.5/site-packages/rdkit/

-greg



On Sun, Mar 26, 2017 at 8:45 PM, Gayathree Kaluarachchi <
kalpa.ga...@gmail.com> wrote:

> Hello everyone,
>
> I have installed RDKit using Anaconda and download the latest release of
> RDKit following the steps in http://www.rdkit.org/docs/
> Install.html#cross-platform-under-anaconda-python-fastest-install .
> But I have stuck in next step which is building RDKit. I setup environment
> variable according to the documentation as well.
> It would be much appreciated, if anyone can give me an idea on that and
> give any tip on how to build RDKit in local workspace.
>
> Thank you.
>
> Best regards,
> Gayathree.
>
> 
> --
> 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 and ipywidget installation

[Greg Landrum]

Dear Gayathree,

On Wed, Mar 22, 2017 at 3:46 PM, Gayathree Kaluarachchi <
kalpa.ga...@gmail.com> wrote:

>
> I am Gayathree, a level 3 undergraduate from Faculty of Information
> Technology, University of Moratuwa, Sri Lanka. I am really interested in
> RDKit - 3Dmol.js Integration, a project in GSoC.
> I started to work on it and faced several problems when I was going to
> install Rdkit and ipywidget. I have followed http://www.rdkit.org/
> docs/Install.html#windows to install rdkit and https://ipywidgets.readthe
> docs.io/en/latest/user_install.html#
>  to
> install ipywidgets. But they were not successful.
> So it would be much appreciated, if you could tell me whether I have
> followed correct documents to install them. Also if it is not correct, it
> would be great if you could give me some guidance to setup those
> successfully.
>

I would strongly suggest using anaconda python (instead of the normal
python distribution):
http://www.rdkit.org/docs/Install.html#cross-platform-under-anaconda-python-fastest-install
After you have installed anaconda (by following those instructions) you can
install ipywidgets with: "conda install ipywidgets"

-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]

Yeah, I was testing using master and everything is fine.

On Fri, Feb 24, 2017 at 2:51 PM, Igor Filippov 
wrote:

> Greg,
>
> Thank you for the kind words!
> I should note that I am using a slightly older version of rdkit (half a
> year to a year old), but I don't think it makes a difference as far as
> InChI is concerned.
>
> Best regards,
> Igor
>
>
> On Fri, Feb 24, 2017 at 8:43 AM, Greg Landrum 
> wrote:
>
>> 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] 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

[Rdkit-devel] 2016.09 (Q3 2016) RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit -- 2016.09
(a.k.a. Q3 2016) -- is released. This one is even later than usual since
the RDKit UGM was quite late this year. And then we hit some problems with
the python 2.7 builds on Windows .

The release notes are below.

The release files are on the github release page:
https://github.com/rdkit/rdkit/releases/tag/Release_2016_09_2
Unless there is demand for it, I do not plan to create Windows binaries
this time. Python binaries are best installed using conda and the Java
binaries were very rarely downloaded.

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).

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 2017.

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

Re: [Rdkit-devel] GenerateDepictionMatching3DStructure

[Greg Landrum]

Hi Dave,

On Tue, Nov 22, 2016 at 11:08 AM, David Cosgrove  wrote:

>
> I really couldn't decide whether this should just be for you, or to the
> whole list, so I decided to defer the decision to you!
>

Seems like it's appropriate for the -devel list, so I'm including it on the
reply.


> I'm looking at GenerateDepictionMatching3DStructure in
> $RDBASE/rdkit/Chem/AllChem.py.  There seems to be a discrepancy between
> what it says it does and what it actually does.  As far as I can see, the
> reference molecule needs to be the same as the target molecule in terms of
> atom order up to the number of atoms in the target molecule, it generates a
> distance matrix from the given conformation of the reference and that is
> used to make the 2D coordinates for the target.  I can't see the need for a
> depiction for the reference, as the docstring suggests, and the 'piece of
> the molecule is constrained', whilst technically correct (anything in the
> reference after the number of atoms in the target is ignored) isn't doing
> what I thought it would.
>

Yes, the documentation for that function is pretty badly wrong.


> So, as I move it into the core C++ code, I propose:
> a) Correcting the documentation so that it describes what is happening
> b) Putting some extra checks in, to ensure that, for example, the
> reference molecule has at least as many atoms as the target molecule.
> c) Adding an optional 4th parameter that is a query molecule that will
> allow a mapping of a subset of atoms on the reference onto the target, and
> generating a distance matrix just for those atoms.  That way, you would be
> able to take a set of molecules with a common core that are aligned in 3D
> space and generate a similarly arranged set of 2D depictions.  This would
> not be a breaking change.
>

These changes all make sense to me.

-greg
--
___
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 
Sent: Wednesday, November 9, 2016 12:36 PM
Subject: Re: [Rdkit-devel] Boost and cmake version survey
To: Greg Landrum 
Cc: RDKit Developers List 


On Wed, Nov 9, 2016 at 11:41 AM, Greg Landrum  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] Boost and cmake version survey

[Greg Landrum]

The move to modern C++ is coming (at last!) and when we make it, I would
like to go ahead and specify (relatively) modern minimum versions of boost
and/or cmake. This is your chance to pipe up on what we do here. In case
you have no idea what I'm talking about here, the relevant blog post is:
https://medium.com/@greg.landrum_t5/the-rdkit-and-modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147

First things first: I'm not proposing that we immediately start using a
bunch of new libraries (particularly not new libraries that aren't
header-only), but I would like to have the option of doing so and to make
explicit that versions like 1.41 are just too old.

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.

We've been using 1.56 (or 1.59 for py35 on windows) with the conda builds
and haven't had any complaints about those not working, so I am inclined to
pick *at least* 1.56 as a minimum. I almost want to suggest that we take
1.62 - since that includes QVM (http://boostorg.github.io/qvm/), which I
think could be useful - but that's probably overly radical.

With cmake I don't have as clear of an overview of what the differences
between the versions are, but it seems like updating to require at least
3.0 wouldn't be insane.

Any input/opinions from the community about any of this?

-greg
--
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] Beta of Q3 2016 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/Release_2016_09_1b1

The relevant section of the release notes is below. 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.

Unless someone specifically requests them, I don't plan to do binaries for
the beta.

Unless major problems are found, I plan to do the actual release late next
week. Between now and then I hope to get a few more bugs crushed, and to
integrate PR # (https://github.com/rdkit/rdkit/pull/), but this
should otherwise be essentially it for features..

Best,
-greg

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

## Acknowledgements:
Brian Cole, Piotr Dabrowski, Jan Domanski, Peter Gedeck, Richard Hall, Brian
Kelley, Joos Kiener, 'maddogcz', John Mayfield, 'michalsta', Michal Nowotka,
'philopon', Nico Pulver, Sereina Riniker, Roger Sayle, Nadine Schneider,
Gianluca Sforna, Peter Shenkin, Paolo Tosco, David Turbert, Riccardo
Vianello,
Maciek Wojcikowski

## Highlights:

## New Features and Enhancements:
  - Trajectory/Snapshot objects
 (github pull #863 from ptosco)
  - Adds Avalon fingerprints to default set
 (github pull #871 from bp-kelley)
  - Adds the default index to the building block templates
 (github pull #873 from bp-kelley)
  - Pandas: Allow reading just the properties from SDF file
 (github pull #883 from mwojcikowski)
  - Dev/filtercatalog functional groups
 (github pull #885 from bp-kelley)
  - Dev/preprocessrxn cpp
 (github pull #892 from bp-kelley)
  - Rollup of warning squashing (with some tests diagnostics thrown in)
 (github pull #895 from bp-kelley)
  - Adds RDAny (smaller generic holder) Updates all used dictionaries
 (github pull #896 from bp-kelley)
  - expose FPS functions to SWIG
 (github pull #897 from greglandrum)
  - Add SaveFile method to the PyMol wrapper
 (github pull #898 from greglandrum)
  - Add a MultiFPBReader class
 (github pull #909 from greglandrum)
  - Improved Python doc strings for Trajectory/Snapshot objects
 (github pull #912 from ptosco)
  - Added support for building the gzip'd stream test
 (github pull #914 from ptosco)
  - Improved Trajectory Python doc strings
 (github pull #915 from ptosco)
  - improve error reporting for kekulization failures
 (github pull #919 from greglandrum)
  - Feat/github934
 (github pull #939 from greglandrum)
  - Add support for a simplified aromaticity model.
 (github pull #942 from greglandrum)
  - Dev/moldescriptors callables
 (github pull #944 from bp-kelley)
  - Dev/cleanup warnings
 (github pull #948 from greglandrum)
  - Modifications to enable building with MinGW compilers
 (github pull #960 from ptosco)
  - Made DistGeomHelpers test robust against small 3D coordinate variations
 (github pull #961 from ptosco)
  - Adds aromatization and reaction options to AdjustQuery
 (github pull #965 from bp-kelley)
  - Improved planarity for ETKDG
 (github pull #967 from sriniker)
  - Java wrappers for Trajectory/Snapshot objects
 (github pull #977 from ptosco)
  - Fixes built-in popcount in PgSQL cartridge on Windows
 (github pull #978 from ptosco)
  - A variety of drawing-related changes
 (github pull #986 from greglandrum)
  - support "OR" for adjust query flags in cartridge
 (github issue #987 from greglandrum)
  - Expose the aromatizeIfPossible parameter to python
 (github pull #991 from greglandrum)
  - refactoring of the postgresql cartridge
 (github pull #992 from rvianello)
  - - Get pango 2D depiction to work with cairocffi
 (github pull #998 from ptosco)
  - Adds Atom atom map and rlabel apis
 (github pull #1004 from bp-kelley)
  - Dev/chemtransforms chirality
 (github pull #1006 from bp-kelley)
  - Added the option to label deuterium and tritium as D and T
 (github pull #1011 from ptosco)
  - Adds replaceCore function that takes a matchVect
 (github pull #1013 from bp-kelley)
  - Add an initial version of wavy bonds
 (github pull #1014 from greglandrum)
  - remove a compiler warning
 (github pull #1019 from greglandrum)
  - Make the Contrib directory available in RDConfig
 (github pull #1024 from NadineSchneider)
  - Adds some additional canned atom and bond query definitions
 (github pull #1047 from greglandrum)
  - Draw crossed bonds
 (github pull #1052 from greglandrum)
  - Alex/struct checker apr15
 (github pull #1054 from bp-kelley)
  - MolDraw2D: allow the amount of padding around atom labels to be
adjusted.
 (github issue #1056 from greglandrum)
  - Add multiple molecule drawing to the C++ interface
 (github pull #1059 from greglandrum)
  - add pickle support to FilterCatalog
 (github pull #1063 from greglandrum)
  - Issue #1066: Improved .gitignore file
 (github pull #1068 from gedeck)
  - Cleanup of Scaffolds Python code
 (github pull #1069 from gedeck)
  - Consistent formattin

Re: [Rdkit-devel] Failing test 103 on cutting edge Fedora

[Greg Landrum]

It's something with the python InChI wrappers:
103: !!! TEST FAILURE:  python UnitTestInchi.py {}103/103 Test #103: 
pythonTestDirChem ***Failed   35.63 secThe following tests 
passed: testInchi ...
The fact that the testInchi one passed indicates that the C++ build completed 
and worked, but something has gone wrong with the installation of the inchi 
wrapper.I'll try to take a look in more detail tomorrow morning (I have some 
more prep for the UGM that I need to do, but I'll try and make time for this 
too)







On Tue, Oct 25, 2016 at 9:43 PM +0200, "Gianluca Sforna"  
wrote:










Thanks Greg,
here is the new build log:
https://kojipkgs.fedoraproject.org//work/tasks/9220/16199220/build.log

On Tue, Oct 25, 2016 at 5:33 PM, Greg Landrum  wrote:
> I don't see anything obvious and there's not currently an easy way to figure
> out what the problem is (but I'm fixing that now).
>
> Using this diff as a patch (not sure what syntax you want) will provide more
> info about which test failed:
> landrum@Otter:/scratch/RDKit_git/build$ git diff ../rdkit/TestRunner.py
> diff --git a/rdkit/TestRunner.py b/rdkit/TestRunner.py
> index 99432dc..308dbfd 100755
> --- a/rdkit/TestRunner.py
> +++ b/rdkit/TestRunner.py
> @@ -106,6 +106,9 @@ def RunScript(script, doLongTests, verbose):
>
>nTests = len(tests) + len(longTests)
>del sys.modules[script]
> +  if verbose and failed:
> +for exeName,args,extras in failed:
> +print("!!! TEST FAILURE: ",exeName,args,extras,file=sys.stderr)
>return failed, nTests
>
>
>
> On Tue, Oct 25, 2016 at 4:02 PM, Gianluca Sforna  wrote:
>>
>> I am trying to rebuild the rdkit RPM for Fedora rawhide (aka Fedora
>> 26) but the i686 build fails at test 103.
>>
>> Looking at the log [1], can anyone spot what the issue could be?
>>
>> Regards
>>
>> G.
>>
>>
>> [1] https://kojipkgs.fedoraproject.org//work/tasks/6457/16196457/build.log
>>
>> --
>> Gianluca Sforna
>>
>> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>> Tinker Garage - http://tinkergarage.it
>>
>>
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> Rdkit-devel mailing list
>> Rdkit-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>



-- 
Gianluca Sforna

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





--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] Failing test 103 on cutting edge Fedora

[Greg Landrum]

I don't see anything obvious and there's not currently an easy way to
figure out what the problem is (but I'm fixing that now).

Using this diff as a patch (not sure what syntax you want) will provide
more info about which test failed:
landrum@Otter:/scratch/RDKit_git/build$ git diff ../rdkit/TestRunner.py
diff --git a/rdkit/TestRunner.py b/rdkit/TestRunner.py
index 99432dc..308dbfd 100755
--- a/rdkit/TestRunner.py
+++ b/rdkit/TestRunner.py
@@ -106,6 +106,9 @@ def RunScript(script, doLongTests, verbose):

   nTests = len(tests) + len(longTests)
   del sys.modules[script]
+  if verbose and failed:
+for exeName,args,extras in failed:
+print("!!! TEST FAILURE: ",exeName,args,extras,file=sys.stderr)
   return failed, nTests



On Tue, Oct 25, 2016 at 4:02 PM, Gianluca Sforna  wrote:

> I am trying to rebuild the rdkit RPM for Fedora rawhide (aka Fedora
> 26) but the i686 build fails at test 103.
>
> Looking at the log [1], can anyone spot what the issue could be?
>
> Regards
>
> G.
>
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/6457/16196457/build.log
>
> --
> Gianluca Sforna
>
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
> Tinker Garage - http://tinkergarage.it
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
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]

Great.
After this next round of travis builds passes I will merge the two
outstanding PRs and then do the release.

-greg


On Fri, Apr 15, 2016 at 7:07 PM, Gianluca Sforna  wrote:

> On Fri, Apr 15, 2016 at 1:36 PM, Greg Landrum 
> wrote:
> > Would you be comfortable with me doing the release based on the current
> > state of the code (once that PR is merged, of course)?
>
> Yes, I guess we're good to go.
> As soon as we have the final tarball I will build RHEL 7 and Fedora
> RPMs at the usual COPR location, then will have a look at software
> collections.
>
>
>
> --
> 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]

On Fri, Apr 15, 2016 at 1:18 PM, Gianluca Sforna  wrote:

> On Fri, Apr 15, 2016 at 11:20 AM, Greg Landrum 
> 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  wrote:

> On Fri, Apr 15, 2016 at 4:41 AM, Greg Landrum  > 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 
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 
> 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 
>> wrote:
>> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum 
>> 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  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 
> wrote:
> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum 
> 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  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 
> 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 
>> 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 
>>> 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 
>>> 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 
>>>> 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] More build fun with RHEL 6

[Greg Landrum]

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  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  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 
> 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 
>> wrote:
>> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum 
>> 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] More build fun with RHEL 6

[Greg Landrum]

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  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 
> wrote:
> > On Thu, Apr 14, 2016 at 11:37 AM, Greg Landrum 
> 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]

Gianluca,

Which version of boost are you using?

-greg


On Thu, Apr 14, 2016 at 11:33 AM, Gianluca Sforna  wrote:

> The RPM build for Fedora worked so I moved to RHEL/CentOS and got a new
> error:
>
>
> In file included from /usr/include/boost/python/to_python_indirect.hpp:10,
>  from
> /usr/include/boost/python/converter/arg_to_python.hpp:10,
>  from /usr/include/boost/python/call.hpp:15,
>  from /usr/include/boost/python/object_core.hpp:12,
>  from /usr/include/boost/python/args.hpp:25,
>  from /usr/include/boost/python.hpp:11,
>  from
>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/RDBoost/python.h:2,
>  from
>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/FilterCatalog/Wrap/FilterCatalog.cpp:31:
> /usr/include/boost/python/object/pointer_holder.hpp: In member
> function 'void* boost::python::objects::pointer_holder Value>::holds
> (boost::python::type_info, bool) [with Pointer =
> boost::shared_ptr, Value = const
> RDKit::FilterCatalogEntry
> ]':
>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/FilterCatalog/Wrap/FilterCatalog.cpp:463:
>   instantiated from here
> /usr/include/boost/python/object/pointer_holder.hpp:145: error:
> invalid conversion from 'const void*' to 'void*'
> /usr/include/boost/python/object/pointer_holder.hpp:145: error:
> initializing argument 1 of 'void*
> boost::python::objects::find_dynamic_type(void*,
> boost::python::type_info, boost::python::type_info)'
> /usr/include/boost/python/object/pointer_holder.hpp:145: error:
> invalid conversion from 'const void*' to 'void*'
>
> anything we can do to make it work on this older compiler?
>
> Talking about this, I'd like to note the compilation is pretty noisy
> because of some pragmas not supported by GCC until version 4.6. I
> applied the attached patch to silence them.
>
>
>
> --
> 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] Beta of Q1 2016 release now up

[Greg Landrum]

On Wed, Apr 13, 2016 at 8:43 PM, Gianluca Sforna  wrote:

> On Wed, Apr 13, 2016 at 12:27 PM, Greg Landrum 
> wrote:
> > Wow, that's a "typing in the wrong buffer" bug.
> > Great catch.
>
> :)
>
> Another couple points.
> I noticed the RDKit_Overview.pdf file is not there anymore. Was it
> integrated in the main manual, moved somewhere else or just removed?
>

The information in the pdf and the odb source for it were pretty out of
date, they've been removed. Docs/Book/Overview.md and the other contents of
the Docs/Book directory are a better information source.


> Regarding PostgreSQL cartridge, I expected the build to fail since I
> knew it was ported to cmake; instead, the older recipe just worked, I
> don't know if this is intended or not.
>

I didn't see a reason to immediately remove the old cartridge build make
system and break things for people who are used to using it. It will be
deprecated and removed in a future release.


> Finally, Docs were not building anymore, it seems some stray char was
> left in a file, so I needed to apply this:
>

Fixed.

-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] Beta of Q1 2016 release now up

[Greg Landrum]

Wow, that's a "typing in the wrong buffer" bug.
Great catch.

I will check in the fix in the next couple of minutes.

On Wed, Apr 13, 2016 at 12:09 PM, Gianluca Sforna  wrote:

> I bisected with git the issue, it popped up after commit b76d1a9 last
> december.
>
> I know almost nothing about flex & bison, but I noticed a suspicious
> change in the diff, and indeed the following patch fixes the build:
>
>  diff --git a/Code/GraphMol/SmilesParse/smiles.ll
> b/Code/GraphMol/SmilesParse/smiles.ll
> index 3a2346e..1f1cd27 100644
> --- a/Code/GraphMol/SmilesParse/smiles.ll
> +++ b/Code/GraphMol/SmilesParse/smiles.ll
> @@ -1,4 +1,4 @@
> -%setpropoption reentrant
> +%option reentrant
>  %option bison-bridge
>  %option noyywrap
>
> Was it correct?
>
>
>
> On Wed, Apr 13, 2016 at 10:44 AM, Greg Landrum 
> wrote:
> > Hi Gianluca,
> >
> > On Tue, Apr 12, 2016 at 1:09 PM, Gianluca Sforna 
> wrote:
> >>
> >>
> >> But no joy still
> >>
> >>
> >> [ 36%] Building CXX object
> >> Code/GraphMol/SmilesParse/CMakeFiles/SmilesParse.dir/lex.yysmarts.cpp.o
> >> cd
> >>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse
> >> && /usr/bin/c++   -DRDK_64BIT_BUILD -DRDK_TEST_MULTITHR
> >> EADED -DRDK_USE_STRICT_ROTOR_DEFINITION -DSmilesParse_EXPORTS
> >> -I/usr/include/python2.7
> >> -I/builddir/build/BUILD/rdkit-Release_2016_03_1b1/pyt
> >> hon2/Code  -O2 -g -pipe -Wall -Werror=format-security
> >> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> >> --param=ssp-buffer-size=
> >> 4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> >> -m64 -mtune=generic  -mpopcnt -Wno-deprecated -Wno-unused-function -f
> >> no-strict-aliasing -fPIC -Wall -Wextra -O2 -g -DNDEBUG -fPIC
> >> -DRDK_THREADSAFE_SSS -DBOOST_ALL_NO_LIB -o
> >> CMakeFiles/SmilesParse.dir/lex.yys
> >> marts.cpp.o -c
> >>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmarts.cpp
> >> smiles.ll:40:52: error: 'yyscan_t' has not been declared
> >>  size_t setup_smiles_string(const std::string &text,yyscan_t yyscanner){
> >> ^
> >> smiles.ll: In function 'size_t setup_smiles_string(const string&, int)':
> >> smiles.ll:49:46: error: too many arguments to function 'void*
> >> yysmiles_alloc(yy_size_t)'
> >>buf = (char *) yysmiles_alloc(n ,yyscanner );
> >>   ^
> >>
> >>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmiles.cpp:326:7:
> >> note: declared here
> >>  void *yysmiles_alloc (yy_size_t  );
> >>^
> >> smiles.ll:69:45: error: too many arguments to function
> >> 'yy_buffer_state* yysmiles__scan_buffer(char*, yy_size_t)'
> >>b = yysmiles__scan_buffer(buf,n ,yyscanner);
> >>  ^
> >>
> >>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmiles.cpp:322:17:
> >> note: declared here
> >>  YY_BUFFER_STATE yysmiles__scan_buffer (char *base,yy_size_t size  );
> >
> >
> >
> > Something odd is going on with the output of flex. The easiest way to
> "fix"
> > this is just to avoid the problem by not running flex/bison yourself.
> >
> > If that would be ok, you can just change the cmake command line argment
> > -D RDK_USE_FLEXBISON:BOOL=ON
> > to
> > -D RDK_USE_FLEXBISON:BOOL=OFF
> >
> > -greg
> >
>
>
>
> --
> 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] Beta of Q1 2016 release now up

[Greg Landrum]

Hi Gianluca,

On Tue, Apr 12, 2016 at 1:09 PM, Gianluca Sforna  wrote:

>
> But no joy still
>
>
> [ 36%] Building CXX object
> Code/GraphMol/SmilesParse/CMakeFiles/SmilesParse.dir/lex.yysmarts.cpp.o
> cd
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse
> && /usr/bin/c++   -DRDK_64BIT_BUILD -DRDK_TEST_MULTITHR
> EADED -DRDK_USE_STRICT_ROTOR_DEFINITION -DSmilesParse_EXPORTS
> -I/usr/include/python2.7
> -I/builddir/build/BUILD/rdkit-Release_2016_03_1b1/pyt
> hon2/Code  -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=
> 4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -m64 -mtune=generic  -mpopcnt -Wno-deprecated -Wno-unused-function -f
> no-strict-aliasing -fPIC -Wall -Wextra -O2 -g -DNDEBUG -fPIC
> -DRDK_THREADSAFE_SSS -DBOOST_ALL_NO_LIB -o
> CMakeFiles/SmilesParse.dir/lex.yys
> marts.cpp.o -c
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmarts.cpp
> smiles.ll:40:52: error: 'yyscan_t' has not been declared
>  size_t setup_smiles_string(const std::string &text,yyscan_t yyscanner){
> ^
> smiles.ll: In function 'size_t setup_smiles_string(const string&, int)':
> smiles.ll:49:46: error: too many arguments to function 'void*
> yysmiles_alloc(yy_size_t)'
>buf = (char *) yysmiles_alloc(n ,yyscanner );
>   ^
>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmiles.cpp:326:7:
> note: declared here
>  void *yysmiles_alloc (yy_size_t  );
>^
> smiles.ll:69:45: error: too many arguments to function
> 'yy_buffer_state* yysmiles__scan_buffer(char*, yy_size_t)'
>b = yysmiles__scan_buffer(buf,n ,yyscanner);
>  ^
>
> /builddir/build/BUILD/rdkit-Release_2016_03_1b1/python2/Code/GraphMol/SmilesParse/lex.yysmiles.cpp:322:17:
> note: declared here
>  YY_BUFFER_STATE yysmiles__scan_buffer (char *base,yy_size_t size  );



Something odd is going on with the output of flex. The easiest way to "fix"
this is just to avoid the problem by not running flex/bison yourself.

If that would be ok, you can just change the cmake command line argment
-D RDK_USE_FLEXBISON:BOOL=ON
to
-D RDK_USE_FLEXBISON:BOOL=OFF

-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] Beta of Q1 2016 release now up

[Greg Landrum]

Gianluca,

This could be the issue fixed by this PR from Matt Swain:
https://github.com/rdkit/rdkit/pull/856

-greg


On Mon, Apr 11, 2016 at 12:32 PM, Gianluca Sforna  wrote:

> On Thu, Apr 7, 2016 at 6:24 AM, Greg Landrum 
> wrote:
> > I have tagged a beta of the next RDKit release here:
> > https://github.com/rdkit/rdkit/releases/tag/Release_2016_03_1b1
>
>
> Tried to rebuild the RPMs but got this right on cmake:
>
> -- Found INCHI: /usr/lib64/libinchi.so
> CMake Error at External/INCHI-API/CMakeLists.txt:64 (install):
>   install TARGETS given target "Inchi" which does not exist in this
>   directory.
>
>
> cmake invocation as follow:
>
> /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -D RDK_INSTALL_INTREE=OFF -D
> CMAKE_BUILD_TYPE=RelWithDebInfo -D RDK_BUILD_INCHI_SUPPORT:BOOL=ON -D
> RDK_BUILD_THREADSAFE_SSS:BOOL=ON -D RDK_BUILD_CAIRO_SUPPORT:BOOL=ON -D
> RDK_INSTALL_STATIC_LIBS:BOOL=OFF -D RDK_USE_FLEXBISON:BOOL=ON -D
> RDK_TEST_MULTITHREADED:BOOL=ON -D
> PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2 .
>
> I'll dig in it later, in the meanwhile if you have ideas they will be
> very welcome.
>
--
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! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] Beta of Q1 2016 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/Release_2016_03_1b1

The relevant section of the release notes is below. 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.

Unless someone specifically requests them, I don't plan to do binaries for
the beta.

Unless major problems are found, I plan to do the actual release late next
week. Between now and then I hope to get a few more bugs crushed, but there
shouldn't be any additional feature additions.

Best,
-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, Rich Lewis, Daniel Lowe, 'maddogcz',
Kozo
Nishida, Michal Nowotka, Axel Pahl, Steven Roughley, Alexander Savelyev,
Nadine
Schneider, Teague Sterling, Nik Stiefl, Matt Swain, Eric Ting, Paolo Tosco,
Samo
Turk, JL Varjo, 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 is declared  should be unsigned int?
 (github issue #717 from bp-kelley)
  - ensure line endings are handled consistently for all users
 (github pull #729 from rvianello)
  - Fixes return type of operator[] (fails on later clangs)
 (github pull #733 from bp-kelley)
  - Fix/thread safe localeswitcher line endings
 (github pull #743 from bp-kelley)
  - Fixes Boost 1.46 issues with type traits
 (github pull #748 from bp-kelley)
  - PR #749 causes seg faults on windows
 (github issue #750 from greglandrum)
  - Fixes notebook problems with newer jupyter installs
 (github pull #753 from bp-kelley)
  - Double bond geometry loss on calling 

Re: [Rdkit-devel] Pharm2D -- 4-point pharmacophores

[Greg Landrum]

Hi Ondrej,

There's an illustration of the representation here:
http://rdkit.org/docs/RDKit_Book.html#representation-of-pharmacophore-fingerprints
Some discussion in the code of the terminology used:
https://github.com/rdkit/rdkit/blob/master/rdkit/Chem/Pharm2D/Generate.py#L11
and an illustration of the way the distances are defined:
https://github.com/rdkit/rdkit/blob/master/Docs/Code/Chem/Pharm2D.triangles.jpg

It's been a while since I really looked at that code, but I don'd think
there's really any reason why support for more than 3 features couldn't be
enabled.

-greg


On Tue, Feb 9, 2016 at 10:02 PM, Ondrej Micka  wrote:

> Hello,
> I'd like to implement four-point (or generally N-point) pharmacophores
> into rdkit's  Pharm2D module. It seems that same parts of the module can
> support more-than-three-point pharmacophores without any modification,
> while some other can't. Is there any more thorough documentation than
> the one generated by epydoc which could help me uderstand how the
> generation of 2D pharmacophore fingerprints works?
> Thanks,
> Ondrej
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit binaries available for Win32 .Net?

[Greg Landrum]

Hi Tom,

There's never really been demand for such a thing. It ought to be doable. I
will investigate and see what I can come up with.

-greg


On Sun, Feb 7, 2016 at 7:27 PM, Tom Hagadone  wrote:

> Hello All:
>
> We have a need to be able to call RDKit from an existing Win32 C#.Net app.
> I've been trying to build from source using the existing RDKit SWIG wrapper
> for C#. I haven't had any success yet after two days of trying to sort out
> various SWIG/Boost-related issues. Does anyone know if there is a prebuilt
> Win32.Net RDKit binary (similar to the Win32.Java binary) available
> anywhere? If not, I fear my only option will be to implement a MSVC C++
> Interop solution to bridge between C# and C++.
>
> Thanks,
> Tom Hagadone
> Eli Lilly and Company
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> ___
> Rdkit-devel mailing list
> Rdkit-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] failing with rdkit.Chem.PyMol.MolViewer()

[Greg Landrum]

Hi Zhenquan,

Did you start PyMol with the "-R" flag so that it is running the xmlrpc
server?
You can verify this by looking in the PyMol console for text like this:
"xml-rpc server running on host localhost, port 9123"

-greg



On Wed, Jan 6, 2016 at 2:16 AM, Zhenquan Hu  wrote:

> Dear all,
>
> Recently I tried to install RDKit on ubuntu-14.04/CentOS7.1. First I tried
> with the pre-build version, then compiled with the git source code. Neither
> could call the module Chem.PyMol.MolViewer().
> It looks like something wrong with xmlrpc, but I have no idea about the
> detail.
>
> Anyone knows why?
>
> best,
> Zhenquan
>
> test.py
> #==
> from rdkit.Chem import PyMol
> v = PyMol.MolViewer()
> #==
>
> python test.py
> #===
> Traceback (most recent call last):
>   File "test.py", line 3, in 
> v=PyMol.MolViewer()
>   File "/opt/rdkit/rdkit/Chem/PyMol.py", line 35, in __init__
> serv.ping()
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
> return self.__send(self.__name, args)
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
> verbose=self.__verbose
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
> return self.single_request(host, handler, request_body, verbose)
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1301, in single_request
> self.send_content(h, request_body)
>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1448, in send_content
> connection.endheaders(request_body)
>   File "/usr/lib64/python2.7/httplib.py", line 975, in endheaders
> self._send_output(message_body)
>   File "/usr/lib64/python2.7/httplib.py", line 835, in _send_output
> self.send(msg)
>   File "/usr/lib64/python2.7/httplib.py", line 797, in send
> self.connect()
>   File "/usr/lib64/python2.7/httplib.py", line 778, in connect
> self.timeout, self.source_address)
>   File "/usr/lib64/python2.7/socket.py", line 571, in create_connection
> raise err
> socket.error: [Errno 111] Connection refused
> #=
>
>
>
> --
>
> ___
> 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] 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&iu=/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&iu=/4140___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] [Rdkit-announce] 2015.09 (Q3 2015) RDKit Release

[Greg Landrum]

And I have now pushed the python 2.7 and python 3.4 builds for the Mac to
the rdkit channel at anaconda.org.

-greg

On Mon, Nov 23, 2015 at 11:04 PM, Riccardo Vianello <
riccardo.viane...@gmail.com> wrote:

>
> ​Dear all,
>
> RDKit 2015.09.2 conda packages for linux and win-64 are now available for
> download from the rdkit channel on anaconda.org. This build includes
> python3 packages for windows too (thanks Paolo Tosco for help building
> boost). I'll send an update when win-32 pkgs are also online.
>
> Best,
> Riccardo
>
--
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=254741551&iu=/4140___
Rdkit-devel mailing list
Rdkit-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] 2015.09 (Q3 2015) RDKit Release

[Greg Landrum]

Dear all,

I'm pleased to announce that the next version of the RDKit -- 2015.09
(a.k.a. Q3 2015) -- is released. The new RDKit release theme is: Better
late than never. :-)

Note that this is a patch release (the version number ends in _2). We
discovered a couple of problems in the original release before I actually
announced it and decided we should fix those before announcing the release.

The release notes are below.

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

I will be uploading 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.

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/

Conda builds will start to appear in the RDKit channel at anaconda.org (
https://anaconda.org/rdkit) over the next few days.

We have updated the homebrew recipe and will update the conda build script
to reflect the new version.

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 March 2016.

Best Regards,
-greg

# Release_2015.09.2
(Changes relative to Release_2015.09.1)

## Acknowledgements:
Brian Kelley, Paolo Tosco, Riccardo Vianello

## Bug Fixes:
  - Fixed a post-decrement which causes a crash when compiling under
Windows with MSVC 9
  (from ptosco)
  - Fixes a memory leak in fragmentMol
  (github #669 from bp-kelley)
  - MMPA compile error with Microsoft Visual C++ Compiler for Python 2.7
  (github #655 from rvianello)

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

## Acknowledgements:

Pierre Bhoorasingh, Gungor Budak, Andrew Dalke, JP Ebejer, Peter Ertl,
Jan Holst Jensen, Brian Kelley, Joos Kiener, Noel O'Boyle, Axel Pahl,
Sereina Riniker, Alexander Savelyev, Roger Sayle, Nadine Schneider,
Andrew Stretton, Paolo Tosco, Samo Turk, JL Varjo, Riccardo Vanello,
Maciek Wojcikowski

## Highlights:

  - Addition of parsers/writers for sequence notation, FASTA, and basic HELM
  - Improved conformation generation based on experimental torsional
parameters
  - Much better filtering of generated conformations to ensure they
match the chirality of the input structure
  - New method for enumerating molecular resonance structures
  - Addition of a molecular FilterCatalog data structure

## Bug Fixes:
  - Draw.MolToImage(mol) does not work for Python 3, because cairo for
Python 3 has not yet implemented Surface.create_for_data
 (github issue #460 from apahl)
  - SDWriter.close() fails when the underlying stream has an error
 (github issue #498 from greglandrum)
  - Hexafluorophosphate cannot be handled
 (github issue #510 from greglandrum)
  - Labels of highlighted atoms are invisible
 (github issue #519 from NadineSchneider)
  - MolDraw2D: Fix in highlighting atoms
 (github pull #521 from NadineSchneider)
  - Cartridge: index failing for molecular equality in some circumstances
 (github issue #525 from greglandrum)
  - Bad ring finding in a complex fused ring
 (github issue #526 from greglandrum)
  - Fixed crash upon closing a gzip/bzip2 stream opened in binary mode for
use with SDWriter under Python3
 (github pull #531 from ptosco)
  - Regression: _smilesAtomOutputOrder incorrect for dot disconnected
molecules
 (github issue #532 from baoilleach)
  - Fix #532 - smilesAtomOutputOrder incorrect
 (github pull #535 from baoilleach)
  - Fix Python3 encoding for FilterCatalog/Entry serialization
 (github pull #537 from bp-kelley)
  - Catalog::setCatalogParams needs to be virtual now
 (github pull #538 from bp-kelley)
  - Bonds in allyl cation are not conjugated
 (github issue #539 from greglandrum)
  - Fixes GitHub issue 539
 (github pull #540 from ptosco)
  - SaltBuilder._initPatterns incorrectly handles SMARTS errors
 (github issue #541 from adalke)
  - merging query Hs failing on recursive SMARTS
 (github issue #544 from greglandrum)
  - Crash in O3A alignment when running multi-threaded
 (github issue #546 from greglandrum)
  - PyMol.py: changed xmlrpc import to have Python2/Python3 compatibility
 (github pull #547 from apahl)
  - fix MMPA bugs for some tests
 (github pull #548 from AlexanderSavelyev)
  - TFD fix for single bonds adjacent to triple bonds
 (github pull #550 from sriniker)
  - Canonicalization paper Aug2015
 (github pull #552 from NadineSchneider)
  - Chirality not affected by atom-map index
 (github issue #553 from adalke)
  - Implicit Hs should not appear in depictions for query atoms.
 (github issue #556 from greglandrum)
  - Fix issue with invalid reactions throwing NameError
 (github pull #559 from bp-k

Re: [Rdkit-devel] PDF Book

[Greg Landrum]

hmmm, I replied too quickly: that's already fixed in git.

The PDF book is no longer checked in (it needs to be built with the rest of
the docs). It was in git up until June, but I removed it after Michael
Banck pointed out the old version (https://github.com/rdkit/rdkit/issues/516
)

Maybe the copy you have in the directory is from an old pull?

-greg


On Sat, Nov 7, 2015 at 4:47 AM, Greg Landrum  wrote:

> Thanks for pointing that out. I'll fix it.
>
> -greg
>
>
> On Fri, Nov 6, 2015 at 8:42 PM, Gianluca Sforna  wrote:
>
>> I noticed the RDKit Book I find in Docs/Book after the build claims to
>> be from the 2013.09 release.
>>
>> Is it correct? Maybe it's just in need of a rebuild?
>>
>> Regards
>>
>> G.
>>
>> --
>> Gianluca Sforna
>>
>> http://morefedora.blogspot.com
>> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>>
>>
>> --
>> ___
>> 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] PDF Book

[Greg Landrum]

Thanks for pointing that out. I'll fix it.

-greg


On Fri, Nov 6, 2015 at 8:42 PM, Gianluca Sforna  wrote:

> I noticed the RDKit Book I find in Docs/Book after the build claims to
> be from the 2013.09 release.
>
> Is it correct? Maybe it's just in need of a rebuild?
>
> Regards
>
> G.
>
> --
> Gianluca Sforna
>
> http://morefedora.blogspot.com
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
>
>
> --
> ___
> 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] Beta of Q3 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/Release_2015_09_1beta1

The relevant section of the release notes is below. Note that the list of
people in the acknowledgement section was mostly created automatically from
github. If you feel like I missed you, please let me know so that I can
update the release notes before the actual release.

I will try to get windows binaries up in the next few days, but I'm not
sure this is going to happen.

Unless major problems are found, I plan to do the actual release in the
next week or so. Between now and then I hope to get a few more bugs
crushed, but there shouldn't be any additional feature additions.

Best,
-greg


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

## Acknowledgements:

Pierre Bhoorasingh, Gungor Budak, Andrew Dalke, JP Ebejer, Peter Ertl,
Jan Holst Jensen, Brian Kelley, Joos Kiener, Noel O'Boyle, Axel Pahl,
Sereina Riniker, Alexander Savelyev, Roger Sayle, Nadine Schneider,
Andrew Stretton, Paolo Tosco, Samo Turk, JL Varjo, Riccardo Vanello,
Maciek Wojcikowski

## Highlights:

  - Addition of parsers/writers for sequence notation, FASTA, and basic HELM
  - Improved conformation generation based on experimental torsional
parameters
  - New method for enumerating molecular resonance structures
  - Addition of a molecular FilterCatalog data structure

## Bug Fixes:
  - Draw.MolToImage(mol) does not work for Python 3, because cairo for
Python 3 has not yet implemented Surface.create_for_data
 (github issue #460 from apahl)
  - SDWriter.close() fails when the underlying stream has an error
 (github issue #498 from greglandrum)
  - Hexafluorophosphate cannot be handled
 (github issue #510 from greglandrum)
  - Labels of highlighted atoms are invisible
 (github issue #519 from NadineSchneider)
  - MolDraw2D: Fix in highlighting atoms
 (github pull #521 from NadineSchneider)
  - Bad ring finding in a complex fused ring
 (github issue #526 from greglandrum)
  - Fixed crash upon closing a gzip/bzip2 stream opened in binary mode for
use with SDWriter under Python3
 (github pull #531 from ptosco)
  - Regression: _smilesAtomOutputOrder incorrect for dot disconnected
molecules
 (github issue #532 from baoilleach)
  - Fix #532 - smilesAtomOutputOrder incorrect
 (github pull #535 from baoilleach)
  - Fix Python3 encoding for FilterCatalog/Entry serialization
 (github pull #537 from bp-kelley)
  - Catalog::setCatalogParams needs to be virtual now
 (github pull #538 from bp-kelley)
  - Bonds in allyl cation are not conjugated
 (github issue #539 from greglandrum)
  - Fixes GitHub issue 539
 (github pull #540 from ptosco)
  - SaltBuilder._initPatterns incorrectly handles SMARTS errors
 (github issue #541 from adalke)
  - merging query Hs failing on recursive SMARTS
 (github issue #544 from greglandrum)
  - Crash in O3A alignment when running multi-threaded
 (github issue #546 from greglandrum)
  - PyMol.py: changed xmlrpc import to have Python2/Python3 compatibility
 (github pull #547 from apahl)
  - fix MMPA bugs for some tests
 (github pull #548 from AlexanderSavelyev)
  - TFD fix for single bonds adjacent to triple bonds
 (github pull #550 from sriniker)
  - Canonicalization paper Aug2015
 (github pull #552 from NadineSchneider)
  - Chirality not affected by atom-map index
 (github issue #553 from adalke)
  - Implicit Hs should not appear in depictions for query atoms.
 (github issue #556 from greglandrum)
  - Fix issue with invalid reactions throwing NameError
 (github pull #559 from bp-kelley)
  - InChI radicals not properly converted
 (github issue #562 from pierrelb)
  - MMPA code not python3 compatible
 (github issue #564 from greglandrum)
  - mmpa: fix bug with num_of_cuts > 2 case
 (github pull #566 from AlexanderSavelyev)
  - Incorrect stereochemistry after embedding
 (github issue #568 from greglandrum)
  - changed FrameToGridImage() so that the dataframe index can be used as
legend
 (github pull #570 from apahl)
  - MolDraw2DCairo.GetDrawingText() doesn't work with Python3
 (github issue #571 from greglandrum)
  - addBond return value
 (github issue #572 from JLVarjo)
  - Process aborts during ForwardSDMolSupplier gc when the file object is
closed
 (github issue #579 from adalke)
  - Fix/update pains filter catalog
 (github pull #581 from bp-kelley)
  - Importing PandasTools on Windows fails due to Salts.txt
 (github issue #583 from baoilleach)
  - renumberAtoms() not setting conformer dimensionality properly
 (github issue #584 from greglandrum)
  - stereo atoms property on double bonds not being updated properly with
insertMol
 (github issue #608 from greglandrum)
  - UFF Atom type not properly assigned to lanthanides
 (github issue #613 from greglandrum)
  - segfault from MolToInchi when bad bond stereochem info is present
 (github issue #614 from greglandrum)
  - MQN12 (heavy atom count) seems to be always 0.
 (github issue #623 from kienerj)
  - fmcs: fix issue with initial