Ben Webb wrote: > Forwarded to the list for reference. > > -------- Original Message -------- > Subject: PDB lib > Date: Tue, 13 Nov 2007 16:06:24 -0800 > From: Daniel Russel drussel@gmail.com > Reply-To: drussel@salilab.org > To: Ben Webb ben@salilab.org > References: 3682E173-8139-44FE-8BB0-C2739807D71E@salilab.org > 473A0947.9030501@salilab.org 473A09AD.2000603@gmail.com > 473A31BC.1060000@salilab.org > > >> 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 :-) > what about that one? seems to be the open source default in crystallography these days. they have good funding from electron microscopy as well.
can also be accessed from python:
http://www.phenix-online.org/documentation/what-is-phenix.htm > 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. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >