rdkit-devel — Developers information and discussion.

Re: [Rdkit-devel] fmcs in RDKit

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

On Sat, Sep 1, 2012 at 1:28 AM, Andrew Dalke <da...@da...> wrote:
> I've started to add the fmcs MCS search code to RDKit.
> By that I mean it does not include the command-line driver
> which is part of the fmcs distribution; just the MCS search code.

I would have no objection to the command-line driver being there in a
separate file in the package; it could well be useful to people.

> The interface to it is a single function which takes these
> parameters.
>
> def MCS(mols, min_num_atoms=2,
>         maximize = Default.maximize,
>         atom_compare = Default.atom_compare,
>         bond_compare = Default.bond_compare,
>         match_valences = Default.match_valences,
>         ring_matches_ring_only = False,
>         complete_rings_only = False,
>         timeout=Default.timeout,
>         times=None,
>         verbose=False,
>         verbose_delay=1.0,
>         ):

Any objection to calling it FindMCS?

>
> The steps I've done so far are:
>   - rename all other functions and classes to use the
>       "_" prefix to indicate that they are internal
>   - remove the command-line driver code
>   - removed all code uses of the word 'fmcs'
>
> The steps still to do are:
>   - use the right module name
>   - reformat the doc strings
>   - make it build properly
>   - add basic tests
>   - add the above to SVN and commit to SF
>
> I have some questions about those steps.
>
> 1) What is the right module name? Greg and I talked
> about it a couple of months ago. I can't find the
> paper where I wrote it down.
>
> Right now it is "rdkit.Chem.MCS", so that the actual
> function to call is "rdkit.Chem.MCS.MCS".

MCS is fine with me, the function would then be rdkit.Chem.MCS.FindMCS
assuming that you agree with my function renaming suggestion.

> 2) Is there any other documentation I should update
> other than the docstrings?

It would be nice to have something about it in the Getting Started
guide, but I can do that.

>
> I'll have more questions which I get to the build system.
>
>
> I'm not sure of the long-term coordination between
> the RDKit and fmcs code bases. Greg would like to
> push more of the RDKit code into C++ while I would
> like fmcs to be portable across other toolkits.

Since the rest of the list haven't been involved in these discussions,
here's my motivation for that:
having the MCS code in C++ increases the impact of the code: it allows
it to be used from the cartridge, in the knime nodes, from other Java
programs, and from C++ itself. There may also be performance benefits
(I say "may" because I know that Andrew writes really good Python
code), but those are at most a secondary motivation

-greg

[Rdkit-devel] fmcs in RDKit

[Andrew D. <da...@da...>]

I've started to add the fmcs MCS search code to RDKit.
By that I mean it does not include the command-line driver
which is part of the fmcs distribution; just the MCS search code.

The interface to it is a single function which takes these
parameters. 

def MCS(mols, min_num_atoms=2,
        maximize = Default.maximize,
        atom_compare = Default.atom_compare,
        bond_compare = Default.bond_compare,
        match_valences = Default.match_valences,
        ring_matches_ring_only = False,
        complete_rings_only = False,
        timeout=Default.timeout,
        times=None,
        verbose=False,
        verbose_delay=1.0,
        ):


The steps I've done so far are:
  - rename all other functions and classes to use the
      "_" prefix to indicate that they are internal
  - remove the command-line driver code
  - removed all code uses of the word 'fmcs'

The steps still to do are:
  - use the right module name
  - reformat the doc strings
  - make it build properly
  - add basic tests
  - add the above to SVN and commit to SF

I have some questions about those steps.

1) What is the right module name? Greg and I talked
about it a couple of months ago. I can't find the
paper where I wrote it down.

Right now it is "rdkit.Chem.MCS", so that the actual
function to call is "rdkit.Chem.MCS.MCS".

2) Is there any other documentation I should update
other than the docstrings?

I'll have more questions which I get to the build system.


I'm not sure of the long-term coordination between
the RDKit and fmcs code bases. Greg would like to
push more of the RDKit code into C++ while I would
like fmcs to be portable across other toolkits.

My hope is that excepting API names, future code
will be portable across both futures. My other hope
is to get funding for the work. :)


				Andrew
				da...@da...

Re: [Rdkit-devel] New MolDrawing.h

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

On Wed, Aug 15, 2012 at 6:04 AM, Greg Landrum <gre...@gm...> wrote:
>
> On Tue, Aug 14, 2012 at 1:20 PM, David Cosgrove
> <dav...@gm...> wrote:
>
>> As for the Qt demo, if it's convenient for you to do so, please do add the
>> standard licence to the top of the files. I assume the copyright transfers
>> to you as the RDKit owner?  That's no problem, I just wasn't sure exactly
>> what to put.
>
> I'll make those updates and get the code checked in. Thanks for
> contributing the examples!

I just realized that I hadn't done this.
The qt demo code is now in $RDBASE/Code/Demos/RDKit/Draw/qtDemo

Best,
-greg

[Rdkit-devel] Speeding up SMILES parsing

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

Over the past couple of days I've spent some time doing some tuning of
the RDKit's SMILES parser.

I made a couple of minor changes here and there and saw some
improvement before making a change in the YACC grammar used to
generate the parser. This made the parser source a bit more difficult
to read, but had a pretty significant impact on performance.

In order to just measure performance of the SMILES parser, I did a
benchmark using ~560K molecules from ZINC where I generated a molecule
from SMILES without any sanitization.
Here are the timings on my linux box for that benchmark:

RDKit_2011_06_1: 50.6s
RDKit_2012_03_1: 49.6s
RDKit_2012_06_1: 57.6s  [ <- I'm not sure I understand this outlier]
svn: 30.6s

I'm pretty pleased about that last number. :-)

For those who are interested, here's the commit:
https://sourceforge.net/p/rdkit/code/2159/
and the specific grammar changes that made the difference:
https://sourceforge.net/p/rdkit/code/2159/tree//trunk/Code/GraphMol/SmilesParse/smiles.yy?diff=502dda6571b75b41b4b10063:2158

-greg

Re: [Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

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

Hi James,

On Fri, Aug 24, 2012 at 1:24 AM, James Swetnam <jsw...@gm...> wrote:
> Ironically, I just ran into this same issue with our internal gcc build
> today.  I've attached a patch that removes the platform-specific -O0 flag
> for Dict.cpp and replaces the force_types() method with the following, which
> is somewhat more C++ standard-compliant and portable:
>
> #define ANY_FORCE(T) template T Dict::fromany<T>(const boost::any& arg)
> const; \
>                      template boost::any Dict::toany<T>(T arg) const;
>   ANY_FORCE(int);
>   ANY_FORCE(bool);
>   ANY_FORCE(unsigned int);
>   ANY_FORCE(double);
>   ANY_FORCE(std::string);
>   ANY_FORCE(std::vector<int>);
>   ANY_FORCE(std::vector<unsigned int>);
> ...
> etc.
>
> You can read up on what's going on here (it's not pretty, nothing with c++
> template programming is) here:
> http://www.parashift.com/c++-faq-lite/separate-template-fn-defn-from-decl.html
>
> Feel free to use the patch or not.  Thanks!

Thanks for the patch!

I checked the changes in this morning after testing on my windows
build machine and an up-to-date version of linux. I'm guessing this
isn't going to cause any problems with older gcc versions, but I'll
verify that in the next couple days.

-greg

Re: [Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

[Andrew D. <da...@da...>]

On Aug 24, 2012, at 1:24 AM, James Swetnam wrote:
> Ironically, I just ran into this same issue with our internal gcc build today.  I've attached a patch that removes the platform-specific -O0 flag for Dict.cpp and replaces the force_types() method with the following, which is somewhat more C++ standard-compliant and portable:  

It works - w00t!

Thanks James; I have a 100% build now.

> You can read up on what's going on here (it's not pretty, nothing with c++ template programming is) here:
> http://www.parashift.com/c++-faq-lite/separate-template-fn-defn-from-decl.html

 "I will do it anyway even though it's confusing."
 "I will do it anyway even though it's confusing."
 "I will do it anyway even though it's confusing."

  :)




				Andrew
				da...@da...

