rdkit-devel Mailing List for RDKit (Page 5)
Open-Source Cheminformatics and Machine Learning
Brought to you by:
glandrum
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(24) |
Jun
(20) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(39) |
Nov
(33) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(17) |
Feb
(13) |
Mar
(35) |
Apr
(10) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
(4) |
Sep
(4) |
Oct
(7) |
Nov
(1) |
Dec
|
2008 |
Jan
(10) |
Feb
(2) |
Mar
(2) |
Apr
(10) |
May
(8) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
2009 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(7) |
Aug
(2) |
Sep
(6) |
Oct
(12) |
Nov
|
Dec
|
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(17) |
Aug
(7) |
Sep
(20) |
Oct
(8) |
Nov
(1) |
Dec
(12) |
2011 |
Jan
(8) |
Feb
(15) |
Mar
(20) |
Apr
(5) |
May
(8) |
Jun
(2) |
Jul
(17) |
Aug
(8) |
Sep
(4) |
Oct
(15) |
Nov
|
Dec
(2) |
2012 |
Jan
(3) |
Feb
|
Mar
(23) |
Apr
(2) |
May
(2) |
Jun
(8) |
Jul
(7) |
Aug
(18) |
Sep
(8) |
Oct
(10) |
Nov
(2) |
Dec
(7) |
2013 |
Jan
(6) |
Feb
(3) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
(6) |
2015 |
Jan
(22) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(3) |
2016 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
(31) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(10) |
Dec
(7) |
2017 |
Jan
|
Feb
(7) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(6) |
Jul
(5) |
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(11) |
Apr
(13) |
May
(18) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
2020 |
Jan
(2) |
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Igor F. <igo...@gm...> - 2017-09-07 12:16:46
|
Dear Colleagues, I seem to remember there already was a discussion about this, but I cannot find the relevant email thread, nor recall what was the conclusion. When I try to draw the following molecule I am getting an image of a few pixels in size, quite unusable. NC(=O)C(N)CCCC[NH3+] Has anyone else seen this problem? Best regards, Igor |
From: Igor F. <igo...@gm...> - 2017-08-20 23:49:24
|
Greg, I just noticed that stock MolDraw2Dwx.h will not build because of the line: setColour(drawOptions.backgroundColour); should be drawOptions() as it is a function call. Also, I would recommend adding the following lines into setFontSize(): if (font_size_in_points < 1.0) font_size_in_points = 1; I noticed that if font height is less than 1 it gets rounded to zero and wxWidgets has a problem with that. Warmest regards, Igor |
From: Paul E. <pe...@mr...> - 2017-07-17 15:41:31
|
So, to wind up and answer the question... and for future reference for myself in 5 years time perhaps. I did indeed need to wrap the RDKit::ROMol * - with a boost shared pointer. RDKit::ROMol *cm_p = new RDKit::ROMol(rdkm); boost::shared_ptr<RDKit::ROMol> xx(cm_p); boost::python::object obj(xx); rdkit_mols_list.append(obj); On 16/07/2017 20:32, Paul Emsley wrote: > > Oh good grief... > > I did a bit of googling: "python::object RDKit::ROMol" to see if I could find someone having > similar problems: > > The first non-rdkit page was this: > > ftp://ftp.ccp4.ac.uk/ccp4/7.0/unpacked/checkout/coot-0.8.2/lbg/qed-interface.cc > > i.e... Just what I needed - hooray - it was the same problem! > > But... Hmm... that's not surprising - it's code I had written 5 years ago and had forgotten > about (quite likely after having asked on the list a similar question :-)). > > Cheers, > > Paul. > > > On 16/07/2017 16:58, Greg Landrum wrote: >> It's been a while since I've seen one of these, but could it be that you either haven't >> imported rdkit.Chem (in Python) before calling the function that returns the RDKit >> molecule or that your extension module is linked against a different rdkit library than >> the rdkit extension module that you're using? >> >> -greg >> >> >> On Sun, Jul 16, 2017 at 4:40 PM, Paul Emsley <pe...@mr... >> <mailto:pe...@mr...>> wrote: >> >> >> Hi, >> >> I'd like to bring to python a function that returns a list (or vector?) of RDKit >> molecules. But I am lost in boost::python. >> >> BOOST_PYTHON_MODULE(pyrogen) { >> def("extract_ligands_from_coords_file", coot::extract_ligands_from_coords_file); >> } >> >> boost::python::list >> coot::extract_ligands_from_coords_file(const std::string &file_name) { >> >> boost::python::list rdkit_mols_list; >> std::vector<RDKit::ROMol *> mols_vec = my_get_mols(file_name); >> for(unsigned int i=0; i<mols_vec.size(); i++) { >> rdkit_mols_list.append(mols_vec[i]); >> } >> return rdkit_mols_list; >> } >> >> When I try to use it: >> >> >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb') >> TypeError: No to_python (by-value) converter found for C++ type: RDKit::ROMol >> >> I am not sure what I should do (instead). At a guess, maybe I need to convert/wrap the >> mols_vec[i] before using it in append()? Please advise. >> >> Thanks, >> >> Paul. >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Rdkit-devel mailing list > Rdk...@li... > https://lists.sourceforge.net/lists/listinfo/rdkit-devel |
From: Paul E. <pe...@mr...> - 2017-07-16 19:33:14
|
Oh good grief... I did a bit of googling: "python::object RDKit::ROMol" to see if I could find someone having similar problems: The first non-rdkit page was this: ftp://ftp.ccp4.ac.uk/ccp4/7.0/unpacked/checkout/coot-0.8.2/lbg/qed-interface.cc i.e... Just what I needed - hooray - it was the same problem! But... Hmm... that's not surprising - it's code I had written 5 years ago and had forgotten about (quite likely after having asked on the list a similar question :-)). Cheers, Paul. On 16/07/2017 16:58, Greg Landrum wrote: > It's been a while since I've seen one of these, but could it be that you either haven't > imported rdkit.Chem (in Python) before calling the function that returns the RDKit molecule > or that your extension module is linked against a different rdkit library than the rdkit > extension module that you're using? > > -greg > > > On Sun, Jul 16, 2017 at 4:40 PM, Paul Emsley <pe...@mr... > <mailto:pe...@mr...>> wrote: > > > Hi, > > I'd like to bring to python a function that returns a list (or vector?) of RDKit > molecules. But I am lost in boost::python. > > BOOST_PYTHON_MODULE(pyrogen) { > def("extract_ligands_from_coords_file", coot::extract_ligands_from_coords_file); > } > > boost::python::list > coot::extract_ligands_from_coords_file(const std::string &file_name) { > > boost::python::list rdkit_mols_list; > std::vector<RDKit::ROMol *> mols_vec = my_get_mols(file_name); > for(unsigned int i=0; i<mols_vec.size(); i++) { > rdkit_mols_list.append(mols_vec[i]); > } > return rdkit_mols_list; > } > > When I try to use it: > > >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb') > TypeError: No to_python (by-value) converter found for C++ type: RDKit::ROMol > > I am not sure what I should do (instead). At a guess, maybe I need to convert/wrap the > mols_vec[i] before using it in append()? Please advise. > > Thanks, > > Paul. > |
From: Paul E. <pe...@mr...> - 2017-07-16 16:09:05
|
Hi Greg, Thanks for your prompt response. I'm pretty sure that my setup/libraries and importing is fine - my other boost::python-related finagling is working. I think I want to do the opposite of extract(). After a bit more reading, it might be to do with the return value policy and/or a boost::python::converter. I'll continue reading. Paul. On 16/07/2017 16:58, Greg Landrum wrote: > It's been a while since I've seen one of these, but could it be that you either haven't > imported rdkit.Chem (in Python) before calling the function that returns the RDKit molecule > or that your extension module is linked against a different rdkit library than the rdkit > extension module that you're using? > > -greg > > > On Sun, Jul 16, 2017 at 4:40 PM, Paul Emsley <pe...@mr... > <mailto:pe...@mr...>> wrote: > > > Hi, > > I'd like to bring to python a function that returns a list (or vector?) of RDKit > molecules. But I am lost in boost::python. > > BOOST_PYTHON_MODULE(pyrogen) { > def("extract_ligands_from_coords_file", coot::extract_ligands_from_coords_file); > } > > boost::python::list > coot::extract_ligands_from_coords_file(const std::string &file_name) { > > boost::python::list rdkit_mols_list; > std::vector<RDKit::ROMol *> mols_vec = my_get_mols(file_name); > for(unsigned int i=0; i<mols_vec.size(); i++) { > rdkit_mols_list.append(mols_vec[i]); > } > return rdkit_mols_list; > } > > When I try to use it: > > >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb') > TypeError: No to_python (by-value) converter found for C++ type: RDKit::ROMol > > I am not sure what I should do (instead). At a guess, maybe I need to convert/wrap the > mols_vec[i] before using it in append()? Please advise. > |
From: Greg L. <gre...@gm...> - 2017-07-16 15:59:15
|
It's been a while since I've seen one of these, but could it be that you either haven't imported rdkit.Chem (in Python) before calling the function that returns the RDKit molecule or that your extension module is linked against a different rdkit library than the rdkit extension module that you're using? -greg On Sun, Jul 16, 2017 at 4:40 PM, Paul Emsley <pe...@mr...> wrote: > > Hi, > > I'd like to bring to python a function that returns a list (or vector?) of > RDKit molecules. But I am lost in boost::python. > > BOOST_PYTHON_MODULE(pyrogen) { > def("extract_ligands_from_coords_file", coot::extract_ligands_from_coo > rds_file); > } > > boost::python::list > coot::extract_ligands_from_coords_file(const std::string &file_name) { > > boost::python::list rdkit_mols_list; > std::vector<RDKit::ROMol *> mols_vec = my_get_mols(file_name); > for(unsigned int i=0; i<mols_vec.size(); i++) { > rdkit_mols_list.append(mols_vec[i]); > } > return rdkit_mols_list; > } > > When I try to use it: > > >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb') > TypeError: No to_python (by-value) converter found for C++ type: > RDKit::ROMol > > I am not sure what I should do (instead). At a guess, maybe I need to > convert/wrap the mols_vec[i] before using it in append()? Please advise. > > Thanks, > > Paul. > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Rdkit-devel mailing list > Rdk...@li... > https://lists.sourceforge.net/lists/listinfo/rdkit-devel > |
From: Paul E. <pe...@mr...> - 2017-07-16 14:40:20
|
Hi, I'd like to bring to python a function that returns a list (or vector?) of RDKit molecules. But I am lost in boost::python. BOOST_PYTHON_MODULE(pyrogen) { def("extract_ligands_from_coords_file", coot::extract_ligands_from_coords_file); } boost::python::list coot::extract_ligands_from_coords_file(const std::string &file_name) { boost::python::list rdkit_mols_list; std::vector<RDKit::ROMol *> mols_vec = my_get_mols(file_name); for(unsigned int i=0; i<mols_vec.size(); i++) { rdkit_mols_list.append(mols_vec[i]); } return rdkit_mols_list; } When I try to use it: >>> m = pyrogen.extract_ligands_from_coords_mol('test.pdb') TypeError: No to_python (by-value) converter found for C++ type: RDKit::ROMol I am not sure what I should do (instead). At a guess, maybe I need to convert/wrap the mols_vec[i] before using it in append()? Please advise. Thanks, Paul. |
From: Brian K. <fus...@gm...> - 2017-06-13 14:45:23
|
I have the current builds down to about 30 minutes if that helps as a data point. I think we can build/test -j3 on the makefile without blowing up memory. Perhaps we could give this a try while you refactor. Cheers, Brian On Tue, Jun 13, 2017 at 10:18 AM, Greg Landrum <gre...@gm...> wrote: > > > On Tue, Jun 13, 2017 at 3:24 PM, Brian Kelley <fus...@gm...> > wrote: > >> I'm unsure if that staging will help, aren't the builds and tests already >> done in parallel effectively? >> > > Kind of. There are currently two jobs that run in parallel: > - job 1: build the core library, the python 2.7 wrappers, and the java > wrappers and test everything > - job 2: build the core library, the python 3.5 wrappers, and the java > wrappers and test everything > > Those have no dependencies on each other. I would hope that by pulling the > core library and test builds out into a separate job and then using the > artifacts (=libraries) from that for the python and java builds we could > shorten the individual jobs. > > -greg > > > > >> On Tue, Jun 13, 2017 at 9:20 AM, Greg Landrum <gre...@gm...> >> wrote: >> >>> Given that the current variability is almost a factor of two I don't >>> think smaller changes are going to help. >>> >>> What I'm likely going to try is doing staged builds: >>> - stage 1: build and test core library >>> - stage 2a: build and test python 2.7 wrappers >>> - stage 2b: build and test python 3.5 wrappers >>> - stage 2c: build and test java wrappers >>> >>> the three "stage 2" things can run in parallel. >>> >>> From the bit of reading I did on the train this morning, it looks like >>> this is not that horrible to do in jenkins; just need to invest a bit of >>> time. >>> >>> -greg >>> >>> >>> On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fus...@gm...> >>> wrote: >>> >>>> I tried using ninja for the builds in stead of make, after an evening >>>> of not building I successfully had two builds: >>>> >>>> https://travis-ci.org/bp-kelley/rdkit/builds/242399233 >>>> >>>> Commit: >>>> >>>> https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f6641301 >>>> 1aed239413fe74da3388/.travis.yml >>>> >>>> Note that the default ninja build is #cores + 2 which blew out the >>>> memory on the VMs so I used -j3 we could try this in the makefile as well. >>>> >>>> I also think we could shave off a few minutes by >>>> >>>> 1. building in the root conda env >>>> 2. having only one conda install for *everything* >>>> >>>> If you like I can try these fixes. >>>> >>>> Cheers, >>>> Brian >>>> >>>> On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <gre...@gm...> >>>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> We're getting more and more timeouts with RDKit builds on travis. I'm >>>>> reasonably sure that this is due to some variability in the performance of >>>>> the VMs that the builds end up running on. A good demonstration of that is >>>>> this particular build (on a branch where I'm playing with simplifying the >>>>> travis builds), which works fine for py35 but times out for py27: >>>>> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc >>>>> e=email&utm_medium=notification >>>>> >>>>> If you look into the details you'll see that the main compile "only" >>>>> takes 1475 seconds for the python 3.5 build but it is killed after 2541 >>>>> seconds in the python2.7 build. Given that it's the same code being built, >>>>> it seems like this more or less has to be infrastructure variability. >>>>> >>>>> I'll continue to explore, particularly breaking the build into stages, >>>>> but if anyone has suggestions on how to improve this please let me know. >>>>> >>>>> -greg >>>>> >>>>> >>>>> ------------------------------------------------------------ >>>>> ------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Rdkit-devel mailing list >>>>> Rdk...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel >>>>> >>>>> >>>> >>> >> > |
From: Greg L. <gre...@gm...> - 2017-06-13 14:19:00
|
On Tue, Jun 13, 2017 at 3:24 PM, Brian Kelley <fus...@gm...> wrote: > I'm unsure if that staging will help, aren't the builds and tests already > done in parallel effectively? > Kind of. There are currently two jobs that run in parallel: - job 1: build the core library, the python 2.7 wrappers, and the java wrappers and test everything - job 2: build the core library, the python 3.5 wrappers, and the java wrappers and test everything Those have no dependencies on each other. I would hope that by pulling the core library and test builds out into a separate job and then using the artifacts (=libraries) from that for the python and java builds we could shorten the individual jobs. -greg > On Tue, Jun 13, 2017 at 9:20 AM, Greg Landrum <gre...@gm...> > wrote: > >> Given that the current variability is almost a factor of two I don't >> think smaller changes are going to help. >> >> What I'm likely going to try is doing staged builds: >> - stage 1: build and test core library >> - stage 2a: build and test python 2.7 wrappers >> - stage 2b: build and test python 3.5 wrappers >> - stage 2c: build and test java wrappers >> >> the three "stage 2" things can run in parallel. >> >> From the bit of reading I did on the train this morning, it looks like >> this is not that horrible to do in jenkins; just need to invest a bit of >> time. >> >> -greg >> >> >> On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fus...@gm...> >> wrote: >> >>> I tried using ninja for the builds in stead of make, after an evening of >>> not building I successfully had two builds: >>> >>> https://travis-ci.org/bp-kelley/rdkit/builds/242399233 >>> >>> Commit: >>> >>> https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f6641301 >>> 1aed239413fe74da3388/.travis.yml >>> >>> Note that the default ninja build is #cores + 2 which blew out the >>> memory on the VMs so I used -j3 we could try this in the makefile as well. >>> >>> I also think we could shave off a few minutes by >>> >>> 1. building in the root conda env >>> 2. having only one conda install for *everything* >>> >>> If you like I can try these fixes. >>> >>> Cheers, >>> Brian >>> >>> On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <gre...@gm...> >>> wrote: >>> >>>> Dear all, >>>> >>>> We're getting more and more timeouts with RDKit builds on travis. I'm >>>> reasonably sure that this is due to some variability in the performance of >>>> the VMs that the builds end up running on. A good demonstration of that is >>>> this particular build (on a branch where I'm playing with simplifying the >>>> travis builds), which works fine for py35 but times out for py27: >>>> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc >>>> e=email&utm_medium=notification >>>> >>>> If you look into the details you'll see that the main compile "only" >>>> takes 1475 seconds for the python 3.5 build but it is killed after 2541 >>>> seconds in the python2.7 build. Given that it's the same code being built, >>>> it seems like this more or less has to be infrastructure variability. >>>> >>>> I'll continue to explore, particularly breaking the build into stages, >>>> but if anyone has suggestions on how to improve this please let me know. >>>> >>>> -greg >>>> >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Rdkit-devel mailing list >>>> Rdk...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel >>>> >>>> >>> >> > |
From: Brian K. <fus...@gm...> - 2017-06-13 13:24:24
|
I'm unsure if that staging will help, aren't the builds and tests already done in parallel effectively? On Tue, Jun 13, 2017 at 9:20 AM, Greg Landrum <gre...@gm...> wrote: > Given that the current variability is almost a factor of two I don't think > smaller changes are going to help. > > What I'm likely going to try is doing staged builds: > - stage 1: build and test core library > - stage 2a: build and test python 2.7 wrappers > - stage 2b: build and test python 3.5 wrappers > - stage 2c: build and test java wrappers > > the three "stage 2" things can run in parallel. > > From the bit of reading I did on the train this morning, it looks like > this is not that horrible to do in jenkins; just need to invest a bit of > time. > > -greg > > > On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fus...@gm...> > wrote: > >> I tried using ninja for the builds in stead of make, after an evening of >> not building I successfully had two builds: >> >> https://travis-ci.org/bp-kelley/rdkit/builds/242399233 >> >> Commit: >> >> https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f6641301 >> 1aed239413fe74da3388/.travis.yml >> >> Note that the default ninja build is #cores + 2 which blew out the memory >> on the VMs so I used -j3 we could try this in the makefile as well. >> >> I also think we could shave off a few minutes by >> >> 1. building in the root conda env >> 2. having only one conda install for *everything* >> >> If you like I can try these fixes. >> >> Cheers, >> Brian >> >> On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <gre...@gm...> >> wrote: >> >>> Dear all, >>> >>> We're getting more and more timeouts with RDKit builds on travis. I'm >>> reasonably sure that this is due to some variability in the performance of >>> the VMs that the builds end up running on. A good demonstration of that is >>> this particular build (on a branch where I'm playing with simplifying the >>> travis builds), which works fine for py35 but times out for py27: >>> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc >>> e=email&utm_medium=notification >>> >>> If you look into the details you'll see that the main compile "only" >>> takes 1475 seconds for the python 3.5 build but it is killed after 2541 >>> seconds in the python2.7 build. Given that it's the same code being built, >>> it seems like this more or less has to be infrastructure variability. >>> >>> I'll continue to explore, particularly breaking the build into stages, >>> but if anyone has suggestions on how to improve this please let me know. >>> >>> -greg >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Rdkit-devel mailing list >>> Rdk...@li... >>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel >>> >>> >> > |
From: Greg L. <gre...@gm...> - 2017-06-13 13:21:03
|
Given that the current variability is almost a factor of two I don't think smaller changes are going to help. What I'm likely going to try is doing staged builds: - stage 1: build and test core library - stage 2a: build and test python 2.7 wrappers - stage 2b: build and test python 3.5 wrappers - stage 2c: build and test java wrappers the three "stage 2" things can run in parallel. >From the bit of reading I did on the train this morning, it looks like this is not that horrible to do in jenkins; just need to invest a bit of time. -greg On Tue, Jun 13, 2017 at 3:12 PM, Brian Kelley <fus...@gm...> wrote: > I tried using ninja for the builds in stead of make, after an evening of > not building I successfully had two builds: > > https://travis-ci.org/bp-kelley/rdkit/builds/242399233 > > Commit: > > https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f66413011aed239413 > fe74da3388/.travis.yml > > Note that the default ninja build is #cores + 2 which blew out the memory > on the VMs so I used -j3 we could try this in the makefile as well. > > I also think we could shave off a few minutes by > > 1. building in the root conda env > 2. having only one conda install for *everything* > > If you like I can try these fixes. > > Cheers, > Brian > > On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <gre...@gm...> > wrote: > >> Dear all, >> >> We're getting more and more timeouts with RDKit builds on travis. I'm >> reasonably sure that this is due to some variability in the performance of >> the VMs that the builds end up running on. A good demonstration of that is >> this particular build (on a branch where I'm playing with simplifying the >> travis builds), which works fine for py35 but times out for py27: >> https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_sourc >> e=email&utm_medium=notification >> >> If you look into the details you'll see that the main compile "only" >> takes 1475 seconds for the python 3.5 build but it is killed after 2541 >> seconds in the python2.7 build. Given that it's the same code being built, >> it seems like this more or less has to be infrastructure variability. >> >> I'll continue to explore, particularly breaking the build into stages, >> but if anyone has suggestions on how to improve this please let me know. >> >> -greg >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Rdkit-devel mailing list >> Rdk...@li... >> https://lists.sourceforge.net/lists/listinfo/rdkit-devel >> >> > |
From: Brian K. <fus...@gm...> - 2017-06-13 13:12:24
|
I tried using ninja for the builds in stead of make, after an evening of not building I successfully had two builds: https://travis-ci.org/bp-kelley/rdkit/builds/242399233 Commit: https://github.com/bp-kelley/rdkit/blob/baac00bc1eb7f66413011aed239413fe74da3388/.travis.yml Note that the default ninja build is #cores + 2 which blew out the memory on the VMs so I used -j3 we could try this in the makefile as well. I also think we could shave off a few minutes by 1. building in the root conda env 2. having only one conda install for *everything* If you like I can try these fixes. Cheers, Brian On Tue, Jun 13, 2017 at 3:44 AM, Greg Landrum <gre...@gm...> wrote: > Dear all, > > We're getting more and more timeouts with RDKit builds on travis. I'm > reasonably sure that this is due to some variability in the performance of > the VMs that the builds end up running on. A good demonstration of that is > this particular build (on a branch where I'm playing with simplifying the > travis builds), which works fine for py35 but times out for py27: > https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_ > source=email&utm_medium=notification > > If you look into the details you'll see that the main compile "only" takes > 1475 seconds for the python 3.5 build but it is killed after 2541 seconds > in the python2.7 build. Given that it's the same code being built, it seems > like this more or less has to be infrastructure variability. > > I'll continue to explore, particularly breaking the build into stages, but > if anyone has suggestions on how to improve this please let me know. > > -greg > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Rdkit-devel mailing list > Rdk...@li... > https://lists.sourceforge.net/lists/listinfo/rdkit-devel > > |
From: Greg L. <gre...@gm...> - 2017-06-13 07:45:12
|
Dear all, We're getting more and more timeouts with RDKit builds on travis. I'm reasonably sure that this is due to some variability in the performance of the VMs that the builds end up running on. A good demonstration of that is this particular build (on a branch where I'm playing with simplifying the travis builds), which works fine for py35 but times out for py27: https://travis-ci.org/rdkit/rdkit/builds/242301061?utm_source=email&utm_medium=notification If you look into the details you'll see that the main compile "only" takes 1475 seconds for the python 3.5 build but it is killed after 2541 seconds in the python2.7 build. Given that it's the same code being built, it seems like this more or less has to be infrastructure variability. I'll continue to explore, particularly breaking the build into stages, but if anyone has suggestions on how to improve this please let me know. -greg |
From: Gianluca S. <gi...@gm...> - 2017-05-12 16:57:22
|
On Thu, May 11, 2017 at 4:52 PM, Gianluca Sforna <gi...@gm...> wrote: > The really weird failures are the the i686 ones, where all the tests > passed with python2, while a large number of them segfaulted on > python3. So I digged this issue further and got this backtrace of one segfault #0 0xf5381914 in boost::python::objects::enum_base::add_value(char const*, long) () from /lib/libboost_python3.so.1.60.0 #1 0xf4d9c00b in boost::python::enum_<RDKit::PicklerOps::PropertyPickleOptions>::value (x=RDKit::PicklerOps::AllProps, name=0xf4dcd94a "AllProps", this=0xffffabac) at /usr/include/boost/python/enum.hpp:95 #2 RDKit::mol_wrapper::wrap () at /builddir/build/BUILD/rdkit-Release_2017_03_1/python3/Code/GraphMol/Wrap/Mol.cpp:294 #3 0xf4d84c15 in wrap_mol () at /builddir/build/BUILD/rdkit-Release_2017_03_1/python3/Code/GraphMol/Wrap/Mol.cpp:711 #4 0xf4d3945a in init_module_rdchem () at /builddir/build/BUILD/rdkit-Release_2017_03_1/python3/Code/GraphMol/Wrap/rdchem.cpp:185 This seems to be related to the symbol AllProps, that was already changed to fix #1351 https://github.com/rdkit/rdkit/pull/1351 but probably still not suitable for use on 32bit linux; I read some pages around about the issue [1, 2] but I am still not sure abut the most reliable way to fix it. My takeaway is that we are not using a really robust approach, but with C++11 there is a slightly better method[3,4]; of course that would not help with the current release... Ideas? [1] http://stackoverflow.com/questions/12059774/c11-standard-conformant-bitmasks-using-enum-class [2] http://stackoverflow.com/questions/1448396/how-to-use-enums-as-flags-in-c [3] http://blog.bitwigglers.org/using-enum-classes-as-type-safe-bitmasks/ [4] https://www.justsoftwaresolutions.co.uk/cplusplus/using-enum-classes-as-bitfields.html -- Gianluca Sforna http://plus.google.com/+gianlucasforna - http://twitter.com/giallu Tinker Garage - http://tinkergarage.it |
From: Gianluca S. <gi...@gm...> - 2017-05-11 14:52:49
|
After the first release of 2017 I tried to rebuild the Fedora pakcages but tests have some issues on everything except x86_64. Here is a couple of links to build logs: rawhide example: https://koji.fedoraproject.org/koji/taskinfo?taskID=19487191 EPEL example: https://koji.fedoraproject.org/koji/taskinfo?taskID=19486424 If you looks at logs you will notice the issues are not always the same; in particular some just fails test3D (this is probably a math precision issue), while others could be related to big endian (ppc64). The really weird failures are the the i686 ones, where all the tests passed with python2, while a large number of them segfaulted on python3. Now, while I could disable tests on the RPM builds, that practice is discouraged so I hope someone will be able to make some sense out of these info so I will be able to push the updated package to repos. Regards Gianluca -- Gianluca Sforna http://plus.google.com/+gianlucasforna - http://twitter.com/giallu Tinker Garage - http://tinkergarage.it |
From: Brian K. <fus...@gm...> - 2017-05-08 13:58:06
|
Nitish, This is pretty interesting stuff :) There has been thinking about open-sourcing our in-house descriptor engine that we use to call some common chemistry software libraries. If it would be helpful at all, I can advance this project forward faster if you may find it useful. Note that a good half of the run-time is dedicated to actually being able to run the software, so it may be a good companion piece. Additionally, this is the first time I have heard of cclib actually, so thanks for bringing it to our attention. Cheers, Brian On Mon, May 8, 2017 at 9:06 AM, Nitish Garg <nit...@gm...> wrote: > Hi everyone, > > I am working on the project "Computational Chemistry Web repository > <https://summerofcode.withgoogle.com/organizations/6519372857212928/#6682363720368128>" > during GSoC 2017. > This project will require using cclib, 3Dmol.js, OpenBabel (and probably > RDKit in extension of this project) and thus, it suits to introduce this > project to the various mailing lists. > > This project is completely new and I would love to receive ideas from the > community on additional functionalities that can be added to this project. > Also, the official name of this project is yet to be fixed. I had > suggested 'CCviewer'. Let us discuss an appropriate name for the project. > > Project abstract: > cclib is used to parse calculation results from various chemistry software > log files. This project will be a flask-based framework making use of cclib > to parse a collection of such log files, store the parsed data in a > database and enable searching & filtering of these data records via a REST > API. The web front-end will be based on this API. Also, a chemistry > software log file can be uploaded on the webpage which will be parsed with > cclib to show the results. > Thus, this project will provide a web GUI for cclib, add searching > capability and also make use of 3Dmol.js to visualize the molecule in > browser (when file is uploaded as well as in search results). > > I had started with the simple functionality of showing parsed results from > uploaded file. The current code can be seen at : https://github.com/ > nitish6174/cclib-web. > I hope to migrate the code to a new repository under OpenChemistry's > github. > > Thanks, > Nitish Garg > B.Tech undergraduate, IIT Guwahati > GitHub : https://github.com/nitish6174 > Website : http://nitish6174.com/ > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Rdkit-devel mailing list > Rdk...@li... > https://lists.sourceforge.net/lists/listinfo/rdkit-devel > > |
From: Nitish G. <nit...@gm...> - 2017-05-08 13:07:20
|
Hi everyone, I am working on the project "Computational Chemistry Web repository <https://summerofcode.withgoogle.com/organizations/6519372857212928/#6682363720368128>" during GSoC 2017. This project will require using cclib, 3Dmol.js, OpenBabel (and probably RDKit in extension of this project) and thus, it suits to introduce this project to the various mailing lists. This project is completely new and I would love to receive ideas from the community on additional functionalities that can be added to this project. Also, the official name of this project is yet to be fixed. I had suggested 'CCviewer'. Let us discuss an appropriate name for the project. Project abstract: cclib is used to parse calculation results from various chemistry software log files. This project will be a flask-based framework making use of cclib to parse a collection of such log files, store the parsed data in a database and enable searching & filtering of these data records via a REST API. The web front-end will be based on this API. Also, a chemistry software log file can be uploaded on the webpage which will be parsed with cclib to show the results. Thus, this project will provide a web GUI for cclib, add searching capability and also make use of 3Dmol.js to visualize the molecule in browser (when file is uploaded as well as in search results). I had started with the simple functionality of showing parsed results from uploaded file. The current code can be seen at : https://github.com/nitish6174/cclib-web. I hope to migrate the code to a new repository under OpenChemistry's github. Thanks, Nitish Garg B.Tech undergraduate, IIT Guwahati GitHub : https://github.com/nitish6174 Website : http://nitish6174.com/ |
From: Greg L. <gre...@gm...> - 2017-04-28 06:53:43
|
Dear all, Now that the 2017_03 release cycle has started, I am *finally* ready to start the modern C++ work that I've discussed before. Here's a blog post on the topic: https://medium.com/@greg.landrum_t5/the-rdkit-and-modern-c-48206b966218 To that end I created a new branch this morning: https://github.com/rdkit/rdkit/tree/modern_cxx This was created from the current status of the master branch using the clang-modernize tools that are provided as part of the clang-tidy suite. The results have been hand tweaked based on a review done on an earlier version of this. I want to maintain as much backwards compatibility as possible so this isn't a "damn the torpedos" approach. My current target for legacy support is that it should be possible to build the code under CentOS6 using gcc 4.8, which is provided by the Developer Toolset v2.1 distributed by CERN ( http://linux.web.cern.ch/linux/devtoolset/). This seems like a pretty conservative choice given that CERN provides even more recent versions of gcc in later Developer Toolsets. There's still more testing to be done before I'm comfortable that this really is stable and ready to go, but I've been able to do at least basic builds and tests on Linux (Ubuntu 16.04 and Centos 6 using g++-4.8), macOS, and Windows, so I think we're off to a good start. As always, I'm happy to hear feedback, positive or negative, on this as well as suggestions on better ways to proceed. I'm really looking forward to finally getting to use (at least some of) the new features that modern C++ brings. Best, -greg |
From: Greg L. <gre...@gm...> - 2017-04-21 15:25:07
|
This is now resolved: the boost-1.56 build for python 3.6 on 64bit linux (the only python3.6 build that's currently done) is in place. |
From: Greg L. <gre...@gm...> - 2017-04-21 14:50:48
|
Right you are. I will push those too ________________________________ From: Maciek Wójcikowski <ma...@wo...> Sent: Friday, April 21, 2017 4:37:30 PM To: Greg Landrum Cc: RDKit Discuss; rdk...@li...; RDKit Developers List Subject: Re: [Rdkit-devel] 2017.03 (Q1 2017) RDKit Release Hi Greg, Just FYI rdkit for Python 3.6 requires boost 1.56 which has no Python 3.6 version in your repo. I just tested Linux packages, but it should be the same for other platforms. ---- Pozdrawiam, | Best regards, Maciek Wójcikowski ma...@wo...<mailto:ma...@wo...> 2017-04-21 6:36 GMT+02:00 Greg Landrum <gre...@gm...<mailto:gre...@gm...>>: I'm pleased to announce that the next version of the RDKit -- 2017.03 (a.k.a. Q1 2017) -- is released. The release notes are below. The release files are on the github release page: https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1 We are in the process of updating the conda build scripts to reflect the new version and uploading the binaries to anaconda.org<http://anaconda.org/> (https://anaconda.org/rdkit). The plan for conda binaries for this release is: Linux 64bit: python 2.7, 3.5, 3.6 Mac OS 64bit: python 2.7, 3.5, 3.6 Windows 64bit: python 2.7, 3.5, 3.6 Windows 32bit: python 2.7 Some things that will be finished over the next couple of days: - The conda build scripts will be updated to reflect the new version and new conda builds will be available in the RDKit channel at anaconda.org<http://anaconda.org/> (https://anaconda.org/rdkit). - The homebrew script - The online version of the documentation at rdkit.org<http://rdkit.org/> Thanks to everyone who submitted bug reports and suggestions for this release! Please let me know if you find any problems with the release or have suggestions for the next one, which is scheduled for September 2017. Best Regards, -greg # Release_2017.03.1 (Changes relative to Release_2016.09.1) ## Important - The fix for bug #879 changes the definition of the layered fingerprint. This means that all database columns using layered fingerprints as well as all substructure search indices should be rebuilt. - All C++ library names now start with RDKit (see #1349). ## Acknowledgements: Brian Cole, David Cosgrove, JW Feng, Berend Huisman, Peter Gedeck, 'i-tub', Jan Holst Jensen, Brian Kelley, Rich Lewis, Brian Mack, Eloy Felix Manzanares, Stephen Roughley, Roger Sayle, Nadine Schneider, Gregor Simm, Matt Swain, Paolo Tosco, Riccardo Vianello, Hsiao Yi ## Highlights: - It's now possible (though not the default) to pickle molecule properties with the molecule - There's a new, and still in development, "Getting started in C++" document. - A lot of the Python code has been cleaned up ## New Features and Enhancements: - Add removeHs option to MolFromSmiles() (github issue #554 from greglandrum) - support a fixed bond length in the MolDraw2D code (github issue #565 from greglandrum) - Pattern fingerprint should set bits for single-atom fragments. (github issue #879 from greglandrum) - Reviewed unit tests of rdkit.ML - coverage now 63.1% (github pull #1148 from gedeck) - Reviewed unit tests of rdkit.VLib - coverage now 67.1% (github pull #1149 from gedeck) - Removes exponetial numBonds behavior (github pull #1154 from bp-kelley) - Exposes normalize option to GetFlattenedFunctionalGroupHierarchy (github pull #1165 from bp-kelley) - Expose RWMol.ReplaceBond to Python (github pull #1174 from coleb) - Review of rdkit.Chem.Fraggle code (github pull #1184 from gedeck) - Add support for dative bonds. (github pull #1190 from janholstjensen) - Python 3 compatibility (issue #398) (github pull #1192 from gedeck) - 1194: Review assignments of range in Python code (github pull #1195 from gedeck) - Moved GenerateDepictionMatching[23]DStructure from Allchem.py to C++ (github pull #1197 from DavidACosgrove) - Review rdkit.Chem.pharm#D modules (github pull #1201 from gedeck) - Find potential stereo bonds should return any (github pull #1202 from coleb) - Gedeck coverage sim div filters (github pull #1208 from gedeck) - Gedeck review unit test inchi (github pull #1209 from gedeck) - Coverage rdkit.Dbase (github pull #1210 from gedeck) - Coverage rdkit.DataStructs (github pull #1211 from gedeck) - UnitTestPandas works on Python3 (github pull #1213 from gedeck) - Cleanup and improvement to test coverage of PandasTools (github pull #1215 from gedeck) - Cleanup of rdkit.Chem.Fingerprints (github pull #1217 from gedeck) - Optimization of UFF and MMFF forcefields (github pull #1218 from ptosco) - Support for ChemAxon Extended SMILES/SMARTS (github issue #1226 from greglandrum) - Improved test coverage for rdkit.Chem.Fingerprints (github pull #1243 from gedeck) - Adding a few tests for coverage utils (github pull #1244 from gedeck) - Make Pandastools modifications to generic RDkit functionality more obvious (github pull #1245 from gedeck) - Rename test file and cleanup (github pull #1246 from gedeck) - Review of rdkit.Chem.MolKey (github pull #1247 from gedeck) - Review tests in rdkit.Chem.SimpleEnum (github pull #1248 from gedeck) - Move execution of DocTests in rdkit.Chem into a UnitTest file (github pull #1256 from gedeck) - Review code in rdkit.Chem.Suppliers (github pull #1258 from gedeck) - Add python wraps (github pull #1259 from eloyfelix) - Rename file UnitTestDocTests in rdkitChem (github pull #1263 from gedeck) - Gedeck rdkit chem unit test surf (github pull #1267 from gedeck) - cleanup rdkit.Chem.Lipinski and rdkit.Chem.GraphDescriptors (github pull #1268 from gedeck) - Address Issue #1214 (github pull #1275 from gedeck) - Dev/pickle properties (github pull #1277 from bp-kelley) - Remove unused test boilerplate (github pull #1288 from gedeck) - Refactored the script SDFToCSV (github pull #1289 from gedeck) - Dev/rdmmpa api update (github pull #1291 from bp-kelley) - Fix/rogers fixes (github pull #1293 from bp-kelley) - Remove expected (error) output during unit tests (github pull #1298 from gedeck) - Refactor FeatFinderCLI and add unittests (github pull #1299 from gedeck) - Refactor BuildFragmentCatalog - 1 (github pull #1300 from gedeck) - Review of rdkit.Chem code - 1 (github pull #1301 from gedeck) - Minor cleanup in rdkit.Chem (github pull #1304 from gedeck) - Start using py3Dmol in the notebook (github pull #1308 from greglandrum) - Add the option to match formal charges to FMCS (github pull #1311 from greglandrum) - Review of rdkit.Chem.Subshape (github pull #1313 from gedeck) - Review rdkit.Chem.UnitTestSuppliers (github pull #1315 from gedeck) - Add cis/trans tags to double bonds (github pull #1316 from greglandrum) - MolDraw2D: make custom atom labels easier (github issue #1322 from greglandrum) - MolDraw2D: allow DrawMolecules() to put all molecules in one pane (github issue #1325 from greglandrum) - Refactoring rdkit.Chem.SATIS (github pull #1329 from gedeck) - Minor cleanup of rdkit.Chem.SaltRemover (github pull #1330 from gedeck) - Review rdkit.chem.FunctionalGroups and rdkit.Chem.UnitTestSuppliers (github pull #1331 from gedeck) - Get the tests working with python 3.6 (github pull #1332 from greglandrum) - add "RDKit" to the beginning of all library names (github pull #1349 from greglandrum) - Fix/sanitizerxn merge hs (github pull #1367 from bp-kelley) - Update AllChem.py (github pull #1378 from BerendHuisman) ## New Java Wrapper Features: ## Bug Fixes: - python2 code in python3 install (github issue #1042 from kcamnairb) - Fixes #1162 (resMolSupplierTest failing with boost 1.62) (github pull #1166 from ptosco) - add missing $RDKLIBS to cartridge build (github pull #1167 from rvianello) - Include <boost/cstdint.hpp> for uint64_t (github pull #1168 from mcs07) - replace std::map::at with std::map::find (github pull #1169 from mcs07) - Fix Trajectory GetSnapshot behaviour after Clear (github pull #1172 from mcs07) - Add Contrib dir to RDPaths (github pull #1176 from mcs07) - RDThreads.h: No such file or directory (github issue #1177 from gncs) - this now builds with vs2008 (github pull #1178 from greglandrum) - Add information on building RDkit on macOS using conda (github pull #1180 from gedeck) - new sequence capabilities not available from either Python or Java (github issue #1181 from greglandrum) - Gets the reaction sanitization code working correctly on 32bit systems (github pull #1187 from greglandrum) - Adds RDProps to c# wrapper (github pull #1188 from bp-kelley) - fix compatibility with PostgreSQL 9.2 (github pull #1189 from greglandrum) - Fixes memory leak in closeCheckMolFiles, fixes valgrind read issue in… (github pull #1200 from bp-kelley) - Support valences of 4 and 6 for Te (github issue #1204 from hsiaoyi0504) - Stereochemistry not output to SMILES when allHsExplicit=True (github issue #1219 from greglandrum) - Remove deprecated string module functions (github pull #1223 from gedeck) - Turns on -fpermissive for gcc >= 6 and boost < 1.62 (github pull #1225 from bp-kelley) - all-atom RMSD used to prune conformers in embedding code, docs say heavy-atom RMSD is used (github issue #1227 from greglandrum) - FindPotentialStereoBonds() failure (github issue #1230 from greglandrum) - make the Pandas version checking more robust (github pull #1239 from greglandrum) - Failure to embed larger aromatic rings (github issue #1240 from greglandrum) - fixed build failure on Windows due to missing link to library (github pull #1241 from ptosco) - fixed a test failure on Windows due to CR+LF encoding (github pull #1242 from ptosco) - MolFromMolBlock sanitizing when it should not be (github issue #1251 from greglandrum) - PMI descriptors incorrect (github issue #1262 from greglandrum) - Reactions don't modify isotope unless chemical element is specified for the product (github issue #1266 from i-tub) - Do not include the 3D descriptors in rdkit.Chem.Descriptors.descList (github issue #1287 from greglandrum) - ring stereochemistry perception failing for spiro centers (github issue #1294 from greglandrum) - Property pickling test failing on windows (github issue #1348 from greglandrum) - Fixes overflow error in boost when compiler chooses int for enum type (github pull #1351 from bp-kelley) - Hybridization type of group 1 metals (github issue #1352 from richlewis42) - bad python docs for some distance geometry functions (github issue #1385 from greglandrum) - Bond from reactant not added to product (github issue #1387 from greglandrum) - int32_t with no namespace in MolPickler.h (github issue #1388 from greglandrum) ## Contrib updates: - Chemical reaction role assignment code from Nadine Schneider (github pull #1185 from NadineSchneider) ## Deprecated code (to be removed in a future release): - rdkit.Chem.MCS: please use rdkit.Chem.rdFMCS instead ------------------------------------------------------------------------------ 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...<mailto:Rdk...@li...> https://lists.sourceforge.net/lists/listinfo/rdkit-devel |
From: Maciek W. <ma...@wo...> - 2017-04-21 14:38:21
|
Hi Greg, Just FYI rdkit for Python 3.6 requires boost 1.56 which has no Python 3.6 version in your repo. I just tested Linux packages, but it should be the same for other platforms. ---- Pozdrawiam, | Best regards, Maciek Wójcikowski ma...@wo... 2017-04-21 6:36 GMT+02:00 Greg Landrum <gre...@gm...>: > I'm pleased to announce that the next version of the RDKit -- 2017.03 > (a.k.a. Q1 2017) -- is released. The release notes are below. > > The release files are on the github release page: > *https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1 > <https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1>* > > We are in the process of updating the conda build scripts to reflect the > new version and uploading the binaries to anaconda.org (https:// > anaconda.org/rdkit). > The plan for conda binaries for this release is: > Linux 64bit: python 2.7, 3.5, 3.6 > Mac OS 64bit: python 2.7, 3.5, 3.6 > Windows 64bit: python 2.7, 3.5, 3.6 > Windows 32bit: python 2.7 > > Some things that will be finished over the next couple of days: > - The conda build scripts will be updated to reflect the new version and > new conda builds will be available in the RDKit channel at anaconda.org ( > https://anaconda.org/rdkit). > - The homebrew script > - The online version of the documentation at rdkit.org > > Thanks to everyone who submitted bug reports and suggestions for this > release! > > Please let me know if you find any problems with the release or have > suggestions for the next one, which is scheduled for September 2017. > > Best Regards, > -greg > > # Release_2017.03.1 > (Changes relative to Release_2016.09.1) > > ## Important > - The fix for bug #879 changes the definition of the layered fingerprint. > This means that all database columns using layered fingerprints as well > as > all substructure search indices should be rebuilt. > - All C++ library names now start with RDKit (see #1349). > > ## Acknowledgements: > Brian Cole, David Cosgrove, JW Feng, Berend Huisman, Peter Gedeck, 'i-tub', > Jan Holst Jensen, Brian Kelley, Rich Lewis, Brian Mack, Eloy Felix > Manzanares, > Stephen Roughley, Roger Sayle, Nadine Schneider, Gregor Simm, Matt Swain, > Paolo Tosco, Riccardo Vianello, Hsiao Yi > > ## Highlights: > - It's now possible (though not the default) to pickle molecule > properties > with the molecule > - There's a new, and still in development, "Getting started in C++" > document. > - A lot of the Python code has been cleaned up > > ## New Features and Enhancements: > - Add removeHs option to MolFromSmiles() > (github issue #554 from greglandrum) > - support a fixed bond length in the MolDraw2D code > (github issue #565 from greglandrum) > - Pattern fingerprint should set bits for single-atom fragments. > (github issue #879 from greglandrum) > - Reviewed unit tests of rdkit.ML - coverage now 63.1% > (github pull #1148 from gedeck) > - Reviewed unit tests of rdkit.VLib - coverage now 67.1% > (github pull #1149 from gedeck) > - Removes exponetial numBonds behavior > (github pull #1154 from bp-kelley) > - Exposes normalize option to GetFlattenedFunctionalGroupHierarchy > (github pull #1165 from bp-kelley) > - Expose RWMol.ReplaceBond to Python > (github pull #1174 from coleb) > - Review of rdkit.Chem.Fraggle code > (github pull #1184 from gedeck) > - Add support for dative bonds. > (github pull #1190 from janholstjensen) > - Python 3 compatibility (issue #398) > (github pull #1192 from gedeck) > - 1194: Review assignments of range in Python code > (github pull #1195 from gedeck) > - Moved GenerateDepictionMatching[23]DStructure from Allchem.py to C++ > (github pull #1197 from DavidACosgrove) > - Review rdkit.Chem.pharm#D modules > (github pull #1201 from gedeck) > - Find potential stereo bonds should return any > (github pull #1202 from coleb) > - Gedeck coverage sim div filters > (github pull #1208 from gedeck) > - Gedeck review unit test inchi > (github pull #1209 from gedeck) > - Coverage rdkit.Dbase > (github pull #1210 from gedeck) > - Coverage rdkit.DataStructs > (github pull #1211 from gedeck) > - UnitTestPandas works on Python3 > (github pull #1213 from gedeck) > - Cleanup and improvement to test coverage of PandasTools > (github pull #1215 from gedeck) > - Cleanup of rdkit.Chem.Fingerprints > (github pull #1217 from gedeck) > - Optimization of UFF and MMFF forcefields > (github pull #1218 from ptosco) > - Support for ChemAxon Extended SMILES/SMARTS > (github issue #1226 from greglandrum) > - Improved test coverage for rdkit.Chem.Fingerprints > (github pull #1243 from gedeck) > - Adding a few tests for coverage utils > (github pull #1244 from gedeck) > - Make Pandastools modifications to generic RDkit functionality more > obvious > (github pull #1245 from gedeck) > - Rename test file and cleanup > (github pull #1246 from gedeck) > - Review of rdkit.Chem.MolKey > (github pull #1247 from gedeck) > - Review tests in rdkit.Chem.SimpleEnum > (github pull #1248 from gedeck) > - Move execution of DocTests in rdkit.Chem into a UnitTest file > (github pull #1256 from gedeck) > - Review code in rdkit.Chem.Suppliers > (github pull #1258 from gedeck) > - Add python wraps > (github pull #1259 from eloyfelix) > - Rename file UnitTestDocTests in rdkitChem > (github pull #1263 from gedeck) > - Gedeck rdkit chem unit test surf > (github pull #1267 from gedeck) > - cleanup rdkit.Chem.Lipinski and rdkit.Chem.GraphDescriptors > (github pull #1268 from gedeck) > - Address Issue #1214 > (github pull #1275 from gedeck) > - Dev/pickle properties > (github pull #1277 from bp-kelley) > - Remove unused test boilerplate > (github pull #1288 from gedeck) > - Refactored the script SDFToCSV > (github pull #1289 from gedeck) > - Dev/rdmmpa api update > (github pull #1291 from bp-kelley) > - Fix/rogers fixes > (github pull #1293 from bp-kelley) > - Remove expected (error) output during unit tests > (github pull #1298 from gedeck) > - Refactor FeatFinderCLI and add unittests > (github pull #1299 from gedeck) > - Refactor BuildFragmentCatalog - 1 > (github pull #1300 from gedeck) > - Review of rdkit.Chem code - 1 > (github pull #1301 from gedeck) > - Minor cleanup in rdkit.Chem > (github pull #1304 from gedeck) > - Start using py3Dmol in the notebook > (github pull #1308 from greglandrum) > - Add the option to match formal charges to FMCS > (github pull #1311 from greglandrum) > - Review of rdkit.Chem.Subshape > (github pull #1313 from gedeck) > - Review rdkit.Chem.UnitTestSuppliers > (github pull #1315 from gedeck) > - Add cis/trans tags to double bonds > (github pull #1316 from greglandrum) > - MolDraw2D: make custom atom labels easier > (github issue #1322 from greglandrum) > - MolDraw2D: allow DrawMolecules() to put all molecules in one pane > (github issue #1325 from greglandrum) > - Refactoring rdkit.Chem.SATIS > (github pull #1329 from gedeck) > - Minor cleanup of rdkit.Chem.SaltRemover > (github pull #1330 from gedeck) > - Review rdkit.chem.FunctionalGroups and rdkit.Chem.UnitTestSuppliers > (github pull #1331 from gedeck) > - Get the tests working with python 3.6 > (github pull #1332 from greglandrum) > - add "RDKit" to the beginning of all library names > (github pull #1349 from greglandrum) > - Fix/sanitizerxn merge hs > (github pull #1367 from bp-kelley) > - Update AllChem.py > (github pull #1378 from BerendHuisman) > > ## New Java Wrapper Features: > > ## Bug Fixes: > - python2 code in python3 install > (github issue #1042 from kcamnairb) > - Fixes #1162 (resMolSupplierTest failing with boost 1.62) > (github pull #1166 from ptosco) > - add missing $RDKLIBS to cartridge build > (github pull #1167 from rvianello) > - Include <boost/cstdint.hpp> for uint64_t > (github pull #1168 from mcs07) > - replace std::map::at with std::map::find > (github pull #1169 from mcs07) > - Fix Trajectory GetSnapshot behaviour after Clear > (github pull #1172 from mcs07) > - Add Contrib dir to RDPaths > (github pull #1176 from mcs07) > - RDThreads.h: No such file or directory > (github issue #1177 from gncs) > - this now builds with vs2008 > (github pull #1178 from greglandrum) > - Add information on building RDkit on macOS using conda > (github pull #1180 from gedeck) > - new sequence capabilities not available from either Python or Java > (github issue #1181 from greglandrum) > - Gets the reaction sanitization code working correctly on 32bit systems > (github pull #1187 from greglandrum) > - Adds RDProps to c# wrapper > (github pull #1188 from bp-kelley) > - fix compatibility with PostgreSQL 9.2 > (github pull #1189 from greglandrum) > - Fixes memory leak in closeCheckMolFiles, fixes valgrind read issue in… > (github pull #1200 from bp-kelley) > - Support valences of 4 and 6 for Te > (github issue #1204 from hsiaoyi0504) > - Stereochemistry not output to SMILES when allHsExplicit=True > (github issue #1219 from greglandrum) > - Remove deprecated string module functions > (github pull #1223 from gedeck) > - Turns on -fpermissive for gcc >= 6 and boost < 1.62 > (github pull #1225 from bp-kelley) > - all-atom RMSD used to prune conformers in embedding code, docs say > heavy-atom RMSD is used > (github issue #1227 from greglandrum) > - FindPotentialStereoBonds() failure > (github issue #1230 from greglandrum) > - make the Pandas version checking more robust > (github pull #1239 from greglandrum) > - Failure to embed larger aromatic rings > (github issue #1240 from greglandrum) > - fixed build failure on Windows due to missing link to library > (github pull #1241 from ptosco) > - fixed a test failure on Windows due to CR+LF encoding > (github pull #1242 from ptosco) > - MolFromMolBlock sanitizing when it should not be > (github issue #1251 from greglandrum) > - PMI descriptors incorrect > (github issue #1262 from greglandrum) > - Reactions don't modify isotope unless chemical element is specified > for the product > (github issue #1266 from i-tub) > - Do not include the 3D descriptors in rdkit.Chem.Descriptors.descList > (github issue #1287 from greglandrum) > - ring stereochemistry perception failing for spiro centers > (github issue #1294 from greglandrum) > - Property pickling test failing on windows > (github issue #1348 from greglandrum) > - Fixes overflow error in boost when compiler chooses int for enum type > (github pull #1351 from bp-kelley) > - Hybridization type of group 1 metals > (github issue #1352 from richlewis42) > - bad python docs for some distance geometry functions > (github issue #1385 from greglandrum) > - Bond from reactant not added to product > (github issue #1387 from greglandrum) > - int32_t with no namespace in MolPickler.h > (github issue #1388 from greglandrum) > > ## Contrib updates: > - Chemical reaction role assignment code from Nadine Schneider > (github pull #1185 from NadineSchneider) > > ## Deprecated code (to be removed in a future release): > - rdkit.Chem.MCS: please use rdkit.Chem.rdFMCS instead > > ------------------------------------------------------------ > ------------------ > 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 > > |
From: Greg L. <gre...@gm...> - 2017-04-21 04:36:39
|
I'm pleased to announce that the next version of the RDKit -- 2017.03 (a.k.a. Q1 2017) -- is released. The release notes are below. The release files are on the github release page: *https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1 <https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1>* We are in the process of updating the conda build scripts to reflect the new version and uploading the binaries to anaconda.org (https://anaconda .org/rdkit). The plan for conda binaries for this release is: Linux 64bit: python 2.7, 3.5, 3.6 Mac OS 64bit: python 2.7, 3.5, 3.6 Windows 64bit: python 2.7, 3.5, 3.6 Windows 32bit: python 2.7 Some things that will be finished over the next couple of days: - The conda build scripts will be updated to reflect the new version and new conda builds will be available in the RDKit channel at anaconda.org ( https://anaconda.org/rdkit). - The homebrew script - The online version of the documentation at rdkit.org Thanks to everyone who submitted bug reports and suggestions for this release! Please let me know if you find any problems with the release or have suggestions for the next one, which is scheduled for September 2017. Best Regards, -greg # Release_2017.03.1 (Changes relative to Release_2016.09.1) ## Important - The fix for bug #879 changes the definition of the layered fingerprint. This means that all database columns using layered fingerprints as well as all substructure search indices should be rebuilt. - All C++ library names now start with RDKit (see #1349). ## Acknowledgements: Brian Cole, David Cosgrove, JW Feng, Berend Huisman, Peter Gedeck, 'i-tub', Jan Holst Jensen, Brian Kelley, Rich Lewis, Brian Mack, Eloy Felix Manzanares, Stephen Roughley, Roger Sayle, Nadine Schneider, Gregor Simm, Matt Swain, Paolo Tosco, Riccardo Vianello, Hsiao Yi ## Highlights: - It's now possible (though not the default) to pickle molecule properties with the molecule - There's a new, and still in development, "Getting started in C++" document. - A lot of the Python code has been cleaned up ## New Features and Enhancements: - Add removeHs option to MolFromSmiles() (github issue #554 from greglandrum) - support a fixed bond length in the MolDraw2D code (github issue #565 from greglandrum) - Pattern fingerprint should set bits for single-atom fragments. (github issue #879 from greglandrum) - Reviewed unit tests of rdkit.ML - coverage now 63.1% (github pull #1148 from gedeck) - Reviewed unit tests of rdkit.VLib - coverage now 67.1% (github pull #1149 from gedeck) - Removes exponetial numBonds behavior (github pull #1154 from bp-kelley) - Exposes normalize option to GetFlattenedFunctionalGroupHierarchy (github pull #1165 from bp-kelley) - Expose RWMol.ReplaceBond to Python (github pull #1174 from coleb) - Review of rdkit.Chem.Fraggle code (github pull #1184 from gedeck) - Add support for dative bonds. (github pull #1190 from janholstjensen) - Python 3 compatibility (issue #398) (github pull #1192 from gedeck) - 1194: Review assignments of range in Python code (github pull #1195 from gedeck) - Moved GenerateDepictionMatching[23]DStructure from Allchem.py to C++ (github pull #1197 from DavidACosgrove) - Review rdkit.Chem.pharm#D modules (github pull #1201 from gedeck) - Find potential stereo bonds should return any (github pull #1202 from coleb) - Gedeck coverage sim div filters (github pull #1208 from gedeck) - Gedeck review unit test inchi (github pull #1209 from gedeck) - Coverage rdkit.Dbase (github pull #1210 from gedeck) - Coverage rdkit.DataStructs (github pull #1211 from gedeck) - UnitTestPandas works on Python3 (github pull #1213 from gedeck) - Cleanup and improvement to test coverage of PandasTools (github pull #1215 from gedeck) - Cleanup of rdkit.Chem.Fingerprints (github pull #1217 from gedeck) - Optimization of UFF and MMFF forcefields (github pull #1218 from ptosco) - Support for ChemAxon Extended SMILES/SMARTS (github issue #1226 from greglandrum) - Improved test coverage for rdkit.Chem.Fingerprints (github pull #1243 from gedeck) - Adding a few tests for coverage utils (github pull #1244 from gedeck) - Make Pandastools modifications to generic RDkit functionality more obvious (github pull #1245 from gedeck) - Rename test file and cleanup (github pull #1246 from gedeck) - Review of rdkit.Chem.MolKey (github pull #1247 from gedeck) - Review tests in rdkit.Chem.SimpleEnum (github pull #1248 from gedeck) - Move execution of DocTests in rdkit.Chem into a UnitTest file (github pull #1256 from gedeck) - Review code in rdkit.Chem.Suppliers (github pull #1258 from gedeck) - Add python wraps (github pull #1259 from eloyfelix) - Rename file UnitTestDocTests in rdkitChem (github pull #1263 from gedeck) - Gedeck rdkit chem unit test surf (github pull #1267 from gedeck) - cleanup rdkit.Chem.Lipinski and rdkit.Chem.GraphDescriptors (github pull #1268 from gedeck) - Address Issue #1214 (github pull #1275 from gedeck) - Dev/pickle properties (github pull #1277 from bp-kelley) - Remove unused test boilerplate (github pull #1288 from gedeck) - Refactored the script SDFToCSV (github pull #1289 from gedeck) - Dev/rdmmpa api update (github pull #1291 from bp-kelley) - Fix/rogers fixes (github pull #1293 from bp-kelley) - Remove expected (error) output during unit tests (github pull #1298 from gedeck) - Refactor FeatFinderCLI and add unittests (github pull #1299 from gedeck) - Refactor BuildFragmentCatalog - 1 (github pull #1300 from gedeck) - Review of rdkit.Chem code - 1 (github pull #1301 from gedeck) - Minor cleanup in rdkit.Chem (github pull #1304 from gedeck) - Start using py3Dmol in the notebook (github pull #1308 from greglandrum) - Add the option to match formal charges to FMCS (github pull #1311 from greglandrum) - Review of rdkit.Chem.Subshape (github pull #1313 from gedeck) - Review rdkit.Chem.UnitTestSuppliers (github pull #1315 from gedeck) - Add cis/trans tags to double bonds (github pull #1316 from greglandrum) - MolDraw2D: make custom atom labels easier (github issue #1322 from greglandrum) - MolDraw2D: allow DrawMolecules() to put all molecules in one pane (github issue #1325 from greglandrum) - Refactoring rdkit.Chem.SATIS (github pull #1329 from gedeck) - Minor cleanup of rdkit.Chem.SaltRemover (github pull #1330 from gedeck) - Review rdkit.chem.FunctionalGroups and rdkit.Chem.UnitTestSuppliers (github pull #1331 from gedeck) - Get the tests working with python 3.6 (github pull #1332 from greglandrum) - add "RDKit" to the beginning of all library names (github pull #1349 from greglandrum) - Fix/sanitizerxn merge hs (github pull #1367 from bp-kelley) - Update AllChem.py (github pull #1378 from BerendHuisman) ## New Java Wrapper Features: ## Bug Fixes: - python2 code in python3 install (github issue #1042 from kcamnairb) - Fixes #1162 (resMolSupplierTest failing with boost 1.62) (github pull #1166 from ptosco) - add missing $RDKLIBS to cartridge build (github pull #1167 from rvianello) - Include <boost/cstdint.hpp> for uint64_t (github pull #1168 from mcs07) - replace std::map::at with std::map::find (github pull #1169 from mcs07) - Fix Trajectory GetSnapshot behaviour after Clear (github pull #1172 from mcs07) - Add Contrib dir to RDPaths (github pull #1176 from mcs07) - RDThreads.h: No such file or directory (github issue #1177 from gncs) - this now builds with vs2008 (github pull #1178 from greglandrum) - Add information on building RDkit on macOS using conda (github pull #1180 from gedeck) - new sequence capabilities not available from either Python or Java (github issue #1181 from greglandrum) - Gets the reaction sanitization code working correctly on 32bit systems (github pull #1187 from greglandrum) - Adds RDProps to c# wrapper (github pull #1188 from bp-kelley) - fix compatibility with PostgreSQL 9.2 (github pull #1189 from greglandrum) - Fixes memory leak in closeCheckMolFiles, fixes valgrind read issue in… (github pull #1200 from bp-kelley) - Support valences of 4 and 6 for Te (github issue #1204 from hsiaoyi0504) - Stereochemistry not output to SMILES when allHsExplicit=True (github issue #1219 from greglandrum) - Remove deprecated string module functions (github pull #1223 from gedeck) - Turns on -fpermissive for gcc >= 6 and boost < 1.62 (github pull #1225 from bp-kelley) - all-atom RMSD used to prune conformers in embedding code, docs say heavy-atom RMSD is used (github issue #1227 from greglandrum) - FindPotentialStereoBonds() failure (github issue #1230 from greglandrum) - make the Pandas version checking more robust (github pull #1239 from greglandrum) - Failure to embed larger aromatic rings (github issue #1240 from greglandrum) - fixed build failure on Windows due to missing link to library (github pull #1241 from ptosco) - fixed a test failure on Windows due to CR+LF encoding (github pull #1242 from ptosco) - MolFromMolBlock sanitizing when it should not be (github issue #1251 from greglandrum) - PMI descriptors incorrect (github issue #1262 from greglandrum) - Reactions don't modify isotope unless chemical element is specified for the product (github issue #1266 from i-tub) - Do not include the 3D descriptors in rdkit.Chem.Descriptors.descList (github issue #1287 from greglandrum) - ring stereochemistry perception failing for spiro centers (github issue #1294 from greglandrum) - Property pickling test failing on windows (github issue #1348 from greglandrum) - Fixes overflow error in boost when compiler chooses int for enum type (github pull #1351 from bp-kelley) - Hybridization type of group 1 metals (github issue #1352 from richlewis42) - bad python docs for some distance geometry functions (github issue #1385 from greglandrum) - Bond from reactant not added to product (github issue #1387 from greglandrum) - int32_t with no namespace in MolPickler.h (github issue #1388 from greglandrum) ## Contrib updates: - Chemical reaction role assignment code from Nadine Schneider (github pull #1185 from NadineSchneider) ## Deprecated code (to be removed in a future release): - rdkit.Chem.MCS: please use rdkit.Chem.rdFMCS instead |
From: Greg L. <gre...@gm...> - 2017-04-01 05:58:33
|
[apologies for the date of this... it's not an April Fools joke] Dear all, I have tagged a beta of the next RDKit release here: https://github.com/rdkit/rdkit/releases/tag/Release_2017_03_1b1 The release notes are on the release page linked above. Note that the list of people in the acknowledgement section was mostly created automatically from github. If you feel like I missed you, or if I got your name wrong, please let me know so that I can update the release notes before the actual release. To make testing easier, I've done conda builds for 64bit linux (python 3.5 and python 2.7) and windows (just python v3.5 for the beta, there were some problems with the python 2.7 build that will be fixed for the release). Since this is still a beta, I've labelled them "testing", so you need to install them like this: conda install -c rdkit/label/testing rdkit Unless major problems are found, I plan to do the actual release in 2-3 weeks. I'm going to be travelling for the next couple of weeks so the usual beta period is a bit longer. Between now and then I hope to get another bug or two fixed but this should otherwise be it for features.. Best, -greg |
From: Greg L. <gre...@gm...> - 2017-03-27 04:21:21
|
Gayathree, Those instructions are for installing a binary version of the RDKit. They are not well suited for setting up an environment where you build from source. For the purposes of getting something done quickly while you're preparing your GSoC application (there's not a lot of time left), I would suggest that you go ahead and use the binary install and that you make your changes there. Once you've tested them and think that they are ready for others to see, you can submit your proposed changes here by just emailing the files that you changed. This isn't the normal way of doing a submission, and we'll have to make sure that you have a proper github checkout if your application is accepted, but it allows you to get going quickly. The next step would be to find the files that conda install created and start working with them. Where these files are depend on the details of your anaconda installation and you'll have to poke around a bit to find them. Here's where my rdkit source ends up when I conda install it into an environment named "py35_rdkit": ~/anaconda3/envs/py35_rdkit/lib/python3.5/site-packages/rdkit/ -greg On Sun, Mar 26, 2017 at 8:45 PM, Gayathree Kaluarachchi < kal...@gm...> wrote: > Hello everyone, > > I have installed RDKit using Anaconda and download the latest release of > RDKit following the steps in http://www.rdkit.org/docs/ > Install.html#cross-platform-under-anaconda-python-fastest-install . > But I have stuck in next step which is building RDKit. I setup environment > variable according to the documentation as well. > It would be much appreciated, if anyone can give me an idea on that and > give any tip on how to build RDKit in local workspace. > > Thank you. > > Best regards, > Gayathree. > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Rdkit-devel mailing list > Rdk...@li... > https://lists.sourceforge.net/lists/listinfo/rdkit-devel > > |
From: Gayathree K. <kal...@gm...> - 2017-03-26 18:45:12
|
Hello everyone, I have installed RDKit using Anaconda and download the latest release of RDKit following the steps in http://www.rdkit.org/docs/Install.html#cross-platform-under-anaconda-python-fastest-install . But I have stuck in next step which is building RDKit. I setup environment variable according to the documentation as well. It would be much appreciated, if anyone can give me an idea on that and give any tip on how to build RDKit in local workspace. Thank you. Best regards, Gayathree. |