Implementing break on load #241

rakatyal · 2017-09-27T18:29:46Z

No description provided.

auchenberg · 2017-09-27T18:38:31Z

Any particular reason for why we don't use DOMDebugger.setInstrumentationBreakpoint as per recommendation from the Chrome team?

https://github.com/Microsoft/vscode-chrome-debug/issues/445

roblourens · 2017-09-27T18:40:10Z

Because it has that issue which might never be fixed, and this is blocking chrome-debug in VS.

auchenberg · 2017-09-27T18:44:21Z

@roblourens @rakatyal It's blocking a very particular use case of HTML imports in Chrome, which is a platform issue, so we implement a workaround in our debugger? It's my understanding that break-on-load using the recommended way works for the vast majority of Chrome users?

What's the pro's and con's of our own implementation of this?

rakatyal · 2017-09-27T20:11:44Z

@auchenberg: I believe apart from the flag not working in the HTML imports scenario, there are some other reasons to go this way:

We implemented the same logic for break on load to work for Webkit debugger inside VS. So this is a tried and tested approach.
We are not aware of the performance impact of the experimental flag since we never got around to test it out. Plus it's experimental, so we can't be sure of it's implementation in the future.

So we agree that this might not be the best solution out there, but it's a safe bet for us now.
What do you think?

auchenberg · 2017-09-27T21:19:36Z

@rakatyal

I understand that we have prior art from VS, but it's also my understanding that we were using the Chrome recommended API before we encountered the HTML imports issues, correct? We should therefore know the performance characteristics and behavior of the APIs.

I don't understand why we don't want to offload this functionality to the platform (Chrome) by using an API that's exposed for this purpose and already well-used inside Chrome DevTools.

As I see this then this approach is growing our implementation and maintainability surface within our debugger for no apparent gain. That said this is an engineering decision, and if you think this is the best solution now and going forward then that's the way we roll.

rakatyal · 2017-09-27T22:58:42Z

@auchenberg: I agree that ideally we should be offloading this functionality to the platform. But from my understanding we never actually got to using that flag and hence never actually measured the performance impact of it. @digeff should be able to answer this concretely though, but we may think that flag would have had adverse performance impacts when compared to this approach.

digeff · 2017-09-28T16:35:41Z

@auchenberg We never tested the performance of that flag. We did test the performance of using a breakpoint on .*:0:0 to break on the first line of each and every file, which is similar to that command.

When using .*:0:0 in a project with 100s JavaScript file, the page took an extra 10 seconds to load the page, and as far as I could tell, 5 of those seconds where Chrome stopping and resuming the JS execution 100 times, so there was nothing we could do about that.

The remaining open questions are:

Does DOMDebugger.setInstrumentationBreakpoint has the same performance as .*:0:0?
How many customers have project with 100s of JavaScript files?

I don't have those answers...

auchenberg · 2017-09-28T23:07:48Z

Given that this core library is shared between Node, Chrome and other runtimes we should be careful about enabling this feature by default, if there's any performance overhead with larger amount of files. Ex: smaller Node projects has typically 500+ files.

@digeff Does the current implementation add a significant overhead?

I'm still a firm believer that we should offload as much as possible to the platform, and if there's a platform issue, like the issue with DOMDebugger.setInstrumentationBreakpoint, it should be fixed by a given platform team, and we shouldn't do workarounds in our debugger.

digeff · 2017-09-29T15:45:19Z

src/chrome/chromeDebugAdapter.ts

