go-counting: Add single-territory function to README; Add canonical data #1195

jssander · 2018-02-22T20:30:37Z

Closes #560

Here is a canonical data file for the go-counting exercise. I have a couple questions:

Why are some parts highlighted in red? Also should I specify that the expected territory should be a set and not an array?

cmccandless · 2018-02-22T20:43:22Z

exercises/go-counting/canonical-data.json

+        "y": 1
+      },
+      "expected": {
+        "stone": BLACK


A couple notes on syntax:

Values must be one of: string (with quotes), number, array ([...]), object ({ ... })

Values must be followed by a comma unless it is the last value in the current array/object

cmccandless · 2018-02-22T20:43:33Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "stone": BLACK
+        "territory": [(0, 0), (0, 1), (1, 0)]


Tuples are not supported by JSON.

cmccandless · 2018-02-22T20:44:40Z

@jssander

Also should I specify that the expected territory should be a set and not an array?

The use of sets is an implementation detail, so arrays are better for the canonical-data.

rpottsoh · 2018-02-22T20:45:51Z

exercises/go-counting/canonical-data.json

+        "y": 1
+      },
+      "expected": {
+        "stone": BLACK


BLACK is probably hi-lighted because it should probably be in "'s and should have a trailing , on the line

rpottsoh · 2018-02-22T20:49:01Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "stone": BLACK
+        "territory": [(0, 0), (0, 1), (1, 0)]


I think this wants to be:

"territory": [[0,0], [0,1], [1,0]]

Are you trying to portray an array of tuples? I am not sure if it is really possible to convey a tuple in JSON.

petertseng · 2018-02-22T20:49:47Z

Please edit the PR description and amend the commit message to use one of the words in https://help.github.com/articles/closing-issues-using-keywords/ and https://github.com/exercism/problem-specifications/issues/560 (#560) so that it will automatically close that issue when this PR is merged. We wouldn't want us to forget to do that.

rpottsoh · 2018-02-22T20:51:56Z

exercises/go-counting/canonical-data.json

+        "y": 3
+      },
+      "expected": {
+        "stone": WHITE


"stone": "WHITE",

rpottsoh · 2018-02-22T20:52:47Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "stone": WHITE
+        "territory": [(2, 3)]


"territory": [[2, 3]]

rpottsoh · 2018-02-22T20:53:31Z

exercises/go-counting/canonical-data.json

+        "y": 4
+      },
+      "expected": {
+        "stone": NONE


"stone": "NONE",

rpottsoh · 2018-02-22T20:54:16Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "stone": NONE
+        "territory": [(0, 3), (0, 4), (1, 4)]


"territory": [[0, 3], [0, 4], [1, 4]]

rpottsoh · 2018-02-22T20:55:10Z

exercises/go-counting/canonical-data.json

+        "y": 1
+      },
+      "expected": {
+        "stone": NONE


"stone": "NONE",

rpottsoh · 2018-02-22T21:02:29Z

exercises/go-counting/canonical-data.json

+        "y": 1
+      },
+      "expected": {
+        "stone": NONE


"stone": "NONE",

rpottsoh · 2018-02-22T21:03:04Z

exercises/go-counting/canonical-data.json

+        "y": 5
+      },
+      "expected": {
+        "stone": NONE


"stone": "NONE",

rpottsoh · 2018-02-22T21:03:35Z

exercises/go-counting/canonical-data.json

+		],
+      },
+      "expected": {
+        "TerritoryBlack": []


should have a , at EOL.

rpottsoh · 2018-02-22T21:03:56Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "TerritoryBlack": []
+        "TerritoryWhite": []


should have a , at EOL. "territoryWhite", use lowerCamelCase.

rpottsoh · 2018-02-22T21:05:55Z

exercises/go-counting/canonical-data.json

+      "expected": {
+        "TerritoryBlack": []
+        "TerritoryWhite": []
+	"TerritoryNone": [(0, 0)]


"territoryNone": [[0, 0]]

Note use of lowerCamelCase. Be careful of the indentation too.

rpottsoh · 2018-02-22T21:08:47Z

exercises/go-counting/canonical-data.json

+        "TerritoryBlack": [(0, 0), (0, 1)]
+        "TerritoryWhite": [(3, 0), (3, 1)]
+	"TerritoryNone": []
+      }


"expected": { "territoryBlack": [[0, 0], [0, 1]], "territoryWhite": [[3, 0], [3, 1]], "territoryNone": [] }

rpottsoh · 2018-02-22T21:10:15Z

exercises/go-counting/canonical-data.json

+      },
+      "expected": {
+        "stone": NONE
+        "territory": [(2, 7), (2, 8), (1, 8), (0, 8), (0, 7)]


"stone": "NONE", "territory": [[2, 7], [2, 8], [1, 8], [0, 8], [0, 7]]

rpottsoh · 2018-02-22T21:11:25Z

problem description.

jssander · 2018-02-22T21:17:26Z

Thanks for all the comments, I'll make all the changes. Sorry for all the problems.

rpottsoh · 2018-02-22T21:20:36Z

@jssander this looks like a good start, thanks for taking on the challenge and deciding to help out.

I have created a gist of your canonical data file. The left-hand pane is the JSON schema used by Exercism to confirm that canonical data files are formatted properly. In the right-hand pane is your submitted JSON. Feel free to paste your JSON into this window as you go to check it against the schema. The same check is also made when you commit.

rpottsoh · 2018-02-22T21:40:59Z

No problems. Sent from my android device.

petertseng · 2018-02-23T01:45:18Z

I plan to verify with code similar to the following.

require 'json'
require_relative '../../verify'

json = JSON.parse(File.read(File.join(__dir__, 'canonical-data.json')))

cases = by_property(json['cases'], %w(territory territories))

class UnionFind
  def initialize(things)
    @parent = things.map { |x| [x, x] }.to_h
    @rank = things.map { |x| [x, 0] }.to_h
    @frozen = false
  end

  def keys
    @parent.keys
  end

  def union(x, y)
    raise FrozenError if @frozen
    xp = find(x)
    yp = find(y)

    return if xp == yp

    if @rank.fetch(xp) < @rank.fetch(yp)
      @parent[xp] = yp
    elsif @rank.fetch(xp) > @rank.fetch(yp)
      @parent[yp] = xp
    else
      @parent[yp] = xp
      @rank[xp] += 1
    end
  end

  def find(x)
    @parent[x] = find(@parent.fetch(x)) if @parent.fetch(x) != x
    @parent.fetch(x)
  end

  def freeze
    @frozen = true
    self
  end
end

module EachGridPair refine Array do
  def each_grid_pair
    each_with_index { |row, y|
      row.each_char.with_index { |c, x|
        [[y + 1, x], [y, x + 1]].each { |y2, x2|
          next unless (c2 = self[y2]&.[](x2))
          yield c, [y, x], c2, [y2, x2]
        }
      }
    }
  end
end end

using EachGridPair

def territories(board)
  uf = UnionFind.new(board.each_with_index.flat_map { |row, y| row.size.times.map { |x| [y, x] } })
  board.each_grid_pair { |c1, place1, c2, place2|
    uf.union(place1, place2) if c1 == ' ' && c2 == ' '
  }
  uf.freeze
  regions = uf.keys.group_by { |k| uf.find(k) }
  colours = regions.keys.map { |k| [k, [false, false]] }.to_h
  board.each_grid_pair { |c1, place1, c2, place2|
    next if (c1 == ' ') == (c2 == ' ')
    place = c1 == ' ' ? place1 : place2
    colour = [c1, c2].sort.last == ?B ? 0 : 1
    colours.fetch(uf.find(place))[colour] = true
  }
  colours.transform_values! { |black, white|
    (black && !white ? 'BLACK' : white && !black ? 'WHITE' : nil).freeze
  }
  regions.map { |parent, v|
    y, x = parent
    [parent, {
      # TODO: call this colour instead?
      'stone' => colours.fetch(parent),
      'territory' => v,
    }] if board[y][x] == ' '
  }.compact.to_h.freeze
end

verify(cases['territory'], property: 'territory') { |i, _|
  territories(i['board']).values.find { |t|
    t['territory'].include?([i[?y], i[?x]])
  }
}

verify(cases['territories'], property: 'territories') { |i, _|
  # TODO: Type subject to discussion of multiple territories of a given colour.
  territories(i['board']).values
}

If for some reason I should become unavailable, feel free to verify in my stead. I would highly suggest that verification be performed before merging.

jssander · 2018-02-23T15:19:00Z

I think I made all the changes mentioned, but it still doesn't seem to be proper JSON.

rpottsoh · 2018-02-23T15:19:17Z

exercises/go-counting/canonical-data.json

-	"TerritoryNone": [(0, 0)]
+        "territoryBlack": [],
+        "territoryWhite": [],
+	"territoryNone": [[0, 0]]


Watch the indents on the "territoryNone":'s. they should be the same as the two above.

Is this why it is not valid JSON? Or is there some other problem?

rpottsoh · 2018-02-23T15:26:36Z

It appears as though you have a mix of tabs and spaces to for indenting. It would be easier to read through the file if the tabs were replaced with a sufficient number of spaces. Tabs mean different things in different editors, it isn't always the same number of spaces.

rpottsoh · 2018-02-23T15:37:01Z

exercises/go-counting/canonical-data.json

+      "input": {
+        "board": [
+		    " "
+		],


, not necessary.
Try www.jsonlint.com. It will help point out where the syntax is wrong.

rpottsoh · 2018-02-23T15:37:37Z

exercises/go-counting/canonical-data.json

+        "board": [
+		    " BW ",
+		    " BW "
+		],


, not needed.

jssander · 2018-02-23T15:41:21Z

Thanks for all the help and patience. It passes the checks now.

petertseng · 2018-02-23T22:08:01Z

exercises/go-counting/canonical-data.json

+      "description": "Black corner territory on 5x5 board",
+      "property": "territory",
+      "input": {
+      "board": [


I realise that I gave bad advice. Since this is a k/v pair under input, I would indent the board line and all the strings making up the board two spaces in

petertseng · 2018-02-23T22:08:35Z

exercises/go-counting/canonical-data.json

+        "B W B",
+        " W W ",
+        "  W  "
+                 ],


I would align this with the same column that "board" is; same with all other closing bracket lines

"input": { "board": [ "stuff" ], "x": 0, }

petertseng · 2018-02-25T22:11:32Z

I haven't put in the comment saying which coordinate goes first (x or y). Would you like me to do that

Whichever of [y, x] or [x, y] you choose, I think it will be necessary to put a comment in, yes. So that it is clear to readers of this file.

and change it so it goes [y, x] instead of [x, y]?

I think last time I argued that [y, x] matches how a computer would index into the board, right? On the other hand, I think I also recall from education that [x, y] more closely matches the conventional way humans choose to designate a coordinate in 2d space? It is not a perfect analogy though since I think in such a conventional coordinate system y is increasing as you go up, but in this file y is increasing as you go down.

Unless someone comes forward with more arguments as to whether it is desirable to perfer one or the other, I don't object to either. Maybe someone wishes to retrieve some arguments from #313 .

jssander · 2018-02-26T16:03:01Z

I left it as [x, y], but put in a comment about it. I also changed the indentation.

petertseng

Great stuff.

I am wondering whether the usage of the term "territory" is a little inconsistent. In the territory property, we consider it a contiguous region of spaces surrounded by stones. In the territories property, we consider it the union of all such contiguous regions, such that they are no longer contiguous. Would someone give me a way of thinking about this that makes everything make sense as-is?

If not, then I would think the expected result for all territories cases should change to be one of the two possibilities described in #1195 (comment) .

To give meaning to this discussion, I think a board such as [" B "] should be added as a territories test case; it is useful because the territory for a given player is two regions which aren't connected to each other, something not yet seen in any territories case.

petertseng · 2018-02-27T01:01:24Z

exercises/go-counting/canonical-data.json

+      }
+    },
+    {
+      "description": "Invalid coordinate on 5x5 board",


Would it be better to explain in what way the coordinate is invalid? Here, it is because X is too low.

petertseng · 2018-02-27T01:01:52Z

exercises/go-counting/canonical-data.json

+      }
+    },
+    {
+      "description": "Invalid coordinate #2 on 5x5 board",


Would it be better to explain in what way the coordinate is invalid, so that it is clearer than "#2"? Here, it is because Y is too high.

petertseng · 2018-02-27T01:05:50Z

exercises/go-counting/canonical-data.json

+      "property": "territories",
+      "input": {
+        "board": [
+                    " "


let's re-indent to match the other boards

petertseng · 2018-02-27T01:26:24Z

exercises/go-counting/canonical-data.json

+      }
+    },
+    {
+      "description": "Open corner territory on 9x9 board",


I wasn't sure what this case tests that (for territory) that any previous cases don't. I know the board is larger, but I don't think that adds any extra considerations to the algorithm. May I ask if any insight can be gleaned from any of the four implementing tracks (http://exercism.io/contribute/canonical-data/go-counting C# F# Haskell Python) why they have this test, what it does for them?

If there is nothing new being tested, I would actually think it should be removed.

jssander · 2018-02-27T21:26:41Z

Ok, I remove the 9x9 board test, fixed an indentation, made the two invalid coordinate test case descriptions clearer, and added a test case for the " B " board. I haven't done anything about the "territory" term problem yet.

petertseng

added a test case for the " B " board

Fantastic, thank you! With this case, we can more easily gather opinions on what the answer should be. I see a few choices:

The existing answer: Combine all territories into one, without regard to whether they are connected:

{
  "territoryBlack": [[0, 0], [2, 0]],
  "territoryWhite": [],
  "territoryNone": []
}

Group contiguous regions into their own lists:

{
  "territoryBlack": [[[0, 0]], [[2, 0]]],
  "territoryWhite": [],
  "territoryNone": []
}

Use an array whose element type is the same as the expected answer to territory

[
  {
    "owner": "BLACK",
    "territory": [[0, 0]]
  },
  {
    "owner": "BLACK",
    "territory": [[2, 0]]
  }
]

Warning: If nobody expresses an opinion in a week, I will Approve (in the GitHub sense!!) any correct submission of any of the above three choices. If you care which choice is used, you must speak up.

petertseng · 2018-02-27T21:33:37Z

exercises/go-counting/canonical-data.json

      },
      "expected": {
-        "owner": "NONE",
-        "territory": [[2, 7], [2, 8], [1, 8], [0, 8], [0, 7]]
+        "territoryBlack": [[0, 0], [0, 2]],


inconsistent: This uses [y, x] coordinate instead of [x, y], since a y coordinate of 2 does not exist (the x coordinate should be 2).

petertseng · 2018-03-01T20:28:06Z

I prepared code to verify any of the three possible expected types, so as before I will leave instructions to verify this PR in case I become unable to do so: Someone who wants to verify this PR should replace the last four lines of the verify script and specify the output type we decided to use.

The current type in the submitted JSON is by_owner_combined. (As I pointed out in my earlier review, the currently submitted JSON does not verify, so I can't Approve yet)

verify(cases['territories'], property: 'territories') { |i, _|
  default = {
    'territoryBlack' => [],
    'territoryWhite' => [],
    'territoryNone' => [],
  }

  case which_output_type_should_we_use = :by_owner_combined
  when :array_of_territory
    territories(i['board'])
  when :by_owner
    default.merge(territories(i['board']).group_by { |t| t['owner'] }.map { |k, vs|
      ['territory' + k.capitalize, vs.map { |t| t['territory'] }.sort.freeze]
    }.to_h)
  when :by_owner_combined
    default.merge(territories(i['board']).group_by { |t| t['owner'] }.map { |k, vs|
      ['territory' + k.capitalize, vs.flat_map { |t| t['territory'] }.sort.freeze]
    }.to_h)
  end
}

jssander · 2018-03-03T20:12:57Z

Ok I fixed the x/y coordinate pair order for one of the tests and added tests for x and y being too high or too low.

rpottsoh · 2018-03-03T21:06:01Z

Sorry for bringing it up so late. The change to description.md should probably be in its own commit and / or the title of the PR should be updated as it is no longer just implementing canonical test data for this exercise. Perhaps the title could state that this PR is updating the documentation for this exercise. The PR should only be attempting to accomplish one task.

rpottsoh · 2018-03-03T21:08:11Z

exercises/go-counting/canonical-data.json

+      }
+    },
+    {
+      "description": "Invalid because Y is too high for 5x5 board",


This looks good, thanks for making this change.

jssander · 2018-03-03T21:27:35Z

I updated the title of the PR. Do you still want me to put the changes to description.md in a different commit? Can I keep it in the same PR?

rpottsoh · 2018-03-03T23:44:06Z

I think it is ok as you have things now. I wouldn't worry about it unless any one else has a different opinion. Thanks for updating the PR title.

the JSON file now verifies.

petertseng · 2018-03-04T00:12:29Z

This file now verifies. This means that my Request for Changes is hereby dismissed.

Reminder: In a little over 3 days, it will have been one week since I submitted #1195 (review) which asks for opinions on which expected type to use for territories. Reviewers have until that time to express an opinion. If no opinion is expressed, I will make the choice of "arbitrary i.e. whatever the author of the JSON file chooses" which means I will Approve this PR in its current state.

petertseng

As discussed earlier, I choose "arbitrary; whatever consistent and correct answer the submitter chooses" for the type of territories.

petertseng · 2018-03-07T19:00:15Z

I hope you will not consider it presumptuous that I dismiss #1195 (review). It should be easy to see why I am doing so: The review mentions invalid JSON syntax, and the syntax is valid today.

All implementing tracks have this function, but it is never mentioned.

Closes #560 Implementing tracks (4): * https://github.com/exercism/csharp/tree/master/exercises/go-counting * https://github.com/exercism/fsharp/tree/master/exercises/go-counting * https://github.com/exercism/haskell/tree/master/exercises/go-counting * https://github.com/exercism/python/tree/master/exercises/go-counting

rpottsoh

Thanks again @jssander 👍

petertseng · 2018-03-07T21:20:08Z

Great job, thank you.

jssander · 2018-03-07T21:21:41Z

You're welcome. Thank you for merging.

cmccandless · 2018-03-08T14:50:49Z

exercises/go-counting/canonical-data.json

+      }
+    },
+    {
+      "description": "A stone and not a territory on 5x5 board",


@jssander @petertseng I know this PR has already been merged, but should this be "A stone is not a territory..."?

If you want. I admit I don't see a reason to prefer one or the other, but that could just be because of English not being my first language. I'm happy to defer to others on this matter.

go-counting 1.0.0.3: Match new canonical data exercism/problem-specifications#1195

cmccandless previously requested changes Feb 22, 2018

View reviewed changes

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"y": 3

},

"expected": {

"stone": WHITE

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"stone": "WHITE",

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

},

"expected": {

"stone": WHITE

"territory": [(2, 3)]

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"territory": [[2, 3]]

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"y": 4

},

"expected": {

"stone": NONE

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"stone": "NONE",

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"y": 1

},

"expected": {

"stone": NONE

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"stone": "NONE",

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"y": 1

},

"expected": {

"stone": NONE

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"stone": "NONE",

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"y": 5

},

"expected": {

"stone": NONE

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"stone": "NONE",

rpottsoh reviewed Feb 22, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

],

},

"expected": {

"TerritoryBlack": []

Copy link

Member

rpottsoh Feb 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should have a , at EOL.

rpottsoh reviewed Feb 22, 2018

View reviewed changes

rpottsoh changed the title ~~add go-counting canonical data file~~ go-counting: add canonical data Feb 22, 2018

rpottsoh changed the title ~~go-counting: add canonical data~~ go-counting: Implement canonical-data.json Feb 22, 2018

rpottsoh reviewed Feb 23, 2018

View reviewed changes

exercises/go-counting/canonical-data.json Outdated

"board": [

" BW ",

" BW "

],

Copy link

Member

rpottsoh Feb 23, 2018 •

edited

Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

, not needed.

petertseng reviewed Feb 23, 2018

View reviewed changes

petertseng suggested changes Feb 27, 2018

View reviewed changes

petertseng previously requested changes Feb 27, 2018

View reviewed changes

rpottsoh reviewed Mar 3, 2018

View reviewed changes

jssander changed the title ~~go-counting: Implement canonical-data.json~~ go-counting: Updating documentation Mar 3, 2018

petertseng approved these changes Mar 7, 2018

View reviewed changes

FridaTveit mentioned this pull request Mar 7, 2018

go-counting: add new exercise exercism/java#1351

Merged

jssander added 2 commits March 7, 2018 11:02

go-counting: Add single-territory function to README

56c7a3d

All implementing tracks have this function, but it is never mentioned.

rpottsoh approved these changes Mar 7, 2018

View reviewed changes

petertseng merged commit afbd817 into exercism:master Mar 7, 2018

cmccandless reviewed Mar 8, 2018

View reviewed changes

cmccandless mentioned this pull request Mar 8, 2018

go-counting: adapt tests to canonical data v1.0.0 exercism/python#1360

Merged

petertseng changed the title ~~go-counting: Updating documentation~~ go-counting: Add single-territory function to README; Add canonical data Mar 18, 2018

petertseng mentioned this pull request Mar 18, 2018

go-counting 1.0.0.3: Match new canonical data exercism/haskell#665

Merged

petertseng added a commit to exercism/haskell that referenced this pull request Mar 18, 2018

Merge pull request #665 from petertseng/go-counting

f9a14ba

go-counting 1.0.0.3: Match new canonical data exercism/problem-specifications#1195

go-counting: Add single-territory function to README; Add canonical data #1195

go-counting: Add single-territory function to README; Add canonical data #1195

Conversation

jssander commented Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmccandless commented Feb 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petertseng commented Feb 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rpottsoh Feb 22, 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

rpottsoh Feb 22, 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

rpottsoh commented Feb 22, 2018

jssander commented Feb 22, 2018

rpottsoh commented Feb 22, 2018

rpottsoh commented Feb 22, 2018 via email

petertseng commented Feb 23, 2018

jssander commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rpottsoh commented Feb 23, 2018

Choose a reason for hiding this comment

rpottsoh Feb 23, 2018 • edited Loading

Choose a reason for hiding this comment

jssander commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petertseng commented Feb 25, 2018

jssander commented Feb 26, 2018

petertseng 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

jssander commented Feb 27, 2018

petertseng left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petertseng commented Mar 1, 2018 • edited Loading

jssander commented Mar 3, 2018

rpottsoh commented Mar 3, 2018 • edited Loading

Choose a reason for hiding this comment

jssander commented Mar 3, 2018

rpottsoh commented Mar 3, 2018

petertseng commented Mar 4, 2018

petertseng left a comment

Choose a reason for hiding this comment

petertseng commented Mar 7, 2018

rpottsoh left a comment

Choose a reason for hiding this comment

petertseng commented Mar 7, 2018

jssander commented Mar 7, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jssander commented Feb 22, 2018 •

edited

Loading

rpottsoh Feb 22, 2018 •

edited

Loading

rpottsoh Feb 22, 2018 •

edited

Loading

rpottsoh Feb 23, 2018 •

edited

Loading

petertseng left a comment •

edited

Loading

petertseng commented Mar 1, 2018 •

edited

Loading

rpottsoh commented Mar 3, 2018 •

edited

Loading