tree-building: port #835

guygastineau · 2019-08-28T02:44:29Z

This doesn't point to a canonical-data.json file, because none exists: problem-specifications

I stole all of the tests from the go track. I think it would be good to have tests that verify it can handle more levels of recursion. go tests

I think I probably should have used Either instead of Maybe, but now we can have a discussion about what would be best.

This is a refactoring exercise. I might have made the gross version too gross, but it definitely can be refactored 🤣

I think that my correct solution could probably do with some refactoring too ;)

PS. I meant to send this up here last week, but I've been distracted by life itself. It feels good to get moving on this again ;)

guygastineau · 2019-08-28T02:51:09Z

So, I think the gross solution that is supposed to be shipped with the exercise for the student to refactor got too many linting suggestions and made the Travis build fail.

guygastineau · 2019-08-28T02:53:30Z

Actually a bunch of the linting warnings came from my clean solution too. I'll work on those.

@sshine do you know if that is why it failed?

guygastineau · 2019-08-28T03:37:15Z

Okay, so I got rid of the linting errors for the solution in examples/success-standard/src, but we should be expecting warnings from the sub-optimal solution given to the students to refactor.

This appears to be why it is failing unless I am misreading the report from Travis. Is there someway to exempt files that are for refactoring exercises?

guygastineau · 2019-08-28T03:47:44Z

I see that:

 hlint ${TRAVIS_BUILD_DIR} # Run `hlint` on the entire repository.

returns 1 as it's exit code if any warnings are given.

That seems like desirable behavior in general.

A number of the warnings I put in there intentionally, because they were redundant (to give some easy fixes during refactoring).

I suppose I could fix all of those problems. It would still all be in one giant nasty function.

Anyway, I will wait until I hear back from one of the core maintainers, before I decide on my next course of action here ;)

guygastineau · 2019-08-28T04:10:07Z

So I just discovered that I can disable Hlint for that single file.

If you all like the grotesqueness of the file that will be sent for refactoring, then I suppose that is one way to solve the issue.

sshine

Very nice job.

I thought of another solution that builds a Data.Map and then constructs the tree from that.

I think the stub that needs to be refactored looks fine. I don't have any ideas at this moment as to which kind of pitfalls to place in it beyond ones you've already placed. We can always reiterate on it later, if we like.

sshine · 2019-08-28T06:36:23Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+
+data Record = Record Id (Maybe Id) deriving (Eq, Show)
+
+data Tree = Leaf Id | Branch Id Children deriving (Eq, Show)


I'd go with Data.Tree from containers.

Nice. I'll look into that.

sshine · 2019-08-28T06:37:18Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+cycles = any checkRecord
+  where checkRecord r =
+          case r of
+            (Record i Nothing)  -> if' (i /= 0) True False


Suggested change

(Record i Nothing) -> if' (i /= 0) True False

Record i Nothing -> i /= 0

Oh yeah, that should be pretty obvious 😂

sshine · 2019-08-28T06:37:30Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+  where checkRecord r =
+          case r of
+            (Record i Nothing)  -> if' (i /= 0) True False
+            (Record i (Just p)) -> if' (p >= i) True False


Suggested change

(Record i (Just p)) -> if' (p >= i) True False

Record i (Just p) -> p >= i

sshine · 2019-08-28T06:44:02Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+              . map (\xs -> (recordParent (head xs), map recordId xs))
+              . groupBy parentsEq
+              . sortOn recordParent
+              . sortOn recordId


I think this will have the possibly unintuitive consequence that it'll primarily sort on recordParent and secondarily on recordId. An alternative is to sort with a combined function using the Monoid instance of Ordering described here:

sortBy $ \x y -> comparing recordParent x y `mappend` comparing recordId x y

or something similar...

sshine · 2019-08-28T06:44:58Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+-- General Tools
+
+if' :: Bool -> a -> a -> a
+if' p a b = if p then a else b


No longer necessary.

sshine · 2019-08-28T09:04:48Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+build :: [ParentGrouping] -> Maybe Tree
+build [] = Nothing
+build (x:xs)
+  | not . validRoot $ x = Nothing


