Saveload custom derive #460

WaDelma · 2018-09-08T17:14:46Z

Split from #434
A custom derive for IntoSerialize and FromDeserialize named #[derive(Saveload)]. It may seem odd to derive them together, but after spending significant time trying to do it the normal way (one derive per trait) it became clear that due to the requirement of "proxy" types that fill the IntoSerialize::Data and FromDeserialize::Data fields, it made sense to do it this way or you start getting into attribute hell.

This change is

`IntoSerialize` and `FromDeserialize` relied on `Component` which was somewhat pointless. This wouldn't be a problem, but due to how proc macros work, this is necessary to create something like `\#[derive(IntoSerialize)]` because then we can ensure every field, transitively, is `IntoSerialize`. For the actual (De)`SerializeComponents` traits, this is changed into `IntoSerialize+Component` and `FromDeserialize+Component` as a bound to ensure correctness (it doesn't compile without it anyway). We can then add `#[derive(Saveload)]` which auto-implements `IntoSerialize`/`FromDeserialize` for most types (excluding those with references/pointers, and ones with generics for now) by automatically constructing a matching proxy "Data" type and converting all the fields with a recursive call to `into`/`from`.

zakarumych · 2018-09-08T20:26:03Z

There is no much sense in deriving only one trait anyway. We could merge them altogether.

torkleyy · 2018-09-09T06:56:30Z

There is no much sense in deriving only one trait anyway. We could merge them altogether.

I split them earlier, I'm sure there was a reason for that. Deriving two traits at once doesn't seem odd to me.

torkleyy

First review, mostly formatting. The missing generic implementation should be rather easy to add, I think we should do that.

I didn't review all the files yet.

torkleyy · 2018-09-09T06:57:13Z

specs-derive/Cargo.toml

@@ -9,8 +9,12 @@ keywords = ["gamedev", "parallel", "specs", "ecs", "derive"]
 license = "MIT/Apache-2.0"

 [dependencies]
-syn = "0.12"
+syn = {version="0.12", features=["extra-traits"]}


Formatting / spacing

Also, isn't there a newer version already? Might be wrong

Tried to update this, but the previous derive code was using synom which was removed from re-exports in newer one and trying to depend on it manually didn't work out of the box. Will need more work to do this.

torkleyy · 2018-09-09T06:57:21Z

specs-derive/Cargo.toml

 quote = "0.4"

+[dev-dependencies]
+specs = { path = "..", features=["serde"] }


Same as above

torkleyy · 2018-09-09T06:57:32Z

specs-derive/src/impl_saveload.rs

@@ -0,0 +1,487 @@
+//! Contains implementations for #[derive(Saveload)]


missing backticks

torkleyy · 2018-09-09T06:57:41Z

specs-derive/src/impl_saveload.rs

+//! Contains implementations for #[derive(Saveload)]
+//! which derives both `IntoSerialize` and `FromDeserialize`.
+//!
+//! Since this requires a proxy "Data" `struct`/`enum`, these two need


torkleyy · 2018-09-09T06:58:19Z

specs-derive/src/impl_saveload.rs

+//! to be derived together or it begins requiring unwieldy attribute explosion.
+//!
+//! Currently there is one major limitation to this implementation: it cannot handle
+//! generic types such as `struct Foo<T> { x: T, e: Entity }`. I'm not good enough at


This should be fixed, shouldn't be too hard.

Just starting with the review, is this fixed now?

Yes. Forgot to remove push commit that removes that documentation

torkleyy · 2018-09-09T07:03:52Z

specs-derive/src/impl_saveload.rs

+    let derive = match ast.data {
+        Data::Struct(ref mut data) => saveload_struct(data, &mut ast.ident, &mut ast.generics),
+        Data::Enum(ref data) => saveload_enum(data, &ast.ident, &ast.generics),
+        Data::Union(_) => panic!("Unions cannot derive IntoSerialize/FromDeserialize at present"),


won't in the future (missing tag); missing backticks + spacing

torkleyy · 2018-09-09T07:06:15Z

specs-derive/src/impl_saveload.rs

+}
+
+// Implements all elements of saveload common to structs of any type
+// (except unit structs like `struct Foo;` since they're auto-saveload);


