Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-29 Thread Paolo Tosco
Hi Dimitri,

That can be avoided building the RPMs on older RHEL distributions using the Red 
Hat Developer Toolsets that Greg and others mentioned. These toolsets include 
newer compilers, which however link the binaries against the GLIBC present in 
the distribution they run on, thus maintaining the backwards compatibility. For 
example, devtoolset-4 brings GCC 5.2 to RHEL 6:

http://developers.redhat.com/products/developertoolset/get-started-rhel6-cpp/

Cheers,
p.

> On 29 Sep 2016, at 20:14, Dimitri Maziuk  wrote:
> 
>> On 09/29/2016 10:16 AM, Greg Landrum wrote:
>> 
>> My hope is that all of those people will be able to keep happily
>> using a reasonably up-to-date version of the RDKit.
> 
> Well, that's kinda the point: there are no RPMs that let you run
> binaries linked to GLIBC_2.17 on GLIBC_2.5, nor compile c++-14 code with
> c++-03 compilers.
> 
> -- 
> Dimitri Maziuk
> Programmer/sysadmin
> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
> 
> --
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-29 Thread Dimitri Maziuk
On 09/29/2016 10:16 AM, Greg Landrum wrote:

> My hope is that all of those people will be able to keep happily
> using a reasonably up-to-date version of the RDKit.

Well, that's kinda the point: there are no RPMs that let you run
binaries linked to GLIBC_2.17 on GLIBC_2.5, nor compile c++-14 code with
c++-03 compilers.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-29 Thread Greg Landrum
Which is, along with the inertia that large companies have, part of the reason 
that RHEL6 will be with us for a while.
Similarly, a year after RHEL8 comes out some of us will be complaining that 
we'll be stuck with RHEL7 forever, others will be clamoring for immediate 
support of all the new features, and a third camp will still be stuck with 
RHEL6. That's just the way things go.
My hope is that all of those people will be able to keep happily using a 
reasonably up-to-date version of the RDKit.
-greg






On Thu, Sep 29, 2016 at 5:01 PM +0200, "Dimitri Maziuk"  
wrote:










On 2016-09-29 00:57, Markus Sitzmann wrote:
> I get the feeling, RH/Centos 6 becomes the next XP kind of story - to
> many legacies that make the update impossible or very hard. Also docker,
> a great technology that could mitigate this problem, is very painful
> under RH/Centos 6.

systemd, corosync/pacemaker, apache 2.4, gnome.whichever are some of 
RH7's "exciting new technologies" a lot of us don't want.

Dimitri



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





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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-29 Thread Dimitri Maziuk
On 2016-09-29 00:57, Markus Sitzmann wrote:
> I get the feeling, RH/Centos 6 becomes the next XP kind of story - to
> many legacies that make the update impossible or very hard. Also docker,
> a great technology that could mitigate this problem, is very painful
> under RH/Centos 6.

systemd, corosync/pacemaker, apache 2.4, gnome.whichever are some of 
RH7's "exciting new technologies" a lot of us don't want.

Dimitri



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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-29 Thread Greg Landrum
I agree that it's going to be a thorn for a while. Still, it's better than 
being stuck with RHEL5. :-S





On Thu, Sep 29, 2016 at 7:58 AM +0200, "Markus Sitzmann" 
 wrote:










I get the feeling, RH/Centos 6 becomes the next XP kind of story - to many 
legacies that make the update impossible or very hard. Also docker, a great 
technology that could mitigate this problem, is very painful under RH/Centos 6.
---Markus Sitzmann

On 29 Sep 2016, at 07:31, Greg Landrum  wrote:


On Thu, Sep 29, 2016 at 7:06 AM, Peter S. Shenkin  wrote:

Thanks... so it sounds like the main effort (aside from what you delicately 
called "professional development" ;-) ) will be to introduce features that 
improve robustness or performance when writing new code and possibly when 
maintaining (fixing, extending) existing code.
Yes, I think that's about right with the one refinement that we'll be using 
some automated tools to convert the existing code to use some of those new 
features.
-greg 
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss





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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-28 Thread Markus Sitzmann
I get the feeling, RH/Centos 6 becomes the next XP kind of story - to many 
legacies that make the update impossible or very hard. Also docker, a great 
technology that could mitigate this problem, is very painful under RH/Centos 6.

---
Markus Sitzmann


