[chemfp] chemfp-1.0 on Windows

[Andrew Dalke]

Hi Chris,

  Thanks for trying out the package.

On Sep 27, 2011, at 10:17 AM, Chris Morley wrote:

> The installation is fine by:

> setup.py install

> with only a few warnings from the Visual Studio compiler, including an unrecognized compiler option -O3.


Grrr. My Unix experience lead me to falsely believe that every compiler understood -O3.

Well, that's an easy fix. In the next few weeks or so I'll work on making a pre-built distribution for Windows.

I'm tempted as well to make a GUI version with Qt ... although I am not a GUI programmer.


> Scripts like sdf2fps are obviously not aimed at Windows and do not work directly in a command window, but they do if prefaced by "python".


That is unexpected. I thought that the Python installer took care of things so that those scripts would work correctly under Windows. I'll have to look into that.


> I have not found how to do this from an arbitrary data folder - setting PYTHONPATH to various likely folders was unsuccessful. The installation provides sdf2fps.py, etc. in C:\Python27\Lib\site-packages\chemfp\commandline. Should I be using these?


The scripts "sdf2fps", "ob2fps", "simsearch", and so on are simple wrappers which call the corresponding chemfp\commandline\sdf2fps.py, etc. scripts. They also suppress the standard Python support for control-break of showing the stack trace where the break occurred.

Setting the PYTHONPATH shouldn't make a difference here.

I've not tested this but if you want to get the command-line scripts working then I think you can rename them so they have the ".py" extension. Of course you'll then need to type "sdf2fps.py".

This may require that your PATHEXT environment variable includes .py files. That's under

  Control Panel -> System -> Advanced -> Environment Variables

Researching some more,
  http://www.voidspace.org.uk/python/articles/command_line.shtml#pathext
says that if that directory is on your PATH then you don't need the .py suffix.


I will need to research this some more to get a good Windows solution.



> A "k-nearest neighbor search" with simsearch worked ok, as did ob2fps. But anything involving arena.py crashes:


  That is quite strange. Noel reported something like this, but I thought
I had fixed that. I presume it's something to do with differences in how
the MS and GNU C compilers allocate/deallocate memory, and that I have a
free'd block of memory which I'm still using.

  It's somewhat unexpected that the k-nearest search doesn't have a problem
while the threshold one does. That's probably because there's a size-based
rule in place. If there are only a couple of queries then it's not worthwhile
to read the entire list of targets into memory. I'm going to guess that
your k-nearest search only had a few queries in it.


> I admire your patience in working round all the quirks in the OpenBabel code!


Thanks, but it wasn't so bad. Most of it was because I want to
support extra metadata (fingerprint sizes, fingerprint type version number,
and so on) which aren't in Open Babel proper.

Cheers,


				Andrew
				dalke at dalkescientific.com