rdkit-devel — Developers information and discussion.

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

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.

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

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.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

[Riccardo V. <ric...@gm...>]

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
>

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

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

> 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

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

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

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.

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.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] Beta of Q2 2011 Release Available

[Robert D. <rkd...@gm...>]

It works here on CentOS 5.6.  Testing with my code goes fine, but the test
step (ctest from the build directory) results in 72/76 tests failed.
Problem with the test DB?





On Fri, Jul 1, 2011 at 5:40 AM, Greg Landrum <gre...@gm...> wrote:

> Dear all,
>
> This morning I tagged the beta for the Q2 2011 (2011.06 in the new
> numbering) release in svn:
> http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2011_06_1beta1/
>
> and uploaded a source distribution to the google code site:
>
> http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2011_06_1beta1.tgz
> If there's demand for it, I will also put up a windows binary.
>
> As usual: if no show-stopper bugs appear, I will do the release itself
> in about a week.
>
> Excerpts from the release notes are below.
>
> 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 :
>
> In [2]: inchi = Chem.MolToInchi(Chem.MolFromSmiles('c1ccccc1C(=O)O'))
> In [3]: print inchi
> InChI=1S/C7H6O2/c8-7(9)6-4-2-1-3-5-6/h1-5H,(H,8,9)
>
> and then convert the InChIs to InChI keys:
>
> In [4]: print Chem.InchiToInchiKey(inchi)
> WPYMKLBDIGXBTP-UHFFFAOYSA-N
>
> There is also experimental and partial support for converting InChI
> back into a molecule:
>
> In [5]: m2 = Chem.MolFromInchi(inchi)
> In [6]: print Chem.MolToSmiles(m2)
> O=C(O)c1ccccc1
>
> Note that this last bit is not something InChI is actually designed
> for, so it's probably not a good idea to rely on it.
>
>
>
> Best Regards,
> -greg
>
>
> ******  Release_2011.06.1 *******
> (Changes relative to Release_2011.03.2)
>
> Acknowledgements:
>  - Eddie Cao, Andrew Dalke, James Davidson, JP Ebejer, 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 3305420)
>  - 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
>
> 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:
>
> 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())
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [Rdkit-devel] PostgreSQL cartridge bfp in Python

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

Adrian,

On Mon, Jul 4, 2011 at 12:30 PM, Adrian Schreyer <am...@ca...> wrote:
>
> is it actually possible to reconstruct a binary fingerprint stored in
> the database back to a Python object?

Not at the moment, but it should be easy to add. I'll get it in in the
next couple of days.

-greg

[Rdkit-devel] PostgreSQL cartridge bfp in Python

[Adrian S. <am...@ca...>]

Hi Greg,

is it actually possible to reconstruct a binary fingerprint stored in
the database back to a Python object?

Cheers,

Adrian

[Rdkit-devel] Beta of Q2 2011 Release Available

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

Dear all,

This morning I tagged the beta for the Q2 2011 (2011.06 in the new
numbering) release in svn:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2011_06_1beta1/

and uploaded a source distribution to the google code site:
http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2011_06_1beta1.tgz
If there's demand for it, I will also put up a windows binary.

As usual: if no show-stopper bugs appear, I will do the release itself
in about a week.

Excerpts from the release notes are below.

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 :

In [2]: inchi = Chem.MolToInchi(Chem.MolFromSmiles('c1ccccc1C(=O)O'))
In [3]: print inchi
InChI=1S/C7H6O2/c8-7(9)6-4-2-1-3-5-6/h1-5H,(H,8,9)

and then convert the InChIs to InChI keys:

In [4]: print Chem.InchiToInchiKey(inchi)
WPYMKLBDIGXBTP-UHFFFAOYSA-N

There is also experimental and partial support for converting InChI
back into a molecule:

In [5]: m2 = Chem.MolFromInchi(inchi)
In [6]: print Chem.MolToSmiles(m2)
O=C(O)c1ccccc1

Note that this last bit is not something InChI is actually designed
for, so it's probably not a good idea to rely on it.



Best Regards,
-greg


******  Release_2011.06.1 *******
(Changes relative to Release_2011.03.2)

