►
From YouTube: Node.js Diagnostics WG Meeting - 2018-02-21
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
I
think
everything
in
there
is
on
the
is
on.
The
agenda
are
closed,
so
just
jump
into
the
agenda.
I
think
the
first
thing
I,
don't
know
how
much
we're
going
to
get
down
with
this.
Is
this
one
three
to
five
four,
which
is
integrated,
C++
Haitian
cook,
some
better
API
with
native
abstraction
I
know
that
Lily's
been
doing
some
pr's
around
that
he's
not
here
today
and.
B
A
A
Okay,
so
the
working
group
meeting
times
is
issue
number
158
has
came
up,
I
was
tempted
to
just
kind
of
move
this
meeting
this
week,
but
I
did
want
to
just
give
people
chance
to
chime
in
here
on
the
call
there's
two
proposals:
one
is
9:00
a.m.
PST,
a
5:00
p.m.
GMT
and
the
other
is
11
a.m.
PST
7:00
p.m.
GMT
that
seemed
to
work
for
I.
Think
most
people
have
chimed
in
on
the
issue.
It
does
have
some
periodic
conflicts
with
TSC
meetings,
at
least
at
9:00
a.m.
well
one
does,
and
the
11:00
a.m.
A
E
A
The
issues
been
open,
so
there
isn't
issue
its
issue,
158
and
you
know
I
think
for
people
people
did
chime
in
there.
You
know
I.
Think
yang
said
that
he
would
prefer
7:00
p.m.
GMT,
I.
Think
at
the
summit
you
know
several
people
said
5
p.m.
GMT,
and
you
know
the
other
comments
on
here
were
basically
silence
and
Michael
Dawson,
saying
both
times
work
for
me,
provided
there
no
conflicts
with
other
working
group
meeting.
So
you
know
we
know
now
that
this
one
isn't
doesn't
work
for
everyone,
and
you
know
the
other
alternative.
A
Is
we
alternate
bi-weekly
that
feels
a
little
more
complicated
schedule?
Wise
and
I
prefer
to
avoid
it,
but
we
can
do
it
on.
You
know,
I.
Think,
Stephen
to
your
point.
We
don't
have
to
make
a
final
decision
now,
but
you
know
weak
institutions.
I'd
like
to
be
able
to
you
know,
say
something:
you
know
decisive,
like
hey
we're
gonna,
you
know,
move
this
to
11:00
p.m.
here's,
the
issue.
A
A
So
that
will
say
something
definitive
and
let
people
try
me
in
I
think
the
issues
been
open,
though
so
for
people
to
you
know
to
tell
us
so
I,
don't
think
it's
it's
we're
doing
it
in
a
vacuum,
but
tell
me
if
I'm
missing
something
or
you
were
thinking
something
else
Stephen.
What
the
issue
right
now
is.
C
B
A
B
So
I
think
just
forced
is,
and
he
has
I'm
not
sure.
If
he's
been
around
the
diagnostic
side
of
thing
much
these
days,
anyways
yeah
I
haven't
we
meet
every
other
week
right
yeah.
So
that
means
it's
only
like
every
six
weeks
that
we
actually
run
into
a
conflict
of
the
TAC
meeting.
Anyways
I
didn't
actually
go
through
one.
B
F
A
A
Okay,
so
so
let
me
do
this
I'm
gonna
say
you
know.
We
move
this
to
11:00
a.m.
PST.
Let
people
do
an
up-or-down
vote
on
that
issue,
and
you
know,
with
the
caveat
that
there's
if
there
is
a
conflict
with
the
moderation
committee,
it's
going
to
happen
quote
infrequently
and
if
somebody's
really
concerned
about
it,
somebody
can
dig
in
do
the
math.
That's
unfair.
A
G
A
So
I
think
the
general
thing
here
is
that
you
know
it
is
expressed
that,
rather
than
just
pulsing
on
the
you
know
the
open
issues
and
and
going
into
detail
on
that
that
we
periodically
wanted
to
do
deep
dives
on
specific
topics
on,
and
you
know
do
that
for
an
hour.
I
think
somebody
mentioned
two
hours
on
I
think
you
know
to
start
on
things
that
we
would
do
say
an
hour
and
see
how
things
go,
and
we
would
try
this
every
other
meeting.
A
Okay,
so
I'll
open
another
issue.
You
know
just
basically
saying
like
we're
going
to
periodically
do
deep,
dives,
let
people
chime
in
on
that
see
if
there's
any
sort
of
concerns
around
it
and
then
there's
a
specific
thing
here
for
a
deep
dive
with
CI
testing.
Who
was
the
one
that
was
that
was
driving
that
bit
I.
G
Think
it
was
me
who
bring
this
up
regarding
the
CPU
profiling,
that
we
should
have
first-class
citizen
tools
that
are
tested
releases,
but
we
didn't
really
agree
in
anything
on
this.
I
mean
because
at
this
moment
we
are
not
sure
that
what
are
the
first
class
citizen
tools
so
I
think
in
the
first
run
we
should
come
up
with
a
list
so.
D
A
G
A
Definition
that
we
can
have
conversations
about
it
so
I
think
that's
a
good
candidate
for
these
things.
I
think
without
what
I
can
do
is
post
an
issue
saying
that
hey
we
want
to
get
a
list
of
candidate
things
to
do
deep,
dives
on
we'll
schedule.
These
things
and
periodically
people
can
join,
will
adjust
timing,
as
you
know,
as
we
learn
more
about
how
things
go
and
people
can
comes
up
or
thumbs
down
that
so
some
fair,
yes,.
G
D
Sure,
basically,
we
talked
with
young
and
trendy
about
about
the
possibilities
to
have
a
code
eventlistener
api,
which
gives
us
the
ability
to
to
map
symbols
from
external
profilers
and
also
about
the
v8
CPU
profiler,
which
today
only
is
able
to
sample
JavaScript
frames,
but
maybe
in
the
future
we
can
work
with
that
to
collect
also
native
frames
regarding
the
external
profilers
and
the
problem
they
have
with
interpreted
frames.
I
have
a
prototype
that
I
worked
on
for
the
past
few
weeks,
which
is
able
to
to
collect
the
interpreter
frames.
D
G
Therefore,
you
know
what
with
discuss
on
the
summit
just
to
to
summarize
it
that
basically,
this
event
listener
library
will
be
an
NPM
package
which
will
be
part
of
the
diagnostic
tools
and
we
will
move
it
under
the
node.js
organization
and
there
will
be
CI
provided
for
that
and
other
than
that
today
there
was
a
conversation
about
that.
Where
should
be,
the
testing
take
a
place
for
this
and
VA
team
recommended
to
do
the
test.
One
node,
like
an
integration,
kind
of
test
that
it's
working
from
our
side.
D
G
A
D
A
D
A
D
A
G
G
G
A
So
Mike
we
discussed
the
timing
of
this
I.
Think
this
the
the
proposal
is
to
move
the
timing
of
the
meeting
to
11:00
a.m.
and
then
there's
a
periodic,
but
infrequent
conflict
with
the
moderation
committee
meeting
and
we're
gonna
put
this
up
on
in
an
issue
that
people
vote
up
or
down.
I,
don't
know
if
you
wanted
to
chime
in
on
that
yeah.
So.
A
Okay,
great
so
it
sounds
like
there's
some
progress
on
the
perf
thing:
okay,
so
moving
on
so
number
134
lemonade
monkey-patching
for
diagnostic
instrumentation
I'm,
not
aware
of
any
progress,
that's
happened
on
there.
The
I
think
the
end
result
of
this
one
after
the
meeting
or
the
summit
was
that
we
would
start
a
new
code
code
base
somewhere
under
the
you
know,
the
node
organization-
and
you
know
we
would
start
building
stuff
out
there
rather
than
using
the
existing
diagnostic
source
module.
A
C
I
A
I
A
Well,
I
mean
I
think
that
there's
a
there's
a
an
idea
of
how
you
know
a
hub
sub-model
can
sort
of
obviate
the
need
for
a
number
of
cases
where
monkey-patching
is
currently
being
used
and
that
if
we
have
the
pub/sub
infrastructure,
we
can
monkey
patch
to
get
the
publication
of
data
in
there
in
the
short-term.
And
then
we
can
open
PRS
on
libraries
to
eliminate
monkey
patching
in
the
long
term.
So
I
think
it's
a
path
on
how
we
get
out
of
my
focaccia
right.
I
A
Is-
and
you
know,
there's
this
sort
of
and
I
get
it
like.
I,
don't
know
like
if
I
didn't,
if
I
hadn't
looked
at
the
code
and
I
maybe
be
saying
the
same
thing,
but
you
know
there's
what
you
know
we
believe
is
a
good
start
for
that
and
I
think
you
know
OB
and
some
others
have
mentioned
wow.
We
should
just
start
fresh
and
you
know
people
want
to
start
fresh.
That's
that's
great
and
I
personally
think
that's
the
best
best
approach,
but.
A
I
Like
I
I'll
propose
we'll
see
if
people
agree
or
not
like
I
think
we
should
actually
start
by
a
deep
dive
into
the
existing
implementation,
not
necessarily
saying
we're,
starting
with
that,
but
at
least
you
know
you
know,
have
you
take
us
through
it
or
whatever,
so
that
it's
we
at
least
can
take
the
the
like
some
inspiration
from
that.
Even
if,
at
the
end
we
say,
let's
start
from
fresh,
fresh
I,
you
know
what
I
mean
yeah.
A
I
C
A
A
You
know,
people
in
agreement
that
you
know
this
API
is
the
right
API
and
this
thing
is
doing
what
it's
supposed
to
be
doing
and
everybody's
happy
with
it,
and
then
you
can
talk
about
well,
we
want
to
use
this
in
the
core.
How
would
we
make
it
available
and
then
it's
a
conversation
about
this
as
pub
subchannel
meaty
part
of
their
core,
then
people
can
take
depths
on
it
and
I
kind
of
feel
like.
C
A
A
I
Know
I
I
definitely
agree
that
making
it
much
more
concrete
in
terms
of
like
here's,
a
PR
that
pretty
much
is
what
it's
going
to
look
like
as
opposed
to
trying
to
get
a
little
bits
and
pieces.
Is
it's
going
to
be
a
better
way
so
to
work
on
it
separately,
get
it
to
a
good
state
and
then
consider
that,
as
is
what
I'd
recommend.
A
And
the
other,
the
other
way
to
think
about
this-
and
this
is
a
you
know-
I'll,
throw
it
out
there
just
so
people
chew
on
it
right,
but
like
I,
think
it
was
brought
up
that
there's
some
times.
People
want
to
go
in
and
they
want
to
do
some
mutations
on
objects
like,
for
example,
adding
headers
wrapping.
You
know
callbacks
things
like
that
right
and
it's
one
class
of
operations
that
are
happening.
I,
think
the
other
class
of
operations
are
happening
or
is
just
you
know,
sending
data
through
right.
A
That
is,
like
you
know,
I,
don't
know
something
took
some
amount
of
time,
and
you
know
in
terms
of
what's
in
nerdcore
like
is
it
possible
and
I
know
that
we
discussed
this
at
the
summit,
but
is
it
possible
to
use
the
the
trace
events
macros
to
sort
of
fire
some
of
that
data
right,
because
that's
already
in
node
core
and
then
can
you
somehow
have
that
stuff?
You
know
surfaced
potentially
through
this
hug
subsystem
right.
A
Fire
some
data
through
or
from
node
core,
without
having
to
get
this
pub/sub
model
in
there
and
lets
you
address
some
of
those
and
there
was
some
pushback
on
you
know
this
thing
actually
using
the
the
trace
event:
stuff
I'm,
not
totally
convinced
I,
think
there's
some
cases
where
the
trace
events
doesn't
make
sense.
I
think
there's
some
cases
where
it
may
I
could
be
wrong,
but
but
that's
the
other
thing
to
just
kind
of
think
about
and
see.
If
it's
it
makes
sense
for
people
or
not
so.
I
A
I
A
So
async
context,
formalization
and
diagnostic
support.
So
not
much
has
happened
here
since
the
summit
I
was
just
talking
with
Mark
about
some
of
this
stuff.
I
think
we've
got
at
least
a
you
know,
a
path
in
in
my
mind
about
how
we
can
build
a
monkey
patch
system
just
kind
of
generate
the
events
for
this
model
that
would
work
on
down
level
revs
of
node
and
I.
A
Think
we
have
a
path
that
lets
us
build
this
graph
and
then
so
I
think
the
question
is:
is:
can
I
find
some
time
to
actually
write
the
code
to
do
that
and
then
get
it
in
people's
hands?
And
let
people
say,
like
you
guys,
are
crazy,
or
this
makes
some
sense
and
so
I
think
that's
kind
of
the
next
thing.
There
I
think
some
of
the
discussions
about
at
the
summit
we're
good
and
sort
of
clarifying
some
confusion
points
that
people
had.
A
I
A
We
had
a
intern
here,
a
few
years
back,
who
went
through
node
and
identified
every
place
that
there
is
a
in
the
node
libraries
that
there
is
an
asynchronous
continuation
point
that
is
FS
dot
read
and
you
pass
and
run
something
right.
So
what
we
can
do
is
we
can
have
so
it's
a
big
data
file
right,
and
so
we
can
use
that
to
basically
monkey
patch
all
these
places,
where
we
want
to
be
able
to
generate
these
events
that
build
this
that'll.
Let
us
build
this
graph,
so.
F
A
A
Say
it's
like
async
hooks
cuz,
they
sing
cloaks
is
operating
it
like
a
the
handle
level
right
like
you've
got
these
low-level
resources
and
native
code,
and
you
know
they're,
you
know
going
through
their
lifecycle
events
and
as
they
go
through
the
lifecycle
events,
it's
it's
firing.
Events
back
into
JavaScript
right.
What
we're
doing
is
we're
just
going
to
monkey
patch
things
to
generate
this
sort
of
event,
stream
that
we
talked
about
in
that
dock
right.
A
You
know
different,
you
know,
I,
don't
know
some
of
the
different
use
cases
for
understanding
these
events
right,
so
you
could
implement
continuation,
local
storage,
you
could
implement.
You
know
the
long
stack
trace,
that's
sort
of
the
goal
right
and
then
also
that
you
know
there's
a
way
than
to
tie
like
ultimately
tie
user
code
back
to
you
know
this
model
so
that
when
somebody
is
actually
looking
at
their
JavaScript
code,
they
have
they
can
have
an
intuitive
sense
about
the
asynchronous
nature
of
it.
A
A
Okay
trace
event:
I
know
that
there's
been
some
stuff,
that's
going
on
with
a
number
of
things
in
here.
Not
all
of
those
issues
are
on
our
agenda.
I
know
that
James
open
some
has
a
small
PR
around
some
of
the
api's
and
JavaScript
land.
I
saw
that
there's
an
you
open
around,
like
hey,
we've
got
DTrace
and
we've
got
healthy
TNG
and
you
know
we
want
etw
and
we've
got
tres
event,
and
what
are
we
gonna?
Do
anybody
have
any
comments
here
on
this.
I
A
D
A
I
D
I
Guess
I'll
just
comment:
I'm
still
working
on
putting
together
sort
of
a
you
know
a
high-level
blog
and
then
you
know
the
the
parts
that
I
have
in
terms
of
the
follow-ons
from
the
summit.
So
still
working
on
that
and
you
know
hope
to
pull
it
together
once
I
finish
that
and
everybody
else
felt
finished
as
the
other
sections
as
well.