rdkit-devel Mailing List for RDKit (Page 17)
Open-Source Cheminformatics and Machine Learning
Brought to you by:
glandrum
Menu
▾
▴
rdkit-devel — Developers information and discussion.
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: Greg L. <gre...@gm...> - 2011-10-23 14:28:49
|
Adrian, On Wed, Oct 12, 2011 at 2:30 PM, Adrian Schreyer <am...@ca...> wrote: > > I made some small changes to the database cartridge code in order to > compile it under 9.1 and also to use the new extension infrastructure. > The exact changes are probably the easiest to see in my bitbucket > repository changesets > (https://bitbucket.org/aschreyer/rdkit/changesets). It's currently > running on our 9.1 server without any problems. I just merged your changes in along with some tweaks to allow the cartridge to still build under older versions of postgresql. Thanks for figuring out how to do this! The build instructions have changed, the new version is here: http://code.google.com/p/rdkit/wiki/BuildingTheCartridge Best Regards, -greg |
|
From: Greg L. <gre...@gm...> - 2011-10-13 08:16:20
|
Adrian, On Wed, Oct 12, 2011 at 8:30 AM, Adrian Schreyer <am...@ca...> wrote: > > I made some small changes to the database cartridge code in order to > compile it under 9.1 and also to use the new extension infrastructure. > The exact changes are probably the easiest to see in my bitbucket > repository changesets > (https://bitbucket.org/aschreyer/rdkit/changesets). It's currently > running on our 9.1 server without any problems. Very cool. Thanks for doing this and letting me know about it! I'll grab a copy and take a look over the next few days. -greg |
|
From: Adrian S. <am...@ca...> - 2011-10-12 12:30:57
|
Hi Greg, I made some small changes to the database cartridge code in order to compile it under 9.1 and also to use the new extension infrastructure. The exact changes are probably the easiest to see in my bitbucket repository changesets (https://bitbucket.org/aschreyer/rdkit/changesets). It's currently running on our 9.1 server without any problems. Cheers, Adrian |
|
From: Greg L. <gre...@gm...> - 2011-10-08 16:40:40
|
I'm very happy to announce that the next version of the RDKit -- 2011.09 (a.k.a Q3 2011) -- is released. The release notes are below. The source release is on the sourceforge downloads page: http://sourceforge.net/projects/rdkit/files/rdkit/Q3_2011/ The files can also be downloaded from the google project page: http://code.google.com/p/rdkit/downloads/list The binaries for Windows, Python 2.6 and Python 2.7 are uploaded already. Thanks to the everyone who submitted bug reports and suggestions for this release! Please let me know if you find any problems with the release or have suggestions for the next one. -greg ****** Release_2011.09.1 ******* (Changes relative to Release_2011.06.1) !!!!!! IMPORTANT !!!!!! - A bug in the definition of the Lipinski HBD descriptor was fixed in this release. The descriptor Lipinski.NHOHCount will return different values for molecules containing Ns or Os with more than one attached H. Acknowledgements: Eddie Cao, Richard Cooper, Paul Czodrowski, James Davidson, George Papadatos, Riccardo Vianello Bug Fixes: - A problem with interpretation of stereochemistry from mol files was fixed (Issue 3374639) - Sterochemistry information for exocyclic double bonds in mol blocks is no longer lost. (Issue 3375647) - linear double bonds from mol files now have their stereochemistry set correctly(Issue 3375684) - Chirality for phosphates and sulfates is not longer automatically removed. (Issue 3376319) - A bug with the reading of query information from mol files was fixed. (Issue 3392107) - Sterochemistry is now cleaned up after processing mol2 files. (Issue 3399798) - mergeQueryHs now correctly handles atoms with multiple Hs (Issue 3415204) - mergeQueryHs now correctly handles atoms without initial query information (Issue 3415206) - the calcLipinskiHBD() (equivalent to Lipinski.NHOHCount) descriptor now correctly handles Ns or Os with multiple Hs. (Issue 3415534) - Morgan fingerprints generated using the fromAtoms argument now have all bits from those atoms set.(Issue 3415636) - A problem with the way MolSuppliers handle the EOF condition when built with the most recent versions of g++ was fixed. - Translation of RDKit stereochemistry information into InChI stereochemistry information is improved. New Features: New Database Cartridge Features: - molecules can now be built from mol blocks using the function mol_from_ctab(). The corresponding is_valid_ctab() function was also added. - the radius argument is now optional for the functions morganbv_fp, morgan_fp, featmorganbv_fp, and featmorgan_fp. The default radius for all four functions is 2. Deprecated modules (to be removed in next release): Removed modules: Other: - The documentation in $RDBASE/Docs/Book has been migrated to use Sphinx instead of OpenOffice. - The optional InChI support can now be built using a system installation of the InChI library. |
|
From: Greg L. <gre...@gm...> - 2011-09-04 11:09:56
|
Michael, On Sun, Sep 4, 2011 at 11:59 AM, Michael Banck <mb...@gm...> wrote: > > On Sun, Sep 04, 2011 at 06:46:56AM +0200, Greg Landrum wrote: >> Dear Michael >> >> On Sat, Sep 3, 2011 at 2:08 PM, Michael Banck <mb...@de...> wrote: >> > >> > I have uploaded rdkit packages to Debian today, they are pending archive >> > admin review. >> >> Wow, fantastic. Thanks! > > Rdkit is now in Debian, there was only one major issue: the Docs/Book > directory is licensed CC-BY-SA 2.5, which Debian does not accept as a > Free Software license, so I had to remove this for the first upload. > > However, the issues Debian had got fixed with the 3.0 version of the > CC-BY-SA license, so if you are in a position to relicense that content > to it, we could ship it in Debian for the next release of rdkit. The license.html file that mentions CC-BY-SA 2.5 should never have been checked in. I removed it. The remaining files are CC-BY-SA 3.0, so they should be fine. -greg |
|
From: Michael B. <mb...@gm...> - 2011-09-04 09:59:14
|
Hi, On Sun, Sep 04, 2011 at 06:46:56AM +0200, Greg Landrum wrote: > Dear Michael > > On Sat, Sep 3, 2011 at 2:08 PM, Michael Banck <mb...@de...> wrote: > > > > I have uploaded rdkit packages to Debian today, they are pending archive > > admin review. > > Wow, fantastic. Thanks! Rdkit is now in Debian, there was only one major issue: the Docs/Book directory is licensed CC-BY-SA 2.5, which Debian does not accept as a Free Software license, so I had to remove this for the first upload. However, the issues Debian had got fixed with the 3.0 version of the CC-BY-SA license, so if you are in a position to relicense that content to it, we could ship it in Debian for the next release of rdkit. Best regards, Michael |
|
From: Greg L. <gre...@gm...> - 2011-09-04 04:47:29
|
Dear Michael
On Sat, Sep 3, 2011 at 2:08 PM, Michael Banck <mb...@de...> wrote:
>
> I have uploaded rdkit packages to Debian today, they are pending archive
> admin review.
Wow, fantastic. Thanks!
> I am slightly worried about the copyright in Data/Crippen.txt ("All
> Rights Reserved"), but hopefully it will pass and should be available in
> the near future. You could consider making that one similar to the
> other Code boilerplate ("The contents are covered by the terms of the
> BSD license...") if you have control over the content.
I just checked in changes to the data files so that they include the
license information. Thanks for pointing out the oversight.
> About the libraries in /usr/lib, are they supposed to be used by 3rd
> party programs, or meant internally for the python shared objects? I
> looked into linking them statically into the python objects, but a
> comment about exception handling made be reconsider.
They do need to be shared libraries in order for both exception
handling and cross-module use of objects to work.
> Some of the library names are quite generic ("libCatalogs") and this
> might make trouble (i.e. file name clashes with other Debian packages).
> One option would be to rename them so they all have an RD prefix
> (thought depending on how many external users there are, this should be
> scheduled for a SOVERSION bump I guess), or support having them in e.g.
> /usr/lib/rdkit/, outside of the standard linker library search path (and
> hardcode that location into the python shared objects at build-time via
> RPATH or similar). I just ship them in /usr/lib for now.
If there is a problem with the naming, I would definitely prefer the
/usr/lib/rdkit solution to renaming the files.
FYI: I will be on vacation from later today until the last week of
September, so replies from me will be either slow or non-existent
until then.
Best Regards,
-greg
|
|
From: Greg L. <gre...@gm...> - 2011-09-03 08:09:48
|
Dear all, I will be on vacation from tomorrow until the last week of September, so replies from me will be either slow or non-existent until then. Now is a great time for the community to support itself. :-) -greg |
|
From: Greg L. <gre...@gm...> - 2011-08-28 14:50:04
|
Richard, I'm moving this from the discuss list to the devel list since it's getting very implementation specific. I've got a modified version of your patch applied on a branch (https://rdkit.svn.sourceforge.net/svnroot/rdkit/branches/ReactionStereochem_23Aug2011) and it mostly works. The patch was a massive help. There are still some outstanding things that need to be completed before calling this "done". 1) You sent a python script with inputs and expected outputs. This ought to be converted into some unit tests. I'm going to at least get started on this today. 2) There's a remaining piece of unsatisfactory behavior that I haven't been able to come up with a reasonable solution for. It's demonstrated by the test case test19Issue2050085() in testReaction.cpp The reaction is one of the RECAP rules: "[N;!D1;+0](-!@[*:1])-!@[*:2]>>[*][*:1].[*:2][*]" And the test molecule is: "C1CC1N[C@H](C)F". One of the products of this reaction is *-[CH](C)F. In a perfect world this would be *-[C@H](C)F, but I couldn't come up with a way of reliably getting there. Probably this just needs to be documented. -greg |
|
From: Greg L. <gre...@gm...> - 2011-08-15 05:41:04
|
Riccardo,
On Sun, Aug 14, 2011 at 9:54 AM, Riccardo Vianello
<ric...@gm...> wrote:
>
> on Fedora 15 (gcc 4.6.0) testMolSupplier seems to hang forever inside
> testGetItemText(), this way blocking tests execution.
>
> I tracked the problem to line 1422
>
> try {
> molB=sdsup.getItemText(16); // <- here
> ok = false;
> } catch (FileParseException &) {
>
> Inside sdsup.getItemText(16), a call to SDMolSupplier::moveTo() never
> stops trying to read lines from the stream, and I think this is
> related to some changes in the behavior of the streams in gcc 4.6.0
> and the initial call to seekg() performed on a stream that was put
> into a not-good state (eof) by the earlier test case (mol1 =
> sdsup[15]; testMolSupplier.cpp:1414). I made a few tests and it seems
> that clearing the stream prior to calling seekg() produces the
> expected behaviour (mainly for clarity, I'm attaching a small patch).
Thanks for the patch. I made similar changes to SmilesMolSupplier and
TDTMolSupplier and checked them in this morning.
-greg
|
|
From: Riccardo V. <ric...@gm...> - 2011-08-14 07:55:01
|
Hi Greg,
on Fedora 15 (gcc 4.6.0) testMolSupplier seems to hang forever inside
testGetItemText(), this way blocking tests execution.
I tracked the problem to line 1422
try {
molB=sdsup.getItemText(16); // <- here
ok = false;
} catch (FileParseException &) {
Inside sdsup.getItemText(16), a call to SDMolSupplier::moveTo() never
stops trying to read lines from the stream, and I think this is
related to some changes in the behavior of the streams in gcc 4.6.0
and the initial call to seekg() performed on a stream that was put
into a not-good state (eof) by the earlier test case (mol1 =
sdsup[15]; testMolSupplier.cpp:1414). I made a few tests and it seems
that clearing the stream prior to calling seekg() produces the
expected behaviour (mainly for clarity, I'm attaching a small patch).
Regards,
Riccardo
|
|
From: Greg L. <gre...@gm...> - 2011-08-07 15:03:52
|
On Sun, Aug 7, 2011 at 4:33 PM, Riccardo Vianello <ric...@gm...> wrote: > Hi Greg, > > On Sun, Aug 7, 2011 at 11:40 AM, Greg Landrum <gre...@gm...> wrote: >> Hi Riccardo, >> >> I'm trying to get your patch working in a local install now. >> >> I tried an in-source build and have encountered a somewhat odd >> problem: "make install" fails. > > yes, it's actually quite strange.. to my understanding the additional > management of package configuration files wasn't supposed to affect > the existing build and installation process of the other targets. I > didn't observe anything like that in my tests, but I'm now repeating > the whole build and (in-tree) install process investigating this > behaviour in a more specific way. FWIW: make install works fine if i do my usual out-of-source build. -greg |
|
From: Riccardo V. <ric...@gm...> - 2011-08-07 14:33:27
|
Hi Greg, On Sun, Aug 7, 2011 at 11:40 AM, Greg Landrum <gre...@gm...> wrote: > Hi Riccardo, > > I'm trying to get your patch working in a local install now. > > I tried an in-source build and have encountered a somewhat odd > problem: "make install" fails. yes, it's actually quite strange.. to my understanding the additional management of package configuration files wasn't supposed to affect the existing build and installation process of the other targets. I didn't observe anything like that in my tests, but I'm now repeating the whole build and (in-tree) install process investigating this behaviour in a more specific way. Riccardo > > Here's the situation after doing "make": > > /scratch/RDKit_vianello > ls -l lib/*RDBoost* > lrwxrwxrwx 1 glandrum glandrum 15 2011-08-07 11:31 > lib/libRDBoost.so -> libRDBoost.so.1 > lrwxrwxrwx 1 glandrum glandrum 28 2011-08-07 11:31 > lib/libRDBoost.so.1 -> libRDBoost.so.1.2011.09.1pre > -rwxr-xr-x 1 glandrum glandrum 13342 2011-08-07 11:31 > lib/libRDBoost.so.1.2011.09.1pre > > Now I do a verbose "make instal"l: > > /scratch/RDKit_vianello > VERBOSE=1 make install > /usr/local/bin/cmake -H/scratch/RDKit_vianello > -B/scratch/RDKit_vianello --check-build-system > CMakeFiles/Makefile.cmake 0 > /usr/local/bin/cmake -E cmake_progress_start > /scratch/RDKit_vianello/CMakeFiles > /scratch/RDKit_vianello/CMakeFiles/progress.marks > make -f CMakeFiles/Makefile2 all > > <SNIP> > > make[1]: Leaving directory `/scratch/RDKit_vianello' > Install the project... > /usr/local/bin/cmake -P cmake_install.cmake > -- Install configuration: "Release" > -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-targets.cmake > -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-targets-release.cmake > -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-config.cmake > -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-config-version.cmake > -- Up-to-date: /scratch/RDKit_vianello/lib/libRDGeneral_static.a > CMake Error at Code/RDBoost/cmake_install.cmake:50 (FILE): > file INSTALL cannot find > "/scratch/RDKit_vianello/lib/libRDBoost.so.1.2011.09.1pre". > Call Stack (most recent call first): > Code/cmake_install.cmake:38 (INCLUDE) > cmake_install.cmake:70 (INCLUDE) > > And, if I look in lib the library has vanished: > > /scratch/RDKit_vianello > ls -l lib/*RDBoost* > lrwxrwxrwx 1 glandrum glandrum 15 2011-08-07 11:31 lib/libRDBoost.so > -> libRDBoost.so.1 > lrwxrwxrwx 1 glandrum glandrum 28 2011-08-07 11:31 lib/libRDBoost.so.1 > -> libRDBoost.so.1.2011.09.1pre > /scratch/RDKit_vianello > > > Any ideas what's wrong here? > > -greg > |
|
From: Greg L. <gre...@gm...> - 2011-08-07 09:40:55
|
Hi Riccardo, I'm trying to get your patch working in a local install now. I tried an in-source build and have encountered a somewhat odd problem: "make install" fails. Here's the situation after doing "make": /scratch/RDKit_vianello > ls -l lib/*RDBoost* lrwxrwxrwx 1 glandrum glandrum 15 2011-08-07 11:31 lib/libRDBoost.so -> libRDBoost.so.1 lrwxrwxrwx 1 glandrum glandrum 28 2011-08-07 11:31 lib/libRDBoost.so.1 -> libRDBoost.so.1.2011.09.1pre -rwxr-xr-x 1 glandrum glandrum 13342 2011-08-07 11:31 lib/libRDBoost.so.1.2011.09.1pre Now I do a verbose "make instal"l: /scratch/RDKit_vianello > VERBOSE=1 make install /usr/local/bin/cmake -H/scratch/RDKit_vianello -B/scratch/RDKit_vianello --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bin/cmake -E cmake_progress_start /scratch/RDKit_vianello/CMakeFiles /scratch/RDKit_vianello/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all <SNIP> make[1]: Leaving directory `/scratch/RDKit_vianello' Install the project... /usr/local/bin/cmake -P cmake_install.cmake -- Install configuration: "Release" -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-targets.cmake -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-targets-release.cmake -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-config.cmake -- Up-to-date: /scratch/RDKit_vianello/lib/rdkit-config-version.cmake -- Up-to-date: /scratch/RDKit_vianello/lib/libRDGeneral_static.a CMake Error at Code/RDBoost/cmake_install.cmake:50 (FILE): file INSTALL cannot find "/scratch/RDKit_vianello/lib/libRDBoost.so.1.2011.09.1pre". Call Stack (most recent call first): Code/cmake_install.cmake:38 (INCLUDE) cmake_install.cmake:70 (INCLUDE) And, if I look in lib the library has vanished: /scratch/RDKit_vianello > ls -l lib/*RDBoost* lrwxrwxrwx 1 glandrum glandrum 15 2011-08-07 11:31 lib/libRDBoost.so -> libRDBoost.so.1 lrwxrwxrwx 1 glandrum glandrum 28 2011-08-07 11:31 lib/libRDBoost.so.1 -> libRDBoost.so.1.2011.09.1pre /scratch/RDKit_vianello > Any ideas what's wrong here? -greg |
|
From: Greg L. <gre...@gm...> - 2011-08-04 09:49:32
|
Riccardo,
Thanks for doing this! This is a piece that has been missing for a
while and it's nice to see someone taking a crack at it. I will take a
look at the patch over the next couple of days, ask whatever questions
I have, and then integrate it.
-greg
On Thu, Aug 4, 2011 at 12:15 AM, Riccardo Vianello
<ric...@gm...> wrote:
> Hello all,
>
> I made a few changes to the cmake list files of a local snapshot
> (r1814), working on introducing support for package configuration
> files. As recently mentioned on the mailing lists, building 3rd party
> C++ projects that use rdkit would be easier if cmake's 'find_package'
> command were able to locate the rdkit headers and libraries. For a
> generic XYZ software package, find_package most often relies on the
> availability of an independently provided FindXYZ.cmake module, but
> when a project is already built with cmake, as is the case for rdkit,
> the build process can be instructed to export analogous information
> into configuration files to be installed into a standard location
> (e.g. together with the library code).
>
> I'm attaching two rdkit-config*.cmake.in templates that should be
> placed into the rdkit top directory, and a small patch file. The patch
> mostly consists in additions directly related to the managements of
> the config files, but for one modification, that "promotes" the hc
> target (in Code/ML/Cluster/Murtagh/) from a build-time intermediate to
> an installed and exported build target (this was due to the target
> export process raising a blocking error due to SimDivPickers depending
> on hc which wasn't in turn exported.. I'm not yet sure if this is
> highlighting an issue in the rdkit build or a bug in cmake which is
> confused by the intermediate static library). The rest of the code is
> from a cmake documented example, with some very small adjustments.
>
> With these changes a few rdkit-*.cmake files are installed into the
> library directory and, for example,
> Code/Demos/RDKit/GettingStarted/sample.cpp should build with a list
> file similar to the following:
>
> # --8<--
> cmake_minimum_required (VERSION 2.6)
> project (Sample)
>
> find_package (RDKit 1.2011.09 REQUIRED)
>
> include_directories (${RDKit_INCLUDE_DIRS})
>
> add_executable (sample sample.cpp)
> target_link_libraries (sample ChemReactions
> # FileParsers SmilesParse Depictor etc...
> # all other dependencies already known to CMake
> # since the RDKit build process.
> )
> # --8<--
>
> I tested this on my Linux box, with the in-tree and $HOME installs, in
> both cases the config files location was provided on the command line
> as in
>
> $ cmake ../sample/ -DRDKit_DIR=/full/path/to/rdkit/installation/lib
>
> For the most part (the hc target above being the exception) these
> additions should not interfere with the existing build process, so
> they could be worth some quick testing on windows and/or mac (target
> export directives in RDKitUtils.cmake should be already present for
> the various platforms, but only linux/g++ was tested).
>
> Best Regards,
> Riccardo
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>
|
|
From: Riccardo V. <ric...@gm...> - 2011-08-03 22:16:07
|
Hello all,
I made a few changes to the cmake list files of a local snapshot
(r1814), working on introducing support for package configuration
files. As recently mentioned on the mailing lists, building 3rd party
C++ projects that use rdkit would be easier if cmake's 'find_package'
command were able to locate the rdkit headers and libraries. For a
generic XYZ software package, find_package most often relies on the
availability of an independently provided FindXYZ.cmake module, but
when a project is already built with cmake, as is the case for rdkit,
the build process can be instructed to export analogous information
into configuration files to be installed into a standard location
(e.g. together with the library code).
I'm attaching two rdkit-config*.cmake.in templates that should be
placed into the rdkit top directory, and a small patch file. The patch
mostly consists in additions directly related to the managements of
the config files, but for one modification, that "promotes" the hc
target (in Code/ML/Cluster/Murtagh/) from a build-time intermediate to
an installed and exported build target (this was due to the target
export process raising a blocking error due to SimDivPickers depending
on hc which wasn't in turn exported.. I'm not yet sure if this is
highlighting an issue in the rdkit build or a bug in cmake which is
confused by the intermediate static library). The rest of the code is
from a cmake documented example, with some very small adjustments.
With these changes a few rdkit-*.cmake files are installed into the
library directory and, for example,
Code/Demos/RDKit/GettingStarted/sample.cpp should build with a list
file similar to the following:
# --8<--
cmake_minimum_required (VERSION 2.6)
project (Sample)
find_package (RDKit 1.2011.09 REQUIRED)
include_directories (${RDKit_INCLUDE_DIRS})
add_executable (sample sample.cpp)
target_link_libraries (sample ChemReactions
# FileParsers SmilesParse Depictor etc...
# all other dependencies already known to CMake
# since the RDKit build process.
)
# --8<--
I tested this on my Linux box, with the in-tree and $HOME installs, in
both cases the config files location was provided on the command line
as in
$ cmake ../sample/ -DRDKit_DIR=/full/path/to/rdkit/installation/lib
For the most part (the hc target above being the exception) these
additions should not interfere with the existing build process, so
they could be worth some quick testing on windows and/or mac (target
export directives in RDKitUtils.cmake should be already present for
the various platforms, but only linux/g++ was tested).
Best Regards,
Riccardo
|
|
From: Gianluca S. <gi...@gm...> - 2011-07-11 22:42:15
|
On Mon, Jul 11, 2011 at 6:19 AM, Greg Landrum <gre...@gm...> wrote: > > Thanks for taking a look despite being on vacation. Once this release > is wrapped up, I will work on setting up the cmake files so that the > static build can be easily disabled so that you don't have to deal > with the patches. Yeah, that would be very useful indeed. In the meanwhile, I updated the patch and verified the build completes correctly, also passing all the tests. This is for Fedora 14 x86_64, will try the same for F15, rawhide (aka F16) and possibly RHEL 6; had no time to continue the work for porting code to 5.6, sorry :( Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
|
From: Greg L. <gre...@gm...> - 2011-07-11 04:43:59
|
Dear all, I'm very happy to announce that the next version of the RDKit -- 2011.06 (a.k.a Q2 2011) -- is released. The release notes are below. The source release is on the sourceforge downloads page: http://sourceforge.net/projects/rdkit/files/rdkit/Q2_2011/ The files can also be downloaded from the google project page: http://code.google.com/p/rdkit/downloads/list The binaries for Windows and Python 2.7 are uploaded already, I will do the Python 2.6 binaries in the next couple of days. Thanks to the everyone who submitted bug reports and suggestions for this release! Please let me know if you find any problems with the release or have suggestions for the next one. -greg ****** Release_2011.06.1 ******* (Changes relative to Release_2011.03.2) Acknowledgements: - Eddie Cao, Andrew Dalke, James Davidson, JP Ebejer, Gianluca Sforna, Riccardo Vianello, Bernd Wiswedel Bug Fixes: - A problem with similarity values between SparseIntVects that contain negative values was fixed. (Issue 3295215) - An edge case in SmilesMolSupplier.GetItemText() was fixed. (Issue 3299878) - The drawing code now uses dashed lines for aromatic bonds without kekulization. (Issue 3304375) - AllChem.ConstrainedEmbed works again. (Issue 3305420) - atomic RGP values from mol files are accessible from python (Issue 3313539) - M RGP blocks are now written to mol files. (Issue 3313540) - Atom.GetSymbol() for R atoms read from mol files is now correct. (Issue 3316600) - The handling of isotope specifications is more robust. - A thread-safety problem in SmilesWrite::GetAtomSmiles() was fixed. - some of the MACCS keys definitions have been corrected - Atoms with radical counts > 2 are no longer always written to CTABs with a RAD value of 3. (Issue 3359739) New Features: - The smiles, smarts, and reaction smarts parsers all now take an additional argument, "replacements", that carries out string substitutions pre-parsing. - There is now optional support for generating InChI codes and keys for molecules. - the atom pair and topological torsion fingerprint generators now take an optional "ignoreAtoms" argument - a function to calculate exact molecular weight was added. - new java wrappers are now available in $RDBASE/Code/JavaWrappers - the methods getMostCommonIsotope() and getMostCommonIsotopeMass() have been added to the PeriodicTable class. New Database Cartridge Features: - Support for generating InChIs and InChI keys (if the RDKit InChI support is enabled). Deprecated modules (to be removed in next release): - The original SWIG wrappers in $RDBASE/Code/Demos/SWIG are deprecated Removed modules: Other: - The quality of the drawings produced by both the python molecule drawing code and $RDBASE/Code/Demos/RDKit/Draw is better. - the python molecule drawing code will now use superscripts and subscripts appropriately when using the aggdraw or cairo canvases (cairo canvas requires pango for this to work). - $RDBASE/Code/Demos/RDKit/Draw now includes an example using cairo - A lot of compiler warnings were cleaned up. - The error reporting in the SMILES, SMARTS, and SLN parsers was improved. - the code for calculating molecular formula is now in C++ (Descriptors::calcMolFormula()) |
|
From: Greg L. <gre...@gm...> - 2011-07-11 04:20:04
|
Hi Gianluca, On Mon, Jul 11, 2011 at 12:55 AM, Gianluca Sforna <gi...@gm...> wrote: > On Sat, Jul 9, 2011 at 12:23 PM, Greg Landrum <gre...@gm...> wrote: >> >> I'd really like to get this release finished soon. Gianluca: can you >> please take a look and see if what's there now works for the >> packaging? > > Sorry for the late reply, I'm in vacation with the family and can > hardly use the PC :) That's a pretty good reason. :-) > I tried to update from SVN and rebuild the RPM but now I fail because > I need to update one patch (I still carry a couple of the to disable > completely the static build and linking) so I could not finish it. > I'll need to work on that a bit more before reporting results, however > the approach seems sane so I guess you can go on and release if you > wish Thanks for taking a look despite being on vacation. Once this release is wrapped up, I will work on setting up the cmake files so that the static build can be easily disabled so that you don't have to deal with the patches. -greg |
|
From: Gianluca S. <gi...@gm...> - 2011-07-10 22:55:45
|
On Sat, Jul 9, 2011 at 12:23 PM, Greg Landrum <gre...@gm...> wrote: > > I'd really like to get this release finished soon. Gianluca: can you > please take a look and see if what's there now works for the > packaging? Sorry for the late reply, I'm in vacation with the family and can hardly use the PC :) I tried to update from SVN and rebuild the RPM but now I fail because I need to update one patch (I still carry a couple of the to disable completely the static build and linking) so I could not finish it. I'll need to work on that a bit more before reporting results, however the approach seems sane so I guess you can go on and release if you wish Thanks again G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
|
From: Greg L. <gre...@gm...> - 2011-07-09 10:24:00
|
I think we're about there now. The current svn version has a new configuration flag (RDK_BUILD_INCHI_SUPPORT) that toggles inclusion of the inchi wrappers. It defaults to OFF. If this is set: - if $RDBASE/External/INCHI-API/src contains the inchi code, the local copy will be used. - otherwise if a system version is found (using a copy of the openbabel findinchi.cmake file), that will be used. - otherwise a warning will be issued and the use_inchi flag will be switched off. In any case the appropriate version of the file inchi.py will be created in the rdkit/Chem directory at build time. This ought to all work for in-source and out-of-source builds and seems to also work with make install I'd really like to get this release finished soon. Gianluca: can you please take a look and see if what's there now works for the packaging? Thanks, -greg |
|
From: Greg L. <gre...@gm...> - 2011-07-08 10:00:14
|
On Fri, Jul 8, 2011 at 11:01 AM, Gianluca Sforna <gi...@gm...> wrote: >>> >>> Now I see. The problem is that I'd need some help from your side to >>> also support some alternate standards, otherwise building proper >>> packages for end users is increasingly painful. >> >> Sorry that we created the problem, we will get it fixed. The packaging >> work that you're doing is really valuable and I certainly don't want >> to make it either more difficult or complex. I will start to make a >> habit of doing an out-of-source build to make sure things like this >> are less likely to happen again. > > Thanks Greg, I really appreciate this. > To help you avoid adding burden to development, I was thinking about I have a script that does the "checkout, build, test" process already. I just need to create a copy that does the build in-source... shouldn't be that bad. > starting a buildbot instance somewhere so compilation and tests could > be run regularly with both methods. Did you ever consider such a > setup? I do nightlies of the Novartis-internal version at work, but I haven't really looked for anywhere to do the equivalent with the open-source build. It would be nice to have. >> It would be great if you could do that; otherwise Eddie and I will get >> something put together today. > > I'm having a look at it right now I integrated Riccardo's patch and can verify that, with those two changes made, an in-source build passes the python tests without first having to do a "make install". -greg |
|
From: Gianluca S. <gi...@gm...> - 2011-07-08 09:02:12
|
On Fri, Jul 8, 2011 at 5:21 AM, Greg Landrum <gre...@gm...> wrote: > Hi Gianluca, > > On Fri, Jul 8, 2011 at 12:14 AM, Gianluca Sforna <gi...@gm...> wrote: >> On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote: >>> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote: >>>> I just tried to build the beta into RPM packages; I've read that inchi >>>> support is optional, so I guess there is a new cmake switch to trigger >>>> it. However, all py* tests are now failing because "from inchi import >>>> *" gives an ImportError. >>> >>> That's defniitely not what's supposed to happen (and isn't what >>> happens for me when doing the standard in-tree install). >> >> Now I see. The problem is that I'd need some help from your side to >> also support some alternate standards, otherwise building proper >> packages for end users is increasingly painful. > > Sorry that we created the problem, we will get it fixed. The packaging > work that you're doing is really valuable and I certainly don't want > to make it either more difficult or complex. I will start to make a > habit of doing an out-of-source build to make sure things like this > are less likely to happen again. Thanks Greg, I really appreciate this. To help you avoid adding burden to development, I was thinking about starting a buildbot instance somewhere so compilation and tests could be run regularly with both methods. Did you ever consider such a setup? > > It would be great if you could do that; otherwise Eddie and I will get > something put together today. I'm having a look at it right now -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
|
From: Greg L. <gre...@gm...> - 2011-07-08 03:21:37
|
Hi Gianluca, On Fri, Jul 8, 2011 at 12:14 AM, Gianluca Sforna <gi...@gm...> wrote: > On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote: >> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote: >>> I just tried to build the beta into RPM packages; I've read that inchi >>> support is optional, so I guess there is a new cmake switch to trigger >>> it. However, all py* tests are now failing because "from inchi import >>> *" gives an ImportError. >> >> That's defniitely not what's supposed to happen (and isn't what >> happens for me when doing the standard in-tree install). > > Now I see. The problem is that I'd need some help from your side to > also support some alternate standards, otherwise building proper > packages for end users is increasingly painful. Sorry that we created the problem, we will get it fixed. The packaging work that you're doing is really valuable and I certainly don't want to make it either more difficult or complex. I will start to make a habit of doing an out-of-source build to make sure things like this are less likely to happen again. >>> Probably I'm missing something obvious here, but given that import >>> line is in rdkit/Chem/__init__.py that means python bindings are >>> basically unusable right now unless you also activate Inchi support. >> >> If you don't do the inchi installation cmake should create a file >> $RDBASE/rdkit/Chem/inchi.py that is basically empty. > > So, examined this part a bit more and unfortunately, the feature as is > makes packaging harder: the main issue is that we will need to use the > system's provided inchi library but right now the build lacks any > support for that. In practice, I think I'd suggest: > > 1. add an option to build or not inchi support > 2. add an option to use system's provided inchi > 3. ensure tests works also before the in-tree install > 4. skip inchi feature tests if disabled I agree with all of these. > For reference, I found OpenBabel is doing something very similar: > https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/CMakeLists.txt > https://openbabel.svn.sourceforge.net/svnroot/openbabel/openbabel/trunk/cmake/modules/FindInchi.cmake > > Of course, if you are ok with the plan, I am willing to provide > patches for the above. It would be great if you could do that; otherwise Eddie and I will get something put together today. Best, -greg |
|
From: Eddie C. <cao...@gm...> - 2011-07-07 22:48:26
|
Hi Riccardo,
Thanks for the analysis. I think you are right about the cause of the problem. When writing the CMake listfile, I never thought about the second workflow, and I assumed tests were always done after installation. The implication is that the source is essentially in incomplete state and missing a proper inchi.py until `make install` is run.
I think your patch - without the typo at the end - should solve the problem. I will patch the source later in case other concerns are raised.
Thanks,
Eddie
On Jul 7, 2011, at 3:01 PM, Riccardo Vianello wrote:
> On Thu, Jul 7, 2011 at 3:35 PM, Greg Landrum <gre...@gm...> wrote:
>> Moving just to the -developers list.
>>
>> On Thu, Jul 7, 2011 at 9:53 AM, Gianluca Sforna <gi...@gm...> wrote:
>>> On Fri, Jul 1, 2011 at 1:40 PM, Greg Landrum <gre...@gm...> wrote:
>>>
>>>> One highlight I will call your attention to is that, thanks to some
>>>> nice work from Eddie Cao, it is now possible to generate InChI codes
>>>> from within the RDKit :
>>>
>>> I just tried to build the beta into RPM packages; I've read that inchi
>>> support is optional, so I guess there is a new cmake switch to trigger
>>> it. However, all py* tests are now failing because "from inchi import
>>> *" gives an ImportError.
>>
>> That's defniitely not what's supposed to happen (and isn't what
>> happens for me when doing the standard in-tree install).
>>
>
> I gave a look to the CMake listfile that manages the InChI code and
> I'm investigating a possible reason for this unexpected behavior. As
> far as I can remember, two different build workflows allowed tests
> execution. One is "build outside the source dir, install in-tree,
> test", more supported and documented, useful when developing, but not
> very convenient when packaging; the other is "build in-tree, test,
> install into a tree that mimics the system locations". It is not very
> useful during the development, but produces the tested libraries
> organized in a way which is more convenient when packaging.
>
> In particular, since the testing code was designed for an in-tree
> installation, this second workflow relies on cmake producing the
> output from the build in locations under ${CMAKE_BUILD_DIR} that match
> those same locations that installing in-tree determines under
> ${CMAKE_SOURCE_DIR}. This way, when building in-tree,
> ${CMAKE_BUILD_DIR} and ${CMAKE_SOURCE_DIR} are the same and the files
> resulting from the build are placed where the test code expects them.
>
> I'm sorry if I was confusing, but here's the shorter version. If I
> understood it correctly, the selected inchi.py is copied into
> ${CMAKE_CURRENT_BINARY_DIR} at build time and placed into rdkit/Chem
> only when installing. Since the second workflow above runs tests prior
> to the installation step the tests fail because inchi.py is not yet
> available inside the python tree. Copying to
> ${CMAKE_BINARY_DIR}/rdkit/Chem/inchi.py should work in both cases. I
> tested this with the second workflow on a fresh snapshot and tests
> pass (at least up to 57/76 testMolSupplier, which seems to hang
> forever, I didn't experience this on earlier linux installations, but
> I know this test is also problematic for MinGW, so I think this
> problem is probably unrelated). For clarity, I'm attaching the small
> patch I used (in-tree and with inchi support branches are untested).
>
> Hope that helps,
>
> Best regards,
> Riccardo
>
>
>>> Probably I'm missing something obvious here, but given that import
>>> line is in rdkit/Chem/__init__.py that means python bindings are
>>> basically unusable right now unless you also activate Inchi support.
>>
>> If you don't do the inchi installation cmake should create a file
>> $RDBASE/rdkit/Chem/inchi.py that is basically empty.
>>
>> -greg
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Rdkit-devel mailing list
>> Rdk...@li...
>> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>>
> <inchi_test.diff>------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
|
4 messages has been excluded from this view by a project administrator.