Acknowledgements:
 - Eddie Cao, Andrew Dalke, James Davidson, JP Ebejer, 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 3305420)
 - 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

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:

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())

[Rdkit-devel] A new RDKit developer + InChI support

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

Dear all,

Two things I'm really happy to announce:

1) A new developer on the open-source RDKit project: Eddie Cao. Eddie
has done some great stuff with the RDKit at work, so it's very cool to
have him contributing to the open-source project as well.

2) The addition of InChI support to the RDKit. This is another
open-source contribution from Novartis. It is one of Eddie's projects.

The RDKit InChI support is currently in a branch:
https://rdkit.svn.sourceforge.net/svnroot/rdkit/branches/InChI_13June2011
It requires the InChI source code to be available. Instructions are here:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/branches/InChI_13June2011/External/INCHI-API/README?revision=1748

Once you have the code installed, you can convert molecules to InChI:

In [2]: inchi = Chem.MolToInchi(Chem.MolFromSmiles('c1ccccc1C(=O)O'))
In [3]: print inchi
InChI=1S/C7H6O2/c8-7(9)6-4-2-1-3-5-6/h1-5H,(H,8,9)

and then convert the InChIs to InChI keys:

In [4]: print Chem.InchiToInchiKey(inchi)
WPYMKLBDIGXBTP-UHFFFAOYSA-N

There is also experimental and partial support for converting InChI
back into a molecule:

In [5]: m2 = Chem.MolFromInchi(inchi)
In [6]: print Chem.MolToSmiles(m2)
O=C(O)c1ccccc1

Note that this last bit is not something InChI is actually designed
for, so it's probably not a good idea to rely on it.

We'll merge the changes from the branch back onto the trunk early next
week. In the meantime, any feedback/suggestions/comments is welcome.

Best,
-greg

Re: [Rdkit-devel] RDKit changes for RHEL/CentOS 5 packaging

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

Thanks Greg for the comments, I was carried away for a while, but now
I'll need to update my production servers and I'll work a bit more on
this.

On Thu, May 19, 2011 at 5:29 AM, Greg Landrum <gre...@gm...> wrote:
> I guess I don't really understand how the RHEL guys decide when to
> update a package. Neither bison nor boost are particularly exotic
> pieces of software and both are quite widely used, yet the versions of
> each that are available with these systems is really out of date.

Didn't check bison, but the general idea is that you stick with a base
version for the lifetime of the product and only fix stuff that's
broken; that's the only way to have something that builds and works at
the original release continue working after upgrades.

For instance, if you built and deployed a PHP web application with a
CentOS 5 server you had PHP 5.1.6. You don't want your application to
break because the (incompatible) PHP 5.3 package landed in the
repositories. Yes, that's unfortunate if you want to deploy a new
application requiring PHP 5.3, so they needed to introduce a php53
package in CentOS 5.6 (I guess, due to popular demand).

Flex is in a similar situation: it seems the versions after 2.5.4 were
not 100% compatible, so they could not upgrade. I bet the same is true
for boost.

In short, RHEL is for mission critical infrastructure. That's probably
the reason why more desktop oriented users find it a weird platform to
work on.

>
>> It turned out the
>> only feature used from the newer boost is the BOOST_FOREACH construct
>> (there were about 30 in the whole code base), so I just had to
>> routinely replace it with a regular for loop on the proper iterators.
>
> Lovely. I've been doing the opposite (replacing standard for loops
> with BOOST_FOREACH) whenever I'm working in a file and remember to do
> so. It makes for somewhat cleaner code.

:-)

>
> - There was a change in the boost random number generator in version
> 1.40. This means that fingerprints generated with v1.40 and beyond are
> not compatible with earlier versions. This is likely to lead to
> confusion

Ok, I'd need more info about this. Are you aware if the change was due
to a bug or some other reason? Do you know if we can we do something
on our side to make the behavior consistent?

By the way, I noted 1.39 is required in CMakeList.txt, which is the
first release that supported BOOST_FOREACH


>
> - RHEL is still shipping with only python2.4 available, right? This is
> probably also going to be a problem.

Right, I have python 2.4 there; any specifics about what you expect
breaking with it? Right now the only failing tests I have (more on
this later) look like related to the aforementioned random number
generator changes.
If really needed I can make the package require python26, which is
available in EPEL.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] RDKit changes for RHEL/CentOS 5 packaging

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

Dear Gianluca,

On Wed, May 18, 2011 at 11:34 AM, Gianluca Sforna <gi...@gm...> wrote:
> Since some time, I'm toying with the idea of trying to determine if
> and how it is possible to build RDKit against system provided
> libraries in a CentOS 5 system; this is a requirement for eventual
> inclusion in an official repository.

It would certainly be nice to have those packages available, but I
suspect this restriction (which I understand) is going to end up being
a problem (more below).

> Until version 5.6 this was not really possible mainly due to a gcc
> bug, which is now fixed. Additionally, Flex is still an issue because
> only version 2.5.4a is available for use (but I'm working on this).
>
> The last issue is boost, as we have 1.33 in the repositories, so I
> tried to lower the requirement to see what breaks.

I guess I don't really understand how the RHEL guys decide when to
update a package. Neither bison nor boost are particularly exotic
pieces of software and both are quite widely used, yet the versions of
each that are available with these systems is really out of date.

> It turned out the
> only feature used from the newer boost is the BOOST_FOREACH construct
> (there were about 30 in the whole code base), so I just had to
> routinely replace it with a regular for loop on the proper iterators.

Lovely. I've been doing the opposite (replacing standard for loops
with BOOST_FOREACH) whenever I'm working in a file and remember to do
so. It makes for somewhat cleaner code.

> So, before proceeding further (I have few tests failures to diagnose)
> I'd like to hear opinions about this work: surely, I can just add a
> patch on the RPM side but it would be nice to avoid the need to keep
> maintaining it and eventually rebase it on new releases.

I like the BOOST_FOREACH usage, but if that were the only sticking
point I'd be more than willing to give it up in the name of having
packages available for RHEL. However, it's not the only sticking
point.

- There was a change in the boost random number generator in version
1.40. This means that fingerprints generated with v1.40 and beyond are
not compatible with earlier versions. This is likely to lead to
confusion

- RHEL is still shipping with only python2.4 available, right? This is
probably also going to be a problem.

-greg

[Rdkit-devel] RDKit changes for RHEL/CentOS 5 packaging

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

Since some time, I'm toying with the idea of trying to determine if
and how it is possible to build RDKit against system provided
libraries in a CentOS 5 system; this is a requirement for eventual
inclusion in an official repository.

Until version 5.6 this was not really possible mainly due to a gcc
bug, which is now fixed. Additionally, Flex is still an issue because
only version 2.5.4a is available for use (but I'm working on this).

The last issue is boost, as we have 1.33 in the repositories, so I
tried to lower the requirement to see what breaks. It turned out the
only feature used from the newer boost is the BOOST_FOREACH construct
(there were about 30 in the whole code base), so I just had to
routinely replace it with a regular for loop on the proper iterators.

So, before proceeding further (I have few tests failures to diagnose)
I'd like to hear opinions about this work: surely, I can just add a
patch on the RPM side but it would be nice to avoid the need to keep
maintaining it and eventually rebase it on new releases.

Cheers

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] boost checks skipped

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

On Wed, May 18, 2011 at 6:19 AM, Greg Landrum <gre...@gm...> wrote:
> This is what I'd expect.

Yeah, me too :)

>
> I'm using cmake v2.8.4 (installed from source); which version are you using?
>

version 2.6.4, from the EPEL repository (more on this in another mail)

I'll see if there is something in the documentation about this
difference in behavior, maybe it can be easily fixed without affecting
2.8.4

Thanks a lot

G.


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] boost checks skipped

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

Hi Gianluca,

On Tue, May 17, 2011 at 4:26 PM, Gianluca Sforna <gi...@gm...> wrote:
> I just noticed the boost version check (but this is probably true for
> other ones) looks like being done only once; basically, the first time
> you run "cmake" with a older boost version available you get the error
> message. Running again cmake proceeds without any warning (see below).
>
> Is this the expected behavior?

Not at all. I would expect it to always fail.

> [giallu@g-centos5-i386 build2]$ cmake ..
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
  ...
