Node.js Diagnostics Working Group, 19 Jan 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Node.js Diagnostics WG Meeting - Jan 2017

Description

https://github.com/nodejs/diagnostics/issues/79

A

Alright thank God says that the hangout on air is live so yeah. Let's go ahead and get started.

A

First thing is open up the google doc from the link of the meeting. If you could and make sure you put your name under attendees, so we know who's here.

A

Okay, sorry to the richards, they still are having trouble. You just wrote on the issue. Somebody could just try back in there. Maybe they could watch on youtube, I, guess I'm, not sure we can do for them at the moment.

A

Yeah so put your name in there and then let's go ahead and jump into the agenda.

A

So basically it breaks down into stuff related to inspector stuff related to trace and stuff related to async context and invited the post mortem people to join us, namely Richard Chamberlain, richard lau, we're trying to get on the call.

A

So they can, they might be able to give us an update on a couple projects coming out of that group and I I thought it would be good for us all to be aware of each other. Since there's a lot of overlapping in the domains were targeting.

A

Ok, so, let's just briefly review our previous meeting, which actually was add, note interactive in the collaboration summit under trace. We talked about what we expect, people to use trades, for we talked about that. We do want a jsapi for trace and we talked a little bit about what conventions might be for people to use different category names and different payload fields, and we talked a little about trades points in core. Looking at the next steps, I think we tackled, we added the experimental warning.

A

We had a brief discussion about how to abstract from v8, and we delayed that I would put that off for now and we landed the PR, congratulations, Matt um and then the last one actually was kind of on me and we didn't do it yet stall break out the tasks in the diag repo.

A

That's something we should we'll talk about today, I think under inspector last time we said that we want to deprecate the interface so no dash dash debug deprecated, the CLI debugger get young crams node inspect in as a replacement for the old CLI debugger, and we came up with a strategy for activating inspector and a running process. I think also here, we've covered a lot of the next steps we've been discussing. What else needs to be deprecated like the doc step vacation?

A

uh We I open an issue for deprecated in a CLI debugger, which we'll talk about a little today, we've opened the issues to bring doubt inspect in ongoing discussion about how exactly to bundle the CLI debugger in the thread about switching to sig user. One I think Eugene awestruck off from google said that he's working on that and we probably need to think about messaging changes to the community stuff.

A

We talked a little there about a sync contacts: propagation and basically the call to action was to review the new and better API, which I think Trevor was adding and I'm sure Jeremy I could tell us about.

A

So with that, let's go ahead and jump into today's, so I tried to organize under the minute section in the doc. Yeah give us a kind of a flow here. So the first couple items are some requests for comments about new capabilities that that Google or Eugene is proposing in the inspector protocol. um So I guess it since we're all together.

A

I just thought it would be a good time for us to to come up with an opinion on that and whether we want that a node and so the first one is support for sub-process inspection. And obviously you can look at the issue. Basically, should the inspector be able to proxy inspector commands to another sub process, which is which could be particularly useful for for class and things?

A

So, let's just open it up for discussion.

A

Really think about that sounds.

B

Useful I really have much else to comment on other than that.

A

Is that it all I'm thinking about this? Also, is it at all a concern that those processes won't be won't, be clearly started with, say, dash, dash, inspect and yet will be subject to inspection.

A

There any concerns with that or.

B

We could have child process spawn those with like a similar thing, I think if it's built into mode I.

A

Think this proposal is essentially that if inspector is running in the parent process, then it would I.

A

Guess, you're right, it's not clear on the proposal, whether the it would be obvious within that process that it was being inspected. I, don't I, don't really know so. Overall, though, we think this is a good idea. I.

B

Mean it looks like it sounds like a good idea on the surface, but I don't know what the details of that might all be.

A

So maybe we'll just replying that issue that today's meeting consensus is that is a good idea. Go forth.

B

At least move forward with the perfect concept yeah, it might be more useful to take a look at what the implications of that might be.

A

All right, so, let's look at the next one, similar request from Eugene how about adding a inspector support for for network protocol tracing.

A

So I guess there are two questions: whether we want to support network protocol tracing and then another question that came up in the thread is whether that should go through the trace system at least first or how to inspector.

A

So again, I want to open it up for our comments, do we think this is good idea? Do we really prefer the trace event route.

B

I prefer the async cook events route. So the only thing I have really like the big thing I have at this is, if you're just trying to display, like all HTTP connections in arm.

B

Like in the in the what's that thing called like the chrome inspection is that right, yeah like it's not like a website where I mean with some websites have a lot, but if you're, trying to like look at most I feel like most like uses of node that actually significantly use hcp and look at that in a dev tools.

B

Inspector like it's there's just going to be so much of it like you, won't be able to tell what's going on like I guess you might be able to get some insight for a connection, but I think it most Lee just be like a flood of information.

B

And I'm not sure what kind of performance impact that might have either.

A

um That the valid concern- but maybe that's like for us, like yes, chrome devtools, would be one of the main consumers, but it could be consumed by other tools. Also, like I mean I'm with Microsoft, we probably have it consumed in something else, and I assume chrome devtools could make adjustments to their UI. Also.

A

So are there any concerns having it in the in the system itself, forgetting about you know how might be presented I.

B

Mean I think I still think I you said, cooks is better suited to the task and.

A

So what do you mean by that async hooks like you're saying it? You wrap network connections with async hooks, then I.

B

Mean they've all network connections, all right are wrapped with ace and cooks. So I like are we just duplicating the same thing? I know.

C

It wouldn't be duplicating so so. Tracy mint currently does not instrument note, but the idea would be wherever you have a sink hooks. We probably want Chris image of the same places. So what race event is is a mechanism to get some important data out to debuggers or other Turing and, however, that during wants to display it or if better touring can be able to better show, this I think it's up to the two lighters to do it right.

C

So the objective we should have as part of Diagnostics is they provide a communication channel through the method through which the data can be exposed to tooling at a low level and let others build whatever higher-level tooling and debugging tools there that they can.

A

Quali the question here is about whether to add support for the network domain into the inspector agent. I guess the v8 inspector in node and then a secondary question is if we do want to support. That is that is the right place to start by going to trace events, yeah.

C

Actually I was talking earlier seems like the mic. Wasn't working so I, don't know what what you see her to do here. So my personal opinion is I think we should add, support to trace event first, because we certainly need ability, increase event to get information about network traffic, because that's the whole idea of tracing and that may be adequate I, don't think.

C

Maybe we don't need, maybe that's adequate for dev tools or other debuggers to work with whatever they need to do and if there's some deficiencies I can we think we can go from there now I do think it should be built on top of a sink cooks.

C

But Chris event is probably the starting point. In my opinion,.

B

So is what you're suggesting then I'm not really sure how you can fire a trace event, but would it be possible to have like an NPM module I'm, not sure if it need to have native parts in it, but then hooked into a sink ox, and then it fired the trace events I.

D

Think so I mean I look well. There will be performance implications of that.

B

Right, do you just mean from going from jas the c++ and back correct.

C

If you can do so, it for load Corps for four native stuff, if you can fire the tracer men nike from or see purpose binding code that wouldn't.

B

C

Performant way of doing it.

B

Well, it's not going to be an iteration one, but they're supposed to be a c++ advance API too. So, let's get to know ya.

C

In the prototype that Matt belt, he actually put the trace amounts in exactly all the places that is in cooks. Async raft is, is there so it's a really natural place to put the the tracer meant instrumentation. He didn't put it in his pull request, but that that's the easiest way to add this dressing. To note core.

A

So I think we are actually. We should use async hooks as the entry point to capture that network event data. We should write that network event data into the trace event system.

A

Due for what Eugene has do, we want to somehow expose that from there into the network network domain and the inspector protocol.

D

Yeah I think he's.

C

