I was just checking out the boost serialization library. It looks like the simplest way to get code to save and restore the model state. It also supports XML io, so you can relatively easily generate an XML file. This makes it pretty useless in terms of human readability.
To read and write a DistanceRestraint using the library you just add code like template <class Archive> void serialize(Archive &ar, const unsigned int version) { ar &boost::serialization::base_object<Restraint>(*this); ar &boost::make_nvp("scorefunction", sf_); }
in addition, we need the macro "BOOST_CLASS_EXPORT(DistanceRestraint)" so it gets the names right.
That is pretty awesome as there is only one chuck of code, so there is less to keep synchronized. It has support for stl containers so those get trivially serialized too.
Daniel Russel wrote: > I was just checking out the boost serialization library. It looks like > the simplest way to get code to save and restore the model state.
I agree - I looked at this a few weeks ago and it does look very suitable for our needs.
> It also supports XML io, so you can relatively easily generate an > XML file. This makes it pretty useless in terms of human readability.
Useful?
The only problem with Boost serialization is that it's one of the few Boost libraries that is not header-only. So if you are planning to write any serialization code, a request: please just implement it for a class or two and send a patch, rather than hitting every class in IMP with it. Several of our build machines only have the Boost headers, so I have to get the shared libraries to build on them first before I can put such a patch in. I'd like to make sure everything works everywhere before we get too carried away.
Ben
>> XML file. This makes it pretty useless in terms of human readability. > > Useful? Well, I didn't quite mean useful, but actually, I didn't really mean for the sentence to be there. I think direct XML dump of the objects is a bad way to do a human editable file format since it makes it very hard (to impossible) to ensure invariants such as the hierarchies being right, bonds being right etc.
> Several of our build machines only have the Boost headers, so I have > to > get the shared libraries to build on them first before I can put > such a > patch in. Just out of curiousity, what platforms require work to get boost working (no rpms or prebuild installs)? Or is it just a matter on having not yet installed macports or the full boost binaries on something?
We should probably start assembling such instructions with the installation instructions (for example where to get macports or fink for macs). Pointing people to the projects' web pages is probably only useful for windows users (even then, it is probably easier for most windows users to just use cygwin rather than messing with all sorts of packages).
Daniel Russel wrote: >>> XML file. This makes it pretty useless in terms of human readability. >> Useful? > Well, I didn't quite mean useful, but actually, I didn't really mean for > the sentence to be there. I think direct XML dump of the objects is a > bad way to do a human editable file format since it makes it very hard > (to impossible) to ensure invariants such as the hierarchies being > right, bonds being right etc.
I agree - it wasn't clear to me from your original email though! Just wanted to clarify that.
> Just out of curiousity, what platforms require work to get boost working > (no rpms or prebuild installs)? Or is it just a matter on having not yet > installed macports or the full boost binaries on something?
I think it's just our Suns and the Windows builds.
> We should probably start assembling such instructions with the > installation instructions (for example where to get macports or fink for > macs).
It's certainly straightforward to insert such instructions into the relevant section of the manual.
Ben
participants (3)
-
Ben Webb -
Daniel Russel -
Daniel Russel