inspector: JavaScript bindings for the inspector #12263

eugeneo · 2017-04-06T17:27:30Z

Adds bindings for accessing Inspector backend from the JavaScript code
on the main context. Following methods were added to process.inspector:

connect(callback) - begins a new inspector session. Callback argument
will be notified when the message is received.
disconnect() - destroys the session, disables agents and frees the memory
dispatch(message) - sends a message to inspector dispatcher.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is included
commit message follows commit guidelines

Affected core subsystem(s)

inspector

CC: @ofrobots

eugeneo · 2017-04-06T17:29:28Z

The intent of this API is not to create a comprehensive "debugger" API or "profiler" API - instead, the goal is to provide a generic way to talk to inspector so such APIs could be designed for solving specific issues.

eugeneo · 2017-04-06T17:59:46Z

PPC failure needs to be investigated, I am looking into it.

bnoordhuis · 2017-04-06T20:55:04Z

I don't really get what this is trying to accomplish. I mean, I see what it does but not why. What is the longer-term goal here? A public debugger API?

ofrobots · 2017-04-06T21:07:07Z

The debug context is being removed in V8 by EOY. The objective is to provide an alternative mechanism to do in-process debug tooling.

Node core is dependent on the debug context for some internal functionality (example). It would be good to plumb them over the inspector now.
The ecosystem depends on the debug context for in-process debug tooling (example userspace code dependent on this, another example).

eugeneo · 2017-04-06T22:23:28Z

CI is green now: https://ci.nodejs.org/job/node-test-pull-request/7257/

TimothyGu · 2017-04-07T05:45:11Z

Node core is dependent on the debug context for some internal functionality. It would be good to plumb them over the inspector now.

An even better solution is to add C++ bindings for the cases that need them. What has already happened for proxies and promises should also be done to MapIterator and SetIterator, and GeneratorObject too as a bonus.

I don't oppose the second goal of this PR, but it's simply impractical to go through the overhead of the inspector, when all I want to know is the iterated [[Map]] of an iterator object.

bnoordhuis · 2017-04-07T08:01:53Z

Node core is dependent on the debug context for some internal functionality (example). It would be good to plumb them over the inspector now.

I agree with @TimothyGu that using the inspector is complete overkill for that.

The ecosystem depends on the debug context for in-process debug tooling (example userspace code dependent on this, another example).

strong-agent's use is not important; I wrote that code, I can rewrite it. I imagine the same is true for GCP.

ofrobots · 2017-04-07T16:04:45Z

I'm more concerned about the ecosystem usage. The linked GCP module is an in-process debugger for in-production use (outbound connections only). It needs to set breakpoints, gather stacks, evaluate expressions on specific frames. Today, it is pure JavaScript, building on top of the vm.runInDebugContext api. Once that API goes away, we'll need an alternative and having to go to a C++ native module would be reduce the number of people who can use this module.

I haven't done a very deep analysis of the ecosystem, but there are quite a few other modules that also depend on vm.runInDebugContext and they will be forced to C++ native modules unless core offers another way to offer similar functionality in JS.

I think offering JS bindings to the inspector opens up the possibility for the ecosystem to write really cool debug and profiling tooling. Just throwing out ideas: profilers / heapdumps that don't have dependencies on native code or requiring core to add apis for heapdumps; debug functionality integrated into test-frameworks like mocha etc.

TimothyGu

A review of the code itself, assuming this PR is to go forward.

TimothyGu · 2017-04-07T16:11:32Z

src/inspector_agent.cc

+      if (len > buffer.size() - 1) {
+        len = buffer.size() - 1;
+      }
+      buffer[len] = '\0';


Use node::Utf8Value.

Thanks! Did that, made code simpler.

TimothyGu · 2017-04-07T16:15:16Z

src/inspector_agent.cc

