[WIP] Tail recursion warning and attribute #1976

AviAvni · 2016-12-09T13:36:42Z

Start working on fsharp/fslang-suggestions#147

add tests
check for async { .. } and seq { .. }

Merge branch 'master'

merge from dev

merge from master

vasily-kirichenko · 2016-12-09T13:48:08Z

TailRecursionAttribute is too long for my taste. What about TailrecAttribute?
Scala uses @tailrec attribute.

abelbraaksma · 2016-12-09T14:19:07Z

This is a wonderful addition to F#! Writing either [<TailRec>] or [<TailRecursion>] wouldn't matter much to me (@vasily-kirichenko). In fact, I think if at all possible, let rec f vs let tail rec f (or let tailrec f) would have my preference, but that'd mean introducing a new keyword.

We may need a keyword if we are to allow this feature on local functions:

let factorial n =
    let rec loop i acc =   // this is tail-recursive, but if it isn't I'd like the new warning
        match i with
        | 0 | 1 -> acc
        | _ -> loop (i-1) (acc * i)
    loop n 1

forki · 2016-12-10T11:53:51Z

Mhm since many many rec functions are local I think the introduction of a new tailrec keyword makes a lot of sense. If we decide on attributes then we should go with "TailRecursionAttribute". This is very similar to the existing RequireQualifiedAccessAttribute".

Regarding the error message. I think we should make it really verbose and explain as much as possible.

forki · 2016-12-10T11:55:30Z

Forgot to mention that this is just wonderful. One of the best additions to the compiler in quite some time. Kudos for tackling this.

forki · 2016-12-10T12:15:35Z

There is also the possibility of taking a more radical approach and to always check for tail recursion. This has a couple of advantages.

we don't need to introduce new syntax constructs nor attributes
existing code will be checked without the need of change
people can always opt-out by nowarn directive - that's already built in
using tail recursion is whenever it is possible also the best way to do things and should therefore the default choice of the language
it is still non-breaking (ignoring "warning as error" mode like we usually do)

Tbh I think this should be really considered. @dsyme what do you think?

thinkbeforecoding · 2016-12-10T12:55:39Z

@forki suggestion to check tail recursion systematically seems a good idea.
Recursion is to my experience really often used in local nested functions. So it'd be a problem if attributes are limited to top level functions (didn't check).
There's a tailcall reserved keyword, but it seemed @dsyme didn't recommend its usage.

vilinski · 2016-12-10T15:39:07Z

+1 to check always

AviAvni · 2016-12-10T15:52:23Z

Thanks for everyone I will wait for @dsyme to decide about the details

abelbraaksma · 2016-12-10T15:56:03Z

I'm in favor of checking always, with one caveat: beginning users will be stymied by this warning, it requires a working knowledge of too many concepts to even understand the gist of what it means, let alone knowing how to fix it.

Either we should make it a L4 warning (are levels currently used?) or we should make sure that the warning includes a "ignore me" statement, for instance:

FS8888: This function is marked recursive, but is not tail-recursive. If the recursion is deep or performance is of the essence, consider making it tail-recursive, otherwise, ignore this warning with #nowarn 8888.

Either way, I would prefer this as an option for experienced programmers. In 9 out of 10 cases it doesn't matter, as recursion won't go too deep anyway and performance isn't critical. If L3 warnings is the default, making it an L4 warning would suffice (though I am uncertain whether or not the levels are actually adhered to, or used, see for instance this uservoice post, which wasn't converted?)

Warnings like these should either be leveled (L4, L5), or be allowed to be switched on/off on a more granular level than per-file (but that's OT for this issue, I know).

Even better yet: if someone feels like it, this could be switched on/off on the property page of a project (an option "analyze for tail-recursion").

vladima · 2016-12-10T16:33:58Z

Idea of detecting calls in non-tail position definitely sounds useful, however I think that implementation should be different. Reason: currently it is done at the codegen phase which is IDE never does (because there is no point to generate actual binary on every keystroke) - so this error will never be reported in editor which to me significantly decreases its value.

forki · 2016-12-10T16:39:37Z

In 9 out of 10 cases it doesn't matter, as recursion won't go too deep anyway

My (completely made up) statistics suggest the exact opposite. ;-)