> -- Found PythonInterp: /usr/bin/python2.4
> CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:868 (message):
>  Unable to find the requested Boost libraries.
>
>  Boost version: 1.33.1
>
>  Boost include path: /usr/include
>
>  Detected version of Boost is too old.  Requested version was 1.39 (or
>  newer).
> Call Stack (most recent call first):
>  CMakeLists.txt:69 (find_package)
>
>
> -- Found BISON: /usr/bin/bison
> -- Found FLEX: /usr/bin/flex
> CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:868 (message):
>  Unable to find the requested Boost libraries.
>
>  Boost version: 1.33.1
>
>  Boost include path: /usr/include
>
>  Detected version of Boost is too old.  Requested version was 1.39 (or
>  newer).
> Call Stack (most recent call first):
>  Code/GraphMol/SLNParse/CMakeLists.txt:4 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> [giallu@g-centos5-i386 build2]$ cmake ..
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/giallu/RDKit_2011_03_2/build2
>

Here's what happens to me on a bare-bones centos VM:

[root@localhost build]# cmake -D RDK_BUILD_PYTHON_WRAPPERS=OFF ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
   ...
CMake Error at /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:1128
(message):
  Unable to find the requested Boost libraries.

  Boost version: 1.33.1

  Boost include path: /usr/include

  Detected version of Boost is too old.  Requested version was 1.39 (or
  newer).
Call Stack (most recent call first):
  CMakeLists.txt:97 (find_package)


-- Found BISON: /usr/bin/bison
-- Found FLEX: /usr/bin/flex
CMake Error at /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:1128
(message):
  Unable to find the requested Boost libraries.

  Boost version: 1.33.1

  Boost include path: /usr/include

  Detected version of Boost is too old.  Requested version was 1.39 (or
  newer).

  The following Boost libraries could not be found:

          boost_regex

  No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to the
  directory containing Boost libraries or BOOST_ROOT to the location of
  Boost.
Call Stack (most recent call first):
  Code/GraphMol/SLNParse/CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!



And the second attempt:

[root@localhost build]# cmake ..
CMake Error at /usr/local/share/cmake-2.8/Modules/FindBoost.cmake:1128
(message):
  Unable to find the requested Boost libraries.

  Boost version: 1.33.1

  Boost include path: /usr/include

  Detected version of Boost is too old.  Requested version was 1.39 (or
  newer).

  The following Boost libraries could not be found:

          boost_regex

  No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to the
  directory containing Boost libraries or BOOST_ROOT to the location of
  Boost.
Call Stack (most recent call first):
  Code/GraphMol/SLNParse/CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
[root@localhost build]#


This is what I'd expect.

I'm using cmake v2.8.4 (installed from source); which version are you using?

-greg

[Rdkit-devel] boost checks skipped

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

I just noticed the boost version check (but this is probably true for
other ones) looks like being done only once; basically, the first time
you run "cmake" with a older boost version available you get the error
message. Running again cmake proceeds without any warning (see below).

Is this the expected behavior?

[giallu@g-centos5-i386 build2]$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonLibs: /usr/lib/python2.4/config/libpython2.4.a
-- Found PythonInterp: /usr/bin/python2.4
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:868 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.33.1

  Boost include path: /usr/include

  Detected version of Boost is too old.  Requested version was 1.39 (or
  newer).
Call Stack (most recent call first):
  CMakeLists.txt:69 (find_package)


-- Found BISON: /usr/bin/bison
-- Found FLEX: /usr/bin/flex
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:868 (message):
  Unable to find the requested Boost libraries.

  Boost version: 1.33.1

  Boost include path: /usr/include

  Detected version of Boost is too old.  Requested version was 1.39 (or
  newer).
Call Stack (most recent call first):
  Code/GraphMol/SLNParse/CMakeLists.txt:4 (find_package)


-- Configuring incomplete, errors occurred!
[giallu@g-centos5-i386 build2]$ cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to: /home/giallu/RDKit_2011_03_2/build2


-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu

Re: [Rdkit-devel] RDKit cartridge & PostgreSQL 9.1 Beta

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

Adrian,

