►
From YouTube: 2020-09025-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
A
A
I
have
access
to
the
machine,
so
that's
what
I
was
thinking
like,
I
might
even
clone
the
job
and
like
narrow
it
down,
so
we
can
easily
run
it
there
and
yeah.
That
was
kind
of
what
I
was
going
to
investigate
is
yeah.
If
we
can't
invest
locally,
which
seems
to
be
the
case,
you
know
if
it's
like
get
on
the
machine
and
run
it
it
just
recreates,
then
you
know,
let's
get
people
access
and
we
can
figure
that
out.
B
A
B
Yep
got
back
ports
for
12
and
for
10
going
all
approved.
All
they
need
to
do
now
is
land.
Oh
maybe
I
should
do
a
job
like
a
ci
for
for
12
as
well,
because
I
think
I
I
did
one
for
10
last
night.
Okay,
so
so
I
think
that's
still
out,
but
then
the
rest
is
just
is
up
to
the
up
to
the
releasers.
A
A
B
Not
yet
I'm
wondering
I'm
wondering
if
we
can
do
replace
me
in
the
matrix.
B
You
know
like
just
the
way
we
do
it
for
the
header,
I'm
not
sure
how
how
stringent
the
requirements
are
for
using
that
replacement
tag,
whether
it
only
works
in
the
in
the
metadata
or
whether
we
can
just
plop
that
anywhere
in
the
text
and
it'll
replace
it
with
the
right
version.
B
A
So
I
did
open
this
draft
pr
to
break
it
into
two
tables,
and
I
thought
it
would
be
good
to
spend
at
least
a
minute
talking
about
whether
this
is
a
good
idea.
There's
other
good
ideas,
because,
as
we
added
like
every
time,
we
added
one
to
the
right,
it
just
got
wider.
This
would
this
breaks
it
into
multiple
tables
so
like
this
first,
one
just
will
actually
stay
as
is
forever
now.
I
guess
other
than
this
growing
list
of
versions.
B
A
And
so
greater
than
equal
v10.x
yeah
I'll
change,
I'll
change
that
otherwise
does
this
look
reasonable.
B
A
B
That's
true
yeah,
I
mean
yeah
yeah
unless,
unless
they,
unless
they
use
them
in,
like
like
missile
launch
systems,
you
know,
I
don't
believe
we're
we're
gonna
be
worried
about
version
version
three
of
an
api
in
version
six
of
node.
A
Yeah,
so
that's
where
yeah
I
think
like.
Maybe
this
is
a
good
short
term
like
the
next
step
and
then
when
we
need
to
create
the
next
table,
we
could
actually
just
drop
the
first
one
put
it
in
an
external
link
or
something
okay.
So
it
sounds
like
generally.
This
seems
people
are
happy
with
this
I'll
make
that
one
change
and
then,
if
you
have
any
other
comments
or
thoughts,
just
jump
into
that
pr.
B
A
B
See
you
know
there
is.
There
is
one
sort
of
wider
issue
you
know
and
and
it's
it's
it's
sort
of
crystallized,
at
least
in
my
mind
because
of
this,
this
missed
back
port
with
the
with
with
exposing
the
the
napi
version
in
core,
and
that's
that
you
know
whatever
changes
we
make
to
an
api.
We
should
have
some
sort
of
mechanism
for
for
tracking
to
make
sure
that
they
were
in
fact
back
ported.
B
You
know
because
it's
it's
it's
unclear
whether
that
change
will,
you
know,
will
will
apply
cleanly
to
the
back
branch,
etc,
etc.
So
I'm
not
sure
how
to
do
this.
You
know
it
would
be
nice
to
have
sort
of
a.
B
I
don't
know.
I
guess
like
a
kanban
board
or
something
with
with
you
know
where,
where
all
the
napi
prs
are,
because
you
know,
unlike
unlike
other
changes,
other
changes
are
not
so
much
concerned
about
back
porting.
You
know
unless
there's
a.
A
B
A
I
don't
know
that
we
always
have
to
get
into.
They
have
to
be
back
party,
but
I
think
it's
it's
it's
good.
I'm
wondering
if,
like
that,
one
is
kind
of
a
like.
We
have
a
process
which
I
think
covers
api
editions
reasonably
well
because,
like
they're
experimental
and
then,
if
we
actually
want
to
make
a
version
like
we,
you
know
we
have
an
issue
like
this,
it's
more
like
that
was
exposing
another
way
to
get
at
what
was
the
version
that
was
supported.
A
B
Yeah
but
I
mean
you
know,
we're
we're
distinguishing
now,
but
but
you
know
when
one
of
these
foundational
changes
comes
along,
if
ever
you
know,
are
we
going
to
get
hit
by
it
again?
You
know.
B
B
But
I
guess
I
guess
if,
if,
if
prs
in
core
are
tracked
reasonably
well
using
the
label
napi,
then
we
should
be
able
to
occasionally
go
in
there
and
just
just
do
it,
and
so
so,
if
we
have
that
issue
open,
maybe
even
add
it
to
the
milestone.
Then,
even
if
we
do
nothing
at
each
meeting
at
least
it'll.
C
B
Sort
of
you
know
snap
its
fingers
at
us
saying
yo.
Maybe
you
should
go
in
there
and
start
updating.
You
know.
A
B
A
Okay,
because
yeah,
I
know
I
could
see
that
and
like
I
think,
with
right
now.
The
napi
team
is
that
mentioned
on
each
of
the
the
the
napi
prs
so
and
there's
a
little
check
box
for
like
somebody
from
the
api
team
is
taking
a
look.
So
hopefully
one
of
us
will
notice
that,
and
we
can
use
this
then
to
say:
okay,
if
we
see
one,
we
think
needs
to
be
backboarded,
we
can
throw
it
onto
this
issue
sounds
good
and
I
think
like
what
I'd
suggest
is
that
we
edit
this.
B
I
can
probably
add
things
offline
because
I
mean
we've
got
the
napi7
stuff
going
on
and
and
we've
got
the
back
part
of
the
an
api
version.
Variable
exposure,
but
that's
about
it.
A
A
Yeah
tracking
issues
for
modules
we've
noted
have
been
backported.
A
Just
to
keep
an
eye
on
downloads
that
still
seems
to
be
has
been
going
up
over
two
million,
which
is
good.
That's
definitely
a
substantial
amount,
the
node
confu
workshop
proposal-
I
don't
know
jim
if
you've
heard
anything
on
that
one,
not
so
far.
Michael
okay,
enable
debug
testing
for
add-ons.
I
haven't
had
a
chance
to
look
at
that,
so
I
don't
think
there's
any
progress
yet
burning
down
this
the
list
of
issues.
A
A
A
B
Yeah,
that's
probably
sitting
there
for
a
while
yeah
yeah,
it's
it's
kind
of
it
needs.
It
needs
a
lot
of
work
now
because,
because
I
I
did
add
the
asynchronous
running
of
the
tests
so
now
now
the
the
this
infrastructure
sort
of
clashes
with
that
infrastructure.
So
I'm.
D
A
B
A
B
I
believe
we
may
have
addressed
some
of
this
stuff
because
because
we
did
have
no
wait,
no,
this
is
this
is
never
mind,
never
mind
this,
isn't
about
the
failure
of
the
constructor.
B
We
did,
we
did
have
a
pr
that
that
addressed
multiple
inheritance,
so
so
and
we
we
had
to
change,
we
had
to
change
how
we
cast
things
and
and
how
we
called
the
the
the
native
equivalent.
If
I
remember
correctly
so
I
believe
I
I
believe
that
this
may
have
been
addressed
in
in
in
a
different
pr.
B
Yeah,
I
I'd
have
to
go
back
in
and
and
compare
this
change
with,
with,
with
that
object,
wrap
fix
that
that
we
landed
a
while
back
that
addresses
the
issue
of
multiple
inheritance
of
an
object
wraps
up
class.
A
Right,
I
think
this
was
good
too,
because
it
was
non-breaking
right
like
basically
it
like
you,
you
needed
to
define
nappy,
safe
or
unwrap
right,
which
is.
B
Yeah
well,
it's
the
conflict
is
probably
because
I
split
the
I
split.
The
object.
Wrap
class
into
instance
wrap
an
object,
wrap,
that's
probably
where
the
conflict
is
coming.
So
some
of
these
some
of
these
methods
are
now
located,
in
instance,
wrap,
and
so
the
changes
need
to
apply
to
a
different
class
that
might
be
what
broke
things.
A
B
Not
in
principle,
but
I'd
have
to
review
again,
I
I
don't.
I
don't
think
I
have
any
objections,
maybe
maybe
asking
for
changes
but
nothing
substantial.
B
A
B
A
A
Well,
I'd
have
to
I
don't
yeah.
I
have
to
look
at
it
again
to
see
see
if
we
can
think
about
that.
So
that
was
in
pull
requests
issues.
A
B
This
no
except
stuff
reminds
me
that
we
should
probably
add
no,
except
to
to
all
the
all
the
function,
all
the
symbols
that
we
define
that
are
passed
into
an
api
because
those
symbols-
they
are
plain
c.
They
have
to
be
right,
even
if
their
names
are
mangled.
Their
signature
is
plain
c
and
therefore
they
cannot
throw
exceptions.
So
any
and
all
exception
handling
has
to
be
done
inside
those
symbols.
Therefore,
it
is
safe
to
mark
them
as
no,
except
precisely
because
our
interface
with
node.js
is
a
plain
c.
B
Yeah
all
the
ones
that
are
that
are
bracket,
nappy
and
and
comma
nappy
callback
info
info,
all
those
that
have
that
signature.
They
can
all
be
marked
as
no,
except
because
they
are
playing
c
functions
and
and
they
are
passed
into
what
looks
like
a
plain
c
library.
So
there
cannot
be
exceptions
because
they
they
have
no
place
to
go.
A
B
Well,
but
but
yes,
but
for
performance
reasons,
I
think
adding
the
no
accept
is
worth
it
right.
Okay,
so
so
then
so
then
I
mean
yes,
then
that
would
be
the
job
of
whoever
proposes
the
wrapping
to
to
remove
the
no
except.
B
Well,
well
conceptually
correct
me:
if
I'm
wrong
as
long
as
at
the
boundary
between
node.js
and
the
add-on,
there
is
the
the
function
that
constitutes
the
boundary
is
no
except
right.
Then,
then
anything,
that's
behind
that
function.
Anything
that
that
function,
calls
can
can
be
hand,
can
can
have
exceptions
for
all
it.
For
for
all,
it
cares
because
the
function
that
constitutes
the
boundary
has
to
handle
all
any
and
all
exceptions
because
past
the
boundary
it's
it's
all
c
right.
So
there
cannot
be
any
exceptions
currently
that
boundary.
B
A
A
B
Me
well,
they
can't
they
can't,
but
it'll
be
ugly
if
they
do
right,
because
I
I'm.
If
I,
if
I
understand
the
exceptions
correctly,
if
they
throw
exceptions,
it
will
just
it
would
be,
they
would
be
considered
unhandled,
even
though
on
the,
even
though
on
the
on
the
node.js
side,
they,
you
know
the
the
napi
implementation
could
be
backed
by
c
plus,
which
can
handle
exceptions,
but
because
there
is
that
break
in
between
right,
they,
they
will
still
end
up
unhandled.
A
A
B
It
and
besides,
we
now
have
multiple
implementations
of
an
api.
So
if
anybody
chooses
to
use
node
on
api
against
a
different
implementation
which
doesn't
handle
exceptions
on
on
the
on
the
core
side,.
A
B
A
B
C
Yeah,
no
that's
on
no!
No,
no,
not
in
core
yeah
right,
because.
A
A
It
okay
sounds
good
any
other
of
these.
That
people
think
we
should
talk.
A
I
don't
know
through
your
work
on
things
like
jury
script,
for
smaller
things,
gabriel.
If
you
had
any
run
across
that
kind
of
casting.
B
A
B
B
Because
there
is,
there
is
no,
there
is
no
way
to
retrieve
the
current
async
context,
and
so-
and
that
makes
sense,
because
you're
coming
in
without
you're,
coming
in,
without
without
a
like,
a
node
stack
right,
which
is
why
you're
calling
make
callback
is
because
you're
coming
in
sort
of
raw
and
so
which
it's
in
context
to
pick
is
kind
of
a
degree
of
freedom
right
like
okay,
but
you
know
we
cannot
decide
on
their
behalf,
which
async
context
they
are
to
be
part
of
if
they
come
in
without
one
okay.
B
So
I
guess
it's
the
best
best
practice
to
always
maintain
an
async
context.
If
you're
going
to
be
using
make
callback
and
the
documentation,
I
think
comments
to
that
effect.
A
Okay,
this
is
the
thing
here
like
gabriel,
I
guess
you
know,
when
anyone
or
or
others.
C
C
B
Oh,
I
I
noticed
this
new
tag,
this
request
ci.
What
does
that
mean
that.
A
B
A
Mary's
been
doing
some
great
work
in
the
automation
side
and
that's
one
of
the
things
she
put
in
place
so
that
you
just
do
that
it
will
do
the
and
I
think,
there's
there's.
I
have
to
go
check.
The
commit
cue
she's
also
been
doing
work
to
make
it
so
that
there's
a
tag
to
actually
land
things
as
well,
so
like
yeah,
exactly
yeah
okay,
so
I
don't
see
anything
else.
Newish
that
jumps
out
there.
Let's
look
in
pull
requests.
A
Okay,
so
I
don't
see
anything
there
to
talk
about
anything
else
that
people
want
to
discuss.
B
I
have
one
thing
so
for
for
this,
for
my
work
with
web
gpu
and
api,
I
started
working
on
on
like
this
web
idl
2n
api
code
generator
and
I'm
I'm
trying
to
find
a
home
for
it,
and
so
I
wanted
to
sort
of
float
the
idea
that
maybe
you
should
live
off
the
node.js
organization,
and
so
I
just
wanted
to
get
your
thoughts
on
on
whether
I
should
ask
for
there
to
be
a
repo
off
of
node.js
called,
like.
B
Maybe
I
don't
know,
web
web
ideal
dash
and
api
and
just
put
the
put
the
code
there
and,
and
you
know
start
having
people
contribute,
because
it's
it's
quite
a
chunk
of
work
to
do
all
of
web
web
idl.
B
Why
I
wanted
to
get
it
out
there
and
and
by
what
means,
should
I
get
it
out?
There
is
the
question.
A
B
Yeah
so
yeah
I
mean
I
I
could.
I
could
also
probably
put
it
under
intel
and
then
it
will
be
there,
but
it's
kind
of
an
api
related
thing
right.
So
yeah.
C
B
A
Yeah,
I
don't
have
any
objection,
I'm
just
not
sure
whether
it's
like,
if
somebody
else
came
to
us
and
said,
hey,
I've
got
another
rapper.
Would
we
like
immediately
say
yeah
put
it
in
the
node.js
or
right.
A
B
A
B
B
B
Yeah
yeah,
I
like
the
thing
is,
though,
like
if
I,
if
I,
if
I
put
it
under
intel,
eventually
right,
because
you
can't
stay
under
my
name
forever.
If.
A
B
B
A
A
If
people
think
it,
you
know,
you
can
explain
what
it
is
and
how
it's
tied
to
napi
and
you
can
and
so
asking
there
that
people
think
like
as
again,
it's
not
like
to
date,
all
the
ones
that
have
been
going
in
there
have
kind
of
been
being
worked
by
the
package
maintenance
team
and
are
related
to
helping
the
manage
the
package
sort
of
ecosystem
side
of
things
right.
But.
A
B
A
A
So,
like
the
one
I've
I've
worked
on,
there
is
support
which,
which
you
know
the
package
maintenance
team
is
you
know
proposing
that
people
add
to
their
module,
support
information,
yeah,
okay,.
A
Well
like
this
is
the
kind
of
things
we've
been
working
on
where
it's
like.
Okay,
you
know
it's
like
hey.
Will
changes
in
my
re
in
my
package
afford
other
break
other
packages.
Support
info
info
helps
display
and
validate
support
info,
which
is
something
we're
you
know
advocating
to
put
in
to
your
package.
Json
status
board
is
like
hey.
B
Well,
I
mean
this:
is
you
know
this
is
a
a
tool
that
people
would
use
in
their
in
their
binding
jib.
That's
you
know,
because
you
would,
you
would
add,
an
action
in
your
binding
jib
or
a
rule
that
that
tells
that
tells
the
tool
chain
how
to
convert
dot,
idl
files
into
into
dot
cc
files
right.
So
so
it
is.
It
is
kind
of
a
tool
chain
item,
and
so
yes,
it's
it's
for
packages
which
ship
native
add-ons,
so
that
that
that's
how
I
see
this
being.
B
B
No
jib
right,
it's
it's
kind
of
right,
it's
kind
of
a
it's,
a
tool
that
is
being
used
from
nodejib
yeah
right.
It
would
be.
A
B
A
And
that's.
B
B
Yeah,
I
was
gonna
say
like
I
can.
I
can
do
like
like
I
can
do
like
a
proposal
in
the
admin
repo
and
I
can
show
like
how
this
would
look
in
the
binding
chip
and
and
that
kind
of
thing,
because
you
know
I
I
have
like
a
test
which
shows
illustrates
how
you
would
use
this
tool,
and-
and
so
I
can.
I
can
give
that
test
as
an
example
in
in
the
opening
comment
in
the
admin.
A
B
Them,
okay,
yeah,
so
yeah,
so
currently
so
far
for
it
arguments
for
that,
we
have
the
fact
that
it's
being
used
from
nodejib
the
fact
that
it's
tied
very
closely
to
an
api
yeah
right
because
it
it
does
produce-
and
it
is
c
right
now,
like
I
I'm
doing
c
and
api
calls
rather
than
c
plus
plus
ones,
even
though
it
would
probably
be
a
better
fit
just
because
I
I
want
to
have
like
the
lowest
common
denominator.
B
C
B
B
Right,
you
know,
but
the
the
signatures
themselves
I
think
for
for,
given
that
this
is
coming
from
web
gpu
and
given
that
that
the
the
the
google
person
working
on
the
spec
said
that
it's
a
fairly
chatty
protocol.
I
was
thinking
that
we
should.
We
should
not
wrap
the
functions
any
further
than
they
need
to
be
because
it's
already
pretty
expensive,
going
between
js
and
and
c
or
c,
plus,
plus
right
now.
So.
A
The
other
thing
I'm
thinking
is
like
just
about
to
get
approval
is
the
concept
of
collaboration
spaces
under
the
openjs
foundation
and
actually
like
web
gpu,
like
our
gpu
support
for
node
could
be
one
of
those
like
do
you
think?
That's
a
space
where,
like
you
know,
you're
collab?
Is
it
just
something
you're
working
on
on
your
own,
but
are
you
collaborating
with
other
people
and
there's
a
spec
and.
C
B
Idle
right,
I
I
seek
not
to
concern
myself
with
web
gpu
other
than
using
the
their
web
idl
declaration,
like
the
declaration
of
the
web
gpu
api
as
an
input
for
for
my
project,
so
that
I
can
handle
all
the
cases
right.
But
web
ideal
in
principle
is
not
in
any
way
tied
to
web
gpu.
It's
tied
to
like
w3c
specs,
javascript,
api,
specs,
right
and.
C
B
So
you
know
the
final
goal
of
the
project
would
be
to
be
able
to
generate
an
api
bindings
for
all
web
ideal
files,
whatever
they're
concerned
themselves
with
whether
they
expose
sensors,
whether
they
expose
sockets,
whether
they
expose
hardware
doesn't
matter,
you
should
be
able
to
generate
that
api
code
for
any
of
those
specs.
So
in
that
sense
it's
independent
of
web
gpu
right,
but
right,
the
the
the
initial
impetus
for
doing
this
was
coming
from
web
gpu.
B
So
it's
yes,
I
mean
you
know
we
are
concerned
with
with
web
standards
right
at
node.js,
so
so
in
that
sense,
in
that
sense,
since
most
w3c
javascript
apis
are
described
in
web
idl
having
a
web
idl
compiler
would
be
a
sort
of
a
good
thing
right
right.