I don't quite understand this sentence.

torkleyy · 2018-09-09T07:06:58Z

specs-derive/src/impl_saveload.rs

+        )),
+        clause => *clause = Some(parse_quote!(
+            where MA: ::serde::Serialize + ::serde::de::DeserializeOwned + ::specs::saveload::Marker,
+            for <'deser> MA: ::serde::Deserialize<'deser>


Why is this necessary? Isn't this guaranteed by DeserializeOwned?

torkleyy · 2018-09-09T07:08:52Z

specs-derive/src/impl_saveload.rs

+            &saveload_fields,
+        )
+    } else {
+        panic!("This derive does not support unit structs (Hint: they automatically derive FromDeserialize and IntoSerialize)");


Ah now I get the above sentence; both places should describe it more like "every unit struct can derive Serialize and Deserialize, thus has a blanket impl fulfill their IntoSerialize / IntoDeserialize".

Yeah, I think I wasn't thinking when I wrote this. TBH, we could probably just silently do nothing because of this instead of panicking. I think I decided to be explicit for some reason.

torkleyy

Looks good otherwise 👍

torkleyy · 2018-09-09T07:17:54Z

specs-derive/src/impl_saveload.rs

+            panic!("Slices are unsupported, use owned types like Vecs or Arrays instead")
+        }
+        Type::Reference(_) => panic!("References are unsupported"),
+        Type::Ptr(_) => panic!("Raw pointer types are unsupported"),


Why is that?

I didn't want to deal with reference/pointer graphs within serialized components (especially with cycles).

The biggest problem is it's not exactly clear what to even do with types that hold references while deserializing, since you'd need to somehow deserialize the contents of the reference and then pass that handle back to the callsite as well.

The funny thing is, we have a pointer that solves all these problems for us -- Entity, which is just a generational weak pointer. So I see no reason to try and solve these issues when we can tell the user "either write your own impl to explain what you mean by "(de)serialize this pointer" or split this into multiple components and use an Entity ID lookup".

Oh right. I don't know what I was thinking there.

torkleyy · 2018-09-09T07:21:56Z

specs-derive/tests/saveload.rs

@@ -0,0 +1,70 @@
+// These are mostly just compile tests
+#![allow(dead_code)]


Please just check the result of the method calls, so we've got some additional coverage and don't need to disable warnings. Would be nice to have some more "exotic" types involving entities, like Vec<Entity>.

See the overall thread because this is really important.

torkleyy · 2018-09-09T07:24:39Z

src/saveload/ser.rs

 use storage::{GenericReadStorage, ReadStorage, WriteStorage};
 use world::{Component, EntitiesRes, Entity};

-/// Converts a component into its serialized form.
+/// Converts a data type (usually a [`Component`]) into its serialized form.


Not caused by this PR, but this isn't accurate. It gets converted into its serializable form.

torkleyy · 2018-09-09T07:25:18Z

src/saveload/ser.rs

