> As for just a pdb reader, since it only reads atoms and put then in > IMP we can have in the meantime even a few readers and converge to > something as time passes. > I would recommend that we have a few test cases that check main > functionalities ( multiple positions, HETATMs, chains, > symmetry ..... ) - so that we can have some objective criteria for > a final decision. Agreed. As we want more from the PDB reader we write more involved test cases and evolve the backend to support what we need. No reason to jump to a full feature set if that is not easy.
> I can also offer considering c++ code written in my lab in TA > which was used for structural alignment and docking procedures - so > it was debugged well. Sounds good. The more the merrier :-)
> > On Nov 14, 2007, at 6:53 PM, Daniel Russel wrote: > >> I think Ben and I have a disagreement about the significance of >> picking a PDB reader at this point. As I see it, any PDB reading >> should be hidden behind some very general interface (I have a >> proposal using the MolecularHierarchyDecorator). As a result, the >> code doing the actually reading doesn't matter too much and so we >> shouldn't worry now about whether we have the perfect solution. We >> should pick something easy which does what we want and minimizes the >> amount of effort people have to make. > >> >> When someone needs something more, we can either modify our current >> solution or chuck it and write an adaptor to someone else's code. >> Writing these adaptors is trivial given a backend which supports all >> we want. >> >> I picked my pdb reader since it is small and so can be stuck in the >> with rest of imp so that no one has to worry about installing >> external libraries and it does what I want, namely give me a >> hierarchy for proteins and a bond information. >> >> The alternatives I have looked at so far are >> >> BALL- probably dead although it took a breath this morning >> >> the one Frido sent- I don't see how to get bonds out of it, but >> otherwise fine. The documentation really sucks, so I might be missing >> something. >> >> a few random other C and C++ ones all of which are either embedded in >> a large library, suck, don't give me bonds etc. >> >> One area I haven't looked is the in python only readers. There may be >> some good ones there. >> >>> >>> If it's an external library, it should be a dependency, not part of >>> IMP. >> It depends. Having obscure external dependencies is a good way to >> piss off people who have to install your software. It is a tradeoff. >> I would say that we shouldn't depend on anything not in fedora or >> fedora-extras for something basic like this. >>> >> >>> Hao's project absolutely requires HETATMs, for example. And I >>> don't share your concern for runtime checks, since PDB reading is >>> not >>> performance-critical. >> My concern on checks was not for efficiency, it was for correctness. >> Depending on strings is poor as capitalization or abbreviation errors >> don't easily get caught. >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev