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

2018-04-05 Thread Greg Landrum
Tim: where did you see the mention of cmake 2.6?
The docs that are part of the source tree have already been updated to
mention that cmake 3.1 or newer is required:
https://github.com/rdkit/rdkit/blob/master/Docs/Book/Install.md
maybe you're looking at the online docs? I don't update those for the beta
releases, so those still correspond to the previous version.


I'd like to be sure I didn't miss anything else.

-greg



On Thu, Apr 5, 2018 at 5:52 PM, Greg Landrum  wrote:

> Yeah, thats another change that has been made. I will update the docs.
>
> Thanks for pointing out the oversight
>
> -greg
>
> On Thu, 5 Apr 2018 at 17:30, Tim Dudgeon  wrote:
>
>> Greg,
>>
>> Does this explain problems I'm seeing with building on Centos:
>>
>> From the current docs:
>> cmake. You need version 2.6 (or more recent)
>>
>> With a current centos7 distro after a `yum install cmake`
>>
>> # cmake --version
>> cmake version 2.8.12.2
>>
>> When you build from current master branch you get this error:
>>
>> CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
>>   CMake 3.1 or higher is required.  You are running version 2.8.12.2
>>
>> This is not seen when you build from the Release_2017_09_2 branch.
>>
>> Tim
>>
>>
>>
>>
>> On 04/04/18 04:23, Greg Landrum wrote:
>>
>>
>> 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.
>> landrum_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-discuss mailing 
>> listRdkit-discuss@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
>> _
>> Rdkit-discuss mailing list
>> Rdkit-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net

[Rdkit-discuss] Fwd: What is correct treatment of bond stereochemistry defined by hydrogen

2018-04-05 Thread Dan Nealschneider
I'm working on a translation layer between Schrodinger structures and RDKit
mols. Schrodinger structures do not have implicit hydrogens, so I'm
struggling a bit to understand how best to treat potentially implicit
hydrogens!

What is the correct treatment of bond stereochemistry at centers for which
a hydrogen is required in order to specify the bond stereochemistry? For
example, an imine with a hydrogen substituent (trivial example, F/C=N/[H]).

I notice that when I use the smiles constructor, or if I read from an SDF
file using the SDMolSupplier, the C=N bond in the example shown above is
not recognized as having stereochemistry. However, if I use
removeHydrogens=False in the SDMolSupplier, the bond *is* recognized as Z.
Maybe that can beg presented more clearly as code (here's an interactive
Python shell, I've also attached this as a script, as well as an SDF file).

Python 3.6.2 (default, Jul 21 2017, 13:21:26)
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rdkit
>>> print(rdkit.__version__)
2017.03.1
>>> from rdkit import Chem
>>> from rdkit.Chem import AllChem
>>> from rdkit.Chem import rdmolops
>>> def summarize(mol):
...  bond = mol.GetBondBetweenAtoms(0, 1)
...  atoms = list(bond.GetStereoAtoms())
...  atoms.insert(1, bond.GetEndAtom().GetIdx())
...  atoms.insert(1, bond.GetBeginAtom().GetIdx())
...  print(Chem.MolToSmiles(mol, isomericSmiles=True))
...  print(bond.GetStereo(), atoms)
...
>>> has_h = next(Chem.SDMolSupplier('cis_imine.sdf', removeHs=False))
>>> no_h = rdmolops.RemoveHs(has_h)
>>> has_h_again = rdmolops.AddHs(no_h)
>>> summarize(has_h)
[H]/N=C(/[H])F
STEREOZ [3, 0, 1, 2]
>>> summarize(no_h)
N=CF
STEREOZ [1, 0]
>>> summarize(has_h_again)
[H]N=C([H])F
STEREOZ [1, 0]
>>> AllChem.EmbedMolecule(has_h)
0
>>> AllChem.EmbedMolecule(no_h)
0
>>> AllChem.EmbedMolecule(has_h_again)
Fatal Python error: Segmentation fault

Current thread 0x7faa949d8740 (most recent call first):
  File "", line 1 in 
Segmentation fault

*At core, I have 2 questions:* Is RDKit able to represent stereochemistry
about this bond if the hydrogen is implicit? It's fine if not, I just want
to know. If RDKit can represent stereochemistry for bonds for which one
substituent is hydrogen, what different information do I need to provide
RDKit?

- dan nealschneider

(né wandschneider)

Senior Developer
Schr*ö*dinger, Inc
Portland, OR


cis_imine.sdf
Description: Binary data
"""
Demonstrate my questions about bonds whose stereochemistry is specified
based on a hydrogen, especially when that hydrogen is made implicit.

"""
import rdkit
from rdkit import Chem
from rdkit.Chem import AllChem
from rdkit.Chem import rdmolops

has_h = next(Chem.SDMolSupplier('cis_imine.sdf', removeHs=False))
def summarize(mol, a0=0, a1=1):
bond = mol.GetBondBetweenAtoms(a0, a1)
atoms = list(bond.GetStereoAtoms())
atoms.insert(1, bond.GetEndAtom().GetIdx())
atoms.insert(1, bond.GetBeginAtom().GetIdx())
print(Chem.MolToSmiles(mol, isomericSmiles=True))
print(bond.GetStereo(), atoms)

no_h = rdmolops.RemoveHs(has_h)
has_h_again = rdmolops.AddHs(no_h)

print(rdkit.__version__)
summarize(has_h)
summarize(no_h)
summarize(has_h_again)
AllChem.EmbedMolecule(has_h)
AllChem.EmbedMolecule(no_h)
# This generates a SEGV in my hands. Totalview says it happened in
# _ZN5RDKit12DGeomHelpers14_getAtomStereoEPKNS_4BondEjj, but I
# can't find a getAtomStereo or 2DGeomHelpers in RDKit's github.
AllChem.EmbedMolecule(has_h_again)

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


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

2018-04-05 Thread Greg Landrum
Yes; cmake can also come from conda or from one of the redhat-supplied
developer tool sets.

On Thu, 5 Apr 2018 at 17:57, Tim Dudgeon  wrote:

> So that means its not easy to build on a up to date centos (and maybe most
> other Red Hat based) distros?
> You would need to install a newer version of cmake from some other source
> e.g https://cmake.org/ ?
>
> On 05/04/18 16:52, Greg Landrum wrote:
>
> Yeah, thats another change that has been made. I will update the docs.
>
> Thanks for pointing out the oversight
>
> -greg
>
> On Thu, 5 Apr 2018 at 17:30, Tim Dudgeon  wrote:
>
>> Greg,
>>
>> Does this explain problems I'm seeing with building on Centos:
>>
>> From the current docs:
>> cmake. You need version 2.6 (or more recent)
>>
>> With a current centos7 distro after a `yum install cmake`
>>
>> # cmake --version
>> cmake version 2.8.12.2
>>
>> When you build from current master branch you get this error:
>>
>> CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
>>   CMake 3.1 or higher is required.  You are running version 2.8.12.2
>>
>> This is not seen when you build from the Release_2017_09_2 branch.
>>
>> Tim
>>
>>
>>
>>
>> On 04/04/18 04:23, Greg Landrum wrote:
>>
>>
>> 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.landrum_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-discuss mailing 
>> listRdkit-discuss@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Rdkit-discuss mailing list
>> Rdkit-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>

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

2018-04-05 Thread Tim Dudgeon
So that means its not easy to build on a up to date centos (and maybe 
most other Red Hat based) distros?
You would need to install a newer version of cmake from some other 
source e.g https://cmake.org/ ?



On 05/04/18 16:52, Greg Landrum wrote:

Yeah, thats another change that has been made. I will update the docs.

Thanks for pointing out the oversight

-greg

On Thu, 5 Apr 2018 at 17:30, Tim Dudgeon > wrote:


Greg,

Does this explain problems I'm seeing with building on Centos:

From the current docs:
cmake. You need version 2.6 (or more recent)

With a current centos7 distro after a `yum install cmake`

# cmake --version
cmake version 2.8.12.2

When you build from current master branch you get this error:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.1 or higher is required.  You are running version 2.8.12.2

This is not seen when you build from the Release_2017_09_2 branch.

Tim




On 04/04/18 04:23, Greg Landrum wrote:


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.landrum_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-discuss mailing list
Rdkit-discuss@lists.sourceforge.net

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


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

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



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


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

2018-04-05 Thread Greg Landrum
Yeah, thats another change that has been made. I will update the docs.

Thanks for pointing out the oversight

-greg

On Thu, 5 Apr 2018 at 17:30, Tim Dudgeon  wrote:

> Greg,
>
> Does this explain problems I'm seeing with building on Centos:
>
> From the current docs:
> cmake. You need version 2.6 (or more recent)
>
> With a current centos7 distro after a `yum install cmake`
>
> # cmake --version
> cmake version 2.8.12.2
>
> When you build from current master branch you get this error:
>
> CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
>   CMake 3.1 or higher is required.  You are running version 2.8.12.2
>
> This is not seen when you build from the Release_2017_09_2 branch.
>
> Tim
>
>
>
>
> On 04/04/18 04:23, Greg Landrum wrote:
>
>
> 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.landrum_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-discuss mailing 
> listRdkit-discuss@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Rdkit-discuss mailing list
> Rdkit-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


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

2018-04-05 Thread Tim Dudgeon

Greg,

Does this explain problems I'm seeing with building on Centos:

From the current docs:
cmake. You need version 2.6 (or more recent)

With a current centos7 distro after a `yum install cmake`

# cmake --version
cmake version 2.8.12.2

When you build from current master branch you get this error:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.1 or higher is required.  You are running version 2.8.12.2

This is not seen when you build from the Release_2017_09_2 branch.

Tim




On 04/04/18 04:23, Greg Landrum wrote:


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


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


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

2018-04-05 Thread 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-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss


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

2018-04-05 Thread Markus Sitzmann
Yes, looks good :-). And the good thing with git is (if you very uncertain
about the outcome), you always can make a test run by copying the whole
directory, test all things with the copy, and if it goes horribly wrong,
just delete the copy.

Markus



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


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

2018-04-05 Thread 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-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss