►
From YouTube: 2020-10-23-Node.js N-API Team 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
I
have
one
the
web
ideal
and
api
project
is
now
available
on
the
node.js
organization.
We
don't
have
any
releases
yet,
but
we
are
making
progress
in
implementing
the
web
idle
standard
and
just
generating
code
for
all
kinds
of
things
and
api
code.
A
B
B
A
Yep,
okay.
So
let's
move
on
to
what
we've
got
tagged
here,
I
will
share
the
screen,
which
is
this
one?
The
first
one
issue
is
this
issue
crash
reported
on
node.js,
so
34
839.
A
I
was
hoping
I
don't
know
gabriel
if
we've
had
a
chance
to
look
at
that
at
all,
but
it's
related
to
a
recent
change.
I
think
you're
trying
to
fix
what
looked
like
a
memory
leak
in
one
of
our
tests.
A
C
A
B
A
A
That
was
this
here
we
had,
we
had
something
that
looked
like
a
you
know,
a
test
that
looked
like
it
leaked
memory
yeah.
So
I
think
we'd
we'd
need
to
revert
that.
B
A
A
Yeah,
like
I,
you
know,
we'll,
need
to
understand
whether
it
was
the
test
that
was
like.
Is
it
doing
something
that
just
shows
up
as
a
leak
because,
like
the
finalizer
hasn't
run
yet
or
it's
really
leaking,
but
I
think
it's
better
not
to
crash
so
because
we
were
like
that,
I
think
yeah
yeah,
so,
okay,
so
I'll
go
ahead
and
open
a
pr
to
revert
that
and
then
we
can.
You
know
we.
We
should
open
a
new
issue
which
says
investigate
that
test
again.
B
A
A
Okay,
okay,
good!
So
let's
the
next
one
is
napi.
Seven.
I
think
we
left
this
as
a
tracking
one
as
things
move
through
the
process.
So
anything
you
want
to
bring
up
on
that.
A
B
A
E
A
Review
external
examples:
I
haven't
had
time
to
do
that
tracking
issue
for
modules
that.
A
Reported
so
it
doesn't
look
like
there's
anything
new
since
last
time
I
did
look
and.
A
A
A
The
blog
post,
maybe
we
can
leave
that
one
to
the
end
and
just
use
any
time
that
we
have
to
work
on
that
haven't
looked.
I
haven't
had
any
time
to
look
at
the
debug
enabling
debug
in
terms
of
the
list
of
issues.
C
Yes,
so
this
was
discussing
it's
in
addition
to
lucas's
pr
that
he
created
for
the
sealing
formats
right,
I
added
one
for
so.
This
is
his
for
c
lang
format,
the
one
that
I
made
was
for
the
pre-commit,
which
is
right
basically,
as
we
discussed
if
you're
a
local
developer,
and
you
make
a
commit
to
your
local,
your
your
local
repository.
C
C
Here's
an
example
of
the
failure
that
targets
show:
okay,
yeah
and
that's
the
example
of
the
failure
and
even
in
the
comments
it
says
that
it
failed,
but
you
can
forcefully
make
the
commit
with
that
switch
there,
the
minus
n.
So
it's
still
it's
optional.
Basically,
okay,.
C
C
Added
was
the
pre-commit
module
and
the
fact
to
run
run
the
linter.
F
E
F
Yeah
is,
is
the
tricep
x
ready
or
not.
F
So
I
I
saw
some
comments
recently,
but
is
it
possible
to
merge.
G
Sorry,
which
one
in
in
last
time
we
have
discussed
the
edit
the
incremental
check
of
the
syllab
format.
We
have
to
spread
separate
the
linking
checks
from
the
build
steps
so
that
we
can
see
the
states
of
this
build
from
separated
from
the
linkedin
resource
so
that
we
can
know
all
this
this.
This
api
is
built,
it
can
be
built
and
built
faster
and
it
failed
for
the
linking.
H
A
Okay,
yeah,
it
would
make
sense
just
that
way.
We
will
avoid
landing
it
by
accident.
B
A
D
A
C
Yep,
yes,
I
saw
gabe's
most
recent
comments.
I
have
to
rebase.
I
should
be
able
to
do
that
by
the
after.
This
call
ends.
B
F
A
A
Which
is
good
yeah
and
I
guess
we
have
a
couple
other
questions.
G
Yeah
this
one
I
have-
I
haven't
had
many
times
to
check
it
in
deep,
but
the
the
author
have
edited
the
pr
the
issue
to
say
that
he
they
cannot
find
a
way
to
reproduce
produce
this
in.
By
modifying
your
example,
so
that.
G
B
Yeah,
but
I
mean
okay,
if
if
if
they
want
to
do
this,
you
know
that's
that's
fine.
I
mean
that
they
could.
You
know
they
could
just
add
like
like,
like
a
mutex
and
and
just
just
lock
the
mutex
before
making
the
blocking
call
and
then
and
then,
when
the
callback
happens,
call
javascript
and
then
unlock
the
mutex,
and
then
they
could
get
this.
But
I
mean
that's
not
the
point.
D
B
Unlock
it,
I,
I
can't
think
of
it
off
the
top
of
my
head,
because
I
mean
you
know
we
made
it
to
be
asynchronous
on
purpose
right.
B
Well,
you
know
it's
conceivable
that
they
do
so
much
work
on
the
secondary
thread
that
that
it's
still
advantageous
so
right,
I
don't
think
I
don't
think
blocking
for
the
for,
for
the
callback
is
the
same
as
if
the
whole
work
ran
on
the
main
thread
right,
so
they
just
they
just
want
that
one
step
to
be
synchronized.
So,
okay,
that's
that's
fine
and
you
know
they
have
to
do
their
own
synchronization.
For
that
right.
A
E
B
D
A
A
G
Yeah
we
have
a
discussion
on
this
one,
but
we
have
no
conclusion
on
the
discussion
yet,
but
so
right
here
so
now
the
status
is
that
we
have
a.
We
have
to
decide
if
the
pr
is
is
addressing
a
box
that
we
have
previously,
the
nappy
assignment
created
a
weak
reference
on
the
resource
object.
G
G
And
I
have-
and
I
have
mentioned
that
if
we
change
the
reference
to
a
strong
stonework
previously,
some
some
around
my
my
called
napier-
isn't
destroyed
in
the
big
callback
of
the
resource
object
itself.
So
in
this
case
the
navi
isn't
destroyed
will
never
be
called
in
the
strong
reference
cases.
G
First,
if
we,
if
we
don't
change
the
reference
type,
we
have
to
decide
if
the
resource
object
have
been
collected
and
yet
the
async
context
has,
since
it's
a
c
provis
object,
and
it's
not
very
strongly
connected
with
the
javascript
resource
objects.
So
the
source
object
has
might
have
been
collected
by
the
gc
and
the
single
text,
my
still
being
used
as
normally
as
as
it
can.
It
cannot
be
observed.
The
resource
object
has
been
collected,
so
we
have
to
decide
to
return
a
nappy
invalid
arc.
G
So
we
cannot
call
the
because
nappy
make
callback
with
this
asm
contacts.
Since
the
resource
object
has
been
has
been
collected
and
we
have
to
keep
strong
guarantee
that
every
time
the
medical
bag
is
called,
the
asynchronous
dot
execution
resource
is
correctly
populated
to
keep
async
local
storage
working
correctly.
G
G
G
I
believe
the
mecca
back
a
pyramid
list
in
a
challenge,
but
the
behavior
is
being
vulnerable
to
the
liquid
reference,
since
we
have
to
populate
the
execution
resource
to
to
be
the
resource
object.
But
if
the
resource
object
has
been
collected
very
no
way
to
correctly
populate
the
results
of
the
jet.
B
B
B
You
know
if
the
resource
is
gone,
then
yeah,
then
then
we
have.
We
have
kind
of.
We
have
kind
of
a
situation
where,
where
okay
there's
still
async
work
going
on,
but
now
it's
it's
happening
in
some
random
context,
because
its
original
context
is
gone
so
so
so
yeah
it
kind
of
breaks
things,
but
but
it's
still
valid.
D
B
No,
it
doesn't
that's
the
problem,
so
so
right,
so
so
today,
today,
if
nobody
wants
this
async
work
anymore,
then
on
the
javascript
side,
then
all
the
other
references
to
to
to
the
resource
will
be
removed
and
the
garbage
collector
will
well
collect
the
resource,
but
right,
not
the
ac,
but
not
the
async
context
right
and
so
the
18
contacts
will
now
sort
of
be
orphaned.
B
The
the
the
native
side
of
the
na
of
the
ac
context
will
still
be
around,
but
the
resource
with
which
it
was
dissociated
will
be
gone
and
because
the
extinct
context
is
still
around,
you
can
still
make
you
can
still
pass
it
into
and
to
make
call
back
right.
But
now
what
is
your
resource
since
the
resource
which
was
created
is
gone?
B
It
has
no
more
resource,
and-
and
so
so-
and
this
was
okay
before
because
we
did
not
require
continuity
with
respect
to
the
resource,
but
now
we
do
right,
and
so
so,
how
do
we
handle
that
case
right?
We
we've
been
correct
if
I'm
wrong,
because
we've
been
handling
it
by
creating
a
new
object
correct
if
the
old
one
is
gone,.
G
B
B
Yeah
right,
okay,
so
that
is,
that
is
also
a
change,
because
what
because,
on
main,
what
do
we
do
on
main
we
still
successfully
call,
even
though
the
resources
could
on
correct.
A
A
B
I
was
just
going
to
say
like
it
sounds
like
okay,
this.
This
is
something
this.
This
is
sort
of
like
hasting
hooks
pull
the
carpet
out
from
underneath
us
right
and
we
have
to
stay
api
stable,
whereas
asynchronous
does
not
right
so
so
they
changed
this
behavior
and
and
now
we're
sort
of
stuck
with
the
bill
right.
B
B
That
or
you
know,
do
the
right
thing
and
when
you-
and
when
you
get
a
weak
callback
for
your
for
your
for
your
resource,
then
turn
off
the
whole
lacing
thing
basically
make
no
more
calls
using
this
context
after
the
resource
is
gone.
That
should
be
our
advice,
because
the
resource
can
be
gone
because
the
javascript
is
no
longer
interested
right
or
the
resources
must
be
kept
around.
B
If
you
wish
to
make
async
calls
past
the
the
expected
lifetime
of
the
resource,
so
I
like
so
either
way
because
of
a
change
in
in
the
behavior
of
of
of
core.
B
G
B
G
If
we
keep
the
weak
reference
style,
there
will
be
cases
that
the
nappy
is
when
not
basing
is
called
with
not
a
normal
resource
object.
Then,
since
we,
since
currently,
the
navigation
will
implicitly
create
a
local
scope,
resource
object,
and
so
when
this
object
is
weak
referenced,
so
this
not
now
piercing
ink
will
be
invalid.
Since
the
initial
the
source
object
will
be
collected
after
the
navigation.
Go
back
right
returned
immediately
and
it
depends
on
the
va
implementation.
G
G
B
The
add-on
that
the
resource
is
gone
right,
so
the
value
is
that
the
add-on
can
say.
Oh,
oh
you're,
not
interested
in
my
acting
stuff
anymore,
all
right,
fine,
fine,
okay!
Let
me
delete
everything,
so
it
gives
the
add-on
a
chance
to
do
the
right
thing
right,
but
this
way
it
doesn't
even
give
the
add-on
a
chance
to
do
the
right
thing.
G
A
Right,
like
yeah,
so
to
get
proper
context
propagation,
you
need
to
provide
a
resource,
and
we
should
document
that,
but
to
prevent
us
from
breaking
existing
code
like
in
terms
of
it
won't
run
anymore.
We
could
create
that
resource
create
a
hard
reference
in
the
close
or
whatever
the
the
equivalent
to
the
getting
rid
of
the
async.
We
could
delete
that
so
that
we
don't
leak
memory,
so
it
would
continue
to
work.
We
wouldn't
have
changed
the
api,
but
really
you
know
for
for
async
hooks
and
proper
contacts.
A
G
Yes,
I
can
try
this
pad
this
pattern
so
that
we
can
see
if
there
is
any
module
being
break
and
so
that
we
can
see
it.
If
we
can
proceed.
B
A
G
B
I
don't
know
if
we
can
do
that
right,
because
we
cannot
return
an
error
that
we
didn't
return
before
right.
So
so
you
know
the
the
problem
that
you
know.
If
if
people
don't
listen
and
they
don't
say
that
you
know
and
they
don't
change
their
code
right
and
they
give
us
a
resource
and
the
resource
goes
out
of
scope
right
if
they
don't
change
their
code,
then
then
you
know
their
code.
B
So
nothing
will
change
right
so
and-
and
they
will
know
that,
then
they
will
get
a
bug
report
that
says:
hey
your
context,
doesn't
work
anymore
right
and
then,
when
they
do
that
they're
going
to
go
to
the
documentation
that
they're
going
to
say
and
the
documentation
is
going
to
say
you
need
to
maintain
a
strong
reference
to
the
to
the
resource
in
order
for
the
context
to
work
properly
and
they're.
Like
oh.
D
B
So
I
need
to
make
that
change
and
then
they
make
the
change.
I
think
that's
that's
the
best
we
can
offer
right
now.
If
we,
if
we
change
the
way
it
fails,
then
then
then
we
are
breaking.
You
know
the
the
covenant.
You
know
we
are
breaking
an
api.
If
we
do
that
right,
but
but
we
don't
need
to,
we
don't
need
to
say
napping
validar
because
it
will
be
broken.
Even
if
we
don't
say
it
it'll
break,
because
core
doesn't
work
that
way.
Anymore.
E
B
G
B
G
The
they
cost
not
see
the
there
is
any
error
message
by
from
the
same
hooks,
there
will
be
no.
There
will
be
no
messages
that
I
think
will
just
act
access
the
exchange
behavior
on
the
execution
resource,
since
the
resource
is
not
correct,
but
we
have
no
way
to
check
that.
A
B
Async
nappy
async
in
it
strong
context,
then
then
we
could
we
could.
We
could
add
a
variant
that
wherein
we
we
explicitly
maintain
a
strong
reference
right
and
then
and
then
you
know
for
when
they
receive
such
a
bug,
then
our
answer
would
be
use
use
this
other
api,
because
this
will
do
what
you
want
and
then
the
resource
will
not
evaporate
and
that's
somewhere
minor
changes.
To
just
add
this
api
and
and
document
and
direct
people
who
experience
this
bug,
who
are
responsible
for
fixing
bugs
such
as
these
direct
them
to
this
new
api.
A
Yeah
and
then
deprecate
the
old
one
and-
and
you
know
not.
B
Well,
no,
no,
the
old
one
has
has
a
has
a
role
to
play
right
because
for
those
for
those
add-ons
who
wish
to
tie
the
life
cycle
of
the
async
context
to
the
life
cycle
of
the
resource,
they
do
not
wish
to
create
the
strong
reference
right
because
they
are
responsible
and
in
the
in
the
weak
callback
for
the
regular
context.
They
will
destroy
the
context.
So
then
the
context
will
have
the
life
cycle
of
the
of
the
resource,
but
those
who
wish
the
context
to
have
the
life
cycle
that
they
ch
right.
B
They
will
want
to
create
a
strong
context
right.
So
if
the
add-on
decides
when
the
context
lives
or
dies,
then
you
use
the
strong
context.
If
the.
If
the
javascript
side
decides
when
the
add-on
lives
or
dies
by
way
of
the
garbage
collector,
then
you
create
a
weak
context
right
and
and
then,
if
you
create
a
weak
context,
you're
responsible
for
destroying
it
during
its
garbage
collection.
B
So
so,
then,
you
have
two
kinds
of
basic
contexts:
one
controlled
by
the
javascript
side
right
and
you
know
if,
if
it's
not
needed
anymore,
it's
garbage
collected
and
and
you
as
the
add-on
maintainer,
are
responsible
for
destroying
the
entire
context,
not
just
a
resource.
That's
one
correct
way
of
functioning
and
the
other
correct
way
of
functioning
is
the
the
that
is
that
the
async
context
behaves
like
a
like
a
like
a
set
interval.
You
know
it
keeps
happening
and
it
keeps
being
alive
until
somebody
calls
clear
interval
right
same
same
way.
B
The
context
is
alive
and
valid,
and
with
a
valid
and
with
a
valid
resource,
until
somebody
calls
it,
they
sing,
nappy,
ates
and
destroy
right.
So
so
these
are
two
modes
of
operation.
Both
of
them
are
valid,
right,
yeah
and
right
now,
right
now,
only
the
weak
one
is
possible
right.
That
makes
sense.
B
Yeah
right,
okay,
so
so
so
then
we
can
yeah.
We
can
solve
this
with
with
some
documentation
and
december
minor
change,
adding
a
new
api
that
that
that
will
will
do
this
for
you
so
that
we
don't
have
to
tell
people
okay.
Well,
add
a
finalizer
or,
or
you
know,
add
a
strong
reference,
because
that
gives
them
more
work
right
now
they
have
to
destroy
the
reference
and
so
forth,
and
so
so
that's
more
code
on
the
on
the
add-on,
maintainer
side.
A
B
Yes,
yes,
yes,
because
we
we
keep
supporting
this
yeah.
Yes,
basically,
the
the.
If
you
pass
a
null,
then
you
are
automatically
opting
for
a
strong
context.
That's
basically
well.
B
E
A
Sounds
good,
so
we've
got
10
minutes
left.
So
let's
flip
back
to
talk
about
the
blog.
A
Post
this
one,
I
see,
I
do
see
that
a
number
of
people
have
started
to
fill
things.
E
E
C
You,
sir,
go
ahead,
so
I
started
working
a
little
on
the
features
section
sort
of
where
that
table
is
here,
so
I
wasn't
sure
how
the
best
way
to
organize.
C
Right
so
here
I
put
like
a
table
and
then
underneath
I
just
maybe
put
a
list.
I
don't
know
and
then
a
little
after
that
I've
specifically
talked
about
thread
safe
stuff
here
and
how
we
had
mentioned,
maybe
pinpointing
a
couple
of
projects
that
use
those
features.
C
So
that's
what
I
had
in
that
little
blurb
near
the
bottom
near
the
bottom
of
the
page.
C
A
A
C
Because
that
would
be
for
context
sensitive
add-ons.
A
Yeah
it's
just
like
the
you
know.
The
thread
say
functions.
I
look
at
say,
I'm
not
necessarily
sure.
That's
what
that
is,
whereas
if
I
read
like
data
objects,
attaching
a
finalizer
to
an
object,
bigints
getting
property
names,
detached
array
buffers
those
all.
I
figure
I
kind
of
know
what
those
are
right.
Just
by
reading
the
title,
but
setting
instance
data
and
the
thread
say
functions,
I'd
be
like.
C
B
C
It's
really
just
like
a
one
sentence,
description
of
what
it
does,
because
the
concern
that
I
had
last
time
was,
I
didn't
want
it
to
be
too
tutorial
sounding
right.
A
A
What
problem
it's
trying
to
address
you
know.
C
A
As
a
as
a
you
know,
we
found
you
know
something
like
we
found
that
that
a
lot
of
module
owners
needed
to
do
x
and
that's.
A
A
A
A
We
only
have
a
few
minutes
left
now,
but
it
sounds
like.
Maybe
we
should
try
and
reserve
like
half
an
hour
next
meeting
to
kind
of
go
through
it
and
see
if
we're
we're
pretty
much
done
or
what's
left
to
be
done.
Does
that
make
sense,
yeah.
F
Maybe
we
can
start
writing
the
blog
post
and
then
we
follow
with
the
our
usual
agenda.
A
Going
to
be
through
faster
on
the
other
stuff,
but
yeah,
okay,
so
yeah.
So
let's
start
with
that
next
time,
and
then
you
know
it
looks
like
we've
got,
you
know,
we've
got
we're
pretty.
We've
got
a
lot
of
the
good
content.
We
can
just
sort
of
tweak
it
together
in
that
half
hour
and
or
whatever
it
takes
of
the
hour
and
and
hopefully
be
ready
to
go.
G
Some
questions
on
the
table
of
the
nappy
navigators.
Just
in
the
document
we
have
seen.
G
Six,
the
property
names
is
actually
the
get
all
property
names
since
we
have
previously.
We
have.
We
do
have
calpers
names
in
nappy
since
number
version,
one.
So
the
nappy
version
six
introduce
a
catalyst,
including
the
symbols
and
the
non-innumerable
names.
So
I
it.
It
is
important
to
mention
this
point.
G
G
Again,
I'll
probably.
A
G
A
A
If
not
thanks
for
everybody's
time
and
we'll
see
you
in
github
and
at
the
meeting
next
week,.