►
From YouTube: 2023-01-19 meeting
Description
Instrumentation: Messaging
A
B
A
A
C
C
Perfect,
okay,
cool.
Can
you
all
see
my
screen?
Yes,
okay,
thanks
thanks!
Everyone
for
coming,
if
you
haven't
yet
already
add
yourself
to
the
attendees
list
and
anything
you
want
to
talk
about
in
the
agenda
and
we
can
jump
in
here
so
wow
that
cursor
seizure
there's
another
release
for
the
specification
this
past
week.
So
the
117
package
is
out.
C
We
we're
all
set
to
complete
the
milestone
for
this
112
release,
but
I
decided
just
to
quickly
add
this
in
because
we
spent
all
this
time
working
on
getting
this
income
gen
working.
So
it
should
be
straightforward.
It
just
needs
reviews,
but
then
this
is
again
I'm
blocking
the
release.
It's
not
like
the
end
of
the
world.
If
we
don't
include
this
one
in
the
in
a
release
but
I,
don't
think
we're
also
going
to
get
it
out
this
week.
So
actually,
maybe
we
talk
a
little
bit
about
that.
A
C
Up
is
this
PR
ad
here
it's
been
open
for
a
little
while
just
kind
of
a
heads
up
on
this.
It's
got
two
reviews
that
are
approving
I
just
wanted
to
like
call
it
out,
because
it's
a
complex
PR,
which
actually
might
mean
that
you
may
not
want
to
review
it,
but
it's
really
complex
because
it
has.
We've
talked
a
little
bit
about
this
before
this
has
the
interaction
between
aggregators
and
the
filter,
aggregator,
which
sits
on
top
of
them
and
has
to
deal
with
the
pre-computed
values.
C
There's
a
lot
of
conversation
in
here
between
David
and
myself,
around
actual
Behavior
and
actual
specified
Behavior,
which
is
like
I,
mean
it
is,
or
at
least
specified.
I
guess
is
what
I'll
say
there
in
fact,
I
think
there's
still
some
like
outstanding,
like
here's,
this
I
think
might
be
the
a
good
point
that,
like
you
know,
one
of
the
things
is
like
the
default.
Behavior
of
the
pre-computed
setup
may
not
need
to
keep
State
for
the
cumulative.
C
It's
not
actually
specified
anywhere
that
it
needs
to
so
like
I
mean
I.
There's
this
isn't
blocking
because
this
isn't
going
to
relate
to
the
actual
filtered
values,
but
yeah
I,
just
kind
of
wanted
to
like
there's
a
lot
of
things
that,
like
are
done
here,
based
on
I,
think
preference
more
than
specifications.
So
just
kind
of
keep
that
in
mind.
If
you
do
read
this,
there
is
a
consensus
in
a
specification
issue
that
these
filters
should
be
I'm.
C
Sorry,
these
aggregate
or
should
be
adding
any
value
that
is
associated
with
attributes
that
have
been
filtered
so
that
that
doesn't
exist.
Whether
that
should
also
be
added
for
the
default.
Pre-Computed
values
is
there's
another
issue
that
says
that
probably
shouldn't,
but
there's
like
there's
still
consensus
being
built
around
that
so
yeah
I
guess.
This
is
just
an
understanding
of
the
specification,
but
it's
not
specified
I.
Guess
is
the
way
to
say
that
in
any
hard
sense,
so
yeah
I
mean,
if
you
have
time,
take
a
look.
A
C
It
was
yeah,
it's
okay,
it's
all
in
this
meter
test.
So
the
thing
that
Aaron's
talking
about
is
he
went
through
the
supplementary
guidelines
and
he
built
out
essentially
a
test
that
Works
to
to
highlight
that
supplementary
guidelines.
So
you
can
go
and
you
can
follow
along
there's
a
link
here
that
and
then
you
know,
based
on
what
the
specification
says,
these
values
should
turn
into
this
test
shows
that
it
turns
into
those
values.
So
yeah,
that's
just
a
good
heads
up.
C
Not
to
say
that
we
shouldn't
be
scrutinizing
every
line
of
tests
as
well,
but
yeah
just
kind
of
like
if
you
wanted
to
get
a
heads
up
on
that.
Okay,
that
I,
don't
think
is
as
critical.
It
is
included
in
this
next
Milestone,
but
yeah
just
a
heads
up,
so
maybe
on
that
note
we
can
talk
about
next
releases
Maybe,
so
we
talked
about
this
last
week
about
maybe
a
release
going
out
this
this
week,
but
that
didn't
happen.
C
We
have
completed
the
112
milestone
well
and
then
we
uncompleted
it
by
adding
in
the
117.
but
I
I.
Don't
think
this
is
too
too
much
of
a
challenge
to
figure
out.
This
still
has
you've
things
still
in
here.
I,
don't
know!
If
there's
any
issue,
it
doesn't
yeah.
This
actually
doesn't
have
something,
but
I
don't
think
it
should
be
included
in
this.
C
So
we'll
talk
about
that,
the
this
issue
to
consider
using
math
Nan
was
resolved
by
using
this
extrema.
That's
another
I,
guess
PR.
That
is
worth
checking
out.
If
you
haven't
already.
We
talked
about
this
last
week
where
there's
this,
maybe
we
can
go
into
this
issue.
A
little
bit
here,
proposals
were
included
here
for
using
Nan
as
a
as
a
max
value,
using
some
pointer,
optimization
and
then
using
this
extrema
structure
that
is
explicitly
able
to
then
handle
the
value
by
setting
a
Bool.
C
So
one
of
the
things
that
was
asked
for
is
performance
tests
which
were
done,
there's
a
gist
here
that
kind
of
highlights
the
code
and
it
breaks
down
all
these
different
things,
just
kind
of
like
a
high
level.
It
does
measure
the
strut
size.
This
is
the
zero
value
struct
size.
So
it's
not
that
critical,
given
their
you
know,
within
a
factor
of
two
of
each
other.
The
performance
hit
just
kind
of
a
heads
up,
I
guess
maybe
on
the
nomenclature,
the
his
pointer.
These
are
the
original.
C
C
This
recommendation
to
have
some
sort
of
local
reference
to
the
pointer
that
the
Min
and
Max
are
going
to
use,
and
then
the
extrema
is
the
extrema
that
we
saw
above,
and
so,
if
you
look
at
the
performance
here
kind
of
like
at
a
base
rate
for
allocations,
like
our
base,
the
main
thing
was,
you
know:
one
thing
that
is
not
included
directly
in
the
performance
numbers
of
computation
time
is
the
GC
time.
That's
going
to
be
spent
allocations
is
kind
of
a
proxy
to
that.
C
So
I
think
this
is
what
Josh
was
kind
of
pointing
out.
Is
that,
like
our
original
implementation
is
two
allocations?
Bogdens
approaches,
one
Josh's
approach
of
not
having
any
pointers
and
then
using
n
is
zero.
The
externa
also
has
zero,
so
they
have
very
similar
I.
Think
effects
on
the
GC.
The
computational
performance
is
comparable.
This
might
be
a
little
skewed
because
it
doesn't
actually
do
any
like
comparison
to
find
out
if
the
value
is
zero
and
set
it
to
nand.
C
So
it's
not
a
really
true,
but
like
it's
close
enough
for
it,
it's
a
factor.
Two
kind
of
thing,
really
the
big
ones
are
just
you
know,
look
at
these
other
performances
because
they
have
to
do
allocations
to
the
Heap
are
pretty
big,
so
I
think
performance
wise.
It
did
make
sense
and
I
think
that
we
wanted
to
go
ahead
and
I
ended
up
moving
the
related
PR
that
was
associated
with
to
ready
to
review.
C
Okay,
then
this
was
just
out
of
this
morning
after
we
finished
the
refactor
of
the
API
by
updating
the
multi
callback
setup,
it
was
observed
we
kind
of
talked
about
this
last
week
in
passing,
but
I
just
want
to
call
it
out
that
the
if
we
are
single
callbacks,
don't
and
our
multi-callbacks
all
make
observations
by
using
a
parameter.
Having
an
observed
method
on
any
of
the
instruments
is
one
not
required
by
the
specification
and
two
only
causes
confusion
amongst
the
users.
C
So
this
is
a
issue
to
track
a
proposal
to
remove
that
it
does
a
lot
of
breakdown
into
each
one
of
those
claims.
I
just
made,
especially
the
specification
part
and
then
I've
got
a
PR.
That
I
think
is
yeah.
I.
Think
I
just
made
it
ready
for
review
this
morning.
That
does
this
and
it
it
removes.
It
removes
The
observed
method,
there's
a
little
bit
of
a
reshuffle,
because
our
Observer
used
to
embed
things.
C
So
now
there's
this
new
thing,
where
it's
an
observable
that
embeds
all
of
the
observable
instruments
and
then
our
Observer
is
just
what
it
was
before,
but
it's
specifically
left
around,
because
the
callback
for
the
single
callback
needs
to
accept
this.
So
it's
kind
of
a
high
level
overview
of
what
this
is
going
to
do.
C
This
log
duplicate
warning
for
duplicate
for
the
know-up
is
still
blocked.
It
should
not
be
in
this
Milestone
because
I
don't
think
we're
going
to
do
this.
This
again,
just
a
heads
up,
like
the
specification,
says
all
implementations
log
based
on
name
conflicts.
We
don't
think
that
should
be
the
case,
so
yeah
I
think
that
this
is
probably
not
something
we're
going
to
do,
but
I
just
wanted
to
track
it.
So
that's
why
it's
there
that
being
removed.
C
A
So
I'm
gonna
work
on
it,
but
I
want
to
add
one
thing
to
that
list
which
I
you
can't
actually
put
in
the
release.
Milestone
is
my
comment.
There
yeah
I
put
this
together
this
morning.
This
doesn't
have
like
I
can't
I
can
test
it
locally,
because
I
can
use
like
a
workspace
or
redo
the
replaces,
but
I
don't
have
a
way
of
testing
it
until
there
is
a
release
done,
but
this
is
the
work
that
would
need
to
be
done
in
the
contribute
to
convert
to
the
new
API.
C
Yeah
well,
what
we've
done
in
the
past
it
might
be
helpful
here
is,
if
you
do
a
go
get
with
at
the
end
of
whatever
the
package
name
is
and
at,
and
then
you
put
a
commit
hash,
it
should
be
able
to
pull
like
the
master
Branch
or
we're
not
using
main
branch,
and
then
you
should
be
able
to
like
do
a
full
like
committable
change
here.
If
you
wanted
to
do
that
and
then
the
pass
for
the
semcom,
which
is
also
something
we
need
to
do
here,.
A
C
I
think
that's
great
like
because,
again
going
back
to
our
release,
planning
I
think
that's
something
we
try
to
do
is
to
have
the
trip
out
as
soon
as
possible,
after
the
main
so
having
this
staged
or
merged
actually
because
it'd
be
on
Main.
If
we
can
get
into
a
emergable
state
by
using
the
commit
hash,
I
think
is
a
good
idea.
C
I
realize
we
might
actually
be
already
have
gone
through
all
of
these
just
by
looking
at
those
Milestones,
so
I
guess
there's
a
little
bit
more,
so
the
metrics
ga
project
can
just
want
to
take
a
look
at
this.
There
is
this
removal
of
the
observable
instrument
method,
so
this
is
I
think
the
last
thing
outside
of
that
logging
issue.
That
would
change
that.
We
have
open
that
would
change
the
code,
so
I
think
that
this
is
in
a
really
good
State.
C
All
of
these
other
blocked
verification
issues
are
either
I.
Guess
there's
still
this
TCR
review
one,
but
there's
specification,
clarification
or
updates.
That
needs
to
be
done
here.
So
I
think
this
is
looking
really
good.
One
of
the
clarifications
would
close
this
so
like
I,
think
we're
in
line
there.
There's
there's
active
work
going
on
Upstream.
Try
to
help
clarify
this,
so
I.
Think
that
looks
good.
C
The
metric
SDK,
the
only
outstanding
issue,
is
this
optimization
of
the
memory
allocations,
so
I
think
that
we
just
need
somebody
to
tackle
this,
which
I
guess
in
due
time.
If
nobody
does
I
would
I
will
jump
on.
But
if
you
have
interest
in
picking
something
up
in
the
next
day
or
two
I
think
this
is
a
good
one.
So
just
to
kind
of
point
it
out
that
this
doesn't
necessarily
need
a
full
solution,
especially
not
something
that
can
be.
C
You
know
merged
in
right
now,
but
it
needs
to
have
a
clear
line
of
sight
on
it,
and
an
answer
currently
like
this
includes
all
histograms
copies
all
over
the
place
like
whenever
you
pass
for
aggregation,
it
copies
the
balance
that
whenever
it
actually
produces
the
metric
data,
it
it
copies
the
bounds.
There's
a
lot
of
copying
going
on
here
and
there's
a
few
different
ways
that
I
think
you
probably
start
to
think
about
trying
to
solve
this.
C
But
the
answer
I
think
is
one
that
Josh
pointed
out
is
like,
if
say
in
the
computation
or
in
the
collection
cycle,
you
can
pass
some
sort
of
structure.
That's
already
pre-allocated.
On
the
memory
could
be
useful,
which
I
think
is
viable,
but
it's
going
to
be
based
on
the
reader,
so,
like
I
think
that
using
something
with
our
our
periodic
reader,
since
it
can
hold
a
sink
pool,
it
could
actually
do
this
because
it
could
do
the
collection,
through
its
own,
collect
method
that
it
wanted.
C
A
C
C
It
does
one
thing
that
is
kind
of
unstated.
There,
though,
is
the
performance
improvements
like
those
need
to
be
I,
think
concretely
defined,
including
having
some
sort
of
test.
That
shows
the
thing
that
we're
trying
to
optimize
for
whether
that's
allocations
or
memory
overheads
on
the
stack
or
I
don't
know
like
something
like
those
need
to
get
defined
right.
A
C
C
C
I
I
definitely
think
that
having
some
sort
of
I
see
a
similar
to
what
we
did
for
the
standard.metrix
exporter,
where
we
had
a
line
of
sight
that
we
could
actually
do
time
stamp
removal
from
from
something
and
we've
bumped
that
ticket
priority
but
yeah
somebody
just
yeah
so
I
don't
know.
If
there's
any
takers.
C
B
C
Okay
cool
so
I
mean
I.
Think
with
that
I
think
timeline
wise.
We
should
start
talking
about
I
think
the
ends
of
like
our
release,
Cycles
here
so
because
we
I
think
we
have
a
you
know
identified
a
lot
of
stuff
that
is
actually
going
to
get
us
to
our
goal
of
releasing
both
a
stable,
metrics,
API
and
SDK
here.
So
you
know
first
step
is
is
definitely
this
next
release.
We
need
to
prioritize
that
we've
seen
with
the
API
that
What's
blocking
us
is
going
to
be
the
specification.
C
So
we
already
have
somebody
working
on
that
and
if
you
haven't
already
taking
a
look
at
those
issues,
would
help
unblock
us
and
then
the
next
thing,
that's
really
holding
back
on
the
beta
for
the
SDK
is
just
memory
optimization.
So
there's
really
like
three
things:
they're,
not
really
I,
think
blocked
one
after
the
other,
but
I
think
with
that.
Our
our
next
steps
after
the
specification
work
for
the
API,
is
just
getting
verification
from
a
TC
member
and
going
through
release.
C
Cycles
I
think
the
next
steps
for
the
metrics
SDK
is
I,
think
making
some
sort
of
beta
and
then
I
think
we
need
to
then
go
into
the
project.
That's
tracking
the
SDK
GA,
which
is
going
to
need
to
be
broken
up
into
verification
tasks
and
do
similar
things
to
what
we've
done
for
the
API
but
other
than
that.
I.
Think
that,
like
you
know
the
long
term,
we
have,
we
have
a
vision
as
to
how
we
can
actually
achieve
this
stable
metric
signal.
Just
for
clarity.
There.
C
C
C
B
I
think
the
conclusion
I
drew
was
actually
that
almost
all
this
behavior
is
unspecified
and
yeah
I
feel,
like
maybe
there's
some
opportunities
for
us
to
do
things
that
are
better
than
what
we're
currently
doing,
but
I.
Think
the
the
filtered
PR
in
its
current
state
is
definitely
a
step
forward,
but
I'm
not
sure
if
it
makes
do.
B
C
C
If
we
started
you
know
to
change
the
behavior,
it
would
provide
an
optimization
and
it
and
it
there
there's
a
there's,
a
logical
case
to
do
that,
so
that
that
seems
reasonable
to
me
to
say
that
we
should
just
do
that
in
the
go
implementation
and
then
you
know
asynchronously
at
the
same
time
try
to
work
with
a
specification
to
get
them
to
say
either
it's
intentionally
left
undefined
or
here's
the
behavior.
We
want
to
enforce
that.
That
sounds
good
to
me.
In
my
opinion,.
C
B
Foreign
I
actually
think
it's,
at
least
in
a
lot
of
the
things
I've
worked
on
in
the
past,
I
think
being
able
to
drop
observations
or
like
label
sets
is
actually
like
a
really
important
feature,
even
more
than
just
an
optimization,
because
there's
certain
use
cases
that
just
become
impossible.
If,
like
that,
is
impossible
in
some
form
so
yeah,
it's
it's
a
little
near
and
dear
to
my
heart,
but
I'm
also
happy
to
wait,
we're
only
in
Alpha.
So
there's
plenty
of
time.