On Thu, May 12, 2011 at 5:04 PM, Adrian Schreyer <am...@ca...> wrote:
>
> After porting my extensions to the new PostgreSQL extension system, I
> tried to do the same with the RDKit cartridge. Changing the Makefile
> and adding a .control file was pretty easy but apparently some of the
> internal PostgreSQL functions related to GUC have changed:
>
> guc.c: In function ‘initRDKitGUC’:
> guc.c:84:28: warning: passing argument 10 of
> ‘DefineCustomRealVariable’ from incompatible pointer type
> /usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: expected
> ‘GucRealCheckHook’ but argument is of type ‘bool (*)(double,  bool,
> enum GucSource)’
> guc.c:84:28: error: too few arguments to function ‘DefineCustomRealVariable’
> /usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: declared here
> guc.c:98:28: warning: passing argument 10 of
> ‘DefineCustomRealVariable’ from incompatible pointer type
> /usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: expected
> ‘GucRealCheckHook’ but argument is of type ‘bool (*)(double,  bool,
> enum GucSource)’
> guc.c:98:28: error: too few arguments to function ‘DefineCustomRealVariable’
> /usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: declared here
> make: *** [guc.o] Error 1
>

Thanks for the heads up. I'll take a look at it.

-greg

[Rdkit-devel] RDKit cartridge & PostgreSQL 9.1 Beta

[Adrian S. <am...@ca...>]

Hi Greg,

After porting my extensions to the new PostgreSQL extension system, I
tried to do the same with the RDKit cartridge. Changing the Makefile
and adding a .control file was pretty easy but apparently some of the
internal PostgreSQL functions related to GUC have changed:

guc.c: In function ‘initRDKitGUC’:
guc.c:84:28: warning: passing argument 10 of
‘DefineCustomRealVariable’ from incompatible pointer type
/usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: expected
‘GucRealCheckHook’ but argument is of type ‘bool (*)(double,  bool,
enum GucSource)’
guc.c:84:28: error: too few arguments to function ‘DefineCustomRealVariable’
/usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: declared here
guc.c:98:28: warning: passing argument 10 of
‘DefineCustomRealVariable’ from incompatible pointer type
/usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: expected
‘GucRealCheckHook’ but argument is of type ‘bool (*)(double,  bool,
enum GucSource)’
guc.c:98:28: error: too few arguments to function ‘DefineCustomRealVariable’
/usr/include/postgresql/9.1/server/utils/guc.h:257:13: note: declared here
make: *** [guc.o] Error 1

Adrian

[Rdkit-devel] New RDKit SWIG wrappers

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

Dear all,

I'm happy to announce the next contribution to the RDKit from NIBR: a
new set of SWIG-based Java wrappers for the RDKit. These wrappers,
developed for us by Entagen, provide a much better coverage of the C++
functionality and are more robust than the demo SWIG wrappers I had
developed as a proof of concept. There are some API differences, so
code that worked with the old wrappers will require a few
modifications to work with the new wrappers.

The new wrappers had been on a branch in svn for the past week or so,
this morning I merged them onto the trunk. They live in
$RDBASE/Code/JavaWrappers

If you're interested in building the wrappers yourself, note that
there's a change in the build process: at the moment you need to put a
copy of junit.jar (from www.junit.org) in the directory
$RDBASE/External/java_lib.

Please give the wrappers a try and let me know what you think.

 Best Regards,
-greg

[Rdkit-devel] 2011.03 (Q1 2011) RDKit release

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

Dear all,

I'm very happy to announce that the next version of the RDKit --
2011.03 (a.k.a Q1 2011) -- is released.

The release notes are below.

The source release is on the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q1_2011/
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list
I will upload Windows binaries (python 2.6 only, please let me know if
anyone needs a python 2.7 release) 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.03.1 *******
(Changes relative to Release_2010.12.1)

Acknowledgements:
 - Eddie Cao, James Davidson, Kirk DeLisle, Peter Gedeck, George
   Magoon, TJ O'Donnell, Gianluca Sforna, Nik Stiefl, Bernd Wiswedel

Bug Fixes:
 - The performance of SSSR finding for molecules with multiple highly-fused
   ring systems has been improved. (Issue 3185548)
 - Isotope information is now correctly saved when molecules are
   serialized (pickled). (Issue 3205280)
 - Generating SMILES for a molecule no longer changes the
   molecule. This fixes a round-trip bug with certain highly symmetric
   molecules read from SD files. (Issue 3228150)
 - Another bounds-matrix generation bug for highly (con)strained
   systems was fixed. (Issue 3238580)
 - Conformation information is now better handled by deleteSubstructs(),
   replaceSubstructs(), and replaceCore().

