rdkit-devel — Developers information and discussion.

Re: [Rdkit-devel] Rdkit and ipywidget installation

[Greg L. <gre...@gm...>]

Dear Gayathree,

On Wed, Mar 22, 2017 at 3:46 PM, Gayathree Kaluarachchi <
kal...@gm...> 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#
> <https://ipywidgets.readthedocs.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

Re: [Rdkit-devel] InChI 1.05

[Igor F. <igo...@gm...>]

Great!

On Fri, Feb 24, 2017 at 8:55 AM, Greg Landrum <gre...@gm...>
wrote:

> Yeah, I was testing using master and everything is fine.
>
> On Fri, Feb 24, 2017 at 2:51 PM, Igor Filippov <igo...@gm...>
> 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 <gre...@gm...>
>> 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 <
>>> igo...@gm...> 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
>>>> Rdk...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>>>
>>>>
>>>
>>
>

Re: [Rdkit-devel] InChI 1.05

[Greg L. <gre...@gm...>]

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

On Fri, Feb 24, 2017 at 2:51 PM, Igor Filippov <igo...@gm...>
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 <gre...@gm...>
> 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 <igo...@gm...
>> > 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
>>> Rdk...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>>
>>>
>>
>

Re: [Rdkit-devel] InChI 1.05

[Igor F. <igo...@gm...>]

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 <gre...@gm...>
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 <igo...@gm...>
> 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
>> Rdk...@li...
>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>
>>
>

Re: [Rdkit-devel] InChI 1.05

[Greg L. <gre...@gm...>]

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 <igo...@gm...>
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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>

Re: [Rdkit-devel] InChI 1.05

[Igor F. <igo...@gm...>]

I did run the tests and they went through just fine.

Igor

On Thu, Feb 23, 2017 at 8:47 AM, Gianluca Sforna <gi...@gm...> wrote:

> On Thu, Feb 23, 2017 at 4:55 AM, Igor Filippov
> <igo...@gm...> 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.
>
> Did you try and run the tests after compiling rdkit against 1.05? IIRC
> I had failing tests with prereleases
>
>
> --
> Gianluca Sforna
>
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
> Tinker Garage - http://tinkergarage.it
>

Re: [Rdkit-devel] InChI 1.05

[Gianluca S. <gi...@gm...>]

On Thu, Feb 23, 2017 at 4:55 AM, Igor Filippov
<igo...@gm...> 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.

Did you try and run the tests after compiling rdkit against 1.05? IIRC
I had failing tests with prereleases


-- 
Gianluca Sforna

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

[Rdkit-devel] InChI 1.05

[Igor F. <igo...@gm...>]

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

Re: [Rdkit-devel] RDKit Python wrappers

[Greg L. <gre...@gm...>]

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" <fus...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

------------------------------------------------------------------------------
_______________________________________________
Rdkit-devel mailing list
Rdk...@li...
https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] RDKit Python wrappers

[Greg L. <gre...@gm...>]

You can always just ask...






On Thu, Dec 1, 2016 at 9:14 PM +0100, "David Cosgrove" <dav...@gm...> 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 <ma...@wo...> wrote:
One big thing on pros side: boost::python supports serialization natively, and SWIG does not.
----
Pozdrawiam,  |  Best regards,
Maciek Wójcikowski
ma...@wo...


2016-12-01 20:46 GMT+01:00 Gianluca Sforna <gi...@gm...>:
On Thu, Dec 1, 2016 at 7:09 PM, Brian Kelley <fus...@gm...> 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

Rdk...@li...

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


------------------------------------------------------------------------------

_______________________________________________

Rdkit-devel mailing list

Rdk...@li...

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

Re: [Rdkit-devel] RDKit Python wrappers

[David C. <dav...@gm...>]

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 <ma...@wo...>
wrote:

> One big thing on pros side: boost::python supports serialization natively,
> and SWIG does not.
>
> ----
> Pozdrawiam,  |  Best regards,
> Maciek Wójcikowski
> ma...@wo...
>
> 2016-12-01 20:46 GMT+01:00 Gianluca Sforna <gi...@gm...>:
>
> On Thu, Dec 1, 2016 at 7:09 PM, Brian Kelley <fus...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

Re: [Rdkit-devel] RDKit Python wrappers

[Maciek W. <ma...@wo...>]

One big thing on pros side: boost::python supports serialization natively,
and SWIG does not.

----
Pozdrawiam,  |  Best regards,
Maciek Wójcikowski
ma...@wo...

2016-12-01 20:46 GMT+01:00 Gianluca Sforna <gi...@gm...>:

