Hi,
is there any reason that ResidueTypes and AtomTypes are defined as static variables, rather than enum?
what is the best way to map between ResidueType and the PDB residue name string and the same for atoms?
thanks! Dina
On Dec 16, 2008, at 11:40 AM, Dina Schneidman wrote:
> Hi, > > is there any reason that ResidueTypes and AtomTypes are defined as > static variables, rather than enum? Having them as static variables means you have a proper type associated with the identifiers, which is kind of nice. It also means that you can add your own residue names and have the mapping to a string accessible to i/o code.
> > > what is the best way to map between ResidueType and the PDB residue > name string and the same for atoms? ResidueType("pdbname") should work for now. Same for AtomType.
I think I should add a function residue_type_from_pdb_name and atom_type_from_pdb_name to provide a cleaner and clearer route. I'll check in such code shortly. > > > thanks! > Dina > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
no need to add, works just fine. thanks!
On Tue, Dec 16, 2008 at 11:48 AM, Daniel Russel drussel@gmail.com wrote:
> > On Dec 16, 2008, at 11:40 AM, Dina Schneidman wrote: > > Hi, >> >> is there any reason that ResidueTypes and AtomTypes are defined as static >> variables, rather than enum? >> > Having them as static variables means you have a proper type associated > with the identifiers, which is kind of nice. It also means that you can add > your own residue names and have the mapping to a string accessible to i/o > code. > > >> >> what is the best way to map between ResidueType and the PDB residue name >> string and the same for atoms? >> > ResidueType("pdbname") should work for now. Same for AtomType. > > I think I should add a function residue_type_from_pdb_name and > atom_type_from_pdb_name to provide a cleaner and clearer route. I'll check > in such code shortly. > >> >> >> thanks! >> Dina >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
On Dec 16, 2008, at 11:56 AM, Dina Schneidman wrote:
> no need to add, works just fine. Constructing it directly is slightly unsafe as a few method assume that the keys are initialized in a given order (the problem is unlikely to arise, so go ahead until the patch is committed).
I stuck a patch in kernel/doc/patch to added methods to safetly construct keys from PDB strings (it requires a minor change to Key.h). The new methods check to make sure the atom and residue names are standard ones.
> > thanks! > > On Tue, Dec 16, 2008 at 11:48 AM, Daniel Russel drussel@gmail.com > wrote: > > On Dec 16, 2008, at 11:40 AM, Dina Schneidman wrote: > > Hi, > > is there any reason that ResidueTypes and AtomTypes are defined as > static variables, rather than enum? > Having them as static variables means you have a proper type > associated with the identifiers, which is kind of nice. It also > means that you can add your own residue names and have the mapping > to a string accessible to i/o code. > > > > > what is the best way to map between ResidueType and the PDB residue > name string and the same for atoms? > ResidueType("pdbname") should work for now. Same for AtomType. > > I think I should add a function residue_type_from_pdb_name and > atom_type_from_pdb_name to provide a cleaner and clearer route. I'll > check in such code shortly. > > > thanks! > Dina > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Dear IMP developers,
Since I check out the latest SVN repository of version 1041, I'm getting these error messages when I do "scons".
It worked fine before 1041 version. I'm working on Macbook Pro, with scons version 1.0.1
Anybody has an idea of this?
Thanks!
At revision 1041.
[sjkim:~/imp2]$ scons scons: Reading SConscript files ... Checking whether compiler supports -fvisibility...yes Checking for MODELLER...(cached) /Users/sjkim/modeller Checking for Boost version >= 1.30... /opt/local/include Checking for CGAL ...no Checking for EMBED...(cached) not found TypeError: 'function' object is unsubscriptable: File "/Users/sjkim/imp2/SConstruct", line 58: SConscript('modules/SConscript') File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 596: return apply(method, args, kw) File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 533: return apply(_SConscript, [self.fs,] + files, subst_kw) File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 256: exec _file_ in call_stack[-1].globals File "/Users/sjkim/imp2/modules/SConscript", line 4: description='Interface to the EMBED package.') File "/opt/local/lib/scons-1.0.1/SCons/Environment.py", line 183: return apply(self.method, nargs, kwargs) File "/Users/sjkim/imp2/tools/imp_module.py", line 367: return env.SConscript('%s/SConscript' % module, exports='env') File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 533: return apply(_SConscript, [self.fs,] + files, subst_kw) File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 256: exec _file_ in call_stack[-1].globals File "/Users/sjkim/imp2/modules/em/SConscript", line 24: SConscript('pyext/SConscript') File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 596: return apply(method, args, kw) File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 533: return apply(_SConscript, [self.fs,] + files, subst_kw) File "/opt/local/lib/scons-1.0.1/SCons/Script/SConscript.py", line 256: exec _file_ in call_stack[-1].globals File "/Users/sjkim/imp2/modules/em/pyext/SConscript", line 7: e.IMPPythonExtension('em.i') File "/opt/local/lib/scons-1.0.1/SCons/Environment.py", line 183: return apply(self.method, nargs, kwargs) File "/Users/sjkim/imp2/tools/imp_module.py", line 234: swigcom[0] = swigcom[0].replace('$SWIG ', repl)
Seung Joong Kim wrote: > Since I check out the latest SVN repository of version 1041, I'm > getting these error messages when I do "scons".
Should be fixed in r1042. Let me know if things are still broken after an update.
Ben
participants (4)
-
Ben Webb -
Daniel Russel -
Dina Schneidman -
Seung Joong Kim