Marc Colosimo | 11 May 2004 18:04
Picon
Favicon

Re: Re: Work towards getting KDTree compiling


On May 10, 2004, at 4:17 PM, Brad Chapman wrote:

> Hi Michiel;
>
> [mingw32]
>
[snip]
>
> [Sun]
>
[snip]
>
> [Mac OS X]
>>> Hmmm. How do they crash? Just a core dump? Can you attach gdb and
>>> see anything? Also, is this with gcc? What versions? For the record,
>>> I'm compiling with gcc version 2.95.4 and 3.3.3 without any
>>> problems.
>>>
>>
>> I'm not sure if this will help much but this is what I get from gdb:
>>
>>>>> from Bio.KDTree import *
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
>> Reading symbols for shared libraries . done
(Continue reading)

Michiel Jan Laurens de Hoon | 12 May 2004 04:50
Picon

Re: Re: Work towards getting KDTree compiling

Marc Colosimo wrote:
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> 0x8fe0cc18 in __dyld_is_symbol_coalesced ()
>>> (gdb)
>>
>>
>> Bleah. Some kind of memory leak when loading the libraries -- I have
>> zero idea what that means or how to fix it. If it compiles decently,
>> then I'll leave it right now, and just hope that some Mac OS people
>> can come up with a reason/solution for this. Anyone else with OS X
>> can confirm?
>>
>> Otherwise, well -- I have no idea what to do.
>>
> 
> With both the Mac and  fink version of python, it works fine for me (two 
> different systems, both 10.3.3). Did you install some  other odd python 
> package or gcc?

I compiled Python from souce on Mac OS X, using gcc. Personally I don't need to 
use the KDTree and Affy modules right now, so don't worry too much about it. But 
other users may run into the same problem.

--Michiel.

--

-- 
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
(Continue reading)

Michiel Jan Laurens de Hoon | 13 May 2004 08:18
Picon

Re: Re: Work towards getting KDTree compiling

Brad Chapman wrote:
> Well, one thing at a time. At least the compilation works :-).
> Thanks for putting up with this remote debugging process.
> 
> First thing about your traceback -- it looks like the bdist_wininst
> is using the Microsoft Visual C++ compiler -- at least that is where
> the traceback is coming from. Is that, uh, strange, or normal
> behavior?

That is probably OK. The bdist_wininst command creates an installer from the 
compiled and linked files (created by the build command), but doesn't do any 
compiling itself.

> Secondly, it should support compiling on msvc regardless, so I tried
> to modify the setup.py to do this. Basically, msvc uses a different
> interface to specify the compilers, which I tried to take into
> account. I also disabled C++ compilation on msvc until we have
> someone with the compiler willing to get it all worked out.

Sorry, no luck. With the Microsoft Visual C++ compiler, I get the following 
error when running python setup.py build:

C:\Program Files\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo /INCREME
NTAL:NO /LIBPATH:c:\Python23\libs /LIBPATH:c:\Python23\PCBuild /EXPORT:initclust
er build\temp.win32-2.3\Release\Bio/Cluster/clustermodule.obj build\temp.win32-2
.3\Release\Bio/Cluster/cluster.obj build\temp.win32-2.3\Release\Bio/Cluster/ranl
ib.obj build\temp.win32-2.3\Release\Bio/Cluster/com.obj build\temp.win32-2.3\Rel
ease\Bio/Cluster/linpack.obj /OUT:build\lib.win32-2.3\Bio\Cluster\cluster.pyd /I
MPLIB:build\temp.win32-2.3\Release\Bio/Cluster\cluster.lib
    ?????? build\temp.win32-2.3\Release\Bio/Cluster\cluster.lib ????????? build\t
(Continue reading)

Brad Chapman | 13 May 2004 15:16
Picon
Favicon

Re: Re: Work towards getting KDTree compiling

Hi Michiel;

[bsdist_wininst plus msvc]
> Sorry, no luck. With the Microsoft Visual C++ compiler, I get the following 
> error when running python setup.py build:
[...]
> AttributeError: MSVCCompiler instance has no attribute 'compiler_cxx'
[...]
> Using mingw32, the build command runs correctly (skipping the C++ modules), 
> but the bdist_wininst command fails:
> $ /cygdrive/c/Python23/python setup.py bdist_wininst
[...]
> AttributeError: MSVCCompiler instance has no attribute 'compiler_cxx'

Thanks for the tracebacks. Grrrr, I am a moron -- my fix to skip
compilation on msvc didn't also fix trying to assign a C++ compiler,
before skipping the compilation completely. Ugh, my fault.

The problem here is that while the semi-standard compiler_so and
compiler_cxx attributes are supported on a number of compilers, msvc
uses it's own setup (it just has a cc, which I think supports C++
but am not really into testing for right now, so we are just
skipping it).

But yes, I've checked in yet another change. I am praying that this
will finally let everything compile and build windows installers and
all those good things, so that I can stop bothering you with this
and we can be all good and happy and ready for release time.

Thanks again for all your patience on this. Please do let me know if
(Continue reading)

IPSI conference | 13 May 2004 20:50

Invitation to Montenegro and Sweden vip/bb

Dear Potential Speaker:

This is an invitation for you to attend two IPSI BgD multidisciplinary and interdisciplinary
conferences, one in Montenegro, and one in Sweden, as follows:

Sveti Stefan, MONTENEGRO (arrival: 2.10.2004. departure 9.10.2004.)
Keynote: Dr. de Gennes, Nobel Laureate, France
Contact: vipforum <at> internetconferences.net
Deadlines: May 31 2004 (abstract) + June 30 2004 (full paper)

Stockholm, SWEDEN (arrival: 24.9.2004. departure: 26.9.2004.)
Contact: stockholm <at> internetconferences.net
Deadlines: May 15 2004 (abstract) + June 15 2004 (full paper).
Keynote: Dr. Dino Karabeg, University of Oslo, Norway

If you like to obtain more information on both conferences, please reply to this email. All IPSI BgD
conferences are non-profit! They take place in the leading hotels of the world, and are aimed at bringing
together the elite of the world science.

Topics of interest include, but are not limited to: Internet, Computer Science and Engineering,
Management and Business Administration, Education, e-Medicine, Electrical Engineering,
Bioengineering, Environment Protection, and e-Economy.

Sincerely Yours,

Prof. Veljko Milutinovic, Chairman

PS - If you plan to submit an abstract/paper, let us know immediately. If you are not able to attend now, but
you like to be informed about the future IPSI BgD conferences, please let us know. If you do not like to
receive future invitations, let us know, as well!
(Continue reading)

Michiel Jan Laurens de Hoon | 14 May 2004 04:25
Picon

Re: Re: Work towards getting KDTree compiling

Brad Chapman wrote:
> But yes, I've checked in yet another change. I am praying that this
> will finally let everything compile and build windows installers and
> all those good things, so that I can stop bothering you with this
> and we can be all good and happy and ready for release time.

The latest version works with Microsoft Visual Studio and the mingw32 compiler. 
Good job!

Some short comments:

o) The source in Bio/PDB/mmCIF/lex.yy.c uses some Unix-specific commands from 
unistd.h. Microsoft's compiler barfs on these, the mingw32 compiler does not. It 
may be a good idea anyway to check if the mingw32-compiled version actually works.

o) Recently I found out that the official Numerical Python version is now 
numarray. The Numeric module is now unsupported (see 
http://www.pfdubois.com/numpy). We'll need to decide if Biopython is going over 
to numarray, or whether to stick with Numeric for now. Some modifications will 
be needed in the Python and C code if we start using numarray.

--Michiel.

--

-- 
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
(Continue reading)

Thomas Hamelryck | 14 May 2004 08:58
Picon
Favicon

Re: Re: Work towards getting KDTree compiling


> o) The source in Bio/PDB/mmCIF/lex.yy.c uses some Unix-specific
> commands from  unistd.h. Microsoft's compiler barfs on these, the
> mingw32 compiler does not. It  may be a good idea anyway to check if
> the mingw32-compiled version actually works.

lex.yy.c is a lex-generated file. I presume it will look different when
generated on a windows system. lex.yy.c is part of the distribution
because (a) not everyone has lex installed and (b) it's not clear to me
how to fire up lex from distutils. I have no objections if you want to
comment this out in setup.py.

> o) Recently I found out that the official Numerical Python version is
> now  numarray. The Numeric module is now unsupported (see
> http://www.pfdubois.com/numpy). We'll need to decide if Biopython is
> going over  to numarray, or whether to stick with Numeric for now. Some
> modifications will  be needed in the Python and C code if we start
> using numarray.

Good point. We should indeed move to numarray, I think, though we might
wait some months until numarray is more widely used.
Cheers & thanks for the C++ related work,

--

-- 
Thomas Hamelryck
Bioinformatik centret
København Universitet
Universitetsparken 15
Bygning 10
DK-2100 København Ø
(Continue reading)

Brad Chapman | 14 May 2004 17:13
Picon
Favicon

Re: Re: Work towards getting KDTree compiling

Michiel and Thomas;

> The latest version works with Microsoft Visual Studio and the mingw32 
> compiler. Good job!

Sweet. Thanks for all your work helping to debug this. That's good
enough for me for now -- making a release with what we've got -- and
we'll deal with these next problems for the upcoming release. 

> > o) The source in Bio/PDB/mmCIF/lex.yy.c uses some Unix-specific
> > commands from  unistd.h. Microsoft's compiler barfs on these, the
> > mingw32 compiler does not. It  may be a good idea anyway to check if
> > the mingw32-compiled version actually works.
> 
> lex.yy.c is a lex-generated file. I presume it will look different when
> generated on a windows system. lex.yy.c is part of the distribution
> because (a) not everyone has lex installed and (b) it's not clear to me
> how to fire up lex from distutils. I have no objections if you want to
> comment this out in setup.py.

What kind of work would be involved with generating this lex file on
Windows? I know next to nothing about lex, but if we could get
different copies that work on Windows and Unix then we could again
build up the extension in the setup.py file so it would compile on
with all compilers.

> > o) Recently I found out that the official Numerical Python version is
> > now  numarray. The Numeric module is now unsupported (see
> > http://www.pfdubois.com/numpy). We'll need to decide if Biopython is
> > going over  to numarray, or whether to stick with Numeric for now. Some
(Continue reading)

Jeffrey Chang | 14 May 2004 17:47

Re: Re: Work towards getting KDTree compiling

On May 14, 2004, at 11:13 AM, Brad Chapman wrote:
> I'd agree that a move to numarray makes the most sense. We need to
> move in the direction development is going. I'd like to make this
> something we can plan to do soon-ish so it can be tested and ready
> for the next release. Right now, it looks like the following code
> would need to be migrated:
>
> -> LogisticRegression -- Jeff?
> -> MarkovModel -- Jeff?
> -> NaiveBayes -- Jeff?
> -> distance -- Jeff?
> -> kNN -- Jeff?

Yes, these are mine, and I can upgrade them to use numarray.

> What I really don't want is to make people download both Numeric and
> numarray to use Biopython, so I'd hope to make a coordinated switch
> between releases. If we decide to do this, we can split up the tasks
> and have a go at it.

Sure -- let me know the plans!

Jeff
Thomas Hamelryck | 15 May 2004 11:55
Picon
Favicon

Epydoc markup


Hi Brad,

First of all - thanks for shipping 1.30! Nice job!

Small remark: I noticed that the Epydoc markup language
in the doc strings of the Bio.PDB module is not translated into
HTML in the documentation on the website. If I run Epydoc locally
everything looks fine, though. Any idea what could be wrong? BTW,
is there a way for the Biopython developers to update the documentation
on the website directly? Might be useful.

Epydoc is a great tool, BTW. It was a very good idea to
introduce it, IMO.

Cheers,

-Thomas

Gmane