abelbraaksma · 2016-12-10T17:20:10Z

@forki, I came to this idea from Brian on SO suggesting, esp. too beginners or moderately advanced programmers to stay away from even trying to use tail recursion: http://stackoverflow.com/a/1797302/111575.

From my own experience: looking at the my largest F# project I see some 50 or so let rec statements. Only a handful of which would benefit from this (hence my 9 out of 10, but I'm biased to myself :D). That is not to say, I also have a few while-statements which I didn't dare to make recursive for fear of getting it wrong... (shame on me, I know, kudos to this fix, it can be a life saver!)

Thinking of which: I also encountered a few mutual recursive members. Would these be detected as tailcall with this fix?

forki · 2016-12-10T17:32:56Z

I absolutely agree with the "prefer higher order functions" part, but that is actually not really related to this here. Am 10.12.2016 6:20 nachm. schrieb "Abel Braaksma" <notifications@github.com

…

: @forki <https://github.com/forki>, I came to this idea from Brian on SO suggesting, esp. too beginners or moderately advanced programmers to stay away from even trying to use tail recursion: http://stackoverflow.com/a/ 1797302/111575. From my own experience: looking at the my largest F# project I see some 50 or so let rec statements. Only a handful of which would benefit from this. That is not to say, I also have a few while-statements which I didn't dare to make recursive for fear of getting it wrong... (shame on me, I know, kudos to this fix, it can be a life saver!) Thinking of which: I also encountered a few mutual recursive members. Would these be detected as tailcall with this fix? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1976 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNMzK8ZTV7iP5S9sP069xBLQMhSajks5rGt9KgaJpZM4LI8dW> .

abelbraaksma · 2016-12-10T17:44:50Z

My train of thought was: if the tendency is to suggest beginning users to stay away from recursion, and if they don't, then stay away from tailcalls (makes sense, they can be hard, even for experienced programmers), then I think we ought to make sure this warning either doesn't throw them off, helps them, or is only available as an extra option for advanced users.

forki · 2016-12-10T17:48:08Z

stay away from tail-calls is a bad advice. really

abelbraaksma · 2016-12-10T19:01:24Z

stay away from tail-calls is a bad advice. really

I'm just trying to follow what I believe is consensus here: keep it simple for beginners, but give power tools for advanced users. Saying "stay away" is perhaps too strong, but my point is simply: don't overwhelm beginning users with trying to explain what TCO is by means of warnings. We are trying to get more users, not less.

Regardless of your opinion on my ideas of tutoriability of warnings, this warning is a very valuable addition, just don't get my comments the wrong way, I am not arguing against implementing it, or against TCO in general (apologies if it looked that way).

theimowski · 2016-12-10T21:04:36Z

We already have the rec keyword for marking recursive functions, so if we provide yet another construct for marking tail recursion (be it an attribute, or special keyword), it might turn out tedious to use and confusing for new-comers. That said, I'm for making tail recursion warnings turned on by default.

TeaDrivenDev · 2016-12-11T17:26:33Z

I'm for always checking as well, without any special keywords or decorations. Recursion is so important in functional programming that one should be able to consider it "safe" by default, so the compiler telling you when it isn't is a good thing.
As for the beginners, I think that would actually help them too. Myself, I still don't always write proper tail calls, because it often doesn't matter, so when I have to, I sometimes don't really know how to get there. If I always had to do them properly to satisfy the compiler, I'd have much more practice with that.

OnurGumus · 2016-12-12T05:56:34Z

I would vote for a tailrec keyword. Always checking would yield unnecessary warnings.

vasily-kirichenko · 2016-12-12T07:06:05Z

I'm for tailrec keyword, too. It looks quite natural as a specific rec, it's far tidier that [<TailRecursive>].

cartermp · 2016-12-12T15:30:49Z

Is the suggestion here to have tailrec be a replacement for rec? e.g.

let tailrec foo() = ...

forki · 2016-12-12T15:32:49Z

That is one of three proposed versions. Am 12.12.2016 16:30 schrieb "Phillip Carter" <notifications@github.com>:

…

Is the suggestion here to have tailrec be a replacement for rec? e.g. let tailrec foo() = ... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1976 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgND3RrUjxX5Z5bS2VWPwoesbgMW2cks5rHWipgaJpZM4LI8dW> .

AviAvni · 2017-01-02T19:07:52Z

@forki I can bring back the check in the code gen

forki · 2017-01-02T19:14:08Z

I think that would be good, not sure how others feel about it.

forki · 2017-01-02T19:20:55Z

src/fsharp/FSComp.txt

@@ -1332,3 +1332,4 @@ tcTupleStructMismatch,"One tuple type is a struct tuple, the other is a referenc
 3211,DefaultParameterValueNotAppropriateForArgument,"The default value does not have the same type as the argument. The DefaultParameterValue attribute and any Optional attribute will be ignored. Note: 'null' needs to be annotated with the correct type, e.g. 'DefaultParameterValue(null:obj)'."
 tcGlobalsSystemTypeNotFound,"The system type '%s' was required but no referenced system DLL contained this type"
 3213,typrelMemberHasMultiplePossibleDispatchSlots,"The member '%s' matches multiple overloads of the same method.\nPlease restrict it to one of the following:%s."
+3212,chkNotTailRecursive,"The member or function '%s' has the 'TailCallAttribute' attribute, but is not being used in a tail recursive way."


Maybe "was marked with"? Do we already have similar texts?

dsyme · 2017-01-02T19:21:34Z

Try to implement the tailrec intrinsic in this PR?

Ideally yes. This would be an F# 4.2 feature, and I think we would progress by first having one or two people try out the feature, e.g. try to use apply it to the F# codebase. Having both the intrinsic and the attribute implemented would help.

Note

The presence of uses of the intrinsic in the TAST may easily mess up optimizations and/or codegen. So removing it during the first optimization phase makes sense. However this means you can't perform the check at code-gen time.
You will also need to decide if it appears in quotations - it shouldn't I think - so should again be removed during quotation processing.
Syntactically the use of an intrinsic has pros and cons. For example, peope may expect you can pipeline it, e.g. let rec f x = ... tailrec (f x) becomes let rec f x = ...f x |> tailrec. That won't work of course. I can also see people definitely asking for a keyword here, so they don't need parentheses let rec f x = ... tailrec f x
The current intended rule is "TailRecAttribute implies the function is only used in a tail recursive way within its recursive scope" . Just to note that this is in tension with the various ways to increase the size of recursive scopes, e.g. namespace rec or module rec or even just a set of object-oriented type definitions. Increasing the size of a recursive scope will mean spurious errors/warnings are given. In this case, people will gravitatte to using tailrec

Checking in codegen does make sense, to make sure the optimizer hasn't screwed things around.

forki · 2017-01-02T19:28:39Z

So intrinsics feature should be a separate PR?

merge from master

jack-pappas · 2017-01-17T19:49:13Z

I've been thinking -- introducing a tailrec keyword or [<TailRecursive>] attribute doesn't seem strictly necessary. Unless there's a something I'm missing, it'd only serve to augment the analysis; for example, when the keyword/attribute is applied, the analysis pass might emit an error instead of a warning.

Given this is a rather complex piece of analysis with many edge cases to consider, what if we went the route of implementing it within something like VFPT for now? There, it could be enabled optionally while we work on getting the analysis correct; once it's ready, we'd roll the analysis code into the compiler itself and implement the keyword/attribute if it still seems useful. If VFPT isn't a good fit, what about implementing the analysis as a standalone tool (again, for now) on top of FCS -- we could provide it as a NuGet package which would install the tool into a project (so no manually configuration would be needed, and it'd still be easy to iterate quickly).

KevinRansom · 2017-01-17T22:01:01Z

