Merge pull request #2221 from RosettaCommons/roccomoretti/fixedarray_static_compile_fix
Fix static mode GCC 4.9 error in fixedsizearray1.hh
GCC isn't liking using a Size as a C-style array index in this situation. Do an explicit conversion to int first.
Thanks to Aliza Rubenstein for pointing out the issue.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2212 from RosettaCommons/sergey/binder
1. Updating Binder to support binding for template member functions.
2. Adding support for PyRosetta serialization build.
3. Adding procedure to explicitly instantiate serialization save/load function during binding generation phase.
4. Small refactoring to Rosetta source to allow easier extraction of instantiation macros.
5. Adding support for Testing Server serialization build.
6. Adding support for std::shared_ptr<void> types.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2219 from RosettaCommons/everyday847/hotfix_integration_tests
Hotfix integration tests
Andy Watkins 7 years Note that these failures to run are entirely unique to the mac/release platform. I'd been on a very different branch on my only available mac, so the rebuild will take a while. I'll figure out what the issue is, but in the meantime your regularly scheduled release builds on clusters and debug builds on your workstations will be a-okay.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2214 from RosettaCommons/everyday847/atom_alias_lcaa
ATOM_ALIAS lines for L-CAAs
Andy Watkins 7 years I unbeautified! My bad. I will fix this with a minor PR I'll merge today anyway.
Andy Watkins 7 years Notably, there are a lot of broken -- as in non-running -- integration tests here. That's odd, since they didn't come up in testing on commits. I'll fix this up...
Vikram K. Mulligan 7 years In those cases where there are trajectory changes, is it just that Rosetta is now able to recognize atoms in the input PDB that it was rebuilding before? I checked a few of mine and it seems that's the case, but have you gone through all of the rest carefully?[list]
Merge pull request #2141 from RosettaCommons/vmullig/xsd_types_for_taskoperations
Add an XSD type for comma-separated task operation lists
It is useful for a potential GUI to be able to differentiate between a Rosetta module that takes a general string and a Rosetta module that takes a comma-separated list of pre-defined task operations. This adds an XSD type for task operation lists separated by commas.
Tasks:
- [x] Add the type (xsct_task_operation_comma_separated_list).
- [x] Update the utility functions in protocols/rosetta_scripts that parse task operations lists to use xsct_task_operation_comma_separated_list instead of xs_string.
- [x] Find and update any additional movers, filters, etc. that take comma-separated task operations lists, being mindful of those that might take multiple lists.
- [x] Check in core.
- [x] Check in protocols.
- [x] Check in devel.
- [x] Check in apps.
- [x] Check tests.
- [x] Think about the case of something that might take a _single_ task operation.
- ~~Think about the case of things that take task factories.~~ --> Put off for a future pull request.
- [x] Also: cherry-pick in some more utility functions in utility/xsd_util/.
- [x] Beauty.
Ultimately, I'll do this for things that take residue selectors, score functions, movers, filters, etc.
**Note:** This does _not_ add any GUI elements to the Rosetta codebase. This is just utility code that will make GUI development easier down the road.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2208 from RosettaCommons/weitzner/match_xml_test
Adding '-jd2:failed_job_exception false' to the match_xml integration test command
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2190 from RosettaCommons/weitzner/match_cst_format
Weitzner/match cst format
Vikram K. Mulligan 7 years Huh -- from this commit onward, the cluster_calibur integration test either fails to run or is unstable.[list]
Andy Watkins 7 years Some of these issues are repaired in my calibur Rosetta-ification branch; timing info is also part of the culprit. A variable calculation for the mode of a set, however, seems odd! Maybe it's a random subset of all decoys, taken in a way that doesn't use the Rosetta rng (so maybe I fixed that); not sure, though. In any event, that's a branch I'd like to revisit. Good reason to do so.
Vikram K. Mulligan 7 years OK -- as long as someone is aware of this and is working on it.
notify author
notify list [rosetta-logs@googlegroups.com]