@@ -191,7 +219,7 @@ macro_rules! serialize_components {
            M: Marker,
            $(
                $sto: GenericReadStorage<Component = $comp>,
-                $comp : IntoSerialize<M>,
+                $comp : IntoSerialize<M>+Component,


torkleyy · 2018-09-09T07:26:48Z

@WaDelma Are you going to be working on this?

WaDelma · 2018-09-09T09:33:58Z

Yeah I'll work on this.

UserAB1236872 · 2018-09-09T09:49:39Z

@torkleyy says

Please just check the result of the method calls, so we've got some additional coverage and don't need to disable warnings. Would be nice to have some more "exotic" types involving entities, like Vec.

I can tell you that Vec<Entity> doesn't work right now. I think this info got lost in the split, but back then I said:

Crap, I forgot code like

impl IntoSerialize for C where C: Serialize+Clone vs impl IntoSerialize for Vec<T> where T: IntoSerialize would require specialization to resolve (and even then IDK if specialization would solve this).

Not sure how to solve this from a design standpoint, seems like there are only really two options:

Hand-implement IntoSerialize and FromDeserialize for every native type to avoid a blanket impl, and expect others to #[derive(Saveload)] for their own types.
Extend the derive to have special casing for things like Vec<T> and generate specialized code

I feel like 1 is more painful but probably ultimately more flexible, it seems closer to how serde works, but is also a massive undertaking (not in difficulty so much in time and scale).

I'm still not sure how to fix it.

torkleyy · 2018-09-09T09:54:38Z

Ah right I just read it. What I don't understand though: Vec<Entity> does not implement Serialize so it should also not implement IntoSerialize. So where do you need specialization here?

UserAB1236872 · 2018-09-09T09:58:23Z

Vec<Entity> could probably be done on its own, but Vec<T> such that T may contain an Entity can't.

The reason is Rust can't prove the implementations won't conflict.

torkleyy · 2018-09-09T11:27:04Z

I don't think that'd be such a big issue.

Suggested solution

implement traits for Vec<Entity>
other fields can either be solved by
- creating a newtype with an implementation
- providing an attribute like #[saveload(data = "FooVecData", into = "into_foo_vec_data", from = "from_foo_vec_data"]

UserAB1236872 · 2018-09-10T23:37:11Z

specs-derive/src/impl_saveload.rs

+/// ```nobuild
+///  fn into<F: FnMut(Entity) -> Option<MA>>(&self, mut ids: F) -> Result<Self::Data, Self::Error> {
+///      FooSaveloadData (
+///          e: IntoSerialize::into(&self.0, &mut ids)?


Tuple struct, shouldn't have a name here.

WaDelma · 2018-09-14T11:14:29Z

I stumbled into problem while trying to make custom derive to work with generics: I need to assert that <T as FromDeserialize<MA>>::Data = <T as IntoSerialize<MA>>::Data which triggers error: equality constraints are not yet supported in where clauses (#20041).

So we would need to either wait for that to stabilize, merge the traits or figure some other workaround for it.

This is my current macro expansion

UserAB1236872 · 2018-09-20T10:52:45Z

Merging the traits seems adequate, to me. I don't see much near-term utility in having them split with how all the saveload stuff currently works (as opposed to serde where there can be good reasons to implement only one of (De)serialize). If somebody has a compelling reason they can be split again.

WaDelma · 2018-09-21T12:46:01Z

After merging the traits and getting code gen work I tried to implement ConvertSaveload (I am not fond of the name) for Vec<Entity>, but it cannot be done:

error[E0119]: conflicting implementations of trait `saveload::ConvertSaveload<_>` for type `std::vec::Vec<world::entity::Entity>`:
   --> src/saveload/mod.rs:187:1
    |
143 | / impl<C, M> ConvertSaveload<M> for C
144 | | where
145 | |     C: Clone + Serialize + DeserializeOwned,
146 | | {
...   |
162 | |     }
163 | | }
    | |_- first implementation here
...
187 | / impl<M> ConvertSaveload<M> for Vec<Entity>
188 | | where
189 | |     M: Serialize + DeserializeOwned,
190 | | {
...   |
206 | |     }
207 | | }
    | |_^ conflicting implementation for `std::vec::Vec<world::entity::Entity>`
    |
    = note: upstream crates may add new impl of trait `serde::Serialize` for type `std::vec::Vec<world::entity::Entity>` in future versions
    = note: upstream crates may add new impl of trait `serde::Deserialize<'de>` for type `std::vec::Vec<world::entity::Entity>` in future versions

UserAB1236872 · 2018-09-21T15:05:53Z

Looks like since in the future they're allowing upstream impls of Serialize and Deserialize there could possible be a blanket impl conflict because, if an upstream crate did it, then suddenly the impl<C> would work? That's... bizarre and unfortunate.

UserAB1236872 · 2018-09-23T06:57:31Z

I've checked and annoyingly, even specialization doesn't solve this.

zakarumych · 2018-09-23T07:56:56Z

Can addition of C: Component fix this?

WaDelma · 2018-09-23T08:43:12Z

Adding Component bound seems to fix it, but I am not sure if it's right trait here.

Real solution would be adding bound for:

auto trait NoEntity {}

impl !NoEntity for Entity {}

but auto traits are unstable so that's out of the picture

zakarumych · 2018-09-23T08:51:18Z

I see. This trait is for deriving.
I have an idea.

torkleyy · 2018-09-23T13:40:36Z

Since this seems rather experimental, please move this into an optional crate / hide it behind a feature flag. If this only works for nightly, that would also be a way to get a first implementation.

WaDelma · 2018-09-23T17:05:47Z

I was going to leave it out of this PR anyways. Is there still something missing here otherwise?

UserAB1236872 · 2018-09-25T10:28:51Z

src/saveload/mod.rs

+/// [`Clone`], [`Serialize`] and [`DeserializeOwned`].
+///
+/// Implementing this yourself is usually only needed if you
+/// have a component that points to another Entity, or has a field which does,


Entity -> [Entity] (and subsequent link at the bottom)

UserAB1236872 · 2018-09-25T10:29:27Z

src/saveload/mod.rs

+///  and you wish to [`Serialize`] it.
+///
+/// *Note*: if you're using `specs_derive`
+/// and your struct does not have a generic bound (i.e. `struct Foo<T>`),


The generic bound thing was fixed, so we can remove this part.

torkleyy

Reviewed 1 of 2 files at r2, 3 of 6 files at r5, 1 of 1 files at r6, 1 of 1 files at r7.
Reviewable status: 6 of 7 files reviewed, 8 unresolved discussions (waiting on @torkleyy, @Zaerei, and @WaDelma)

specs-derive/Cargo.toml, line 16 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Same as above

Done

specs-derive/src/impl_saveload.rs, line 1 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

missing backticks

Done

specs-derive/src/impl_saveload.rs, line 4 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

spacing

Done.

specs-derive/src/impl_saveload.rs, line 56 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

won't in the future (missing tag); missing backticks + spacing

Done.

specs-derive/src/impl_saveload.rs, line 112 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

I don't quite understand this sentence.

Done.

specs-derive/src/impl_saveload.rs, line 129 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Why is this necessary? Isn't this guaranteed by DeserializeOwned?

OK, now invalid.

specs-derive/src/impl_saveload.rs, line 479 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Oh right. I don't know what I was thinking there.

OK, nothing left here.

specs-derive/src/impl_saveload.rs, line 117 at r8 (raw file):

        .cloned()
        .map(|mut f| {
            replace_entity_type(&mut f.ty);

In the future, it would be nice if we had a compiletest that checks if a serde derive would do it, too.

specs-derive/tests/saveload.rs, line 9 at r8 (raw file):

#[derive(ConvertSaveload)]
struct OneFieldNamed {
    e: ::specs::Entity,

Please import the prelude.

specs-derive/tests/saveload.rs, line 68 at r8 (raw file):

        // so no need to test anything but unit
        black_box::<U64Marker, _>(AnEnum::Unit);

whitespace

src/saveload/de.rs, line 156 at r8 (raw file):

/// ```
///
pub trait FromDeserialize<M>: Component {

That's what I'm a bit more skeptical about.. There was no split before the overhaul, then I added it for some reason (don't remember), now I'm not sure why I did that. And yeah, maybe we can find a better trait name.

src/saveload/mod.rs, line 58 at r7 (raw file):

Previously, Zaerei (Zoe Juozapaitis) wrote…

Entity -> [Entity] (and subsequent link at the bottom)

Did you check the links actually work? It would be good if all of them were absolute, since relative ones break for re-exports. But then, versions might differ..

src/saveload/mod.rs, line 62 at r7 (raw file):

Previously, Zaerei (Zoe Juozapaitis) wrote…

The generic bound thing was fixed, so we can remove this part.

Is this resolved?

src/saveload/ser.rs, line 12 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Not caused by this PR, but this isn't accurate. It gets converted into its serializable form.

OK, no longer valid.

src/saveload/ser.rs, line 222 at r2 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

spacing

This is still an issue.

WaDelma · 2018-09-26T11:34:08Z

"Please import the prelude.":
I removed import for that to make sure all things referred in custom derive use full path (previously there were inconsistencies here because prelude was used).
I am not sure if I should change everything to work like in #467 though

re relative paths:
Yeah I checked that they work. I think I can actually use trait.Component.html to refer them if they are in same crate

WaDelma · 2018-09-28T08:14:12Z

Absolute links also break if the user is using locally generated documentation

torkleyy · 2018-09-29T15:22:17Z

Reviewable still not working for you?

Please ping me when I should review again.

WaDelma · 2018-10-01T23:00:44Z

@torkleyy Should I change things inside the custom derive to work like in #467?
That and concern on the merging of trait/renaming it are only things left.

torkleyy · 2018-10-02T23:09:05Z

@WaDelma I don't know what you mean by that rn. I'll review both PRs tomorrow if possible.

WaDelma · 2018-10-03T08:06:41Z

Currently the custom derive does ::specs::Entity, but in that PR the other custom derive was changed to do Entity so you have to import everything the derive needs. In exchange you get ability to (easily) use without direct specs dependency. (You can still make top level module named specs I think)

torkleyy · 2018-10-03T09:22:27Z

I think I speak for the Amethst team when I say that relative paths are better for Amethyst. Please just make sure to document the needed imports.

…

On Wed, Oct 3, 2018, 10:06 WaDelma ***@***.***> wrote: Currently the custom derive does ::specs::Entity, but in that PR the other custom derive was changed to do Entity so you have to import everything the derive needs. In exchange you get ability to (easily) use without direct specs dependency. (You can still make top level module named specs I think) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#460 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWFFuZYZSiz7knQDhVonxp8saEnaP2TIks5uhHAXgaJpZM4Wf9Ki> .

specs-derive/tests/saveload.rs

torkleyy

Reviewed 1 of 2 files at r2, 1 of 1 files at r8, 1 of 1 files at r9, 2 of 4 files at r10, 3 of 3 files at r11.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Zaerei)

torkleyy

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @torkleyy and @Zaerei)

specs-derive/src/impl_saveload.rs, line 241 at r3 (raw file):

Previously, Zaerei (Zoe Juozapaitis) wrote…

Tuple struct, shouldn't have a name here.

Not sure what this one is about.

src/saveload/mod.rs, line 58 at r7 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Did you check the links actually work? It would be good if all of them were absolute, since relative ones break for re-exports. But then, versions might differ..

OK, let's ignore this.

src/saveload/mod.rs, line 62 at r7 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Is this resolved?

LGTM

UserAB1236872 · 2018-10-07T10:24:06Z

specs-derive/src/impl_saveload.rs, line 241 at r3 (raw file):

Previously, torkleyy (Thomas Schaller) wrote…

Not sure what this one is about.

It's just a minor documentation error. We have a tuple struct, i.e. FooData(a,b,c) but in the example we're instantiating it like FooData(a: a, b: b, c: c) which doesn't make sense.

WaDelma · 2018-10-15T21:17:26Z

bors r+

Ah yeah, this PR.

460: Saveload custom derive r=WaDelma a=WaDelma Split from #434 A custom derive for IntoSerialize and FromDeserialize named #[derive(Saveload)]. It may seem odd to derive them together, but after spending significant time trying to do it the normal way (one derive per trait) it became clear that due to the requirement of "proxy" types that fill the IntoSerialize::Data and FromDeserialize::Data fields, it made sense to do it this way or you start getting into attribute hell.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/slide-rs/specs/460)  Co-authored-by: Zoe Juozapaitis <jragonmiris@gmail.com> Co-authored-by: Delma <delma@del.ma>

bors · 2018-10-15T21:50:14Z

Build succeeded

continuous-integration/travis-ci/push

UserAB1236872 and others added 2 commits May 31, 2018 00:22

Visibility changes

c0ac1c3

WaDelma mentioned this pull request Sep 8, 2018

Saveload convenience (proc-)macros #434

Closed

Merge remote-tracking branch 'upstream/master' into saveload-derive

8b9ea4f

WaDelma force-pushed the saveload-derive branch from 953c5ed to 8b9ea4f Compare September 8, 2018 17:44

Cleanup

0742b25

torkleyy reviewed Sep 9, 2018

View reviewed changes

torkleyy added the in progress label Sep 9, 2018

WaDelma added 2 commits September 10, 2018 21:20

Improved documentation and minor formating

6400761

Don't build autogenerated examples in comments

3cff971

UserAB1236872 reviewed Sep 10, 2018

View reviewed changes

Fixed tuple struct expansion documentation

a762169

WaDelma added 2 commits September 20, 2018 23:57

Adding generic support started

12f76c2

Merge IntoSerialize and FromDeserialize to ConvertSaveload

2ca1497

Remove dead code allow

c71311d

Fix documentation

98c5c1b

UserAB1236872 reviewed Sep 25, 2018

View reviewed changes

Fixed documentation

5f30dc9

torkleyy requested changes Sep 26, 2018

View reviewed changes

Cargo.toml formatting

1c86323

Cleanup

c30b064

ldesgoui mentioned this pull request Oct 2, 2018

Book improvements v2 #408

Closed

3 tasks

Don't depend on specs directly

f963476

torkleyy reviewed Oct 3, 2018

View reviewed changes

specs-derive/tests/saveload.rs Show resolved Hide resolved

torkleyy approved these changes Oct 7, 2018

View reviewed changes

bors bot merged commit f963476 into amethyst:master Oct 15, 2018

expenses mentioned this pull request Oct 20, 2018

Saveload example that features serializing/deserializing a whole World #497

Closed

		@@ -0,0 +1,487 @@
		//! Contains implementations for #[derive(Saveload)]

		@@ -0,0 +1,70 @@
		// These are mostly just compile tests
		#![allow(dead_code)]

Saveload custom derive #460

Saveload custom derive #460

Conversation

WaDelma commented Sep 8, 2018 • edited by torkleyy Loading

zakarumych commented Sep 8, 2018

torkleyy commented Sep 9, 2018

torkleyy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WaDelma Sep 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

torkleyy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

torkleyy commented Sep 9, 2018

WaDelma commented Sep 9, 2018

UserAB1236872 commented Sep 9, 2018 • edited Loading

torkleyy commented Sep 9, 2018

UserAB1236872 commented Sep 9, 2018 • edited Loading

torkleyy commented Sep 9, 2018

Suggested solution

Choose a reason for hiding this comment

WaDelma commented Sep 14, 2018

UserAB1236872 commented Sep 20, 2018

WaDelma commented Sep 21, 2018

UserAB1236872 commented Sep 21, 2018

UserAB1236872 commented Sep 23, 2018

zakarumych commented Sep 23, 2018

WaDelma commented Sep 23, 2018 • edited Loading

zakarumych commented Sep 23, 2018

torkleyy commented Sep 23, 2018

WaDelma commented Sep 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

torkleyy left a comment

Choose a reason for hiding this comment

WaDelma commented Sep 26, 2018

WaDelma commented Sep 28, 2018

torkleyy commented Sep 29, 2018

WaDelma commented Oct 1, 2018

torkleyy commented Oct 2, 2018

WaDelma commented Oct 3, 2018

torkleyy commented Oct 3, 2018 via email

torkleyy left a comment

Choose a reason for hiding this comment

torkleyy left a comment

Choose a reason for hiding this comment

UserAB1236872 commented Oct 7, 2018

WaDelma commented Oct 15, 2018

bors bot commented Oct 15, 2018

Build succeeded

WaDelma commented Sep 8, 2018 •

edited by torkleyy

Loading

WaDelma Sep 21, 2018 •

edited

Loading

UserAB1236872 commented Sep 9, 2018 •

edited

Loading

UserAB1236872 commented Sep 9, 2018 •

edited

Loading

WaDelma commented Sep 23, 2018 •

edited

Loading