Re: [Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

[James S. <jsw...@gm...>]

Sorry for the red herring, Andrew.

FWIW, per the comment in CMakeLists.txt, I was able to reproduce the error
on GCC 4.4.3 on our corporate ubuntu distribution by removing the -O0 flag.
 Experimentation revealed that building Dict.cpp with -O1 links
successfully, so I assume the particular optimization that is eliding these
symbols is in O2 or beyond.

Best,
James

On Wed, Aug 22, 2012 at 11:56 PM, Greg Landrum <gre...@gm...>wrote:

> Hi Andrew,
>
> On Wed, Aug 22, 2012 at 12:17 PM, Andrew Dalke
> <da...@da...> wrote:
> > On Aug 17, 2012, at 11:35 AM, Greg Landrum wrote:
> >> Here is, hopefully, the last update on this topic. Apologies for the
> verbosity.
> >
> > I'm trying to build the latests from the new repository. Here's
> > the message I get:
> >
> > [  4%] Building CXX object
> Code/RDGeneral/CMakeFiles/testDict.dir/testDict.cpp.o
> > Linking CXX executable testDict
> > ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a
> directory
> > Undefined symbols for architecture x86_64:
> >   "boost::any RDKit::Dict::toany<std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > > >(std::vector<std::vector<int, std::allocator<int> >,
> std::allocator<std::vector<int, std::allocator<int> > > >) const",
> referenced from:
> >       void RDKit::Dict::setVal<std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > > >(std::string const&, std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > >&) in testDict.cpp.o
> >   "std::vector<int, std::allocator<int> >
> RDKit::Dict::fromany<std::vector<int, std::allocator<int> > >(boost::any
> const&) const", referenced from:
> >       void RDKit::Dict::getVal<std::vector<int, std::allocator<int> >
> >(std::string const&, std::vector<int, std::allocator<int> >&) const in
> testDict.cpp.o
> >   "boost::any RDKit::Dict::toany<std::vector<int, std::allocator<int> >
> >(std::vector<int, std::allocator<int> >) const", referenced from:
> >       void RDKit::Dict::setVal<std::vector<int, std::allocator<int> >
> >(std::string const&, std::vector<int, std::allocator<int> >&) in
> testDict.cpp.o
> >   "int RDKit::Dict::fromany<int>(boost::any const&) const", referenced
> from:
> >       void RDKit::Dict::getVal<int>(std::string const&, int&) const in
> testDict.cpp.o
> >   "boost::any RDKit::Dict::toany<int>(int) const", referenced from:
> >       void RDKit::Dict::setVal<int>(std::string const&, int&) in
> testDict.cpp.o
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
>
> Nikolas Fechner, who has a MacBookPro running Lion, and I just got
> this figured out.
> There's a test at line 4 of $RDBASE/Code/RDGeneral/CMakeLists.txt:
>
> if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANG)
> # Dict.cpp behaves badly if compiled with optimization under g++
> SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
> endif()
>
> apparently neither of those two variables is set under Lion. The
> "fix", which I will check in later today, is:
>
> if(NOT MSVC)
> # Dict.cpp behaves badly if compiled with optimization under g++
> SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
> endif()
>
> After making this change we were able to complete an RDKit build on
> Niko's machine.
>
> I will try to remember to do a longer explanation of why the above is
> necessary later, but right now I have to run to a meeting.
>
> Hope this helps,
> -greg
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

Re: [Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

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

Hi Andrew,

On Wed, Aug 22, 2012 at 12:17 PM, Andrew Dalke
<da...@da...> wrote:
> On Aug 17, 2012, at 11:35 AM, Greg Landrum wrote:
>> Here is, hopefully, the last update on this topic. Apologies for the verbosity.
>
> I'm trying to build the latests from the new repository. Here's
> the message I get:
>
> [  4%] Building CXX object Code/RDGeneral/CMakeFiles/testDict.dir/testDict.cpp.o
> Linking CXX executable testDict
> ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a directory
> Undefined symbols for architecture x86_64:
>   "boost::any RDKit::Dict::toany<std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >(std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >) const", referenced from:
>       void RDKit::Dict::setVal<std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >(std::string const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >&) in testDict.cpp.o
>   "std::vector<int, std::allocator<int> > RDKit::Dict::fromany<std::vector<int, std::allocator<int> > >(boost::any const&) const", referenced from:
>       void RDKit::Dict::getVal<std::vector<int, std::allocator<int> > >(std::string const&, std::vector<int, std::allocator<int> >&) const in testDict.cpp.o
>   "boost::any RDKit::Dict::toany<std::vector<int, std::allocator<int> > >(std::vector<int, std::allocator<int> >) const", referenced from:
>       void RDKit::Dict::setVal<std::vector<int, std::allocator<int> > >(std::string const&, std::vector<int, std::allocator<int> >&) in testDict.cpp.o
>   "int RDKit::Dict::fromany<int>(boost::any const&) const", referenced from:
>       void RDKit::Dict::getVal<int>(std::string const&, int&) const in testDict.cpp.o
>   "boost::any RDKit::Dict::toany<int>(int) const", referenced from:
>       void RDKit::Dict::setVal<int>(std::string const&, int&) in testDict.cpp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>

Nikolas Fechner, who has a MacBookPro running Lion, and I just got
this figured out.
There's a test at line 4 of $RDBASE/Code/RDGeneral/CMakeLists.txt:

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANG)
# Dict.cpp behaves badly if compiled with optimization under g++
SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
endif()

apparently neither of those two variables is set under Lion. The
"fix", which I will check in later today, is:

if(NOT MSVC)
# Dict.cpp behaves badly if compiled with optimization under g++
SET_SOURCE_FILES_PROPERTIES(Dict.cpp PROPERTIES COMPILE_FLAGS -O0)
endif()

After making this change we were able to complete an RDKit build on
Niko's machine.

I will try to remember to do a longer explanation of why the above is
necessary later, but right now I have to run to a meeting.

Hope this helps,
-greg

