Unions: Remove feature-gate for stable rustc #415

Luke-Nukem · Jul 21, 2017

Removes all feature-gating of union, and now requires rust 1.19
Updates readme to reflect this.

Travis build failure is legit

EPashkin · Jul 22, 2017

Travis build failure is legit

EPashkin · Jul 22, 2017

EPashkin reviewed Jul 22, 2017

View changes

EPashkin · Jul 22, 2017

src/codegen/sys/statics.rs

    let v = vec![
-        u,
+        "#![feature(untagged_unions)]",


This line unneeded just "" instead

Ah, yes. I was using nightly rust still.

Only last problem with error: unions with non-Copyfields are unstable (see issue #32836)
I thought that we can just add #[derive(Clone, Copy)] to child structs, but in case of GDoubleIEEE754_mpn it won't works because _truncated_record_marker: c_void.
Maybe we need change its type to u8.
Also from gdk's "GdkEvent" seems we need derive Copy for many child structs and it inners (GdkRectangle) etc.,
so IMHO simpler derive Copy for all structs and possibly for unions.
@GuillaumeGomez you agree with this?
@sdroege As I remember you was for derive Copy from start?

EPashkin · Jul 22, 2017

Only last problem with error: unions with non-Copyfields are unstable (see issue #32836)
I thought that we can just add #[derive(Clone, Copy)] to child structs, but in case of GDoubleIEEE754_mpn it won't works because _truncated_record_marker: c_void.
Maybe we need change its type to u8.
Also from gdk's "GdkEvent" seems we need derive Copy for many child structs and it inners (GdkRectangle) etc.,
so IMHO simpler derive Copy for all structs and possibly for unions.
@GuillaumeGomez you agree with this?
@sdroege As I remember you was for derive Copy from start?

Not sure how to go about #[derive(Clone, Copy)]... To be honest, I don't think we should be adding this manually as this implies that we are checking each case to be sure all fields can be Copy - which we are not doing unless it is at the parser/output level.

Changing _truncated_record_marker: c_void to u8 would be a good idea I think. I'll work on removing the #![feature(untagged_unions)] and implementing #[derive(Copy, Clone)] for those particular types. Do you have any suggestions for tracking which ones need it?

Luke-Nukem · Jul 22, 2017

Not sure how to go about #[derive(Clone, Copy)]... To be honest, I don't think we should be adding this manually as this implies that we are checking each case to be sure all fields can be Copy - which we are not doing unless it is at the parser/output level.

Changing _truncated_record_marker: c_void to u8 would be a good idea I think. I'll work on removing the #![feature(untagged_unions)] and implementing #[derive(Copy, Clone)] for those particular types. Do you have any suggestions for tracking which ones need it?

@Luke-Nukem Lets wait for other say their options. For GdkEvent need or implement recursive check and update for all children or just derive for all structs.

EPashkin · Jul 22, 2017

@Luke-Nukem Lets wait for other say their options. For GdkEvent need or implement recursive check and update for all children or just derive for all structs.

@EPashkin no problem. I do know we absolutely shouldn't (and can't) implement #[derive(Copy, Clone)] for all structs, it would introduce inefficiencies such as copying large data structures automatically instead of using a move. Looking at the structure of what we use to output the bindings, there doesn't seem to be anything easily used for it - unless perhaps we insert some flag at the parse stage?

Luke-Nukem · Jul 22, 2017

@EPashkin no problem. I do know we absolutely shouldn't (and can't) implement #[derive(Copy, Clone)] for all structs, it would introduce inefficiencies such as copying large data structures automatically instead of using a move. Looking at the structure of what we use to output the bindings, there doesn't seem to be anything easily used for it - unless perhaps we insert some flag at the parse stage?

Hm, I don't though that some structures can be large and Copy for these unreasonable.
Maybe we can add some config for Copy and for expanding enum.
Or really check\add Copy flag all unions children and hope that its will not cause problem.

EPashkin · Jul 22, 2017

Hm, I don't though that some structures can be large and Copy for these unreasonable.
Maybe we can add some config for Copy and for expanding enum.
Or really check\add Copy flag all unions children and hope that its will not cause problem.

last commit produce strange diff:

// Records
 #[repr(C)]
-pub struct GArray {
+GArraypub struct GArray {
     pub data: *mut c_char,
     pub len: c_uint,
 }

EPashkin · Jul 22, 2017

last commit produce strange diff:

// Records
 #[repr(C)]
-pub struct GArray {
+GArraypub struct GArray {
     pub data: *mut c_char,
     pub len: c_uint,
 }

Oh dear, looks like I'm making a mess of git. Hang on, I'll try and fix this up.

Luke-Nukem · Jul 22, 2017

Oh dear, looks like I'm making a mess of git. Hang on, I'll try and fix this up.

The sys crates I've compiled so far seem to be fine now.

Luke-Nukem · Jul 22, 2017

The sys crates I've compiled so far seem to be fine now.

EPashkin · Jul 22, 2017

EPashkin reviewed Jul 22, 2017

View changes

EPashkin · Jul 22, 2017

src/codegen/sys/lib_.rs

@@ -434,7 +434,7 @@ fn generate_records(w: &mut Write, env: &Env, records: &[&Record]) -> Result<()>
            if record.derive_copy {
                try!(writeln!(w, "{}#[derive(Copy,Clone)]", comment));
            }
-            try!(writeln!(w, "{0}pub struct {} {{", record.c_type));
+            try!(writeln!(w, "pub struct {} {{", record.c_type));


This not correct too, you lost comment text

🤦‍ 🤦‍ 🤦‍
Added back, squashed last series of commits. Should be good now.

Only last questionable problems with GdkEvent and GtkTextAppearance_u1, for this better wait opinions from others.

EPashkin · Jul 22, 2017

Only last questionable problems with GdkEvent and GtkTextAppearance_u1, for this better wait opinions from others.

With GtkTextAppearance_u1 is problem that it used gdk::GdkRGBA so we can't add Copy for it automaticly.

EPashkin · Jul 22, 2017

With GtkTextAppearance_u1 is problem that it used gdk::GdkRGBA so we can't add Copy for it automaticly.

Seems GtkTextAppearance_u1 actually unused as GtkTextAppearance is struct with bit-sized fields and truncated before union.

EPashkin · Jul 22, 2017

Seems GtkTextAppearance_u1 actually unused as GtkTextAppearance is struct with bit-sized fields and truncated before union.

Seems GtkTextAppearance_u1 actually unused as GtkTextAppearance is struct with bit-sized fields and truncated before union.

I guess that's just a side effect of how things are parsed then read out. Not sure what we can do about it other than just leave it. Or add in a special case for it? Do you think that is the only problem area?

Luke-Nukem · Jul 22, 2017

Seems GtkTextAppearance_u1 actually unused as GtkTextAppearance is struct with bit-sized fields and truncated before union.

I guess that's just a side effect of how things are parsed then read out. Not sure what we can do about it other than just leave it. Or add in a special case for it? Do you think that is the only problem area?

Just short comments

u8 or array thereof for bit fields makes sense. Just count the bits
I think deriving copy for all ffi structs is probably safe. As in, except for very few exceptions you only get them as pointers anyway. Using a configuration seems cleaner though, but OTOH we need to do that automatically for nested structs anyway. Copy for structs with pointers seems dangerous, but this is all unsafe code anyway so maybe OK. And in C, all structs are "Copy" too. Performance-wide I see no problem here in any case: if your code moved before, it will still do that. You might just copy without noticing, but that's only a problem if you have the whole struct and not just a pointer to it.

So in summary, I don't know. Making all Copy seems fine to me, a configuration also. Both are ugly in their own ways and in practice it probably makes no difference

sdroege · Jul 22, 2017

Just short comments

u8 or array thereof for bit fields makes sense. Just count the bits
I think deriving copy for all ffi structs is probably safe. As in, except for very few exceptions you only get them as pointers anyway. Using a configuration seems cleaner though, but OTOH we need to do that automatically for nested structs anyway. Copy for structs with pointers seems dangerous, but this is all unsafe code anyway so maybe OK. And in C, all structs are "Copy" too. Performance-wide I see no problem here in any case: if your code moved before, it will still do that. You might just copy without noticing, but that's only a problem if you have the whole struct and not just a pointer to it.

So in summary, I don't know. Making all Copy seems fine to me, a configuration also. Both are ugly in their own ways and in practice it probably makes no difference

@sdroege the one problem with making all Copy though, is that there will be some things that shouldn't be or are inherently non-copy. I think c_void is one of those so if any structs have that as a field type then we'll have issues. Having said that I know c_void is u8 sized, and don't quite understand the purpose of c_void.

Copy on pointers... iirc raw pointers are fine and safe for copy, it's only when we deref them that it's unsafe. (?)

Luke-Nukem · Jul 22, 2017

@sdroege the one problem with making all Copy though, is that there will be some things that shouldn't be or are inherently non-copy. I think c_void is one of those so if any structs have that as a field type then we'll have issues. Having said that I know c_void is u8 sized, and don't quite understand the purpose of c_void.

Copy on pointers... iirc raw pointers are fine and safe for copy, it's only when we deref them that it's unsafe. (?)

For pointers, correct. You just need to be careful to free all copies later, I.e. do double-frees. But that's already with plain pointers

sdroege · Jul 22, 2017

For pointers, correct. You just need to be careful to free all copies later, I.e. do double-frees. But that's already with plain pointers

@GuillaumeGomez what you think about implementing Copy for almost all structs in sys crates to make unions work on stable?

EPashkin · Jul 28, 2017

@GuillaumeGomez what you think about implementing Copy for almost all structs in sys crates to make unions work on stable?

That's something I proposed not that long ago so I'm totally for it!

GuillaumeGomez · Jul 28, 2017

That's something I proposed not that long ago so I'm totally for it!

@Luke-Nukem sorry for delay, I thought that I already asked.

EPashkin · Jul 28, 2017

@Luke-Nukem sorry for delay, I thought that I already asked.

Sorry about the delay here, I'll push through an update soon. Was a bit tied up with study this week.

Luke-Nukem · Jul 29, 2017

Sorry about the delay here, I'll push through an update soon. Was a bit tied up with study this week.

I'm not sure about pub struct Volatile<T>(T); being copy,clone... Thoughts?

Appveyor is pretty far behind in rust versions isn't it...

Luke-Nukem · Jul 29, 2017

I'm not sure about pub struct Volatile<T>(T); being copy,clone... Thoughts?

Appveyor is pretty far behind in rust versions isn't it...

error[E0277]: the trait bound `[f64; 128]: std::clone::Clone` is not satisfied
    --> /home/travis/build/gtk-rs/gir/tests/sys/gdk-sys/src/lib.rs:3743:5
     |
3743 |     pub axes: [c_double; 128],
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `[f64; 128]`
     |
     = help: the following implementations were found:
               <[T; 28] as std::clone::Clone>
               <[T; 14] as std::clone::Clone>
               <[T; 7] as std::clone::Clone>
               <[T; 8] as std::clone::Clone>
             and 29 others
     = note: required by `std::clone::AssertParamIsClone`

Suggestions?

Luke-Nukem · Jul 29, 2017

error[E0277]: the trait bound `[f64; 128]: std::clone::Clone` is not satisfied
    --> /home/travis/build/gtk-rs/gir/tests/sys/gdk-sys/src/lib.rs:3743:5
     |
3743 |     pub axes: [c_double; 128],
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `[f64; 128]`
     |
     = help: the following implementations were found:
               <[T; 28] as std::clone::Clone>
               <[T; 14] as std::clone::Clone>
               <[T; 7] as std::clone::Clone>
               <[T; 8] as std::clone::Clone>
             and 29 others
     = note: required by `std::clone::AssertParamIsClone`

Suggestions?

About old appveyour version: added fix #420

EPashkin · Jul 29, 2017

About old appveyour version: added fix #420

As gtk has single problem too, IMHO better add config parameter for object like "dont_copy=true"

error[E0277]: the trait bound `unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32): std::clone::Clone` is not satisfied
    --> d:/eap/rust/0/sys/gtk-sys\src\lib.rs:5295:5
     |
5295 |     pub draw_shadow_gap: Option<unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const c_char, c_int, c_int, c_int, c_int, GtkPositionType, c_int, c_int)>,
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32)`
     |
     = note: required because of the requirements on the impl of `std::clone::Clone` for `std::option::Option<unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32)>`
     = note: required by `std::clone::AssertParamIsClone`

EPashkin · Jul 29, 2017

As gtk has single problem too, IMHO better add config parameter for object like "dont_copy=true"

error[E0277]: the trait bound `unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32): std::clone::Clone` is not satisfied
    --> d:/eap/rust/0/sys/gtk-sys\src\lib.rs:5295:5
     |
5295 |     pub draw_shadow_gap: Option<unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const c_char, c_int, c_int, c_int, c_int, GtkPositionType, c_int, c_int)>,
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32)`
     |
     = note: required because of the requirements on the impl of `std::clone::Clone` for `std::option::Option<unsafe extern "C" fn(*mut GtkStyle, *mut cairo::cairo_t, GtkStateType, GtkShadowType, *mut GtkWidget, *const i8, i32, i32, i32, i32, GtkPositionType, i32, i32)>`
     = note: required by `std::clone::AssertParamIsClone`

