Iterators #395

steveklabnik · 2017-01-10T21:07:24Z

A continuation of #381.

This is the draft of the iterators and closures chapter. I decided to cut the bit about closure implementation at the end.

This also

Fixes #374

by using @ruuda's example from https://ruudvanasseldonk.com/2016/11/30/zero-cost-abstractions. Is that okay with you, @ruuda?

Not well edited and doesn't have everything about iterators

steveklabnik · 2017-01-10T21:31:07Z

Failures seem to be all spellcheck related

ruuda · 2017-01-10T22:00:21Z

Sure, go ahead.

sophiajt · 2017-01-10T23:55:34Z

src/ch13-00-functional-features.md

+```
+
+Here, even though `x` is not an argument to `equal_to_x`, it's able to
+refer to it, as it's a variable defined in the same scope. We couldn't


The wording here makes me a little nervous that people will read this and assume "bound variables must be in the same scope as the lambda", but is that how it works? I was assuming they just had to be in the scope chain.

I'm going to just take out the word "same", so that this says "a variable defined in the scope"

sophiajt · 2017-01-11T01:49:56Z

This feels a bit meatier, but seems it's time for that book-wise.

A few comments:

Would be nice to call back to our "impl Iterator for Counter" example later in the chapter. We show using for loops but I didn't see where we use it on the Counter.
We don't implement IntoIterator on a custom type. Do we want to? Otherwise this part seems a bit extra.
Generally, I think this is good. It's got the right balance of information and also pulling people into the "Rust way", which is a good way to kick off the new section.

sophiajt · 2017-01-10T23:55:51Z

src/ch13-00-functional-features.md

-### What is a closure
+Rust gives you the ability to define *closures*, which are sort of like
+functions. Instead of giving you a technical definintion, let's dive into
+what clousures look like, syntactically:


Mmm clousures

sophiajt · 2017-01-11T00:02:31Z

src/ch13-00-functional-features.md

+let f = Foo;
+let moves = |f| moves(f);
+moves(f);
+```


The shadowing here made it harder for me to read. Probably better to avoid shadowing just for clarity.

hehe we will fight about this forever, won't we 😄

I'm on @jonathandturner's side with this one. Between shadowing f and the closure names shadowing the function names.... yeah, that's a little bit too much mental overhead i think.

sophiajt · 2017-01-11T00:09:00Z

src/ch13-00-functional-features.md

+```
+
+We only get `5`. Rather than taking a mutable borrow out on our `num`, we took
+ownership of a copy.


Does move always copy?

it copies but it does not Copy. (aka words are hard)

It might not copy data in memory if it can reuse the location efficiently.

yeah, this is about semantics, not about what happens after optimization

hnnnng i thought i understood this part but these comments make me confused again

sophiajt · 2017-01-11T00:37:42Z

src/ch13-00-functional-features.md

+
+`Fn` isn't the only trait, however, there are three. `Fn`, `FnMut`, and
+`FnOnce`. This continues the patterns of threes we've seen elsewhere in Rust:
+by owner, by reference, and by mutable reference. By using `Fn`, you may only


I visually matched them in the same order and got a confused. Fn->Owner, FnMut->Reference, FnOnce->Mutable Reference isn't right. Maybe we can reword to avoid people doing the visual matching?

sophiajt · 2017-01-11T01:34:39Z

src/ch13-00-functional-features.md

+```
+
+At the time, we didn't explain the `.iter()` bit, but now you know that it
+makes an iterator. Rust's `for` loop is actually 'synatx sugar', that is, it's


sophiajt · 2017-01-11T01:37:29Z

src/ch13-00-functional-features.md

+
+Well, when we told you about the definition of `Iterator`, we committed a
+small lie of omission. The `Iterator` trait has a number of other useful
+methods. Like `map`:


Did we lie? You told us about map and collect earlier...

well we lied when we showed The Definition of The Iterator Trait and it only had the next method on it

sophiajt · 2017-01-11T01:41:11Z

src/ch13-00-functional-features.md

