►
From YouTube: 2021-08-20 Node.js Node-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
All
right
everybody
and
welcome
to
today's
node
add-on,
note
api
meeting
for
friday
august
20th
before
we
go
through
with
our
normal
announcements.
Does
anybody
our
normal
agenda?
Does
anybody
have
any
announcements.
A
All
right,
so
first
we
have
stale
issues
to
discuss.
You
can
go
down
to
the
bottom
that
one's
already
marked
crossed
nick.
He
did
not
join
today,
but
he
does
have
a
open
pr
on
node
headers.
A
And
it's
mainly
a
documentation,
update,
but
there's
also
this
small
change
here
and
from
what
I
thought
that
it
was
always
better
to
separate
path
names
as
different
arguments
instead
of
using
a
hard-coded
slash,
even
though
it
should
work
across
system.
I
always
thought
it
was
better
to
do
this
this
way,
so
I
wasn't
exactly
sure
why
this
change
was
made,
but
I
guess
if
I
can
leave
this
as
a
comment
unless
anybody
else
knows
why.
A
A
Okay,
then,
because
this
pr
was
related
to
that
bottom
one,
and
then
this
one
here
this
was
the
reference
with
the
no
except
move
constructor.
A
We
looked
at
this
last
week
and
there
was
no
updates
and
again
there's
there's
been
no
updates.
A
So
I'm
not
exactly
sure
what
we
should
do
with
this
unless
he
comes
back
saying
otherwise,
maybe
we
would
just
leave
this
open
until
the
stale
bot
closes.
It.
A
Yeah,
so
we'll
just
wait
from
him,
then
the
next
one
on
the
sales
issue
is
this
access
violation
and
typed
array
of
we
also
looked
at
this
last
week
and
again
we
were
waiting
for
feedback
from
the
poster
and
again
still
waiting
so
we'll
leave
this
one
open
until
we
get
feedback.
A
C
Not
much
updates,
I
was
mostly
on
vacation.
Actually
last
we
speak,
and
but
anyway,
I'm
kind
of
currently
working
on
implementing
an
api
for
hermes
and
I
kind
of
in
next
couple
weeks
we'll
definitely
learn
more
in
this
area,
but
I
hope
that
it's
not
show
stopper
for
this
issue.
But
what
do
you
think?
A
So
I
think
it
would
also
be
helpful
to
have
lucas
and
michael
on,
but
so
the
the
issue
is
that
what
we
need
to
be
able
to
do
is
support
if
we
go
back
to
the
top
here,
throwing
allowing
this
to
be
referenced
or
persisted
so
that
we
can
give
it
back
to
to
the
caller,
and
since
this
can
be
any
type,
whether
it
is
an
object
or
primitive,
we
was
we're
hoping
that
that
could
be
handled
in
the
core
and
gabe.
B
I
think
I
think
the
the
the
key
here
is
that
you
know,
if
I
remember
correctly,
except
for
symbols,
we
can't
handle
it
all
internally
right
because
primitives
in
js
are
also
primitives
in
c
plus
right,
so
things
like
strings
and
and
numbers,
but
ideally
what
we
would
want.
B
If
all
engines
support
it
is
to
remove
the
restriction
that
persistent
references
can
only
be
created
to
like
objects
and
functions,
but
basically
javascript
objects
right,
and
for
that
we
we
need
to
know
that
all
the
engines
support
persistent
references
to
primitive
types,
and
so
so
that's
so
that's
why
we
need
the.
We
need
to
know
this
about
hermes.
B
So
so
you
know
if,
if,
if
node
api
gets
implemented
for
hermes,
that's
not
going
to
immediately
tell
us
this,
but
but
if
you
can
run
an
experiment
where
you
remove
the
restriction
and
see
if
it
still
works
and
just
try
to
make
a
persistent
references
to
like
the
persistent
reference
to
like,
I
don't
know
the
number
five
you
know
and
that
works
and-
and
you
know
a
garbage
collection
and
all
that
and
the
reference
the
finalized
callback
gets
called.
B
Then
then,
I
don't
see
a
reason
why
we
should
not
drop
this
requirement
and
basically
you
know
in
in
in
node
api
version
nine.
We
would
have
this
feature
that
okay,
you
can
now
reference
pretty
much
any
javascript
value,
but
we
need
to
run
this
experiment.
First.
C
So
current
state
is
actually
any
kind
of
pointer
types
can
be
used
as
a
persistent
references
like
strings
and
symbols,
objects
and
and
function
considered
as
an
object
in
hermes
engine.
The
other
values
like
boolean
numbers
kind
of
now
undefined.
C
I
I
believe
these
guys
are
kind
of
treated
as
just
enum
values
in
external
apis,
and
I
think
they
may
have
some
internal
references
from
numbers
for
like
local
values,
but
they
always
cons
converted.
B
Okay,
so
okay,
but
it
sounds
like
it's
okay.
Let
me
let
me
think
about
what
you
just
said.
So,
basically,
if
so
in
in
let's
say,
let's
say
we
added
this
relaxation
of
the
requirements
for
for
persistent
references
right
then
in
hermes,
would
you
be
able
to
implement
persistent
references
to
primitive
types
in
the
node
api
implementation?
So
would
you
be
able
to
receive
notification
from
the
engine
that
the
number
five
is
being
garbage
collected?
C
B
C
B
C
Are
considered
object
so,
okay,
so
we
just
didn't
understand
before
so
think
the
the
problem
that
you
say
that
you
need
to
have
this
notification
from
garbage
collection
from
gc.
In
order
to
be
able
to
remove
this
persistent.
B
Values
is
it
correct?
Yes,
that
that
that
is
the?
That
is
the
one
important
feature
that
we
need.
Oh,
I
see
yeah
because
we
we
have,
we
have
like.
We
have
weak
persistent
references
and
strong
persistent
references
right
and
for
a
weak,
persistent
reference.
You
know
if
you
say
if
in
javascript
you
say
you
know
a
equals
five
and
then
a
equals
null.
Then,
and
you
know
what,
but
then
there's
a
persistent
reference,
a
weak,
persistent
reference
to
five.
B
C
B
So
so
the
the
the
one
piece
of
good
news
that
you
brought
is
that
the
you
know
the
the
persistent
reference
system
and
the
garbage
collection
notification
mechanism
works
for
symbols
and
that's
great,
because
because
then
we
can
achieve
the
minimum
necessary
for
this,
which
is
to
extend
the
the
the
or
to
relax
the
check
to
like
functions,
objects
and
symbols
instead
of
just
functions
and
objects.
B
And
since
the
original
motivation
for
this
work
was
to
treat
exceptions,
then
I
think
we
may
just
have
enough
because,
like
we
don't
like,
ideally
we
want
to
do
this
for
for
in
core.
But
if
we
put,
if
we
put
symbols
as
as
a
type
that
can
be
referenced
persistently
in
core
and
we
leave
the
rest
as
primitives,
then
we
still
have
a
solution,
because
you
know
we
we
can
just
store
the
the
primitive
type
in
the
exception.
And
then
we
solve
the
rest
of
the
problem
and
know
that
on
api
right.
B
So
so
the
fact
that
you
have
confirmed
that
that
symbols
in
hermes
are
treated
as
objects
is
very
good
because
then
we
can
have.
You
know
we
can
have
a
a
a
notification
from
the
garbage
collector
saying
this
symbol
is
about
to
be
garbage
collected.
Therefore,
you
know
do
whatever
native
things
you
need
to
do
at
that
time
and
we
we
also
have
that
from
v8,
and
I
suppose
we
should
check
with
other
engines,
but
but
it's
it's
a
pretty
good
sign.
C
A
Yeah,
so
I
also
tried
to
do
a
little
bit
of
research
into
the
different
engines
and
whatnot
so,
for
example,
in
spider
monkey.
I
found
this
persistent
rooted
that
has
the
different
types
and
I
did
see
that
they
have
symbols
and
and
stuff
here.
So
I
think
that
would
be.
A
I
didn't
actually
go
as
far
as
creating
a
a
test
or
anything
like
that,
but
going
from
this
definition,
I
would
imagine
that
if,
if
you
were
implementing
node
api
on
top
of
this
engine,
you
could
so
you
could
create.
You
know
the
persistent
references
on
these
types
using
this
somehow.
B
So
so,
okay,
that
that'll
take
care
of
strong
persistent
references,
but
does
it
also
support
weak,
persistent
references,
meaning
that
you
know
when
you
get
a
notification
when
the
when
the
reference
is
being
garbage
collected
yeah?
That's
that's
what
I'm
trying
to
figure
out
from
the
example,
because
we
really
want
that.
B
Yes,
exactly
yeah,
okay,
so
so
that's
yeah.
Basically
what
we
need
for
each
engine.
We
need
the.
We
need
the
answer
to
two
questions:
does
it
support
persistent
references
to
this
specific
type
and
does
it
support
weak,
persistent
references
to
the
specific
type
because
v8s
the
answer
in
both
cases
is
yes,
so
that's
that's
what
we
got
to
figure
out.
A
Okay,
so
I
can
continue
looking
at
these
a
little
bit
too
then.
C
So
let
me
ask
a
question:
I
know
that
the
javascript
itself
supports
weak
pointers.
I
and
I
wonder
if
what
types
actually
are
covered
by
this
big
pointer
support
inside
of
javascript
itself,.
B
B
C
I
think
it's
possible
exactly.
B
A
Yeah,
it
was
only
an
object
and
that's
the
same
thing.
With
the
keys
in
a
weak
map.
They
can
only
be
functions
or
objects,
and
that's
what
legendary
cast
was
also
mentioning
as
one
of
the
the
ts
proposals
of
allowing
symbols
to
be
weak.
B
D
Okay,
so
it
sounds
like
we
just
still
have
some
more
investigations
to
do
on
this
one
then.
So
I
I
guess.
C
C
So
think
we
have
big
reference
really
behave
more
like
javascript
style.
In
this
case,
we
have
less
chances
to
go
out
of
seeing
what
javascript
engines
could
do.
So
pretty
much
from
one
hand
allows
us
persistent
references
which
will
behave
like
normal
javascript,
persistent
references
and
have
weak
references
not
to
be
necessarily
merged
with
resistance
references.
C
I
just
find
that
it's
a
current
design
that
we
have
ref
count
goes
to
zero
and
becomes
weak
reference.
I
found
this
this
design
a
little
bit
difficult
to
use
and-
and
it's
not
really
consistent
with
what
we
find
today
in
c,
plus
plus
standard
library,
because
today
I
have
potentially
for
big
pointer,
I
can
have
like
multiple
big
pointer
to
the
same
object.
With
current
reference
design,
I
only
can
have
one
weak,
weak
reference.
B
Well,
you,
you
can
say,
like
you
know,
an
api,
what
is
it
an
api
create
reference
and
then
you
say
an
api
create
reference,
and
now
you
have
two
references
to
the
same
javascript
object.
C
Yeah
but
kind
of
losing
this
kind
of
advantage
of
ref
counting
right
like
so
imagine
that
today
I
could
have
create
reference
enough
that
I
simply
can
increment
decrement
with
ref
count
right,
like
so
normal
shared
ptr.
If
you
like
an
hour
works
pretty
well,
but
then
we
go
to
big
big
pointer
field.
We
have
to
kind
of
go
to
zero
and
instead
of
normal
behaviors,
and
we
go
to
zero,
actually
deleting
the
objects,
which
was
normal
sure
ptr
will
do.
B
Weird
yeah,
yes,
yes,
yes,
yes,
and-
and
the
reason
for
that
is,
is
because
we
we
are.
We
are
basically
exposing
the
the
garbage
collection
behavior
to
to
native
right.
So
we
want.
We
want
the
the
native
cleanup
to
happen
when
the
javascript
object
goes
out
of
scope,
not
when
the
ref
count
reaches
zero.
Basically,
the
you're
right,
the
semantics
are
a
little
bit
different
right
in
in
in
in
node
api,
a
ref
going
to
zero
means.
The
object
is
becoming
eligible
for
garbage
collection.
B
C
But
so
yeah
next
go
ahead,
but
it
kind
of
creates
this
issue
that,
with
big
pointers,
like
you,
said,
weak
pointers,
most
just
retention
will
support
only
four
objects
right
yeah.
Well,
while
I
can
be
shared
pointer
kind
of
ref
counted
references,
we
can
do
against
probably
different
objects,
not
only
limited
by
oh,
oh,
I
see
I
see
I
see.
B
Right
yeah,
that's
that's
a
good
point
yeah.
So
in
a
way,
yeah.
Okay,
I
see
what
you're
saying
yeah.
So
that's
how
we
could
go
about
doing
that
for
primitive
types,
yeah,
except
except
in
v8,
right
because
in
v8
it
seems
even
even
a
primitive
type
needs
to
be
garbage
collected
explicitly
so,
in
which
case
you'd
want
to
inform
about
this.
But
anyway,
anyway,
where
we,
I
think
we're
getting
bogged
down
here.
B
Our
our
our
goal
here
was
to
to
to
to
just
do
exceptions
right
and
to
just
have
a
way,
a
potentially
consistent
way
of
of
of
of
handling
of
handling
exceptions,
and
so,
if
we
cannot
find
such
a
consistent
way,
then
the
only
thing
that
we
need
from
engines
is
symbols,
and
that
seems
to
be
available,
and
so
you
know
we
we
need
to.
B
We
just
need
to
extend
whatever
you
know,
reference
system
that
we
have
to
symbols
and
then
we're
done
everything
else
can
be
done
with
with
with
primitives
on
the
native
side,
because
after
all,
the
exception
is
synchronous
right.
So
we,
you
know,
we
just
need
to
store
the
primitive
value
until
the
thing
gets
thrown
and
then
we
can
get
rid
of
it
synchronously.
B
B
B
A
Support
symbol,
references.
A
A
Include
symbols:
okay!
How
does
that
sound
yeah?
All
right,
then
that's
it
for
that,
then
that
is
it
for
the
stale
issues.
E
A
We
always
check
this
last
week.
I
think
we
saw
that
we
breached
the
before
4
million
last
week.
So
it's
nice,
while
we're.
D
A
While
we're
discussing
this
one-
though
let
me
just
talk
about
this,
because
this
is
a
a
requested
port-
a
pr,
a
port
from
from
nan
to
node
on
api,
I
took
a
a
look
at
it
briefly
and
in
general,
it's
basic.
It's
a
lot
of
one-to-one
conversions.
A
But
then
I
also
mentioned
that
if
you
were
to
go
to
also
migrate
these
over
to,
for
example,
using
the
node
add-on
api
library,
then
he
wouldn't
actually
have
to
do
those
explicit
checks,
let's
just
sort
of
see
what
anything
that
he
says
and
another
thing
was
a
recommendation
to
use
the
async
worker
for
this
async
cue
work
because
again
he's
creating
all
of
these
without
checking
the
status
so
using.
That
would
alleviate
some
of
that.
B
Oh,
I
suspect,
I
know
why
I
think
async
worker
is
one
of
those
object,
wrap
type
classes
where
you're
expected
to
subclass
it,
and
then
you
know,
and
then
the
implementation
is
the
subclass
and
and
that
may
not
fit
the
model
that
they
had
before
right.
And
so
that's
probably,
why
they're,
why
they're
using
an
api
calls
directly
right,
but
but
we
do
have
macros
exposed
that
will
help
them,
handle
the
the
possible
resulting
non
okay,
statuses.
B
So
your
comment,
so
I
mean
so
your
comment
on
on
the
previous
calls
to
to
handle
the
non-okay
status.
I
think
probably
applies
here
as
well.
B
You
know,
like
you
can
maybe
add
like
if
you
cannot
switch
to
an
api
async
worker,
then
then
at
least
use
and
insert
name
of
macro
here
to
handle
non-non-okay
status
like
I
think
I
think
I
think
we
have
an
api
throw
or
fail,
or
something
like
that,
because
I
remember,
I
remember
exposing
those
those
used
to
be
private
and
and
then
I
exposed
them,
because
I
realized
people
who
who
do
this
hybrid
thing
where
they
sometimes
call
know
that
on
api,
sometimes
not
they'll
probably
want
those
right.
So
I
think
yeah
so
so.
A
A
All
right,
then,
that's
it
for
the
modules
ported,
then
testing
methods.
A
We
can
go
to
the
issues
here
for
test
because
jack.
I
noticed
that
you
created
a
bunch
of
these
couple
of
these
issues
here
to
outline
which
ones
are
covered,
so
I'm
assuming
then
that
something
that's
empty
here.
Yeah
means
that
that
they're
not
covered
that's
a
kind
of
very
small
use
case
there.
Then
I
also
saw
you
had
a
pr
for
function.
Reference.
E
A
Okay
yep,
so
this
is
open.
We
can
just
go
through
and
review
this
when
when
we
have
time
this
closes
this
issue,
then,
is
this
going
expected
to
cover
all
of
these
then
yeah
yeah?
It
just
covers
all
those
different
overloads
and
like
different
use
cases
and
stuff
yeah.
A
Okay,
do
you
have
any
questions
or
anything
for.
E
Us
it's
just
a
small
one
so,
like
I
was
like
doing
some
documentations
for
the
classes,
and
I
was
doing
for
the
like
the
async
q
workers
and
notice,
like
the
tests
that
we
have
for
those
they
only
like
it,
doesn't
really
have
cover
all
the
different
constructor
overloads.
So
I
was
wondering
if
we
should
like
cover
all
of
those,
but
because
there
was
like
seven
or
eight
different
ways
you
can
like.
I
guess,
construct
a
kiloworker.
A
Well,
we
have
had
threat
issues
in
the
past,
but
I
I
think
michael
has
has
solved
the
most
recent
one.
So
hopefully
that
shouldn't
be
a
problem,
but
I
do
know
what
you're
referring
to,
because
it's
also
the
same
with
threat,
safe
functions.
We
have
a
lot
of
overloads
for
the
new
there
as
well.
B
Yeah,
I
think
I
think
in
in
the
case
of
these
complex
classes,
we
were
concentrating
on
on
on
making
sure
that
the
class
behaves
you
know
as
expected
and
we
weren't
so
much
worried
about
about
coverage
so
yeah.
Basically,
I'm
I'm
thinking,
I
don't
know
if
we
can
use
some
summons.
B
I
mean
some
inheritance
or
some
class
structure
magic
here
to
to
basically
have
the
same
behavior
that
that
the
test
already
has
but
then
use
use
like
the
like,
basically
fan
out
the
constructor
to
to
the
different
overloads
you
know,
and
so
basically
you
run
the
same
test
over
and
over,
but
with
differently
constructed
objects.
You
know,
and-
and
I
know
that
in
the
case
of
threat-
say
function
that
might
also
increase
the
test.
Runtime
significantly,
because
I
know
threat
say
function
has
like
all
kinds
of
like
busy
loops
on
purpose.
B
You
know
just
to
just
to
test
the
the
synchronization,
so
it
it
yeah.
So
you
know
trying
all
the
different
constructors
might
sort
of
yeah.
It
might
increase
testing
time.
One
one
thing
that
I'm
thinking
we
might
want
to
do
is
is
maybe
add,
like
a
friend
class
like
declare
a
florent
class
inside
like
the
async
worker,
and
then
you
could
you,
you
could
do
like
a
unit
test.
You
know
like.
B
E
A
Thanks
all
right,
then
that
is
it
for
debug
testing
methods,
debug
testing
for
node
add-ons.
This
is
what
michael's
working
on.
I
don't
think
he
has
posted
any
updates
and
he's
on
I'm
not
here.
So
we
will
wait
for
next
week
and
see
what
he
says
about
that.
A
Then
we
have
burn
down
list
of
issues.
Let's
see.
If
there
are,
I
mean
I
don't
think
there
are
any
yeah
in
here.
So
are
there
any
issues
on
the
repo
that
anybody
wants
to
bring
up
explicitly.
A
No
okay,
I
added
I
mean
I
didn't
add
an
issue.
I
there
was
this
one
issue
here
that
was
added
two
weeks
ago
and
we
looked
at
it
last
week
a
bit.
It
is
when
you
want
to
call
a
javascript
async
function
from
like
a
native
function
and
wait
for
the
value
and
then
return
that
value
sort
of
like
bridging
native
promises
and
futures
with
javascript
promises,
and
then
so.
This
was
from
the
original
poster
and
then
another
person
had
the
exact
same
sort
of
question.
A
A
A
Callback
for
the
then
that
actually
resolves
the
date
of
promise,
pretty
simple
like
that,
so
this
is
ready
for
review
for
any
lighting.
That
has
a
little
extra
time.
A
A
So
someone
else,
we
have
time
to
look
at
that.
Someone.
A
Else
has
time
to
look
at
that
that'd
be
great
as
well,
then
those
are
all
of
the
issues.
A
This
enum1
I've
been
going
back
and
forth
with
one
of
the
posters
here
they
were
asking
about
casting
from
the
enum
class
to
native
types
and
who
would
work
back
and
forth,
which
I
think
should
be
fine,
but
then
I
also
noted,
if
you
just
use
a
normal
enum,
it
may
have
the
casting
automatically
for
you,
so
you
don't
have
to
explicitly
cast
it.
A
Okay,
this
is
just
one
that
has
just
not
been
looked
at,
yet
I
guess
it's
an
issue
on
the
documentation.
Hopefully
we
can
take
a
look
at
that
as
well.
Anybody
has
time
for
that.
A
A
Dpox
pr
for
unit
tests,
he
hasn't
made
any
changes
in
some
time,
but
I
didn't
want
to
lose
track
of
what
we
had
discussed
before,
which
was
possibly
standardizing
some
of
the
test
structure
in
order
to
not
necessarily
have
to
have
this
sort
of
mapping,
because
one
of
the
one
of
the
not
issues,
but
we
have
a
tight
coupling
between
like
the
tests,
exports
and
names
and
things
like
that
and
act
in
the
test
runner.
A
But
then,
when
you're
doing
locally,
you
can
do
npm
tests
with
the
filters,
and
these
may
come
piecewise
there's
different
changes,
because
maybe
the
standardization
of
the
test
names
can
come
before
this.
You
know,
but
I
just
didn't,
want
to
lose
track
of
those.
So
put
them
in
this
pr
as
a
comment
and
if
anybody
else
has
some
time
to
look
at
his
his
changes.
That'd
be
great
as
well.