rdkit-devel — Developers information and discussion.

[Rdkit-devel] Default values for morgan fingerprints / incomplete uninstall_rdkit.sql script

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

Hi Greg,

I have seen on the wiki that you wanted to include a default value for
the morganbv_fp() function - a very easy and straightforward
implementation looks like this:

CREATE OR REPLACE FUNCTION morganbv_fp(mol,int default 2)
RETURNS bfp
AS '$libdir/rdkit'
LANGUAGE C STRICT IMMUTABLE;

I don't know when this was implemented in PostgreSQL but it works fine in 9.0+.

Another thing: The uninstall_rdkit.sql script is not complete: Some
types and operators are left, the qmol type for example.

Cheers,

Adrian

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

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

Hi Gianluca,

I finally managed to go through your proposed refactoring of the
drawing code. I like it. It definitely helps clean things up and make
the code more flexible.

I made some changes and have attached the diffs (if we have to wait
for me to figure out git correctly, we'll be waiting a long time).

We can do a round or two via git if you like, and then I'll merge the
changes back into the main svn.

Best Regards,
-greg

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

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

On Wed, Feb 2, 2011 at 5:21 AM, Greg Landrum <gre...@gm...> wrote:
> Cairo is a great toolkit for drawing, and the backend you did is
> perfectly capable. For systems that have cairo installed, it's almost
> definitely the best choice to use. However, due to its dependency on
> GTK Cairo is not easy to build and install.

I think this is not accurate, it's GTK that requires cairo, cairo
itself has very few dependencies. There are also more or less
"official" cairo builds for windows referenced from
http://cairographics.org/download, in case one do not want to mess
with compilers.


> the aggdraw canvas provides a high-quality alternative for
> generating raster images. The sping-based canvas is provided as a
> lowest-common denominator, pure-python, solution to allow images to be
> generated from the RDKit out-of-the-box (it also has the advantage of
> being able to generate pdf and svg, which aggdraw cannot).

I have nothing against keeping the various backends; I'm more in favor
of removing the rdkit/sping directory, which looks like an external
dependency much like agg, cairo or other stuff not bundled with the
rdkit tarball. On a side note, I had a brief look at the code and at
first glance there is not much there added over PIL so if you want to
provide a simple fallback when no other backend is available I'd
suggest replacing sping for a plain PIL backend.

Obviously, those are just my 0.02 :)

Cheers

G.

-- 
Gianluca Sforna

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

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

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

On Wed, Feb 2, 2011 at 12:40 AM, gi...@gm... <gi...@gm...> wrote:
> On Tue, Feb 1, 2011 at 12:51 PM, Uwe Hoffmann <uw...@fa...> wrote:
>> just some idea: what about removing sping and agg altogether ?
>
> Well, agg is not really there, you still need to get it, compile the
> library and let rdklit find it in order to use that backend. On the
> other hand, sping is embedded in the rdkit repository and I agree it
> would be better removed from the rdkit tarball.

I would rather not remove sping (or the possibility to use aggdraw),
for reasons I explained in the previous message.

> If the patches will get merged, I'd like to make more changes along these lines:
>
> 1. remove the sping code
> 2. make the backend selectable from the API
> 3. make cairo the default backend
> 4. further refactor backends (there is still much duplicated code)
> 5. last, but not least, apply more PEP8

Aside from the first bullet point, I agree with all of these.

I am (finally) back in Basel now; I'll take a look at your changes
over the next day or so and make comments.

Best Regards,
-greg

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

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

Dear Uwe,

On Tue, Feb 1, 2011 at 12:51 PM, Uwe Hoffmann <uw...@fa...> wrote:
>
> just some idea: what about removing sping and agg altogether ?
> The code will be simpler and bug reports also, because it's clear
> which backend is used.
> Questions:
> 1) I don't know if there is a feature/backend which isn't supported
>   by cairo ?
> 2) Is the cairo quality sufficient (cairo itself , not the actual
>   implementation in rdkit)?
> 3) speed (when used for many images)

Cairo is a great toolkit for drawing, and the backend you did is
perfectly capable. For systems that have cairo installed, it's almost
definitely the best choice to use. However, due to its dependency on
GTK Cairo is not easy to build and install. For systems that don't
have a cairo installation (for example, almost every machine I work
on), the aggdraw canvas provides a high-quality alternative for
generating raster images. The sping-based canvas is provided as a
lowest-common denominator, pure-python, solution to allow images to be
generated from the RDKit out-of-the-box (it also has the advantage of
being able to generate pdf and svg, which aggdraw cannot).

Best Regards,
-greg

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

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

On Tue, Feb 1, 2011 at 12:51 PM, Uwe Hoffmann <uw...@fa...> wrote:
> just some idea: what about removing sping and agg altogether ?

Well, agg is not really there, you still need to get it, compile the
library and let rdklit find it in order to use that backend. On the
other hand, sping is embedded in the rdkit repository and I agree it
would be better removed from the rdkit tarball.

If the patches will get merged, I'd like to make more changes along these lines:

1. remove the sping code
2. make the backend selectable from the API
3. make cairo the default backend
4. further refactor backends (there is still much duplicated code)
5. last, but not least, apply more PEP8


> The code will be simpler and bug reports also, because it's clear
> which backend is used.
> Questions:
> 1) I don't know if there is a feature/backend which isn't supported
>   by cairo ?

For my purposes it's perfectly fine, but of course I have no idea how
it's used outside the (few) projects I know of.

> 2) Is the cairo quality sufficient (cairo itself , not the actual
>   implementation in rdkit)?

IMHO, they are of good quality

> 3) speed (when used for many images)

did not run any benchmark, but we can exercise some code and gather
numbers. Are you referring just to the draw code or depiction+drawing?

Cheers

G.



-- 
Gianluca Sforna

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

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

[Uwe H. <uw...@fa...>]

Hi,

Am Dienstag, den 25.01.2011, 20:27 -0500 schrieb Greg Landrum:
> Dear Gianluca,
> 
> On Tue, Jan 25, 2011 at 6:34 AM, gi...@gm... <gi...@gm...> wrote:
> > I've been working lately on adding a feature to the draw code, that
> > is, highlighting atoms by an arbitrary color. This work lead me to
> > some refactoring to the Chem/Draw python code; basically, I added a
> > base canvas class that specialized classes derives to draw on
> > different backends (agg, sping, cairo).
> 
> Thanks for this. I am traveling at the moment and probably won't have
> time to take a look at it until I'm back in Basel, so I won't be able
> to comment until the middle of next week.
> 

just some idea: what about removing sping and agg altogether ?
The code will be simpler and bug reports also, because it's clear
which backend is used.
Questions:
1) I don't know if there is a feature/backend which isn't supported
   by cairo ?
2) Is the cairo quality sufficient (cairo itself , not the actual
   implementation in rdkit)? 
3) speed (when used for many images)
4) ...

regards

  Uwe

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

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

Dear Gianluca,

On Tue, Jan 25, 2011 at 6:34 AM, gi...@gm... <gi...@gm...> wrote:
> I've been working lately on adding a feature to the draw code, that
> is, highlighting atoms by an arbitrary color. This work lead me to
> some refactoring to the Chem/Draw python code; basically, I added a
> base canvas class that specialized classes derives to draw on
> different backends (agg, sping, cairo).

Thanks for this. I am traveling at the moment and probably won't have
time to take a look at it until I'm back in Basel, so I won't be able
to comment until the middle of next week.

> I'm sharing it now because the Q4 release was done, so it looks a good
> timing to eventually drop some new code in the repo and avoid the need
> to rebase my changes when you make commits to the main SVN repo.
>
> So, the code is in my github space here:
> https://github.com/giallu/rdkit/commits/draw_refactor
>
> where you can find the current status and the individual commits; if
> needed I can send a patch series on this list instead.
>
> I'm obviously open to any code review questions and willing to revise
> my changes in case you want any improvement before considering a
> merge.

I will take a look when I'm back in Basel and have a bit more time and
then get back to you with comments and suggestions.

Thanks again for the contribution,
-greg

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

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

I've been working lately on adding a feature to the draw code, that
is, highlighting atoms by an arbitrary color. This work lead me to
some refactoring to the Chem/Draw python code; basically, I added a
base canvas class that specialized classes derives to draw on
different backends (agg, sping, cairo).

I'm sharing it now because the Q4 release was done, so it looks a good
timing to eventually drop some new code in the repo and avoid the need
to rebase my changes when you make commits to the main SVN repo.

So, the code is in my github space here:
https://github.com/giallu/rdkit/commits/draw_refactor

where you can find the current status and the individual commits; if
needed I can send a patch series on this list instead.

I'm obviously open to any code review questions and willing to revise
my changes in case you want any improvement before considering a
merge.

Best regards

G.

-- 
Gianluca Sforna

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

Re: [Rdkit-devel] dependency of the chemical cartridge from PostgreSQL's GiST index

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

Hi Greg,

On Tue, Jan 11, 2011 at 9:25 PM, Greg Landrum <gre...@gm...> wrote:
>> the question is actually a bit speculative, but how much does the
>> chemical cartridge depend on the GiST index in its functionality and
>> performances? Do you think porting the cartridge to a different rdbms
>> would be potentially feasible, or is the implementation very specific
>> to PostgreSQL?
>
> This is unfortunately not an area where I have strong expertise, so
> it's a hard question for me to answer. I would guess that the methods
> used for the postgresql index could also be adapted to the indexing
> technologies used for other rdbms, but that's really a guess.

Thanks for your reply. I agree the question was quite generic and an
answer would require a high level of specialized expertise, so I hoped
some basic estimates were already available :-)

Best Regards,
Riccardo

Re: [Rdkit-devel] dependency of the chemical cartridge from PostgreSQL's GiST index

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

On Tue, Jan 11, 2011 at 9:25 PM, Greg Landrum <gre...@gm...> wrote:
>
> This is unfortunately not an area where I have strong expertise, so
> it's a hard question for me to answer. I would guess that the methods
> used for the postgresql index could also be adapted to the indexing
> technologies used for other rdbms, but that's really a guess.

Talking about this, I noticed in the rdkit overview pdf the following
bullet point:

* Database “cartridge” (PostgreSQL, sqlite coming)

So I wonder if there is anyone working (or planning to work) on that


-- 
Gianluca Sforna

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

Re: [Rdkit-devel] dependency of the chemical cartridge from PostgreSQL's GiST index

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

HI Riccardo,

On Tue, Jan 11, 2011 at 4:29 PM, Riccardo Vianello
<ric...@gm...> wrote:
>
> the question is actually a bit speculative, but how much does the
> chemical cartridge depend on the GiST index in its functionality and
> performances? Do you think porting the cartridge to a different rdbms
> would be potentially feasible, or is the implementation very specific
> to PostgreSQL?

This is unfortunately not an area where I have strong expertise, so
it's a hard question for me to answer. I would guess that the methods
used for the postgresql index could also be adapted to the indexing
technologies used for other rdbms, but that's really a guess.

Best Regards,
-greg

[Rdkit-devel] dependency of the chemical cartridge from PostgreSQL's GiST index

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

Hi Greg,

the question is actually a bit speculative, but how much does the
chemical cartridge depend on the GiST index in its functionality and
performances? Do you think porting the cartridge to a different rdbms
would be potentially feasible, or is the implementation very specific
to PostgreSQL?

Thank you in advance,

Best regards,
Riccardo

Re: [Rdkit-devel] postponing the Q4 2010 release

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

I just tested the new Windows binary and it worked perfectly for me.  I
haven't tested building the new code bundle, but the previous version was
fine.  I'll test the new one later today.

-Kirk






On Thu, Jan 6, 2011 at 11:09 PM, Greg Landrum <gre...@gm...>wrote:

> Dear all,
>
> Since I've been slow getting a working windows binary of the Q4 2010
> beta up, and since there have been a couple of last minute bug fixes,
> I'm going to do an additional beta version and shift the planned
> release until next week.
>
> I just uploaded what should be a functioning windows binary for python 2.6:
> http://rdkit.googlecode.com/files/RDKit_2010_12_1beta3.win32.zip
> and I will try to get an updated tgz up this morning as well.
>
> Apologies for the delay,
> -greg
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>

[Rdkit-devel] postponing the Q4 2010 release

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

Dear all,

Since I've been slow getting a working windows binary of the Q4 2010
beta up, and since there have been a couple of last minute bug fixes,
I'm going to do an additional beta version and shift the planned
release until next week.

I just uploaded what should be a functioning windows binary for python 2.6:
http://rdkit.googlecode.com/files/RDKit_2010_12_1beta3.win32.zip
and I will try to get an updated tgz up this morning as well.

Apologies for the delay,
-greg

Re: [Rdkit-devel] RDkit git repository

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

On Wed, Dec 29, 2010 at 5:36 PM, gi...@gm... <gi...@gm...> wrote:
> Just in case someone wants to hack on rdkit and is comfortable with
> git, I'm mirroring the official SVN repository on github:
> https://github.com/giallu/rdkit
>
> so you don't need to clone the SVN repo, which is a bit time and
> bandwidth consuming.
>
> Right now, I'm syncing the two repos manually, but if needed I could
> run a cron job to have it regularly updated.

Nice.
Guess I should probably learn how to use git one of these days.

-greg

[Rdkit-devel] RDkit git repository

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

Just in case someone wants to hack on rdkit and is comfortable with
git, I'm mirroring the official SVN repository on github:
https://github.com/giallu/rdkit

so you don't need to clone the SVN repo, which is a bit time and
bandwidth consuming.

Right now, I'm syncing the two repos manually, but if needed I could
run a cron job to have it regularly updated.

Cheers

G.

-- 
Gianluca Sforna

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

Re: [Rdkit-devel] moving towards the Q4 2010 release

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

On Tue, Dec 28, 2010 at 5:18 PM, Greg Landrum <gre...@gm...> wrote:
> I'd like to get things wrapped up for a Q4 2010 (2010_12_01 in the new
> numbering scheme) release of the RDKit.
>
> I will tag a beta of the release on Thursday and try to target doing
> the actual release sometime in the first or second week of January.

Great, I will try to timely build RPMs for this release for an easier
and wider testing.

>
> If you have last-minute bug reports, please get them in.

Nothing here, though I'm working on some changes in the python code,
possibly material for the Q1 2011 release.

Thank you

G.

-- 
Gianluca Sforna

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

[Rdkit-devel] moving towards the Q4 2010 release

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

Dear all,

I'd like to get things wrapped up for a Q4 2010 (2010_12_01 in the new
numbering scheme) release of the RDKit.

I will tag a beta of the release on Thursday and try to target doing
the actual release sometime in the first or second week of January.

If you have last-minute bug reports, please get them in.

Thanks,
-greg

Re: [Rdkit-devel] Python vs C++ exceptions

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

On Mon, Dec 13, 2010 at 7:09 PM, gi...@gm... <gi...@gm...> wrote:
> On Mon, Dec 13, 2010 at 5:14 PM, Greg Landrum <gre...@gm...> wrote:
>> #--------
>>
>> supplier = Chem.SDMolSupplier('foo.sdf')
>> for mol in supplier:
>>  if mol is None: continue
>>  #otherwise do whatever you need to do with the molecule.
>
> Thanks, that's what I ended up doing.
>
> If you think it's technically doable and see value in explicitly
> forwarding the exception, I could report this in the tracker,
> otherwise, let's move on :-)

I think having the molecule construction functions return None instead
of throwing exceptions is a useful feature: it really simplifies
writing client code to not have to worry about catching exceptions
every time you try and build a molecule. There would, on the other
hand, be some value in being able to more easily programmatically
determine where an error occurred while processing a molecule. This is
probably doable and is certainly worth thinking about.

-greg

Re: [Rdkit-devel] Python vs C++ exceptions

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

On Mon, Dec 13, 2010 at 5:14 PM, Greg Landrum <gre...@gm...> wrote:
> #--------
>
> supplier = Chem.SDMolSupplier('foo.sdf')
> for mol in supplier:
>  if mol is None: continue
>  #otherwise do whatever you need to do with the molecule.

Thanks, that's what I ended up doing.

If you think it's technically doable and see value in explicitly
forwarding the exception, I could report this in the tracker,
otherwise, let's move on :-)


-- 
Gianluca Sforna

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

Re: [Rdkit-devel] Python vs C++ exceptions

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

HI Gianluca,