+        let search = match args.next() {
+            Some(arg) => arg,
+            None => return "Didn't get a search string",
+	};


wrong indent x 2

sophiajt · 2017-01-11T01:44:12Z

src/ch13-00-functional-features.md

+and building a new vector, it focuses on the high-level objective of the loop.
+
+But are they truly equivalent? Surely the more low-level loop will be faster?
+Let's talk about performance.

 ## Summary: Performance


This could probably just be "Performance"?

Nice try, Stephen. We still have to write a summary section :P

sophiajt · 2017-01-11T01:44:59Z

src/ch13-00-functional-features.md

+```
+
+That's right, the iterator version ended up slightly faster! We're not going
+to share the bencharmark code exactly here, as the point is not to prove that


bencharmark

sophiajt · 2017-01-11T01:47:03Z

src/ch13-00-functional-features.md


-Closures don't have any further performance penalty over regular fn calls
+This code sample is taken from an audio decoder. It "restores sample values


original link? do we refer to the creator in our footnotes?

I don't know how that works, but that's one reason I CC'd @ruuda here; to see how they'd like to be credited, if using this is okay.

Oh, just saw that they replied, great 👍

Would be nice if you can add a link though :) Does the book have footnotes?

matthewjasper

Reading through and comparing to the old book

Being able to refer to the last chapter's example is nice.
I think this chapter takes a while to get going, but I don't know if there's anything to do about it.
I guess that returning closures is for chapter 17 (at least until impl trait). and lifetimes in closures for chapter 19, but a forwards reference would help.
Are function pointer types worth talking about?
While the exact implementation of closures may not be important, I think there's a risk of making closures seem too much like magic (which is a more general problem with learning rust).

matthewjasper · 2017-01-11T18:28:56Z

src/ch13-00-functional-features.md

+
+```rust
+struct Counter {
+    count: usize,


This doesn't match the u32 below.

matthewjasper · 2017-01-11T18:34:37Z

src/ch13-00-functional-features.md

+        } else {
+            None
+        }
+    }


Doesn't this method have integer overflow problems if you (for some reason) call next u32::MAX or so times?

matthewjasper · 2017-01-11T18:34:53Z

src/ch13-00-functional-features.md

+
+let x = counter.next().unwrap();
+println!("{}", x);
+```


Is it worth showing that the iterator will now keep returning None?

Yeah, I think the check for < 6 should be before the += 1 so that count won't continue to increase, is there a particular reason you implemented it this way @steveklabnik? It's slightly easier to talk through the way it is, but I'm going to try and make it work I think...

oh shoot i see why. poop.

Aha. So to address the u32::MAX issue and whether we should show that it keeps returning None, I'm going to add in this note from the std::iter docs: "Individual iterators may choose to resume iteration, and so calling next() again may or may not eventually start returning Some(Item) again at some point." So what happens after getting the first None depends on the implementation of the iterator.

matthewjasper · 2017-01-11T18:38:55Z

src/ch13-00-functional-features.md

+let a = [10, 20, 30, 40, 50];
+
+{
+    let result = match IntoIterator::into_iter(a) {


Should be IntoIterator::into_iter(a.iter()).

ah yes; I missed this, thanks

matthewjasper · 2017-01-11T18:39:14Z

src/ch13-00-functional-features.md

+            }
+        },
+    };
+    result


result has type () and is unnecessary AFAICT in this code. This probably needs explaining if it's there for a reason.

it's here because I copied it from our other docs, which say this is the correct de-surgaring. @eddyb?

Weird. It would be relevant for break value but that's not the case here. I'd remove result.

It's like this in the std::iter docs, should it be removed there too? or just here, to reduce some noise.

matthewjasper · 2017-01-11T18:43:45Z

src/ch13-00-functional-features.md

+mut iter => loop {
+```
+
+The `match` only has one arm: we match the result, binding it to a mutable


I think you should explain why a let binding isn't used.

matthewjasper · 2017-01-11T19:14:14Z

src/ch13-00-functional-features.md