> On 29 Sep 2016, at 07:31, Greg Landrum  wrote:
> 
> 
>> On Thu, Sep 29, 2016 at 7:06 AM, Peter S. Shenkin  wrote:
>> 
>> Thanks... so it sounds like the main effort (aside from what you delicately 
>> called "professional development" ;-) ) will be to introduce features that 
>> improve robustness or performance when writing new code and possibly when 
>> maintaining (fixing, extending) existing code.
> 
> Yes, I think that's about right with the one refinement that we'll be using 
> some automated tools to convert the existing code to use some of those new 
> features.
> 
> -greg
>  
> --
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-28 Thread Greg Landrum
On Thu, Sep 29, 2016 at 7:06 AM, Peter S. Shenkin  wrote:

>
> Thanks... so it sounds like the main effort (aside from what you
> delicately called "professional development" ;-) ) will be to introduce
> features that improve robustness or performance when writing new code and
> possibly when maintaining (fixing, extending) existing code.
>

Yes, I think that's about right with the one refinement that we'll be using
some automated tools to convert the existing code to use some of those new
features.

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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-28 Thread Peter S. Shenkin
Hi,

Thanks... so it sounds like the main effort (aside from what you delicately
called "professional development" ;-) ) will be to introduce features that
improve robustness or performance when writing new code and possibly when
maintaining (fixing, extending) existing code.

-P.

On Thu, Sep 29, 2016 at 12:42 AM, Greg Landrum 
wrote:

> Hi Peter,
>
> On Sat, Sep 24, 2016 at 7:55 PM, Peter S. Shenkin 
> wrote:
>
>> Hi, I read your posting on Medium, and would be curious to hear which of
>> the many language features in c++11/14 you find most appealing. Is it that
>> you hope to rewrite things using these features, or, at the other extreme,
>> just want to make sure that the code remains compatible with new language
>> standards?
>>
> The standards committee has been very careful and the changes they made do
> not, to the best of my knowledge, break backwards compatibility (note: I'm
> just talking about being able to compile code and have it work, binary
> compatibility could be a different story, but that's less important).
>
> A big component of this is just being able to learn and use the new
> features in the language. It's a professional development thing for anyone
> working with the RDKit C++ code.
>
> Some of the changes (auto variables, range-based for loops, non-member
> begin() and end()) will help simplify the code, which is a big win.
> Others (unique pointers) will help with making things more explicit and, I
> hope, result in some speed improvements.
> And, the great unknown, move semantics could result in a nice performance
> boost. But that we'll have to see.
>
> -greg
>
>
>
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-28 Thread Greg Landrum
Hi Peter,

On Sat, Sep 24, 2016 at 7:55 PM, Peter S. Shenkin  wrote:

> Hi, I read your posting on Medium, and would be curious to hear which of
> the many language features in c++11/14 you find most appealing. Is it that
> you hope to rewrite things using these features, or, at the other extreme,
> just want to make sure that the code remains compatible with new language
> standards?
>
The standards committee has been very careful and the changes they made do
not, to the best of my knowledge, break backwards compatibility (note: I'm
just talking about being able to compile code and have it work, binary
compatibility could be a different story, but that's less important).

A big component of this is just being able to learn and use the new
features in the language. It's a professional development thing for anyone
working with the RDKit C++ code.

Some of the changes (auto variables, range-based for loops, non-member
begin() and end()) will help simplify the code, which is a big win.
Others (unique pointers) will help with making things more explicit and, I
hope, result in some speed improvements.
And, the great unknown, move semantics could result in a nice performance
boost. But that we'll have to see.

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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-28 Thread Greg Landrum
[I'm slow on all of this because I'm on vacation and was away from reliable
net access for a while]

On Sat, Sep 24, 2016 at 3:12 PM, Brian Kelley  wrote:

>
> One thing that may help RHEL6 is that anaconda actually can install/build
> gcc4.8 in user space: https://anaconda.org/anaconda/gcc/.  Note: it does
> require root to install some dependencies, but doesn't override the system
> gcc.
>
> While this is not a complete solution for many applications, for python
> and python related packages it really is a god-send.  We have some legacy
> systems stuck on RHEL6 and have had to use this to compile some newer
> packages.
>
>
Do you mean RHEL6 above or RHEL5? The RedHat Developer toolkit is a
supported solution for RHEL6, but using anaconda is an interesting possible
alternative for RHEL5. I will put that on my list of things to try when we
create that branch.

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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-24 Thread Peter S. Shenkin
Hi, I read your posting on Medium, and would be curious to hear which of
the many language features in c++11/14 you find most appealing. Is it that
you hope to rewrite things using these features, or, at the other extreme,
just want to make sure that the code remains compatible with new language
standards?

-P.
Sent from a cell phone. Please forgive brvty and m1St@kes.

On Sep 24, 2016 2:26 AM, "Greg Landrum"  wrote:

> Dear all,
>
> I just did a blog post describing a proposal for some upcoming changes to
> the RDKit code base:
> https://medium.com/@greg.landrum_t5/the-rdkit-and-
> modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147
>
> This is a big and important change and I'd love to hear whatever feedback
> members of the community may have. Please comment either on the blog post
> or here.
>
> Best Regards,
> -greg
>
>
>
>
> 
> --
>
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-24 Thread Dimitri Maziuk
On 2016-09-24 01:25, Greg Landrum wrote:

> https://medium.com/@greg.landrum_t5/the-rdkit-and-modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147
>
> This is a big and important change and I'd love to hear whatever
> feedback members of the community may have. Please comment either on the
> blog post or here.

What are the concrete benefits -14 will bring to the toolkit?

C++ committee has long been criticized for attempting to solve the wrong 
problems every time and every time coming up with solutions that are 
reasonable, logical, and wrong. We've been forced to update our code 
several times due to g++ updates being incompatible with the "language 
formerly known as C++" and if that's the case with RFKit, then you don't 
have much choice. However, if I were rewriting the code for the sake of 
making it "cleaner" or "more maintainable", I'd be seriously considering 
go or objective c or maybe gnat even.

At this point I can only recommend C++ to Comp. Sci. students in the 
Programming languages unit; as an object example of where good 
intentions usually end up. I certainly wouldn't recommend it to chemists 
as a "modern tool", or even a good tool.

Just mu $.02 as "it professional".
Dimitri


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


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-24 Thread Brian Kelley
I whole heartedly agree.

One thing that may help RHEL6 is that anaconda actually can install/build
gcc4.8 in user space: https://anaconda.org/anaconda/gcc/.  Note: it does
require root to install some dependencies, but doesn't override the system
gcc.

While this is not a complete solution for many applications, for python and
python related packages it really is a god-send.  We have some legacy
systems stuck on RHEL6 and have had to use this to compile some newer
packages.

As a side note, the latest Xcode update has deprecated libstdc++ which is
par-for-the-course dealing with Apple's style of updating.  This will
likely require recompilation and new packages on Anaconda which will
probably be painful.

Cheers,
 Brian

On Sat, Sep 24, 2016 at 2:25 AM, Greg Landrum 
wrote:

> Dear all,
>
> I just did a blog post describing a proposal for some upcoming changes to
> the RDKit code base:
> https://medium.com/@greg.landrum_t5/the-rdkit-and-
> modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147
>
> This is a big and important change and I'd love to hear whatever feedback
> members of the community may have. Please comment either on the blog post
> or here.
>
> Best Regards,
> -greg
>
>
>
>
> 
> --
>
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


Re: [Rdkit-discuss] The RDKit and modern C++

2016-09-24 Thread David Hall
I've used Red Hat's developer toolset for years on RHEL5 to be able to
build stuff there using gcc 4.8 and that software has seemed to run fine
when shipping to people running RHEL5 and RHEL6. I have "source
/opt/rh/devtoolset-2/enable" in my bash profile and that sets all the
environment variables whenever I log in. That includes some code built on
top of RDKit, so it seems like it should work on the technical side,
although obviously there is a barrier in getting it installed and set up
correctly.

-David


On Sat, Sep 24, 2016 at 2:25 AM, Greg Landrum 
wrote:

> Dear all,
>
> I just did a blog post describing a proposal for some upcoming changes to
> the RDKit code base:
> https://medium.com/@greg.landrum_t5/the-rdkit-and-
> modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147
>
> This is a big and important change and I'd love to hear whatever feedback
> members of the community may have. Please comment either on the blog post
> or here.
>
> Best Regards,
> -greg
>
>
>
>
> 
> --
>
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
--
___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


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

2016-09-24 Thread Greg Landrum
Dear all,
I just did a blog post describing a proposal for some upcoming changes to the 
RDKit code 
base:https://medium.com/@greg.landrum_t5/the-rdkit-and-modern-c-48206b966218?source=linkShare-d698b3fa9f7-1474698147
This is a big and important change and I'd love to hear whatever feedback 
members of the community may have. Please comment either on the blog post or 
here.
Best Regards,-greg


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