> On Thu, Dec 1, 2016 at 7:09 PM, Brian Kelley <fus...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

Re: [Rdkit-devel] RDKit Python wrappers

[Gianluca S. <gi...@gm...>]

On Thu, Dec 1, 2016 at 7:09 PM, Brian Kelley <fus...@gm...> 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.

Re: [Rdkit-devel] RDKit Python wrappers

[Brian K. <fus...@gm...>]

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 <dav...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

[Rdkit-devel] RDKit Python wrappers

[David C. <dav...@gm...>]

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

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

[Andrew D. <da...@da...>]

On Nov 23, 2016, at 9:30 AM, Greg Landrum wrote:
> The release files are on the github release page:
> https://github.com/rdkit/rdkit/releases/tag/Release_2016_09_2

Will github be the new place to download a release?

I ask because I decided to build the newest release. I went to rdkit.org and searched for "download". The link was to Sourceforge, but the newest release there is RDKit_2016_03_1 , not this latest one. Your release announcement mentioned updating anaconda.org but not SF.org.

If it's a permanent change, I think it makes sense to make a new SF "release" with the file "DOWNLOAD_SITE_MOVED.txt" to point people to the new site. This would be a sort of soft repair for outdated links.

Cheers,


				Andrew
				da...@da...

Re: [Rdkit-devel] GenerateDepictionMatching3DStructure

[Brian K. <fus...@gm...>]

There has been a bit of discussion about this anyway, I find the tutorial
in the RDKit book is pretty good, but perhaps we can fill in the gaps here
as well.

In addition, I have a PR that makes the constrained depictions from
distance matrices work with both the N**2 and  diagonal (N*N-1)/2 matrices,
this has been an area of confusion as well.  This probably won't be ready
this week though.

On Wed, Nov 23, 2016 at 12:34 AM, Greg Landrum <gre...@gm...>
wrote:

> Hi Dave,
>
> On Tue, Nov 22, 2016 at 11:08 AM, David Cosgrove <
> dav...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>

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

[Greg L. <gre...@gm...>]

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

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

Re: [Rdkit-devel] GenerateDepictionMatching3DStructure

[Greg L. <gre...@gm...>]

Hi Dave,

On Tue, Nov 22, 2016 at 11:08 AM, David Cosgrove <dav...@gm...
> 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

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

[Gianluca S. <gi...@gm...>]

On Wed, Nov 9, 2016 at 1:59 PM, David Hall <li...@co...> wrote:
> The EPEL repo has cmake3 package (3.6). Can that not be a dependency for
> rdkit in epel?

Yep, I overlooked that one. So a newer cmake requirement is not an issue

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

[David H. <li...@co...>]

The EPEL repo has cmake3 package (3.6). Can that not be a dependency for rdkit in epel?

-David

> On Nov 9, 2016, at 7:22 AM, Greg Landrum <gre...@gm...> wrote:
> 
> 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 <gi...@gm...>
> Sent: Wednesday, November 9, 2016 12:36 PM
> Subject: Re: [Rdkit-devel] Boost and cmake version survey
> To: Greg Landrum <gre...@gm...>
> Cc: RDKit Developers List <rdk...@li...>
> 
> 
> On Wed, Nov 9, 2016 at 11:41 AM, Greg Landrum <gre...@gm...> 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
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

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

[Greg L. <gre...@gm...>]

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


On Wed, Nov 9, 2016 at 11:41 AM, Greg Landrum <gre...@gm...> 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



	

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

[Gianluca S. <gi...@gm...>]

On Wed, Nov 9, 2016 at 11:41 AM, Greg Landrum <gre...@gm...> 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

[Rdkit-devel] Boost and cmake version survey

[Greg L. <gre...@gm...>]

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

[Rdkit-devel] Beta of Q3 2016 release now up