+};
+```
+
+### Accepting closures as arguments with the `Fn` traits


Should this be earlier as it's what happens to closures most of the time?

Mmm I'm not sure. I'll think about it.

matthewjasper · 2017-01-11T20:18:24Z

src/ch13-00-functional-features.md

+that's can be converted into an iterator to a `for` loop, and it will
+just work. That's nice! However, arrays do not implement `IntoIterator`,
+and so we had to call the `iter` method ourself. But since that returns
+an iterator, calling `into_iter` on it does nothing, so we're still good!


Should it be explicit that IntoIterator is blanket implemented for all iterators?

matthewjasper · 2017-01-11T20:48:52Z

src/ch13-00-functional-features.md

+refer to things in its environment by reference. If you mutate the environment,
+you must use `FnMut`, and if you take ownership of the environment, `FnOnce`.
+Most of the time, you can write `Fn`, and then the compiler will tell you if
+you need `FnMut` or `FnOnce`.


This is when you try to call the function taking the closure, so I'm not sure that if this is really true.

True. I'll clear this up :)

matthewjasper · 2017-01-11T22:56:01Z

src/ch13-00-functional-features.md

+## Closures and their environment
+
+We've learned that functions can only use variables that are in scope, either
+by being static or being declared as parameters. But closures can do more.


It is clear enough that this is talking about const? static hasn't been mentioned yet.

Very true, I'll change this to say const instead!

yalinglee · 2017-01-13T18:51:51Z

src/ch13-00-functional-features.md

 ## Closures

-### What is a closure
+Rust gives you the ability to define *closures*, which are sort of like
+functions. Instead of giving you a technical definintion, let's dive into


extra n in definintion

yalinglee · 2017-01-13T18:56:59Z

src/ch13-00-functional-features.md

+assert_eq!(2, plus_one(1));
+```
+
+But we dont have to. Why is this? Functions are part of an explicit interface


missing ' in dont

yalinglee · 2017-01-13T18:59:51Z

src/ch13-00-functional-features.md

+
+Small differences, but they're similar. Why come up with a different syntax
+for closures? There's one additional way in which they're different from
+functions: they posses an 'environment'.


missing another s in posses

yalinglee · 2017-01-13T19:10:42Z

src/ch13-00-functional-features.md

+
+So in this case, our closure took a mutable reference to `num`, and then when
+we called `add_num`, it mutated the underlying value, as we'd expect. We also
+needed to declare `add_num` as `mut` too, because were mutating its


missing ' in were

yalinglee · 2017-01-13T19:11:08Z

src/ch13-00-functional-features.md

+needed to declare `add_num` as `mut` too, because were mutating its
+environment.
+
+If we change to a `move` closure, its different:


missing ' in its

yalinglee · 2017-01-13T19:17:04Z

src/ch13-00-functional-features.md

+```
+
+This example doesn't compile, becuase `x` doesn't have a long enough lifetime.
+Becuase closures may borrow variables from their enclosing scope, we can


Becuase should be Because

yalinglee · 2017-01-13T19:18:12Z

src/ch13-00-functional-features.md

+}
+```
+
+This example doesn't compile, becuase `x` doesn't have a long enough lifetime.


becuase -> because

yalinglee · 2017-01-13T19:18:28Z

src/ch13-00-functional-features.md

+type. In this case, our closure takes an `i32` as an argument and returns an
+`i32`, and so the generic bound we use is `Fn(i32) -> i32`.
+
+Why a trait? Well, each closure has a unique type. Becuase of this, we can't


Becuase -> Because

yalinglee · 2017-01-16T08:02:09Z

src/ch13-00-functional-features.md

+}
+```
+
+Not too bad! So which style should you chose? Most Rust programmers prefer to


chose -> choose

yalinglee · 2017-01-16T08:09:42Z

src/ch13-00-functional-features.md

+something that often needs to be done very quickly, so you care about speed.
+But here, we're creating an iterator, using two adaptors, and then finally
+consuming the value. What would this code compile to? Well, as of this writing,
+this, it compiles down to the same assembly you'd write by hand: there's no


redundant this?

yalinglee · 2017-01-16T08:10:31Z

src/ch13-00-functional-features.md

+3. Use the `collect` adaptor to consume the iterator and make a new vector.
+
+That's how we end up with `[2, 3, 4]`. As you can see, closures are a very
+important part of using iterators; they provide the way of customizing the


the way of -> a way of?

yalinglee · 2017-01-16T08:11:06Z

src/ch13-00-functional-features.md

+`IntoIterator` is another trait that we haven't discussed yet. As the name
+suggests, it has an `into_iter` method that takes one argument, and turns
+that argument into an `Iterator`. This means that we can pass anything
+that's can be converted into an iterator to a `for` loop, and it will


that's -> that

yalinglee · 2017-01-16T08:11:32Z

src/ch13-00-functional-features.md


-Talk about using Associated Types here, foreshadow to advanced type systems
-chapter about why this is a different thing than normal
+Let's talk a bit more about `IntoIterator`. As we said above, it's job is to


it's job -> its job

yalinglee · 2017-01-16T08:12:21Z

src/ch13-00-functional-features.md

+sums that are less than 100, and then finally, take the first five of those
+numbers. Finally, `sum` will add up all of the numbers into one last number.
+This is kind of a silly calculation, but it shows off a few different iterator
+adaptors, you can do all kinds of things! Check the documentation of `Iterator`


you can do all kinds of things! should be a new sentence?

yalinglee · 2017-01-16T08:12:51Z

src/ch13-00-functional-features.md

+```
+
+We take one parameter, and it has the type `F`. We also return an `i32`. This
+part isnt interesting. The next part is:


isnt -> isn't

carols10cents · 2017-01-18T03:34:39Z

Not done yet, I'm only through the Closures section and took care of some of the spelling/grammar comments throughout.

carols10cents · 2017-01-19T00:21:48Z

Pulling this out of a collapsed thread where @steveklabnik said:

it [move] copies but it does not Copy. (aka words are hard)

Ok this is the part that has me confused. If I change the i32 to String, which is NOT Copy, then this code does not compile:

let mut num = String::from("four");

{
    let mut add_num = move |x| num.push_str(x);

    add_num("six");
}

assert_eq!(String::from("four"), num);

says:

error[E0382]: use of moved value: `num`
  --> src/main.rs:11:34
   |
6  |     let mut add_num = move |x| num.push_str(x);
   |                       -------- value moved (into closure) here
...
11 | assert_eq!(String::from("four"), num);
   |                                  ^^^ value used here after move
   |
   = note: move occurs because `num` has type `std::string::String`, which does not implement the `Copy` trait

... which implies to me that, contrary to what steve said, this DOES Copy, since it only works at all if the value is Copy.

Am I misunderstanding more...? How should we change this sentence to be clearer?

In the last line, num now contains 4: add_num took ownership of a copy of num, rather than mutably borrowing num.

eddyb · 2017-01-20T04:49:22Z

Heh. It "moves" captures into the closure value, but you can't ever move away a Copy value.
Yes the use of the keyword is pretty terrible.

carols10cents · 2017-01-22T03:20:39Z

src/ch13-00-functional-features.md

+texts of various sizes, different words, words of different lengths, and all
+kinds of other things. The point here is this: iterators, while a high-level
+abstraction, get compiled down to roughly the same code as if you'd written
+the lower-level code yourself.


uggghhh i want to cite stroustrup accurately here but i can't find exactly where he said the part about not being able to hand code it any better... like https://blog.rust-lang.org/2015/05/11/traits.html cites stroustrup citing himself that i think i saw on some powerpoint???

yeah this http://www.stroustrup.com/ETAPS-corrected-draft.pdf

carols10cents · 2017-01-22T21:07:30Z

Heh. It "moves" captures into the closure value, but you can't ever move away a Copy value.
Yes the use of the keyword is pretty terrible.

@eddyb How should we change this sentence to be clearer:

In the last line, num now contains 4: add_num took ownership of a copy of num, rather than mutably borrowing num.

carols10cents · 2017-01-22T21:15:37Z

@steveklabnik and anyone else who wants to reread this: I think I'm done. Any suggestions before I send this to nostarch sometime Monday?

matthewjasper

One last thing, apart from what I've already said. And a typo.

matthewjasper · 2017-01-22T22:09:52Z

src/ch13-01-closures.md

+fn main() {
+    let f1 = Foo;
+    let closure_that_borrows = |x| borrows(x);
+    closure_that_borrows(&f1);


And then this should be

let f1 = Foo; let closure_that_borrows = || borrows(&f1); // Maybe even a comment that `f1` is now borrowed? closure_that_borrows();

to match the above description.
Likewise with the next two.

matthewjasper · 2017-01-22T22:32:34Z

src/ch13-02-iterators.md

+<!-- Will add wingdings in libreoffice /Carol -->
+
+The `iter` method on vectors allows us to produce an *iterator* from the
+vector. Nex, the `map` method called on the iterator allows us to process each


Just a typo, but CI didn't catch 'Nex'. Or maybe I'm misunderstanding something.

Oh i totally meant the Navy Exchange, yup (thank you for catching this :))

matthewjasper · 2017-01-22T22:49:02Z

src/ch13-01-closures.md

+The compiler even reminds us that this only works with closures!
+
+### Closures, Ownership, and Borrowing
+


This section is surely supposed to be about inference of capture borrowing, but then seems to get confused about parameter type inference. The changes I'm suggesting are assuming that it's about captures. If it's really supposed to about parameters, why?

It's entirely possible that I'm confused.

matthewjasper · 2017-01-22T22:52:06Z

src/ch13-01-closures.md

+The property of being allowed to use variables from the surrounding scope is
+also subject to all of the usual rules around ownership and borrowing. Since
+closures attempt to infer the types of their parameters, they also infer how
+those parameters are borrowed. Closures make that inference by looking at how


This sentence would then be something like 'Closures attempt to infer how the variables from their environment are borrowed.'

matthewjasper · 2017-01-22T23:01:04Z

src/ch13-01-closures.md

+`&Foo`, then the type of the parameter must be `&Foo`. If it passes the
+parameter to a function that takes `&mut Foo`, then the type of parameter must
+be `&mut Foo`, and so on. If we try to use `f3` after the call to
+`closure_that_moves` in the last line of `main`, we'll get a compiler error


In fact, after closure_that_moves is defined.

matthewjasper · 2017-01-22T23:01:05Z

src/ch13-01-closures.md

+
+Here, Rust is able to look at how we use the parameters of each closure inside
+their bodies. If the closure passes its parameter it to a function that takes
+`&Foo`, then the type of the parameter must be `&Foo`. If it passes the


Should be something like 'If the closure only uses borrows of a variable from the enclosing scope, then it will only capture the reference rather than take ownership of the value'.
And similarly for the next two.

matthewjasper · 2017-01-22T23:54:53Z

src/ch13-03-improving-our-io-project.md

+the `match` expressions for `search` and `filename` are so similar. It would be
+nice if we could use `?` on the `Option` returned from `next`, but `?` only
+works with `Result` values currently. Even if we could use `?` on `Option` like
+we can on `Result`, the value we would get would be borrowed, and we want to


Ok, one more thing. Why mention ?? And is this correct about borrowing?

This code is similar to the code for ?, so readers might be wondering if you can use ? here. Also, someday you probably will be able to.

That makes sense. I was concerned that the (possible) future feature was the only reason.

steveklabnik

extremely minor nits, but we're good to go after

steveklabnik · 2017-01-23T18:56:12Z

src/ch13-00-functional-features.md

+Rust's design has taken inspiration from a lot of previous work. One of Rust's
+influences is functional programming, where functions are values that can be
+used as arguments or return values to other functions, assigned to variables,
+and so forth. We're going to sidestep the issue of what, exactly, function


steveklabnik · 2017-01-23T18:57:40Z

src/ch13-01-closures.md

+```rust
+fn  add_one_v1   (x: i32) -> i32 { x + 1 }  // a function
+let add_one_v2 = |x: i32| -> i32 { x + 1 }; // the full syntax for a closure
+let add_one_v3 = |x: i32|        { x + 1 }; // a closure eliding types


the : i32 should be removed here too

steveklabnik · 2017-01-23T19:01:48Z

src/ch13-03-improving-our-io-project.md

+        let search = match args.next() {
+            Some(arg) => arg,
+            None => return Err("Didn't get a search string"),
+	    };


this needs another indent

steveklabnik · 2017-01-23T19:01:55Z

src/ch13-03-improving-our-io-project.md

+        let filename = match args.next() {
+            Some(arg) => arg,
+            None => return Err("Didn't get a file name"),
+	    };


as does this

carols10cents · 2017-01-24T02:49:17Z

I merged this in but then rebased so github couldn't tell

steveklabnik mentioned this pull request Jan 10, 2017

Wrote part of Ch 13, closures and iterators #381

Closed

AdamCDunlap and others added 7 commits January 10, 2017 16:08

Adding information on closures and iterators

af95273

Not well edited and doesn't have everything about iterators

Minor grammar fix

5b2bf6d

Updating text wrapping

f1d7eea

Clarifications/typos

0cdc0dd

Fix spelling errors

eaa6b80

word wrap and tweak a bit

fcf95cd

First draft of the iterators chapter

e0db513

steveklabnik force-pushed the iterators branch from 4fc9f99 to e0db513 Compare January 10, 2017 21:08

sophiajt reviewed Jan 10, 2017

View reviewed changes

sophiajt reviewed Jan 11, 2017

View reviewed changes

matthewjasper reviewed Jan 11, 2017

View reviewed changes

yalinglee reviewed Jan 13, 2017

View reviewed changes

yalinglee reviewed Jan 16, 2017

View reviewed changes

carols10cents added 2 commits January 17, 2017 22:11

Edits to the intro and Closures section

09dd956

Fix spelling, grammar, and other small stuff

118124d

carols10cents self-assigned this Jan 18, 2017

Add another spelling and ignoring

a37a6bd

carols10cents reviewed Jan 22, 2017

View reviewed changes

carols10cents added 2 commits January 22, 2017 15:44

More edits

117f3d8

Clarify what happens when iteration is done

e3a1744

carols10cents added 2 commits January 22, 2017 16:09

Add more words to the dictionary

fa861f7

Break into sections

851bd9f

matthewjasper reviewed Jan 22, 2017

View reviewed changes

Fix typos

528c2c9

steveklabnik commented Jan 23, 2017

View reviewed changes

carols10cents added 3 commits January 23, 2017 14:34

Fixing steve nits

f033a6f

Move (pun intended) closure env capture/borrowing/etc to concurrency

231932a

Ignore this test now

1a60421

carols10cents closed this Jan 24, 2017

carols10cents deleted the iterators branch January 24, 2017 02:49


		Closures don't have any further performance penalty over regular fn calls
		This code sample is taken from an audio decoder. It "restores sample values

		The compiler even reminds us that this only works with closures!

		### Closures, Ownership, and Borrowing

Iterators #395

Iterators #395

Conversation

steveklabnik commented Jan 10, 2017

steveklabnik commented Jan 10, 2017

ruuda commented Jan 10, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sophiajt commented Jan 11, 2017

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

steveklabnik Jan 11, 2017 • 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

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

matthewjasper 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

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

steveklabnik Jan 17, 2017 • 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

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

Choose a reason for hiding this comment

carols10cents commented Jan 18, 2017

carols10cents commented Jan 19, 2017 • edited Loading

eddyb commented Jan 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents commented Jan 22, 2017

carols10cents commented Jan 22, 2017

matthewjasper left a comment

steveklabnik Jan 11, 2017 •

edited

Loading

steveklabnik Jan 17, 2017 •

edited

Loading

carols10cents commented Jan 19, 2017 •

edited

Loading

matthewjasper Jan 22, 2017 •

edited

Loading