New Features:
 - the rdkit.Chem.Draw package has been significantly refactored.
 - Code for doing Murcko decomposition of molecules has been
   added. From Python this is in the module:
   rdkit.Chem.Scaffolds.MurckoScaffold
   It's available in C++ in the GraphMol/ChemTransforms area.
 - rdkit.Chem.AllChem.TransformMol() now takes optional arguments
   allowing the conformation to be transformed to be specified and
   other existing conformations to be preserved.
 - Calculations for most of the descriptors in rdkit.Chem.Lipinski and
   rdkit.Chem.MolSurf have been moved into C++. The python API is the
   same, but the calculations should be somewhat faster.
 - Extensive feature additions to the SWIG-based java wrapper.
 - The Chem.ReplaceCore() function is now better suited for use
   in R-group decomposition.
 - The Morgan fingerprinting code can now return information about
   which atoms set particular bits.
 - The function pathToSubmol() now copies coordinate information
   from conformations (if present). The function is also now available
   from Python
 - The path and subgraph finding code now takes an optional
   rootedAtAtom argument to allow only paths/subgraphs that start at a
   particular atom to be generated.
 - The function findAtomEnvironmentOfRadiusN has been added to allow
   circular atom environments to be located in molecules.
 - MolOps::assignStereochemistry now can also flag potential
   stereocenters that are not specified.

New Database Cartridge Features:
 - the descriptor-calculation functions mol_numrotatablebonds(),
   mol_numheteroatoms(), mol_numrings(), and mol_tpsa() have been
   added.

Deprecated modules (to be removed in next release):

Removed modules:

Other:
 - In C++, the functions CalcCrippenDescriptors and CalcAMW have been
   renamed calcCrippenDescriptors and calcAMW to make them consistent
   with the other descriptor calculators.
 - The molecule serialization (pickling) format has been changed. The
   new format is more compact.

[Rdkit-devel] Beta of Q1 2011 Release Available

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

Dear all,

This morning I tagged the beta for the Q1 2011 (2011.03 in the new
numbering) release in svn:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2011_03_1beta1/

and uploaded a source distribution to the google code site:
http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2011_03_1beta1.tgz
If there's demand for it, I will also put up a windows binary.

As usual: if no show-stopper bugs appear, I will do the release itself
in about a week.

Excerpts from the release notes are below.

Best Regards,
-greg

******  Release_2011.03.1 *******
(Changes relative to Release_2010.12.1)

Acknowledgements:
 - Eddie Cao, James Davidson, Kirk DeLisle, Peter Gedeck, George
   Magoon, TJ O'Donnell, Gianluca Sforna, Nik Stiefl, Bernd Wiswedel

Bug Fixes:
 - The performance of SSSR finding for molecules with multiple highly-fused
   ring systems has been improved. (Issue 3185548)
 - Isotope information is now correctly saved when molecules are
   serialized (pickled). (Issue 3205280)
 - Generating SMILES for a molecule no longer changes the
   molecule. This fixes a round-trip bug with certain highly symmetric
   molecules read from SD files. (Issue 3228150)
 - Another bounds-matrix generation bug for highly (con)strained
   systems was fixed. (Issue 3238580)
 - Conformation information is now better handled by deleteSubstructs(),
   replaceSubstructs(), and replaceCore().

New Features:
 - the rdkit.Chem.Draw package has been significantly refactored.
 - Code for doing Murcko decomposition of molecules has been
   added. From Python this is in the module:
   rdkit.Chem.Scaffolds.MurckoScaffold
   It's available in C++ in the GraphMol/ChemTransforms area.
 - rdkit.Chem.AllChem.TransformMol() now takes optional arguments
   allowing the conformation to be transformed to be specified and
   other existing conformations to be preserved.
 - Calculations for most of the descriptors in rdkit.Chem.Lipinski and
   rdkit.Chem.MolSurf have been moved into C++. The python API is the
   same, but the calculations should be somewhat faster.
 - Extensive feature additions to the SWIG-based java wrapper.
 - The Chem.ReplaceCore() function is now better suited for use
   in R-group decomposition.
 - The Morgan fingerprinting code can now return information about
   which atoms set particular bits.
 - The function pathToSubmol() now copies coordinate information
   from conformations (if present). The function is also now available
   from Python
 - The path and subgraph finding code now takes an optional
   rootedAtAtom argument to allow only paths/subgraphs that start at a
   particular atom to be generated.
 - The function findAtomEnvironmentOfRadiusN has been added to allow
   circular atom environments to be located in molecules.
 - MolOps::assignStereochemistry now can also flag potential
   stereocenters that are not specified.

New Database Cartridge Features:
 - the descriptor-calculation functions mol_numrotatablebonds(),
   mol_numheteroatoms(), mol_numrings(), and mol_tpsa() have been
   added.

Deprecated modules (to be removed in next release):

Removed modules:

Other:
 - In C++, the functions CalcCrippenDescriptors and CalcAMW have been
   renamed calcCrippenDescriptors and calcAMW to make them consistent
   with the other descriptor calculators.
 - The molecule serialization (pickling) format has been changed. The
   new format is more compact.

Re: [Rdkit-devel] [Cartridge] Cis/Trans in SMILES bug (backslashes)

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

Hi Adrian,

On Fri, Apr 1, 2011 at 3:15 PM, Adrian Schreyer <am...@ca...> wrote:
>
> I have noticed that trans backslashes in SMILES strings will cause
> problems in PostgreSQL because they are not treated as literals by
> default. The E'' syntax will not escape the backslash and just remove
> it instead. select 'F\C=C/F' = 'F\C=C/F' is by default the same as
> select 'FC=C/F' = 'F\C=C/F.

Nice catch.

Apparently the E and \\ works :
vendors=# select E'F\\C=C/F'::mol::text;
  text
---------
 F/C=C\F
(1 row)

Happily, when inserting from a file, \\ works as well:
~ > cat > blah.smi
C/C=C/C
C\\C=C/C
~ > psql vendors
psql (9.0.0)
Type "help" for help.

vendors=# create table blah (m mol);
CREATE TABLE
vendors=# copy blah (m) from '/Users/landrgr1/blah.smi';
COPY 2
vendors=# select * from blah
vendors-# ;
    m
---------
 C/C=C/C
 C/C=C\C
(2 rows)


Best Regards,
-greg

[Rdkit-devel] [Cartridge] Cis/Trans in SMILES bug (backslashes)

[Adrian S. <am...@ca...>]

Hi Greg,

I have noticed that trans backslashes in SMILES strings will cause
problems in PostgreSQL because they are not treated as literals by
default. The E'' syntax will not escape the backslash and just remove
it instead. select 'F\C=C/F' = 'F\C=C/F' is by default the same as
select 'FC=C/F' = 'F\C=C/F.

Given the molecule:
CC[NH+]1CC[NH+](CC1)Cc2cc(cc(c2)NC(=O)c3cccc4c3ccc(c4)c5ccc(o5)/C=C\6/C(=O)NC(=O)S6)C(F)(F)F

>>> select mol_in('CC[NH+]1CC[NH+](CC1)Cc2cc(cc(c2)NC(=O)c3cccc4c3ccc(c4)c5ccc(o5)/C=C\6/C(=O)NC(=O)S6)C(F)(F)F'::cstring)

produces "WARNING:  nonstandard use of escape in a string literal" and
SMILES error afterwards

>>> select mol_in(E'CC[NH+]1CC[NH+](CC1)Cc2cc(cc(c2)NC(=O)c3cccc4c3ccc(c4)c5ccc(o5)/C=C\6/C(=O)NC(=O)S6)C(F)(F)F'::cstring)

will be escaped to a binary character, produces SMILES error

---

The solution is to set standard_conforming_strings = on (default in 9.1):

>>> set standard_conforming_strings = on;

>>> select mol_in('CC[NH+]1CC[NH+](CC1)Cc2cc(cc(c2)NC(=O)c3cccc4c3ccc(c4)c5ccc(o5)/C=C\6/C(=O)NC(=O)S6)C(F)(F)F'::cstring);

