►
From YouTube: Node.js N-API Team meeting - May 4 2020
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).
B
B
D
A
A
A
A
A
B
B
A
May
be
more
that
this
is
like
a
special
situation
where
we
had
a
bunch
of
changes
that
got
in
and
really
we
should
have
maybe
done
a
release
earlier,
but
we
didn't
and
if
we
had
done
a
release
earlier,
it
wouldn't
really
been
a
problem
so
but
I
think
it's
worse
right.
You
know
talking
together
as
a
team
saying
this
is
this
is
what
we're
approaching
this
one
agreeing
to,
and
so.
C
A
B
A
F
C
F
C
F
F
A
F
A
A
G
A
Okay,
so
we'll
leave
this
one
on
as
a
reminder
to
talk
about
the
two
directs
release
between
now
and
then
you
know,
I
think
we
should
give
people
a
little
bit
more
time
to
comment.
If
there's
any
other
issues,
and
maybe
next
week
we
can
talk
about
timing
for
that
I,
don't
kind
of
okay
SQL,
eight,
an
API
port
yeah.
C
C
It
lists
each
test
and
the
first
column
is
the
mean
time
in
milliseconds
form
and
then
the
nan
version
to
run
the
particular
test.
So
this
is
20
iterations
of
the
test,
and
then
the
nappy
mean
is
how
long
an
API
took.
There's
a
difference
there.
So,
overall,
if
you
total
it
all
up,
the
N
API
version
of
the
the
add-on
is
running
about
15
percent
slower
than
the
man
version.
Okay.
C
So
what
I'm
thinking
is
I
feel
I
need
to
make
the
maintainer
of
the
of
the
add-on
aware
of
this
right
and
my
my
I've
been
monitoring
now
I'm
monitoring
the
issues
on
that
repo.
My
plan
would
be
to
monitor
any
any
complaints
of
slowness.
There
take
a
look
at
it
and
then,
if,
if
it's
beyond
my
capability
to
post
an
issue
either
on
node
core
or
on
the
node
add-on,
API
yeah.
A
A
C
A
I
A
C
C
C
C
Michael,
if
you
open
that
one
up
also
down
at
the
bottom
as
I
mentioned
last
week,
I've
got
a
gap,
Gatsby
implementation
going
and
there's
a
link
here.
That
brings
up
what
it
would,
what
it
will
look
like
when
it's
on
Gatsby,
okay
and
it
needs
work.
I,
do
not
make
any
progress
on
that
this
week,
but
this
is
where
I'll
start
putting
my
energy.
D
C
C
A
C
A
C
A
C
A
G
G
C
H
A
A
A
We
want
to
turn
on
get
up
pages
for
this
repo
I'm,
not
a
hundred
percent
sure
that,
like
once
a
repo
is
open,
we
really
have
to
ask,
but
since
I
don't
think
there's
many
of
them
like
I,
don't
know
of
other
repos
that
haven't
turned
on.
It
makes
sense
to
make
sure
everybody's
aware
through
that,
by
making
the
ask
in
the
first
place,
yeah.
C
C
A
A
A
B
Because
I
think
you
were
working
with
with
the
acing
context
and
stuff
that
was
the
most
recent
sort
of
movement.
There
I
believe
Lucas
Lucas
identified
this
this
redundancy
in
in
the
way
our
API
was
was
it
was
written,
so
we
were
having
our
lasing
context
as
well
as
an
async
resource.
Alright,
that's
over
in.
A
B
A
E
A
I
A
Alright,
so
here
so
this
object.
If
you're
passing
in
the
context
that
already
has
an
object
in
it,
then
this
object
doesn't
really
make
sense
and
I
guess
we
couldn't.
We
couldn't
come
up
with
a
case
where
you
would
want
to
override
what's
in
the
async
context,
handle
or
it
would
make
sense
at
all,
but
because
we
don't
want
to
break
this
ABI
EBI.
What
I'd
suggested
was.
A
A
A
C
A
B
A
It's
bundled
into
like
it
ends
up
being
the
object
you
would
get
back
for
the
for
the
contacts.
The
problem
is:
is
that
because
there's
also
this
async
handle,
which
you've
actually
been
aided,
you're,
now
overriding
the
object
that
you
gave
it
when
you
created
the
handle?
We
think
like
these
in
context
and
that
message
so.
B
I
Yeah
strictly
speaking,
Reynold
the
parameters
passed
in
the
Nappy
may
go
back
and
anatomy
and
a
bit
of
panko
that
Scott
was
another,
the
actual
facing
hook,
the
source
being
not
as
the
expected
result.
So,
basically,
if
we
use
the
NAPLAN
method
for
the
so
the
current
behavior
another
actually
not
as
would
be
expected
one.
So
I'm
wondering
if
it's
someone
is
everything
in
the
right
back,
then
they
might
not
be
receive.
The
mag
not
be
pursue
the
correct
behavior
of
the
facing
hooks.
A
I
The
thing
that
would
be
yes,
the
it
can
change
either
behavior
look
story
with
nappy
in
the
next
day.
Nappy
open
code,
Xcode
and
I
didn't
call
that,
but
the
opportunity
that
we
passed
into
the
nappy
functions
in
it's
possible
in
other
another
one.
We
pursue
a
tracing
hooks
so
currently
not
nappy,
I.
I
Think
in
so
currently
the
nappy
method
doesn't
work
work
and
the
document
talk
as
in
the
document
since
a
and
maybe
an
and
take
a
sample
like
nappy
Nickelback,
you
not
make
hotel
with
we
passed
in
a
interesting
context
and
the
async
conduct
is
indeed
until
with
a
resource,
but
in
the
ASIC
hooks
right
now
we
we
can
still
the
resource.
The
source
we
see
is
actually
the
nothing
Michael
that
the
the
receiver,
the
receiver
of
parameters.
So
let
me
nappy
Michael
that
is
not
working
and
the
document
with
the
icing
hooks
so.
I
I
A
A
I
You
see
that
extant
context
we
created
with
the
nappy
thing
innit
you
still
a
listing
contacts
in
created
with
a
resource
and
we
we
use
async
contact
the
start
of
each
other
in
the
assumed
to
the
summative
in
the
nappy,
nappy
resource
analogy,
actual
resource
and
the
parameter
receiver
of
the
nappy
make
coke
back.
So
it
doesn't
look
and
doesn't
work
and
document
right.
A
A
It
sounds
like
in
this
case,
like
we
couldn't
come
up
with
any
reason
why
it
would
make
sense
to
be
doing
like
why
people
would
want
it
to
do
what
it
is
doing
before
this
fix
and
then,
even
though
you
know,
if
listen
to
cassock
you're,
saying
it's
even
documented,
not
to
do
this.
That's
even
another
good
reason.
A
A
A
A
E
B
B
And-
and
so
that's
probably
why
we
added
it,
but
now
that
now
that
we
have
it
properly
like,
we
have
to
the
context
properly
thread
it
through
from
the
definition
of
the
of
the
async
context.
I
think
it
might
make
sense
to
point
out
that
this
is
not
used
or
and
yeah
I.
Eventually
we
can
do.
We
can
do
a
second
API,
so
then,
so
then
then
this
would
have
to
accept
null
for
that
right.
A
A
A
Because,
again,
that's
one
where
it
may
have
been
optional
at
some
vote
at
some
point.
You
know
along
the
lines
of
what
you're
saying
they
reeled
it
back
at
some
point,
do
you
think
itself
wasn't
necessarily
tied
to
the
object,
but
now
it
is
so
it
doesn't
actually
make
sense
that
that
be
optional
anymore
anymore.
B
That's
right:
well,
I
mean
you
know
it
can
be
optional
in
the
JavaScript
sense,
because
if
you
don't
provide
it,
then
you
can
just
pass
null
point
or
like
a
JavaScript
null
pointer
object,
which
is
an
object
so
and
if
people
want
to
pass
no
pointer,
then
the
you
know
the
they
can
so
I
mean
it's
optional.
In
that
sense,
it's
just
I'm,
not
sure
if
it
if
we
are
currently
translating
from
from
from
a
native
null
pointer
to
a
JavaScript
null
pointer.
If
it's
not
given.
H
I
A
So
that's
where,
like
you
know,
we
thought
we
did.
The
discussion
so
far
was
what
I've
captured
in
this
draft
PR,
which
is
again
because
we
don't
want
to
break
the
APA,
be
I
you
know
documented
as
it
being
required.
But
if
you
pass
in
no,
it's
not
gonna
actually
throw
an
error,
but
they're
telling
you
that
you're
gonna
result
in
incorrect
operation.
I
A
B
I
B
C
B
We
should
say
here
that
you
know
if
it
says
right
now:
it's
as
an
optional
object
associated
with
the
async
work
that
will
be
passed,
Oh
lacing
hooks
right.
We
should
say
that
if,
if,
if,
if
an
object
is
not
given,
then
then
an
empty
object
would
be
created.
However,
it
is
strongly
recommended
that
an
object
be
given
so
that
the
async
hooks
might
work
properly.
Yeah.
A
I
just
thought
we
documented
as
you
you
know
you
need
to
it's
not
optional
and
then
DeLong.
You
know
below
have
the
explanation
that
says:
oh
okay,.
B
A
H
A
I
H
G
B
B
A
B
A
A
F
F
So
the
last
comment,
or
the
second-to-last,
or
something
basically,
the
imitation
yeah
the
implementation
that
I
have
does
not
work
on
the
old
version
of
GCC
and
so
a
little
backup
since
you're
in
last
week's
meeting.
What
I
ended
up
doing
was
changing
the
existing
thread-safe
function
class
to
use
this
new
thread
safe
function,
e^x
class
great,
but
for
some
reason,
if
GCC
4
is
having
some
issues
realizing
a
constant
expression
evaluation,
it's
that
on
the
Travis
CI,
with
link
it's
having
some
issues.
F
A
F
E
F
Why
what
the
issue
is
so
then
I
brought
up
the
question:
do
we
need
to
support
GCC
for
then
someone
else
brought
up
that?
Well,
no
10
builds
on
GCC
for
8,
so
this
is
sort
of
where
I
currently
am
and
I.
Guess
like
it's
work,
it's
breaking
net
like
if
we
were
to
introduce
this
thread
say
function
e^x
with
the
MV
old
class,
implementing
the
new
class
kind
of
like
what
this
PR
is.
Now
it
would
be
a
breaking
change
for
people
that
use
the
old
GCC
version.
F
A
Like
I,
don't
think
we're
necessarily
tied
to
the
versions
of
the
compilers
used
in
in
the
particular
node
version.
However,
I
think
there
is
some
risk
there
and
that
you
know
if,
if,
if
that
was
the
version
that
was
used,
you
know
for
to
compile
know,
then
you
would
think
that
it's
not
unreasonable
that
people
used
it
as
well
in
that
era
to
build
the
add-ons,
and
so,
if
you
then
had
to
I
mean
I
guess
it
would
only
be
if
you
were
trying
to
use
a
newer
version
of.
A
A
F
Cuz
like
if,
because
I'm
thinking
like
if
node
10
is
supposed
to
be
built
on
4x
and
say
I'm,
a
developer,
that's
targeting
10x,
yeah
and
I
would
want
and
I
want
my
application
to
be
able
to
be
built
with
for
ax
with
GCC
for
a
but
I,
don't
know
if
we
can
make
it
a
strict
requirement
to
say
to
say
that.
Oh,
if
you
use
no
doubt
on
API
GCC,
fours
and
aloud
I,
don't.
F
A
B
So
so
yeah,
that's
yeah,
I
I'm
thinking
the
same
thing.
So
so
you
know
the
change
introducing
thread-safe
function.
E^X
is
not
sent
for
major
in
in
and
of
itself
the
change.
The
internal
change
whereby,
whereby
we
implement
thread-safe
function
using
threads
in
function,
X
is
a
super
major
right.
So
if
we
so
you
know,
if
we
we
could,
we
could
split
the
to.
C
B
You
know
and
then
just
release
without
December
major
one
right,
but
then,
but
then
you
know
our
release
process
right
now
is
such
that
we
we
just
release
the
tip
of
Master,
so
we're
gonna
have
to
start
having
like
staging
branches
and
that
kind
of
thing,
if
we
starting
to
to
to
cherry
thick.
So
so
you
know
we
and
which,
which
is
something
we
should
have,
because
we
discussed
earlier
about
about
having
another
two
point:
X
release.
B
B
B
A
F
If,
like
mommy,
do
it
release,
we
wanted
to
do
assembler
minor
release
right
before
we
do
a
major
release
kind
of,
because
so
that
we
can
do
all
of
the
get
all
the
bug
fixes
out
before
the
any
of
these
yeah.
You
know
so
it
maybe
it
would
makes
sense
that
there
is
some
sort
of
long-running
semver
major
branch
that
you
know
all
features.
F
A
F
A
A
One
week
you
know
when
we,
when
we
drop
support,
we're
really
not
breaking
anything
right
like
we're
just
saying
like
we're,
not
changing,
we
don't.
We
don't
want
anything
which
changes.
The
API
is
in
the
breaking
way
right
right,
yeah,
we're
dropping
support.
We
may
be
forced
into
it.
Similarly,
I
think
it's
documenting
our
compiler
level.
Support
approach
makes
sense
because
I
don't
think
we
have
you
know.
So
we
could
be
explicit
that,
basically,
you
know
we
will
support
back
to
the
earliest
LTS.
B
D
B
A
B
Yeah
so
I
mean
yeah,
yeah,
I
think
I
think
for
now
that
the
yeah
you're
right
I
think
the
safest
course
is
to
just
is
to
just
leave
out
the
the
portion
that
does
the
reuse
and
then
I.
Just
have
the
duplicate.
I
mean
we.
We
have.
We
have
ample
code
duplication
anyway
in
some
places.
So
so
it's
just
yeah
my
stuff
somewhere
like
in.
A
B
If
you,
if
you
can
yes,
so
if
you
can
break
it
into
two
commits,
then
then
we
can
have
a.
We
can
have
a
PR
open
with
with
December
major
portion
of
it
and
and
and
maybe
maybe
leave
these
like,
like
a
to
do
in
the
in
the
code
pointing
to
the
URL
of
the
PR.
And
then
then
we
were
not
only.
We
will
not
only
be
aware
that
it
can
be
done
and
and
the
reasons
for
why
we
haven't
done
it,
but
we
will
also
have
the
recipe
for
doing
it.
You
know
yes,.