rdkit-devel — Developers information and discussion.

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

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

Ric,

On Wed, Sep 30, 2009 at 11:38 PM, Riccardo Vianello
<ric...@gm...> wrote:
>
> On Wed, Sep 30, 2009 at 6:00 PM, Greg Landrum <gre...@gm...> wrote:
>> [...]
>> An additional piece of information: I managed over the last couple of
>> days to get the minimal branch building on windows (using visual
>> studio) with cmake. This required some changes to the CMake files. The
>> changes are currently only on the rdkit_minimal branch; once I'm more
>> comfortable that they also work smoothly on linux and the mac, these
>> changes will also have to be done on the rdkit_cmake branch. Maybe we
>> can figure out a logical division of labor for this?
>
> sure. It is obviously not easy to me to plan an effective
> decomposition, but once the specific requirements for the various OSs
> are cleared it's likely (well, it's also my hope) that extending the
> changes to the whole build could become a mostly repetitive task. In
> that case I could probably try to take care of a portion of the source
> tree.

I'm going to take a look this morning to see how much of the required
changes can be abstracted out and put into a central location (as you
did already with a lot of the library stuff).

>
> Actually this reminds me of some questions I intended to ask. In
> "translating" the Jamfiles into more or less corresponding cmake
> listfiles, I had some troubles in understanding the pattern behind the
> production of shared/dynamic vs static C++ libraries. I only read the
> minimum of the boost jam docs that the task seemed to require, but -
> with a few exception - it seemed that under Linux almost all libraries
> were shared libraries while msvc was configured to produce static
> libraries. Is this correct? I tried to clarify this myself and figure
> out the possible reasons, but after a little  I gave up and decided
> that asking could be wiser. As far as I know,  differently from the
> default for Linux shared libraries, windows DLLs are not allowed to
> have unresolved symbols, but the reason could be completely different.

It is, unfortunately, a bit more complex than this. A bit of explanation:
I'd prefer to have everything:
1) consistent (to make it easier to get your brain around things)
2) as shared libraries (so updating is easier, among other reasons)
When I did the Jamfiles, getting the dependencies right on Windows so
that everything worked as a DLL turned out to be beyond my
patience/skills, so I did most everything as static libraries. On
linux (at least, this might also be true for the Mac), some of the
libraries *need* to be dynamic in order for the python wrappers to
work correctly (has to do with passing objects between different
python modules). So we're kind of stuck with some stuff needing to be
static and some needing to be dynamic. This lead to the situation you
now see in the Jamfile-based build: dynamic libraries on linux and the
Mac and static libraries on windows.

> The rdkit_library macro in RDKitUtils.cmake, was also added in the
> hope that it could encapsulate these OS-specific library traits (and
> the corresponding conditional code) in most cases.. I checked out a
> fresh revision of the 'minimal' branch and I was trying to understand
> if the differences are repetitive enough for this to happen, but I
> have no real idea about this yet.

I believe this should be mostly do-able. As I said, I'll take a look
this morning once I've more thoroughly convinced myself that things
are actually working on the minimal branch.

-greg

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

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

Hi Greg,

On Wed, Sep 30, 2009 at 6:00 PM, Greg Landrum <gre...@gm...> wrote:
> [...]
> An additional piece of information: I managed over the last couple of
> days to get the minimal branch building on windows (using visual
> studio) with cmake. This required some changes to the CMake files. The
> changes are currently only on the rdkit_minimal branch; once I'm more
> comfortable that they also work smoothly on linux and the mac, these
> changes will also have to be done on the rdkit_cmake branch. Maybe we
> can figure out a logical division of labor for this?

sure. It is obviously not easy to me to plan an effective
decomposition, but once the specific requirements for the various OSs
are cleared it's likely (well, it's also my hope) that extending the
changes to the whole build could become a mostly repetitive task. In
that case I could probably try to take care of a portion of the source
tree.

Actually this reminds me of some questions I intended to ask. In
"translating" the Jamfiles into more or less corresponding cmake
listfiles, I had some troubles in understanding the pattern behind the
production of shared/dynamic vs static C++ libraries. I only read the
minimum of the boost jam docs that the task seemed to require, but -
with a few exception - it seemed that under Linux almost all libraries
were shared libraries while msvc was configured to produce static
libraries. Is this correct? I tried to clarify this myself and figure
out the possible reasons, but after a little  I gave up and decided
that asking could be wiser. As far as I know,  differently from the
default for Linux shared libraries, windows DLLs are not allowed to
have unresolved symbols, but the reason could be completely different.

The rdkit_library macro in RDKitUtils.cmake, was also added in the
hope that it could encapsulate these OS-specific library traits (and
the corresponding conditional code) in most cases.. I checked out a
fresh revision of the 'minimal' branch and I was trying to understand
if the differences are repetitive enough for this to happen, but I
have no real idea about this yet.

-- 
Ric

Re: [Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

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

Riccardo,

Thanks for the info here. I will take a look soon.

An additional piece of information: I managed over the last couple of
days to get the minimal branch building on windows (using visual
studio) with cmake. This required some changes to the CMake files. The
changes are currently only on the rdkit_minimal branch; once I'm more
comfortable that they also work smoothly on linux and the mac, these
changes will also have to be done on the rdkit_cmake branch. Maybe we
can figure out a logical division of labor for this?

-greg

On Wed, Sep 30, 2009 at 3:02 PM, Riccardo Vianello
<ric...@gm...> wrote:
> Hello,
>
> while building rdkit from branch CMake_28Sept2009 on my linux box,
> during the configuration step I noticed that blas/lapack were not
> checked for (CMake behaved as if no working fortran compiler were
> available, although it was).  I'm not sure I understood the
> implementation in detail, but my impression is that function
> workaround_9220() doesn't actually call enable_language() to set
> CMAKE_Fortran_COMPILER_WORKS in the parent scope, but sets the value
> of the variable it takes as second argument. It's not a big problem
> and workaround_9220 will be obsoleted by a next release of cmake, but
> in case you were interested the following small patch to
> $RDBASE/Code/CMakeLists.txt seems to provide the expected behavior (on
> my linux machine at least).
>
> Regards,
> Riccardo
>
> $ svn diff Code/CMakeLists.txt
> Index: Code/CMakeLists.txt
> ===================================================================
> --- Code/CMakeLists.txt (revision 1231)
> +++ Code/CMakeLists.txt (working copy)
> @@ -25,8 +25,9 @@
>  # pull BLAS and LAPACK
>
>  # Things are easy if we have fortran:
> -workaround_9220(Fortran OPTIONAL)
> -IF (CMAKE_Fortran_COMPILER_WORKS)
> +workaround_9220(Fortran W9220_Fortran_COMPILER_WORKS)
> +IF (W9220_Fortran_COMPILER_WORKS)
> +enable_language(Fortran)
>  find_package(BLAS)
>  find_package(LAPACK)
>  ELSE()
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

[Rdkit-devel] CMake_28Sept2009 pull BLAS and LAPACK

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

Hello,

while building rdkit from branch CMake_28Sept2009 on my linux box,
during the configuration step I noticed that blas/lapack were not
checked for (CMake behaved as if no working fortran compiler were
available, although it was).  I'm not sure I understood the
implementation in detail, but my impression is that function
workaround_9220() doesn't actually call enable_language() to set
CMAKE_Fortran_COMPILER_WORKS in the parent scope, but sets the value
of the variable it takes as second argument. It's not a big problem
and workaround_9220 will be obsoleted by a next release of cmake, but
in case you were interested the following small patch to
$RDBASE/Code/CMakeLists.txt seems to provide the expected behavior (on
my linux machine at least).

Regards,
Riccardo

$ svn diff Code/CMakeLists.txt
Index: Code/CMakeLists.txt
===================================================================
--- Code/CMakeLists.txt (revision 1231)
+++ Code/CMakeLists.txt (working copy)
@@ -25,8 +25,9 @@
 # pull BLAS and LAPACK

 # Things are easy if we have fortran:
-workaround_9220(Fortran OPTIONAL)
-IF (CMAKE_Fortran_COMPILER_WORKS)
+workaround_9220(Fortran W9220_Fortran_COMPILER_WORKS)
+IF (W9220_Fortran_COMPILER_WORKS)
+enable_language(Fortran)
 find_package(BLAS)
 find_package(LAPACK)
 ELSE()

Re: [Rdkit-devel] "minimal" version of the RDKit

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

Dear Riccardo,

Thanks for the feedback.

On Thu, Sep 3, 2009 at 1:40 AM, Riccardo
Vianello<ric...@gm...> wrote:
> On Wed, Sep 2, 2009 at 6:39 AM, Greg Landrum<gre...@gm...> wrote:
>> [...]
>>
>> One potentially interesting thing about this branch to the rest of you
>> is that it is built using cmake instead of bjam. Build instructions
>> are in the INSTALL file.
>>
>> [...]. I will at some point (in October) port the
>> trunk of the RDKit over to cmake as well (if anyone else wants to try
>> doing this: I think it should be pretty easy based on what's in the
>> minimal branch).
>
> sounds very good to me, I think that under linux cmake will allow a
> better integration of the build process with the rest of the
> distribution.

Yeah, I think it's really going to help; and not just on linux.
Windows developers are going to have a much easier time of it when the
RDKit is more easily used with visual studio projects.

> Here's some feedback:
> I've just finished compiling the minimal branch against the boost
> libraries already available on my linux box (Fedora 11) and almost
> everything worked out-of-the box and required a minimal configuration
> of the build environment (just setting $RDBASE for the build,
> $LD_LIBRARY_PATH and $PYTHONPATH to run the tests).

Glad to hear it.

> The only issue I faced has been related to the inclusion of a header
> file belonging to numpy (the numpy include directory here is
> /usr/lib/python2.6/site-packages/numpy/core/include/).
>
> I can't say if the problem is just mine, but I worked around it with a
> FindNumpy.cmake file belonging to the avogadro git repository that was
> easily returned by a web search and then some trial-and-error changes
> to it and the interested CMakeLists.txt files (until now my experience
> with cmake was just from the end-user point of view, so the minor
> fixes I made are not probably very "clean"..).

This was a mistake on my part. I had forgotten to check in a version
of FindNumPy.cmake that I added to get things building on the Mac.
That's been fixed in svn now.

-greg

Re: [Rdkit-devel] "minimal" version of the RDKit

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

Hi,

On Wed, Sep 2, 2009 at 6:39 AM, Greg Landrum<gre...@gm...> wrote:
> [...]
>
> One potentially interesting thing about this branch to the rest of you
> is that it is built using cmake instead of bjam. Build instructions
> are in the INSTALL file.
>
> [...]. I will at some point (in October) port the
> trunk of the RDKit over to cmake as well (if anyone else wants to try
> doing this: I think it should be pretty easy based on what's in the
> minimal branch).

sounds very good to me, I think that under linux cmake will allow a
better integration of the build process with the rest of the
distribution. Here's some feedback:

I've just finished compiling the minimal branch against the boost
libraries already available on my linux box (Fedora 11) and almost
everything worked out-of-the box and required a minimal configuration
of the build environment (just setting $RDBASE for the build,
$LD_LIBRARY_PATH and $PYTHONPATH to run the tests).

The only issue I faced has been related to the inclusion of a header
file belonging to numpy (the numpy include directory here is
/usr/lib/python2.6/site-packages/numpy/core/include/).

I can't say if the problem is just mine, but I worked around it with a
FindNumpy.cmake file belonging to the avogadro git repository that was
easily returned by a web search and then some trial-and-error changes
to it and the interested CMakeLists.txt files (until now my experience
with cmake was just from the end-user point of view, so the minor
fixes I made are not probably very "clean"..).

Best regards,
Riccardo

[Rdkit-devel] "minimal" version of the RDKit

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

Dear all,

In connection with the MolCore project (still in the larval stage:
http://sourceforge.net/apps/trac/molcore/) I've put together a branch
of the RDKit that includes only the most basic molecular functionality
(reading and writing from smiles and SDF, substructure searching,
reactions): http://rdkit.svn.sourceforge.net/viewvc/rdkit/branches/minimal_1Aug2009/

One potentially interesting thing about this branch to the rest of you
is that it is built using cmake instead of bjam. Build instructions
are in the INSTALL file.

Getting cmake working turned out to be relatively straightforward,
particularly now that boost supports it, and it's much easier to get
started with than bjam. I will at some point (in October) port the
trunk of the RDKit over to cmake as well (if anyone else wants to try
doing this: I think it should be pretty easy based on what's in the
minimal branch).

-greg

Re: [Rdkit-devel] Hi~ I have a question about rdkit program.

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

Dear Namjin

2009/8/11 구남진 <reb...@ho...>:
> Hi~ My name is Namjin Koo.
>
> I downloaded Rdkit file and installed the program in our computer.
>
> However, I got errors for install below,
>
> 1. File "/Python/rdkit/sping/WX/pidWxDc.py", line 21
>     from rdkit import sping.pid
>                            ^
> 2. File "/Python/rdkit/Chem/Pharm2D/Matcher.py", line 17
>     form rdkit import Chem
>              ^

great, fixed both of those in and checked them in.

> 3. error: can't copy 'rdkit/rdBase.so': doesn't exist or not a regular file
>
> 1,2 problem is solved by changing code
>
> ( sping.pid -> sping , form rdkit -> from rdkit )
>
> but I didn't solve the third problem. I think that the file is not in your
> tar file.

Can you please tell me which tar file you downloaded? It sounds like
you have a source distribution (since there are no binary
distributions for linux). You will need to build that following the
instructions on the website:
http://code.google.com/p/rdkit/wiki/BuildingOnLinux

> How do you fix this error in my server?
>
> And I want to install rdkit in Epd system , not in Python.
>
> Is it possible?

I'm not sure, but I think it should be possible. Take a look at the
install instructions and see if they help.

Best regards,
-greg

[Rdkit-devel] Hi~ I have a question about rdkit program.

[구남진 <reb...@ho...>]

Hi~ My name is Namjin Koo.

 

I downloaded Rdkit file and installed the program in our computer.

 

However, I got errors for install below,

 

1. File "/Python/rdkit/sping/WX/pidWxDc.py", line 21
    from rdkit import sping.pid
                           ^
2. File "/Python/rdkit/Chem/Pharm2D/Matcher.py", line 17
    form rdkit import Chem
             ^

3. error: can't copy 'rdkit/rdBase.so': doesn't exist or not a regular file


1,2 problem is solved by changing code

 

( sping.pid -> sping , form rdkit -> from rdkit )

 

but I didn't solve the third problem. I think that the file is not in your tar file.

 

How do you fix this error in my server? 

 

And I want to install rdkit in Epd system , not in Python.

 

Is it possible? 

 

Thank you

 

Best regard,

 

- Namjin Koo -

Re: [Rdkit-devel] Building rdkit on (k)ubuntu 9.04 amd64

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

Dear Adrian,

It looks like there are problems with ubuntu 9.04, gcc4.3, and 64 bit
systems (at least AMDs):

----
Hello Greg

I have had trouble compiling RDKit on AMD64 platform with Ubuntu 9.04
and gcc 4.3.3. The solution is to install gcc 4.4 or 4.2 from
launchpad.net repository.
I request you to add note to documentation and website so that others
can know this issue and take necessary action.

Thank you
Abhinav
---------

This is one of those situations where I believe it's not my fault
(yay! :-) since the errors come from the boost libraries (and if you
fix the one below others will come).

-greg


On Fri, Jul 17, 2009 at 12:35 PM, Adrian Schreyer<am...@ca...> wrote:
> Hi,
>
> did anyone manage to build RDKit on this platform with gcc 4.3 and
> boost 1.39? I get a lot of errors like the one below and would like to
> know if this is a platform problem or if I am missing something.
>
> Cheers,
>
> Adrian
>
> warning: No toolsets are configured.
> warning: Configuring default toolset "gcc".
> warning: If the default is wrong, your build may not work correctly.
> warning: Use the "toolset=xxxxx" option to override our guess.
> warning: For more configuration options, please consult
> warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
> ...patience...
> ...patience...
> ...patience...
> ...found 10335 targets...
> ...updating 238 targets...
> gcc.compile.c++
> DataStructs/bin/gcc-4.3.3/release/address-model-64/threading-multi/ExplicitBitVect.o
> In file included from
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset.hpp:15,
>                 from DataStructs/ExplicitBitVect.h:9,
>                 from DataStructs/ExplicitBitVect.cpp:9:
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:
> In member function ‘size_t boost::dynamic_bitset<Block,
> Allocator>::count() const’:
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
> error: ‘mode’ cannot appear in a constant-expression
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
> error: template argument 1 is invalid
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
> error: expected `>' before ‘*’ token
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
> error: expected `(' before ‘*’ token
> /usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
> error: expected primary-expression before ‘>’ token
> ./RDGeneral/types.h: At global scope:
> ./RDGeneral/types.h:49: warning: ‘RDKit::MAX_DOUBLE’ defined but not
> used
> ./RDGeneral/types.h:50: warning: ‘RDKit::EPS_DOUBLE’ defined but not
> used
> ./RDGeneral/types.h:52: warning: ‘RDKit::MAX_INT’ defined but not used
> ./RDGeneral/types.h:53: warning: ‘RDKit::MAX_LONGINT’ defined but not used
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

[Rdkit-devel] Building rdkit on (k)ubuntu 9.04 amd64

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

Hi,

did anyone manage to build RDKit on this platform with gcc 4.3 and
boost 1.39? I get a lot of errors like the one below and would like to
know if this is a platform problem or if I am missing something.

Cheers,

Adrian

warning: No toolsets are configured.
warning: Configuring default toolset "gcc".
warning: If the default is wrong, your build may not work correctly.
warning: Use the "toolset=xxxxx" option to override our guess.
warning: For more configuration options, please consult
warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html
...patience...
...patience...
...patience...
...found 10335 targets...
...updating 238 targets...
gcc.compile.c++
DataStructs/bin/gcc-4.3.3/release/address-model-64/threading-multi/ExplicitBitVect.o
In file included from
/usr/local/src/boost_1_39_0/boost/dynamic_bitset.hpp:15,
                 from DataStructs/ExplicitBitVect.h:9,
                 from DataStructs/ExplicitBitVect.cpp:9:
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:
In member function ‘size_t boost::dynamic_bitset<Block,
Allocator>::count() const’:
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
error: ‘mode’ cannot appear in a constant-expression
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
error: template argument 1 is invalid
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
error: expected `>' before ‘*’ token
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
error: expected `(' before ‘*’ token
/usr/local/src/boost_1_39_0/boost/dynamic_bitset/dynamic_bitset.hpp:1015:
error: expected primary-expression before ‘>’ token
./RDGeneral/types.h: At global scope:
./RDGeneral/types.h:49: warning: ‘RDKit::MAX_DOUBLE’ defined but not
used
./RDGeneral/types.h:50: warning: ‘RDKit::EPS_DOUBLE’ defined but not
used
./RDGeneral/types.h:52: warning: ‘RDKit::MAX_INT’ defined but not used
./RDGeneral/types.h:53: warning: ‘RDKit::MAX_LONGINT’ defined but not used

Re: [Rdkit-devel] I found Bug

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

Dear Akihiro,


On Thu, Jul 16, 2009 at 2:18 PM, Akihiro
Yokota<aki...@ya...> wrote:
>
> Nice to meet you. I am a japanese researcher for computational chemistry,
> and I am newly studying programming of cheminformatics. Therefore I am
> studying RDKit code. I am very impressed by your effective, exciting, and
> beautiful programs. I hope you go to continue to develop RDKit in a long
> time.

Thank you for your kind words.

>
> And what I would like to say is I found a bug in RDKit. please see around
> 203th-line of RDKit_Q22009_1/Code/GraphMol/Depictor/EmbeddedFrag.cpp.
>
> ----------Orignal--------------
> d_eatoms[aid].nbr1 = nb1;
> d_eatoms[aid].nbr1 = nb2;
> -------------------------------
>
> ----------Correct?-------------
> d_eatoms[aid].nbr1 = nb1;
> d_eatoms[aid].nbr2 = nb2;
> -------------------------------

Very nicely found. Thank you. I will fix it and check it in.

>
> This code makes a bug in case of the following (rare) case. I found it when
> I am reading RDKitQ1_2009, but I think it is not be fixed yet in
> RDKitQ2_2009.
>
> When 4 atoms(e.g. A, B, C and E below) are already assigned their
> coordinates, and will add the coordinate of D, RDKit makes invalid results.
> (This is because nb2 is not changed from nb2=0.)
>
> (And I found that you changed the initial value of nb2=0 instead of nb2=-1
> in RDKitQ1_2009. I think nb2=-1 is preferred rather than nb2=0)
>
>   B
>   |
>   |
> A--E---C
>   |
>   |
>   D
>

This second part I'm going to have to think about a bit more before I
make the change.

Thanks for the detailed bug report (and suggested fix!).

-greg

Re: [Rdkit-devel] I found bug

[Akihiro Y. <aki...@ya...>]

Dear develpers,

I am very sorry to send 3 massage today...

The follwing figure in previous message was not correctly.

   B
   |
   |
A--E---C
   |
   |
   D

--------------------------
A connects with E
B connects with E
C connects with E
D connects with E
-------------------------

Best regards.

Akihiro Yokota

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

[Rdkit-devel] I found Bug

[Akihiro Y. <aki...@ya...>]

(Messsage I sent 2 hours ago was not delivery... so I send again.)

Dear developers,

Nice to meet you. I am a japanese researcher for computational chemistry,
and I am newly studying programming of cheminformatics. Therefore I am
studying RDKit code. I am very impressed by your effective, exciting, and
beautiful programs. I hope you go to continue to develop RDKit in a long
time.

And what I would like to say is I found a bug in RDKit. please see around
203th-line of RDKit_Q22009_1/Code/GraphMol/Depictor/EmbeddedFrag.cpp. 

----------Orignal--------------
d_eatoms[aid].nbr1 = nb1;
d_eatoms[aid].nbr1 = nb2;
-------------------------------

----------Correct?-------------
d_eatoms[aid].nbr1 = nb1;
d_eatoms[aid].nbr2 = nb2;
-------------------------------

This code makes a bug in case of the following (rare) case. I found it when
I am reading RDKitQ1_2009, but I think it is not be fixed yet in
RDKitQ2_2009.

When 4 atoms(e.g. A, B, C and E below) are already assigned their
coordinates, and will add the coordinate of D, RDKit makes invalid results.
(This is because nb2 is not changed from nb2=0.)

(And I found that you changed the initial value of nb2=0 instead of nb2=-1
in RDKitQ1_2009. I think nb2=-1 is preferred rather than nb2=0)

   B
   |
   |
A--E---C
   |
   |
   D

Best regards.

Akihiro Yokota


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

[Rdkit-devel] I found Bug

[Akihiro Y. <aki...@ya...>]

Dear developers,

Nice to meet you. I am a japanese researcher for computational chemistry,
and I am newly studying programming of cheminformatics. Therefore I am
studying RDKit code. I am very impressed by your effective, exciting, and
beautiful programs. I hope you go to continue to develop RDKit in a long
time.

And what I would like to say is I found a bug in RDKit. please see around
203th-line of RDKit_Q22009_1/Code/GraphMol/Depictor/EmbeddedFrag.cpp. 

----------Orignal--------------
d_eatoms[aid].nbr1 = nb1;
d_eatoms[aid].nbr1 = nb2;
-------------------------------

----------Correct?-------------
d_eatoms[aid].nbr1 = nb1;
d_eatoms[aid].nbr2 = nb2;
-------------------------------

This code makes a bug in case of the following (rare) case. I found it when
I am reading RDKitQ1_2009, but I think it is not be fixed yet in
RDKitQ2_2009.

When 4 atoms(e.g. A, B, C and E below) are already assigned their
coordinates, and will add the coordinate of D, RDKit makes invalid results.
(This is because nb2 is not changed from nb2=0.)

(And I found that you changed the initial value of nb2=0 instead of nb2=-1
in RDKitQ1_2009. I think nb2=-1 is preferred rather than nb2=0)

   B
   |
   |
A--E---C
   |
   |
   D

Best regard.

Akihiro Yokota



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: [Rdkit-devel] I found Bug

[Akihiro Y. <aki...@ya...>]

Dear developers,

please forgot the following comment of my previous message.

"And I found that you changed the initial value of nb2=0 instead of
nb2=-1 in RDKitQ1_2009. I think nb2=-1 is preferred rather than nb2=0"
 
The comment above is just my mistake.

Best regards.

Akihiro Yokota


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

[Rdkit-devel] beta of Q2 release available

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

Dear all,

It's getting to be time for the next RDKit release. Yesterday I tagged
the Q2 2009 release:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_Q22009_1beta1/

and put a source tar ball up on the google code site:
http://code.google.com/p/rdkit/downloads/list

I'm going to continue to work on the code, particularly on the
documentation, but if no substantial problems are found, I will do the
release towards the end of the month.

Release notes (more complete than usual) are below.

-greg

******  Release_Q22009_1 *******
(Changes relative to Release_Q12009_2)

Acknowledgements
  - Uwe Hoffmann, Marshall Levesque, Armin Widmer

Bug Fixes
  - handling of crossed bonds in mol files fixed (issue 2804599)
  - serialization bug fixed (issue 2788233)
  - pi systems with 2 electrons now flagged as aromatic (issue 2787221)
  - Chirality swap on AddHs (issue 2762917)
  - core leak in UFFOptimizeMolecule fixed (issue 2757824)

New Features
  - cairo support in the mol drawing code (from Uwe Hoffmann) (issue 2720611)
  - Tversky and Tanimoto similarities now supported for SparseIntVects
  - AllProbeBitsMatch supported for BitVect-BitVect comparisons
  - ChemicalReactions support serialization (pickling) (issue 2799770)
  - GetAtomPairFingerprint() supports minLength and maxLength arguments
  - GetHashedTopologicalTorsionFingerprint() added
  - preliminary support added for v3K mol files
  - ForwardSDMolSupplier added
  - CompressedSDMolSupplier added (not supported on windows)
  - UFFHasAllMoleculeParams() added
  - substructure searching code now uses an RDKit implementation of
    the vf2 algorithm. It's much faster.
  - Atom.GetPropNames() and Bond.GetPropNames() now available from
    python
  - BRICS code now supports FindBRICSBonds() and BreakBRICSBonds()
  - atom labels Q, A, and * in CTABs are more correctly supported
    (issue 2797708)
  - rdkit.Chem.PropertyMol added (issue 2742959)
  - support has been added for enabling and disabling logs
    (issue 2738020)

Other
  - A demo has been added for using MPI with the RDKit
    ($RDBASE/Code/Demos/RDKit/MPI).
  - Embedding code is now better at handling chiral structures and
    should produce results for molecules with atoms that don't have
    UFF parameters.
  - the UFF code is more robust w.r.t. missing parameters
  - GetHashedAtomPairFingerprint() returns SparseIntVect instead of
    ExplicitBitVect
  - the CTAB parser (used for mol files and SD files) is faster
  - extensive changes to the layered fingerprinting code;
    fingerprinting queries is now possible
  - molecule discriminator code moved into $RDBASE/Code/GraphMol/Subgraphs
  - the SDView4 prototype has been expanded
  - $RDBASE/Regress has been added to contain regression and
    benchmarking data and scripts.
  - support for sqlalchemy has been added to $RDBASE/rdkit/Chem/MolDb
  - the BRICS code has been refactored

[Rdkit-devel] Q1 2009 Release uploaded

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

Dear all,

This morning I uploaded the 2009 Q1 source release to sourceforge:
https://sourceforge.net/project/showfiles.php?group_id=160139
and google:
http://code.google.com/p/rdkit/downloads/list

Release notes are here:
https://sourceforge.net/project/shownotes.php?group_id=160139&release_id=673088
and at the bottom of this message. Please pay attention to the
IMPORTANT section, as there have been some major changes.

Updated documentation releases have also been uploaded.

Over the next few days I will do binaries and rearrange the wiki pages
at google so that the current build instructions are the default.

Best Regards,
-greg

******  Release_Q12009_1 *******
(Changes relative to Release_Q42008_1)

!!!!!! IMPORTANT !!!!!!

 - The directory structure of the distribution has been changed in
   order to make installation of the RDKit python modules more
   straightforward. Specifically the directory $RDBASE/Python has been
   renamed to $RDBASE/rdkit and the Python code now expects that
   $RDBASE is in your PYTHONPATH. When importing RDKit Python modules,
   one should now do: "from rdkit import Chem" instead of "import
   Chem". Old code will continue to work if you also add $RDBASE/rdkit
   to your PYTHONPATH, but it is strongly suggested that you update
   your scripts to reflect the new organization.
 - For C++ programmers: There is a non-backwards compatible change in
   the way atoms and bonds are stored on molecules. See the *Other*
   section for details.

Acknowledgements
 - Kirk DeLisle, Noel O'Boyle, Andrew Dalke, Peter Gedeck, Armin Widmer

Bug Fixes
 - Incorrect handling of 0s as ring closure digits (issues 2525792,
 and 2690982)
 - Incorrect handling of atoms with explicit Hs in reactions (issue 2540021)
 - SmilesMolSupplier.GetItemText() crashes (issue 2632960)
 - Incorrect handling of dot separations in reaction SMARTS (issue 2690530)
 - Bad charge lines in mol blocks for large molecules (issue 2692246)
 - Order dependence in AssignAtomChiralTagsFromStructure (issue 2705543)
 - Order dependence in the 2D pharmacophore code
 - the LayeredFingerprints now handle non-aromatic single ring bonds
   between aromatic atoms correctly.


New Features
 - BRICS implementation
 - Morgan/circular fingerprints implementation
 - The 2D pharmacophore code now uses standard RDKit fdef files.
 - Atom parity information in CTABs now written and read. If present
   on reading, atom parity flags are stored in the atomic property
   "molParity".
 - An optional "fromAtoms" argument has been added to the atom pairs
   and topological torsion fingerprints. If this is provided, only atom
   pairs including the specified atoms, or torsions that either start
   or end at the specified atoms, will be included in the fingerprint.
 - Kekulization is now optional when generating CTABs. Since the MDL
   spec suggests that aromatic bonds not be used, this is primarily
   intended for debugging purposes.
 - the removeStereochemistry() (RemoveStereoChemistry() from Python)
   function has been added to remove all stereochemical information
   from a molecule.

Other
 - The Qt3-based GUI functionality in $RDBASE/rdkit/qtGui and
   $RDBASE/Projects/SDView is deprecated. It should still work, but it
   will be removed in a future release. Please do not build anything
   new on this (very old and creaky) framework.
 - The function DaylightFingerprintMol() is now deprecated, use
   RDKFingerprintMol() instead.
 - For C++ programmers: The ROMol methods getAtomPMap() and
   getBondPMap() have been removed. The molecules themselves now support
   an operator[]() method that can be used to convert graph iterators
   (e.g. ROMol:edge_iterator, ROMol::vertex_iterator,
   ROMol::adjacency_iterator) to the corresponding Atoms and Bonds.
   New API for looping over an atom's bonds:
        ... molPtr is a const ROMol * ...
        ... atomPtr is a const Atom * ...
        ROMol::OEDGE_ITER beg,end;
        boost::tie(beg,end) = molPtr->getAtomBonds(atomPtr);
        while(beg!=end){
          const BOND_SPTR bond=(*molPtr)[*beg];
          ... do something with the Bond ...
          ++beg;
        }
  New API for looping over a molecule's atoms:
        ... mol is an ROMol ...
        ROMol::VERTEX_ITER atBegin,atEnd;
        boost::tie(atBegin,atEnd) = mol.getVertices();
        while(atBegin!=atEnd){
          ATOM_SPTR at2=mol[*atBegin];
          ... do something with the Atom ...
          ++atBegin;
        }

[Rdkit-devel] another new feature : Morgan/circular fingerprints

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

Dear all,

I see that I forgot to mention this when I checked it in: I added the
ability to calculate molecular fingerprints generated using the Morgan
algorithm, often called circular fingerprints.

On the C++ side, the new function is defined in:
   <GraphMol/Fingerprints/MorganFingerprints.h>
>From Python it's accessible using:
>>> from rdkit.Chem import rdMolDescriptors
>>> rdMolDescriptors.GetMorganFingerprint(mol,4)
Where 4 is the radius of the fingerprint to use.

This is another opportunity for me to thank my employer for allowing
contributions of code I develop at work back to the open-source RDKit.

-greg

[Rdkit-devel] Upcoming changes in the C++ API

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

Dear all,

If you are using the RDKit from C++, please take a look at this wiki
page, which describes an upcoming change to the API of ROMols:
http://code.google.com/p/rdkit/wiki/ChangingGraphProperties

If you use the code from Python, this does not affect you.

Best Regards,
-greg

[Rdkit-devel] Announcement: Q4 2008 RDKit release

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

Dear all,

I'm very happy to announce that the next version of the RDKit --
Q42008_1 -- is released.

The release notes are below.

The source release and a windows binary are on the sourceforge downloads page:
https://sourceforge.net/project/showfiles.php?group_id=160139&package_id=180003&release_id=631220
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list

I also updated the browseable and downloadable API documentation at rdkit.org:
http://www.rdkit.org/C++_Docs
http://rdkit.org/RDKit_C++_Docs.Q42008.tgz
http://www.rdkit.org/Python_Docs
http://rdkit.org/RDKit_Python_Docs.Q42008.tgz

The API documentation is also available as a separate download from
the google code or sourceforge pages.

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
any suggestions.

-greg

******  Release_Q42008_1 *******
(Changes relative to Release_Q32008_1)

!!!!!! IMPORTANT !!!!!!
 - A fix in the handling of stereochemistry in rings means that the
   SMILES generated with this release are different from those in
   previous releases. Note that the canonicalization algorithm does
   not work in cases of pure ring stereochemistry : the SMILES should
   be correct, but it is not canonical. Rings containing chiral
   centers should be fine.

Acknowledgements:
 - Kirk DeLisle, Markus Kossner, George Magoon, Nik Stiefl

Bug Fixes
 - core leaks in learning code (issue 2152622)
 - H-bond acceptor definitions (issue 2183240)
 - handling of aromatic dummies (issue 2196817)
 - errors in variable quantization (issue 2202974)
 - errors in information theory functions on 64 bit machines (issue 2202977)
 - kekulization problems (issue 2202977)
 - infinite loop in getShortestPaths() for disconnected structures
(issue 2219400)
 - error in depictor for double bonds with stereochemistry connected
   to rings (issue 2303566)
 - aromaticity flags not copied to null atoms in reaction products
   (issue 2308128)
 - aromaticity perception in large molecule hangs (issue 2313979)
 - invariant error in canonicalization (issue 2316677)
 - mol file parser handling of bogus bond orders (issue 2337369)
 - UFF optimization not terminating when atoms are on top of each
   other (issue 2378119)
 - incorrect valence errors with 4 coordinate B- (issue 2381580)
 - incorrect parsing of atom-list queries with high-numbered atoms
   (issue 2413431)
 - MolOps::mergeQueryHs() crashing with non-query molecules. (issue
   2414779)

New Features
 - SLN parser (request 2136703).
 - Mol2 parser : Corina atom types (request 2136705).
 - Building under mingw (request 2292153).
 - Null bonds in reaction products are replaced with the corresponding
   bond from the reactants (request 2308123).

Other
 - a bunch of deprecation warnings from numpy have been cleaned up
   (issue 2318431)
 - updated documentation
 - some optimization work on the fingerprinter

[Rdkit-devel] Candidate for the Q4 2008 release

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

Dear all,

I just tagged a release candidate for the Q4 2008 release in svn:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_Q42008_1RC1/
I also uploaded a source tarball to the google code project page:
http://rdkit.googlecode.com/files/RDKit_Q42008_RC1.tgz

The release notes are at the end of this message.

If no major problems turn up, I will do the actual release in one
week: on the 13th of January.

Please let me know if you find any problems or have any suggestions.
-greg

******  Release_Q42008_1 *******
(Changes relative to Release_Q32008_1)

!!!!!! IMPORTANT !!!!!!
 - A fix in the handling of stereochemistry in rings means that the
   SMILES generated with this release are different from those in
   previous releases. Note that the canonicalization algorithm does
   not work in cases of pure ring stereochemistry : the SMILES should
   be correct, but it is not canonical. Rings containing chiral
   centers should be fine.

Acknowledgements:
 - Kirk DeLisle, Markus Kossner, George Magoon, Nik Stiefl

Bug Fixes
 - core leaks in learning code (issue 2152622)
 - H-bond acceptor definitions (issue 2183240)
 - handling of aromatic dummies (issue 2196817)
 - errors in variable quantization (issue 2202974)
 - errors in information theory functions on 64 bit machines (issue 2202977)
 - kekulization problems (issue 2202977)
 - infinite loop in getShortestPaths() for disconnected structures
(issue 2219400)
 - error in depictor for double bonds with stereochemistry connected
   to rings (issue 2303566)
 - aromaticity flags not copied to null atoms in reaction products
   (issue 2308128)
 - aromaticity perception in large molecule hangs (issue 2313979)
 - invariant error in canonicalization (issue 2316677)
 - mol file parser handling of bogus bond orders (issue 2337369)
 - UFF optimization not terminating when atoms are on top of each
   other (issue 2378119)
 - incorrect valence errors with 4 coordinate B- (issue 2381580)
 - incorrect parsing of atom-list queries with high-numbered atoms
   (issue 2413431)
 - MolOps::mergeQueryHs() crashing with non-query molecules. (issue
   2414779)

New Features
 - SLN parser (request 2136703).
 - Mol2 parser : Corina atom types (request 2136705).
 - Building under mingw (request 2292153).
 - Null bonds in reaction products are replaced with the corresponding
   bond from the reactants (request 2308123).

Other
 - a bunch of deprecation warnings from numpy have been cleaned up
   (issue 2318431)
 - updated documentation
 - some optimization work on the fingerprinter

[Rdkit-devel] New RDKit Release: Q32008_1

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

Dear all,
	
I'm very happy to announce that the next version of the RDKit --
Q32008_1 -- is released.

The release notes are below.

The source release and a windows binary are on the sourceforge downloads page:
https://sourceforge.net/project/showfiles.php?group_id=160139&package_id=180003&release_id=631220
The files can also be downloaded from the google project page:
http://code.google.com/p/rdkit/downloads/list

If you plan to build from source, please read the new build instructions:
1) For Linux: http://code.google.com/p/rdkit/wiki/BuildingOnLinux
2) For Windows: http://code.google.com/p/rdkit/wiki/BuildingOnWindows

I also updated the browseable and downloadable API documentation at rdkit.org:
http://www.rdkit.org/C++_Docs
http://rdkit.org/RDKit_C++_Docs.Q32008.tgz
http://www.rdkit.org/Python_Docs
http://rdkit.org/RDKit_Python_Docs.Q32008.tgz

Note that both the source and binary distributions of the code now
include the API documentation in directory $RDBASE/Docs/Code

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
any suggestions.

-greg

******  Release_Q32008_1 *******
(Changes relative to Release_May2008_1)

Acknowledgements:
 - Noel O'Boyle, Igor Filippov, Evgueni Kolossov, Greg Magoon

Bug Fixes
 - A memory leak in the ToBase64 and FromBase64 wrapper functions was
   fixed.
 - The UFF atom typer has been made more permissive: it now will pick
   "close" atom types for things it does not recognize. (issue
   2094445)
 - The handling of molecules containing radicals has been greatly
   improved (issues 2091839, 2091890, 2093420)
 - Iterative (or secondary, or dependent) chirality is now supported,
   see this page for more information:
   http://code.google.com/p/rdkit/wiki/IterativeChirality
   (issue 1931470)
 - Isotope handling has been changed, this allows correct matching of
   SMARTS with specified isotopes. (issue 1968930)
 - Some problems with the MACCS key definitions have been
   fixed. (issue 2027446)
 - Molecules with multiple fragments can now be correctly
   embedded. (issue 1989539)
 - Adding multiple bonds between the same atoms in a molecule now
   produces an error. (issue 1993296)
 - The chemical reaction code now handles chiral atoms correctly in
   when applying reactions with no stereochem information
   provided. (issue 2050085)
 - A problem with single-atom cores in TemplateExpand.py has been
   fixed. (issue 2091304)
 - A problem causing bicyclobutane containing molecules to not be
   embeddable has been fixed. (issue 2091864)
 - The default parameters for embedding are now molecule-size
   dependent. This should help with the embedding of large, and
   crowded molecules. (issue 2091974)
 - The codebase can now be built with boost 1.36. (issue 2071168)
 - A problem with serialization of bond directions was fixed.
   (issue 2113433)

New Features
 - The RDKit can now be built under Darwin (Mac OS/X).
 - Tversky similarity can now be calculated. (request 2015633)
 - Many of the core datastructures now support equality comparison
   (operator==). (request 1997439)
 - Chirality information can now be assigned based on the 3D
   coordinates of a molecule using
   MolOps::assignChiralTypesFrom3D(). (request 1973062)
 - MolOps::getMolFrags() can now return a list of split molecules
   instead of just a list of atom ids. (request 1992648)
 - ROMol::getPropNames() now supports the includePrivate and
   includeComputed options. (request 2047386)

Other
 - the pointers returned from Base64Encode/Decode are now allocated
   using new instead of malloc or calloc. the memory should be
   released with delete[].
 - the generation of invariants for chirality testing is now quite a
   bit faster; this results in faster parsing of molecules.
 - The use of C include files instead of their C++ replacements has
   been dramatically reduced.
 - The new (as of May2008) hashing algorithm for fingerprints is now
   the default in the python fingerprinting code
   (Chem.Fingerprints.FingerprintMols).
 - The functions MolOps::assignAtomChiralCodes() and
   MolOps::assignBondStereoCodes() are deprecated. Use
   MolOps::assignStereochemistry() instead.
 - The RDKit no longer uses the old numeric python library. It now
   uses numpy, which is actively supported.
 - By default Lapack++ is no longer used. The replacement is the boost
   numeric bindings: http://mathema.tician.de/software/boost-bindings.

[Rdkit-devel] Announcement: Q3 2008 release candidate 1

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

Dear all,

I'm really happy to announce that this morning I tagged the Q3 2008
release candidate:
https://rdkit.svn.sourceforge.net/svnroot/rdkit/tags/Release_Q32008_1RC1
(browseable at:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/tags/Release_Q32008_1RC1)

Source and binary distributions (for windows and python 2.5) are
available from the google code download page:
http://code.google.com/p/rdkit/downloads/list

If nothing major comes up, I will plan on doing the actual release one
week from today.

Note that the build instructions on linux have changed a bit:
http://code.google.com/p/rdkit/wiki/BuildingOnLinux_Q32008

If you have time to try out the release candidate, I will be very
happy to hear suggestions, problem reports, or compliments. :-)

FYI: In the interests of not constantly duplicating messages, future
release candidate announcements will be sent only to the devel list.

Here's an excerpt from the release notes (which still need to be completed):

******  Release_Q32008_1 *******
(Changes relative to Release_May2008_1)

Acknowledgements:
 - Noel O'Boyle, Igor Filippov, Evgueni Kolossov, Greg Magoon

Bug Fixes
 - A memory leak in the ToBase64 and FromBase64 wrapper functions was
   fixed.
 - The UFF atom typer has been made more permissive: it now will pick
   "close" atom types for things it does not recognize. (issue
   2094445)
 - The handling of molecules containing radicals has been greatly
   improved (issues 2091839, 2091890, 2093420)
 - Iterative (or secondary, or dependent) chirality is now supported,
   see this page for more information:
   http://code.google.com/p/rdkit/wiki/IterativeChirality
   (issue 1931470)
 - Isotope handling has been changed, this allows correct matching of
   SMARTS with specified isotopes. (issue 1968930)
 - Some problems with the MACCS key definitions have been
   fixed. (issue 2027446)
 - Molecules with multiple fragments can now be correctly
   embedded. (issue 1989539)
 - Adding multiple bonds between the same atoms in a molecule now
   produces an error. (issue 1993296)
 - The chemical reaction code now handles chiral atoms correctly in
   when applying reactions with no stereochem information
   provided. (issue 2050085)
 - A problem with single-atom cores in TemplateExpand.py has been
   fixed. (issue 2091304)
 - A problem causing bicyclobutane containing molecules to not be
   embeddable has been fixed. (issue 2091864)
 - The default parameters for embedding are now molecule-size
   dependent. This should help with the embedding of large, and
   crowded molecules. (issue 2091974)
 - The codebase can now be built with boost 1.36. (issue 2071168)
 - A problem with serialization of bond directions was fixed.
   (issue 2113433)

New Features
 - The RDKit can now be built under Darwin (Mac OS/X).
 - Tversky similarity can now be calculated. (request 2015633)
 - Many of the core datastructures now support equality comparison
   (operator==). (request 1997439)
 - Chirality information can now be assigned based on the 3D
   coordinates of a molecule using
   MolOps::assignChiralTypesFrom3D(). (request 1973062)

Other
 - the pointers returned from Base64Encode/Decode are now allocated
   using new instead of malloc or calloc. the memory should be
   released with delete[].
 - the generation of invariants for chirality testing is now quite a
   bit faster; this results in faster parsing of molecules.
 - The use of C include files instead of their C++ replacements has
   been dramatically reduced.
 - The new (as of May2008) hashing algorithm for fingerprints is now
   the default in the python fingerprinting code
   (Chem.Fingerprints.FingerprintMols).
 - The functions MolOps::assignAtomChiralCodes() and
   MolOps::assignBondStereoCodes() are deprecated. Use
   MolOps::assignStereochemistry() instead.
 - The RDKit no longer uses the old numeric python library. It now
   uses numpy, which is actively supported.
 - By default Lapack++ is no longer used. The replacement is the boost
   numeric bindings: http://mathema.tician.de/software/boost-bindings.


Best Regards,
-greg

[Rdkit-devel] Getting ready for the next release

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

Dear all,

I'd like to start getting things ready for the next RDKit release.
This will nominally be the Q3 2008 release, though it will probably
actually happen in October.

As part of that preparation, I'm merging changes from some of the
other branches into the trunk.

This morning I merged in the iterative chirality branch. This happened
in rev830:
http://rdkit.svn.sourceforge.net/viewvc/rdkit?view=rev&revision=830

The handling of ring stereochemistry, i.e. molecules like
C[C@H]1CC[C@H](C)CC1, is still not 100% correct, but double bonds and
chiral centers should now be right. There are some more details in
this wiki page: http://code.google.com/p/rdkit/wiki/IterativeChirality

The next merge I will do is to bring in the changes from the uBLAS branch:
http://rdkit.svn.sourceforge.net/viewvc/rdkit/branches/uBLAS_8July2008/
The idea here is to remove the use of Lapack++ from the code by
replacing it with the boost numeric bindings. There is some discussion
of this on the wiki here:
http://code.google.com/p/rdkit/wiki/GettingRidOfLapackPP
This introduces another external dependency, which I'm not 100% happy
about, but I think getting rid of Lapack++ is worth it.

I will also get most/all of the open bugs in the tracker fixed before
the release.

Please let me know if you find any problems or have suggestions or questions,
-greg