Jack, I think an IDE analyzer rather than language keyword is the way to go. It could just kick out a warning that Let rec foo = Blah … Blah … Is not be tail-recursive. The il spec regards the .tail instruction as a hint to the jitand it is up to the implementor of the run-time to implement support or just ignore it. I know jit-devs who believe and state quite loudly that if we have to use the .tail command to get the right behavior at all it is a jit bug. So … in short try to think of ways not to bake this into the language, instead make it an IDE analyzer. We may have to figure out ways to make it easy to switch on and off … but that is probably better than baking it in. Thanks Kevin From: Jack Pappas [mailto:notifications@github.com] Sent: Tuesday, January 17, 2017 11:49 AM To: Microsoft/visualfsharp <visualfsharp@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [Microsoft/visualfsharp] [WIP] Tail recursion warning and attribute (#1976) I've been thinking -- introducing a tailrec keyword or [<TailRecursive>] attribute doesn't seem strictly necessary. Unless there's a something I'm missing, it'd only serve to augment the analysis; for example, when the keyword/attribute is applied, the analysis pass might emit an error instead of a warning. Given this is a rather complex piece of analysis with many edge cases to consider, what if we went the route of implementing it within something like VFPT for now? There, it could be enabled optionally while we work on getting the analysis correct; once it's ready, we'd roll the analysis code into the compiler itself and implement the keyword/attribute if it still seems useful. If VFPT isn't a good fit, what about implementing the analysis as a standalone tool (again, for now) on top of FCS -- we could provide it as a NuGet package which would install the tool into a project (so no manually configuration would be needed, and it'd still be easy to iterate quickly). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fpull%2F1976%23issuecomment-273278947&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf37606d53da44733108508d43f11ed57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636202793629281664&sdata=KXE5uIlltpBkMgliUZzjVapftHiQ%2FR7uClbGn%2FZw%2Fig%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FiPKvnjSxjOYUVplvXyVBkTtxCQMks5rTRs8gaJpZM4LI8dW&data=02%7C01%7CKevin.Ransom%40microsoft.com%7Cf37606d53da44733108508d43f11ed57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636202793629281664&sdata=y%2B3gPvnMv0aEwdD9dJ1Mwlilah9wQWWkxZF2RR9ybyM%3D&reserved=0>.

forki · 2017-01-17T22:48:27Z

Analyzer are roslyn based. This feature is something that would useful in the whole ecosystem. We should really think about that and make the compiler smart instead of relying on analyzers. I'm not saying that we have to introduce a keyword or attribute - just that we should use analyzers only as last resort.

KevinRansom · 2017-01-17T22:50:17Z

The C# compiler runs analyzers. We should make that work. From: Steffen Forkmann [mailto:notifications@github.com] Sent: Tuesday, January 17, 2017 2:48 PM To: Microsoft/visualfsharp <visualfsharp@noreply.github.com> Cc: Kevin Ransom <Kevin.Ransom@microsoft.com>; Comment <comment@noreply.github.com> Subject: Re: [Microsoft/visualfsharp] [WIP] Tail recursion warning and attribute (#1976) Analyzer are roslyn based. This feature is something that would useful in the whole ecosystem. We should really think about that and make the compiler smart instead of relying on analyzers. I'm not saying that we have to introduce a keyword or attribute - just that we should use analyzers only as last resort. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fpull%2F1976%23issuecomment-273325695&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C744dbe59529b4581573c08d43f2af602%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636202901122980774&sdata=xVQGmEdxtaocBGg4%2F4W5Qu28wcBr7qRNYI2t2ExYdgk%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FloGvHUHgLu1_4EcW43uHBni1aHsks5rTUU9gaJpZM4LI8dW&data=02%7C01%7CKevin.Ransom%40microsoft.com%7C744dbe59529b4581573c08d43f2af602%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636202901122980774&sdata=TmslPm%2Bc%2BzjoKRe5m%2F2t%2B3Fh0j7SrKcGUI8ovgrS6UU%3D&reserved=0>.

forki · 2017-01-17T22:52:20Z

I can already run as many analyzers as I want during my FAKE build. That's not the point.

forki · 2017-01-17T22:58:25Z

Btw it's nice that people say it's a jit bug if you have to emit tail calls. Are these bugs fixed?

forki · 2017-01-17T23:02:49Z

Even if the jitter could detect tail calls (without explicit tail call), then we still have to write it tail recursive. And the whole idea of this feature is to detect this somehow in the compiler.

KevinRansom · 2017-01-18T01:33:23Z

@forki I believe they would consider fixing the Jit to improve code generation where they believe tail recursion should occur and it isn't. Provide a repro of where the jit does the wrong thing and they will improve it.

dsyme · 2017-01-18T14:50:36Z

@jack-pappas

Unless there's a something I'm missing, it'd only serve to augment the analysis; for example, when the keyword/attribute is applied, the analysis pass might emit an error instead of a warning.

There seems to be a belief going around that F# function calls are normally tail calls and we can just warn if they aren't. This isn't the case - a huge number of F# calls (the majority of syntactic call sites) are not tail recursive - even within the recursive scope of the function or member - even more so when larger recursive scopes are being used in object-oriented programming or namespace rec.

So some kind of attribute is needed to indicate that tail recursion is intended. Otherwise we end up flagging almost everything.

dsyme · 2017-01-18T14:55:09Z

Everyone - his is in the context of the approved language RFC FS-1011. We should probably put design feedback there.

@KevinRansom I'm not opposed to any particular analyzer of course, likewise I wouldn't be opposed to an FSharpLint rule. (FSharpLint rules are active in Ionide by defaut).

Writing a code fix to make something tail recursive would be hard, as there are quite a few ways to do it (see Expert F# 4.0 chapter ~15)

forki · 2017-01-18T14:59:05Z

The thing is even with analyzer we need to commit that decision with the code or we will flag everything. Am 18.01.2017 15:55 schrieb "Don Syme" <notifications@github.com>:

…

Everyone - his is in the context of the approved language RFC FS-1011 <https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1011-warn-on-recursive-without-tail-call.md>. We should probably put design feedback there. @KevinRansom <https://github.com/KevinRansom> I'm not opposed to any particular analyzer of course, likewise I wouldn't be opposed to an FSharpLint rule. (FSharpLint rules are active in Ionide by defaut). Writing a code fix to make something tail recursive would be hard, as there are quite a few ways to do it (see Expert F# 4.0 chapter ~15) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1976 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNJBK2O315l8U73g7WgDci4-5c99cks5rTifNgaJpZM4LI8dW> .

jack-pappas · 2017-01-18T23:42:51Z

@dsyme Agreed, we should move discussion about the design for this feature over to fsharp/fslang-design#82.

jack-pappas · 2017-01-19T00:04:26Z

@dsyme I also realized after your comment today that we may be talking about two different things -- tail calls in general (which don't necessarily imply any recursion) and functions designed to be (mutually-)recursive (where any call sites to functions in that set of mutually-recursive functions should be tail-calls to avoid overflowing the stack). I think there's an easy way to get some low-hanging fruit on the mutually-recursive functions, and I've outlined the analysis algorithm in fsharp/fslang-design#82.

KevinRansom · 2017-02-03T20:00:10Z

@AviAvni @dsyme

Thanks for this PR and lively discussion but it doesn't seem that we are anywhere close to having the necessary investigations and designs complete yet for a tail recursion feature.

I'm going to close this PR for now, the discussion needs to occur on user voice. When consensus or an approach has been determined, then please feel free to resubmit this or an alternate PR.

Thank you,

Kevin

forki · 2017-02-03T22:50:18Z

@KevinRansom please reopen. This is one of the most interesting pull requests in recent history

KevinRansom · 2017-02-03T23:20:10Z

The language design is
https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1011-warn-on-recursive-without-tail-call.md

This interesting thread is not being captured at the right spot.

I will add a link from :
https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1011-warn-on-recursive-without-tail-call.md

back to this thread.

Please consider continuing the discussion at the RFC.

dsyme · 2017-02-04T13:23:21Z

@KevinRansom I think we could leave this open - any efforts to make progress on this particular issue are really valuable, even half-way. It's a really tricky feature to get right, and the thing we need most is a series of prototypes for people to use. A WIP PR is one way to get that (and get eyes on it)?

realvictorprm · 2017-09-22T18:45:47Z

Can the FSSF help with triggering this discussion again @dsyme?

AviAvni added 7 commits August 26, 2016 13:51

Merge pull request #6 from Microsoft/master

6f83e7a

Merge branch 'master'

Merge pull request #7 from Microsoft/master

7f13a25

Merge branch 'master'

Merge pull request #8 from Microsoft/master

500c342

merge from dev

Merge pull request #9 from Microsoft/master

de769f2

merge from master

Merge pull request #13 from Microsoft/master

c802cca

merge from master

Merge pull request #15 from Microsoft/master

d04c1f9

merge from master

add and check for tail recursive attribute

edb5d49

msftclas added the cla-already-signed label Dec 9, 2016

forki reviewed Jan 2, 2017

View reviewed changes

Merge pull request #17 from Microsoft/master

61b14bd

merge from master

Merge branch 'master' into tail-recursion

12cab95

KevinRansom closed this Feb 3, 2017

cartermp mentioned this pull request Feb 18, 2019

Add compiler-known attribute for enforced tail recursion fsharp/fslang-suggestions#721

Closed

5 tasks

TysonMN mentioned this pull request Dec 29, 2020

Tail-recursive function calls that have their parameters passed by the pipe operator are not optimized as loops #6984

Open

dawedawe mentioned this pull request May 25, 2023

Tail recursion warning and attribute, take 2 #15260

Closed

dawedawe mentioned this pull request Nov 27, 2023

Bugfix for 16330: Error while using [<TailCall>] #16347

Merged

[WIP] Tail recursion warning and attribute #1976

[WIP] Tail recursion warning and attribute #1976

Conversation

AviAvni commented Dec 9, 2016

vasily-kirichenko commented Dec 9, 2016

abelbraaksma commented Dec 9, 2016 • edited

forki commented Dec 10, 2016

forki commented Dec 10, 2016

forki commented Dec 10, 2016

thinkbeforecoding commented Dec 10, 2016

vilinski commented Dec 10, 2016

AviAvni commented Dec 10, 2016

abelbraaksma commented Dec 10, 2016 • edited

vladima commented Dec 10, 2016

forki commented Dec 10, 2016

abelbraaksma commented Dec 10, 2016 • edited

forki commented Dec 10, 2016 via email

abelbraaksma commented Dec 10, 2016 • edited

forki commented Dec 10, 2016

abelbraaksma commented Dec 10, 2016 • edited

theimowski commented Dec 10, 2016

TeaDrivenDev commented Dec 11, 2016

OnurGumus commented Dec 12, 2016 • edited

vasily-kirichenko commented Dec 12, 2016

cartermp commented Dec 12, 2016

forki commented Dec 12, 2016 via email

AviAvni commented Jan 2, 2017

forki commented Jan 2, 2017

forki Jan 2, 2017

Choose a reason for hiding this comment

dsyme commented Jan 2, 2017

forki commented Jan 2, 2017

jack-pappas commented Jan 17, 2017

KevinRansom commented Jan 17, 2017 via email

forki commented Jan 17, 2017

KevinRansom commented Jan 17, 2017 via email

forki commented Jan 17, 2017

forki commented Jan 17, 2017

forki commented Jan 17, 2017 • edited

KevinRansom commented Jan 18, 2017

dsyme commented Jan 18, 2017 • edited

dsyme commented Jan 18, 2017

forki commented Jan 18, 2017 via email

jack-pappas commented Jan 18, 2017

jack-pappas commented Jan 19, 2017

KevinRansom commented Feb 3, 2017

forki commented Feb 3, 2017

KevinRansom commented Feb 3, 2017

dsyme commented Feb 4, 2017

realvictorprm commented Sep 22, 2017

abelbraaksma commented Dec 9, 2016 •

edited

abelbraaksma commented Dec 10, 2016 •

edited

abelbraaksma commented Dec 10, 2016 •

edited

abelbraaksma commented Dec 10, 2016 •

edited

abelbraaksma commented Dec 10, 2016 •

edited

OnurGumus commented Dec 12, 2016 •

edited

forki commented Jan 17, 2017 •

edited

dsyme commented Jan 18, 2017 •

edited