produces: CC[NH+]1CC[NH+](Cc2cc(NC(=O)c3cccc4c3ccc(-c3ccc(/C=C5\SC(=O)NC5=O)o3)c4)cc(C(F)(F)F)c2)CC1

if you take this SMILES string and do mol_in without
standard_conforming_strings you will get:
CC[NH+]1CC[NH+](Cc2cc(NC(=O)c3cccc4c3ccc(-c3ccc(C=C5SC(=O)NC5=O)o3)c4)cc(C(F)(F)F)c2)CC1,
which is different.

Cheers,

Adrian

Re: [Rdkit-devel] Chem/Draw code: new feature and some refactoring

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

The changes are merged in here:
https://rdkit.svn.sourceforge.net/svnroot/rdkit/branches/DrawChanges_20March2011

I've verified that the current code works for me on the Mac using
cairo, aggdraw, and sping. I will be going through it a bit more over
the next couple of days, but it would be great if others could also
take a look.

-greg

Re: [Rdkit-devel] Chem/Draw code: new feature and some refactoring

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

Hi Gianluca,

On Sat, Mar 19, 2011 at 10:41 AM, gi...@gm... <gi...@gm...> wrote:
> Ok Greg, it took a while to come back at this; hopefully we can speed
> it up from now on
>
> On Fri, Feb 11, 2011 at 6:49 AM, Greg Landrum <gre...@gm...> wrote:
>> I made some changes and have attached the diffs (if we have to wait
>> for me to figure out git correctly, we'll be waiting a long time).
>>
>> We can do a round or two via git if you like, and then I'll merge the
>> changes back into the main svn.
>
> I reviewed the changes and (hopefully) got them applied as intended;
> there is more work I'd like to see there but it will take more time.
>
> I will be sending the complete patch set here with git send-email, in
> the meanwhile the code was pushed to:
> https://github.com/giallu/rdkit/tree/draw_refactor

Thanks for the diffs. I'll take a look and get them merged into the
svn on a branch over the weekend and then we can review the branch.

Best,
-greg

[Rdkit-devel] [PATCH 17/17] Allow passing a Canvas object to MolToImage().

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

Use cairo based Canvas by default
---
 rdkit/Chem/Draw/__init__.py |   31 ++++++++++++++++---------------
 1 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/rdkit/Chem/Draw/__init__.py b/rdkit/Chem/Draw/__init__.py
index e42eb64..ac1df88 100644
--- a/rdkit/Chem/Draw/__init__.py
+++ b/rdkit/Chem/Draw/__init__.py
@@ -7,7 +7,8 @@ import os.path
 
 from MolDrawing import MolDrawing
 
-def MolToImage(mol, size=(300,300), kekulize=True, wedgeBonds=True, **kwargs):
+def MolToImage(mol, size=(300,300), kekulize=True, wedgeBonds=True,
+               canvas=None, **kwargs):
   """ returns a PIL image containing a drawing of the molecule
 
     Keyword arguments:
@@ -19,25 +20,25 @@ def MolToImage(mol, size=(300,300), kekulize=True, wedgeBonds=True, **kwargs):
   """
   if not mol:
     raise ValueError,'Null molecule provided'
-  import Image
-  try:
-    from aggCanvas import Canvas
-    useAGG=True
-  except ImportError:
+  if canvas is None:
+    import Image
     useAGG=False
+    useCAIRO=False
     try:
       from cairoCanvas import Canvas
       useCAIRO=True
     except ImportError:
-      useCAIRO=False
-      from spingCanvas import Canvas
-      canvas = Canvas(size=size,name='MolToImageFile')
-      img = canvas._image
-      drawer = MolDrawing(canvas)
-  if useAGG or useCAIRO:
-    img = Image.new("RGBA",size,"white")
-    canvas = Canvas(img)
-    drawer = MolDrawing(canvas)
+      try:
+        from aggCanvas import Canvas
+        useAGG=True
+      except ImportError:
+        from spingCanvas import Canvas
+        canvas = Canvas(size=size,name='MolToImageFile')
+        img = canvas._image
+    if useAGG or useCAIRO:
+      img = Image.new("RGBA",size,"white")
+      canvas = Canvas(img)
+  drawer = MolDrawing(canvas)
 
   if kekulize:
     from rdkit import Chem
-- 
1.7.4