EPashkin · Jul 29, 2017

EPashkin reviewed Jul 29, 2017

View changes

EPashkin · Jul 29, 2017

src/codegen/sys/lib_.rs

@@ -574,7 +516,7 @@ fn generate_fields(env: &Env, struct_name: &str, fields: &[Field]) -> (Vec<Strin
            if c_type.is_err() {
                commented = true;
            }
-            if !cfg!(feature = "use_unions") && is_gvalue && field.name == "data" {
+            if is_gvalue && field.name == "data" {


Why this don't removed?

EPashkin · Jul 29, 2017

EPashkin reviewed Jul 29, 2017

View changes

EPashkin · Jul 29, 2017

src/codegen/sys/lib_.rs

@@ -565,7 +507,7 @@ fn generate_fields(env: &Env, struct_name: &str, fields: &[Field]) -> (Vec<Strin
            continue 'fields;
        }

-        if is_gweakref && !cfg!(feature = "use_unions") {
+        if is_gweakref {


Why this don't removed?

EPashkin · Jul 29, 2017

EPashkin reviewed Jul 29, 2017

View changes

EPashkin · Jul 29, 2017

src/codegen/sys/lib_.rs

@@ -444,7 +417,7 @@ fn generate_records(w: &mut Write, env: &Env, records: &[&Record]) -> Result<()>
        if lines.is_empty() {
            try!(writeln!(
                w,
-                "{}#[repr(C)]\n{0}pub struct {}(c_void);\n",
+                "{0}#[repr(C)]\n{0}#[derive(Copy,Clone)]\n{0}pub struct {1}(u8);\n",


This better changed back (it will produce only 1 extra "dont_copy")

..because it just don't right, copy record with unknown size

I'm not sure I understand, pub struct GIConv(u8); should not be copy?

Yes, with GIOChannel

Not sure I understand either. What is the broken code generated by this?

this case produce warning: found non-foreign-function-safe member in struct marked #[repr(C)]: found Rust tuple type in foreign module; consider using a struct instead
just struct produce warning: found zero-size struct in foreign module, consider adding a member to this struct

I see... a case for the new #[repr(transparent)] I guess

Sorry, now I don't understand how it related to struct without fields.

You would want to represent an opaque C type. It's not really a struct without fields, it's just that the struct definition is unknown from the headers. So you can only ever use it as a pointer.

But that's actually extern type: rust-lang/rfcs#1861

extern type is that we need for this case but it not realized and may cause build error when inserted in other struct directly (as with GIConv)
#[repr(transparent)] can be used for minimize alignment errors for known fields, so also not for this case, so last repr(C).
I prefer c_void over u8 as it don't implement Copy while has same size and alignment.

About Volatile: as it applied only to simple types it can be copy.

EPashkin · Jul 29, 2017

About Volatile: as it applied only to simple types it can be copy.

EPashkin · Jul 29, 2017

EPashkin reviewed Jul 29, 2017

View changes

EPashkin · Jul 29, 2017

src/codegen/sys/lib_.rs

+            if lines.is_empty() {
+                try!(writeln!(
+                    w,
+                    "{0}#[repr(C)]\n{0}#[derive(Copy,Clone)]\n{0}pub union {1}(c_void);\n",


Copy better removed as for records
PS. this code actually unused.

config parameter for object like "dont_copy=true"

@EPashkin can you advise where I would look for examples of how to do this?

Luke-Nukem · Jul 29, 2017

config parameter for object like "dont_copy=true"

@EPashkin can you advise where I would look for examples of how to do this?

Add field to GObject same as https://github.com/gtk-rs/gir/blob/master/src/config/gobjects.rs#L151
then get it in generate_records

let full_name = format!("{}.{}", env.namespaces.main().name, record.name);
let config = env.config.objects.get(&full_name);

EPashkin · Jul 29, 2017

Add field to GObject same as https://github.com/gtk-rs/gir/blob/master/src/config/gobjects.rs#L151
then get it in generate_records

let full_name = format!("{}.{}", env.namespaces.main().name, record.name);
let config = env.config.objects.get(&full_name);

.. As config can be None for ffi, use if-let or config.map(|o| o.dont_copy).unwrap_or(false) to get value.

EPashkin · Jul 29, 2017

.. As config can be None for ffi, use if-let or config.map(|o| o.dont_copy).unwrap_or(false) to get value.

I need to put this on the backlog for a week or so while I do a few other things of importance. I may work on it off/on through the week however, we'll see.

Luke-Nukem · Jul 30, 2017

I need to put this on the backlog for a week or so while I do a few other things of importance. I may work on it off/on through the week however, we'll see.

What's the status here?

sdroege · Sep 18, 2017

What's the status here?

I've not had much free time. I'll try and get a look at it again this week, I should be able to juggle my schedule a bit.

…

On 18/09/2017 8:03 PM, "Sebastian Dröge" ***@***.***> wrote: What's the status here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB7Cfsc3v_nuFfAeRZFZYm3CzjgQcSsuks5sjiPagaJpZM4Of-Go> .

Luke-Nukem · Sep 18, 2017

I've not had much free time. I'll try and get a look at it again this week, I should be able to juggle my schedule a bit.

…

On 18/09/2017 8:03 PM, "Sebastian Dröge" ***@***.***> wrote: What's the status here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB7Cfsc3v_nuFfAeRZFZYm3CzjgQcSsuks5sjiPagaJpZM4Of-Go> .

@sdroege @EPashkin I've done a rebase of this on to master and run a couple of small gir tests - seems okay.

Looking back at previous comments it looks like I still have a few things to do such as "dont_copy=true". Is this still a blocker?

Luke-Nukem · Oct 25, 2017

@sdroege @EPashkin I've done a rebase of this on to master and run a couple of small gir tests - seems okay.

Looking back at previous comments it looks like I still have a few things to do such as "dont_copy=true". Is this still a blocker?

IMHO just having copy on all FFI things is fine, configuration can be added later once needed :)

sdroege · Oct 25, 2017

IMHO just having copy on all FFI things is fine, configuration can be added later once needed :)

Okidoki, then this may be good to go if edge cases are okay.

…

On 25 October 2017 at 21:59, Sebastian Dröge ***@***.***> wrote: IMHO just having copy on all FFI things is fine, configuration can be added later once needed :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB7CfrQG3LWkO6JcR6tH2eXYFTh7M9SFks5svvhigaJpZM4Of-Go> .

Luke-Nukem · Oct 25, 2017

Okidoki, then this may be good to go if edge cases are okay.

…

On 25 October 2017 at 21:59, Sebastian Dröge ***@***.***> wrote: IMHO just having copy on all FFI things is fine, configuration can be added later once needed :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#415 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB7CfrQG3LWkO6JcR6tH2eXYFTh7M9SFks5svvhigaJpZM4Of-Go> .

Tests will pass with this commit to cairo.

I get the impression that this is going to require a more in-depth solution rather than just implement Copy,Clone for all. Perhaps by marking unions in codegen and everything branching from it, and only derive/implement Copy,Clone for those, along with setting up the correct sized type to replace c_void for each architecture (c_void does not allow Copy).

Luke-Nukem · Nov 13, 2017

Tests will pass with this commit to cairo.

I get the impression that this is going to require a more in-depth solution rather than just implement Copy,Clone for all. Perhaps by marking unions in codegen and everything branching from it, and only derive/implement Copy,Clone for those, along with setting up the correct sized type to replace c_void for each architecture (c_void does not allow Copy).

Luke-Nukem referenced this pull request Nov 13, 2017
Merged
unions: cairo_pattern_t to u8 #166

tests: update some crate versions, eg, bitflags

Loading status checks…

0e6665f

tmiasko referenced this pull request Jan 29, 2018
Merged
Union, Clone and Copy #527

EPashkin merged commit 0e6665f into gtk-rs:master Feb 1, 2018
2 checks passed

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

continuous-integration/travis-ci/pr The Travis CI build passed
Details

tmiasko referenced this pull request Mar 10, 2018
Closed
Add support for unions #334

gtk-rs/gir

Join GitHub today

Unions: Remove feature-gate for stable rustc #415

Conversation

Luke-Nukem commented Jul 21, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

EPashkin reviewed Jul 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

Luke-Nukem Jul 22, 2017 • edited Edited 1 time Luke-Nukem edited Jul 22, 2017 (most recent)

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

EPashkin reviewed Jul 22, 2017 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

This comment has been minimized.

sdroege commented Jul 22, 2017

This comment has been minimized.

Luke-Nukem commented Jul 22, 2017

This comment has been minimized.

sdroege commented Jul 22, 2017

This comment has been minimized.

EPashkin commented Jul 28, 2017

This comment has been minimized.

GuillaumeGomez commented Jul 28, 2017

This comment has been minimized.

EPashkin commented Jul 28, 2017

This comment has been minimized.

Luke-Nukem commented Jul 29, 2017

This comment has been minimized.

Luke-Nukem commented Jul 29, 2017 • edited Edited 1 time Luke-Nukem edited Jul 29, 2017 (most recent)

This comment has been minimized.

Luke-Nukem commented Jul 29, 2017

This comment has been minimized.

EPashkin commented Jul 29, 2017

This comment has been minimized.

EPashkin commented Jul 29, 2017

EPashkin reviewed Jul 29, 2017 View changes

This comment has been minimized.

EPashkin reviewed Jul 29, 2017 View changes

This comment has been minimized.

EPashkin reviewed Jul 29, 2017 View changes

This comment has been minimized.

EPashkin Jul 29, 2017 • edited Edited 1 time EPashkin edited Jul 29, 2017 (most recent)

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

EPashkin commented Jul 29, 2017

EPashkin reviewed Jul 29, 2017 View changes

This comment has been minimized.

EPashkin reviewed Jul 22, 2017

View changes

Luke-Nukem Jul 22, 2017 •

edited

Edited 1 time

Luke-Nukem edited Jul 22, 2017 (most recent)

EPashkin reviewed Jul 22, 2017

View changes

Luke-Nukem commented Jul 29, 2017 •

edited

Edited 1 time

Luke-Nukem edited Jul 29, 2017 (most recent)

EPashkin reviewed Jul 29, 2017

View changes

EPashkin reviewed Jul 29, 2017

View changes

EPashkin reviewed Jul 29, 2017

View changes

EPashkin Jul 29, 2017 •

edited

Edited 1 time

EPashkin edited Jul 29, 2017 (most recent)

EPashkin reviewed Jul 29, 2017

View changes

EPashkin commented Jul 29, 2017 •

edited

Edited 1 time

EPashkin edited Jul 29, 2017 (most recent)

EPashkin commented Jul 29, 2017 •

edited

Edited 1 time

EPashkin edited Jul 29, 2017 (most recent)