[Greg L. <gre...@gm...>]

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 #1111 (https://github.com/rdkit/rdkit/pull/1111), 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 formatting of Python code
 (github issue #1071 from gedeck)
  - Improved test coverage of Python code
 (github pull #1081 from gedeck)
  - Improved test coverage of rdkit.DataStructs
 (github pull #1083 from gedeck)
  - Add some 3D molecular descriptors
 (github pull #1084 from greglandrum)
  - Conformer GetPos returns a numpy array rather than a tuple of tuples
 (github pull #1087 from jandom)
  - make the 3D descriptors available in the Descriptors module
 (github pull #1097 from greglandrum)
  - Documentation update.
 (github pull #1100 from greglandrum)
  - Provide SVG output from the cartridge
 (github pull #1109 from greglandrum)
  - Allow the output of ROMol::debugMol() to show up in jupyter
 (github pull #1110 from greglandrum)
  - yapf formatting of recent changes to Python code in rdkit and Code
 (github pull #1120 from gedeck)
  - Add a parameters structure for controlling the embedding options.
 (github pull #1121 from greglandrum)
  - add more detailed error reporting when python tests fail in
TestRunner.py
 (github pull #1122 from greglandrum)
  - add support for a default constructor to the python-exposed RWMol class
 (github pull #1129 from greglandrum)
  - The RunStruchk function is not exposed in pyAvalonTools
 (github issue #1130 from pulveni1)
  - SSSR performance improvements to support larger systems
 (github pull #1131 from coleb)
  - Script PythonFormat.py will test the RDkit python code for conformance
with the agreed format using yapf
 (github pull #1133 from gedeck)
  - support additional trans-uranic elements
 (github pull #1134 from greglandrum)
  - Expanded sequence support
 (github pull #1140 from greglandrum)
  - add UGM link to documentation
 (github pull #1142 from David-Turbert)

## New Database Cartridge Features:
  - Provide SVG output from the cartridge
 (github pull #1109 from greglandrum)
  - Add cartridge support for adjustQueryProperties()
 (github pull #949 from greglandrum)

## New Java Wrapper Features:
  - Expose filtermatch to swig
 (github pull #1117 from bp-kelley)
  - adjustQueryProperties()

## Bug Fixes:
  - initialization of the PeriodicTable object should be made thread-safe
 (github issue #381 from greglandrum)
  - AssignAtomChiralTagsFromStructure() not recognizing chiral S
 (github issue #607 from greglandrum)
  - Fixed a few typos in Code/PgSQL/rdkit/CMakeLists.txt
 (github pull #867 from ptosco)
  - MergeQueryHs explicit H warning when no explicit Hs were actually used
 (github issue #868 from bp-kelley)
  - Fixes regression in python api CalcNumRotatableBonds
 (github pull #870 from bp-kelley)
  - Single atoms setting radius 1 bits in Morgan fingerprints
 (github issue #874 from greglandrum)
  - Providing subImgSize argument to MolsToGridImage() causes drawing
failure
 (github issue #876 from greglandrum)
  - javadoc failure on CentOS 7
 (github pull #878 from ptosco)
  - adjust cartridge tests after the fix for #874
 (github pull #884 from greglandrum)
  - bugreport: invalid handling of negation of aromaticity when parsing
SMARTS
 (github issue #893 from michalsta)
  - Fixes depictor problem with empty fragments
 (github pull #894 from greglandrum)
  - Fix building with G++ on Mac OS X
 (github pull #900 from johnmay)
  - linked additional libs to fix a build failure on Windows
 (github pull #901 from ptosco)
  - Rdkit 2016_03_1 generate SVG typo in Python bindings
 (github issue #903 from maddogcz)
  - PAINS filters update fails when old Python is installed
 (github issue #904 from greglandrum)
  - rdMolDraw2D.PrepareMolForDrawing() should not default to
forceCoords=True
 (github issue #906 from greglandrum)
  - AddHs() using 3D coordinates with 2D conformations
 (github issue #908 from greglandrum)
  - ugly coordinates generated for peptide chains
 (github issue #910 from greglandrum)
  - Cartridge: makefile not using -O2 for C code.
 (github issue #920 from greglandrum)
  - Removes incorrect setting of hasNonPodData
 (github pull #923 from bp-kelley)
  - cleanups of RDLog's tee behavior
 (github pull #926 from greglandrum)
  - initialize boost::once_flag properly
 (github pull #927 from greglandrum)
  - sys not imported in IPythonConsole.py
 (github issue #928 from greglandrum)
  - AddTee is now SetTee
 (github pull #930 from bp-kelley)
  - mistake in SVG generated for wedged bonds
 (github issue #932 from greglandrum)
  - PandasTools AttributeError with pandas-0.18.1
 (github issue #933 from philopon)
  - Jupyter Notebooks: Issue with PyMol.MolViewer on Windows
 (github issue #936 from kienerj)
  - Subshape module: Not Python 3 compatible
 (github issue #937 from kienerj)
  - property dictionaries leaking memory
 (github issue #940 from greglandrum)
  - Bug when removing stereo info?
 (github pull #946 from mnowotka)
  - Distorted aromatic rings from ETKDG
 (github issue #952 from greglandrum)
  - MolDraw2D: default color should not be cyan
 (github issue #953 from greglandrum)
  - GetPropNames() no longer working on Atoms or Bonds
 (github issue #955 from greglandrum)
  - Kekulization issues post successful smiles parsing
 (github issue #962 from bp-kelley)
  - Fixes includes for older boost/gcc
 (github pull #966 from bp-kelley)
  - ugly conformations can be generated for highly constrained ring systems
 (github issue #971 from greglandrum)
  - Cleanup bad conformations
 (github pull #973 from greglandrum)
  - Unnecessary warnings in rxn.validate()
 (github issue #975 from greglandrum)
  - Minor fix to Code/GraphMol/Wrap/testTrajectory.py
 (github pull #979 from ptosco)
  - prepareMolForDrawing(): Do not add Hs to some three-coordinate Cs
 (github issue #982 from greglandrum)
  - MolDraw2D: wedged bonds between chiral centers drawn improperly
 (github issue #983 from greglandrum)
  - Fix format-security GCC warning
 (github pull #984 from giallu)
  - MolDraw2D scaling problems
 (github issue #985 from greglandrum)
  - RIght-justified elements in RCSB SDF files can now be parsed
 (github pull #994 from ptosco)
  - Right-justified elements in RCSB SDF files raise an exception
 (github issue #995 from ptosco)
  - ChemReactions: Bugfix in copy constructor
 (github pull #996 from NadineSchneider)
  - PgSQL README typos
 (github pull #997 from ptosco)
  - Fixes rounding errors in test
 (github pull #1001 from bp-kelley)
  - Fixes middle-justified symbols in sd files, adds M_CHG tests
 (github pull #1002 from bp-kelley)
  - fix compatibility issues with postgres < 9.5 (#1000)
 (github pull #1005 from rvianello)
  - Fixes MMFF94 aromaticity perception and
ChemicalForceFields.MMFFHasAllMoleculeParams()
 (github pull #1007 from ptosco)
  - fixes typo which breaks the PostgreSQL cartridge build on Windows
 (github pull #1008 from ptosco)
  - Fix Inchi being hardcoded into PostgreSQL
 (github pull #1009 from ptosco)
  - Support ETKDG from within the SWIG wrappers
 (github pull #1010 from greglandrum)
  - move definition of computedPropName to namespace RDKit::detail
 (github issue #1017 from greglandrum)
  - fix non-inchi build
 (github pull #1018 from greglandrum)
  - Fixes #1018
 (github pull #1020 from ptosco)
  - GetSSSR interrupts by segmentation fault
 (github issue #1023 from PiotrDabr)
  - FMCS fix for Windows DLLs
 (github pull #1030 from ptosco)
  - Cause ImportError from failed dlopen of the rdBase.so shared library to
propagate.
 (github pull #1032 from coleb)
  - typos in MMPA hash code
 (github issue #1044 from greglandrum)
  - MolOps::cleanUp() being called by CTAB parser even when sanitization
isn't on
 (github issue #1049 from greglandrum)
  - Bond::BondDir::EITHERDOUBLE not exposed to python
 (github issue #1051 from greglandrum)
  - add python3 compatibility
 (github pull #1057 from greglandrum)
  - doc updates from Dave Cosgrove
 (github pull #1060 from greglandrum)
  - Fix leak with renumberAtoms() in the SWIG wrappers
 (github pull #1064 from greglandrum)
  - Timings on Windows with Python 3
 (github pull #1067 from ptosco)
  - computeInitialCoords() should call the SSSR code before it calls
assignStereochemistry()
 (github issue #1073 from greglandrum)
  - Remove duplicates doesn't work on first column in
rdkit.Dbase.DbUtils.GetData
 (github issue #1082 from gedeck)
  - clear up a bunch of windows warnings
 (github pull #1086 from greglandrum)
  - MolsToGridImage barfs on '&' in labels, at least with useSVG=True
 (github issue #1090 from shenkin)
  - Fixes csharp build for 64 bit systems
 (github pull #1098 from bp-kelley)
  - Cartridge: some C++ functions returning pointers to local storage
 (github issue #1106 from greglandrum)
  - Check for doubles after other integer types when reporting properties
 (github pull #1115 from bp-kelley)
  - Replace has_key use in Python (#issue1042)
 (github pull #1132 from gedeck)
  - fix moldraw2d headers installation path
 (github pull #1143 from giallu)
  - Remove iPythonConsole configuration for normal Draw tests
 (github pull #1146 from gedeck)

## Deprecated code (to be removed in next release):

## Removed code:

## Contrib updates:
  - added an implementation of the Gobbi Atom-Atom-Path (AAP) similarity
 (github pull #1015 from Richard-Hall)

## Other: