{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/tracing-wg/issues/46","repository_url":"https://api.github.com/repos/nodejs/tracing-wg","labels_url":"https://api.github.com/repos/nodejs/tracing-wg/issues/46/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/tracing-wg/issues/46/comments","events_url":"https://api.github.com/repos/nodejs/tracing-wg/issues/46/events","html_url":"https://github.com/nodejs/tracing-wg/issues/46","id":147934027,"number":46,"title":"Expanding this WG to all Diagnostics for Node","user":{"login":"joshgav","id":4421720,"avatar_url":"https://avatars.githubusercontent.com/u/4421720?v=3","gravatar_id":"","url":"https://api.github.com/users/joshgav","html_url":"https://github.com/joshgav","followers_url":"https://api.github.com/users/joshgav/followers","following_url":"https://api.github.com/users/joshgav/following{/other_user}","gists_url":"https://api.github.com/users/joshgav/gists{/gist_id}","starred_url":"https://api.github.com/users/joshgav/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joshgav/subscriptions","organizations_url":"https://api.github.com/users/joshgav/orgs","repos_url":"https://api.github.com/users/joshgav/repos","events_url":"https://api.github.com/users/joshgav/events{/privacy}","received_events_url":"https://api.github.com/users/joshgav/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":29,"created_at":"2016-04-13T03:09:11Z","updated_at":"2016-06-07T23:37:08Z","closed_at":null,"body":"Hello all! I've talked to several of you over the past month about invigorating this working group and creating a greater Diagnostics team for Node. To be helpful, I wanted to come with a tentative plan and hammer out details with everyone.\r\n\r\nTo that end, following is a summary of the diagnostic domains which we can help Node cover and around which we can orient our work. **I propose creating a wiki-like structure** in this repo oriented around these domains and then using PRs to add new domains, interfaces and APIs, tools, samples and docs.\r\n\r\n> Note: \"Post-mortem\" topics are listed here under \"Heap and Memory Analysis\" for completeness; that work should continue in the [nodejs/post-mortem](https://github.com/nodejs/post-mortem) team.\r\n\r\nI also propose we **restart our monthly meeting to discuss items from this list**. In our next meeting, for example, we should probably discuss AsyncWrap issues and how to support the coming Chrome Debugging Protocol in V8.\r\n\r\nCould you provide feedback on the proposed structure? If we have consensus I'll go ahead and work with @pmuellr to organize this repo accordingly.\r\n\r\n---\r\n\r\n## Goals  \r\n- Node surfaces a set of comprehensive, documented, extensible diagnostic protocols, formats, and APIs for use by tooling clients and VM vendors.\r\n- Enable many tool vendors to provide reliable diagnostic tools for Node.\r\n\r\n## Plans  \r\n- Collect, understand, and document existing diagnostic capabilities and entry-points throughout Node, V8, and other components.\r\n- Collect and document projects and products providing diagnostics for Node with brief description of their technical architecture and sponsoring organizations.\r\n- Identify and explore opportunities and gaps, feature requests, and conflicts in existing diagnostics capabilities.\r\n\r\n## Domains  \r\n- Tracing\r\n- Profiling\r\n- Heap and Memory Analysis\r\n- Step Debugging\r\n- Protocol and API\r\n\r\n### Tracing  \r\n- [nodejs/tracing-wg](https://github.com/nodejs/tracing-wg)\r\n- System: dtrace, lttng, etw, systemtap\r\n- V8: TRACE_EVENT\r\n    - Requires implementation of v8::Platform::AddTraceEvent\r\n- Node: AsyncWrap, Domains, Zones\r\n- JavaScript: Domains, Zones\r\n\r\n### Profiling  \r\n- V8 CPU Profiler: `v8::Isolate::GetCpuProfiler` (include/v8-profiler.h)\r\n    - Accessible globally through `--prof`, basic display through `--prof-processor`\r\n    - [node-inspector/v8-profiler](https://github.com/node-inspector/v8-profiler)\r\n- V8 Heap Profiler: `v8::Isolate::GetHeapProfiler` (include/v8-profiler.h)\r\n    - Also accessible through 'v8' module.\r\n    - [node-inspector/v8-profiler](https://github.com/node-inspector/v8-profiler)\r\n- Intel vTune (`./configure --enable-vtune-profiling`)\r\n\r\n### Heap and Memory Analysis  \r\n- [nodejs/post-mortem](https://github.com/nodejs/post-mortem)\r\n- [mdb_v8](https://github.com/joyent/mdb_v8)\r\n- [node-heapdump](https://github.com/bnoordhuis/node-heapdump)\r\n- [lldb_v8](https://github.com/tjfontaine/lldb-v8)\r\n- [IBM IDDE](https://www.ibm.com/developerworks/java/jdk/tools/idde/)\r\n- [Snapshot Utils](https://github.com/bmeck/snapshot-utils)\r\n\r\n### Step Debugging  \r\n- [llnode](https://github.com/indutny/llnode)\r\n- [node-inspector](https://github.com/node-inspector/node-inspector)\r\n\r\n### Protocol and API  \r\n- [Chrome Debugging Protocol](https://chromedevtools.github.io/debugger-protocol-viewer/)\r\n    - Stability and extensibility\r\n- [V8 Debugging Protocol](https://github.com/v8/v8/wiki/Debugging-Protocol)\r\n"},"comment":{"url":"https://api.github.com/repos/nodejs/tracing-wg/issues/comments/224446007","html_url":"https://github.com/nodejs/tracing-wg/issues/46#issuecomment-224446007","issue_url":"https://api.github.com/repos/nodejs/tracing-wg/issues/46","id":224446007,"user":{"login":"rvagg","id":495647,"avatar_url":"https://avatars.githubusercontent.com/u/495647?v=3","gravatar_id":"","url":"https://api.github.com/users/rvagg","html_url":"https://github.com/rvagg","followers_url":"https://api.github.com/users/rvagg/followers","following_url":"https://api.github.com/users/rvagg/following{/other_user}","gists_url":"https://api.github.com/users/rvagg/gists{/gist_id}","starred_url":"https://api.github.com/users/rvagg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rvagg/subscriptions","organizations_url":"https://api.github.com/users/rvagg/orgs","repos_url":"https://api.github.com/users/rvagg/repos","events_url":"https://api.github.com/users/rvagg/events{/privacy}","received_events_url":"https://api.github.com/users/rvagg/received_events","type":"User","site_admin":false},"created_at":"2016-06-07T23:37:08Z","updated_at":"2016-06-07T23:37:08Z","body":"@Jeff-Lewis coming to Node from Java or .NET and expecting to find everything the way you _want_ it to exist is the wrong way to migrate and inevitably leads to very poor programming practices via heavy reliance on accepted Node anti-patterns and usually complete failure because you end up trying to make Node applications look like their old style counterparts and doing a terrible job at it. We've seen more than enough examples of this to reinforce the recommendation that migration to Node also requires a migration of programming styles, both at the organisational level and the technical level and that this reorganisation comes with its own benefits as well (not least of which is breaking apart monolithic application building practices which Java and .NET lend themselves so well to).\r\n\r\n\"Context\" is provided perfectly well via the tools we currently have available to us in Node. Common web frameworks such as Express and Hapi do a fine job of providing what's needed for doing this. Moving to continuation-passing simply means changing the way you think about context. There's nothing new that you need for this unless you're going to overengineer, in which case you're setting yourself up for failure from the begining.\r\n\r\nEven _if_ Zones become first-class in JavaScript, relying on them for these kinds of concerns is also going to lead to tears. It's likely that their use will best applied as an exception rather than a norm and leaning on them to do what can be achieved perfectly well using existing patterns is going to overcomplicate and give you with terrible enough performance that you'll be begging for a JVM in short order.\r\n\r\nThere are very good reasons why \"most Node contributors don't want to touch Domains with a ten foot pole\" and refusing to listen to any of the reasons behind this is not going to lead to a happy place. Hiding behind the pretense that \"Enterprise needs this\" doesn't help either, a significant number of Node contributors either work in Enterprise environments or make their living from dealing with Enterprise deployments of Node in some form. That kind of argument doesn't work as well as it might have a few years ago."}}
{"actor":{"display_login":"rvagg"}}