►
From YouTube: Diagnostics WG Meeting - 2018-02-07
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
B
A
Okay,
limine
monkey-patching.
I
think
there's
been
no
activity
on
that
that
I
am
aware
of
I
thought
we
have
some
general.
You
know
idea
for
how
to
approach
it.
I
think
now
it's
just
a
problem
for
an
issue
of
you
know
finding
the
right
people
to
execute
on
that,
and
maybe
that's
something
we
can
bring
up
at
the
diagnostics
summit.
A
A
B
I
think
that
was
a
idea
that
Benedict
had
and
I
think
that
that
one
is
pretty
much
closed
at
this
point
and
to
give
a
background
people
who
not
aware
so
one
of
the
things
we've
been
finding
is
that
promise
hooks
are
quite
expensive
out
of
all
the
ascend
cooks
and
enabling,
but
them
by
default
is
something
that
no
h8
doesn't
do.
When
you
enable
AC
cooks
promise
hooks
are
not
a
name
when
you
load
a
sink
Oaks
pomace
hooks
are
not
enabled
by
default.
B
You
have
to
add
a
hook
in
order
for
the
promise
work
should
be
enabled
so
I
think
Benedict
is
looking
at
overall
promise,
performance
and
I.
Think
there's
some
work
happening
and
I.
Think
one
of
the
things
to
keep
track
of
going
forward
is
working
with
the
VA
team
to
come
up
with.
Maybe
some
changes
to
the
promise
works
API
so
that
make
it
more
amenable
for
performance
and
I.
B
C
Right,
so
maybe
I
can
elaborate
a
little
bit
on
this.
One
idea
that
Benedict
had
and
the
threat
is
already
closed,
was
to
make
promises
man
compatible
in
that
the
resulting
promise
of
an
a
sync
function
call
can
be
overridden
to
you
know,
do
additional
things
like
tracking,
and
that
would
be
all
in
JavaScript
instead
of
you
know,
having
to
call
into
C++
and
pay
the
cost
of
doing
that.
But
it's
not
entirely
clear
whether
that's
feasible
or
whether
that
can
be
put
up
for
specification,
a
tc39,
because
we
expect
some
pushback
one.
C
B
C
C
C
I
see
yeah.
That
would
also
make
sense,
because
then
you
also
save
going
back
and
forth
between
JavaScript
and
C++,
but
the
issue
here
is
that
the
the
reason
we
like
what
we
do
in
C++
is
also
creating
a
weak
handle
on
the
promise
so
that
we
get
to
the
strive
event
right
and
I,
don't
know
whether
that's
feasible
with
a
JavaScript
implementation.
B
Going
forward
so
I
was
discussing
this
with
Benedict
I
think
it
would
be
good
to
me
open
up
tracking
issue
for
performance
and
then
explore
the
ideas,
and
some
of
the
points
you
blaze
are
valid.
I
think
it
would
be
really
useful
to
have
real
world
impact
numbers,
so
people
are
using
I
know
some
of
the
APM
vendors
are
already
using
async
hooks
and
if
they
have
feedback
from
real
world
customers
that
they
can
share
on
how
much
it
was
of
performing
impact.
The
C.
A
D
Reached
out
to
Thomas,
but
he
didn't
I,
think
he's
quite
busy
right
now,
working
somewhere
in
abroad,
but
I
will
think
with
him
Dennis's
agnostic
summit,
because
my
problem
I
need
a
tool
that
at
the
same
time
using
useless
Asian
cooks
and
also
measures
performance
them
on
this
API
I
have
because
everything
else
would
kind
of
have
side
effect,
so
I'm
hoping
for
his
version
and
to
run
tests
against
them.
Yeah.
C
E
Can
I
ask
a
quick
question
and
I
don't
know
if
I
don't
quite
understand
this
or
it's
still
an
open
issue.
Do
we
understand
is
where
the
performance
overhead
is
coming
from?
Is
it
this
native
managed
boundary
crossing
like
the
innate
destroy
part?
Is
it
tracking
the
you
know,
callback
part?
What's
what's
sort
of
the
high
cost
its
popping
up
so.
C
C
B
C
E
C
So
I
am
not
all
that
familiar.
There
was
the
latest
spec,
because
last
time
I
looked
at
the
implementation
was
quite
a
while
ago,
but
so
Benedict
did
looking
into
it
and
I
think
there
were
a
lot
of
things,
because
the
JavaScript
is
fairly
descriptive
on
which
steps
to
take
and
and
v8
doesn't
alight
any
of
those
promises.
Currently
I
guess.
B
E
D
B
A
B
B
A
The
other
thing
I'll
throw
out
is
I
wonder
if
it's
possible-
and
this
doesn't
need
to
be
answered
now,
but
I'll
just
throw
it
out
on
that.
We
can
track
contacts
without
calling
through
these
various
api's
right
I'm
like
Ian
it
and
destroy
and
begin
and
end
api's
right,
and
if
that
would
make
this
faster,
because.
A
D
A
B
Problem
I
see,
is
that
you
think
a
rate
is
you
cannot
I
mean
purely
in
user
land
or
embedder
or
host
land?
You
cannot
know
when
a
when
a
promise
resumes
after
Ana
wait.
So
if
you
wanted
to
propagate
context
into
the
resumption
of
a
wait,
that
is
not
currently
possible,
as
per
the
spec.
So
that's
why
I
promised
Roxanne.
He
did
because
you
think
of
Aleen.
You
cannot
keep
track
on
me.
E
E
So
it's
like
I
think
async
hooks
sort
of
captures,
two
things:
it
captures
async,
propagation
and
async
object,
lifetime
and
they're
combined
in
that
one
API
and
you
know
maybe
it's
maybe
it's
not
clear
if
they
need
to
be
in
the
same
API
or
there
should
be
some
ability
to
pick
which
parts
of
the
async
I
don't
know.
World
you're
interested
in
yeah.
B
And
actually
Benedict
has
been
asking
on
Twitter
and
elsewhere
one,
but
they
have
people
have
valid
use
cases
for
for
the
destroy
hook
and
people
do.
But
your
point
is
definitely
valid.
That
may
be
both
at
the
same
time
doesn't
make
sense
right,
so
life
time
is
more
related
to
resources
and
basic
the
automatic
cleanup
of
resources
and
header
propagation,
whereas
context
propagation
probably
doesn't
mean
the
destroy
book,
and
that
would
definitely
help
making
some
of
the
performance
impact
lower
and.
E
A
G
G
I
would
like
to
add
that
icing
cooks
under
pins
domains
from
master
the
domain
module
the
domain
module
is,
unfortunately,
even
if
it's
deprecated
still
very,
very
much
used
in
the
enterprise
work
so
which
means
that
everybody
will
be
impacted
by
as
in
coops
in
one
form
or
another.
In
no
time
in
the
next
LTS
version.
G
F
B
B
G
B
A
B
A
C
A
F
The
other
thing
I
did
is
I
did
make
a
reservation
on
a
pub.
That's
walking
distance
away
for
dinner,
we're
all
on
our
own
for
dinner,
but
I
think
we
can
go
to
the
same
place.
I
have
lunch
coming
in
on
the
two
days
and
then
like
coffee
tea
in
the
morning,
but
not
a
breakfast
I,
don't
know.
If
there's
anything
else,
people
can
think
of.
F
Checked
out
the
room,
we
should,
you
know
we're
at
we're
at
25
people
and
the
room
could
hold
and
I've
got
food
for
25
people
coming
the
hope
the
room
could
hold
a
few
more
people,
so
we'll
all
have
seats,
which
is
good,
I,
don't
know
if
there's
any
when
you
get
there,
it's
actually
on
the
left.
So
there's
security
and
that's
on
the
left.
Oh
I'll,
get
there
early
that
day,
I.
My
understanding
is,
you
know
nobody
actually
has
to
sign
in
because
it's
outside
of
the
main
building.
F
F
That's
got
multi
levels
you
can
go
into
or
if
you
want,
or
as
visitors,
there's
even
a
little
bit
of
visitor
parking
out
front
and
it's
the
executive
briefing
center,
which
is
kind
of
like
outside
I,
don't
know
if
anybody
else
will
be
in
there,
but
there's
multiple
rooms,
and
so
if
there
isn't
we'll
be
able
to
spread
out,
but
otherwise
we
have
the
largest
room.
That
bolts,
you
know,
it'll
hold
all
of
us
fairly
comfortably.
A
E
F
H
Sorry
would
it
be
possible
to
get
like
not
to
whaling,
cuz
I,
don't
think
I'll
be
able
to
physically
be
there,
but
there's
a
few
things
that
we
would
love
to
talk
about.
H
H
F
F
A
So
we
you
know,
Daniel
had
put
this
on
this
Google
Doc
up,
so
that
we
can
maybe
try
and
fine-tune
some
of
the
agenda.
I
took
an
action
I
to
try
and
do
that.
A
I'm
curious
people,
feedback
I,
just
took
the
the
post-mortem
tooling
and
I
tried
to
break
it
down
into
sort
of
the
you
know,
themes,
scenarios
what
are
the
desired
outcomes
and
then
just
sort
of
a
sketch
on
what
we
wanted
to
talk
about
and
I'm
open
to
feedback
on
this.
What
I
was
trying
to
do
here
was
just
get
something
a
little
bit
more
on
structured
than
what
was
there
before,
so
that
we
can
kind
of
move
things
along
and
not
lose
any
of
the
bullet
points
that
Michael
had
originally
put
together.
A
So
it
kind
of
felt
like
and
I
hope,
I
didn't
miss
anything.
There
was
sort
of
two
themes.
One
is
that
sort
of
the
current
set
of
tools
get
broken
and
there's
this
question
of
are
the
current
at
a
post-mortem
tools.
The
right
set
of
tools.
I
wanted
to
understand
what
scenarios
people
were
actually
trying
to
solve
with
post-mortem
tools,
and
you
know,
try
and
understand
that,
as
sort
of
like
you
know,
at
an
abstraction
level,
is
it
just
sufficient
to
understand
the
JavaScript
stack
and
and
JavaScript
heap?
Do
people
actually
need
to
understand?
A
F
Sorry
go
ahead.
The
other
discussion
which
I
can't
see
from
the
screen,
because
a
little
bit
small
is
that
sort
of
separate
I
think
is.
We
also
want
to
cover
the
like
what
level
of
integration
do
we
want
to
target
for
node?
Other
runtimes
will
have
built-in
support
for
a
number
of
these
things,
and-
and
you
know
we
should
agree
as
a
group,
you
know,
should
we
be
trying
to
integrate
node
rapport
support
for
core.
You
know
heap
dumps
or
you
know,
is
it
having
separate
modules?
F
A
So
I
thought
that
I,
maybe
I,
didn't
capture
it
like
one
of
the
things
that
you
know
as
I
sort
of
broke
it
out
into
some
discussion
points.
You
know
I
sort
of
have
the
short
term
like
how
do
you
keep
existing
tools
from
being
broken
and
I
thought
that
there
was
some
work
that
went
in
to
try
and
add
some
tests
to
prevent
that
exactly
sort
of
all
the
details
there,
but
then
longer-term
is
like
what
is
it
that?
A
What
is
it
that
we
that
that
you
would
want
to
provide
to
support
post-mortem
debugging
at
some
of
these
different
levels?
I
saw
that
there
was
one
issue
that
was
open.
The
post
mortem
work
working
group
around
with
some
JavaScript
level,
API
yeah,
you
can
possibly
you
know,
extend
the
C
RDP
protocol
and
then
you
can
have
a
nice
picture.
A
A
That
the
I
I,
don't
know
if
that
covers
I,
would.
F
H
Well,
the
overarching
themes
I
see
is
there's
a
lot
of
really
great
tools
out
there,
whether
it's
post-mortem
or
profiling,
or
whatever
else,
but
they're
kind
of,
like
you
kind
of
like
this
Venn
diagram
of
the
set
intersections
like
some
of
them
have
these
features,
and
some
of
them,
like
a
concrete
example,
would
be
like
if
I
were
to
use
a
chrome,
dev
tools.
Is
this
thing
with
retainers,
which
makes
it
really
easy
to
like?
H
H
H
F
Like
certainly
if
we,
you
know
I'm,
just
one
of
the
outcomes
of
the
discussion
could
be
hey
here.
This
here
are
some
use
cases
and
like
our
tasks,
first
task
is
identify
the
core
use.
Cases
then
go
through
and
say
you
know,
what's
needed
to
make
those
first
class
and
then
work
on
those
and
it's
sort
of
like
yeah,
okay
memory
debugging.
We
have
these
pieces,
but
we
don't
have
these
pieces.
Is
there
something
we
need
to
add
in
terms
of
API?
H
A
Priorities
right,
and
so
you
know,
as
as
a
discussion
evolve,
hoping
that
you
know
we
can
sort
of
drill
in
what's
needed,
serve
around
some
of
these
different
scenarios.
It
isn't
clear
to
me
that
low-level
tools,
like
you
know
like
what
is
it
ll,
note
or
MDB
PA,
are
necessarily
useful
to
sort
of
a
very
broad
audience.
But
you
know,
if
that's
not
the
case,
that
these
things
are
very
useful.
I
think
it'd
be
good
to
know
about
them,
but
that's
kind
of
what
I
was
hoping
to
walk
away
from
is
like
hey.
F
A
H
Mean
I
think
it's
just
organ
Amish
right
like
there's
a
couple
of
things,
I
mean
obviously,
when
you
start
with
a
diagnostic
yeah
Rahul,
but
like
I,
think
to
keep
it
to
not
to
final
point,
I.
Think
it's
like
right,
there's
ergonomics,
I
think
we
all
agree
like
using
command-line
kind
of
text,
input
or
debuggers
for
most
people
is
not
super
accessible,
but
I.
H
Think
at
a
lower
level,
though,
from
our
perspective
of
having
used
these
tools
for
years
and
how
critical
they
are
to
our
deployments
is
that
there
are
actually
just
features
that
are
missing.
That
really
makes
it
difficult
to
solve
a
very
big
class
of
problems.
We
see
all
the
time
and
I'm
right
in.
F
H
H
H
H
A
I
guess
the
rather
than
sort
of
going
into
the
specifics
of
the
post-mortem
stuff.
What
I
wanted
to
do
is
try
and
get
you
know
you
have
to
have
people
think
about
this
sort
of
the
the
framing
of
the
agenda
right
that
I
have
here,
which
was
you
know
just
what
are
the
themes?
What
are
the
scenarios?
What
do
we
want
to
walk
out
of
here
with
or
the
desired
outcomes,
and
then
some
bullet
points
to
sort
of
drive,
discussion
right
and
there's
some
overlap
between
these
different
things?
A
A
I
didn't
read
through
that
whole
thing,
so
I
didn't
kind
of
like
synthesize,
that
onto
the
level
that
I
synthesized
the
the
tooling
stuff,
but
that's
sort
of
what
I
was
hoping,
would
frame
the
discussion
a
little
better
and
maybe
make
it
a
little
more
positive,
I'm
open
to
feedback
on
this.
The
updates
are
in
that
doc
that
Daniel
had
put
in
there.
So
if
you
have
comments,
you
know
either
you
know
just
make
them
in
in
the
Google
Doc
or
you
know
or
ping
me
somehow.
H
But
notice
profiling
here
is
actually
I'm
tea,
witches,
which
is
I'm
glad
it's
on
the
agenda.
I
think
we
actually
have
we've
written
up
like
this
big
we're
about
to
like
post
the
github
issue
to
the
diagnostic
working
group,
with
kind
of
like
Hassan
profiling
I'm
like
a
role
map,
so
I
guess
we'll
do
that
after
this
meeting
and
then
we
can
drop
that
into
the
agenda.
Basically,.
H
A
H
F
A
A
Okay,
dan,
do
you
want
to
add
anything?
I'm
gonna,
stop
sharing
here,
that's
okay,
this
the
the
link
to
the
word
doc
is
just
here
in
this
issue
at
the
very
bottom.
So
you
know,
I
think
that
you
know
to
the
extent
that
we
can
have
a
little
more
structure
around
the
agenda.
I
think
it'll
sort
of
help
move
things
along
with
that
many
people
in
the
room.
So
you
have
ideas
or
teens
about
that.
Please
dive
in
there.
F
A
F
D
A
E
That
splits
out
the
notion
of
we
want
to
do
async
context,
tracking,
which
is
very
important
to
a
number
of
applications
like
long
call
stacks
or
these
other
types
of
things
as
one
category
of
information
we
want
to
track,
and
then
we
also
have
async
object
lifetime,
which
is
a
separate
sort
of
information
which
you
may
optionally
want
to
turn
on
or
off,
depending
on
your
application.
So
I
want
to
know
why
a
certain
callback
didn't
fire
well
I
need
to
know
you
know.
Was
that
object
even
created
was
it
destroyed?
Was
it
canceled?
E
You
know
that
sort
of
thing
to
support
those
scenarios.
So
at
this
point
in
time,
I
think
we
have
a
pretty
good
set
of
definitions
and
structure
around
async
lifetime
or
async
context
around
the
lifetime
concepts
we're
still
a
little
fuzzy
on
what
other
metadata
we
might
want
to
be
able
to
turn
off
and
on
in
tracking.
E
All
of
this
you
know
line
numbers
are
obvious,
maybe
call
stacks
if
you
want
to
pay
a
larger
cost,
but
others
are
maybe
a
little
more
fuzzy
and
then
I
think
we
need
some
examples,
but
otherwise
I'm
pretty
happy
with
the
structure
of
definitions.
We
have
and
I
think
it's
getting
to
the
point
where
you
know
we
can
start
experimenting
with
some
implementations
like
Mike
is
doing
just
assuming
we
have
a
magic
trace,
seeing
what
it
looks
like,
but
also
going
and
starting
to
prototype.
E
F
I
I
mean
I,
keep
meaning
to
want
to
do
that,
but
never
quite
gotten
there
is
it
something
where
you
think
like
a
half
hour
presentation
in
one
of
these
meetings
would
bring
people
up
to
speed
more
quickly
or
is
it
really
take?
You
know
you're
going
off
and
spending
longer
to
understand.
What's
going
on.
E
Iii
think
I
think
we,
you
know
a
half
hour
presentation
could
help
bring
people
up
to
speed.
I
mean
I'm
happy
to
do
some
I'm
happy
to
talk
about
it
informally
or
we
can
schedule
a
little
bit
more.
The
goal
is
the
you
know.
The
paper
might
have
been
a
little
bit
something
you
need
to
ponder
for
a
while
this
accessible
and
reasonably
into
it,
and
if
it's
not,
then
we
need
to
work
on
that.
I
think.
B
Half
an
hour
for
to
talk
about
this
would
be
a
really
good
idea.
I
think
I
think
this
is
something
that
would
really
benefit
from
a
overview
or
and
as
many
people
are
aware
of
the
of
this,
the
better
it
is,
and
all
of
us
might
want
to
read
a
paper
but
fax.
Whenever
is
probably
not
everybody
has
a
time
to
go
out
of
this
and
go
read
the
paper,
so
how
about?
We
would
be
quite
helpful,
I
think
bringing
everybody.
A
Yeah
all
right,
I,
just
pasted
a
link
and
so
there's
sort
of
like
a
little
readme
that
I
added,
which
I
need
to
work
on
the
text
a
little
bit,
but
it
tries
to
just
kind
of
cover
the
the
primary
concepts
and
then
it
links
off
to
the
current
visualizations
and
you
can
step
through
the
visualizations
and
look
through
the
code
being
executed
and
I.
Think
that
might
be
a
good
start.
But
I
agree
that
you
know
we
need
to
sort
of
bring
people
along
in
understanding.
So
you
know
we'll
talk
about.
F
F
And
so
we'll
try
and
you
know
fit
it
into
one.
I
think
we're
gonna
have
to
like
time
box
some
of
the
different
areas
like
if
we
could
fit
this
into
the
async
hooks
or
whatever
suction
were
I.
Guess
it's
monitoring
or
tracing
whichever
one
it
fits
into
there
put
it.
You
know
we
could
split
out
that
half
hour
for
that
yeah.
A
D
A
I
do
think
that
having
sort
of
well-defined
understanding
of
asynchronous
call
flow
is
a
significant
missing
gap
and
so
I
think
it's
it's
beneficial
to
be
able
to
discuss
that.
So,
let's
maybe
play
it
by
ear.
If
we
can
fit
it
in
and
then
you
know
make
sure
that
you
know
either
mark
or
myself
is
on
point
probably
mark
yeah.
E
H
H
So
I
think,
like
part
of
the
problem,
is
an
yang
could
probably
sell
a
lot
more
contacts
there,
but
basically
with
the
move
to
the
new
version
that
v8
in
node
a
lot
of
the
kind
of
the
stack
sampling
techniques,
we've
been
using
just
don't
work
anymore,
and
then
we've
had
some
discussions
with
Benedictine,
yang,
Francisco
and
basically
I
think.
The
summary
is
that,
like
using
external
profilers
and
having
chrome
chrome
coming
generate
a
mapping
of
JavaScript
symbols,
tomato
stack
frame
symbols
is
not
something
that
they
are
going
to
support
in
the
future.
H
Whether
whether
code
of
support
is
using
Pro
for
the
CPU
profiler,
but
that
comes
with
some
kind
of
issues
on
its
own.
In
terms
of
like
it,
ou
can
only
stable.
You
know
it
only
will
show
you
the
JavaScript
frames
and
nothing
native
you.
Obviously
one
gets
this
cause
because
it's
inside
the
process
and
currently
like
I,
think
tuning
isn't
really
set
up
in
a
way
where
it's
like
accessible,
some
of
them
back
api's
or
you
know
you
have
to
like
write
C++
code,
though
you
actually
access
some
of
that
stuff.
H
So
you
know,
we've
been
sponsoring
some
folks
to
work
on
this
issue
with
the
v8
folks
and
I
think
what
I
know
we
can
obviously
talk
about
more
about
this
at
is
not
diagnostic
summit,
but
I.
Think
the
general
theme
that
I
wanted
to
get
across
is
you
know,
I,
think
these
being
able
to
sample
CPU
frames
and
answer
profile.
H
The
running
process
is
really
really
important
and
in
the
past
we've
kind
of
relied
on
like
external
operating
system
level,
profilers
plus,
you
know
whatever
kind
of
translation
tools
that
VA
provided,
which
is
no
longer
applied
and
where
I'm
looking
for
is
kind
of
consensus.
I'm
like
hey,
can
we
think
about
providing
a
set
of
profiling
tools
for
node
and
v8
on
any
other
runtimes,
that's
going
to
be
maintained
and
the
first-class
thing
going
forward.
H
That's
part
of
the
new
API
and
we're
happy
to
like
to
initially
do
the
work
and
sponsor
folks,
do
you
know,
implement
stack
walkers
in
v8,
using
prof.
or
whatever,
but
I
think
when
we're
trying
to
get
alignment,
it's
like
you
know
is
this
is
the
is
the
CTC
and
the
VA
folks
amenable
to
like
continue
to
maintain
that
going
forward
right.
The
set
of
tools.
F
D
F
F
H
C
H
And
then
that'll
be
so
we
can
refer
to
at
the
summit
to
kind
of
go
over.
I
think
thing
is
like
getting
alignment
to
make
sure
that
like
hey
these
are
we
think
this
is
important.
We
want
to
maintain
ease
going
forward.
You
know
we're
obviously,
as
netflix
we're
happy
to
do
the
work
right
now
to
do
to
mate,
to
make
the
changes
and
work
with
you
guys
to
make
it
work,
but,
like
we
want
to
love,
we
would
love
to
see
more
community
support
for
this
as
well
right
right.
F
I
mean
on
that
front
that
the
challenge
is
always
most
people
being
volunteers.
We
can't
really,
we
don't
really
get
people
signed
up
and
committed
to
doing
things
there.
They
work
on
things
that
are
interesting
to
them,
but
you
know
the
thing
we
can
do
is
to
make
it
so
that
it's
part
of
the
overall
safety
net
and
infrastructure
to
know
when
something
does
get
broken
right.
D
F
H
C
C
D
F
F
H
H
H
F
H
I
think
it
first,
we
need
to
get
alignment
I
guess
with
the
CDC
and
yeah
the
VA
folks
on
the
rope
like
we
I
have
we
have
a
roadmap,
we
think
yeah
we
can
do
to
get
there
and
I
want
to
make
sure
that
it's.
You
know
something
everyone
agrees
with
in
terms
of
the
technical
implementation
and
then
once
that's
there
yeah
we're
absolutely
happy
to
sponsor
yeah.
F
In
terms
of
the
amount
of
feedback
you'll
get
you
know,
some
people
will
comment.
Some
people
won't,
but
the
key
thing
is
having
made
it
visible.
You
know
that'll
make
sure
that
when
you
get
there,
everybody
is
like
oh
yeah,
okay
I
knew
that
was
happening.
So
even
if
I
didn't
have
strong
feelings,
it's
like
yeah
I,
think
that
should
be
going
in
well
good.