Like get in touch with Eugene on this one, on yeah, actually hindsight I should have added him to this meeting, but yeah I think we should touch base with the the debugger people see it was the easiest way for them to consume. This data is whether trace is adequate or, and if not, what are the deficiencies and what? What kind of a domain do we need in inspector for network stuff, okay,.

A

One of the ones I was talking with Jason who's on the call here and one of the things that would be important. Probably if we went the trace event route would be a listener's L that could capture well in this case, will be network events, but could be other ones too, and that's actually something Jason's been thinking about is how to listen. How either c++ or JS modules could listen right.

E

So if we wanted to hook this into detector protocol, the way we do, that is a trace event listener at the C++ level and um Delos Norwood received raise events and translate those to read inspector protocol.

E

The missing piece there is that there's not currently support for trace listener than deviate location of tracing. There's a man flirting their board, but it wouldn't be a to trace event from chromium. They stripped out a lot of stuff. They didn't want and listen to. Our support was excluded. We have an 11.

C

Okay, I can throw them back to eugene and and the crazy one team to to see what, with the best way to proceed here might be whether we bring in that education or door. Whether there's some other way to implement this.

A

Okay, for the purposes of this conversation, I think we kind of had a straw man which was use async hooks to get the events right. There's a trace event, use trace event, listeners potentially to add to send them out if we wanted them to all the inspector protocol or something like that that sound about right.

C

Yeah make it make sense, I'm.

A

Writing down Allie that you're going to discuss with Dean.

A

Anything else on that.

A

Alright, so let's move to the next one, which is about deprecating, the old debug agent and the CLI debugger I open this PR. It's not finished up what kind of said. Actually that's what I want to bring up is when what are the timelines? Should we land us now, I think one of the feedback was, we should make sure note, inspect, is ready to go.

A

An option is to just separate out these these two and deprecated the debug agent and wait to deprecate the CLI debugger to load in spec lands.

A

Actually, I'll propose that, can you get you all can disagree if you want which.

B

Branch are you targeting with us.

A

Would be could be cut in the next release? I think well, I mean we can talk about that, but I think we wanted to go to a7x release.

B

Yeah I would because it's not going to.

A

Exist at all in eight right. Well, that actually is another thing depends if we go with v8 5, 7 or 8 58 as I understand, correct.

B

Would there be other motivation to go with v 580.

C

Okay, there might be some motivation not to go with the 858, so so so there in 5-8 might include turbofan else as a default. Jit compiler. So and given that it's an LPS I, don't know if you want to pick up the first version of turbofan when it becomes a default interesting.

A

So to be clear, 58 doesn't include the OB bugger at all.

C

Also includes the program, so so 58 also will not include the exposed debug as commanding plug. Okay, that's probably the bigger reason why we don't want to go with 58 48 x.

C

And the time I a bit too close, I think I think 58 comes out at the very end of april, which is probably too late for us to ship with no date.

A

To do we hear up as a group, how do we have an opinion like I? Was the diagnosis group that look? We should stick with 57 to make it easier for this transition.

A

Meaning, if it comes down to it and james is like we want to go 58, should we make a stink and say no, we need to stay 57 to keep the surround. I.

C

Have an opinion, but I don't have as a group my opinion are or, as a group diagnostic opinion, really matters. I think at the end of the CDC that has to decide the / and weigh the pros and cons yeah.

B

We can still make us adjustment to them too, though,.

A

Yeah, that's what I'm asking really would we suggest that we stay with 58 s, sorry stay with 57, because then we give a little more time for this adjustment.

C

I've certainly support that um yeah.

F

I would say, probably.

A

hmm This kind of makes a difference like show so well. Actually, that's the question doesn't make a difference so should we land the deprecation? Nevertheless, now at 750 or whenever the next chance we get no.

B

So we should only land it in a already existing major branch if it will be removed in the next version. I.

B

Think so I think actually technically then, if we had a choice on that, then the ctc should probably pick 57 because it breaks our somberness far less mm-hmm.

G

A

So do so we kind of need the CTC to make a decision soon, if they're going to go with 57 or two right, and if so, then we don't have to land this now we'll get it into the ADA X branch.

C

Yeah we'll be good to get clear, ctc sign off on this as 5.7 being the target. If that's case, then it makes your path head much simpler.

A

And so I think the next steps on this is to ask the CPC to tell us or the plan is for 57 58 open there.

A

Any other items there around deprecation.

A

All right, so, let's move on to the next one. This is actually another one of mine, oh and actually I think this should be separated. So I put up a PR to update the hint text that comes out when you do def dash, inspect and to add a guide about it. um I'm pretty sure. Now that they're working on step rating out the guides to different part of the Borg I think no Jo repo, so I'll move that guide over there in some form and we can all review it.

A

So that's faster OOP guide to org um I do think we should talk about the hint text, though, and that's just because we're we're getting it. It's become almost a standard feature, and maybe we should make sure they're providing the information that people need in a easily consumable form.

A

um I'll put a straw man out there. I guess like we could potentially return to json that we return with if you do like JSON / Liske, meaning what I'm thinking about is that people need that grid.

A

Or do people need the full URL with the chrome, dev tools? I guess that's another question for this. For this group.

B

Are we moving away from the devtools URL for the stable release of this wherever whenever that might be, because.

A

That's part of the question: should we move away from that URL and if so, what should it? You know? What should the output be, and maybe part of the question is, how do we get this out from the experimental state.

C

Okay, I think we have to get it out of experimental before eight point X right, because if you're going to deprecate the old seal, a debugger or both like a protocol, I.

B

Don't think we have to.

B

Perhaps it'd be nice.

C

Wait it's the two questions in that case. So first question is yeah what is needed for it to be not experimental and then when we can get that done so I think that I be good to get an understanding of when when is it not experimental? If you're like in my mind, if we are offering it it deprecating something and saying use this instead and it's experimental, it just doesn't seem right.

A

We need to do to get it out of experimental.

B

Either of the CTC probably vote on it to tie or like open up PR that may well yeah I think you'd probably need to ctc vote on it, because it's a pretty large thing or they seed want ctc consensus on it, but I'm not sure. If that can be done in a major or know it can be done in a minor, because that's what we're going to do for acing cox-2. um Was there an EP on this?

B

Not that there has to be. I'm just wondering. I don't recall if there was one.

A

Or not for any.

B

A

It was an issue. Okay.

A

We could try to find that I.

B

Yeah I, like I, don't think it's super complicated I would move forward with opening, essentially a pull request that you tag is ctc agenda arm and it's you. You want to bring this out of out of experimental in a minor version.

A

You don't necessarily have to bring it out. Well, I, guess it depends on the previous thing, but we could bring it out of experimental and eight. You could.

B

But it I don't think it is necessarily semper major unless anything API wise is changing in that transition. The only other major thing that we would that would be wanted. Is we essentially need some sort consensus about the from the people working on it that the API is probably not going to radically change in the near future, because if it is, then it should still stay experimental.

B

Does anyone have questions on that? I have some opinions on this specific poll request, otherwise,.

A

I was just going to mention that the paste the link in here of the chrome devtools team, what the protocol is now and I- think that's what you're I just want to make sure we have the info that the CTC is going to ask for so I think you're asking if that, if that protocol, the chrome debugging protocol is stable, yeah.

B

Sencha lee, but also any API parts that are implementation-specific in any way, I, don't like I'm, not sure what the extent of those might be.

C

So what do you mean by API parts that are implementation-specific getting.

B

Elaborate mmm yeah again I'm, not sure if there really are any like. Maybe you have some flag that does anything else that it's like a part of it like debug break, maybe that behavior still you're thinking might need to change a little bit. We wouldn't want to necessarily stabilize that unless, like a couple of things like that, if you're already thinking, they might need to be changed for anything any part of the exposed public API.

B

Essentially, um if they're still thoughts that that's you know still going to really need to be changed, we would probably want to factor that into the decision. Does that help clear it up.

C

I'm not sure so so so, let's take, let's say cig user one, for example. Right so at some point the user one will start enabling the new debug protocol, but that doesn't have anything to do with the protocol or the protocol API itself. It's it's a new feature to a debug service respond when the user, one is said so so I don't know if that's necessary, related, so I'm, not sure I'm, trying I'm trying to figure out what kind of things would be considered.

C

Part of the API so some other than flat, such as debug break. Again. Those are nodes. Flags, yeah.

E

C

They enable of which protocols enable our are not dependent on the protocol right.

B

So it might be a lot simpler in the case of inspector. If we look at a similar example, so acing cooks, if we were like hmm you know, we might need to get rid of after in the future or after might need to return vastly different parameters, or something like that like we would probably still want to keep an experimental until we kind of iron. That out does that make sense. Yeah.

C

Yeah I guess so the question is going to be: is it any sort of epi this exposes perhaps in process actually by the way? I do know that Eugene is working on adding an API to exposes to JavaScript, so you could programmatically enable inspection from JavaScript, but that sounds like a semi minor edition, not not a change of the EPI but but a new degree so, but but yeah so I think what you're saying is. If is there any api whatsoever?

C

Let's go figure figure it out and make sure that we're comfortable with saying yeah. We don't need changes in this green color, yeah.

B

More for more for AP is that we think like either are in the current experimental API or that yeah essentially stuff. That is going to be in that first public API. If we're like okay, we might need to radically change like some. Some part of it, not not really, like add on to adding on to it's fairly simple yeah.

C

Yeah I can circle back and do a review. I, don't I, don't think, there's any API a piece I'm, not aware of any API right now. It's all internal to note course. So, really.

A

C

Good, we go to creepers at that. Make.

A

Oh, you know what got actually I actually am thinking about that. I opened an issue a long.

H

A

Ago it is tightly coupled right now from the web back in the WebSocket domesticate and if other VMS wanna plug in, we would have to do some refactoring in the middle, and I think chocolate will want to talk in eventually. um So maybe that is something we might want to ask about. Yeah.

C

Should be good if you can talk to the folks there as deceived it and if, if the plumbing is adequate for you to plug in chakra core or if there's changes you want I think we go to get some feedback on it sooner. Okay,.

A

That's fair, so let me we might need a little while for that of like a week or two, but if you.

A

Just thinking should we go ahead and bring it up for ctc review, probably and then I can ask the chocolate for people to look at over to and be part of that discussion.

A

Sounds good to me, cool.

B

So, just on this actual per request, um I kind of agree with some of the change on the message, I I- think what's really important for the message to contain is a link to documentation. That way, it's a little bit easier for us to list all the options to possibly interact with this. While it's an experimental, still issue a warning and then I think it should probably print the whatever is actually needed from any implementation to connect to it, which is probably just the port um or like port NGO ID or whatever I.

A

Guess, v8 folks ally in particular. Do you do you think that we should? Is it okay to take the chrome, devtools URL out and just make it WS? You know hosts colon port / win.

C

Let me talk to Powell and the dev tools. Team I know that they were working on some feature in 5.6. That makes it really easy to connect. So so the goal ready is that anybody is using. It should should have very easy way to connect using multiple different debuggers doing devtools. So let me circle back on that one to make sure those things would get into VA, chrome, 556 or whatever status is yeah.

A

Honestly, some of the comments are about the usability of that URL like it folds and people can't copy it and it's not automatic and they don't know the quid and it changes. So uh it's not really only about like other tools, although obviously vs coat, you know, brings it up from time to time. um It's also, you know the pure usability right. It also like interferes with its goes to standard app error, I think, but it still covers of the output yeah.

B

It'd be nice to print primarily like maybe Doc's info and then like the the parts that you would actually need to paste into I'm, like Chrome or anywhere else, to actually connect from anything. Essentially.

A

Sorry and the DIA got crashed on me. There I.

A

Think our next steps here are.

A