+
+Local<v8::Private> DelegatePrivateKey(Isolate* isolate) {
+  return v8::Private::ForApi(
+      isolate, node::OneByteString(isolate, "Inspector#Delegate"));


Can you use the existing private symbol infrastructure?

Done. Not sure if it should be surrounded with #if to only be enabled when building with the inspector...

TimothyGu · 2017-04-07T16:21:07Z

src/inspector_agent.cc

+
+void Dispatch(const FunctionCallbackInfo<Value>& info) {
+  Environment* env = Environment::GetCurrent(info);
+  if (info.Length() != 1 || !info[0]->IsString()) {


The Length check isn't necessary, since if one calls the function without arguments info[0] will be Undefined.

TimothyGu · 2017-04-07T16:23:12Z

src/inspector_agent.cc

+    return;
+  }
+  Agent* inspector = GetInspectorChecked(env);
+  if (!inspector->delegate()


inspector can be nullptr here. I'd even return a Maybe<Agent*> from GetInspectorChecked() and maybe GetDelegate() to ensure nullptr is always checked for.

Done, though I am not entirely sold on using Maybe for pointers...

TimothyGu · 2017-04-07T16:25:35Z

src/inspector_agent.cc

+
+void CreateJSBindingsSession(const FunctionCallbackInfo<Value>& info) {
+  Environment* env = Environment::GetCurrent(info);
+  if (info.Length() != 1 || !info[0]->IsFunction()) {


Ditto about Length() check.

sam-github

Generally I'm in favour of introspectability of the runtime. This PR introduces new js APIs with no documentation, so it is WIP, but in the absence of docs, its hard to comment on it as a feature unless you already are familiar with the v8 c++ inspector session API.

TimothyGu

Echoing @sam-github's concerns here as well. I'm fine with committing the code right now (other than two nits below) as a first draft, but it has to stay behind a flag or disabled by default in some other way, since we would want to be a bit more careful when making new APIs.

Other than the fact that docs are missing, I wonder if these added APIs are as polished as we could make it. To this end, it might be necessary to make an EP for this feature. A few questionable things that came to my mind:

that we are putting everything into process.inspector; maybe we should at one point have a separate require('inspector') (or some other module name) for these user-facing interfaces
that we are creating a new session object from scratch every time connect() is called; making an inspector session a class seems appropriate for this case (const session = new inspector.Session((notification) => { ... }); session.disconnect();)
that only one inspector can be attached at one time; it doesn't take much imagination to think of an instance where the user wishes to debug an application that uses the JS-land inspector API; or am I missing something?

TimothyGu · 2017-04-07T20:27:42Z

test/inspector/test-bindings.js

+scopeCallback = () => (breakpointHit = true);
+debuggedFunction();
+assert(!breakpointHit);
+testExecution();


The test looks fairly convoluted, but I don't have any better idea to refactor it.

TimothyGu · 2017-04-07T20:30:26Z

src/inspector_agent.cc

+    return;
+  }
+  inspector->Dispatch(ToProtocolString(env->isolate(),
+                                                   info[0])->string());


Indentation is off

TimothyGu · 2017-04-07T22:57:06Z

src/inspector_agent.cc

+      || delegate != GetDelegate(env, info.This()).FromMaybe(nullptr)) {
+    env->ThrowError("Inspector is not connected");
+    return;
+  }


The handling here basically means that if dispatch.call(null) is executed, two errors will be attempted to be thrown (one in GetDelegate()'s Get(), one here), which of course won't work. The approach taken by GetInspectorChecked() (i.e. throwing an error in GetDelegate() if the delegate is nullptr) should be better.

I redid the code. Original version was written before the signal handler was merged in. Now V8 inspector is always present and there's no need to check if it exists.

eugeneo · 2017-04-07T23:44:54Z

Thank you for the feedback.

I will work on docs next week, will update this PR then. I will also look into user-land JS module.

At this point, there can be only one concurrent V8 inspector session. Same is true for Chrome - you cannot connect two frontends to the same page.

bnoordhuis · 2017-04-08T12:44:16Z

I think offering JS bindings to the inspector opens up the possibility for the ecosystem to write really cool debug and profiling tooling.

I'm sympathetic but this PR feels a little ad hoc. @TimothyGu already pointed out a few issues and it's not hard to poke more holes. This should be an EP first.

ofrobots · 2017-04-10T17:07:52Z

An EP sounds good. We can get that put together.

Can we add this as an experimental API in the interim? This allows all existing users of vm.runInDebugContext (given #12243) to at least have an alternative to prototype with.

bnoordhuis · 2017-04-10T19:28:15Z

Can we add this as an experimental API in the interim?

I think that would be alright, the question is where? The v8 module?

eugeneo · 2017-04-11T16:16:51Z

I am working on creating an "inspector" module - but I'm fine with any other name.

…

On Mon, Apr 10, 2017 at 12:28 PM Ben Noordhuis ***@***.***> wrote: Can we add this as an experimental API in the interim? I think that would be alright, the question is where? The v8 module? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12263 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARkrd8jmyCSulfQPP6He9Zjf4CjqylHks5ruoLSgaJpZM4M16km> .

dgozman · 2017-04-13T01:02:16Z

test/inspector/test-bindings.js

+  assert.deepStrictEqual(failures, []);
+  assert.strictEqual(cur, 5);
+  scopeCallback = null;
+  session.disconnect();


I'd also add test for:

connect twice;

disconnect twice;

disconnect without connect;

send 1000 messages in a row;

pass non-function as callback;

dispatch without connect.

dgozman · 2017-04-13T01:02:51Z

src/inspector_agent.cc

+  }
+  Local<Object> session = Object::New(env->isolate());
+  env->SetMethod(session, "dispatch", Dispatch);
+  env->SetMethod(session, "disconnect", Disconnect);


I like the API overall.

eugeneo · 2017-04-17T18:12:21Z

I have updated the branch with a new JS API. I also added initial revision of the docs for the module.

jasnell

Still working through the whole PR but some initial requests...

jasnell · 2017-04-17T18:32:20Z

lib/inspector.js

+
+assert(connect, 'Inspector is not available');
+
+exports.Session = class extends EventEmitter {


would prefer ...

class Session extends EventEmitter { /** ... **/ } module.exports = { Session };

for consistency with changes made recently in other modules.

jasnell · 2017-04-17T18:32:52Z

lib/inspector.js

+const connect = process.binding('inspector').connect;
+const EventEmitter = require('events');
+
+assert(connect, 'Inspector is not available');


Not convinced this should be an assert as opposed to a throw.

Indeed; the assert is generally used for testing rather than internally.

Switched to exception, added a test.

(Sorry, it was about a different assert below).

jasnell · 2017-04-17T18:33:39Z

lib/inspector.js

+exports.Session = class extends EventEmitter {
+  constructor() {
+    super();
+    this._connection = connect((message) => this._onMessage(message));


Would prefer using internal Symbols for these instead of _-prefixed properties.

Can you take a look if I did it properly?

eugeneo · 2017-05-16T19:23:48Z

@joshgav I really like the suggestion to use namespace, e.g. nodejs/inspector. It allows to efficiently indicate that the module is coming from the core Node, removes the clash with NPM modules, etc.

To me it looks like this should be a policy for all modules shipped with the Node.js...

ofrobots · 2017-05-17T15:49:30Z

Coming up with a new naming scheme for core modules might be out of scope for this PR. How about: require('vm').inspector()?

eugeneo · 2017-05-17T16:07:17Z

Coming up with a new naming scheme for core modules might be out of scope for this PR. How about: require('vm').inspector()?

Looks good. I also think this could be made into vm.InspectorSession.

Moving inspector session into VM would mean merging the docs, marking the new API "Stable". I don't think this would be a problem.

sam-github · 2017-05-17T18:57:30Z

Didn't Andreas already say he'd give us inspector? We don't have to wait, node's builtins are loaded in preference to any on disk, I think we should stick with inspector.

If we have to move, vm seems weird to me, v8.inspector.Session makes more sense.

Btw, merging docs doesn't have to make the API stable (see url.md as an example, some is stable, some is not).

joshgav · 2017-05-17T19:37:59Z

@sam-github

We don't have to wait, node's builtins are loaded in preference to any on disk, I think we should stick with inspector.

Users of that module may not appreciate that :)

addaleax · 2017-05-17T19:42:16Z

@joshgav I think at 112 downloads/month we’re good ;)

ofrobots · 2017-05-17T20:43:48Z

I think at 112 downloads/month we’re good ;)

If that is a low enough number for others, that works for me too!

ofrobots · 2017-05-17T20:51:38Z

@sam-github, @jasnell you have existing changes-requested reviews here. Can you take another look to see if they can be disposed now?

Issues fixed

addaleax · 2017-05-18T11:40:55Z

doc/api/inspector.md

+
+Emitted when a notification from the V8 Inspector is received.
+
+### Event: INSPECTOR_PROTOCOL_METHOD


Is there any reason why this is uppercase?

I am not sure what the proper syntax here. I was trying to make it look different as it is not an actual value but a variable...

How long is the list of possible events? Would something like this be doable?

### Event: Foo1 ### Event: Foo2 ### Event: Foo3 …

The list is already quite long. And the protocol is expandable - there are plans to provide Node API to define new "domains" and hopefully to bring Chrome "Network" and subtarget domains.

This is an interesting doc case, because there are no other examples of it currently in Node that I'm aware of. It is common in node packages to have events with values that aren't known before hand (websockets, etc). I think its not clear enough that its a variable, maybe <inspector-protocol-method> would be better, because its clearly not a string? Also, I think this would be more clear if the 'inspectorNotification' event had an example and some more text. IIRC, each inspectorNotification has a method: <inspector-protocol-method> field, and the notification is emitted twice, once with the event name set to the protocol-method. This allows subscribing to all notifications using 'inspectorNotificaion', but it also allows users of the API to subscribe to only the notifications they know they are interested in. <--- something like this last sentence is what is missing. With some more info in the 'inspectorNotification' event, its possible this "pseudo event" would not even need to show up as its own ## Event: ... (something)... section, or at least could be documented with a simple "See the 'inspectorNotification' event for more information.

I uploaded a new doc, PTAL.

addaleax · 2017-05-18T11:41:20Z

doc/api/inspector.md

+* {Object} The notification message object
+
+Emitted when an inspector notification is recieved that has method field set
+to INSPECTOR_PROTOCOL_METHOD value.


I think there’s a missing the before INSPECTOR_PROTOCOL_METHOD, and I’d put the latter in backticks

I changed to notation.

addaleax · 2017-05-18T11:42:44Z

doc/api/inspector.md

+Up-to-date version of the V8 inspector protocol is published on the
+[Chrome DevTools Protocol Viewer][].
+
+Node inspector supports all V8 domains.


Just curious, what does “V8 domain” refer to here?

@addaleax all Inspector methods are namespaced to a domain, e.g. Debugger.enable and Profiler.start.

A list of the currently supported domains is on the left of the protocol explorer at https://chromedevtools.github.io/debugger-protocol-viewer/v8/

"supports all V8 domains from the "Inspector Protocol" or "Chrome DevTools Protocol"" might make that clearer.

@joshgav Thanks, that makes sense :)

addaleax · 2017-05-18T11:48:02Z

lib/inspector.js

+
+  [onMessageSymbol](message) {
+    const parsed = JSON.parse(message);
+    if (parsed['id']) {


I would just use parsed.id, parsed.result etc. here

addaleax · 2017-05-18T11:49:10Z

lib/inspector.js

+  post(method, params, callback) {
+    if (typeof method !== 'string')
+      throw new TypeError(
+          '"method" must be a string, got ' + typeof method + ' instead');


Can you use template strings for these?

addaleax · 2017-05-18T11:53:28Z

src/inspector_agent.cc

+    callback->Call(receiver, 1, &argument);
+    if (try_catch.HasCaught()) {
+      try_catch.ReThrow();
+    }


What’s the point of this try_catch?

Mostly to debug programmatic errors in handlers.

I’m not quite sure I understand – is the idea that people can set a debugger breakpoint for the ReThrow() line?

No, it's to surface simple exceptions, like null pointer dereferences, etc. It is not possible to use debugger frontend when working on a code that uses inspector.Session so printf debugging is pretty much the only option.

This is the test code: https://github.com/eugeneo/node/blob/d92bc580a1187e82508d5ba2149e3fa0c8b522d3/test/inspector/test-bindings.js#L94

@eugeneo I think we may not be talking about the same thing here.

My question is not whether it makes sense to pass along errors, but rather what this TryCatch actually changes; if you remove it, the errors won’t be caught here, but that doesn’t make a difference if the alternative is just re-throwing immediately, does it? The test you linked to does pass without it.

I uploaded a new version. I assumed that you always had to use TryCatch and rethrow the exception when calling JS from native. Thanks for pointing it out that it is not needed!

addaleax · 2017-05-18T11:54:03Z

src/inspector_agent.cc

+    TryCatch try_catch(isolate);
+    Local<Function> callback = callback_.Get(isolate);
+    Local<Object> receiver = receiver_.Get(isolate);
+    callback->Call(receiver, 1, &argument);


Can you use the MaybeLocal overload here?

addaleax · 2017-05-18T11:57:03Z

src/inspector_agent.cc

@@ -155,6 +161,146 @@ static int RegisterDebugSignalHandler() {
 }
 #endif  // _WIN32

+class JsBindingsSessionDelegate : public InspectorSessionDelegate {


I think you can wrap (almost?) everything in here in an anonymous namespace

I moved the ChannelImpl into anonymous namepace.

addaleax · 2017-05-18T12:03:44Z

test/inspector/test-bindings.js

+  assert.throws(() => session.post('Debugger.enable'), (e) => !!e);
+}
+
+function testNoCrashWithExceptionInCallback() {


Is there any reason to wrap this in a function? It seems like block scope would be enough for it.

I did it to document what it does.

sam-github · 2017-05-18T19:02:12Z

Still LGTM, though every console.log() in the example would be more helpful if it had a comment after showing the output.

eugeneo · 2017-05-18T20:35:25Z

@sam-github I documented the expected outputs.

eugeneo · 2017-05-18T22:46:08Z

CI: https://ci.nodejs.org/job/node-test-pull-request/8162/

addaleax · 2017-05-21T19:33:14Z

Is anything left to do for this to land?

bnoordhuis

LGTM modulo comments. Did we settle on the module name?

bnoordhuis · 2017-04-25T08:47:54Z

doc/api/inspector.md

+added: v8.0.0
+-->
+
+The `inspector.Session` class is a primary means of dispatching the messages to


'the primary means'?

Tangential: 'primary' suggests there is also a secondary means.

bnoordhuis · 2017-04-25T08:49:54Z

doc/api/inspector.md

+session using this API will throw an exception.
+
+Up-to-date version of the V8 inspector protocol is published on the
+[protocol viewer][protocol-viewer]


Missing punctuation.

bnoordhuis · 2017-05-22T09:03:46Z

doc/api/inspector.md

+added: REPLACEME
+-->
+
+Create a new instance of the `inspector.Session` class. The resulted inspector


Typo: s/resulted/resulting/ (or just drop the word altogether, it's somewhat superfluous.)

bnoordhuis · 2017-05-22T09:06:21Z

doc/api/inspector.md

+
+* {Object} The notification message object
+
+Emitted when an inspector notification is received that has method field set


s/method/its method/

bnoordhuis · 2017-05-22T09:12:16Z

doc/api/inspector.md

+* params {Object}
+* callback {Function}
+
+Posts a message to the inspector back-end. Optional `callback` will be notified


I'd drop the word "Optional." The function prototype makes it clear it's optional and "Optional callback" reads awkward (ad "The optional callback" isn't really an improvement, IMO.)

bnoordhuis · 2017-05-22T09:21:18Z

lib/inspector.js

+    const remainingCallbacks = this[messageCallbacksSymbol].values();
+    var error = new Error('Session was closed');
+    for (const callback of remainingCallbacks) {
+      callback(error);


Consider doing for (const callback of remainingCallbacks) process.nextTick(callback, new Error(...)) for two reasons:

It ensures subsequent callbacks still run if a callback throws, and

new Error(...) gives each callback its own copy.

bnoordhuis · 2017-05-22T09:22:55Z

src/inspector_agent.cc

+    JsBindingsSessionDelegate* delegate = info.GetParameter();
+    delegate->Disconnect();
+    delete delegate;
+  }


Blank line.

bnoordhuis · 2017-05-22T09:23:30Z

src/inspector_agent.cc

+    const FunctionCallbackInfo<Value>& info) {
+  Environment* env = Environment::GetCurrent(info);
+  Local<Value> delegate;
+  MaybeLocal<Value> delegateField =


Style nit: delegate_field (also, maybe_delegate is perhaps a better name for it.)

bnoordhuis · 2017-05-22T09:25:09Z

src/inspector_agent.cc

+    env->ThrowError("Inspector message must be a string");
+    return;
+  }
+  Maybe<JsBindingsSessionDelegate*> maybeDelegate = GetDelegate(info);


Style nit: maybe_delegate.

bnoordhuis · 2017-05-22T09:27:48Z

src/inspector_agent.cc

+  delete delegate.ToChecked();
+}
+
+void CreateJSBindingsSession(const FunctionCallbackInfo<Value>& info) {


Maybe call this Connect() since it's exposed as .connect?

There already is Agent::Connect so I renamed to "ConnectJSBindingsSession"

eugeneo · 2017-05-22T20:49:42Z

@bnoordhuis

Did we settle on the module name?

'inspector' seems to be the final name.

eugeneo · 2017-05-22T20:57:35Z

Did some edits to a doc. Please review, I hope to land it tomorrow.

addaleax

Still LGTM, go for it.

Fresh CI: https://ci.nodejs.org/job/node-test-commit/10075/

bnoordhuis · 2017-05-23T09:14:42Z

doc/api/inspector.md

+-->
+
+Connects a session to the inspector back-end. An exception will be thrown
+if there is already a connected session esteblished either through API or by


Typo: established. Also, "the API".

bnoordhuis · 2017-05-23T09:15:38Z

doc/api/inspector.md

+[Chrome DevTools Protocol Viewer][].
+
+Node inspector supports all the Chrome DevTools Protocol domains declared
+by the V8. Chrome DevTools Protocol domain provides an interface for interacting


Just "V8". :-)

addaleax · 2017-05-23T17:55:07Z

Landed in 60390cd, fixed Ben’s nits during landing.

PR-URL: #12263 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Timothy Gu <timothygu99@gmail.com> Reviewed-By: Josh Gavant <josh.gavant@outlook.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. dont-land-on-v4.x test Issues and PRs related to the tests. labels Apr 6, 2017

eugeneo added inspector Issues and PRs related to the V8 inspector protocol dont-land-on-v6.x labels Apr 6, 2017

ofrobots mentioned this pull request Apr 6, 2017

doc: deprecate vm.runInDebugContext #12243

Closed

4 tasks

eugeneo added the diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. label Apr 6, 2017

mscdex removed the test Issues and PRs related to the tests. label Apr 6, 2017

TimothyGu suggested changes Apr 7, 2017

View reviewed changes

sam-github suggested changes Apr 7, 2017

View reviewed changes

TimothyGu reviewed Apr 7, 2017

View reviewed changes

dgozman reviewed Apr 13, 2017

View reviewed changes

refack force-pushed the master branch from 16073c0 to fbe946b Compare April 14, 2017 04:11

jasnell previously requested changes Apr 17, 2017

View reviewed changes

sam-github approved these changes May 18, 2017

View reviewed changes

addaleax approved these changes May 18, 2017

View reviewed changes

eugeneo mentioned this pull request May 18, 2017

inspector: allow opt-out of console.* hijacking #13106

Closed

addaleax added the semver-minor PRs that contain new features and should be released in the next minor version. label May 21, 2017

bnoordhuis approved these changes May 22, 2017

View reviewed changes

inspector: JavaScript bindings for the inspector

f6a70f4

addaleax approved these changes May 22, 2017

View reviewed changes

bnoordhuis approved these changes May 23, 2017

View reviewed changes

addaleax closed this May 23, 2017

jasnell mentioned this pull request May 28, 2017

8.0.0 Release Proposal #12220

Closed


		assert(connect, 'Inspector is not available');

		exports.Session = class extends EventEmitter {


		Emitted when a notification from the V8 Inspector is received.

		### Event: INSPECTOR_PROTOCOL_METHOD


		* {Object} The notification message object

		Emitted when an inspector notification is received that has method field set

inspector: JavaScript bindings for the inspector #12263

inspector: JavaScript bindings for the inspector #12263

Conversation

eugeneo commented Apr 6, 2017 • edited Loading

Checklist

Affected core subsystem(s)

eugeneo commented Apr 6, 2017

eugeneo commented Apr 6, 2017

bnoordhuis commented Apr 6, 2017

ofrobots commented Apr 6, 2017

eugeneo commented Apr 6, 2017

TimothyGu commented Apr 7, 2017

bnoordhuis commented Apr 7, 2017

ofrobots commented Apr 7, 2017 • edited Loading

TimothyGu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TimothyGu Apr 7, 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

sam-github left a comment

Choose a reason for hiding this comment

TimothyGu 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

eugeneo commented Apr 7, 2017

bnoordhuis commented Apr 8, 2017

ofrobots commented Apr 10, 2017

bnoordhuis commented Apr 10, 2017

eugeneo commented Apr 11, 2017 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eugeneo commented Apr 17, 2017

jasnell left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eugeneo commented May 16, 2017

ofrobots commented May 17, 2017 • edited Loading

eugeneo commented May 17, 2017

sam-github commented May 17, 2017

joshgav commented May 17, 2017

addaleax commented May 17, 2017

ofrobots commented May 17, 2017

ofrobots commented May 17, 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

sam-github May 18, 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

eugeneo commented Apr 6, 2017 •

edited

Loading

ofrobots commented Apr 7, 2017 •

edited

Loading

TimothyGu Apr 7, 2017 •

edited

Loading

ofrobots commented May 17, 2017 •

edited

Loading

sam-github May 18, 2017 •

edited

Loading