impl abom, serde

timely/src/progress/change_batch.rs

@@ -9,7 +9,7 @@
 /// until they are required. This means that several seemingly simple operations may be expensive, in
 /// that they may provoke a compaction. I've tried to prevent exposing methods that allow surprisingly
 /// expensive operations; all operations should take an amortized constant or logarithmic time.
-#[derive(Clone, Debug, Eq, PartialEq)]
+#[derive(Clone, Debug, Eq, PartialEq, Abomonation, Serialize, Deserialize)]
 pub struct ChangeBatch<T> {
     // A list of updates to which we append.
     updates: Vec<(T, i64)>,

timely/src/progress/frontier.rs

@@ -9,7 +9,7 @@ use crate::order::PartialOrder;
 /// This antichain implementation allows you to repeatedly introduce elements to the antichain, and
 /// which will evict larger elements to maintain the *minimal* antichain, those incomparable elements
 /// no greater than any other element.
-#[derive(Clone, Debug, Default, Eq, PartialEq)]
+#[derive(Clone, Debug, Default, Eq, PartialEq, Abomonation, Serialize, Deserialize)]
 pub struct Antichain<T> {
     elements: Vec<T>
 }
@@ -175,7 +175,7 @@ impl<T: PartialOrder> Antichain<T> {
 /// There is an `update_dirty` method for single updates that leave the `MutableAntichain` in a dirty state,
 /// but I strongly recommend against using them unless you must (on part of timely progress tracking seems
 /// to be greatly simplified by access to this)
-#[derive(Clone, Debug)]
+#[derive(Clone, Debug, Abomonation, Serialize, Deserialize)]
 pub struct MutableAntichain<T: PartialOrder+Ord> {
     dirty: usize,
     updates: Vec<(T, i64)>,