To move it out of experimental state and Ally's gonna handle that or get that going. uh As we move out of experimental state that we're going to have to update the text, then anyways we'll update it then and we'll get Ali. Maybe you can get the input from the dev tools team? How and we come up with something I'll try to get vs code to chime in and we can come up with something yeah.

A

So I guess there are only two things: get it out of experimental state and as we get it out of experimental state, decide on what the hint text is.

A

Ok, next note inspect, so that's pretty I can give an update on that we're pretty moved along with that the CTC and the tsc both signed off on bringing it into the foundation. So it's just now. Logistics probably made William kappa figuring out how to get it in um I.

A

Think. The only question that might remain for this group is exactly is to just mention how we're considering bringing it in and see. If there's other thoughts so essentially now to use the CLI debugger, you can run node space, debug space, you know userscript jas and it actually runs the local node instance running a special debugger client and then spins up the user script, and it attaches it to that to the local debugger.

A

um Do we want to have the same experience for node in spec, or somebody could type node space inspect space script Jas and or do we want no space debug still I.

F

Don't have strong feelings on this one I.

F

B

If it could be kept so essentially, I have the functionally to be at least reminiscent of node space debug.

B

Yeah agree: we don't, we don't have like a huge debugging story for from node, as it is so having something like that more pretty much anyone has access to it. Right away is probably a good idea.

A

Yeah I agree I like these that sometimes I.

A

Think that in that thread, I think I might have even done something to make that work, and it wasn't all that difficult. So, basically, we support that and that's how we'd like to see it integrated um anything else around note inspect. Actually the next one is kind of related was a proposal to move Ben's at node heap, dump tool and basically, that stuff is all accessible now via the inspector protocol.

A

So it makes sense and beyond, has already done something somewhere for cpu profile kind of makes sense to just integrate that into node inspect that functionality. I, guess that's my suggestion there and I want to bring that up.

B

I'm not really sure what this tails so I'm not going to sign off on it.

A

Because it's fair enough, basically it'll be once note inspectors in I can make a PR to the repo to add that and refer to that issue. I.

A

Think they're going to be a number of things like this as CPU profile heaped up there too obvious ones where now that it's available in inspector, it's not a big jump to make it available in the CLI debugger. There's.

B

No deep temp also provide a JavaScript API, because I talked to trevor very briefly about this, and he wanted to kind of see like a v8 module. Dot. Take heap snapshot, sort of thing you.

C

Guys, it does have a think, that's what it does. It gives you a jsapi to take a heap dump and- and I personally also would like to see it in core, because it's faith I mean I, don't know if inspect fully addresses the use case here.

C

Many people have an aversion to using anything related in production, whereas heap dump is has nothing to do with debug debug ports. It just gives you a heaped up.

B

H

B

There anyone that else that would have thoughts on us suggesting that this B are not necessarily taken in, but the center of the same functionality, beery added to like the BM module, encore or sorry the v8 module. Oh.

A

There's a v8 model in core. Yes,.

F

A

A

Yes, my feedback is just thinking about chakra is that we should probably factor the v8 module out actually, rather than factor more things in.

B

um Yeah, probably but I mean in a renaming sense, maybe there'll be pretty difficult to do. That. I think there's a good amount of things that use it. um It kind of predates a lot of the multi vm stuff, but I think that functionality is important to keep. So maybe, if there's some suggestion to trying to eventually move that module to a different name that might work, but that's gonna be a long road. Yeah.

C

It's probably a rename, but the functionality is pretty pretty essential.

C

Actually, in a similar vein, there's also the trash dumping code from Richard Chamberlain. That actually would be a good addition to the to the same module.

A

Report no report correct so you're saying it's like I was adjusting with put all the note inspector from that you're saying. Actually, no, we should gather some of these things together, but it shouldn't be as part of inspect a node.

C

Apart I, don't think no report is fits into the inspect use case at all right because it's a low-level, it's not debugging JavaScript, it is giving you a process level, a unique level or what operate system level. Information about you crashed- and this is some idle information about why you crashed and having this is. A third party. Module is not an ideal way of doing things, especially if that is a needed module so having this functionality in kora is going to just make core core dumps better I'd all to the box. Oh so.

A

You're so you're saying completely independently should note report being core all.

H

A

Yeah, let's, let's save that I, think because we have a space for no report. Yeah we'll need to move along exactly running along time here. So sorry, and also I keep getting the google doc Reese lutz on me, okay, so, okay, we brought that up with. We know those other functionality. Let's continue discussion in that issue, I'll Ali and ensure my if you want to just chime in on that issue and say no, we should move this and severally contradict what I said, which I think is towards the app well good.

A

So next up stairs continue and github. um Okay, next is: let's switch over to trace so first I just gather together to to tracking issues we have, um which I think we probably well I'll, give a suggestion and you guys can get feedback. We should probably close those and open specific issues for the things that remain, which I'll paste in a few that I've was thinking about. That was actually talking to Jason about earlier.

A

So I guess putting up a straw man here for things that remain really either around the critical path like right now the trace event system landed, but it's not in a release, so we should think about what's needed to get it into a release. What's needed, we s, we don't necessarily need to think about getting it out of experimental. Quite yet.

A

So here are some things: are there other so 1 I'll, just read them again, adolescent capability, so right now we can write to that log, but there's no way for anything, either native or js2 to know about stuff going their other than looking at the file itself. um Add a JavaScript API, so that modules can actually add tracing information and potentially listen.

A

If we wanted at trace points to core that's been pending for us for a while and then another thing we talked about last time is what kinds of conventions do we want to encourage mouth waters, to use for their category names and for their payloads, and things like that, so I guess my my straw, man, here's that open up for issues for all of these, and actually the jsapi, is already an ODP from Jason talk about that in a minute to track each of these separately. What do you all think of that I.

A

Don't know each of which separately, the four things that I put into the notes and listeners able to listen a JavaScript API. How trace points using against the raw macros in core, like, for example, in the async hooks area and then what conventions for category names for module? Authors, like one of the suggestions, was used: the module name.

B

So I just looked at this new j's racing API is EP over the last couple minutes.

B

Why would like isn't can't you just do basically the same thing by having like an MPN module that listen, Stace and cooks.

B

Like that looks like exactly the same, except a little bit more high level, let me let's hold off on that.

A

Because I want Jason to kind of talk about the jas stuff and I kind of wanted to know before we go into that specific one. What items? What high level things we need to work on for trace event, so jsapi yeah? Let's talk about that in a second! Is there any other besides us for that I listed in the notes. Are there any other things that are pending for trace events, I? Think the for you listed. They sound good to me.

A

Okay, so then I after this meeting at some point, I'm going to close both of those issues, 53 and 30 and start three or four new issues based on these cool, that's good, all right, so jess tracing, let's go back and Jason and Jeremiah talk.

E

Okay, so not entirely sure what you meant by that, but let me get back and explain. The purpose of these tracing api's is not just to track a sink. Things is for any kind of tracing, but primarily performance Diagnostics, to omit time stamps or capture time ranges or performance counters and all those things are certainly not limited to async operations.

E

That address your blood I.

B

G

It just seems like we're: gonna have an awful lot duplication between the two things. These are way different things, so so.

C

One is how do you let JavaScript developers? It goes tracing data, the other one is I, think folks, it's within node core and how do they provide data to the same stream of it? So I think the very.

B

C

B

Like to take mr, how longer read I, don't think we have time to discuss all the enzyme out so that right now so.

A

That seems fair up Jason. Do you want to talk more about that stuff now or any other issues that you wanna um I mean it'd, be easier? People read.

E

The dock rather than me, and you talk through.

H

E

Appreciate feedback on the dock, there are a few optional pieces which we and I particularly want feedback on whether those are things that people think should go in or or not.

C

Yeah so I briefly skimmed through the doc I haven't done an in-depth review. It's looking pretty good to me and thanks for writing such a such a nice detail, doc I think you from my point way. I think we best if everybody had some chance to sort of think about it at a deeper level and review the doc in more detail, and maybe we can come back to it at the next meeting.

F

B

A

Cool alright, so let's 1255 got a couple more minutes. Is there any I know andreas chimed in and gave us a quick update in the thread about acing Hawks? My notice Isaac started a thread about domain couple days ago. Is there anything that we want to discuss here between us or is it just the usual.

B

So docs and test should be up on the pole, require for a sink hooks very shortly: I'm not not as in shortly hasn't today, necessarily but compared to the overall time frame relatively shortly. I'm, not sure if we'll end up opening up a new poll request or not, that might be possible to get extra visibility and review on it. um But progress is very far along on our end for implementation and that's been mostly Trevor and Thorson. Laurens I've been doing that.

A

Okay cool, so let's move to the post, part of stuff, Richard I think joined the call yeah.

H

We got on didn't.

A

Give you too much time years now.

H

It looks like you need to maybe do that next time, I will have a quick word if you like yeah.

A

I I just kind of wanted for people that aren't aware of these. These projects and some of the stuff the post mortem group is doing, and there is a lot of overlap with some stuff we're doing so. um Yeah I wanted to make people aware of it. You know Ali brought up earlier whether no report should go into core and then we might be able to help with that. Oh yeah, yeah yeah.

A

H

Bit early days, for that maybe yeah this other two main projects is our load, which is kind of getting the mebd bug story for core dumps available on, or linux and mac and no default, which is human, readable, dump and yeah. They might. There might be some integration with the debugger, but we do need those to be independent as well you to be able to trigger those kind of things without attaching a debugger. So that is some thinking about. Maybe there's some of the underlying functionality be useful available to the debugger as well.

H

So in the debugger you could you sleep, tempura or no report, but it it is something that the production people want to see as a separate in the easily triggered facility.

H

Yeah, maybe we should know if you combine these two groups but looks like you have plenty to talk about on the tracing and the netherlands specs side which isn't going to much time for this.

A

Yeah exactly so it that's interesting what you brought up cuz, that's something I've been noticing to like. You, have a dump, then we're kind of turning to ll node, and maybe note well noted when work with a dump but like that's, where you guys are focusing kind of those dumps or frozen processes where, as inspector the process has to be alive, sure.

H

Yeah, that's the main difference and it isn't the sort of thing you use in the production area, whereas you could accept the off production people to be able to produce the dumps and these stashed away for later. So that's the big difference really.

A

Okay, well I know they kind of keep an eye on both sides. I think Michael. Dawson does too, though, in writing keep each other updated.

H

Yes, I think yeah just need those are interesting and kind of watch both groups and we're probably know what you are meeting on the other on the other group. At some point.

A

Cool well thanks for joining and introducing yourself. Okay,.

A

So yeah I think that about wraps it up unless there's any other things, people want to discuss or is there anything on the call.

B

And I'm still just thinking through how related tracing and dumps are I, mean I, think they're, both kind of like Diagnostics on what happened or what is happening in a node process. One just has slightly different timing and thus, like all the different semantics, but it still seems kind of related to me on the note of meetings.

B

Would it be possible to transition to using a label to mark issues for the agenda that might be a way to reduce our agenda a bit by only marking the things that we really need to discuss in person.

A

Yes, so we I will talk with the people necessary to create a label for which are their worldwide labels and github.

B

No, unfortunately, the tools that we use for making the ctc meaning just pick them up or wide, um but there are no org wide labels. You'll need to make your own okay yeah. Usually it's slang like wdw, G, dash, meeting or Diagnostics meeting or whatever call it anything. You want yeah.

A

I'll figure that out yeah that would be all bullet. It was that and speaking of which, the next meeting we don't really I, didn't really have an official schedule. Is it okay to just put out a doodle in a few weeks, I.

B

Think that's fun. Yes,.

A

All right one last chance any questions. Anybody see anything on the YouTube side that we should know.

A

Okay, when I guess we're done thank.

H

You, like sperm, yes x, run in a khole yeah.

A

No problem makes organism.