[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IMP-dev] [Fwd: PDB lib]



Forwarded to the list for reference.

-------- Original Message --------
Subject: PDB lib
Date: Tue, 13 Nov 2007 16:06:24 -0800
From: Daniel Russel <>
Reply-To: 
To: Ben Webb <>
References: <> <> <> <>


At any rate, this PDB reader stuff needs to be discussed on imp-dev before we proceed. For example, what's wrong with the BALL stuff you were playing with before?
BALL is dead. No activity on email list. No response to bugs. No move to
actually document their newest version even though it was released a
year ago. I don't think we want to tie ourselves to it. Sure we can take
it to IMP dev. No one else seems to care much :-)

I have looked around and asked around and couldn't find any decent PDB
readers (in C or C++) which are not buried in some huge project.
Why can't we link against this PDB library, rather than cut-and-pasting thousands of lines of code?
The nice thing about it is that it is small and simple and mine so we
can just ship it along with IMP and not worry about dependencies, name
collisions etc. I don't want people to have to get another library from
somewhere else, hence my desire to put a copy into imp svn. Soon enough
the lib will make it to fedora extras (whenever the next CGAL release
is) so we could potentially just use that.
Should the kernel include a PDB reader anyway?
It doesn't matter if it is in the kernel or a separate lib that is
brought along, especially since we are using dynamic linking (so the
library can be pulled in my libimp). Everyone seems to want a PDB
reader, including me so we need one somewhere.
My concerns are 1. it'll be a maintenance nightmare to fork this PDB library,
Not at all. It doesn't actually need forking other than changing
#include <CGAL/PDB to #include <IMP/PDB to avoid stomping on things. I
really with there were some way to parameterize such things.

It was written to be self-contained, I just got sloppy with the last few
changes so I had to fix those this morning).

2. it's LGPL so we can't include it in IMP without being forced to adopt LGPL (only link against it)
Why would we want to do more than link against it? Anyway, changing the
license is easy. It was initially free, I just changed the license
recently because much of the rest of CGAL is LGPL.
and 3. from a brief reading, it looks like a not-very-good PDB library anyway (hard-coded atom names - what's with that?)
Well, it is either that or use strings which pushes the checks to
runtime rather than compile time. Adding to an enum and recompiling is
trivial (and adding a constant externally works just as well for must
purposes). Checking everywhere than an object falls in a small set of
allowed strings is hard (especially if you can't specify that set of
strings anywhere). BALL has hardcoded atoms for that matter (just a lot
more of them :-)

Anyway, I am a fan of it (as I should be :-) And since our backups are
rather less than I thought, the ball code got lost with the constant
rechecking out of IMP.