►
From YouTube: Diagnostics WG meeting July 28 2021
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
B
B
I've
currently
made
it
a
top
level
module
just
like
promised
under
star
hook,
hooks,
I
think
and
yeah
there's
like
it
seems
to
be
in
the
issue
of
conflicting
opinions
on
if
it
should
be
the
top
level
module
or
if
it
should
be
under
asian
hooks
right
now
or
like
if
it
should
be
just
temporarily
under
async
hooks,
there's
well
also
when
I
did
diagnostics
channel
before
I
approached
that
from
like
the
angle
of
it
being
a
minor
except
for
a
minor
change
with
the
intent
that
they
would
get
backboarded
and
that's
what
I'm
trying
to
do
here.
B
I
want
this
to
be
backwarded.
If
we
can
and
at
that
like
at
that
point
it,
it
was
agreed
that
adding
a
new
top
level
module
was
not
a
number
of
major
change
and,
like
the
docs
suggest
that,
but
in
this
issue,
like
a
bunch
of
people,
seem
to
be
suggesting
that
it
is
or
should
be,
a
somewhere
major
change,
so
not
sure
how
to
deal
with
that.
Exactly.
B
B
There's
also
some
questions
about
like
the
like
the
shape
of
the
api,
so
that
this
is
like
in
some
ways
slightly
similar
to
asynchronous,
but
has
very
different
intent,
so
it
like
I'm.
I
was
not
really
trying
to
reproduce
the
form
of
the
asynchronous
api
like
this,
rather
than
having
to
like,
like
strictly
the
create
hook
interface,
where
you
have
like
passing
an
object
with
a
bunch
of
like
named
functions.
B
This
you
can
actually
just
interact
with
each
separate
hook
independently
that
this
has
a
way
to
do
the
like
all-in-one
just
for
convenience,
but
it's
more
of
the
intent
that
you
just
be
able
to
interact
with
each
hook
individually,
but
like
that
there
was
a
suggestion
that
this
should
have
the
like
same
shape
as
asynchronous
with
like
the
disable
function
and
all
these
sorts
of
things
yeah
just
like
to
get
some
opinions
from
diagnostics,
working
group
folks
on
what
they
think
of
this
and
what
the
direction
should
be.
C
B
Yeah,
so
this
this
is
like
a
much
simpler,
much
simpler
api
than
h
and
cox.
It
doesn't
expose
internals.
All
of
all
it
does
is
just
hand
you
a
promise.
Whenever
a
promise
is
created,
not
really
telling
you
anything
about
what
it
is.
C
B
Like
it's,
it's
functionally
different
and,
like
I
think
at
least
the
user
lands
use
of
it
would
be
somewhat
different,
like
it's
not
really
intended
for
any
sort
of
context,
management,
or
anything
like
that.
It's
just
intended
to
like
observe
when
a
promise
happens.
B
It's
like
you,
can't
really
build
cls
on
just
that.
You
need,
like
all
of
it,
isn't
cooked
so
like
it
can
be
used
to
feed
some
of
the
events
into
basic
hooks
like
it
doesn't
even
do
like
the
destroy
hook.
You
have
to
layer
that
on
top,
which
is
what's
happening
inside
of
asynchronous.
B
Yep
yeah
it
doesn't,
it
doesn't
necessarily
need
to
be
public,
but
it's
just
helpful.
I
think
like
it
does
give
you
you
get
access
to
the
current
promise
and
the
parent
promise
in
the
net
hook,
which
can
be
helpful
for
tying
things.
C
B
It's
it's
a
bit
of
both,
so
I
I
wanted
to
make
a
new
api.
That's
like
could
be
consumed
in
for
like
if
there's
other
places
that
want
to
use
this,
but
it's
more
intended
for,
like
I,
I
know,
there's
a
bunch
of
like
user
land
uses
of
asian
folks
that
only
listen
for
promises
and
so
like
having
all
of
asic
hooks
just
to
listen
for
promises,
seems
a
bit
overkill.
C
B
C
I'm
sure
we
had
a
discussion
around
this
sometime
in
the
past,
but
like
there's
no
other
like
this
generic
diagnostics
or
type
top
level
module
right,
because
I
think
you
know
they
think
hook's
name
is
partially
what
seems
off
if
it's
kind
of
like
hey
this
is
not
asynch
hooks,
then
why
is
you
know
and
even
the
context,
local
storage?
I
know
there
was
a
discussion
about
that
and
I
think
it
ended
up
there
partially
to
avoid
having
to
create
a
new
top
level.
B
Yeah
yeah,
like
personally
my
feeling
is
like
we
should
just
be
making
stuff
like
top
level
new
things
like
this
should
be
top
level
unless,
like
it,
really
really
makes
sense
that
it
is
like
directly
tied
to
this.
Other
thing
like,
in
my
opinion,
like
async
local
start,
should
be
its
own
top
level
thing.
It's
confusing
that
it's
in
asynchronous,
so
anyone
that's
not
like
already
familiar
with
asynchronous
in
the
context
of
like
why
you
should
be
using
this
or
not.
This
other
thing.
C
C
B
Well,
I
I
I
have
been
thinking
that,
like
we
should
like
make
more
use
of
like
nested
paths.
B
It's
like
if
we
put
a
bunch
of
stuff
under
like
diagnostic,
slash,
pharmaceutics
diagnostic,
slash
like
async
local
storage,
right
like
if
we
just
claimed
like
some
top
level
scope
for
like
all
of
the
stuff.
We
do.
C
B
B
Yeah,
I
think
we
we
can
like
contact
them
and
ask
if
we
can
take
the
name
space
if
it's
not
like
actually.
E
C
B
We
also
have
like
that
node
colon
thing
we
can
just
like
put
it
behind
that.
C
So
I
guess
it
sounds
like
you
know,
you're
thinking
it
would
be
nice
to
have
it
as
a
separate
module
like
top
level
module,
but
possibly
one
that
we
we
should
instead
of
creating
a
specific
one,
it
would
be
better
to
create
one.
We
could
then
layer
things
underneath
right,
yeah
and
then
in
the
future
it
would
make
easier.
It
went
and
I'd
agree
that,
like
making
an
alias
for
cls
that
was
underneath.
That
would
be
nice.
B
D
C
C
B
I'm
not
not
sure
how
possible
it
is,
but
that
that,
like
node
prefix,
if
if
we
could
make
it
so
there's
like
all
the
existing
stuff
like
takes
priority
over
user
land
but
like
new
stuff,
is
like
lower
priority
than
user
land.
And
then
you
have
to
like.
You
have
to
use
the
node
prefix
to
get
these
other
things
or
something
like
that.
C
C
No,
I
know,
but
that's
what
I
was
saying
like,
but
if
it's
node
colon
and
it's
you
know
that
basically
means
that
you
know
you
can
still
do
a
require
diag.
If
you
want
to
yeah
shouldn't
diag
is
it's
only
got
four
weekly
downloads
so
that
one
might
be
one
to
get
anyway?
C
B
C
And
this
is
exposing
like
the
v8
level,
functionality
yeah
and
I
guess
that's
something
like
common
commonly
going
to
be
available
in
different
javascript
engines,
always
in
v8.
B
Yeah
yeah
it
it's
exists
in
v8.
I
don't
know
about
other
javascript
engines,
probably
not.
B
Well,
I
I.
I
can't
really
comment
on
the
like
new
promisework
api.
The
this
is
exposing
the
new
javascript
promise
api
that
I
made
the
like
old
one.
They
like
they
are
using
it
in
like
their
debugger
and
some
other
places.
It's
like.
I
don't
think,
that's
going
anywhere
anytime
soon,
the
the
new
api
I
mean
who
knows
but
like
since,
since
we
are
a
user
of
it,
I
I
think
v8
would
not
deprecate
it
like
lightly
right
and
like
I've.
B
I've
been
in
discussion
with
them
a
bit
about
like
seeing
if
any
of
their
uses
of
the
like
existing
c
plus
api
would
be
better
served
with
this.
C
B
Like
if
there's
some
comments
about
like
it
should
maybe
be
shaped
more
like
the
async
hooks
api,
with
like
returning
an
object
with
a
disabled
function
and
those
sorts
of
things
and
like
some
some
comments
that,
like
it,
maybe
shouldn't
expose
each
individual
hook.
B
B
Things
so
so
right,
right
now,
I
have
like
there's
one
function
that
you
can
attach
all
the
hooks.
That's
similar
to
the
create
hook,
function
on
asynchronous
right,
but
then
I
I
also
have
like
on
init
on
before
on
after
unresolved,
so
you
can
just
interact
with
each
hook
directly.
C
B
So
you
can
just
say
like
here:
is
my
function
to
run
when
an
init
happens
and
that's
it
and
you
can
like
it
returns
a
cancel
function
like
stop
listening
and
yeah.
That's
that's
it!
So
it's
like
really
simple.
If
you
only
care
about
one
event,
but
there's
like
some
comments
like
maybe
we
shouldn't
be
exposing
like
each
of
these.
Like
single
events,
we
should
only
have
the
one
entry
point.
C
B
C
B
C
B
A
I
created
this
issue,
so
I
I
was
solving
some
other
issue
and
came
across
the
fact
that
our
diagnostic
repo
has
so
many
branches,
probably
still
branches,
because
we
don't
do
any
release
as
such.
It's
it's
rather
static
repository
with
years
and
issues,
I'm
not
sure
why
we
have
so
many
branches,
not
sure
whether
it's
part
of
some
old
pr
practices
where
you
directly
create
a
branch
in
the
upstream
and
then
merge
it
with
the
master.
C
A
A
E
Whenever
a
pr
is
made
actually
even
if
appear,
is
made,
the
the
op
upstream
don't
receive
the
branch
actually
only
only
if
it's
created
by
one
of
the
contributors
in
the
same
stream.
So
I
would
say
for
for
this
case
we
can
just
add
just
hello
to
to
delete
branches
whenever
it's
closed
by
by
the
bottom
of
the
github.
This
is
pretty
simple.
C
E
Here
the
option
is.
B
Yeah,
I
I
just
deleted
one
of
mine,
which
I'm
pretty
sure
I
just
used
the
like
github,
like
edit
in
place
thing.
That's
right,
yeah,.
C
C
And
there
I
see
you
said
landed,
so
I
think,
like
of
those
there
there's
only
like
two
that
don't
say
closed
or
merged
one
which
has
my
name
on
it,
and
I
have
no
idea
what's
there,
so
I'm
just
gonna
delete
it
and
then
there's
one.
That's
that
mary
opened
11
months
ago.
You
know,
maybe
we
we
leave,
that
one
delete
all
the
others
and
then
just
ask
mary
to
delete
that
one.
If
it's
not.
B
Against
a
stephen
yeah,
so
I've
put
together
the
blog
post
for
that
and
it's
been
published
hasn't
been
a
ton
of
response
to
that.
So
far,
I
think
there's
like
one
comment
added
to
the
issue
just
asking
about
like
the
domains
use
case.
C
Doing
another
tweet
but
yeah
so
you're
saying
you
posted
in
the
in
the
chat
tweet
that
did
go.
D
D
D
C
C
C
D
D
C
C
I
don't
think
it's
just
going
to
tweet
automatically
like
I
you
know,
I
think
basically,
somebody
from
like
either
joe
or
tierney
who's
on
the
the
social
team
needs
to
actually
land
it,
and
I
think
it's
actually
there's
automation
that,
like
once
it
lands
that
will
actually
generate
the
tweet,
so
approving
should
be
no
problem.
There
certainly
haven't
been
a
lot
of
tweets,
though.
C
C
I
see
you
yeah
you,
you
added
your
approval,
it
just
isn't
green,
but
I
think
that's
just
as
good.
In
terms
of
of
you
know,
people
they
can
see,
see
who's
done,
that
oh
yeah
people
involved
in
the
diagnostics
working
group.
So
it
looks
good
yeah,
okay,
so
I'd
say
you
know.
Do
that
see
if
you
get
any
more
responses
and
like
maybe
do
one
more
or
something
like
if
we
don't
get
enough
and
I'm
not
sure
what
other
things.
C
B
Yeah
my
plan
has
kind
of
been
to
just
like
go
through
the
use
case
list
and
just
make
sure
like
we've
built
something
to
serve
each
of
the
use
cases
and
then
like,
as
we
approach
the
end
of
that
list,
mark
basic
hooks
itself
as
deprecated
or
we
have
that
new
like
legacy
one
as
well.
That
might
actually
be
more
suitable
for
this.
C
B
A
B
C
Yeah,
maybe
I'm
just
seeing
the
comments
like,
maybe
once
we
have
a
list
it's
you
know.
We
just
make
sure
the
tse
is
like
hey
here's
the
list.
You
know
and
that's
what
we're
gonna
work
work
on.
If,
if
there's
a
reason,
if
this
list
was
fulfilled
and
you'd
still
say
hey,
we
shouldn't
deprecate
async
hooks.
C
A
E
Let's
not
keep
going
because
because
of
time,
and
also
because,
as
we
we
just
had
some
some
meetings
ago,
looks
like
the
prefix
is
not
working
properly,
but
I
didn't
leave
this
time
to
go
deeper
and
only
yet
also
I
haven't
yet.
I
haven't
noticed
yet
that
the
google
have
removed
from
the
google
chrome
the
options
to
add
the
black
box
as
an
option.
E
So
I'm
not
sure
if
this
is
a.
This
is
still
a
good
feature
or
a
good
update
to
do,
and
I
would
like
to
see
with
you
guys
if
we
should
keep
going
with
it,
because
at
first
moment
I
don't
see
any
good
benefits
from.
D
E
Actually,
I
I
think
mainly
when
you
are
like
you
are
using
debugging
your
code
and
for
some
reason
you
do
I
stepped
into
node.js.
I
don't
know
fire
read
string
and
you
don't
want
to
see
the
internal
code.
You
just
want
to
to
to
skip
that
and
go
to
your
function.
E
E
If
they
are
debugging
by
cli,
I
would
say
that
they
need
to
to
communicate
directly
with
the
websock
and
send
the
event
debugger
dot
disable
by
black
box,
and
this
is
not,
I
don't
know
clear
enough
for
them.
So
this
is
one
of
one
one,
more
reason
that
I'm
not
sure
about
this
feature
and
if
they
are
debugging
through
the
I
don't
know,
google
chrome,
they
only
have
options
to
to
remove
that
that
script,
so
it
will
be
a
bit
more
easy.
C
I
guess
I
don't
feel
strongly
strongly
one
way
or
the
other.
Does
anybody
have
any.
A
Is
it?
Is
it
fair
to
say
that
those
who
are
debugging
through
the
cli
have
a
better
grip
on
the
code
base
or
what
they
are
doing,
and
they
will
actually
be
more
interested
to
see
everything,
whereas
for
those
who
are
debugging
through
the
gui
may
be,
limiting
to
the
application
by
default
makes
makes
more
sense.
I'm
looking
for
my
very
high
level
point
of
view
how
the
user
experience
can
be
improved
kind
of
thing.
B
And
it
could
could
just
like
leave
it
the
way
it
is
and
then
have
like
a
flag.
That's
like
saying
like
no
really,
I
want
to
know
what
internals
are
doing.
E
E
E
And
you
have
a
ignore
list
that
you
can
add
those
prefix,
for
instance,.
B
Yeah,
from
my
perspective,
like
if
anything
like,
if
there's
like
a
failure,
that's
coming
from
node
core,
like
a
lot
of
the
people
using
node
inspect,
are
not
going
to
be
equipped
to
do
anything
about
it
like
if
it's
like
a
problem
with
node
core.
If
it's
something
that
is
like
like
in
this
case,
like
it's,
a
validation
thing
like
it's
complaining,
if
they
don't
give
it
a
call
back
or
something
like
that
and
like
in
that
case,
then,
like
you'd,
maybe
walk
the
context
of
what's
going
on.
E
You
mean
for
folks
who
work
directly
to
the
node.js
core.
This
feature
could
be,
I
don't
know
could
be
annoying
for
them,
or
I
misinterpret
that.
B
That's
right
and
in
your
example
in
the
issue,
it's
doing
like
a
validate
callback
check
and
like
having
the
context
of
like
knowing
it's
doing.
That
is
helpful
like
it.
It's
like
in
this
example,
maybe
a
little
bit
obvious.
But
if
you
have
like
several
layers
deep
somewhere,
does
some
sort
of
validation
and
blows
up
then
like.
If
it's
like
several
layers,
deep
of
internals,
it
might
just
be
exploding,
and
you
don't
really
know
why
yeah
so
having
having
that
visibility,
helps
there.
E
Yeah
for
sure,
but
actually
in
the
in
the
issue,
we
are
talking
about
two
different
issues.
The
first
one
is
is
if
we
showed
or
not
enable
black
box
by
default
and
the
second
one.
The
issue
shows
that
even
adding
the
node
prefix
at
the
ignore
list-
it's
not
completely
ignoring,
like,
I
have
add,
add
the
node
prefix
to
the
black
box,
skip
script
patterns
and
even
though
the
node
internal
validators
was
colored,
and
I
don't
think
that
this
is
expected.
E
Don't
matter
actually,
if
we
will
add
it
by
the
foreign
by
the
poor
or
not.
My
concern
is
if
the
pattern
matching
is
working
properly,.
E
B
C
C
C
E
Okay,
but
even
for
instance,
even
with
this
tutorial,
passing
the
the
the
black
box
script
like,
for
instance
in
the
inspector
I
passed
that
I
don't
want
to
see
the
internal
scripts.
But
if
the
node.js
validator
is
still.
E
I
don't
know
not
is
unexpected
behavior,
I'm
not
sure
if
I
think
that's
a
different
issue
right
if
the
if
we
check
if
this
still
happens,
I
think
that
should
be
a
new
issue,
a
new
task
for
her
right.
E
A
I
wrote
an
action
plan
as
for
raphael
to
document
how
to
flip
the
configuration
in
both
the
gui
and
the
cli
mode
is
that
the
right
representation
of
the
action
yeah
miss
some
conversation.