On Mon, Dec 13, 2010 at 3:50 PM, gi...@gm... <gi...@gm...> wrote:
> While reading some SD molecules in python, I've got on the console
> messages like:
>
> [15:18:47] Explicit valence for atom # 0 N, 4, is greater than permitted
> [15:18:47] ERROR: Could not sanitize molecule ending on line 48
> [15:18:47] ERROR: Explicit valence for atom # 0 N, 4, is greater than permitted
>
> Then my script breaks (rightfully) when accessing the structure which
> is not loaded
>
> Traceback (most recent call last):
>  File "importdata.py", line 23, in <module>
>    molecule = Chem.MolToSmiles(sup[0])
> Boost.Python.ArgumentError: Python argument types in
>    rdkit.Chem.rdmolfiles.MolToSmiles(NoneType)
> did not match C++ signature:
>    MolToSmiles(RDKit::ROMol {lvalue} mol, bool isomericSmiles=False,
> bool kekuleSmiles=False, int rootedAtAtom=-1)
>
>
> I've checked the C++ code and it seems the error comes from the
> calcExplicitValence() method in Code/GraphMol/Atom.cpp
>
> Now my question is: since the method throws MolSanitizeException(msg);
> maybe there should be a way from python to catch it?

The errors are actually already caught in the python wrapper. You're
seeing the error message so that you know what happend, but the
exception doesn't make it back to python. What makes it back is a None
instead of a molecule. If you look at the error message above you will
see that you have called MolToSmiles with a NoneType.

This is very easy to test for:

#--------

supplier = Chem.SDMolSupplier('foo.sdf')
for mol in supplier:
  if mol is None: continue
  #otherwise do whatever you need to do with the molecule.

#--------

Best regards,
-greg

[Rdkit-devel] Python vs C++ exceptions

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

While reading some SD molecules in python, I've got on the console
messages like:

[15:18:47] Explicit valence for atom # 0 N, 4, is greater than permitted
[15:18:47] ERROR: Could not sanitize molecule ending on line 48
[15:18:47] ERROR: Explicit valence for atom # 0 N, 4, is greater than permitted

Then my script breaks (rightfully) when accessing the structure which
is not loaded

Traceback (most recent call last):
  File "importdata.py", line 23, in <module>
    molecule = Chem.MolToSmiles(sup[0])
Boost.Python.ArgumentError: Python argument types in
    rdkit.Chem.rdmolfiles.MolToSmiles(NoneType)
did not match C++ signature:
    MolToSmiles(RDKit::ROMol {lvalue} mol, bool isomericSmiles=False,
bool kekuleSmiles=False, int rootedAtAtom=-1)


I've checked the C++ code and it seems the error comes from the
calcExplicitValence() method in Code/GraphMol/Atom.cpp

Now my question is: since the method throws MolSanitizeException(msg);
maybe there should be a way from python to catch it?

-- 
Gianluca Sforna

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

Re: [Rdkit-devel] cairo backend not loadable

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

On Wed, Dec 1, 2010 at 7:19 PM, Greg Landrum <gre...@gm...> wrote:
> The better results ([2]) come from using aggdraw, which you'll need to
> download and build separately (instructions in the wiki). Aggdraw
> really makes for nice pictures.

Some update on this. I double checked the code and it seems to me the
example in the wikia page I linked was done by the cairo backend,
because the "MolToFile" function used to render the depiction is not
using the agg backend at all.

In fact, I can now reproduce the same quality here, except for the
font which is, in my case, a Serif one; I guess I will be able to fix
this one as well before moving on.

Cheers

G.



-- 
Gianluca Sforna

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

Re: [Rdkit-devel] cairo backend not loadable

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

On Wed, Dec 1, 2010 at 7:19 PM, Greg Landrum <gre...@gm...> wrote:

> The better results ([2]) come from using aggdraw, which you'll need to
> download and build separately (instructions in the wiki). Aggdraw
> really makes for nice pictures.

I suspected that was the case. I checked Fedora repositories and it
seems we have agg but not python-aggdraw so I tried to build the 1.1
release which failed.

Now, I could go on and try to debug/fix the build but I realized both
agg and aggdraw development seem stale enough to suggest sticking the
cairo way.

I'll probably spend some time to see how the cairo output can be
improved to match agg; if anything I'll learn more about rdkit code in
the process...

Thanks again

G.

-- 
Gianluca Sforna

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