►
From YouTube: 2022-02-17 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
Also,
the
the
discussion
that
you
guys
had
yesterday-
I
I
I
just
looked
at
it
this
morning-
was
that
and
I'm
looking
at
the
linked
issue
that
you're
talking
about
diego.
I
I
didn't
really
understand
what
situations
you
guys
are
talking
about.
Has
this
been
resolved
or
anything?
This
is
like
new,
okay.
C
The
discussion
we
had
was
regarding
views
and
the
use
of
wild
cards.
The
particular
discussion
we
had
has
been
resolved
aaron
pretty
much
resolved
it
with
the
provided
answers.
The
issue
that
aaron
opened,
I
believe,
is
still
open.
C
A
C
To
the
scope
of
the
meter
right,
it's
related
to
the
fact
that
specification
right
now
doesn't
allow
for
views
to
match
more
than
one
instrument
if
the
name
of
the
view
is
defined,
but
it
is
okay
to
match
more
than
one
instrument
if
the
view
is
defined
if
those
instruments
belong
to
different
meters.
Yes,
so
the
the
intention
is
to
make
the
the
wording
accept
that
situation,
where
we're
instrumental
and
everything
makes
sense.
A
In
that
regard,
for
you
yes,
yes,
definitely
awesome.
Yeah
sounds
good.
C
Oh,
by
the
way,
the
views,
pr
that
I
have
right
now
has
been
addressed,
I
mean
I
have
implemented
it
pretty
much,
assuming
that
the
issue
that
aaron
reported
has
been
solved
somehow
sure,
so
we
in
this
vr
as
it
is
right
now
we
already
support
wildcard
matching
and
we
already
support
matching
more
than
one
instrument
as
long
as
they
belong
to
different
mirrors
when
they
use
name.
A
I
guess
we
can
get
started
now.
It's
a
six
after
yeah,
thanks
guys
for
for
joining
our
weekly
sig
as
usual.
Just
you
can
feel
free
to
add
your
name
to
the
attendees
list
we'll
be
going
through.
You
know
a
list
of
topics
pr's
and
issues
as
usual
feel
free
to
add
any
of
them
that
you
want
to
get
addressed
quickly.
A
Just
taking
a
look
at
the
prs
and
issues
today,
I
think
a
majority
of
them
will
be
metrics
related.
You
know,
aaron
and
diego
have
been
trying
to
streamline
their
prs
and
it'll
be
great
if
people
help
them
out
with
that.
So
looking
at
this
right
now
doesn't
seem
like
we
have
any
over
overarching
topics
to
talk
about.
A
So
if
nobody
else
says
anything,
we
can
go
right
into
the
prs.
That's
cool.
A
All
right
now:
okay,
first
one
metric
reader
storage
by
aaron.
So
I
added
this
just
now.
I
just
had
a
couple
of
questions,
so
I
want
to
confirm
that
the
view
storage
in
this
pr
is
the
same
as
the
view
instrument
match
right.
A
The
other
one
cool
cool
awesome,
so
my
question
is:
was
there
a
reason
for
moving
the
asynchronous
logic
from
the
consumer
to
the
reader
storage.
D
Yeah,
so
so,
basically,
when
a
single
metric
reader
collects,
you
only
want
to
record
the
async
instruments
at
that
time
for
that
metric,
reader's
data
right,
if
you
sent
it
to
all
of
the
instruments.
Sorry,
if
you
send
it
to
all
the
metric
reader
storage,
like
all
of
the
backing
storage
for
the
different
metric
readers,
you
would
end
up,
like
you
know,
double
counting
or
something
like
that
or
taking
different
measurements
right.
A
Yep,
okay,
yep.
That
makes
sense
to
me.
I
just
want
to
confirm
that
other
than
that,
the
the
pr
looks
great
to
me.
Thank
you.
Yeah.
D
There
is
yeah,
one
alternative
is
to
leave
it
in
the
consumer
thing,
but
then
just
pass
the
measurements
to
that
specific
reader.
So
basically
the
same
just
yeah.
Right
thanks.
I
don't
know
if
anybody
has
that
thoughts
on
that.
C
I
added
a
comment
yesterday
right
there
regarding
the
usage
of
sdk
configuration,
so
I
believe
it's
getting
a
little
bit
hard
to
define.
I
guess
what
the
sdk
configuration
object
is.
We
have
been
pretty
much
putting
stuff
inside
and
now
we
are
also
making
it
register
the
ace,
the
synchronous
instruments.
C
So
I
don't
know
it
kind
of
I'm
getting
hunched
that
it's
getting
a
little
bit
yeah
hard
to
understand
what
what
that
object
is
since
more
and
more
stuff
is
getting
added
to
it,
and
I
wonder
if
the
stuff
that
is
moved
in
sec
configuration
doesn't
actually
belong
to
the
meter
provider,
which
I
think
it
was
before.
If
I
remember
correctly,
there
is
station
of
asynchronous
instruments
was
happening
in
the
media
provider
before.
D
A
C
Yeah,
I'm
not
against
having
views
and
the
synchronous
or
even
asynchronous
instruments.
D
We
know
that
there's
going
to
be
a
multiple
callbacks
that
support
multiple
instruments
and
instruments
supporting
multiple
callbacks,
in
which
case
this
is
all
going
to
change
a
bit
anyway,
but
the
the
tricky
part
there
is
it's.
What
the
api
looks
like
it's
going
to
be
meter.addcallback,
and
then
you
pass
a
callback
and
a
list
of
instruments
that
can
be
recorded
against
that
callback.
D
Okay.
So
so,
when
we
do
that,
it's
not
gonna
be
at
the
meter
provider
level
right
like
like,
we
could
keep
a
map
in
there,
but
we're
gonna
have
to
rethink
it
anyway.
C
And
what
I'm
trying
to
say
is:
how
is
that
change
that
you
just
mentioned
going
to
effect
as
the
sq
configuration
as
it
is
right
now.
C
D
Yeah,
or
rather
the
instruments
that
I
can
be
recorded
against
for
the
callback.
A
But
what
are
you
gonna
say
laden
right
right,
so
let
me
think
so
is
that
is
that
being
discussed
like
that
implementation,
detail,
yeah.
A
D
Yeah,
like
I,
don't
think
it
actually
matters
that
much
for
like
that,
it's
at
the
meter
level
right,
but
my
point
is
I
I
don't
know
it
would
be
really
weird
to
have
meter
provider,
dot,
callback,
call
all
callbacks
or
something
like
that
right,
right,
right,
yeah,.
A
C
Okay,
but
all
these
callbacks
are
going
to
belong
to
instruments
right
so
aren't
we
going
to
follow
the
same
procedure
of
going
through
all
the
asynchronous
instruments
and
for
every
synchronous
instruments
calling
every
callback,
but
that
is
assigned
to
it.
A
Right
so
maybe
we
should
work
on
the
assumption
that
of
the
current
spec
right
now,.
A
C
That
was
the
original
issue.
Yes,
I
mean
I'm
just
getting
the
feeling
that
we
are
having
this.
This
object
named
sdk
configuration
which
it's
really
hard
to
understand
what
it
does,
or
I
mean
what
what
is
what
it's
supposed
to
be
right,
since
it's
doing
more
and
more
stuff.
A
Well,
my
understanding
like
with
this
is
like
the
tracing
equivalent
of
like
you
know
what
sampler
am
I
using
what
resource
I'm
using
you
know
stuff
like
that,
so
the
metric
readers,
views
and
resource
makes
sense
for
me
to
be
in
here.
It
seems
like
we
have
async
instruments
in
here,
because
we
just
have
nowhere
else
to
put
it
and
sdk
configuration
is
like
accessible
globally
or
not
globally,
but
like
easily
accessible
from
like
down
the
down
the
metric
export
chain
right,
yeah.
A
To
keep
the
original
definition
like
it,
I
understand
your
concern,
diego
about
this.
C
To
be
able
to
access
insta,
let's
say
this
attributes
that
will
belong
to
the
media
provider,
but
will
be
private
and
for
the
sake
of
our
implementation,
I'm
not
that
I
mean,
I
think
we
have
done
it
before
several
times
that
we
in
our
sdk
implementation
access,
private
attributes
of
instances
of
our
class
that
also
belong
to
the
sdk.
D
C
D
And
just
that's
that's
true
but
like
in
this
case,
if
you
have
a
reference
to
this
sdk
configuration
and
we
add
new
async
instruments,
then
you
you
don't
need
to
have
it
passed
every
single
time.
You're
called
like
you'll
see
those
updates,
because
you
have
a
reference
to
the
same
one.
That's
shared
across
all
the
different
components.
Right.
A
D
Yeah,
what
what
I
think
in
the
java
one
they
have
something
called
meter
shared
state,
their
design's,
a
bit
different,
but
it
has
basically
all
the
instruments
and
instrumentation
library
info
and
whatever
other
stuff
it
does
this.
So
would
you
prefer
a
different
name
like
sdk
shared
state
or
something
like
that
or.
D
A
For
the
sorry
for
interrupting,
so
so
the
java
implementation
is
it
pretty
much?
Has
these
classes
it's
just.
It's
called
something
different.
It's.
A
Place
that
they
store
the
instruments
that
can
be
accessed
by
their
collection
components,
correct.
A
Yeah-
okay,
oh,
and
also
going
back
to
what
you
said
about
the
pattern
that
you'd
you
don't
like
the
accessing
the
private
attribute
pattern.
Are
you
referring
to?
Like
you
know,
we
have
id
generator
resource,
sampler
and
stuff
like
that
within
the
tracer
provider,
equivalently,
and
then
we
have
to
access
those
with
the
other
components.
D
Yes,
yeah,
I
mean
I'm
not
I'm
not
really
a
fan
of
it,
but
just
because
it
makes
it
fuzzy
to
know
which
things
are
like
private
first,
which
things
are
like.
I
don't
know
right
right,
yeah
I
get
I'd
rather
just
not
have
to
silence
any
lead
warnings
and.
D
Do
you
go
if
I,
if
I
put
all
these
things
on
the
meter
provider,
though,
would
that
actually
be
cleaner,
though
I
feel
like,
rather
than
having
two
things,
we
would
have
just
one
thing
with
a
whole
bunch
of
stuff
on
it.
Instead,
right.
C
Yeah,
so
what
we're
doing
here
is
that
we
are
stuff
that
is
just
passed
down
to
the
mini
provider.
We
are
just
pretty
much
putting
it
together
into
this
sdk
configuration
object
and
then
passing
it
down.
I
personally
feel
that
it's
just
another
step
we
could
pass
the
media
provider.
C
I
am
actually
not
not
opposed
to
making
views
or
metric
readers
or
everything
else,
public
read-only
properties,
since
I
think
that's
pretty
much
what
we
are
doing
and
I'm
passing
the
media
provider
since,
and
we
just
save
us
from
having
an
another
class-
and
I
also
do
we
in
the
original
design.
The
synchronous
instruments
were
also
registering
into
another
provider
right.
D
C
D
A
D
It
was
basically
like
yeah,
it
would
get
reported
to
the
measurement
consumer
like
if
you
want
to
put
all
these
properties
on
the
measurement
consumer
that
works
too.
D
Correct
yeah
yeah
should
we
maybe
take
this
offline
yeah.
A
Yeah
yeah
cool.
That's
a
good
discussion,
though
I
feel
like
I
do
agree
with
diego's
point
about
finding
a
good
place.
To
put
this
also,
I
am
also
taking
a
look
at
what
we're
doing
for
tracer.
It's
like
kind
of
a
mess
like
span
limits
were
passing
down.
You
know,
sampler.
We
expose
like
publicly
resource
we
expose
as
a
property,
but
it's
private.
You
know
it's
like
a
bunch
of
different
stuff
like
id
generator,
is
just
public
as
well
so
yeah
kind
of
ugly
yeah
but
anyways
yeah.
A
A
Okay,
any
other
discussion
or
anything
else
related
to
aaron's
pr
awesome
cool.
All
right.
I
also
put
the
next
one
the
view
instrument
match,
taking
a
look
at
the
time
of
a
bit
over
30
minutes.
So
let's
try
to
get
through
this
quickly.
A
So
I
think
the
my
question
was
for
a
few
instrument
match
related
to
this
warning
right
here
for
consume
measurement.
A
So
this
this
step,
diego,
is
like
it's
like
filtering
the
attributes
based
off
of
the
view
right
if
yeah
right,
so
this
makes
sense.
So
how
come
we
need
to
like?
We
don't
like.
We
need
to
pinpoint
measurements
that
have
no
attributes
well.
C
If
we
don't
have
any
attributes,
then
okay,
let
me
start
again:
the
attributes
are
being
used
as
a
key
in
a
dictionary.
C
D
C
A
Nice,
so
could
you
kind
of
explain
what
what
the
following
logic
is?
After
that
sure.
C
I
think
before
we
used
a
function
that
took
a
dictionary
and
kind
of
made
it
a
string
and
frozen
said
is
the
equivalent
of
that,
but
it
may
be
faster
because
of
implementation
details,
and
I
also
think
it
it's
it's.
It's
cleaner
not
not
require
an
extra
function
that
can
do
something
that
is
done
with
the
built-in
function.
C
So
attributes
are
made
like
that
a
frozen
set
so
that
it
can
be
used
as
a
key,
then
that
key
in
the
attribute
segregation
dictionary
points
to
an
aggregation
object
that
is
instantiated
in
line
75.
A
C
So,
and
also
that,
that's
a
reason
why
I
think
aggregation
the
views
should
receive
a
class
in
the
as
in
the
aggregation
field
of
the
view,
we
should
pass
a
class,
because
this
is
the
class
that
ends
up
being
aggregated
yeah.
Instantiate.
Sorry
in
line
75.
A
C
Yep
right
here,
yes,.
A
C
So
the
aggregation
that
is
being
passed
there,
yes,
is
supposed
to
be
a
class.
C
It
also
matches
because
instruments
should
also
have
a
default
aggregation
class.
So
if
that
aggregation
is
so
when
is
the
moment
of
creating
the
aggregate
the
view
the
view
instrument
match
objects?
What
we
do
is
that
we
take
a
look
at
the
aggregation
class
in
the
view,
and
if
it's
not
there,
we
use
the
default
aggregation
class
of
the
instrument
and
one
of
those
we
end
up
instantiating
and
that's
why
I
think
it's
it's
the
right
thing
to
use
a
class
argument
here
is
a
discussion.
B
D
Okay,
I
don't
know
why
it
doesn't
show
here
on
the
code
side.
Do
you
see
any
comment
from
me
in
here.
D
It's
in
the
views,
yeah
it's
in
this
pr
is
another
you
could
just
search
for.
Is
it
intent
or
sorry?
You
can
search
for.
D
D
Sorry,
but
whatever
class
do
we
have
so
like
the
java?
If
you
look
at
the
java
example,
you
linked
you,
can
you
can
open
that
it.
D
Is
not
the
same
class
so
this
this
method,
which
does
the
get
aggregation,
returns
an
internal
aggregation
but
you'll
notice
that
there's
no
aggregation
behavior
in
this
interface.
D
Because
it's
not
part
of
the
spec
right,
like
the
aggregation,
is
not
part
of
the
spec
there's
no
public
interface.
That
says:
here's
how
you
implement
an
aggregator,
you
accept
measurements
and
and
then
you
should
return
otlp
points
or
anything
like
that
and
I
think
there's
a
good
chance.
Something
gets
added
later
and
it
will
be
more
prescriptive.
B
Are
you
just
suggesting
that
we
have
like
an
empty
public
interface
that
we
expose?
Instead,
that
then
gets
implemented
by
the
sck.
D
Yes
or
sorry,
I
think,
there's
a
few
options.
I
initially
said
an
enum,
but
theo
made
a
good
point
that
if
we
do
an
enum,
then
if
we
do
a
class
later,
it
will
be
not
compatible.
D
Stuff
inside
of
it,
but
if
they
wanted
to
add
like
the
actual
aggregation
methods
there
later,
they
can
do
that.
C
That's
fine,
I
think
what
we
can
do
is
we
can
create
an
abc
name,
some
aggregation
or
last
value
or
histogram
aggregations
with
a
bunch
of
abcs
and
use
that
abc
there
and.
C
A
Fine,
I
think
we
can.
We
can
follow
that
approach.
Hey
question
is
this
field
only
exposed
because
we
want
to
have
the
ability
to
have
aggregations
that
are
not
the
default
aggregations
for
instruments?
A
A
A
C
I
think
I
am
okay
with
doing
what
what
aaron
is
suggesting
here
and
I
personally
don't
think
we're
gonna
I
mean
we
can
move
it
for
later.
I
think
we're
gonna
end
up
doing
the
same
thing.
A
A
What
was
I
talking?
Oh
right,
yes,
oh
yeah,
aaron,
just
to
clarify
the
so
that
means
like
the.
If
there's
an
empty
frozen
set,
they
will
all
go
through
one
aggregation
right
like
and
it's
okay
to
be
used
as
a
key.
D
A
Sounds
good
and
diego
just
to
also
clarify
like
order
doesn't
matter
for
frozen
set
right?
No,
it
says
it
so
awesome
cool
sounds
good.
This
makes
sense
to
me.
A
Awesome
nice.
I
think
that's
all
the
questions
I
had
for
this
vr.
It
looks
good
to
me.
Does
anybody
else
have
any
discussion
topics
for
this.
C
A
B
D
Great,
I
think
the
we're
gonna
talk
about
the
the
view,
one,
the
2391
again
or
because
I
have.
A
One
it's
it's
next,
it's
right.
D
A
Yeah,
okay,
cool
anything,
any
other
comments
for
reviews
from
a
match.
A
D
Yeah
I
haven't
looked
at
the
logic
again
yet,
but
I
wanted
to
talk
about
the
underscore
match
method
again.
C
D
Talked
about
this
briefly
last
week
and
whether
or
not
people
should
be
able
to
override
it,
so
I
think
the
thing
we're
missing
is
like
the
convention
of
a
single
underscore
would
be
a
protected
method,
which
means
that
somebody
who
subconsciously
can
override
it
or
any
any
subclasses
of
this
can
call
that
method
right.
D
If
if,
on
the
other
hand,
it's
public,
that's
fine
too,
and
people
can
override
it,
it
just
is
going
to
be
less
obvious
to
them.
To
not
do
that,
so
I
think
we
should
figure
out
if
we
want
to.
Let
people
do
that
or
if
we
want
a
different
sort
of
predicate
based
way
to
say
hey.
I
want
to
make
a
view
that
has
this
matching
behavior,
so
we
I
think
we
should
decide
between
those
two,
maybe
not
right
now,
but
we
should
track
it.
D
The
only
thing
I
want
to
call
is,
if
you
do
make
this
double
underscore:
it
won't
sorry,
if
you
leave
it
single
underscore,
then
we
have
that
thing.
We're
just
discussing
again
what
we're
calling
private
methods
on
classes
which
I
which
I'd
like
to
avoid,
because
it
makes
it
very
confusing
like
who
who's
allowed,
to
call
it
and
who's,
not
within
the
sdk,
and
if
you
make
it
double
underscore.
Instead,
you
can't
call
it
because
it
will
python
at
one
time
will
will
change
the
name
of
the
functions
that
you
can't
find.
It.
C
Yeah,
I
actually
prefer
to
make
match
a
private
method.
I
understand
that
that
would
mean
we
somewhere
else
in
the
sdk
end
up
calling
a
private
method
and
having
to
add
a
filing
comment
to
disa
disable
that
warning
just
because
I
always
prefer
to
keep
the
tx
v8
the
public
api
to
a
minimum
right.
If
not,
we
commit
ourselves
to
keeping
match
there
forever,
and
maybe
we
can.
Maybe
we
don't
want
that
later.
C
So
I
understand
it's
an
inconvenience
with
pilot
and
everything
else,
but
I
think
keeping
the
the
public
api
smaller.
It's
it's.
A
More
important,
you're
saying
you
rather
keep
it
either
underscore
or
double
underscore
you
just
don't
want
it
to
be
public
right.
I
don't
I.
I
prefer.
C
Not
to
do
anything
public
pretty
much
unless
the
specification
requires
it,
but
I
I
try
to
keep
it
really
really
tight
there.
But
what
was
the
other
reason?
Oh
yeah.
C
So,
okay,
now
we
go
going
to
the
the
question
that
aaron
has
regarding,
should
we
allow
custom
views
or
views
that
have
their
custom
maps?
C
To
be
honest,
I
don't
think
there's
anything
we
can
do
if,
if
someone
wants
to
create
their
own
view
and
their
custom
matching
behavior
go
ahead.
Well,
we
can't
stop
them,
so
I
don't
see
much
point
in
in
trying
to
implement
it
somehow
that
it
is
not
possible
to
do
it.
I
I'm-
and
that
also
applies
to
the
rest
of
our
implementation.
If
someone
wants
to
create
a
custom
span
or
a
closed
custom,
tracer
provider
or
trace
or
whatever
right,
they
can
do
that
they
can.
D
Right,
my
point
is:
if
we
want
that
to
be
the
api,
we
should
just
make
it
public
and
then
make
it
easy
for
people
to
do
and
document
that,
because,
like
we
heard
in
the
spec
meeting,
I
think
at
least
java
and
uh.net
have
made
it
so
that
you
can
pass
either
like
a
predicate
or
you
can
subclass
the
view
and
make
your
own
matching
behavior
yeah,
but
that
is
not
inspect
right.
D
Yeah!
That's
right!
It's
not
it's
not
in
the
spec,
but
if
you
want
to
do
it
later,
what
I'm
trying
to
say
is
we
don't
have
to
just
leave
this
if
you
make
it
under
a
single
underscore
and
somebody
subclasses
it
and
they
pass
in
a
view
they
can
like.
The
convention
is:
oh,
it's
fine
to
override
a
protected
method,
right
yeah.
D
C
Do
anything
to
support
custom
views
until
that
is
interspec.
A
I
think
aaron's
point
is
like:
if
we
do
release
this
it'd
be
very
difficult
to
have
that
behavior
implemented.
C
If
we
then
want
that
to
be
possible,
we
can
pretty
much
have
documentation,
saying
subclass
this
view
class
and
implement
your
own
views.
Your
own
match
methods.
C
D
No,
no,
I
think
I
think
that's
okay
and,
like,
like
david,
said,
we
should
document
it.
I'm
just
saying.
If
we
want
to
hide
this,
we
don't
there's
like
an
easier
way
to
do
it
without
doing
all
the
pilot
stuff
and
like
we
could
literally
just
take
this
method
and
move
it
somewhere
else
off
of
the
class
sure
I
I.
C
C
Sure
I
I
understand
I
I
I
also
find
it
I
mean,
I,
I
think
it's
less
than
ideal
when
we
in
another
instance
of
the
sdk
called
a
private
method.
That's
another
thing
in
this
case.
It's.
C
C
Sure
but
then,
then
you
are
pretty
much
splitting
the
what
the
view
does
in
separate
things
so
and
that's
the
only
thing
that
the
view
does
that
the
only
thing
that
the
view
does
is
collect
instruments.
A
D
F
D
F
Yeah
diigo
was
saying
that
this
logic
should
be
belonging
to
the
view,
because
that
core
function,
like
that's
one
of
the
core
functionalities
of
the
view
I
mean,
if
that's
I
mean,
if
we
are
going
to
that,
then
I
mean
why
not
make
it
public
like
it's
like
one
of
the
like,
if
you're
considering,
that
has
to
be
the
core
functionality
of
the
view
on
them.
C
End
user
will
not
it's
not
expected
to
call
much.
C
It's
also
not
defined
in
the
spec
and
every
time
we
make
something
public
we
put
ourselves
in
trouble
right
because.
A
C
A
And
then
what
aaron's
saying
is
like,
since
it's
not
like
explicitly
defined
and
respect
views,
is
just
a
a
set
of
configurations.
It's
like
going
by
your
logic,
it's
it's
fine
for
it
not
to
be
in
the
same
class
right.
This
is
just
something
like
an
implementation
detail
that
we
made
up,
but
honestly,
like
I
think
we
shouldn't
spend
too
much
more
time
on
this.
It's
kind
of
just
like
a
lint
preference
kind
of
easiness
kind
of
preference.
A
So
if
we
just
come
with
the
consensus
right
now,
we
just
kind
of
table
this
spending
a
bit
too
much
time.
C
Yeah,
I
think
we
should
follow
the
approach
that
is
defined
here
and
if
the
moment
comes,
when
the
spec
says
the
views,
custom
views
should
be
supported.
I
think
we
can
pretty
much
just
add
a
some
documentation
that
says
to
create
your
own
custom
views
subclass
these
and
implement
the
others.
A
Yeah,
I
understand
okay
cool
second,
for
the
sake
of
time,
let's
just
leave
it
at
that.
A
I
might
have
missed
it,
but
there
was
like
a
bunch
of
logic
after
the
constructor
before
was
that
like-
and
I
had
a
question
about
that-
was
that
kind
of
like
resolved
or.
C
What
happened
there?
Yes,
so
I
added
that
yesterday,
the
line
one
one
one.
C
So
what
I'm
trying
to
do
there
is
to
implement
this
view
in
a
way
that
supports
the
the
issue
that
aaron
brought
up
about
metrics.
I'm
sorry
views
that
have
a
name
allowing
multiple
instruments
to
be
matched
as
long
as
they
belong
to
different
meters.
C
A
Okay,
I'll
have
to
take
a
look
at
that
again.
I
think
my
question
before
was
remember
you
had
the
like.
It
throws
an
exception
every
time
the
view
name
is
defined,
but
some
other
criteria
is
also
defined.
A
C
F
So
these
these
other
comments
are
very
minor,
so
I
had
a
different
question
about
this
thing.
Yeah
this
one
like
you
had
earlier
logic
that
would
prevent
this
configuration
like
if,
if
there
is
a
match
and
if
there's
a
way
that
multiple
instant
match,
but
now
that
you
updated
the
logic
to
support
the
defenders
like
I,
I
think
that
logic
is
fine.
But
how
are
we
handling
like
this
specification.
E
C
Yeah
that
specification
part
is
going
to
change
and
it's
going
to
be
made
so
that
it
allows
for
matching
more
than
one
instrument
as
long
as
those
instruments
belong
to
different
meters.
So.
F
I'm
sorry
this
was
the
question.
So,
if
is,
is
this
how
it's
supposed
to
be
like
on
the
some
which
one
if
there
are
multiple
first
one
matches
and
the
rest
are
ignored,
or
do
we
want
to
not
allow
such
behavior
that
that
was
the
question
I
had.
A
C
No,
no,
what
happens
is
that
the
mirror
may
have
instruments
that
whose
names
can
match
the
same
wild
card.
So
maybe
you
have
two
instruments.
One
named
fu.
C
F
Yeah
I
saw
that
updated
logic,
so
this
was
the
question.
So
respect
says
is
that
you
do
not
allow
views
like
with
like
that
match
the
multiple
instrument,
but
our
car,
like
this
implementation,
is
that
it
allows,
but
only
the
first
instruments
that
you
know
that's
received
is
considered,
which
I
think
is
like
not
really
what.
C
Okay,
yes,
I
I,
I
think,
the
way
that
the
specification
is
redacted
is
wrong,
because
pretty
much
the
specification
says
views
that
match
more
than
one
instrument
should
not
be
allowed
to
be
declared,
but
that
will
require
views
to
know
the
future,
because
when
you
declare
a
view,
you
don't
know
what
instruments
you're
going
to
end
up
matching
or
not
so
the
way
that
the
the
specification
is
worded
now.
I
think
it
is
not
correct.
I
in
the
in
the
issue
that
are
created.
C
I
added
a
comment
regarding
that,
because
I
think
that
the
specification
can't
be
written
like
that,
because,
because
of
that,
it's
when
you
declare
the
view
you
don't
know
what
instruments
will
end
up
matching
or
not.
So
it's
it's
like
you
need
to
know
the
future
and
that's,
of
course,
not
possible.
So
I
think
the
what
the
specifications
should
say
is
that
is
that
should
define
what
the
view
should
do
if
multiple
instruments
match
either
select
the
first
or
drop
them
all,
or
I
don't
know
something.
B
F
Yeah,
that's
a
good
good
point.
I
think
I
would
like
to.
C
C
Question
because
pretty
much
what
I
have
done
is
that
I
have
pretty
much
decided
that
the
specification
is
wrong.
This
is
the
the
way
that
it
can
be
done,
but
I
just
picked
up
an
arbitrary
implementation
and.
C
C
Concerned
now
that
this
is
going
to
be
blocked
until
the
specifications
right,
I
don't
know
if
I
can
move
this
into
a
separate
vr.
A
F
Basically,
the
issue
is
that
we
are
not
supposed
to
set
any
default
propagators
in
the
api,
but
we
are
doing
it
in
the
api
part,
so
basically
it
should
be
set
to
some
knob.
F
Yeah
I
was
asking
if
you
understood
the
issue
so
issue
is
that
we
should
not
be
setting
the
default
propagators
in
the
api.
It
should
be
a
nasty
configuration,
but
right
now
we
are
doing
it
in
the
api,
which
is
we
should
actually
be
setting
it
to
some
propagator.
So
yeah,
that's
the
issue.
So
what
do
we
do
about
like?
What
do
you
think
we
should
be
doing.
F
C
F
E
F
Yeah,
so
they
wanted
to
go
so
they
wanted
to
do
this
in
the
go.
And
then
you
know
one
of
the
go
maintenance
found
out
that
they
should
not
be
part
of
the
api
and
should
be
part
of
the
specification
and
then.
B
F
Yeah,
so
so
the
discussion
that
I
followed
from
the
other
repo
is
that
nobody
is
doing
that
right
now.
It's
only
the
python
sdk,
but
then.
F
Sure
I
just
wanted
to
bring
it
to
everybody's.
A
Cool
sounds
good;
okay,
any
other
pressing
topics
that
people
need
to
address.
A
All
right,
if
not
I'll,
see
you
guys
next
week,
then
thank
you
later.
Everyone.