Suggested change

| not . validRoot $ x = Nothing

| not (validRoot x) = Nothing

sshine · 2019-08-28T09:31:45Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+             in if not (null children)
+                then Branch yid (build' children)
+                else Leaf yid
+          ) (snd y)


This function is not exhaustive.

I might write it like:

build' :: [ParentGrouping] -> [Tree] build' [(_, yids)] = map Leaf yids build' ((_, yids):pgs) = map buildWithChildren yids where buildWithChildren yid = let children = [ child | child <- pgs, fst child == Just yid ] in if null children then Leaf yid else Branch yid (build' children)

And I might address that it's not exhaustive by concluding that it shouldn't be empty.

sshine · 2019-08-28T09:34:11Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+
+groupByParent :: [Record] -> [ParentGrouping]
+groupByParent = sortOn fst
+              . map (\xs -> (recordParent (head xs), map recordId xs))


import Control.Arrow ((&&&)) (\x -> (f x, g x)) = f &&& g

Suggested change

. map (\xs -> (recordParent (head xs), map recordId xs))

. map (recordParent . head &&& map recordId))

Nice. I haven't used the Control.Arrow library before. It is exciting to see it in action here.

I only really use &&&, ***, first and second from Control.Arrow, and the only arrow I ever think about is (,).

You may like to know that first and second actually live in two places nowadays: There is a better version in Data.Bifunctor. A bifunctor is considerably less scary than an arrow, I think.

sshine · 2019-08-28T09:38:31Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+-- verification
+succIdCheck :: [Record] -> Bool
+succIdCheck = all (\(x,y) -> succ x == y) . pairwise . sort . map recordId
+  where pairwise = zip <*> tail


I'm not sure why this check is necessary.

Can't a database skip IDs as long as they're monotonically increasing?

Probably. Taking all of the tests from the golang version of this exercise has the concequence of those tests incorporated simply by virtue of their being there.

I have not had to deal with the premis of this exercise in the real world. I suppose if users delete comments, then we could definitely end up with trees that have gaps, although a lit of forums seem to keep a marker that it is deleted.

I suppose that is what we have to think about here.
is this tree building for a system where users have the right to completely delete their comments? or is it creepy like facebook.?

sshine · 2019-08-28T09:42:10Z

exercises/tree-building/src/TreeBuilding.hs

+
+import Data.List
+import Data.Ord (comparing)
+--import Data.Maybe (fromMaybe)


I'm not sure an unused import is necessary in the stub.

Suggested change

--import Data.Maybe (fromMaybe)

sshine · 2019-08-28T10:09:21Z

I see that:
hlint ${TRAVIS_BUILD_DIR} # Run `hlint` on the entire repository.
returns 1 as it's exit code if any warnings are given. That seems like desirable behavior in general. A number of the warnings I put in there intentionally, because they were redundant (to give some easy fixes during refactoring).

You're quite right, with refactoring exercises we don't want hlint to fail in CI because of intentional mistakes. It should be possible to add a .hlint.yaml containing ignore directives:

- ignore: { within: [ TreeBuilding ] }

But I'm not sure how to distinguish the TreeBuilding of the stub with the TreeBuilding of the example solution. It's not possible to specify the directory in which to ignore a module, so perhaps we should look into replacing a repository-wide hlint . with local ones. I'm not really sure, though.

guygastineau · 2019-08-28T13:02:56Z

It appears like we can put the ignore rules in the stub file as ANN pragmas for it to apply specifically to that file.
hlint manual
Unfortunately there are no anchors on the site for # linking, but the info is near the bottom.

The only issue I see is that is would introduce a lot of clutter in the file, and we would probably need to add nformation in the README.md telling the student to remove these pragmas as they fix the problems.

guygastineau · 2019-08-28T13:05:05Z

I think I responded in some way to each thing 😆

I have to move a 1400 lb millingachine today, so I won't get any more work up until this evening in US/EST.

@sshine as always thank you very much for your constructive guidance 😁

petertseng · 2019-08-30T02:33:05Z

exercises/tree-building/examples/success-standard/package.yaml

@@ -0,0 +1,21 @@
+name:                tree-building
+version:             1.0.0.0


since there is no canonical-data.json, by what's written in https://github.com/exercism/haskell/blob/master/README.md#exercise-versioning please use 0.1.0.s instead of 1.0.0.s version numbers

Okay, cool. I wasn't sure of the protocol.

petertseng · 2019-08-30T02:36:27Z

exercises/tree-building/package.yaml

@@ -0,0 +1,21 @@
+name:                tree-building
+version:             1.0.0.0


since there is no canonical-data.json, by what's written in https://github.com/exercism/haskell/blob/master/README.md#exercise-versioning please use 0.1.0.s instead of 1.0.0.s version numbers

guygastineau · 2019-08-30T02:37:47Z

Just an update. I've been super busy recently, and I will be through Saturday.
Should get some time early next week to finish up on this project 😄

sshine · 2019-08-30T11:35:04Z

It appears like we can put the ignore rules in the stub file as ANN pragmas for it to apply specifically to that file.

I'm sorry that I didn't address this in my research: Yes, we could do that, but then we would distribute the pragma to the student, which would cause HLint to be disabled on their end, which we really don't want. So ideally we should find a workaround HLint not having an --ignore-file or --ignore-directory feature, which most likely will complicate the very neat hlint . at the root.

The long-term benefit we get from working out this part is that we make way for handing out stubs with warnings in them for other refactoring exercises. I think having obvious errors that HLint catches is a good basis for refactoring, since it encourages the use of HLint.

guygastineau · 2019-08-30T12:50:50Z

Okay, those are some compelling reasons to get this figured out the right way regarding hlint 😁

sshine

Here's another implementation and some thoughts regarding the stub and test files:

How about naming the stub file ForumThread.hs?
Subsequently, module ForumThread where ....
How about renaming newTree into fromList?
How about renaming Tree into ForumThread?

Your tests include a lot of bad input cases also present in the F# version in which no trees are produced. One could imagine they're a product of some bad SQL JOIN (in case of duplicates), SELECT (in case of wrong order), DELETE (in case of missing parents) or some wicked UPDATE (in case of cycles).

We assume that records are sorted and hope that duplicates and cycles don't occur. But if these promises are broken, it's really a problem in the producer of these records. I thought it might be interesting to deal a little differently with the various errors:

"Duplicate", "Duplicate root": Instead of failing to produce a tree, what we'd rather do in a production environment is discard the duplicate and log a warning. This could be an excellent opportunity to try the validation package ("A data-type like Either but with an accumulating Applicative") or the co-log package (production-grade logging framework): Accept threads with duplicates by discarding them, and encourage in a later iteration to add either cumulative error handling or logging of these.
"Non-continuous": We assume that records are sorted, but test what happens if the assumption is broken? How about either (1) not assume this and require sorting, or (2) not test this and assume that the bug is located outside the function we're writing? In case of (1) it's just as easy to sort as it is to handle the error, and in case of (2) it's even easier.
"Cycle Directly", "Cycle indirectly": We can disregard cycles by dealing with records ordered by their ID: Record x (Just y) is always invalid if x > y (y is at this point an unknown parent). Similarly to duplicates, we could simply discard records that can't be inserted because of an unknown parent and encourage error handling / logging in a later iteration.
"Higher id parent of lower id": Same as "Non-continuous": How about either (1) not assume records are sorted and require sorting, in which case this is not an error, or (2) not test this and assume that the bug is located outside the function we're writing. Maybe a bug like this could occur if a record was "moved" from one thread to another. Maybe this is an acceptable anomaly as long as it doesn't produce bad trees.

TL;DR:

Proposal: Discard duplicates and pseudo-cyclical records, change tests so they're positive edge cases rather than negative cases.
Proposal: Either assume sorting and remove testing of non-sorted records, or require sorting and change negative tests of non-sorted records to positive tests.

module TreeBuilding (fromList, Record(..), Thread) where

import Debug.Trace (trace)

import Data.Function ((&))
import Data.Maybe (fromMaybe)
import Data.Ord (comparing)
import           Data.List (sortBy, foldl')

import qualified Data.Map as Map
import           Data.Map (Map)
import           Data.Tree (Tree(..))

type Id = Int
type Thread = Tree Id
data Record = Record
  { recordId       :: Id
  , recordParentId :: Maybe Id
  } deriving (Eq, Show)

type ParentId = Id
type ChildId = Id
type ParentChildMap = Map ParentId [ChildId]

fromList :: [Record] -> Maybe Thread
fromList = threadWithRoot 0
         . foldl' (flip insertRecord) Map.empty
         . sortBy (comparing recordParentId <> comparing recordId)
  where
    insertRecord (Record recordId Nothing) m
      | Map.member recordId m = trace ("Duplicate parent " ++ show recordId ++ "!") m
      | otherwise = Map.insertWith (++) recordId [] m

    insertRecord (Record recordId (Just parentId)) m
      | Map.member recordId m = trace ("Duplicate child " ++ show recordId ++ "!") m
      | Map.member parentId m =
          Map.insertWith (++) recordId []
            (Map.adjust (++ [recordId]) parentId m)
      | otherwise = trace ("Unknown parent " ++ show parentId ++ "!") m

threadWithRoot :: ParentId -> ParentChildMap -> Maybe Thread
threadWithRoot rootId parentChildMap = buildMaybe rootId
  where
    buildMaybe parentId = parentChildMap
                        & Map.lookup parentId
                        & fmap (Node parentId . map build)

    build parentId = fromMaybe (pure parentId) (buildMaybe parentId)

sshine · 2019-09-03T10:49:32Z

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

+
+groupByParent :: [Record] -> [ParentGrouping]
+groupByParent = sortOn fst
+              . map (\xs -> (recordParent (head xs), map recordId xs))


I only really use &&&, ***, first and second from Control.Arrow, and the only arrow I ever think about is (,).

guygastineau · 2019-09-03T12:17:39Z

I'll finally have some time for this tonight !

I looked at Data.Tree and it is exactly what I need.

sshine · 2019-09-03T12:18:31Z

A last thought -- sorry for spamming you -- if we're giving a

data Thread = Leaf Id | Branch Id Children

in the stub, but we'd like people to use

import Data.Tree (Tree)
type Thread = Tree Id

then how can we express test cases abstractly? We would need to hide the concrete constructors (Leaf, Branch for the stub, Node for the example) and instead export ~~functions for extracting the posts of a thread~~ an abstract constructor, i.e.

module ForumThread (Record, Thread, fromList, thread) where

...

-- In the stub
thread :: Id -> [Thread] -> Thread
thread recordId [] = Leaf recordId
thread recordId children = Branch recordId children

-- In the example
thread :: Id -> [Thread] -> Thread
thread = Node

Then we can express expected trees in the test file using e.g.

Just (thread 0 [ thread 1 [], thread 2 [] ])

regardless of internal representation.

Then it can become an objective to change the internal representation to Data.Tree without affecting the test suite.

guygastineau · 2019-09-03T12:37:43Z

@sshine that is amazing!

Thank you for sharing that strategy with me 😍

petertseng · 2019-09-04T02:29:34Z

exercises/tree-building/examples/success-standard/package.yaml

@@ -0,0 +1,21 @@
+name:                tree-building
+version:             1.0.0.0


upon further review of other example package.yaml, I find that we just don't have version in example package.yaml, likely so we don't need to update them in multiple places. So this one should be removed

petertseng · 2019-09-04T02:29:53Z

exercises/tree-building/examples/success-standard/package.yaml

+  exposed-modules: TreeBuilding
+  source-dirs: src
+  ghc-options: -Wall
+  # dependencies:


these lines can (and should) be removed from example's package.yaml

sshine · 2019-09-05T12:51:00Z

@guygastineau: I feel that I've left you a bit of a mess wrt. feedback.

I'll try and summarize my proposal of what we need to do from here:

Rename the stub module into ForumThread
Rename the main type the module exports into ForumThread
Rename the main function that the module exports into fromList
Create and use an abstract thread constructor in the stub, test and example, so students can refactor data ForumThread = ... into (new)type ForumThread = Tree Id without having to change the tests.
Fix imports and exports in the stub, test and example to something like Record(..), Thread, thread, fromList.
Make a decision about some of the negative cases, as I've outlined above.

In this gist I've updated the stub file and the tests so they conform to these proposals, and the only thing I've left commented out are the negative cases.

As for your example solution: Feel free to stop refactoring whenever you feel like it. The important part here is that it's a learning experience for you and that it behaves the same as the stub file. We can always take iterations on improving it further for your sake after merging the important parts.

guygastineau · 2019-09-05T13:29:28Z

@sshine thank you for your detailed work.

I will see how far I can take this with your guidance ;)