Re: [Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

[James S. <jsw...@gm...>]

Looks like you're trying to link against a 32-bit shared library?

file -L /path/to/boost/shared/libraries*

Should tell you the architecture of your boost 1.5

On Wed, Aug 22, 2012 at 3:17 AM, Andrew Dalke <da...@da...>wrote:

> On Aug 17, 2012, at 11:35 AM, Greg Landrum wrote:
> > Here is, hopefully, the last update on this topic. Apologies for the
> verbosity.
>
> I'm trying to build the latests from the new repository. Here's
> the message I get:
>
> [  4%] Building CXX object
> Code/RDGeneral/CMakeFiles/testDict.dir/testDict.cpp.o
> Linking CXX executable testDict
> ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a
> directory
> Undefined symbols for architecture x86_64:
>   "boost::any RDKit::Dict::toany<std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > > >(std::vector<std::vector<int, std::allocator<int> >,
> std::allocator<std::vector<int, std::allocator<int> > > >) const",
> referenced from:
>       void RDKit::Dict::setVal<std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > > >(std::string const&, std::vector<std::vector<int,
> std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int>
> > > >&) in testDict.cpp.o
>   "std::vector<int, std::allocator<int> >
> RDKit::Dict::fromany<std::vector<int, std::allocator<int> > >(boost::any
> const&) const", referenced from:
>       void RDKit::Dict::getVal<std::vector<int, std::allocator<int> >
> >(std::string const&, std::vector<int, std::allocator<int> >&) const in
> testDict.cpp.o
>   "boost::any RDKit::Dict::toany<std::vector<int, std::allocator<int> >
> >(std::vector<int, std::allocator<int> >) const", referenced from:
>       void RDKit::Dict::setVal<std::vector<int, std::allocator<int> >
> >(std::string const&, std::vector<int, std::allocator<int> >&) in
> testDict.cpp.o
>   "int RDKit::Dict::fromany<int>(boost::any const&) const", referenced
> from:
>       void RDKit::Dict::getVal<int>(std::string const&, int&) const in
> testDict.cpp.o
>   "boost::any RDKit::Dict::toany<int>(int) const", referenced from:
>       void RDKit::Dict::setVal<int>(std::string const&, int&) in
> testDict.cpp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> Just in case, I rebuilt Boost to 1.50 , checked out the latest RDKit from
> 10 minutes, etc.
>
> This is deep into the mixture of C++ and OS-specific architecture I can't
> figure out.
>
> If it's of any help,
> -- The C compiler identification is GNU 4.2.1
> -- The CXX compiler identification is Clang 3.1.0
>
> What gets me is that I was able to build RDKit on this same machine last
> week.
> BTW, a "make -k" keeps on going. It looks like the issue might be some
> subtle difference between gcc and clang. I say this because I see clang
> warnings which suggest that clang hasn't yet been used to compile RDKit.
>
>
>
> /Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:50:32: warning:
> comparison of unsigned
>       expression < 0 is always false [-Wtautological-compare]
>     for (unsigned int i = 0; i < size / 2; ++i)
>                              ~ ^ ~~~~~~~~
> /Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:81:12: note: in
> instantiation of function
>       template specialization 'RDKit::SwapBytes<unsigned char, 1>'
> requested here
>     return SwapBytes<T, sizeof(T)>(value);
>            ^
> /Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:229:11: note: in
> instantiation of function
>       template specialization 'RDKit::EndianSwapBytes<0, 0, unsigned
> char>' requested here
>     loc = EndianSwapBytes<LITTLE_ENDIAN_ORDER,HOST_ENDIAN_ORDER>(tloc);
>           ^
> /Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:333:7:
> note: in instantiation of
>       function template specialization 'RDKit::streamRead<unsigned char>'
> requested here
>       streamRead(ss,tVal);
>       ^
> /Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:317:11:
> note: in instantiation of
>       function template specialization
> 'RDKit::SparseIntVect<int>::readVals<unsigned char>'
>       requested here
>           readVals<unsigned char>(ss);break;
>           ^
> /Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:295:7:
> note: in instantiation of
>       member function 'RDKit::SparseIntVect<int>::initFromText' requested
> here
>       initFromText(txt.c_str(),txt.length());
>       ^
> /Users/dalke/cvses/rdkit-code/Code/DataStructs/testDatastructs.cpp:918:9:
> note: in instantiation of
>       member function 'RDKit::SparseIntVect<int>::fromString' requested
> here
>     iV2.fromString(pkl);
>         ^
>
>
>
> /Library/Python/2.7/site-packages/numpy/core/include/numpy/npy_deprecated_api.h:11:2:
> warning:
>       #warning "Using deprecated NumPy API, disable it by #defining
> NPY_NO_DEPRECATED_API
>       NPY_1_7_API_VERSION" [-W#warnings]
> #warning "Using deprecated NumPy API, disable it by #defining
> NPY_NO_DEPRECATED_API ...
>  ^
> 1 warning generated.
>
> Currently at 35% in the build process, and slowly advancing.
>
>                                 Andrew
>                                 da...@da...
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

[Rdkit-devel] "symbol(s) not found" on Mac OS X 10.7.3

[Andrew D. <da...@da...>]

On Aug 17, 2012, at 11:35 AM, Greg Landrum wrote:
> Here is, hopefully, the last update on this topic. Apologies for the verbosity.

I'm trying to build the latests from the new repository. Here's
the message I get:

[  4%] Building CXX object Code/RDGeneral/CMakeFiles/testDict.dir/testDict.cpp.o
Linking CXX executable testDict
ld: warning: path '/usr/lib/libpython2.7.dylib' following -L not a directory
Undefined symbols for architecture x86_64:
  "boost::any RDKit::Dict::toany<std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >(std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >) const", referenced from:
      void RDKit::Dict::setVal<std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >(std::string const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >&) in testDict.cpp.o
  "std::vector<int, std::allocator<int> > RDKit::Dict::fromany<std::vector<int, std::allocator<int> > >(boost::any const&) const", referenced from:
      void RDKit::Dict::getVal<std::vector<int, std::allocator<int> > >(std::string const&, std::vector<int, std::allocator<int> >&) const in testDict.cpp.o
  "boost::any RDKit::Dict::toany<std::vector<int, std::allocator<int> > >(std::vector<int, std::allocator<int> >) const", referenced from:
      void RDKit::Dict::setVal<std::vector<int, std::allocator<int> > >(std::string const&, std::vector<int, std::allocator<int> >&) in testDict.cpp.o
  "int RDKit::Dict::fromany<int>(boost::any const&) const", referenced from:
      void RDKit::Dict::getVal<int>(std::string const&, int&) const in testDict.cpp.o
  "boost::any RDKit::Dict::toany<int>(int) const", referenced from:
      void RDKit::Dict::setVal<int>(std::string const&, int&) in testDict.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Just in case, I rebuilt Boost to 1.50 , checked out the latest RDKit from 10 minutes, etc.

This is deep into the mixture of C++ and OS-specific architecture I can't figure out.

If it's of any help,
-- The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is Clang 3.1.0

What gets me is that I was able to build RDKit on this same machine last week.
BTW, a "make -k" keeps on going. It looks like the issue might be some
subtle difference between gcc and clang. I say this because I see clang
warnings which suggest that clang hasn't yet been used to compile RDKit.



/Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:50:32: warning: comparison of unsigned
      expression < 0 is always false [-Wtautological-compare]
    for (unsigned int i = 0; i < size / 2; ++i)
                             ~ ^ ~~~~~~~~
/Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:81:12: note: in instantiation of function
      template specialization 'RDKit::SwapBytes<unsigned char, 1>' requested here
    return SwapBytes<T, sizeof(T)>(value);
           ^
/Users/dalke/cvses/rdkit-code/Code/RDGeneral/StreamOps.h:229:11: note: in instantiation of function
      template specialization 'RDKit::EndianSwapBytes<0, 0, unsigned char>' requested here
    loc = EndianSwapBytes<LITTLE_ENDIAN_ORDER,HOST_ENDIAN_ORDER>(tloc);
          ^
/Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:333:7: note: in instantiation of
      function template specialization 'RDKit::streamRead<unsigned char>' requested here
      streamRead(ss,tVal);
      ^
/Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:317:11: note: in instantiation of
      function template specialization 'RDKit::SparseIntVect<int>::readVals<unsigned char>'
      requested here
          readVals<unsigned char>(ss);break;
          ^
/Users/dalke/cvses/rdkit-code/Code/DataStructs/SparseIntVect.h:295:7: note: in instantiation of
      member function 'RDKit::SparseIntVect<int>::initFromText' requested here
      initFromText(txt.c_str(),txt.length());
      ^
/Users/dalke/cvses/rdkit-code/Code/DataStructs/testDatastructs.cpp:918:9: note: in instantiation of
      member function 'RDKit::SparseIntVect<int>::fromString' requested here
    iV2.fromString(pkl);
        ^



/Library/Python/2.7/site-packages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: 
      #warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API
      NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API ...
 ^
1 warning generated.

Currently at 35% in the build process, and slowly advancing.

				Andrew
				da...@da...

Re: [Rdkit-devel] updating the rdkit project on sourceforge

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

Here is, hopefully, the last update on this topic. Apologies for the verbosity.

One unfortunate thing about this update is that the svn repository has
moved. If you have a version of the source checked out via svn, you
need to change the repository URL.
You have a few choices:
1) checkout a fresh copy (instructions for how to do that are here:
http://sourceforge.net/p/rdkit/code)
2) switch your existing copy. The method for the switch depends on how
you checked out the code in the first place, but this is what I just
did :
svn switch --username glandrum --relocate
https://rdkit.svn.sourceforge.net/svnroot/rdkit/trunk
https://svn.code.sf.net/p/rdkit/code/trunk
I'm not quite sure why, but this worked for me on linux, but not on the Mac.
3) If you have unchecked-in changes that you want to keep, you can do
something like this:
   - cd $RDBASE
   - svn update
   - cd ..
   - svn diff $RDBASE > rdk.patch
   - mv $RDBASE $RDBASE.old
   - <do a fresh rdkit checkout as directed in option 1 above>, make
sure it goes into the directory $RDBASE
   - patch -p0 < ./rdk.patch

Best,
-greg




On Fri, Aug 17, 2012 at 8:25 AM, Greg Landrum <gre...@gm...> wrote:
> Ok, the change I mentioned below has been made; we're now using the
> new sourceforge tools.
>
> I've update the links on www.rdkit.org.
>
> The svn migration is still ongoing, so at the moment svn is unavailable.
> Once the migration is complete, people who are using the RDKit svn
> repository will need to change their local copies.
> I'll send information about how to do this once the migration has finished.
>
> -greg
>
>
> On Thu, Aug 16, 2012 at 5:24 AM, Greg Landrum <gre...@gm...> wrote:
>> Dear all,
>>
>> Sourceforge has new backend software that they are encouraging
>> everyone to switch their projects too.
>> Based on the descriptions
>> (https://sourceforge.net/p/allura/wiki/Features/) it sounds like a
>> good idea to me, so I plan to go ahead and initiate the update in the
>> next couple of days (unless one of you has a strong opinion that it
>> would be a bad idea).
>>
>> Aside from a more modern web experience and the new features described
>> above, the only real significant change that you should see is that
>> the URLs for the svn repository will change. I will send updated info
>> about this after the switch (when I know the new urls).
>>
>> For those interested, there are some details about the upgrade process
>> here: https://sourceforge.net/p/upgrade/
>>
>> Best,
>> -greg

Re: [Rdkit-devel] updating the rdkit project on sourceforge

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

Ok, the change I mentioned below has been made; we're now using the
new sourceforge tools.

I've update the links on www.rdkit.org.

The svn migration is still ongoing, so at the moment svn is unavailable.
Once the migration is complete, people who are using the RDKit svn
repository will need to change their local copies.
I'll send information about how to do this once the migration has finished.

-greg


On Thu, Aug 16, 2012 at 5:24 AM, Greg Landrum <gre...@gm...> wrote:
> Dear all,
>
> Sourceforge has new backend software that they are encouraging
> everyone to switch their projects too.
> Based on the descriptions
> (https://sourceforge.net/p/allura/wiki/Features/) it sounds like a
> good idea to me, so I plan to go ahead and initiate the update in the
> next couple of days (unless one of you has a strong opinion that it
> would be a bad idea).
>
> Aside from a more modern web experience and the new features described
> above, the only real significant change that you should see is that
> the URLs for the svn repository will change. I will send updated info
> about this after the switch (when I know the new urls).
>
> For those interested, there are some details about the upgrade process
> here: https://sourceforge.net/p/upgrade/
>
> Best,
> -greg

[Rdkit-devel] updating the rdkit project on sourceforge

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

Dear all,

Sourceforge has new backend software that they are encouraging
everyone to switch their projects too.
Based on the descriptions
(https://sourceforge.net/p/allura/wiki/Features/) it sounds like a
good idea to me, so I plan to go ahead and initiate the update in the
next couple of days (unless one of you has a strong opinion that it
would be a bad idea).

Aside from a more modern web experience and the new features described
above, the only real significant change that you should see is that
the URLs for the svn repository will change. I will send updated info
about this after the switch (when I know the new urls).

For those interested, there are some details about the upgrade process
here: https://sourceforge.net/p/upgrade/

Best,
-greg

Re: [Rdkit-devel] New MolDrawing.h

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

Dave,

On Tue, Aug 14, 2012 at 1:20 PM, David Cosgrove
<dav...@gm...> wrote:
>
> Thanks for the reply.  I'll try and find time to have a crack at wedged
> bonds in the C++ drawings.

That would be very cool.

> When does the next version freeze? I'll try and
> get it done for then.

I'm going to try to get at least the beta of the next release done
before the UGM, so the third week of September is a reasonable freeze
date. That gives me time to do some testing.

> As for the Qt demo, if it's convenient for you to do so, please do add the
> standard licence to the top of the files. I assume the copyright transfers
> to you as the RDKit owner?  That's no problem, I just wasn't sure exactly
> what to put.

I'll make those updates and get the code checked in. Thanks for
contributing the examples!

-greg

Re: [Rdkit-devel] New MolDrawing.h

[David C. <dav...@gm...>]

Hi Greg,

Thanks for the reply.  I'll try and find time to have a crack at wedged
bonds in the C++ drawings.  When does the next version freeze? I'll try and
get it done for then.

As for the Qt demo, if it's convenient for you to do so, please do add the
standard licence to the top of the files. I assume the copyright transfers
to you as the RDKit owner?  That's no problem, I just wasn't sure exactly
what to put. I'll remember to do it in future. At some point I'll learn how
to use gmail properly, so as to be able to insert a reply into the body of
the message in a sensible manner!

Cheers,
Dave


On Tue, Aug 14, 2012 at 5:01 AM, Greg Landrum <gre...@gm...>wrote:

> Hi Dave,
>
> On Tue, Aug 7, 2012 at 11:32 AM, David Cosgrove
> <dav...@gm...> wrote:
> >
> > As discussed with Greg, I've tweaked
> > $RDBASE/Code/Demos/RDKit/Draw/MolDrawing.h so that for acyclic double and
> > triple bonds the offset is symmetrical about the bond, which I think
> looks
> > neater. The two PNGs attached show the effect.
>
> Indeed. The new version definitely looks better. I just checked in a
> slightly modified version (the lines in triple bonds were being drawn
> too close to each other).
>
> > The amended header is in the
> > tarball attached, along with a toy program demonstrating drawing into a
> Qt
> > widget via a QPainter.  If you would like to include that with the cairo
> and
> > SVG demonstrators, I'd be very happy.  I do all my GUI development in
> Qt, so
> > I would have found this example useful, hopefully others might too.
>
> I'd be happy to add the Qt example (which looks good), but the files
> need to have something added to the header to make the license a bit
> clearer. Could you please add (or are you ok with me adding):
> //  This file is part of the RDKit.
> //  The contents are covered by the terms of the BSD license
> //  which is included in the file license.txt, found at the root
> //  of the RDKit source tree.
> //
> at the top of each file?
>


>
> > I'm
> > guessing that there are Python drawing modules, too, though I haven't
> > looked.  If someone can point me at the Python equivalents for drawing
> the
> > WEDGE bonds, I'll have a crack at that at some point soon, too.  I would
> > rather not have to work through the chirality designations from scratch
> if
> > someone has already done it!
>
> The Python drawing code is in $RDBASE/rdkit/Chem/Draw/MolDrawing.py
> The function to draw a wedged bond is _drawWedgedBond()
> That is called from around line 180, which shows the logic for
> figuring out when a bond should be wedged.
> Actually figuring out which bonds should be wedged is accomplished
> with the function RDKit::WedgeMolBonds()
>
> http://www.rdkit.org/C++_Docs/namespaceRDKit.html#aa07f087fff07281ab8889e6488dbb8f5
> defined in GraphMol/FileParsers/MolFileStereochem.h (that's probably
> the wrong place for this function to live).
>
> > When building my application originally, using -Wall which I do as a
> matter
> > of course, I got a number of compiler warnings about unsigned ints not
> going
> > below zero, which obscured a lot of other more useful error messages and
> > warnings. They turned out to be due to Numerics/Vector.h and
> > Numerics/Matrix.h calling RANGE_CHECK with unsigned ints with the first
> > parameter 0, the purpose in this case being to see if the second
> parameter
> > exceeded the size of a vector.  So I've added a new macro HIGH_CHECK to
> > RDGeneral/Invariant.h and used it in Vector.h and Matrix.h, new versions
> > attached.  If nothing else, it saves an unnecessary comparison.
>
> Thanks for pointing that out. Rather than add the new HIGH_CHECK
> macro, I just switched all of those RANGE_CHECKs involving unsigned
> ints to PRECONDITIONs with the appropriate single test. This
> accomplishes the same thing without requiring a special purpose macro.
> Those changes are also checked in.
>
> >  I'm not sure
> > how I should go about this sort of contribution, I hope a post like this
> is
> > ok.
>
> It's perfect.
>
> Thanks again for the contributions!
> -greg
>

Re: [Rdkit-devel] New MolDrawing.h

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

Hi Dave,

On Tue, Aug 7, 2012 at 11:32 AM, David Cosgrove
<dav...@gm...> wrote:
>
> As discussed with Greg, I've tweaked
> $RDBASE/Code/Demos/RDKit/Draw/MolDrawing.h so that for acyclic double and
> triple bonds the offset is symmetrical about the bond, which I think looks
> neater. The two PNGs attached show the effect.

Indeed. The new version definitely looks better. I just checked in a
slightly modified version (the lines in triple bonds were being drawn
too close to each other).

> The amended header is in the
> tarball attached, along with a toy program demonstrating drawing into a Qt
> widget via a QPainter.  If you would like to include that with the cairo and
> SVG demonstrators, I'd be very happy.  I do all my GUI development in Qt, so
> I would have found this example useful, hopefully others might too.

I'd be happy to add the Qt example (which looks good), but the files
need to have something added to the header to make the license a bit
clearer. Could you please add (or are you ok with me adding):
//  This file is part of the RDKit.
//  The contents are covered by the terms of the BSD license
//  which is included in the file license.txt, found at the root
//  of the RDKit source tree.
//
at the top of each file?

> I'm
> guessing that there are Python drawing modules, too, though I haven't
> looked.  If someone can point me at the Python equivalents for drawing the
> WEDGE bonds, I'll have a crack at that at some point soon, too.  I would
> rather not have to work through the chirality designations from scratch if
> someone has already done it!

The Python drawing code is in $RDBASE/rdkit/Chem/Draw/MolDrawing.py
The function to draw a wedged bond is _drawWedgedBond()
That is called from around line 180, which shows the logic for
figuring out when a bond should be wedged.
Actually figuring out which bonds should be wedged is accomplished
with the function RDKit::WedgeMolBonds()
http://www.rdkit.org/C++_Docs/namespaceRDKit.html#aa07f087fff07281ab8889e6488dbb8f5
defined in GraphMol/FileParsers/MolFileStereochem.h (that's probably
the wrong place for this function to live).

> When building my application originally, using -Wall which I do as a matter
> of course, I got a number of compiler warnings about unsigned ints not going
> below zero, which obscured a lot of other more useful error messages and
> warnings. They turned out to be due to Numerics/Vector.h and
> Numerics/Matrix.h calling RANGE_CHECK with unsigned ints with the first
> parameter 0, the purpose in this case being to see if the second parameter
> exceeded the size of a vector.  So I've added a new macro HIGH_CHECK to
> RDGeneral/Invariant.h and used it in Vector.h and Matrix.h, new versions
> attached.  If nothing else, it saves an unnecessary comparison.

Thanks for pointing that out. Rather than add the new HIGH_CHECK
macro, I just switched all of those RANGE_CHECKs involving unsigned
ints to PRECONDITIONs with the appropriate single test. This
accomplishes the same thing without requiring a special purpose macro.
Those changes are also checked in.

>  I'm not sure
> how I should go about this sort of contribution, I hope a post like this is
> ok.

It's perfect.

Thanks again for the contributions!
-greg

[Rdkit-devel] New MolDrawing.h

[David C. <dav...@gm...>]

Hi,

As discussed with Greg, I've tweaked
$RDBASE/Code/Demos/RDKit/Draw/MolDrawing.h so that for acyclic double and
triple bonds the offset is symmetrical about the bond, which I think looks
neater. The two PNGs attached show the effect.  The amended header is in
the tarball attached, along with a toy program demonstrating drawing into a
Qt widget via a QPainter.  If you would like to include that with the cairo
and SVG demonstrators, I'd be very happy.  I do all my GUI development in
Qt, so I would have found this example useful, hopefully others might too.
I'm guessing that there are Python drawing modules, too, though I haven't
looked.  If someone can point me at the Python equivalents for drawing the
WEDGE bonds, I'll have a crack at that at some point soon, too.  I would
rather not have to work through the chirality designations from scratch if
someone has already done it!

When building my application originally, using -Wall which I do as a matter
of course, I got a number of compiler warnings about unsigned ints not
going below zero, which obscured a lot of other more useful error messages
and warnings. They turned out to be due to Numerics/Vector.h and
Numerics/Matrix.h calling RANGE_CHECK with unsigned ints with the first
parameter 0, the purpose in this case being to see if the second parameter
exceeded the size of a vector.  So I've added a new macro HIGH_CHECK to
RDGeneral/Invariant.h and used it in Vector.h and Matrix.h, new versions
attached.  If nothing else, it saves an unnecessary comparison. I'm not
sure how I should go about this sort of contribution, I hope a post like
this is ok.

Regards,
Dave

Re: [Rdkit-devel] RHEL/CentOS 5 RPM in the works

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

On Sat, Jul 28, 2012 at 7:44 AM, Greg Landrum <gre...@gm...> wrote:
> One comment here: I'm planning on removing support for postgres 8.4 in
> the one of the next releases (unless there turns out to be a good
> reason not to). So if there's much effort involved in building the
> RPM, it may not be worth it.

No, there is no additional hurdles for that (except that you can't use
the version provided with the base distro). Unless a 9.X package
appear in the EPEL repo I'll stop building the subpackage when this
happens.


>> The last failing one is 76, and this happens because PIL had no "BGRA"
>> raw mode back then, so this need some patching as well.
>
> Looks like this is only used in the cairo canvas. There could be some
> problems with the version that's comes with CentOS 5 anyway: our
> internal version of rdkit.Chem.Draw.cairoCanvas has a check that, I
> believe, is specific to older versions of cairo. I just checked that
> into the open-source svn; please look to see if it helps. If not, I'm
> sure we can figure out how to patch it.

yes, the get_data method is actually not present in the pycairo
package provided by the distro. The patch "works", so now it falls
back to the other methods. I still need to fix it somehow, given I've
got no aggdraw  and sping is removed during build (I wanted to
simplify licensing on the package review)

So I have now three ways to produce a working rpm:
1. fix code to work with older pycairo
2. try to package aggdraw for EPEL
3. move to python 2.6

I'll see what's easier, I'd like to do this and move along

-- 
Gianluca Sforna

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

Re: [Rdkit-devel] RHEL/CentOS 5 RPM in the works

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

Dear Gianluca,

On Fri, Jul 27, 2012 at 9:26 AM, Gianluca Sforna <gi...@gm...> wrote:
> I'm preparing a rpm for Centos 5 (so we can keep more build questions
> away from the ML :) ) and I'm quite near a good result.

Thanks for this. Any Centos-related build pain we can prevent is a
very good thing. :-)

> In fact, within EPEL repo I found boost 1.41 and postgres 8.4 so I
> could complete a build against those instead of compiling from
> sources.

One comment here: I'm planning on removing support for postgres 8.4 in
the one of the next releases (unless there turns out to be a good
reason not to). So if there's much effort involved in building the
RPM, it may not be worth it.

>
> However, I had three failing tests: two of them (70 and 71) pass if I
> patch (see attachment) the python version check in TestRunner.py with
> a try/except (I'm not sure why it excludes python 2.4, that version
> actually was the first one to include the subprocess module it needs
> to import).

hmm, good point. I'm not sure why that says >2.4 instead of >=2.4; it
seems like a typo.
I'll fix it in svn.

> The last failing one is 76, and this happens because PIL had no "BGRA"
> raw mode back then, so this need some patching as well.

Looks like this is only used in the cairo canvas. There could be some
problems with the version that's comes with CentOS 5 anyway: our
internal version of rdkit.Chem.Draw.cairoCanvas has a check that, I
believe, is specific to older versions of cairo. I just checked that
into the open-source svn; please look to see if it helps. If not, I'm
sure we can figure out how to patch it.

> So I tried to build against python26 (which includes a newer PIL, also
> available in EPEL) but failed for a different reason (see
> https://bugzilla.redhat.com/show_bug.cgi?id=843088) so, before
> continuing on either paths, I'd like to know your opinion on the
> topic.
>
> In particular, is there any strong preference to either python 2.4 or
> 2.6? I usually try to stick to what the base distribution provides,
> but clearly there are python26+ only modules out there or they would
> need to add that package in the repos.

I think it makes sense to keep it as simple as possible, so I'd go for
python 2.4.

-greg

[Rdkit-devel] RHEL/CentOS 5 RPM in the works

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

I'm preparing a rpm for Centos 5 (so we can keep more build questions
away from the ML :) ) and I'm quite near a good result.
In fact, within EPEL repo I found boost 1.41 and postgres 8.4 so I
could complete a build against those instead of compiling from
sources.

However, I had three failing tests: two of them (70 and 71) pass if I
patch (see attachment) the python version check in TestRunner.py with
a try/except (I'm not sure why it excludes python 2.4, that version
actually was the first one to include the subprocess module it needs
to import).

The last failing one is 76, and this happens because PIL had no "BGRA"
raw mode back then, so this need some patching as well.

So I tried to build against python26 (which includes a newer PIL, also
available in EPEL) but failed for a different reason (see
https://bugzilla.redhat.com/show_bug.cgi?id=843088) so, before
continuing on either paths, I'd like to know your opinion on the
topic.

In particular, is there any strong preference to either python 2.4 or
2.6? I usually try to stick to what the base distribution provides,
but clearly there are python26+ only modules out there or they would
need to add that package in the repos.

-- 
Gianluca Sforna

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

Re: [Rdkit-devel] 2012.06 (Q2 2012) RDKit release

[Eddie C. <cao...@gm...>]

Hi,

For those Mac users using the tappable Homebrew formulae, the formulae has been updated to use the new release. To upgrade, simply run:

$ brew update
$ brew upgrade rdkit

Have fun!

Eddie


On Jul 10, 2012, at 9:11 PM, Greg Landrum wrote:

> I'm very happy to announce that the next version of the RDKit --
> 2012.06 (a.k.a Q2 2012) -- is released.
> 
> The release notes are below.
> 
> The source release is on the sourceforge downloads page:
> http://sourceforge.net/projects/rdkit/files/rdkit/Q2_2012/
> 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, have also been uploaded.
> 
> The online version of the documentation at rdkit.org has been updated.
> 
> 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_2012.06.1 *******
> (Changes relative to Release_2012.03.1)
> 
> !!!!!! IMPORTANT !!!!!!
> - Some of the bug fixes affect the generation of SMILES. Canonical
>   SMILES generated with this version of the RDKit will be different
>   from previous versions.
> - Due to changes in the cartridge, indexes on molecule and bitvector
>   fingerprint columns will need to be rebuilt.
> 
> Acknowledgements:
> Andrew Dalke, JP Ebejer, Igor Filippov, Peter Gedeck, Jan Holst
> Jensen, Adrian Jasiński, George Papadatos, Andrey Paramonov, Adrian
> Schreyer, James Swetnam
> 
> Bug Fixes:
> - Radicals are now indicated in molecular depictions. (Issue 3516995)
> - Calling .next() on an SDMolSupplier at eof no longer results in an
>   infinite loop. (Issue 3524949)
> - Chirality perception no longer fails in large molecules.
>   (Issue 3524984)
> - problem creating molblock for atom with four chiral nbrs
>   (Issue 3525000)
> - A second sanitization leads to a different molecule.
>   (Issue 3525076)
> - can't parse Rf atom in SMILES
>   (Issue 3525668)
> - generates [HH2-] but can't parse it
>   (Issue 3525669)
> - improper (re)perception of 1H-phosphole
>   (Issue 3525671)
> - ForwardSDMolSupplier not skipping forward on some errors
>   (Issue 3525673)
> - SMILES/SMARTS parsers don't recognize 0 atom maps
>   (Issue 3525776)
> - R group handling in SMILES
>   (Issue 3525799)
> - Canonical smiles failure in symmetric heterocycles
>   (Issue 3526810)
> - Canonical smiles failure with "extreme" isotopes
>   (Issue 3526814)
> - Canonical smiles failure with many symmetric fragments
>   (Issue 3526815)
> - Canonical smiles failure with dependent double bonds
>   (Issue 3526831)
> - Build Fails Due to Missing include in Code/RDBoost/Wrap.h
>   (Issue 3527061)
> - Incorrect template parameter use in std::make_pair
>   (Issue 3528136)
> - Canonicalization failure in cycle
>   (Issue 3528556)
> - incorrect values reported in ML analysis
>   (Issue 3528817)
> - Cartridge does not work on 32bit ubuntu 12.04
>   (Issue 3531232)
> - Murcko Decomposition generates unuseable molecule.
>   (Issue 3537675)
> - A few memory leaks were fixed in the Java Wrappers
> - The exact mass of molecules with non-standard isotopes is now
>   calculated correctly.
> - The default (Euclidean) distance metric should now work with Butina
>   clustering.
> - Some bugs in the depictor were fixed.
> - AvalonTools bug with coordinate generation for mols with no
>   conformers fixed.
> 
> New Features:
> - ChemicalFeatures now support an optional id
> - Isotope handling has been greatly improved. Atoms now have a
>   getIsotope() (GetIsotope() in Python) method that returns zero if
>   no isotope has been set, the isotope number otherwise.
> - The function MolFragmentToSmiles can be used to generate canonical
>   SMILES for pieces of molecules.
> - The function getHashedMorganFingerprint (GetHashedMorganFingerprint
>   in Python) has been added.
> 
> New Database Cartridge Features:
> - The functions mol_from_smiles(), mol_from_smarts(), and
>   mol_from_ctab() now return a null value instead of generating an
>   error when the molecule processing fails. This allows molecule
>   tables to be constructed faster.
> - The functions mol_to_smiles() and mol_to_smarts() have been added.
> - Creating gist indices on bit-vector fingerprint columns is faster.
> - The indexing fingerprint for molecular substructures has been changed.
>   The new fingerprint is a bit slower to generate, but is
>   considerably better at screening. More information here:
>   http://code.google.com/p/rdkit/wiki/ImprovingTheSubstructureFingerprint
> 
> New Java Wrapper Features:
> 
> Deprecated modules (to be removed in next release):
> - Support for older (pre9.1) postgresql versions.
> 
> Removed modules:
> - rdkit.Excel
> - the code in $RDBASE/Code/PgSQL/RDLib
> - rdkit.Chem.AvailDescriptors : the same functionality is now available
>   in a more useable manner from rdkit.Chem.Descriptors
> 
> Other:
> - Similarity calculations on ExplicitBitVectors should now be much faster
> - Use of [Xa], [Xb], etc. for dummy atoms in SMILES is no longer
>   possible. Use the "*" notation and either isotopes (i.e. [1*],
>   [2*]) or atom maps (i.e. [*:1], [*:2]) instead.
> - Initial work was done towards make the RDKit work on big endian
>   hardware (mainly changes to the way pickles are handled)
> - Canonical SMILES generation is now substantially faster.
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel

Re: [Rdkit-devel] 2012.06 (Q2 2012) RDKit release

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

On Wed, Jul 11, 2012 at 6:11 AM, Greg Landrum <gre...@gm...> wrote:
> I'm very happy to announce that the next version of the RDKit --
> 2012.06 (a.k.a Q2 2012) -- is released.

I uploaded in my fedorapeople space updated rpms for Fedora 17 and
Enterprise Linux 6 (RHEL, CentOS, etc)

http://giallu.fedorapeople.org/rdkit/

They are all 64bit; 32 bit and F16 packages available upon request.


-- 
Gianluca Sforna

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

[Rdkit-devel] 2012.06 (Q2 2012) RDKit release

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

I'm very happy to announce that the next version of the RDKit --
2012.06 (a.k.a Q2 2012) -- is released.

The release notes are below.

The source release is on the sourceforge downloads page:
http://sourceforge.net/projects/rdkit/files/rdkit/Q2_2012/
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, have also been uploaded.

The online version of the documentation at rdkit.org has been updated.

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_2012.06.1 *******
(Changes relative to Release_2012.03.1)

!!!!!! IMPORTANT !!!!!!
 - Some of the bug fixes affect the generation of SMILES. Canonical
   SMILES generated with this version of the RDKit will be different
   from previous versions.
 - Due to changes in the cartridge, indexes on molecule and bitvector
   fingerprint columns will need to be rebuilt.

Acknowledgements:
Andrew Dalke, JP Ebejer, Igor Filippov, Peter Gedeck, Jan Holst
Jensen, Adrian Jasiński, George Papadatos, Andrey Paramonov, Adrian
Schreyer, James Swetnam

Bug Fixes:
 - Radicals are now indicated in molecular depictions. (Issue 3516995)
 - Calling .next() on an SDMolSupplier at eof no longer results in an
   infinite loop. (Issue 3524949)
 - Chirality perception no longer fails in large molecules.
   (Issue 3524984)
 - problem creating molblock for atom with four chiral nbrs
   (Issue 3525000)
 - A second sanitization leads to a different molecule.
   (Issue 3525076)
 - can't parse Rf atom in SMILES
   (Issue 3525668)
 - generates [HH2-] but can't parse it
   (Issue 3525669)
 - improper (re)perception of 1H-phosphole
   (Issue 3525671)
 - ForwardSDMolSupplier not skipping forward on some errors
   (Issue 3525673)
 - SMILES/SMARTS parsers don't recognize 0 atom maps
   (Issue 3525776)
 - R group handling in SMILES
   (Issue 3525799)
 - Canonical smiles failure in symmetric heterocycles
   (Issue 3526810)
 - Canonical smiles failure with "extreme" isotopes
   (Issue 3526814)
 - Canonical smiles failure with many symmetric fragments
   (Issue 3526815)
 - Canonical smiles failure with dependent double bonds
   (Issue 3526831)
 - Build Fails Due to Missing include in Code/RDBoost/Wrap.h
   (Issue 3527061)
 - Incorrect template parameter use in std::make_pair
   (Issue 3528136)
 - Canonicalization failure in cycle
   (Issue 3528556)
 - incorrect values reported in ML analysis
   (Issue 3528817)
 - Cartridge does not work on 32bit ubuntu 12.04
   (Issue 3531232)
 - Murcko Decomposition generates unuseable molecule.
   (Issue 3537675)
 - A few memory leaks were fixed in the Java Wrappers
 - The exact mass of molecules with non-standard isotopes is now
   calculated correctly.
 - The default (Euclidean) distance metric should now work with Butina
   clustering.
 - Some bugs in the depictor were fixed.
 - AvalonTools bug with coordinate generation for mols with no
   conformers fixed.

New Features:
 - ChemicalFeatures now support an optional id
 - Isotope handling has been greatly improved. Atoms now have a
   getIsotope() (GetIsotope() in Python) method that returns zero if
   no isotope has been set, the isotope number otherwise.
 - The function MolFragmentToSmiles can be used to generate canonical
   SMILES for pieces of molecules.
 - The function getHashedMorganFingerprint (GetHashedMorganFingerprint
   in Python) has been added.

New Database Cartridge Features:
 - The functions mol_from_smiles(), mol_from_smarts(), and
   mol_from_ctab() now return a null value instead of generating an
   error when the molecule processing fails. This allows molecule
   tables to be constructed faster.
 - The functions mol_to_smiles() and mol_to_smarts() have been added.
 - Creating gist indices on bit-vector fingerprint columns is faster.
 - The indexing fingerprint for molecular substructures has been changed.
   The new fingerprint is a bit slower to generate, but is
   considerably better at screening. More information here:
   http://code.google.com/p/rdkit/wiki/ImprovingTheSubstructureFingerprint

New Java Wrapper Features:

Deprecated modules (to be removed in next release):
 - Support for older (pre9.1) postgresql versions.

Removed modules:
 - rdkit.Excel
 - the code in $RDBASE/Code/PgSQL/RDLib
 - rdkit.Chem.AvailDescriptors : the same functionality is now available
   in a more useable manner from rdkit.Chem.Descriptors

Other:
 - Similarity calculations on ExplicitBitVectors should now be much faster
 - Use of [Xa], [Xb], etc. for dummy atoms in SMILES is no longer
   possible. Use the "*" notation and either isotopes (i.e. [1*],
   [2*]) or atom maps (i.e. [*:1], [*:2]) instead.
 - Initial work was done towards make the RDKit work on big endian
   hardware (mainly changes to the way pickles are handled)
 - Canonical SMILES generation is now substantially faster.

[Rdkit-devel] Beta of Q2 2012 release available

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

Today I tagged the beta for the 2012.06 (Q3 2012 in the old
numbering) release in svn:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_2012_06_1beta1/

and uploaded a source distribution to the google code site:
http://code.google.com/p/rdkit/downloads/detail?name=RDKit_2012_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.

This release has a relatively small number of new features, but a
large number of bug fixes and some performance enhancements.
Excerpts from the release notes are below.

Best Regards,
-greg

******  Release_2012.06.1 *******
(Changes relative to Release_2012.03.1)

!!!!!! IMPORTANT !!!!!!
 - Some of the bug fixes affect the generation of SMILES. Canonical
   SMILES generated with this version of the RDKit will be different
   from previous versions.

Acknowledgements:
Andrew Dalke, JP Ebejer, Igor Filippov, Peter Gedeck, Jan Holst
Jensen, Adrian Jasiński, George Papadatos, Andrey Paramonov, Adrian
Schreyer, James Swetnam

Bug Fixes:
 - Radicals are now indicated in molecular depictions. (Issue 3516995)
 - Calling .next() on an SDMolSupplier at eof no longer results in an
   infinite loop. (Issue 3524949)
 - Chirality perception no longer fails in large molecules.
   (Issue 3524984)
 - problem creating molblock for atom with four chiral nbrs
   (Issue 3525000)
 - A second sanitization leads to a different molecule.
   (Issue 3525076)
 - can't parse Rf atom in SMILES
   (Issue 3525668)
 - generates [HH2-] but can't parse it
   (Issue 3525669)
 - improper (re)perception of 1H-phosphole
   (Issue 3525671)
 - ForwardSDMolSupplier not skipping forward on some errors
   (Issue 3525673)
 - SMILES/SMARTS parsers don't recognize 0 atom maps
   (Issue 3525776)
 - R group handling in SMILES
   (Issue 3525799)
 - Canonical smiles failure in symmetric heterocycles
   (Issue 3526810)
 - Canonical smiles failure with "extreme" isotopes
   (Issue 3526814)
 - Canonical smiles failure with many symmetric fragments
   (Issue 3526815)
 - Canonical smiles failure with dependent double bonds
   (Issue 3526831)
 - Build Fails Due to Missing include in Code/RDBoost/Wrap.h
   (Issue 3527061)
 - Incorrect template parameter use in std::make_pair
   (Issue 3528136)
 - Canonicalization failure in cycle
   (Issue 3528556)
 - incorrect values reported in ML analysis
   (Issue 3528817)
 - Cartridge does not work on 32bit ubuntu 12.04
   (Issue 3531232)
 - Murcko Decomposition generates unuseable molecule.
   (Issue 3537675)
 - A few memory leaks were fixed in the Java Wrappers
 - The exact mass of molecules with non-standard isotopes is now
   calculated correctly.
 - The default (Euclidean) distance metric should now work with Butina
   clustering.
 - Some bugs in the depictor were fixed.

New Features:
 - ChemicalFeatures now support an optional id
 - Isotope handling has been greatly improved. Atoms now have a
   getIsotope() (GetIsotope() in Python) method that returns zero if
   no isotope has been set, the isotope number otherwise.
 - The function MolFragmentToSmiles can be used to generate canonical
   SMILES for pieces of molecules.
 - The function getHashedMorganFingerprint (GetHashedMorganFingerprint
   in Python) has been added.

New Database Cartridge Features:

New Java Wrapper Features:

Deprecated modules (to be removed in next release):

Removed modules:
 - rdkit.Excel
 - the code in $RDBASE/Code/PgSQL/RDLib

Other:
 - Similarity calculations on ExplicitBitVectors should now be much faster
 - Use of [Xa], [Xb], etc. for dummy atoms in SMILES is no longer
   possible. Use the "*" notation and either isotopes (i.e. [1*],
   [2*]) or atom maps (i.e. [*:1], [*:2]) instead.
 - Initial work was done towards make the RDKit work on big endian
   hardware (mainly changes to the way pickles are handled)
 - Canonical SMILES generation is now substantially faster.

Re: [Rdkit-devel] Changes in the canonicalization algorithm and tests thereof

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

On Fri, Jun 29, 2012 at 7:45 AM, Greg Landrum <gre...@gm...> wrote:
>
> The test I devised was the following :
>
> 1) Read a molecule from the sdf
> 2) generate canonical smiles csmi
> 3) Parse csmi to give a new molecule
> 4) generate a new canonical smiles and make sure it matches csmi
> 5) Pick 5 random atoms in the molecule and, for each one:
>    5a) generate a non-canonical smiles rooted at that atom
>    5b) parse that non-canonical smiles to give a new molecule
>    5c) generate a new canonical smiles from that and make sure it matches csmi
>

<snip>

> If anyone has recommendations for alternate test methodologies or test
> sets, please let me know. These tests aren't exactly super fast, so
> I'd like to avoid something like "just run the {pubchem, emolecules,
> full ZINC} set", but if people are convinced that's necessary, I can
> set it up and run it.

Yesterday I successfully ran the same test across 500K compounds
randomly selected from the ZINC "Drugs Now" set
(http://zinc.docking.org/subsets/drugs-now).

I also created a second testing approach:

1) Read a molecule m1 from the sdf
2) generate canonical smiles csmi
3) Parse csmi to give a new molecule m2
4) make sure all chiral centers in m1 and m2 have the same CIP code
and that all double bonds where stereochemistry is indicated have the
same stereochemistry.
5) Pick 5 random atoms in the molecule and, for each one:
   5a) generate a non-canonical smiles rooted at that atom
   5b) parse that non-canonical smiles to give a new molecule m3
   5c) make sure all chiral centers in m1 and m3 have the same CIP
code and that all double bonds where stereochemistry is indicated have
the same stereochemistry.


This ran without failures across the 500K ZINC compounds.

I've got some confidence now that the code is correct, so I'm merging
it onto the trunk this morning.

-greg