►
From YouTube: 2022-02-24 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).
B
B
C
B
C
C
All
right,
so,
let's
learn
five.
I
guess
that
get
started
I'll,
be
I'll,
be
starting
with
this
issue.
I
have
a
question
here,
so
this
is
the
fix
the
for
the
issue
that
aaron
opened
this
one
I'll
be
explaining
quickly.
So
this
is
an
issue
aaron
opened,
because
the
way
that
the
specification
was
written
was
too
restrictive.
C
It
should
allow
for
this
situation
to
happen
where
two
instruments
have
the
same
name,
but
they
are
in
different
meters,
which
is
okay,
so
the
solution.
The
proposal
solution
here
is
to
add
this
note
that,
as
long
as
they
are
in
different
meters,
this
is
okay.
The
problem
that
I
have
with
this
solution
is
that
I
think
the
problem
persists.
E
So
I
think
I
think
this
is
okay,
because
it's
sort
of
just
like
a
special
case
right.
The
intention,
if
somebody
makes
a
view
that
can
select
multiple
instruments
and
they
select
an
output
name,
their
intention.
There
is
going
to
create
conflicts
because
they're
assuming
you
can
select
multiples
right.
So
I
think
this
is
sort
of
like
a
quote
like
a
static.
E
E
By
the
spec
right
so
so,
I
think
the
problem
is
their
intention.
If
they
put
an
asterisk
there
is
that
they
want
to
map
multiple
instruments
to
a
single
name
within
the
same
meter
right.
So
the
I
think
the
idea
is
like
again
just
a
special
case
and
they'll.
All
they
have
to
do
is
just
remove
the
asterisks
and
rerun
it
right.
C
C
If,
if
this
situation
happens
and
it's
a
problem,
then
this
okay,
let
me
see
how
I
explain
this.
B
C
What
I
think
that
the
the
specification
is
trying
to
say
is
that
the
sdk
must
not
allow
us
views
will
specify
a
name
to
be
declared
with
it
with
instrument
selectors
that
can
select
more
than
one
instrument
like
well
card
matching,
it
doesn't
matter.
If
this
is
added
or
not,
it
doesn't
solve
the
problem
because,
because
by
by
the
time,
the
view
is
declared
it's
not
possible
to
know
if
they
will
be
in
the
same
meeting
or
not.
E
A
C
D
Yeah,
so
the
so
so
specifying
here
that
that
it's
within
the
same
meter
kind
of
adds
a
little
bit
of
clarity.
Maybe
it
doesn't
add
clarity.
I
don't
know.
I
think
it's
trying
to
add
clarity,
that
this
is
like
specifying
an
instrument.
Name
is
okay,
so
long
as
like
specifying
an
instrument.
Name
is
fine,
but
it's
leveraging
the
fact
that
you
can
only
have
one
instrument
named
the
same
thing
per
meter.
C
F
Yeah,
so
you
were
saying
that
it's
not
possible
to
have
a
instrument
with
same
name
like
multiple
instrument,
name
within
the
same
method.
Right
like
they
can
right
now
the
specification
is
changed
that
so
that
you
they
will
that's
still
allowed,
but
you
will
we
will.
You
know
say
that
this
is
going
to
cause
a
metric
stream
conflict
like
we
are
going
to
want
them,
but
right
now
it's
like
you
could
still
create
a
different
instruments
with
same
name
within
a
meter
right.
C
Yeah,
but
just
imagine
that
this
part
of
code
does
not
exist.
Okay,
so.
F
E
But
we're
gonna.
Can
you
all
hear
me?
Okay?
Can
you
hear
me?
Okay,
I
I
mean,
I
think,
my
understanding
of
what
the
spec
added
in
josh
mcdonald's
last
pr
was
this
okay.
Let
me
see
if
I
remember
this
right,
I
think
there's
basically
two
cases
right
so
the
case
where
you
have
multiple
instruments
in
the
same
meter
with
the
same
name
but
otherwise
like
different
aggregator,
a
different
type
of
instrument,
that's
what
he
calls
a
semantic
error,
because
it's
it's
like
a
misconfiguration,
even
though
they're
technically
distinguishable.
E
In
that
case,
we
want
to
allow
we
want
to
warn
users
and
allow
them
to
make
views
to
change
the
name.
To
avoid
that
semantic
error.
The
other
case
is
when
you
try
to
create
two
of
the
same
counter,
we're
just
going
to
return
the
same
counter
twice
when
they
do
that,
if
they
return
like
if
they
try
to
create
a
counter
with
the
same
name,
we're
gonna
tell
them.
E
This
is
wrong
and
return
the
either
like
a
no
op
or
sorry,
not
a
no
we're
gonna
return
the
original
counter
and
update
it
with
those
rules
that
he
said,
like
you,
take
the
longer
the
two
descriptions
and
et
cetera:
does
that
make
sense.
B
F
It's
it's
still
possible
that,
with
a
view
name
with
the
view
instrument,
name
that
there
can
be
like
multiple
matches
right.
So
what
what
I?
What
I'm
understanding
from
riley
is
that
you
know
this
like
if
it's
possible
for
you
to
you
know,
detect
such
things
that
invalid
view,
but
otherwise
let
let
the
metric
stream
pass
through
and
then
the
other
processes
will.
You
know,
take
care
of
that.
F
C
Replying
to
riley,
I
think
I'm
I'm
pretty
much
going
to
say
this.
This
part
is
not
relevant
because
you
don't
know
at
the
time
you
declared
the
view
and.
C
What
happens
is
that
I
understand
that
there
is
an
intention
to
allow
this
to
happen
right
because
it
is
okay,
if
there
are
two
instruments
with
the
same
new
as
long
same
name
as
long
as
they
are
in
different
meters.
The
problem
is
that
the
the
way
that
this
is
written
by
the
time
that
it
is
declared
it
is
not
possible
to
know
this,
so
it
is
impossible
to
to
to
enforce
what
the
specification
should
say
instead.
C
Is
that
it's
just
that
the
sdk
was
not
allows
you
to
specific
name
to
be
declared
with
instrument
selectors
that
use
a
walter?
That's
what
you
should.
E
Say
so
I
don't
think
that's
true,
so
I
I
think
this
sort
of
check
is,
like
think
of
it
almost
as
like
a
type
check
right,
the
a
view
that
doesn't
pin
down
a
specific
instrument,
and
then
it
gives
an
output
name-
is
supposed
to
be
invalid
unless
it's,
unless
it
has
like
a
wild
card
meter,
like
you,
don't
specify
the
meter
right.
So,
if
you
put,
for
instance,
instrument
name,
you
put
instrument
type,
you
put
no
meter
information,
that's
going
to
select
at
most
one
instrument
right.
E
E
On
the
other
hand,
if
you
leave,
if
you
leave
something
unspecified
in
the
selection
criteria,
so
it
could
select
multiple
instruments.
It's
like
a
static
error,
almost
like
hey.
This
is
just
not
a
valid
view,
because
your
intention
is
wrong.
You
need
to
add
more
criteria,
so
you
don't
create
a
conflict.
C
C
C
C
Correct,
okay!
So
what
I'm
tr?
What
I
think
this
specifications
say
is
that
all
these
specific,
with
instruments
with
wild
cards
here?
Okay,
so
I
think
that
what
I'm
proposing
allows
the
situation
you
are
proposing,
which
is
good.
C
C
E
E
I
I
don't
think
that
that
would
be
okay,
but
maybe
we
should
like
try
to
come
up
with
some
examples.
I
think
that's
the
easiest
way
to
talk
about
this,
because
it
does
get
really
complicated
so
yeah.
Maybe
we
should
like
try
to
come
up
with
some
examples
today,
yeah.
F
C
F
So
so
what
what?
What
you're
proposing?
Is
that
a
view
that
that
has
instrument
selector
wild
card
that
includes
wild
card
it
should
not
allow
is
that.
C
Yeah,
that's
that's!
That's
what
I'm
trying
to
avoid
I'm
trying
to
avoid
those
matches
well
pretty
much.
What
I'm
trying
to
say
is
that
this
part
is
not
it's
not
relevant,
and
the
specification
should
refer
specifically
to
the
the
problem
that
the
world
currency
caused.
C
But
but
I
agree
with
her:
it's
it's
really
hard
to
discuss
with
that
example.
So
I
think
we
can
discuss
it
offline
in
one
of
the
slide
channels.
So
can
we
move
forward.
C
C
Good
to
me,
okay,
so
I'll
try
to
write
down
something
that
can
be
more
recently
understood.
C
C
What's
outstanding
good
question,
okay,
all
right,
so
we
had
a
little
bit
of
a
conundrum
that
I
tried
to
solve
yesterday.
Let's
see
if
I
can
show
you
a
solution.
Okay,
so
the
approach
that
I
had
before
was
that
the
views
will
receive.
C
Okay,
that
the
views
will
be
receiving
an
aggregation
plus
here.
That
was
my
approach,
but
always
pointed
out
that
this
doesn't
work,
because
some
aggregations
need
a
configuration.
Histograms
buckets
some
aggregations
need
to
indicate
if
they're
monotonic
or
not
that
kind
of
stuff
okay.
So
I
change
this
so
that
an
aggregation
class
is
not
a
task
here,
but
an
aggregation
instance.
Okay,.
C
You
can
create
beforehand
your
aggregation
with
all
the
configuration
that
you
want
put
it
here,
and
that
is
the
aggregation
that
will
be
used
afterwards
for
creating
the
data
in
the
metric
stream.
Now,
the
what
I
also
did
was
to
a
solution
for
the
situation
where,
where
this
is
not
defined
by
the
user,
so
what
should
we
do
by
default?
C
So
let
me
see
if
I
can,
what
I
did
was
this:
I
created
a
property
in
the
in
all
the
sdk
instruments
that,
when
called
returns
an
aggregation
instance
so
for
every
class
they
return
a
default
aggregation
object
in
the
case
of
counter
it's
some
aggregation,
which
is
defined
as
monotonic
and
delta.
C
C
Here
it,
it
is
being
used
like
that
aggregation.
So
when
the.
C
Is
instantiated
it
tries
to
use
the
view
aggregation
if
it
is
none,
because
the
user
did
not
specify
one
in
the
aggregation,
then
the
instrument
aggregation
is
used.
That's
pretty
much
the
solution
I
have
by
the
way,
I
still
need
to
add
tests.
Sorry,
I
I
added
this
very
late
yesterday.
So
I
think
some
stuff
is
not
running
and
I
need
to
add
this
for
that.
That's
pretty
much
the
idea.
E
I
just
added
a
comment,
but
the
problem
here
is:
if
you
use
a
single,
you
need
one
aggregation
per
attribute
set
right
so
like.
If
you
just
pass
an
instance
of
an
aggregation,
how
do
you
create
a
new
one
for
each
different
attribute.
C
Well,
that's
a
good
point:
it
is
not
the
case
with
instrument
aggregation
because
the
property
creates
a
new
one.
Every
time
it's
called,
I
think
I
will
have
to
do
the
same
thing
for
video
aggregation
so
that
when
the
instrument,
when
the
user
passes
an
aggregation,
a
copy
is
made
every
time
this
happens
so
that
they
will
always
get
a
different
instance
yeah,
but.
E
Okay,
so
that's
did
you
see
my
comment
on
my
old
p?
My
period
I
got
merged
that
alex
was
updating
specifically,
I
suggested
making
an
aggregation,
factory
class
kind
of
similar
to
what
java
has
that
would
basically
do
this
the
same
thing,
but
would
allow
eventually
users
to
add
their
own
custom
aggregations.
C
Okay,
I
think
there
was
a
comment
that
you
added
here-
I
don't
know
yeah
this
this.
This
comment.
C
Question
what's
wrong
with
letting
the
users
put
an
aggregation
in
view.
E
So
I
don't,
I
don't
feel
super
confident,
especially
considering
the
last
metric
sig
there's
like
a
lot
of
confusion
about
how
aggregator
relates
to
a
specific
aggregation
or
whatever,
and
even
somebody
suggested
making.
I
mean,
I
think
you
were
there,
the
async
aggregations
separate
from
the
synchronous
ones
or
having
ones
that
output
cumulative
versus
delta
as
like
a
property
of
them.
So
I
just
don't
feel
comfortable
at
all
exposing
it,
and
I
think
we
might
have
to
change
it
in
the
future.
E
So
I'd
like
to
keep
it
hidden
for
as
long
as
possible
until
we
know
exactly
what
it's
going
to
look
like
all
right.
C
This
is
the
part
that
understands
how
how
do
we
tend
to
hide
it,
because
somehow
we
need
to
allow
the
user
to
tell
the
view
which
kind
of
aggregation
they
want
to
use
right.
E
Right
so
we
just
expose,
we
could
write
our
own
here.
Let
me
just
pull
up
the
the
pr,
oh,
I
can
do
it.
I
can
just
ping
a
link
in
it
sure
I
can
do
that
too.
E
While
I
try
to
get
that
set
up
alex,
do
you
did
you
see
my
comment
there
before
and
any
any
comment
from
you?
There.
D
I
did
I
did
see
the
comment.
I
I
don't
have
a
problem
with
that
approach.
E
All
but
diego
you
have
to
stop
sharing
okay,.
B
C
C
You
share.
Okay,
do
you
want
to
paste
it
in
the
chat.
C
C
D
C
D
Yeah
it
returns
like
the
interface
for
the
aggregation
factory
is
to
return
an
aggregation.
It's
not
the
aggregation
interface
itself.
D
C
C
Anything
well,
it's
actually
returning
an
instance
of
this,
which
is
pretty
much
exposing
that
at
the
same
time,
see
what
I
mean.
E
Diego,
so
the
problem
is,
if
explicit,
bucket
histogram,
we
don't
know
what
the
constructor
parameters
are
gonna,
be
we
don't?
No,
like
that's
that's
the
part.
That's
gonna
be
coupled
to
the
internal
of
the
sdk
right.
So
in
the
meantime,
while
we're
trying
to
figure
out
because,
for
instance,
we
need
to
pass
in
like
some
specific
stuff
about
the
instrument.
C
Okay,
the
histogram
factory
has
the
same
attributes
passed
to
the
constructor.
So
if
these
changes
this
is
these
will
have
to
change
as
well.
E
Right,
no,
so
so
that
the
aggregation
configuration
is
defined
in
the
spec,
those
are
are
specked
out
and
they
shouldn't
change.
What's
not
defined
in
the
spec
is
hey.
This
is
how
an
aggregation
class
looks.
This
is
the
parameters
it
should
take.
This
is
how
it
should
interact
with
the
sdk.
So
the
part
that's
in
the
spec,
it
corresponds
to
this
histogram
factory
or
some
factory
or
whatever.
That's
the
part
that
I'm
saying
we
can
expose.
C
Yeah,
okay,
maybe
this
is
what
I'm
trying
to
say.
So
what
we
don't
know
yet
is
or
again
what
is
not
specified
is
how
the
the
class
that
represents
the
spec
aggregation
should
be.
I
agree
with
you
that
that
is,
of
course,
not
specific,
and
what
is
specified
is
the
the
the
interface
or
the
the
attributes
that
that
class
has
to
needs
right
to
instantiate.
C
C
Right
right,
okay,
so
what
I'm
trying
to
say
is
that
it
is
pretty
much
the
same
thing:
exposing
the
class
and
its
constructor.
D
E
E
C
Right
so,
for
example,
what
you're
trying
to
achieve
is
the
users
just
having
to
say
hey,
I
went
to
some
aggregation
and
they
don't
and
they
should
not
be
concerned
about
if
the
corresponding
instrument
is
is
synchronous
or
for
its
temporalities
or
sorry,
it's
monotonic
or
not.
That's
that's
what
you're
trying
to
say
you're
trying
to
separate
the
so
the
user
can
just
pretty
much
say.
I
want
some
aggregation.
B
C
C
Okay.
I
can
take
a
look
at
that
this
factory
solution
so
that
we
can
yeah.
We
can
separate
the
to
these
details
from
the
user
makes
sense.
It's
a
good
one.
I
I'll
definitely
look
into
that
I'll
refactor.
My
pr
include
a
solution
for
that.
E
D
D
C
E
Nice,
nice
yeah.
I
think
I
had
one
other
comment
about
the
underscore.
No,
no,
it
was
the
one
about
how
we're
saving
the
previously
matched
instrumentation
infos.
I
don't
know
if
it's
still
not
resolved.
I
don't
know
if
you
updated
the
pr
it's
in
the
hidden
section,
so
it
hit.
E
C
This
is
a
great
point,
in
fact,
I
want
to
discuss
this.
The
way
that
I
implemented.
This
view
is
by
making
it
stateful,
and
I
also
think
it's.
C
Maybe
the
instrument
match
needs
to
be
stateful
or
the
metric
reader
storage,
because
because
of
this,
this
thing
I
think
you
you
mentioned
that
here
that
it
needs
to
be
implemented
outside
of
the
viewplus
somewhere
right,
yeah
yeah.
I
also
think
that
this
is
a
good
point.
I
I
agree
that
it
will
be
better
if
the
ebu
just
says
image
or
I
don't
match,
regardless
of
the
circumstances
right
and
someone
else
is
responsible
for
remembering
if
it
had
previously
matched
instrument
or
not.
C
C
E
What
can
happen
is
you
can
have
like
a
counter
and
a
histogram
with
the
same
name.
That's
the
semantic
error
that
yeah
josh
added
that
it's
that
I
put
in
the
quotes
there,
so
so
in
that
case,
you're
still
supposed
to
pass
through
the
conflicting
data,
so
we
have
to
essentially
say
it
matched
and
preserve
that
match
in.
In
that
case,
too,.
E
C
C
Okay,
I
I
am
okay
with
that,
just
everything
everyone
else
is
the
same,
because
that's
that's
that's
what
I'd
like
what
I
plan
to
do.
C
Yes,
so
the
specification
says
you
should
not
be
declared
with
a
name
and
a
wildcard.
So
if
someone
tries
to
do
that,
what
should
we
do?
Should
we
raise
an
exception?
I
think
we
should
raise
an
assumption.
Aaron
also
thinks
we
should
raise
interception.
F
C
That's
that's
a
statement.
I
think
we
should
not
allow
a
view
with
a
name
and
a
world.
C
Which
one
no,
the
the
question
that
I
that
they
had
for
me
folks,
is
that
if
we
are
not
going
to
allow
that
and
the
user
tries
to
do
that,
what
should
we
do?
Should
we
raise
an
exception
at
that
moment
when
the
view
is
about
to
be
instantiated,
I
think
that's
what
we
should
do
and
I
think
aaron
feels
the
same.
F
Yeah,
that
makes
sense
to
me,
but
I
was
wondering
why,
like
what?
What
differentiates
between
the
semantic
error
and
the
the
this
error,
where
we
you
know
raising
an
exception.
C
C
Okay,
possibly,
I
just
think
that
the
way
the
specification
is
is
worded
where
it
says
you
should
not
be
declared
makes
me
think
that
we
should
stop
it
there
at
the
moment
of
the
declaration
of
instantiations.
We,
instead
of
letting
that
happen,
that
turn
into
a
semantic
year
later.
C
Okay,
very
good,
nice,
okay,
so
I
have
homework.
I
need
to
fix
this
somehow
and
I
also
need
to
fix
the
the
interface
for
aggregations
somehow.
D
C
E
C
We
kind
of
need
aggregation
because,
if
not,
why?
How
do
we
make
metric
reader
storage.
C
C
This
one
sorry
yeah,
so
the
these
changes
are,
I
already
added
these
changes
in
the
in
the
views,
pr
because
they
were
necessary,
along
with
the
change
of
the
aggregation
here,
so
aggregation
used
to
be
a
type,
and
now
I'm
changing
it
to
be
a
an
instance.
So
with
this
change
that
I'm
adding
it,
it
also
includes
this
one.
This
pair
is
no
longer
necessary.
I
did
not
want
just
to
close
it
right
away
without
discussing
this
with
anyone
else.
C
D
I
think
that's
fine,
okay
yeah!
I
I
see
that
the
tests
are
passing.
I
was
gonna
say
if
it's
the
tests
are
failing.
If
the
tests
were
passing,
I
was
going
to
say:
maybe
we
can
just
merge
it
and
then
we
can
just
address
the
merge
conflict,
but
that's
fine,
correct,
there's,
more
there's
more
work.
That
needs
to
be
done
for
this
to
pass
anyway,
so
you
might
as
well
just
make
it
part
of
your
pr.
C
That's
right
all
right:
we
don't
have
any
other
topics
or
issues
anything
else
that
someone
else
discussed.