+
+                const mappedUrl = this._pathTransformer.scriptParsed(pausedScriptUrl);
+                let normalizedMappedUrl: string;
+                if (mappedUrl !== undefined) {


Could you please describe in which scenario will **mappedUrl ** be undefined, and what the code will do in that scenario?

It shouldn't be. The base function just returns the value passed to it. I added it just to be sure because path.normalize throws an error when script path is undefined.

digeff · 2017-09-29T15:48:20Z

src/chrome/chromeDebugAdapter.ts

+                    // The file has no pending breakpoints to resolve. Just continue in this case.
+                    this.chrome.Debugger.resume()
+                        .catch(e => {
+                            logger.log("Failed to resume due to exception: " + e.message);


Should we also show a message to the user here?

Hmm I am unsure about that one. @roblourens What do you think? I guess if this happens, Chrome will be stuck in paused state.

You could change the logger.log to logger.error, then it will be sent to the debug console by default.

digeff · 2017-09-29T15:49:47Z

src/chrome/chromeDebugAdapter.ts

+
+                // If the file has unbound breakpoints, make sure to resolve them first and then decide to continue or not
+                if (this._pendingBreakpointsByUrl.has(normalizedMappedUrl)) {
+                    this.resolvePendingBreakpoint(this._pendingBreakpointsByUrl.get(normalizedMappedUrl))


Normalizing paths is tricky. Could you add a logger message that says: We normalized AbC to abc, and we did (or didn't) find any breakpoints for that url? I think that could prove very useful in case we run into any issues

digeff · 2017-09-29T15:51:03Z

src/chrome/chromeDebugAdapter.ts

+                }
+
+                // If the file has unbound breakpoints, make sure to resolve them first and then decide to continue or not
+                if (this._pendingBreakpointsByUrl.has(normalizedMappedUrl)) {


You could also just call this._pendingBreakpointsByUrl.get(normalizedMappedUrl) here, and test for undefined...

digeff · 2017-09-29T15:52:44Z

src/chrome/chromeDebugAdapter.ts

+
+                // If the file has unbound breakpoints, make sure to resolve them first and then decide to continue or not
+                if (this._pendingBreakpointsByUrl.has(normalizedMappedUrl)) {
+                    this.resolvePendingBreakpoint(this._pendingBreakpointsByUrl.get(normalizedMappedUrl))


I'd change this method to return some information about the breakpoint, so you can deduce _userBreakpointOnLine1Col1 from there, rather than having to store it on an instance variable...

I don't wanna change the function signature just for my use case since I think it makes more sense the way it is right now. Do you see any major issue with the use of an instance variable?

I don't understand the flag, don't you need to keep this info per-file?

Yes I need this per file that's why I reset it every time if it becomes true. Since I am waiting for the resolvePendingBP request to complete before resetting it, I figured this should be okay and we won't need to store it per file since the operation will be synchronous for different files. Thoughts?

So it relies on the scriptParsed and onPause happening right next to each other, and scriptParsed coming first? That's probably a safe assumption.

Would help to document these assumptions.

digeff · 2017-09-29T15:53:40Z

src/chrome/chromeDebugAdapter.ts

+                        this._pendingBreakpointsByUrl.delete(normalizedMappedUrl);
+                        // If none of the breakpoints resolved in the file were at position (1,1) we should continue
+                        if (!this._userBreakpointOnLine1Col1) {
+                            this.chrome.Debugger.resume()


I would merge this line with line 530...

digeff · 2017-09-29T16:11:32Z

src/chrome/chromeDebugAdapter.ts

@@ -859,6 +935,10 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        return this.setBreakpoints(pendingBP.args, pendingBP.requestSeq, pendingBP.ids).then(response => {
            response.breakpoints.forEach((bp, i) => {
                bp.id = pendingBP.ids[i];
+                // If any of the unbound breakpoints in this file is on (1,1), we set userBreakpointOnLine1Col1 to true
+                if (bp.line === 1 && bp.column === 1) {


@roblourens Given that Chrome tends to ignore column numbers, is this the best check to do here?

What do you mean it ignores column numbers?

roblourens · 2017-09-29T20:42:36Z

src/chrome/chromeDebugAdapter.ts

+
+            // If all the breakpoints on this point are stopOnEntry breakpoints
+            // This will be true in cases where it's a single breakpoint and it's a stopOnEntry breakpoint
+            // This can also be true when we have multiple breakpoints and all of them are stopOnEntry breakpoints, for example in cases like index.js and index.bin.js


I don't understand the index.js/index.bin.js example

Suppose user puts breakpoints in both index.js and index.bin.js files, when the setBreakpoints function is called for index.js it will set a stopOnEntry breakpoint on index. files which will also match index.bin.js.
Now when setBreakpoints is called for index.bin.js it will again put a stopOnEntry breakpoint in itself. So when the file is actually loaded, we would have 2 stopOnEntry breakpoints.

roblourens · 2017-09-29T20:43:34Z

src/chrome/chromeDebugAdapter.ts

+                const mappedUrl = this._pathTransformer.scriptParsed(pausedScriptUrl);
+                let normalizedMappedUrl: string;
+                if (mappedUrl !== undefined) {
+                    normalizedMappedUrl = path.normalize(mappedUrl);


Why do you need path.normalize? I don't use that anywhere else.

Mapped URL sometimes returned paths with // like E://folder//file while I stored the mappings for stopOnEntry dictionaries without it. So I changed to use normalized paths for consistencies.

Why does it do that? Do you know where the // is coming from?

roblourens · 2017-09-29T20:45:54Z

src/chrome/chromeDebugAdapter.ts

@@ -859,6 +935,10 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        return this.setBreakpoints(pendingBP.args, pendingBP.requestSeq, pendingBP.ids).then(response => {
            response.breakpoints.forEach((bp, i) => {
                bp.id = pendingBP.ids[i];
+                // If any of the unbound breakpoints in this file is on (1,1), we set userBreakpointOnLine1Col1 to true
+                if (bp.line === 1 && bp.column === 1) {


What do you mean it ignores column numbers?

roblourens · 2017-09-29T20:46:43Z

src/chrome/chromeDebugAdapter.ts

+
+                // If the file has unbound breakpoints, make sure to resolve them first and then decide to continue or not
+                if (this._pendingBreakpointsByUrl.has(normalizedMappedUrl)) {
+                    this.resolvePendingBreakpoint(this._pendingBreakpointsByUrl.get(normalizedMappedUrl))


I don't understand the flag, don't you need to keep this info per-file?

roblourens · 2017-09-29T20:53:17Z

src/chrome/chromeDebugAdapter.ts

+                    // The file has no pending breakpoints to resolve. Just continue in this case.
+                    this.chrome.Debugger.resume()
+                        .catch(e => {
+                            logger.log("Failed to resume due to exception: " + e.message);


You could change the logger.log to logger.error, then it will be sent to the debug console by default.

roblourens · 2017-09-29T20:54:39Z

src/chrome/chromeDebugAdapter.ts

-                    .then(() => this._pendingBreakpointsByUrl.delete(source));
+            let normalizedSource: string;
+            if (source !== undefined) {
+                normalizedSource = path.normalize(source);


Don't use path.normalize without a reason, e.g. these can be URLs or remote paths.

Hmm as mentioned above I don't see any other way to use it for consistency for file paths. Would you know of any other solution? Or else I will try to find a way to ignore this for URLs and remote paths somehow.

roblourens · 2017-09-29T20:57:42Z

src/chrome/chromeDebugAdapter.ts

-                            return this.unverifiedBpResponseForBreakpoints(args, requestSeq, body.breakpoints, localize('bp.fail.unbound', "Breakpoints set but not yet bound"), true);
+                            // If it's a break on load script, we need to send the original args to avoid adjusting the line and column numbers twice
+                            if (this._stopOnEntryRequestedFileNameToBreakpointId.has(targetScriptUrl)) {
+                                return this.unverifiedBpResponseForBreakpoints(originalArgs, requestSeq, body.breakpoints, localize('bp.fail.unbound', "Breakpoints set but not yet bound"), true);


This should happen in either case, not just break on load, right?

I think the current behavior is wrong so go ahead and change it.

roblourens · 2017-09-29T20:59:00Z

src/chrome/chromeDebugAdapter.ts

@@ -1079,6 +1175,12 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        if (!args.source.path || args.source.sourceReference) return Promise.resolve();

        return this._sourceMapTransformer.getGeneratedPathFromAuthoredPath(args.source.path).then<void>(mappedPath => {
+
+            // Currently keeping it on under a flag
+            if (this._breakOnLoadActive) {


Jump out before the async call, and more descriptive comment

roblourens · 2017-09-29T20:59:31Z

src/chrome/chromeDebugAdapter.ts

-            });
+
+            // If script has been parsed, script object won't be undefined and we would have the mapping file on the disk and we can directly set breakpoint using that
+            if (script !== undefined) {


if (script) {

At this point, the existing debugger can also set breakpoints in scripts before they are loaded, for node debugging where we know all the sourcemaps and paths. I think the check should only be for if (!_breakOnLoadActive || script) {

roblourens · 2017-09-29T21:02:29Z

src/chrome/chromeDebugAdapter.ts

+        const fileNameWithoutExtension = path.parse(fileNameWithoutFullPath).name;
+        const escapedFileName = fileNameWithoutExtension.replace(/[-\/\\^$*+?.()|[\]{}]/g, '\\$&');
+
+        return ".*[\\\\\\/]" + escapedFileName + "([^A-z].*)?$";


Can you add a comment? I don't quite follow what this is matching

roblourens · 2017-09-29T21:06:11Z

src/chrome/chromeDebugAdapter.ts

@@ -472,6 +481,60 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        } else if (notification.hitBreakpoints && notification.hitBreakpoints.length) {
            reason = 'breakpoint';

+            const hitBreakpoints = notification.hitBreakpoints;


Move all of this to a helper method, and skip it if the flag is not set

digeff · 2017-09-29T21:07:03Z

src/chrome/chromeDebugAdapter.ts

@@ -1004,6 +1094,8 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {

        return this.validateBreakpointsPath(args)
            .then(() => {
+                // Deep copy args to originalArgs
+                const originalArgs: ISetBreakpointsArgs = JSON.parse(JSON.stringify(args));


Isn't there a better way to do this?

digeff · 2017-10-02T15:35:38Z

This feature has a lot of code. What do you guys @roblourens @rakatyal think of putting all the code relevant to this feature in some breakOnLoad.ts file/class and call methods on that file from every other place? That way it'll be easy to find all the relevant code, etc...

roblourens · 2017-10-24T22:32:59Z

src/chrome/chromeDebugAdapter.ts

+    /* Constructs the regex for files to enable break on load
+       For example, for a file index.js the regex will match urls containing index.js, index.ts, abc/index.ts, index.bin.js etc
+       It won't match index100.js, indexabc.ts etc */
+    private getUrlRegexForBreakOnLoad(url: string): string {


Put this in chromeUtils.ts and write some unit tests for it

roblourens · 2017-10-24T22:37:17Z

src/chrome/chromeDebugAdapter.ts

+                            } catch (e) {
+                                logger.log(`Exception occured while trying to set stop on entry breakpoint ${e.message}.`);
+                            }
+                            breakpointId = result.breakpointId;


If the above throws, then result is null

roblourens · 2017-10-24T22:41:20Z

src/chrome/chromeDebugAdapter.ts

@@ -131,6 +131,18 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {

    private _lastPauseState: { expecting: ReasonType; event: Crdp.Debugger.PausedEvent };

+    private _userBreakpointOnLine1Col1: boolean = false;
+
+    private _breakOnLoadActive: boolean = true;


Should not be true by default, you can set it to true if the launch config param is set

roblourens · 2017-10-24T22:42:10Z

src/chrome/chromeDebugAdapter.ts

@@ -237,6 +249,10 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        this._sourceMapTransformer.launch(args);
        this._pathTransformer.launch(args);

+        if (args.useBreakOnLoadRegex === true) {
+            this._useBreakOnLoadRegex = true;


Maybe the option should be "breakOnLoadStrategy" with "regex", "instrument", or "none" (default).

roblourens · 2017-10-24T22:58:10Z

src/chrome/chromeDebugAdapter.ts

+     * Checks and resolves the pending breakpoints of a script. If any breakpoints were resolved returns true, else false.
+     * Used when break on load active, either through Chrome's Instrumentation Breakpoint API or the regex approach
+     */
+    private async ifResolvedPendingBreakpointsOfPausedScript(scriptId: string): Promise<boolean> {


Just call it resolvePendingBreakpointsOfPausedScript

roblourens · 2017-10-24T23:12:07Z

How can we break up this code a little more? It's hard to break logic out of ChromeDebugAdapter, but there's so much just related to this one feature, that it might make sense to attempt that here. We could have a BreakOnLoadHelper that holds all the state specific to this feature, and gets called into for onPaused, addBreakpoints, etc, as appropriate.

rakatyal · 2017-10-25T18:46:20Z

@roblourens: It would be tricky since we are deciding whether to pause/continue inside the onPaused and it might lead to some code duplication since we will have to store that state too and add extra code to handle the communication with the helper class we create. But if you feel strongly about this, I can try to do that.

roblourens · 2017-10-25T18:53:13Z

I think we should try. If you want to look over it together and decide what should go where, we can have a call or sit down together. But I see this adding a lot of code to core pathways which just deals with one feature, so I think it will be more readable if we can split it up a little.

rakatyal · 2017-10-25T18:54:36Z

Okay. I will give it a try and reach out if I need directions.

…API and Regex matching

rakatyal · 2017-10-30T18:33:29Z

@roblourens: Done some refactoring. Please have a look.

roblourens

This is overall really great, and is exactly what I had in mind. The fact that BreakOnLoadHelper is 200 lines long really justifies having a helper class for this feature.

I left a couple comments about moving even more into that class. I think it would be great if we can get rid of all places where chromeDebugAdapter checks the strategy type and does something different. It shouldn't even know that there are two strategies. It's ok to check it for 'none', that will probably simplify a couple things.

roblourens · 2017-10-31T00:08:27Z

src/chrome/breakOnLoadHelper.ts

+
+    // Sets a breakpoint on (0,0) for the files matching the given regex
+    private async setStopOnEntryBreakpoint(urlRegex: string): Promise<Crdp.Debugger.SetBreakpointByUrlResponse> {
+        let result = await this._chromeDebugAdapter.chrome.Debugger.setBreakpointByUrl({ urlRegex, lineNumber: 0, columnNumber: 0, condition: '' });


You can just leave 'condition' out

roblourens · 2017-10-31T00:15:22Z

src/chrome/chromeDebugAdapter.ts

+            } else { // Else if script hasn't been parsed and break on load is active, we need to do extra processing
+
+                // If the strategy is set to regex, we try to match the file where user put the breakpoint through a regex and tell Chrome to put a stop on entry breakpoint there
+                if (this._breakOnLoadStrategy === 'regex') {


Can you move these few lines into the helper? Then it can check the strategy and do the right thing.

roblourens · 2017-10-31T00:16:31Z

src/chrome/chromeDebugAdapter.ts

+                // set break on load breakpoints. For those files, it is called from onPaused function.
+                // For the default Chrome's API approach, we don't need to call resolvePendingBPs from inside scriptParsed
+                if (this._breakOnLoadStrategy !== 'none') {
+                    if (this._breakOnLoadStrategy === 'regex' && !this._breakOnLoadHelper.stopOnEntryRequestedFileNameToBreakpointId.has(mappedUrl)) {


This is a complicated check, can there be a method like shouldResovePendingBPs on the helper?

roblourens · 2017-10-31T00:18:56Z

src/chrome/chromeDebugAdapter.ts

@@ -465,6 +486,19 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        } else if (notification.hitBreakpoints && notification.hitBreakpoints.length) {
            reason = 'breakpoint';

+            // If breakOnLoadStrategy is set to regex, we may have hit a stopOnEntry breakpoint we put.
+            // So we need to resolve all the pending breakpoints in this script and then decide to continue or not
+            if (this._breakOnLoadStrategy === 'regex') {


We could also hide details of the implementation inside the helper here. I'm thinking, before checking details of the notification, call a method onPaused on the helper. It returns true if the helper handled it, and we should continue. If it returns false, we handle it in chromeDebugAdapter as usual.

roblourens · 2017-10-31T00:29:16Z

src/chrome/breakOnLoadHelper.ts

+    /* Constructs the regex for files to enable break on load
+        For example, for a file index.js the regex will match urls containing index.js, index.ts, abc/index.ts, index.bin.js etc
+        It won't match index100.js, indexabc.ts etc */
+    private getUrlRegexForBreakOnLoad(url: string): string {


Move to chromeUtils and write unit tests

roblourens · 2017-10-31T00:30:13Z

Testing - the easiest way to test this will probably be tests in chrome-debug that launch chrome and use a real page. We could also add unit tests in vscode-chrome-debug-core, and breaking out this helper class could make that easier. Do you think we would benefit from unit tests here?

rakatyal · 2017-11-01T18:10:48Z

Thanks for the great feedback Rob! Addressed most of it. I agree that the best way to test this will be in vscode-chrome-debug and I will start working on it. I am sure we can add some value by adding unit tests but I guess we will be in a better position to assess that once we have the tests written in chrome-debug first. We can then assess the areas that those tests aren't properly covering and then maybe write some unit tests for those. Thoughts?

roblourens · 2017-11-01T18:19:21Z

That sounds good to me

roblourens · 2017-11-04T01:34:48Z

This looks great, I'll merge this once there are tests in vscode-chrome-debug

auchenberg · 2017-11-28T05:13:57Z

Woohu 🎉

vscodebot bot assigned roblourens Sep 27, 2017

digeff reviewed Sep 29, 2017

View reviewed changes

roblourens suggested changes Sep 29, 2017

View reviewed changes

roblourens reviewed Sep 29, 2017

View reviewed changes

digeff reviewed Sep 29, 2017

View reviewed changes

rakatyal force-pushed the breakonload branch from 70217ca to 93062b1 Compare October 23, 2017 22:12

roblourens suggested changes Oct 24, 2017

View reviewed changes

Raghav Katyal added 2 commits October 30, 2017 11:19

Implementing break on load using Chrome's Instrumentation Breakpoint …

c0e2d38

…API and Regex matching

Refactoring code

330568e

rakatyal force-pushed the breakonload branch from 9fcf773 to 330568e Compare October 30, 2017 18:22

roblourens suggested changes Oct 31, 2017

View reviewed changes

roblourens reviewed Oct 31, 2017

View reviewed changes

Addressing feedback

61f3f23

Fixing failures

731f7aa

roblourens approved these changes Nov 4, 2017

View reviewed changes

Making breakonload work when source maps are enabled

2bf4c1d

roblourens mentioned this pull request Nov 14, 2017

Breakpoints never hit for typescript #255

Closed

Small change for break on load tests in chrome-debug

c296b4a

roblourens approved these changes Nov 28, 2017

View reviewed changes

roblourens merged commit 22fbf5f into microsoft:master Nov 28, 2017

roblourens added this to the January 2018 milestone Feb 2, 2018

stephencweiss mentioned this pull request Dec 5, 2019

Update Break On Load Details microsoft/vscode-chrome-debug#960

Merged

Implementing break on load #241

Implementing break on load #241

Conversation

rakatyal commented Sep 27, 2017

auchenberg commented Sep 27, 2017

roblourens commented Sep 27, 2017

auchenberg commented Sep 27, 2017 • edited Loading

rakatyal commented Sep 27, 2017

auchenberg commented Sep 27, 2017

rakatyal commented Sep 27, 2017

digeff commented Sep 28, 2017

auchenberg commented Sep 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

digeff Sep 29, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

digeff Sep 29, 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

rakatyal Oct 3, 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

digeff commented Oct 2, 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

roblourens commented Oct 24, 2017

rakatyal commented Oct 25, 2017

roblourens commented Oct 25, 2017

rakatyal commented Oct 25, 2017

rakatyal commented Oct 30, 2017

roblourens 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

roblourens commented Oct 31, 2017

rakatyal commented Nov 1, 2017

roblourens commented Nov 1, 2017

roblourens commented Nov 4, 2017

auchenberg commented Nov 28, 2017

auchenberg commented Sep 27, 2017 •

edited

Loading

digeff Sep 29, 2017 •

edited

Loading

digeff Sep 29, 2017 •

edited

Loading

rakatyal Oct 3, 2017 •

edited

Loading