I'm sorry I've left this PR up without progress for so long. A new project for a startup is taking a lot of time from my days.

guygastineau · 2019-09-13T18:27:28Z

Hey @sshine That is a really good Gist! I appreciate all of your guidance here ;)

I am still swamped with real work projects for a start up right now. I could probably implement these changes over the next day or so, but if you are willing simply to change this to the better version I would be grateful.

I am sorry that I have left this PR hanging for so long on your track.

sshine · 2019-09-13T23:31:25Z

@guygastineau: We've had PRs open for a year, it really is no inconvenience. I'll look at it if you prefer to not continue with it. Thanks for all the effort so far!

guygastineau · 2019-09-13T23:41:09Z

@sshine your generosity of spirit is only matched by your expertise.

Though it might take me til Monday to have it in good shape I suppose I should do it (it will help help me be a better Haskeller). Thank you for dissuading my anxieties about longer running PR's.

exercises/tree-building/examples/success-standard/package.yaml

exercises/tree-building/examples/success-standard/src/TreeBuilding.hs

exercises/tree-building/examples/success-standard/package.yaml

guygastineau · 2019-09-25T21:03:26Z

Thank you for the review @petertseng

I can try to do some work on this this week, but I am still utterly swamped.

I have taken a huge interest in Scheme, and I am trying to help revitalize that6 very ignored track with another enthusiast right now ;)

I have done most of the work for the bob-andfriends` exercise idea, so I expect to get that up here soon.

Even though I said I should finish this PR for my benefit, I honestly would be grateful to anyone who wanted to finish this tree building port up.

sshine · 2019-09-26T15:35:43Z

would be grateful to anyone who wanted to finish this tree building port

You already did the heavy lifting.

I'm playing with stateful tree generators for this one, so it may take a couple of days.

guygastineau · 2019-09-26T15:38:13Z

@sshine cool. I am excited to see your work. I imagine I will learn a lot from reading it 🤓

In the mean time I will get the bob-and-friends PR up.

sshine · 2019-09-26T15:48:28Z

I've gotten seriously frustrated at QuickCheck-GenT. It's old, so it seems you need to run the stateful generator using something like

instance Arbitrary Thread where
  arbitrary = (`evalState` state) <$> runGenT (sized threadGen)

I ditched the thing when I couldn't easily call on deriving (..., MonadState ..., MonadGen ...) having to explicitly lift non-GenT features from QuickCheck's Gen like shuffle. Meh. So I'm redoing it with Hedgehog.Gen that is naturally implemented mtl-style. Hedgehog deals with generating recursive structures in a less primitive way, so I want to learn to do that part right.

guygastineau · 2021-01-05T14:36:26Z

Well, this sure has been open for along time ;)

I have learned a lot since I tried porting this exercise. I think I will give it another go now.

sshine · 2021-02-10T06:32:53Z

@guygastineau: Cool :)

I think I learned something about how to not give feedback doing this one, haha. I think if you regard all of the comments above as one big brainstorm and do the exercise without constraints, maybe it will be less critical. Feel free to decide whether you want to close this one and open a new one, or just work from here and not let the comments made so far disturb your creative process too much.

sshine · 2021-02-10T06:50:00Z

@guygastineau: Upon revisiting the comment thread in this PR, I see this comment containing a link to a proposed copy of the handed-out solution and a test suite that is compatible with it. You would only need to make an example solution that you like and conforms to this test suite (which was made flexible wrt. internal representation, so that this could become a part of the task).

guygastineau · 2021-02-12T13:33:43Z

@sshine hahaha. Well, I think your feedback was useful even though some of it lost me at the time ☺️

I got interested in this again, because I thought I might be able to use recursion schemes in the example. I'll see if it is practical with the internal representation. Still, my point is that your advice was good, but it was over my head at the time. The above brainstorming session makes much more sense now that I have gone on to learn and build more Haskell projects in the wild that do actual work. My ongoing quest to learn intuitionistic type theory is also working out (though it is hard), that and some explorations in compilers has made a lot of things clearer for me ☺️

I will need to see if I can get tools here to work for me. Last time (for some reason I can't understand) I did not reach out about the testing tools not working. Is stack still set up to use some sandbox directory to run all of the tests?

IDK, I will re-familiarize myself with the process of testing and contributing to this project. If I encounter similar issues using the repo's utilities I will reach out for help with that this time.

guygastineau added 2 commits August 27, 2019 22:25

tree-building: peripheral files and the two tests

602d10d

tree-building: generated uuid; added entry to config.json

a3396d0

tree-building: add fixes from Hlint

6e7940c

sshine reviewed Aug 28, 2019

View reviewed changes

petertseng reviewed Aug 30, 2019

View reviewed changes

sshine reviewed Sep 3, 2019

View reviewed changes

petertseng reviewed Sep 4, 2019

View reviewed changes

sshine added the new exercise label Sep 5, 2019

petertseng reviewed Sep 25, 2019

View reviewed changes

sshine mentioned this pull request Oct 2, 2019

Porting zipper with recursion-schemes #851

Closed

Base automatically changed from master to main January 28, 2021 19:15


		data Record = Record Id (Maybe Id) deriving (Eq, Show)

		data Tree = Leaf Id \| Branch Id Children deriving (Eq, Show)

	(Record i Nothing) -> if' (i /= 0) True False
	Record i Nothing -> i /= 0

	(Record i (Just p)) -> if' (p >= i) True False
	Record i (Just p) -> p >= i

	\| not . validRoot $ x = Nothing
	\| not (validRoot x) = Nothing

	. map (\xs -> (recordParent (head xs), map recordId xs))
	. map (recordParent . head &&& map recordId))

tree-building: port #835

Are you sure you want to change the base?

tree-building: port #835

Conversation

guygastineau commented Aug 28, 2019 • edited Loading

guygastineau commented Aug 28, 2019

guygastineau commented Aug 28, 2019

guygastineau commented Aug 28, 2019

guygastineau commented Aug 28, 2019

guygastineau commented Aug 28, 2019

sshine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sshine Aug 28, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sshine Aug 28, 2019 • 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

sshine commented Aug 28, 2019

guygastineau commented Aug 28, 2019

guygastineau commented Aug 28, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guygastineau commented Aug 30, 2019

sshine commented Aug 30, 2019

guygastineau commented Aug 30, 2019

sshine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guygastineau commented Sep 3, 2019

sshine commented Sep 3, 2019 • edited Loading

guygastineau commented Sep 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sshine commented Sep 5, 2019

guygastineau commented Sep 5, 2019

guygastineau commented Sep 13, 2019

sshine commented Sep 13, 2019 • edited Loading

guygastineau commented Sep 13, 2019

guygastineau commented Sep 25, 2019

sshine commented Sep 26, 2019

guygastineau commented Sep 26, 2019 • edited Loading

sshine commented Sep 26, 2019

guygastineau commented Jan 5, 2021

sshine commented Feb 10, 2021

sshine commented Feb 10, 2021

guygastineau commented Feb 12, 2021

guygastineau commented Aug 28, 2019 •

edited

Loading

sshine Aug 28, 2019 •

edited

Loading

sshine Aug 28, 2019 •

edited

Loading

sshine commented Sep 3, 2019 •

edited

Loading

sshine commented Sep 13, 2019 •

edited

Loading

guygastineau commented Sep 26, 2019 •

edited

Loading