►
From YouTube: Diagnostics WG meeting 2021 March 10
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
C
Stephen,
so
I've
made
some
updates
to
that.
The
v8
folks
got
back
with
the
review
the
other
day
and
they
changed
their
mind
on
deferring
some
things
to
a
follow-up
pr
or
follow-up
change.
So
I
I
have
a
couple
more
changes.
I
need
to
make-
hopefully
we'll
be
done
this
week
once
the
v8
changes
are
done,
then
updating
the
nodes
change
should
be
pretty.
C
C
Yeah,
I
I
still
have
a
task
to
write
a
blog
post
for
that
I
was
gonna,
write
a
blog
post,
so
we
can
get
some
more
community
input
on
that.
Just
haven't
had
the
time
for
that.
Yet.
B
I
guess
related
to
that.
I
see
there's
some
activity
around
making
async
local
storage
non-experimental.
I
don't
know
if
there's
anything
worth
mentioning
on
that.
One.
C
B
Yeah
that
I
didn't
yeah,
I
was
wondering
the
same
thing.
I
and
I
know
that
the
proposal
that
was
discussed
earlier.
Actually
the
scope
was
just
talking
about
async
local
stores,
so
that
might
be
related,
but.
D
C
B
B
F
In
drop
state
yeah,
we
discussed
it
in
the
last
meeting.
We
don't
know
if
the
behavior,
as
you
said,
is
really
expected.
So
we
decided
to
to
comment
in
the
in
the
pr
to.
I
don't
know
to
get
some
help
from
folks
who
have
done
some
work
in
the
inspector,
but
still
don't
have
any
answers.
So
we
are
throws
in
this.
In
this
part,.
A
F
F
This
issue
that
have
a
lot
of
distribution
and
we
have
we
decided
to
to
go
to
the
black
box
by
default,
but
this
pr
shows
that
perhaps
we
have
some
bug
in
the
pattern
matching,
because
when,
when
a
debugger
breakpoint
goes
to
the
internal
modules,
internal
folder
specifically
does
not
skip
the
pattern.
F
Match
does
not
match,
and
I
respect
it
to
every
every
file
inside
node
prefix
you're
not
be
called
when
we
we
call
the
inspector,
but
it's
not
seems
constant,
and
we
don't
know
if
this
respect
is
expected
or
is
really
a
bug
that
needs
to
be
fixed.
F
When
we
add
the
black
box,
for
instance,
if
you
go
to
step
into
some
some
internal
module
this,
this
will
skip
to
your
only
your
core
module
right,
I
mean
you
will
not.
You
will
not
see
the
internal
modules
during
your
inspector
right,
okay,.
B
F
Yeah,
there
is
no
a
bug
or
problem;
there
is
no
bug
to
solve,
but
this
this
idea
is
really
to
to
to
add
this.
F
C
F
F
B
Okay,
so
so
it's
hiding
some
code,
but
not
all
of
the
internal
code.
Yeah.
B
A
Just
wondering
yeah
definitely
it
looks
like
a
bug
to
me
because
it
doesn't
meet
the
stated
purpose
and
the
internal
folders
belong
to
the
core.
So
that's
that's
not
hidden
properly.
A
I'm
just
wondering
if
the
if
there
is
a
static
list
that
was
supplied
to
the
v8
saying
that
these
are
the
these
are
the
modules
which
reside
in
node
core
and
for
whatever
reason
the
internal
folder
was
not
in
the
list.
G
Yeah,
so
we
are
using
a
new
feature,
which
is
the
node
prefix
on
require
to
determine
if
it's
a
node
mod,
a
node
car
module
or
not.
I'm
wondering
if
this
prefix
is
missing
on
internal
modules.
Maybe.
A
B
F
Okay,
so
I
would
say
to
to
remove
this
spi
of
the
jag
agenda
and
when
the
the
issue
or
the
pr4
fix
this
pattern
mentioned
the
two
rejects.
I
don't
know
we
add
and
move
forward.
H
Yeah
hi,
okay,
oh
yep,
I've
been
asked
to
help
uninstall
the
diagnostic
user
journey's
work,
so
I've
been
looking
looking
at
the
current
state
of
things
and
hopefully,
over
the
next
couple
of
weeks,
we'll
try
and
try
and
help
that
move
along
a
bit.
I
have
identified
roughly
sort
of
ten
bits
of
work
that
could
be
done
as
sort
of
discrete
bits
of
work
and
I'm
wondering
if
that
would
be
better
tracked
as
a
sort
of
single
issue
or
split.
H
You
know
it
raise
this
sort
of
ten
separate
issues
so
that
they
could
be
picked
up
individually.
What
do
you
guys
think
or
people
think
basically
sort
of
spelling
out
sort
of
further
bits
of
work
that
could
be
done
and
then
sort
of
trying
to
tackle
them?
One
by
one.
A
H
B
So
I
guess
that
that
that's
really
all
I
was
hoping
hoping
for
richard
to
cover.
Let
let
you
know-
and
I
guess
through
the
issues
you
know
if
people
are
interested
in
helping
drive
some
of
those
forward,
you
can
jump
in
and
volunteer
as
well,
because
I
know
I
think
I
think,
there's
at
least
been
a
few
people.
Who've
shown
interest
in
working
on
those
and
if
we
have
some
smaller
bits
defined,
might
make
it
a
little
easier.
So.
H
Yes,
but
just
an
example,
I
think
there
are
certain
things
that
could
be
done:
sort
of
in
isolation
of
the
entire
picture.
If
you
will
so,
there
are
one
or
two
bits
documents
that
are
covering
the
repository
about
using
a
specific
tool
and
that
could
that
could
be
worked
on
and
then
further
work
be
done
to
integrate.
You
know
how
to
use
that
tool
into
the
actual
user
story.
H
It
doesn't
all
have
to
be
done
in
one
go
in
terms
of
work
division,
so
you
know
if
someone
does
know
how
to
use
a
particular
tool
that
we
haven't
written
up.
Yet
that
could
be
a
starting
point
to
just
write
up
how
to
how
you
would
use
a
particular
tool.
You
know
what
you
would
run,
what
baddies
you
need
to
look
out
for,
and
then
that
can
be
tied
later
on
into
a
sort
of
larger
user
story
as
to
sort
of
making
it
connecting
all
together,
maybe
using
multiple
tools.
H
But
you
know
at
the
very
start,
there
were
some
basic
building
blocks
that
I
think
could
be
written
up.
I
mean
there
are
some
documents
that
we
have,
which
are
just
basically
placeholders
at
the
moment
and
and
those
would
be
probably
a
good
first
place
to
start
for
anyone
looking
to
make
their
first
contributions
to
the.
B
D
C
I
don't
know
how
much
there's
there
really
is
to
say
immediately,
but
I've
joined
datadog
recently
and
my
focus
is
on
the
profiler.
C
If
anyone
has
any
experience,
they
want
to
share
with
us,
be
good
to
chat
sometime.
C
So
the
the
datadog
product
that's
attached
to
is
a
continuous
profiler,
so
our
hope
is.
We
can
make
some
adjustments
to
the
existing
v8
profiler
to
make
it
at
least
reasonable
for
continuous
profiling.
C
E
E
The
main
problem
we
faced
was
that
starting,
the
profiler
is
a
blocking
operation
because
they
have
to
copy
over
a
lot
of
information
so
which
function
is
located
via
memory
to
a
separate
thread.
And
if
you
have
a
lot
of
functions
then
this
can
take
a
while.
So
there's
an
issue
where
I
described
it
in
more
detail
and
also
provided
a
yeah,
a
reproducer
which
is
not
the
realistic
application.
E
That
just
shows
the
problem,
and
this
was
one
problem
we
had
and
the
other
problem
we
had
is
that
if
you
use
native
extensions,
then
sometimes.
E
They
show
up
with
strange
so
if,
if
a
profile
sample
is
taken,
you
are
native,
then
the
resulting
data
was
somehow
strange.
I
would
say
so.
I
never
got
the
100
percent
report
user
unless
we
are
not
using
it
anymore.
So
I
stopped
working
on
this.
It
was
also
different
between
note
versions
and
windows
and
linux,
but
it
seems
like
whenever
you
are
not
in
javascript
code,
then
the
result
was
not
that
reliable
so
that
you
have
leaves
on
the
tree,
which
are
simply,
I
would
say,
incorrect
or
partially
correct,
correct.
Maybe.
G
I
suggest
opening
a
new
issues.
Even
so
we
can
discuss
some
of
those
things.
The
the
equivalent
cpu
profile
roadmap
is
a
bit
long
to
continue
using.
C
I've
been
tracking
down
a
couple
like
old
issues
about
the
profiler
just
trying
to
piece
together
what
the
current
state
is
and
figure
out
what
what
my
priorities
are
going
to
be
in
the
future.
The
immediate
term
is
mostly
just
get
the
thing
working
and
then
once
it's
actually
working,
then
you
can
figure
out
performance
improvements
and
things
like
that
in
the
future.
E
A
A
Right,
if
nothing
else,
I
think
that's
it
for
today
and
talk
to
you
in
two
weeks
time.