Use WinSock2 for `PyMOLMover` (#4958)
Issue Details:
`PyMOLMover` uses a number of network APIs that either weren't being included for the Windows build, or were included via legacy winsock.
Fix Details:
Include the WinSock2 headers where these APIs are required.
notify author
notify list [rosetta-logs@googlegroups.com]
Use `utility::file` in `FragmentScoreFilter` instead of OS-specific APIs (#4956)
* Add Win32 implementation of directory manipulation in `FragmentScoreFilter`
Issue Details:
`FragmentScoreFilter` uses Linux/Mac OS specific headers/APIs to change the current directory and create a new directory.
Fix Details:
When building for Windows, include the relevant Win32 headers and use the Win32 APIs.
* Use utility::file in FragmentScoreFilter instead of OS-specific APIs
* beautifying
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4941 from RosettaCommons/vmullig/tag_getOption_for_bool_strings
Try to address cases in which a developer has provided a default value for a boolean as a string in parse_my_tag().
This code compiles correctly, but doesn't do what one expects:
```c++
bool myoption = tag->getOption<bool>( "myoption", "false" );
```
The developer _expects_ that if the user doesn't specify the option "myoption", it will default to `false`. Unfortunately, the string literal `"false"` is sent to the `Tag::getOption<bool>( std::string const &, bool const )` function as a `char*`, which can be cast automatically to a bool. Any non-`nullptr` value gets interpreted as `true`, however, so the default is set to `true`.
The general solution (since even if we fix all the instances currently in the codebase, this will creep back in) is to implement `Tag::getOption<bool>( std::string const &, char const * )`, which parses and interprets the default string and converts it to a `bool`. This PR does this.
Thank you to @danielzaidman for bringing this issue to light!
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #4856 from RosettaCommons/vmullig/move_cavity_volume_from_devel_to_protocols
Move CavityVolumeFilter from devel to protocols
The `CavityVolumeFilter` was used in Silva _et al._ (2019.) De novo design of potent and selective mimics of IL-2 and IL-15. _Nature_ 565: 186–191, but the scripts in the supplement can not be run, and by extension the work that the paper describes is not reproducible, if this remains in devel. At least one person has been asking about this on the Rosetta forums.
Tasks:
- [x] Move this filter to protocols from devel.
- [x] Move supporting class, the `CavityCalculator`, to protocols from devel.
- [x] Add citation info. I'm going to count this as an unpublished module since Tom wasn't on the paper in which it first appeared, and it wasn't really described in that paper, and Tom might want to write a paper describing this.
Also:
- [x] Update the tools submodule to point at the latest master for the tools repo.
notify author
notify list [rosetta-logs@googlegroups.com]