►
Description
A
E
E
F
Hey
so
I
don't
have
much.
I
did
do
another
round
of
questions
with
chakra
dev
contact
just
to
ensure
that
if,
if
the
change
to
the
grammar
was
was
and
was
accepted,
as
I
expect
change,
would
that
be
any
different
or
more
complicated
than
just
going
offering
an
own
specific
API
and
the
results
were
no.
It
shouldn't
be
any
more
difficult,
at
least
on
the
gut
check
level.
So
that's
good
news.
That's
it.
H
I
added
linux
12
the
regression
jobs
and
watched
her
issues,
but
it
seems
to
be
all
good
and
master
next
step
is
to
add
linux,
one
to
the
nightly
releases.
So
look
at
that
next
week,
chasing
down
a
few
AIX
build
breaks
and
test
failures.
We
had,
I
think,
two
things
that
call
caused
it
to
stop
building
and
then
once
got
those
fixed.
H
It
seems
are
some
things
causing
actual
test
failures
now
that
it
builds
again
so
chasing
those
down
continued
work
on
the
a
bi-stable
module
api
in
scheduling
of
the
next
api
working
group,
meeting,
miscellaneous
PR
issue,
reviews
and
pull
requests
working
on
the
post-mortem
work
with
Richard
and
trying
to
schedule
the
next
meeting
to
get
to
group
together,
a
small
update
to
the
benchmark
graphs
just
to
indicate
whether
high
or
low
is
better,
and
that's
generally,
you
know,
reading
through
the
issues
and
keeping
up
to
date
with
them.
I
next
is
bright,
white.
I
A
So
this
morning,
I
on-boarded
Bart
leave
his
last
name
is
says
now:
ski
works
with
Alexis
and
and
while
stuffs
happening
here
and
right
and
the
other
thing
I've
been
working
on,
is
trying
to
chase
down
the
test
net
right,
slow
thing,
that's
failing
on
freebsd
a
ton
and
on
CI
and
I
have
a
PRN
for
fix
its
PR
number,
seven,
five,
five
five.
I
would
love
to
get
that
landed
sooner
rather
than
later.
So,
if
you
have
a
second
to
review
it,
please
do.
A
M
Ok,
we're
going
on
some
PRS
I've
worked
in
the
URL,
whatever
URL
implementation
got
that
stuff
in
up
and
running
or
passing
all
of
the
standard,
parsing
tests
and
all
but
two
of
the
sitter
tests
in
those
two
that
we're
not
or
very
very
minor
I.
Think
that's
ready
for
broader
review
would
love
to
have
folks
on
take
a
good
look
at
that
other
than
that
just
kind
of
closing
up
some
other
other
two
dues
before
going
on
vacation
on
friday,
I'm
going
to
be
again
available
for
at
least
a
week.
A
A
E
G
B
E
A
E
G
E
A
A
M
Like
it
is
so
we
have
a
number
of
issues
that
have
come
up
with
2013
support
and
those
bends
run
into
some
things.
I'll
run
into
some
things,
we've
just
not
compile
errors,
and
there
have
been
a
number
of
issues
on
going
with
native
ad
on
where
the
current
recommendation
is
to
try
to
build
against
2015
possible.
I
know
that
there
are
some
out
there
that
do
require
2013,
but
we
really
want
to
try
to
encourage
people
to
update
upgrade.
M
J
Also,
at
some
time
you
in
this
issue,
I,
don't
have
a
problem
with
up
in
vs,
2013
porno
film,
definitely
to
support
a
don't
drop
in
support
in
v6.
It's
a
bit
risky
in
that
it
would
be
a
breaking
change
for
some
modules
out
there
and
we
need
to
need
more
time
to
assess
the
potential
impact.
There
is
an
API
incompatibility
with
10
local
storage
that
has
impacted
notes,
ass.
J
M
Think
I
think
at
this
point
in
my
significant
number
of
unknowns
at
the,
and
we
would
probably
split
the
conversation
one
would
we
want
to
drop
to
the
age
of
13
is
a
December
major
change
in
V?
Seven,
all
right!
That's
the
first
conversation.
Second
conversation
is
what
we
want
to
do
it
to
go
up:
yessir
2013
in
b6,
before
good
LTS,
I'm.
M
A
So
I
think
the
first
conversation
is
pretty
uncontroversial.
I,
don't
think,
am
I
mistaken
I,
don't
think
anybody's
in
the
github
issue
has
has
said
we
shouldn't
drop
it
for
v7.
Is
that
right,
think
you're,
correct
right
and
then
the
issue
for
and
then
the
second
conversation
is
really.
We
need
to
gather
information,
because
if
we
can
find
a
way
to
use,
you
know
nan
or
whatever
to
to
not
break
it.
A
It
sounds
like
I
mean
I
mean
I'm
I,
don't
need
to
like
be
the
bull
in
the
china
shop,
but
I
want
to
get
through
as
many
of
these
issues
as
possible,
and
it
seems
to
me
like
the
first
conversation,
we
know
what
we're
going
to
do
and
the
second
conversation
we
can't
really
decide
without
gathering
more
information.
So
maybe
we
should
talk
about.
The
second
have
a
second
conversation.
Next
week
after
you
know,
Joelle
or
whoever
is
looking
at
the
issue
Alexis
or
whatever
can
has
gathered
the
information
required
to
make
up
sound
decision.
A
A
A
Games
or
games
tagged
it
and
rod.
Rod
left
a
note
that
said
disc.
Last
week,
that
said,
we
discussed
at
the
ctc
meeting.
Trevor
Norris
is
working
on
the
option
chosen,
which
is
keep
the
new
behavior
and
add
logic
to
handle
new
and
unexpected
errors,
ignoring
the
fact
that
other
methods
in
FS
can
cause
an
e
loop
error
and
yeah.
So
I
guess
it
says,
leaving
it
on
the
CTC
agendas,
who
have
some
pressure
to
resolve
it.
So
I
guess
we
should
just
get
a
status
report,
maybe
from
Trevor
does
that
work.
L
Sure
it's
working
I'm
just
adding
a
test
right
now.
There
is
a
there's
one
thing
where
it
will
fail
after
curses,
which
is
is
that
it
did
before,
though,
I
feel
like
the
number
of
times
it
fails
or
number
of
times
it
will
recur
sin
before
failing
those
kind
of
arbitrary.
So
we
like
comment
on
that
and
also
I,
don't
know
right
now.
L
The
number
of
siblings
in
a
single
resolve
of
the
path
is
32
because
of
an
OSX
header,
I,
don't
know
if
we
want
to
make
it
platform
dependent
and
pull
in
the
like
the
maximum
number
of
siblings
that
can
resolve
at
a
given
time,
based
on
what
platform
is
running
on
or
whether
we
just
want
to
cut
it
at
32.
But
comments
on
the
PR
welcome
is
working,
as
is
right
now.
A
A
F
Sweet
okay,
so
this
is
the
this
was
brought
up.
The
previous
meeting
and
given
time
to
simmer
the
the
gist
here
is
to
replace
the
section
5.1
of
the
es
module
proposal
for
node,
which
was
the
file
extension
dot
MJS
with
unambiguous
javascript
grammar.
The
poor
request
is,
is
open
on
no
DPS.
Its
number
33
and
rod
expressed
wanting
to
have
a
vote
this
week,
if
possible,
on
merging
that
pull
request.
So
y'all
should
have
reviewed
it
by
now
and
that's
what
that's
about
yeah.
A
F
A
A
E
B
J
A
A
L
M
A
L
Is
it
as
far
as
I'm
concerned?
It
is
an
agreement
that
if
it
gets
implemented,
this
is
what
it
will
look
like
and
so
I
can
begin
the
dude
finishing
the
implementation
got
it
goes.
There
are
some
questions
like
well.
How
do
I
eternal
promises?
We
are
waiting,
you
know
for
additional
API,
so
it
can
do
so,
but
that
works
more
in
parallel.
We
shouldn't
have
to
wait
for
that
to
be
implemented
before
the
rest
of
the
async
wrap.
Api
can
be
put.
A
In
so
theoretically,
someone
could
find
you
know
in
the
end
the
one
issue
said
yet
you
know
it
endorse
the
CPS
and
say
yes,
if
we're
going
to
implement
it.
This
is
the
way
we
should
implement
it,
but
also
be
sympathetic
to
who
the
points
been
raises
that
maybe
they
shouldn't
be
implemented
at
all.
Those
are
not
actually
contradictory
views,
they're
kind
of
related,
but
orthogonal
yeah.
A
L
Now
the
yep
it's
as
far
as
voting
on
it,
the
biggest
missing
chunk.
Almost
everything
else
is
just
fix
up
for
clarifications.
The
missing
chunk
is
the
public
API,
which
I
almost
have
hammered
out.
The
issue
is
that
facing
crap
relies
on
internals
and
on
the
c
plus
plus
side,
it's
difficult
to
simultaneously
expose
the
c++
class
that
can
hook
into
a
sink
rep
and
not
expose
the
things
that
shouldn't
expose
so
work
on
that
I'm
just
about
there
and
then
once
I
have
a
proof
of
concept,
all
I'll
break
it
up,
but.
L
Whether
we
want
to
wait
for
that
or
whether
I
put
that
in
a
different
IP
I'll
leave
up
to
everybody
else
again.
This
is
a
large
amount
of
work,
so
I,
don't
I
feel
like
it's
not
an
issue.
If
those
two
parts
were
broken
up
for
for
discussion,
because
I
feel
like
public
API
in
and
of
itself
would
beat,
will
be
lengthy
discussion
just.
L
C++
is
the
major
part.
There
are
some
minor
parts
of
the
couple
things
in
the
JavaScript
API.
For
example,
there's
the
issue
of
batched
calls
which
people
have
pointed
out
and
I
have
a
fairly
simple
solution
for
that
on
the
c++
on
the
JavaScript
side,
so
be
very,
very
minimal,
John
scrapy.
The
key
part,
is
the
C++
API.
E
E
I
think
I
think
it
should
be
kept
in
mind
that,
like
the
stuff
still
could
come
up
doing
implementation
and
like
this
API
could
potentially
like
minor
they
change
from
here.
So
it's
not
like
frozen
thing.
Anything
like
stuffed
full,
if
it
were
to
be
shipped
stuff
would
probably
be
added
to
it
in
the
future.
So.
L
A
M
L
So
I
believe
we
can
land
it
in
six
before
six
goes
LCS
and
if
this
gets
voted
in
I'll
be
able
to
begin
the
implementation
of
what
it
has
for
the
so
it
can
land
in
six
before
six
pose
as
you
guys
that,
though,
that
also
how
how
this
handles
promises
does
depend
on
what
v8
does
in
terms
of
prime
promised
support
and
opening
up
the
black
box
of
promises
to
the
API
and,
unfortunately,
that
will
probably
come
in
a
future
version
v8
that
we
cannot
land
in
v6.
So.
E
Yeah
I,
don't
know
I'd
kind
of
like
to
go
ahead
with
this
I
think
I
think
async
rough
is
probably
a
best
bets
so
of
the
entire
CLS
across
a
sink
activities.
Potential
future
domain
replacement,
etc.
That
were
going
to
get
considering
trevor
has
experimented
this
stuff
with
this
stuff
for
a
very
long
time.