►
From YouTube: 2021-01-06 Node.js Diagnostics WG Meeting
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
Yeah
yeah
I've
been
working
on
that
for
a
bit,
so
I'm
introducing
a
new
alternative
to
the
the
existing
promisebook
api,
which
exists
on
v8,
isolates,
which
this
now
puts
it
on
the
context.
Instead,
which
is
more
correct
place
for
it
and
instead
of
triggering
a
c
plus
function,
it
triggers
javascript
functions
so.
B
The
the
microtask
queue-
it's
basically
all
runs
within
javascript
bytecode,
so
triggering
javascript
functions
is
a
lot
cheaper
than
hopping
back
to
native
all
the
time.
So
this
change
has
had
a
fairly
significant
performance
improvement.
Now
the
the
changes
that
I'm
making
are
basically
all
done
on
the
v8
side.
At
this
point,
there's
just
some
like
minor
nets
like
just
naming
of
a
thing
or
there's
like
an
extra
variable.
B
They
want
me
to
get
rid
of,
and
just
just
small
bits
of
things
that
once
I
get
back
to
this,
I'm
gonna
clean
that
up
and
then
it
as
far
as
I
know,
I
should
be
ready
to
land
the
v8
changes
so
that
this,
I
think,
is
ready
for
people
to
review
the
note
changes.
Nothing
should
really
change
there.
B
There's
there's
some
like
follow-up
stuff
that
I
want
to
do
that.
There
is
still
I'm
not
I'm
not
really
doing
anything
to
make
the
optimizer
play
nice
with
this,
which,
like
it
would
it
was
exact
exactly
the
same
with
the
isolate
based
promise
hook.
Api
as
well
had
a
bunch
of
optimizer
bailouts,
but
those
now
that
this
is
all
javascript
byte
code.
It
should
be
possible
to
avoid
some
of
those
bailouts.
B
B
That
has
a
special
case
in
the
optical
optimizer
that
if
there's
no
ac
hooks
turned
on
or
no
promise
turned
on,
then
it
will
optimize
it
a
certain
way.
The
current
state
won't.
Let
it
do
that
so
it'll.
It
won't
optimize
the
whole
function.
It
will
optimize
from
the
first
to
wait.
It's
not
like
first
little
bit
is
excluded
and
the
other
case
is
the
like.
Promise.Resolve
and
promise.reject
functions
have
a
fast
path
to
skip
the
executor
function
and
that
won't
optimize.
B
Just
in
the
v8
code
base
nothing,
okay,
okay,
got
it
that'll
just
be
some
follow-up.
V8
backport
commit
at
some
point.
Okay,.
C
B
Yeah
yeah,
though,
it's
not
really
possible
for
the
c
plus
plus
based
bronze
hook
to
optimize
correctly
in
those
cases.
So
it
does
that
bailout
and
my
current
changes
here
are
basically
making
use
of
the
existing
bailout
system
from
existing
prospects.
So
I
just
need
to
untangle
that
a
bit.
C
A
Into
files
that
are
from
node.js,
not
from
v8
on
the
asynchronous
file
and
asyncrap.cc.
B
B
C
B
Yeah
yeah
yeah
there's
this
current
v8
change,
which
doesn't
have
any
optimizer
work
which
the
intent
is
to
land
this
like
the
v8
stuff.
Basically
as
it
is
right
now
than
the
like
mining
units
I'm
dealing
with,
and
then
the
small
node
changes
that
I
made
to
make
use
of
this
and
then
I'll
continue
working
after
that
on
the
optimizer
stuff
to
try
and
improve
that
a
bit
more
and
then
you
can
land
the
rest
of
that
at
some
point.
B
But
there's
not
really
a
need
to
block
what
I
have
now
for
the
optimizer
stuff,
like
what
I
have
now
works
and
is
a
lot
faster
than
what's
out
there
right
now.
C
B
Yeah,
it
should
be
fairly
straightforward
to
back
parts
there.
There
is
a
few
spots
where
it's
not
it's
not
going
to
backboard
100
cleanly,
but
it's
not
too
hard
to
backpack.
D
B
Yeah
yeah,
I
was
I've,
been
kind
of
working
on
this
for
a
while
so
sort
of
been
testing
like
how
far
I
could
backboard
it.
I
think
12
was
still
a
valid
target
when
I
was
talking.
B
B
A
A
A
So
there's
some
confusion
between
what
the
non-inspect
actually
is
and
the
second
one
is
code
drift
where
there
are
points
where
car
and
not
inspect
are
changed
without
sinking,
and
then
they
become
incompatible
at
some
point,
which
leads
to
maintenance
burden
on
both
sides.
A
So
there
is
a
lot
of
problems
here
and
the
suggestion
is
to
move
the
code
to
node.js
instead
of
having
on
a
separate
repository
with
also
the
the
hope
that
it
will
improve
collaboration
for
this
part
of
the
code.
C
A
B
Yeah,
I'm
overall
in
favor
as
well.
My
my
only
concern
is
just
the
code.
Drift
commented
as
long
as
there's
like
enough
people,
aware
of
the
code
like
how
to
work
on
it
and
like
able
to
update
it
as
needed.
Then
it
should
be
fine.
C
A
I
mean
it's
still
part
of
car,
it's
one
of
those
dependencies
that
we
pull
as
part
of.
A
A
A
B
Yeah,
I
haven't
had
much
time
to
put
more
thought
into
that
stuff,
but
yeah,
but
basically
just
been
trying
to
identify
what
exactly
is
the
path
forward
with
asian
cooks,
because
it's
been
ambiguous,
if
like,
if
acing
hooks
against
current
form
should
ever
be
considered
stable
just
because
it
exposes
a
bunch
of
internals
like
what
can
we
do
to
get
to
something
that
is
stable?
B
Should
we
be
layering
stuff
on
top
of
async
hooks
and
just
never
make
casing
hooks
itself
stable
or
like
we
try
and
eliminate
some
of
the
bits
of
ace
and
cooks
that
are
potentially
unsafe
or
like
what
we
do
exactly
and
to
identify
like
what
we
should
do
there,
I'm
trying
to
gather
like
what?
What
exactly
are
the
use
cases
of
asin
cooks?
B
What
like
what
are
people
trying
to
do
with
it
and
like
just
think
about
like?
Are
there
better
ways
to
achieve
those
different
things
are?
Are
there
more,
like
appropriately
abstracted
interfaces
to
achieve
that
in
a
cleaner,
safer
way.
B
Yeah
yeah,
I
I
was
thinking
that
it
might
be
good
to
like
tweet
this
out
or
something
like
foundation.
Accounts
ask
like
what
people
are
using
asian
cooks
for.
A
More
free
farm
survey
not
like
the
promises,
one
that
was
a
lot
of
multiple
choice,
question
and
instead
have
like
one,
maybe
two,
multiple
choice:
questions
with
a
text
field
where
people
can
enter
what
they
are
doing
with
facing
looks.
A
B
B
What
what
are
they
hooking
into?
What
insights
are
they
actually
trying
to
gather
and
is
acing
hooks,
actually
the
the
appropriate
level
to
share
that
data,
or
should
it
be
broken
up
into
like
a
couple
higher
level
apis
or
something.
C
Yeah,
I
I
think
you
know
what
mary
described
as
kind
of
makes
sense
to
me.
Like
a
few.
Very
you
know
the
the
yes
no
like
do
you
use
async
hooks?
Yes,
no
and
then,
if
so,
maybe
which
methods
you
use
and
then
a
free
form
which
is
like
describe
the
use
cases
I
don't
know.
Is
it
describe
the
use
cases
describe
the
data
like
a
couple
ones
like
that,
where
it's
like
free
form,
where
we
hope
that
they
they
can
give
us.
You
know
what
steven
just
outlined.
B
Yeah,
I
think
we
might
wanna
put
a
little
more
thought
into
exactly
like
how
we
instruct
them
like
what
information
we
want
right
because,
like
it's,
it's
not
really
like
what
like
what
specific
hooks
from
amazing
hooks.
Are
you
using
that's
not
necessarily
directly
relevant,
it's
more
like
what
are
you
trying
to
do
with
that.
C
B
Yeah
we've
already
gathered
a
couple
use
cases
in
there
that
seem
to
have
like
some
amount
of
particular
needs
emerging.
B
I
I
don't
know
if
we'd
want
to
like
in
a
survey
suggest
like
here
are
some
of
the
things
we're
looking
at
so
far,
I'm
just
trying
to
identify
it.
Is
there
anything
you
want
that
doesn't
fit
into
these
scenarios?.
C
E
C
C
A
C
The
existing
one's,
not
so
long
like
if
it
it's
like
a
couple
pages,
so
I
I
don't
know
unless
unless
steven
thinks
that
a
fresh
one
would
be
useful,
I
I
think
that
one
might
work.
B
I
don't
have
a
strong
opinion
either
way,
there's
not
not
a
huge
amount
of
stuff
to
read
in
existing
issues
and.
B
And
I
I
think
this
is
a
niche
enough
issue,
that's
and
anyone
that
would
be
like
they
would
have
anything
to
say
about.
It
would
probably
have
like
a
deep
enough
understanding
to
actually
read
through
all
of
this
and
make
sense
of
it.
C
A
B
C
A
Is
it
the
inspector
black
boxing
issue.
C
F
F
So
I
spent
some
time
to
to
do
this,
but
I
I
was
wondering
that
it
should
be
done
either
on
node.js
and
in
the
dev2
as
well.
C
C
Is
it?
Is
it
good
to
have
that
bundled
into
the
the
clients,
or
is
it
something
that's
best
like?
Is
it
you
know?
That's?
A
A
B
F
C
I
guess
it.
The
other
question
I
have
is
like
all
these
black
boxes
like
say:
there's
some
new
tool,
that's
going
to
connect
to
the
inspector
and
use
the
apis.
Is
it
also
going
to
want
these
same
black
boxes
on
by
default
like
it
just
it's,
you
know.
If,
if
we
think
that
everybody
is
going
to
want
them
on
as
the
default,
then
forcing
everybody
to
know
that
and
to
have
code
to
do,
it
seems
less
useful
than
just
doing
it.
C
You
know
when
you
connect,
but
if
it's
like
only
a
subset
of
them
would
would
want
it,
then
maybe
it's
a
different
answer
right.
A
F
C
Devtools,
I
think,
in
that
case,
like
what
raphael
suggested
is
like
if
we
did
it
first
in
node,
inspect.
C
A
C
I
was
saying
yeah
like
that's
a
good
first
step
and
then
once
there
we
can
like
even
ask
hashid.
Who
might
you
know?
Is
there
somebody
within
the
chrome,
dev
tools
that
might
actually
do
it
there,
because
I
think
at
least
at
one
point
he
was
part
of
that
dev
tools,
team
and
that
might
be
part
of
why
he
was
opening
this
in
the
first
place.
C
B
E
C
C
C
C
C
A
Okay,
is
there
anything
else
we
want
to
talk
about
today.