►
From YouTube: 2021-03-04 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
B
C
D
A
B
Let
let's
see,
let's
put
a
topic
to
it
right
because
I
think
greg
mentioned
that
he
he
he
could
do
that
and
we
can
move
at
least
a
few
hours.
Nothing
yeah.
B
Yeah
and
also
datadog
has
a
bunch
of
folks
in
europe
right,
so
it
will
be
also
a
better
time
for
them.
So
correct.
B
B
All
right,
I
think,
I
think,
you're
good
so
robert
david
and
rasmus.
B
Yet
because
he's
you
know
estonia,
the
time
zone
for
him
is
pretty
bad
for
this
meeting,
but
they
haven't
been
working
and
we
recent
merged.
I
think
that
is
still
a
pending
one
for
renaming,
but
we
should
be
able
to
kind
of
have
the
open
telemetry
named
files
and
proper
good
different
key
ready
to
test.
So
I'm
more
mentioning
this.
So
if
people
have
a
chance
to
give
a
try,
I'm
planning
to
give
a
try
today
to
msi
and
this
kind
of
structure,
how
that's
going
robert
has
the
semantic
convention
in
progress.
B
There
is
anything
that
you
want
to
discuss
here,
robert
or
the
discussion
is
going
well
on
the.
A
The
issue
itself,
so
maybe
just
one
proposal,
because
I
kind
of
feel
personally
that
it
will
be
more
efficient,
just
put
the
most
critical
like
comments
there,
that
you
find
as
blockers
and
then
merge
it,
and
I
can
make,
I
don't
know
different,
even
github
issues
or
I
I'm
a
guy
that
basically,
if
I
say
that
I
will
do
something
I
would
just
let
you
know
if
there
will
be
a
problem
or
create
a
github
issue.
If
I
want
so
whatever
is
not
critical,
I
prefer
to
merge
it
and
have
like
smaller
pull
requests.
E
Finished
looking
over
it-
and
I
added
one
last
comment,
but
nothing
blocking
the
other
stuff.
We
can
definitely
address
in
a
follow-up,
but
thank
you
so
much
for
doing
the
the
new
header
http
tags.
I
think
that
looks
really
good.
A
I
think
that
also
in
the
name,
we
should
do
it
in
this
video
another
one.
Basically
whoa,
the
guy
from
madrid,
tony
and
andrew
said
that
probably
some
of
the
steps
should
be
not
done
as
I
should
not
probably
set
those
stacks
using
set
set
tag
but
use
this
additional
properties
for
performance
reasons,
but
I'm
not
sure
if
it's
critical
or
not
blocking
but
okay.
B
Yeah
and
as
you
mentioned
robert,
I
think
the
optimization
com
can
come
separately
right.
Yeah,
that's.
H
And
one
thing
to
keep
in
mind
is,
as
you
take
data
dock
people.
One
thing
to
also
drive
through
is
that
a
code
is
merged
back
into
data
docs,
so
that
the
whole
point
of
this
particular
architecture
is
that
we
don't
diverge
code
bases
so
that
when,
when
we're
in
sync
that
I
will
not
always
be
able
to
be
there.
H
But
when
you
kind
of
chat
with
people,
just
make
sure
that
one
of
the
that
not
only
we
get
feedback
for
the
hotel
hotel
version
of
things,
but
that
we
are
also
kind
of
aware
of
merging
back
in
both
directions
so
that
things
are
synchronized.
H
It
doesn't
matter
so
so
I
think
from
engineering
perspective
it
doesn't
matter,
we
can
do
whatever
is
most
convenient.
I
don't
know
whether,
like
other
hotel
people
have
concerns,
because
there
is,
there
is
one
more
step
that
would
require
them
to
merge
from
datadog
into
into
into
hotel.
I
don't
really
care
which,
which
order
of
things
happens
there.
H
H
Yes,
it's
it's,
it
may
be
the
most.
So
so
I
as
an
engineer,
I
don't
care
as
a
as
a
hotel
person.
If
I
wear
the
auto
head,
I
think
that
probably
the
most
appropriate
way
for
this
is
to
first
merge
into
auto
and
then
from
auto
into
data
dog,
of
course,
of.
B
So
greg
this
touch
is
in
a
in
a
very
important
point,
because
we
haven't
been
doing
a
bunch
of
stuff.
We
perhaps
should
do
a
pass
of
the
stuff
that
we
need.
We
did
recently
to
see
the
stuff
that
we
would
like
to
kind
of
having
the
pr
like
roberts,
mentioning
opening
doing
the
same
on
data
dark
side.
H
I
think
this
makes
sense.
We
should
we
should.
What
is
the
best
way
of
doing
this?
I
think
some
zeke
are
you
aware
of
of
the
things
that
has
happened,
because
I'm
I'm
not
looking
at
the
tracer
right
now.
So
are
you
aware
of
the
changes
because
then,
if,
if
it,
if
you
are
then
taking
an
hour
at
some
point,
might
be
a
good
idea.
H
Whether
you're
aware
of
the
changes
that
have
been
recently
made
to
the
hotel
repo
so
that
you
can
have
a
informed
opinion
about
what
to
merge
back.
E
Got
it?
No
I'd
have
to
do
a
review.
F
B
If
you
wanna,
we
can
schedule
something
together
and
we
go
over
them.
B
I
would
say
not
not
today,
but
then
perhaps
tomorrow
morning
or
something
like
this,
so
we
can
get
robert
and
david
that
also
make
the
change
we
get.
You.
B
From
there
just
started
this
morning,
and
I
actually
encounter
one
issue
that
I
want
to
have
a
quick
chat
about
before
I
go
further,
but
we
should
be
done
this
week
this
week,
I
think
tomorrow
or
friday
we
will
be
be
able
to
merge
the
pool
from
database.
H
Let's
finish
that
merge
so
that
we
have
a
clear,
clear
delta
and
if
it
takes
it,
takes
you
another
one
or
two
days
in
the
meantime,
I'll
sync
up
with
the
product
guys
so
that
they're
aware
that
we
are
going
to
take
like
a
couple
of
hours
doing
this
so
that
they
are
like
you
know,
so
that.
A
Doesn't
conflict
with
other
work?
I
think
that
apollo's
intention
is
not
only
to
do
it,
but
also
to
show
how
the
process
look
like
like
because
of
this
easy
cla
stuff
you
need
to
have
you
know
the
comments
from
the
guys
who
are
on
hotel
or
kind
of
kind
of
stuff
like
that.
So
pablo
is
cherry
picking,
and
I
think
it's
not
only
important
to
know
that
we
are
in
sync,
but
also
how
to
do
it,
how
to
merge
in
which
direction.
Sorry.
B
Yeah
this
this
is
actually
I'm
I'm
planning
to
document
the
steps
that
I
do
from
data
drug
to
hotel,
but
I
think
I
also
we
we
we
should
kind
of
think
about
the
stuff
that
we
did
recently
that
datadog
wants
to
pull.
You
know,
that's
that's
the
conversation
that
I
want
to
have.
Yes,
yes,.
H
H
Typically,
my
suggestion
was
finish.
This
emerge
from
data
doctor
auto
on
your
end
and
then
have
a
meeting
with
zach
and
whoever
else
necessary
from
datadog
to
put
back
from
auto
into
datadog.
I
don't
think
you
need
the
data.guys.
G
H
And
then
so,
when
is
a
good
good
convenient
time
for
you
to
to
do
the
other
things?
The
conversation
was
dated
to
guys
from
auto
insurance
data
doc
when
what
which
day.
B
I
I
think,
taking
association
as
soon
as
it's
larger.
I
think,
any
morning
time
in
pacific
time,
it's
reasonable
for
robert
and
david
to
be
on
the
meeting
right.
Can
you
guys
confirm?
Okay,
so.
C
H
But
I
meant
because
before
we
have
that
meeting,
we
need
to
finish
the
merge
from
data
dog
in
hotel
and
that's
why
I'm
asking
like
which
day.
But
by
when.
Will
you
be
finished
with
that.
B
H
Okay
zach:
is
it
something
you
can
help
with
that
conversation
I'll
I'll
paying
jay
so
that
he
is
aware
that
we're
spending
some
time
so
that
there
is
no
like
churn
for
for
time?
If
there
is
anything
else
that
we
need
to
complete
this
week
or
something.
B
Yeah-
and
I
don't
expect
this
to
be
kind
of
a
a
really
long
thing-
I
think
it's
it's
a
bit
harder
on
our
side.
I
think
we're
gonna
do
selected
cherry
picks
that
are
beneficial
for
the
the
ripple.
You
know.
B
I'm
I'm
gonna
get
I
it's
about
the
iapi
here.
There
were
some
changes
that
now
the
api
is
receiving
the
blob,
a
blob,
a
binary,
blob,
optimization.
B
B
B
You
know
so
it's
more
a
heads
up
that
I
will
have
to
do
this
on
the
hotel
side.
You
know
I
will
have
to
find
a
way
to
handle
the
difference
in
the
apis
and
the
hotel
needs
to
handle
these
different
exporters.
B
So
I
still
need
to
have
the
higher
level
there,
but
I,
of
course
I
want
to
have
a
way
to
to
keep
data
dog
with
the
current
code.
B
H
Some
kind
of
similar
dependency
injection,
like
we
have
for
the
for
the
tag
attachment
where
at
compile
time,
some
kind
of
choices
made
between
you
know,
which
component
converts
the
data.
B
Yeah,
actually,
yes,
compile
time
seems
reasonable
in
this
case.
You
know,
because
then
I
I
can
keep
the
the
same
interface
that
we
have
right
now
and
in
in
the
data
dark
case.
You
keep
the
interface
that
you
change
it.
You
know
all
right,
yeah
I'll
be
looking
at
that.
One
work
that
we
have
to
do
for
hotel
is
that
the
trace
ids
in
hotel
are
long.
B
They
are
128
bits
and
we
need
to
support
that,
because,
if
we
receive
the
contacts
from
outside,
we
need
to
to
support
that
david
is
gonna,
be
work
on
that.
B
I
pointed
him
through
the
recent
work
that
the
folks
in
microsoft
did
for
activity
trace
id
that
two
important
things
there,
I
think,
is
that
they
added
a
new
random
generator
that
avoids
the
problems
that
the
old,
random
generator
heading.net
about
concurrence
and
the
low
entropy.
B
So
my
suggestion
should
avid
is
kind
of
to
pull
that
code
from
dotnet.
They
implemented
a
standard
random
that
doesn't
suffer
these
problems
and
we
can
use
that
to
generate
so.
The
performance
is
not
going
to
suffer
the
problems
that
good
suffers
on
linux
and
we
should
get
128
bits
working.
B
H
I
think
it's
it's
an
engineering
discussion
that
is
hard
to
heart
should
answer
spontaneously.
H
I
think,
if
we,
if
it's,
if
it's
structural,
then
we
can
have
a
brief
issue
on
github
that
describes
the
specifics
of
what
needs
to
be
changed
and
then
we
can
review
it
as
a
high
level
thing.
If,
if
we
know
that
it
won't
degrade
performance,
then
I
would
definitely
give
it
a
serious
consideration.
I
mean
why
why
not
if
it
makes
things
better,
if
it
does
degrade
performance,
then
it
will
be
a
hard
sell
and
then
also,
I
think,
specifically
the
random
issue.
H
Did
we
not
solve
it
by
having
as
a
I
think
it
is
soft.
E
Yeah,
I
think
kevin
implemented
it
same
way.
They
did
on
dot
net
core
because
we
had
the
issue
on
dot
net
framework
builds.
So
if
you
need
another
reference
for
implementing
it,
you
can
check
and
see
what
we're
doing
in
our
span
id
generator
class.
B
Yeah
yeah,
what
dot
net
did
they
pick
up?
One
new
algorithm
that
accepts
more
a
bigger
entropy
when
starting
because
the
old
one
was
32-bit
and
also
had
a
bunch
of,
I
think
statics,
I
don't
know
if
they
resolved
their
statics
or
not,
but
they
have
a
good
solution.
I
don't
remember
exactly.
E
Got
it
yeah
that
might
have
more
entropy,
then
I
think
ours.
We
were
solving
a
timing
issue
with
thread
starts
and
sharing
seeds
specifically,
so
I
don't,
I
think,
yeah
you
might
find
a
solution
that
has
more
hp
than
what
we
do.
B
Yeah
so
david,
can
you
open?
I
issue
link
to
the
thingsing.net.
I
sent
you
the
link
via
our
tracking
system,
and
we
start
the
discussion
there
and
do
performance
numbers
and
have
numbers
with
that.
B
B
B
So
I'd
like
to
check
if
this
is
something
that
you
guys
are
also
facing
upstream
or
if
perhaps
I'll
read
fixed
and
when
I
pull.
E
Yeah-
and
maybe
we
can
look
at
that
specific
one-
we
as
of
like
three
months
ago,
we
started
to
aggressively
track
each
ci
failure
and
in
our
own
datadog
azure
devops
pipeline.
We
in
the
past
I
think
week
our
integration
test
pipeline
has
had
a
like
a
94
pass
rate.
So
it's
it's
been
going
up.
E
B
All
right,
so
the
one
that
I'm
seeing
constantly
is
this
one.
You
know
this
this
test
here
is
failing,
so,
okay,
I
could
either
skip
there
for
our
branch
for
now,
and
we
already
have
the
issue
and
we
follow
from
there.
E
That
actually
brings
up
an
interesting
point,
because
this
one
is
a
like
datadog
feature:
less
tracing,
but
more
just
metrics,
oh
yeah,.
G
E
Wondering
if
we
should
be
doing
a
review
at
some
point
to
like
excise,
codepaths
and
stuff
that
aren't
going
to
be
used
by
hotel.
B
Yeah,
no,
that's
that's
a
good
point.
You
know
we
are
not
doing
the
the
the
math
work
right
now,
but
I
I
have
to
say,
since
we
have
the
interesting
keep
things
going
in
both
ways
for.
E
E
B
B
I
I
think,
since
his
dependence
for
tests,
not
the
real
code,
I
think
the
best
way
to
experiment
with
that
is
to
have
some
prt
using
it.
So
we
can
kind
of
get
the
real
feel
besides
reading
the
docs
and
and
stuff,
and
if
people
agree
with
that,
then
I
think
we
can
start
to
use
them.
H
To
your
point,
paulo
in
the
product
itself,
I
think
people
who
just
this
is
mainly
for
for
the
new
folks
joining
just
to
reiterate
and
sorry.
If
it's
already
clear
like
for
the
actual
product
itself,
we
will
be
extremely
hesitant
taking
any
dependencies
exactly.
G
H
Yeah,
if
you,
if
you
are
thinking
that
some
library
is
cool,
most
likely
it's
because
any
any
library
that
we
use,
that
is
also
used
by
the
application
being
monitored,
is
a
conflict.
So.
H
F
H
Did
aha
cool
this
would
be
a
little
longer,
so
maybe
we
can
talk
about
time
for
a
few
minutes
first,
so
that
we
have
focus
on
the
demo
afterwards.
B
Yeah
so
robert
and
david
are
in
poland,
rasmussen,
estonia,
so
right
now
it's
kind
of
I
think
it's
like
11
o'clock
in
estonia,
poland,
so
yeah.
Let
me
let.
H
F
H
H
All
right,
so
we
have
yeah
it's
11
o'clock
a
bit
late,
maybe
something.
H
Because
much
earlier
it
starts
getting
into
early
morning
crunch
time.
Meetings
for
us
that
are
super
super
full
sure,
so
we
can
should
we
do
this
always
or
should
we
alternate
back
and
forth.
H
B
F
H
F
B
For
the
moment,
my
preference
is
to
keep
just
one
instead
of
alternating,
because
then
I
think
when
we
go
to
alternate,
we
have
to
go
kind
of
full
blow.
You
know
kind
of
having
one
that
is
almost
very
early,
so
people
kind
of
inject
and
join
and
one
that
is
very
late
on
our
time.
You
know.
H
Yes,
it
should
be
fine,
I
think,
for
for
me,
I
once
in
a
while
I
I
will
need
to
skip
because
I
might
have.
Let
me
just
double.
F
F
You
know
it
should
be
okay,
it
works
for
me.
B
So
I
I
I
just
gave
my
opinion
for
now
to
keep
just
one
time,
but
if
people
prefer
to
do
rule
for
me
is
also
fine.
I
would
like
to
hear
the
other
voices
in
the
meeting.
E
Yeah,
hey
really
quick
on
that
flaky
test.
I
can
confirm
it's
in
our
internal
tracking
dock
of
a
list
of
flaky
tests
that
we're
addressing
so
what
we
can
do
is
we
can
disable
it
in
hotel
and
then
once
we
we're
still
kind
of
going
through
it.
I
can
let
you
know
when
that's
addressed
and
we
can
well,
you
know
see
if
it's
still
reproducing.
H
Cool
okay,
so
basically
diagnostic
source.
So
we
have
had
had
a
long-standing
problem
that
we
can't
use
activities
or
diagnostic
source.
Very
well,
because
applications.
H
Because
for
that
we
need
to
take
a
dependency
on
the
diagnostic
source
library
and
if
an
application
is
already
using
that
library-
and
there
is
some
sort
of
version
mismatch-
then
we
we
can't
have
this.
So
we
cannot
be
completely
reliant
on
this,
especially
not
on
full
framework
because
on
other
not
quite
there
is
only
the
versioning
problem.
There
is
at
least
the
libraries
almost
always
there
anyway,
so
I
have
created
a
new
library.
H
For
now,
it's
called
datadog
dynamic,
diagnostic
source
bindings.
H
So
what
it
does
it
follows
an
algorithm
to
load
to
always
load
some
kind
of
diagnostic
source
dll
and
then
to
do
compiled
expressions
invocations
through
stubs
against
the
relevant
apis,
and
for
now
I
have
completed
and
tested
it
for
all
relevant
diagnostic
source
apis
and
not
for
activities.
H
So
very
briefly
about
what
it
does.
The
algorithm
is
very
similar
to
what
is
described
here
only
this
was
not
completely
precise,
but
in
a
nutshell,
when
this
whole
system
initializes.
F
Sorry
zoom
come
on.
Did
I
not
have
like
oh
yeah
here.
H
When
oh
hi
david,
just
basically
when
the
library,
when
the
whole
system
initializes,
we
scan
loaded
assemblies
and
if
we
are,
if
diagnostic
source
is
loaded
in
a
good
way,
I
will
describe
what
it
is.
Then
we're
going
to
use
it,
whichever,
whichever
version
it
is.
If,
if
and
only
if,
it's
loaded
in
a
good
way,
if
it's
not
loaded
at
all,
we're
requesting
the
runtime
to
load
it.
H
So
the
renter
will
go
away
and
use
whatever
agreement
users
to
look
on
like
to
probe
for
the
assembly,
and
then
after
the
library
is
after
the
tried
loading,
the
diagnostic
source,
then
we
look
again.
Is
this
loaded
in
a
good
way?
Now,
after
this
looking
once
and
trying
to
load
it
by
requesting
and.
H
So
after
requesting
to
load
it,
we
look
again
whether
it's
loaded,
the
good
way.
So
if
it
eventually
was
loaded
in
a
good
way,
we're
using
it,
if
not
we're
using
a
vendored
inversion
which
is
compiled
into
the
same
assembly
and
also
we
are
subscribing
to
an
assembly
loaded
away
event.
So
if
later,
the
application
decides
to
load
the
library
so
say
we
actually
did
the
fallback
on
the
on
a
version.
H
If
the
library
is
loaded
at
any
one
point
in
time,
then
we
scan
again,
and
we
look
again.
Is
this
a
good
way
and
if
it's
a
good
way,
we
switch
to
using
the
diagnostic
source
assembly?
If
it's
not
a
good
way,
we
continue
using
the
fallback
vendor
inversion
so
at
any
one
time
we're
either
using
the
library
loaded
into
the
application
by
the
application,
which
is
always,
which
is
guaranteed
to
be
in
a
good
way
or
we're
using
the
the
rendered
version,
and
we
switch
back
and
forth
always
preferring
the
good
way
now.
H
What's
a
good
way,
good
way
means
it's
loaded
exactly
once
so.
If
it's
loaded
into
the
up
domain
so
like,
if
it's
loaded
more
than
once,
then
it's
not
a
good
way
we'll
go
like
we
don't
know
which
one
to
to
attach
to
we
just
give
up
and
we
go
to
the
rendered
version.
H
Also,
it
must
be
loaded
into
the
default
assembly
load
context
if
it's
loaded
into
if
it's
loaded
more
than
once,
or
if
it's
only
once,
but
it's
not
in
the
default
assembly
load
context,
then
the
application
is
trying
to
do
something
with
plugins.
We
don't
know.
What's
going
on
we're
going
to
fall
back
to
vendor
version
and
the
last
condition
is,
it
must
be
at
least
version
4
4.
I
think
it's
quite
an
old
version,
the
first
one
she
ever
had
activities
in
it.
H
So
if
a
version
is
that
is
loaded
is
older
than
that,
it's
also
not
in
a
good
way.
So
those
are
three
conditions
that
we
need
to
fulfill
cool.
So
that's
what
what's
going
on
so
now
the
apis.
F
Let's
see
there
is
maybe
a
show
how
to
use
it.
It's
best
shown
so.
H
If
you,
I
hope
you
guys
remember
how
to
use
the
diagnostic
source
apis,
the
original
one,
because
if
you
don't
this
demo
will
make
less
sense
for
you,
but
so
this
way
you
create
a
diagnostic
source.
H
So
essentially
there
is
a
one-to-one
correspondence
to
existing
apis
with
very
similar
naming
you
create
a
diagnostic
source
in
this
way,
then
you
start
emitting
in
this
way
and
just
to
compare
it
here
is
the
original
api,
the
one
that
is
like
this
is
the
actual
diagnostic
source
api,
the
one
that
is
in
library,
so
you
create
using
a
very
similar
way.
Oops
sorry.
H
This
is
stub
same
thing
and
then
for
subscribing
two
diagnostic
source
events
also
very
very
similar.
This
is
original.
You
have
to
subscribe
a
old
listener
that
will
receive
a
diagnostic
listener.
Then
you
check
for
the
names
you
call
subscribe
for
stubbing
again,
you
is
the
same
thing.
You
have
a
no
listener,
you
get
the
stub
you
check
for
the
name,
you
subscribe
to
events
and
then
the
handlers
look
essentially
identical.
H
So
that's
the
api.
Now
one
thing
to
consider
is
that
the
stopped
api
can
always
throw
you
never
know
whether
or
not
it
will
throw.
The
reason
is
that,
exactly
if
the
switch
over
occurs,
where
suddenly
the
the
new
different
library
version
was
loaded
by
the
application,
then
it
can
happen
anytime.
So
there
is
a
very
small
but
possible
chance
that
this
this
api
will
throw
so
it
will
always
will
need
to
be
protected
with
tri
caches,
and
there
is
different
ways
of
doing
this.
H
I
demoed
a
few
a
few
ones.
This
is
just
one
way
if
you
do
like.
H
H
Yeah,
you
may
need
to
do
something
like
this
like
either
wrap
things
into
exceptions,
or
there
is
all
these
demos
that
I'll
share
later
have
different
ways
of
doing.
This
point
is
that
very
rarely
some
exceptions
occur
and
then
they
need
to
be
somehow
recovered.
The
idea
is
that
there
is
always,
if
we
miss
a
few
telling
a
few
data
points
for
telemetry
when
such
a
library
reload
occurs.
That's
okay,
and
what
I
wanted
to
show
as
demo
is
this:
do
you
guys
have
questions
so
far
by
the
way.
H
So
here
is
a
demo.
What
it
does
is,
let
me
let
the
first
it
starts
the
meeting
events
here.
H
So
yeah
this
demo,
it
starts
emitting
diagnostic
source
events
using
the
stubbed
api,
the
one
that
I
just
showed
you
that
wraps
the
emission.
H
Then
after
doing
this
for
a
while
half
half
a
second
or
like
a
few
seconds,
it
also
starts
emitting
and
the
different
thread
events
using
the
normal
api
diagnostic
source
directly.
So
it's
later,
the
load
is
a
load
is
later
and
we
collect
it
using
the
stopped
api.
So
here
the
point
is
that
we
first
don't
use
load
any
types
that
statically
reference
diagnostic
source,
but
we
we
only
begin
with
dynamic
things.
So
if
I
run
this.
H
So
we're
meeting
telemetry
for
you
know
a
couple
of
seconds
and
so
on
so
here's
what
happened?
I
go
quickly
over
the
log,
but
I'll
share
it
and
you
can
take
a
look
if
you
like,
or
whenever
we
get
to
work
on
it.
So
we
initialize
the
dynamic
loading.
We
scan
all
the
assemblies
and
we
realize
that
the
network
source
is
not
loaded.
H
So
then
we're
requesting
the
runtime.
This
is
the
debug
log
from
the
actual
implementation.
Then
we're
requesting
the
runtime
to
load
diagnostic
source,
because
so
once
we
we
requested
the
runtime,
the
runtime
started
looking
for
it
and
it
did
find
it
because
application
did
not
yet
load
it,
but
it
actually
has
code
that
references
it.
H
So
it's
deployed
with
application,
so
the
the
runtime
found
it
and
then
loaded
it
so
that
the
assembly
load
event
occurred
to
to
let
us
know
so
now
we
are
rescanning,
because
we
do
it
every
time
that
an
assembly
with
a
matching
name
is
loaded,
we're
scanning,
and
now
we
found
that
it
is
loaded
and
it's
loaded
in
a
good
way.
H
So
now
we
are
actually
setting
up
the
the
assemblies,
so
we're
configuring
and
we
are
reflecting
against
all
the
types
that
we
need
and
all
of
the
stuff,
and
now
we
essentially
are
done
and
we're
calling
a
bunch
of
callbacks
into
the
application
code.
Saying
hey
we're
ready
for
stuff
later
so
this
is.
This.
Is
some
demo
saying
hey,
I'm
initializing,
because
I
was
notified
by
the
library
that
things
are
good.
Now
later
there
is
some
stuff,
because
if
you
remember
with
first
scant,
we
requested
a
load
and
then
it
was
recursively.
H
We
were
called
back
so
now
we're
actually
completing
that
code.
That
run
in
the
first
place
and
saying:
oh,
the
library
is
loaded
already
and
it's
already
initialized
we're
not
actually
we
don't
need
to
do
anything
else,
so
we're
ready,
and
this
time
the
the
the
demo
starts
and
meeting
events
and
everything
essentially
just
works.
H
So
here
I'm
just
displaying
all
of
the
events
that
were
collected
from
from
the
stubbed
accumulators
from
the
stabbed
source,
the
one
that
used
the
sub
dpi
to
send
events,
and
this
is
from
the
direct
source,
so
the
one
that
started
later
so
they
they
were
running
like.
I
don't
know
whether
you
see
me
my
picture
here
but
they're
running
like
this.
So
this
is
how
they
interleave
in
a
meeting
the
telemetry,
and
so
we
see
like
you
would
be
seeing
dots
instead
of
x's.
H
If
we
missed
some,
we
know
how
many
events
were
sent
and
we
know
how
many
we
collected
so
things
work
here
pretty
nicely
and
also
pretty
fast.
So
the
one
interesting
bit
that
I
wanted
to
show
you
is
this
here
by
changing
this,
what
what
the
application
will
do
now
is
after
it
starts
it
will
go
to
its
application
directory
and
it
will
copy
the
diagnostic
source
library
away
into
a
secret
location
where
the
normalprobinglogicof.net
will
not
find
it.
H
So
that
way,
when
the
library
requests
the
runtime
to
load,
the
runtime
will
fail,
and
only
later
in
the
process,
I
will
stick
a
assembly
resolve
event
that
will
help
the
runtime
finding
it
in
the
right
place
and
I'll
do
it
right
before
this
second
part
starts
running
that
statically
loads,
the
the
the
the
the
diagnostic
source
so
first
for
the
first
three
seconds,
we're
sort
of
emitting
only
through
stubbed
apis,
but
starting
after
the
first
one
and
a
half
seconds
we're
emitting
the
concurrently
the
through
the
normal
apis
and
right
before.
H
It's
it's
essentially
to
artificially
construct
a
case
where
the
the
application,
statically
references
but
doesn't
load,
doesn't
find
it
by
itself.
So
and
here's
what
happened
so
now.
I
run
this
and
now
again
I'm
looking
at
the
log.
We
started
initializing
the
loader
we're
scanning
the
assembly.
H
The
assembly
is
not
loaded
just
like
before
we're
requesting
the
runtime
and
now
so
an
exception
is
wrong.
This
is
an
expected
exception.
So
this
is
because
I
did
an
assembly
load
and
the
runtime
didn't
find
the
assembly,
so
the
runtimes,
through
an
exception,
we're
logging,
the
exception
we
expected
like
here
right,
but
we're
logging
it.
So
now
the
runtime,
as
a
part
of
the
exception,
provides
because
when
we
requested
for
the
library
we
specifically
didn't
say
which
version
we
want,
so
that
any
version
would
would
work.
H
H
H
Oh
after
after
we
we've
asked
the
runtime
to
load
stuff,
we
want
to
see
where
did
the
runtime
loaded
so
we're
scanning
again,
it's
not
loaded.
H
So
we're
saying:
okay,
we're
going
to
set
up
the
vendored
version,
so
we're
setting
up
a
diagnostic
assembly-
and
you
can
see
when
you
look
at
the
type
somewhere
in
here
in
this.
Yes,
here
we
go,
you
see
the
library
where
we're
actually
getting
it
from
is
our
library.
H
So
and
after
this
we're
saying,
hey
everything
is
fine.
We
get
again
the
callbacks
choose
the
application
that
application
that
option
of
the
application
can
subscribe
to
saying
like
hey,
everything's,
fine,
you
can
start
running
now,
so
the
callbacks
are
for
the
for,
for
this
library
swap
event,
it's
it's
all
concurrent.
So
if
you
just
use
it,
you
just
start
using
it.
H
Everything
just
works
just
magically,
but
the
callbacks
are
for
the
cases
if
the
library
gets
unloaded
and
the
new
version
gets
reloaded,
and
you
want
to
kind
of
proactively
know
about
this
so
anyway,
so
in
here
several
seconds
passed
in
during
this
period
of
time
and
after
a
while,
we
have
set
a
flag
that
that
we
are
ready
now
to
start
the
second
part,
which
is
the
static
event
emission.
H
So
at
this
time
our
stub
noticed
that
hey
a
library
load
occurred,
and
now
it's
scanning
again
for
for
the
assemblies.
Now
it
did
find
the
assembly.
H
So
we
are
replacing
the
the
vendored
version
with
the
actual
version
some
callback
occurs
to
this
is
application
code
that
subscribe
to
two
events,
saying
that
this
stop
collector
noticed
that
the
previous
was
invoker
was
invalidated
and
then
a
new
one
will
be
set
up,
blah
blah
blah.
She
has
log
about
all
this
happening.
H
What
happened
here
is
an
interesting
thing,
so
I
had
a
tight
loop
emitting
emitting
and
and
listening
to
two
events
through
diagnostic
source
events.
This
is
a
tight
loop
and,
of
course,
the
library,
unloading
and
loading
happens
concurrently.
H
H
A
dynamic
revocation
exception
occurred
because
this
was
right
at
the
time
when
we
invalidated
this.
This
stub
that
was
sending
so
a
little
bit
of
data
gets
got
lost.
We
just
we
can
either
react
to
this
exception.
Somehow
and
or
we
can
just
log
it.
The
lab
report
provides
callbacks
to
know
this.
So
if
you
want
to
really
avoid
this
exception,
then
we
can.
It
can
be
done
by
the
application,
but
I
think
it's
pointless.
H
H
So
this
is
data
that
we
received
from
the
stubbed
sender,
and
you
you
see,
a
data
point
is
missing,
and
this
is
exactly
when
the
library
reload
happened.
So
this
is
probably
that
exception
that
we
saw
above-
and
this
is
the
direct
result.
Accumulator
and
data
is
not
missing,
but
sometimes
the
first
one
is
also
missing
when
this
whole,
and
that
is
because
the
collector
is
also
stopped
so
sometimes
there's
a
similar
exception
to
what
we
see
before,
depending
on
on
concurrency
situations
also
happens
in
the
collector.
H
That
is
subscribed
because
it
was
subscribed
through
the
other
library,
and
now
it
was
reloaded.
So
there
is
a
blip
board
in
the
sender
and
the
collector
right
now,
just
we
were
lucky,
it
didn't
happen,
but
sometimes
one
or
two
access
and
missing
here
as
well,
because
we
missed
the
the
static
center
started,
sending
data,
and
at
this
moment
the
collector
was
still
re-initializing
due
to
library
reload.
B
I
I
I
think,
look
looks
very
very
nice,
so
in
this
case
we
we
are
able
to
kind
of
let's
just
to
illustrate
the
case
here.
It's
we
could
have
written,
let's
say
the
instrumentation
using
the
diagnostic
stub
and
then
at
runtime.
If
there
was
support
for
the
diagnostic
source,
we'll
be
loading
that
one
if
it
fail,
if
it's
not
a
good
way
to
load,
then
we
fall
back
to
to
the
vendor
one,
but
the
the
profile
is
still
able
to
capture
all
that
instrumentation.
That's
correct!.
H
The
scenario
is
this:
the
the
high
level
uses
usage
of
this
imagine
application
where
telemetry
is
emitted
in
two
ways:
one
is
the
library
like
asp.net
or
any
other
library
is
actually
emitting
the
diagnostic
source
events
and
they're
compiled
against
diagnostic
source.
We
don't
know
which
version.
H
In
addition
to
it,
we
have
a
auto
instrumentation
injected
bytecode
that
also
produces
diagnostic
source
events,
because
for
some
reason
we
chose
not
to
create
spence,
but
instead
we
decided
to
emit
diagnotic
source
events
just
generically.
Let's
assume
we.
We
made
this
decision
at
some
point,
so
that
code
that
we
emitted
will
never
actually
directly
reference
diagnostic
source.
In
fact,
it
will
reference
the
stub.
H
So
now
we
have
essentially
two
pieces
of
of
sources
for
for
diagnostic
source
event:
one
came
with
the
application
and
that
uses
diagnostic
source
directly
and
one
came
with
our
auto
instrumentation
and
to
use
the
stops
now
the
collection
collection
it
comes
always
with
us,
and
it
always
uses
this
tab.
H
Now,
in
a
normal
case,
we
will
receive
all
events
together
and
everything
will
just
work
in
the
rare
case
where
the
application
is
loads,
the
diagnostic
source,
in
an
invalid
way,
for
example,
it
loads
loaded
in
the
it
will
reference
a
very
old
version,
or
it
uses
some
plug-in
architecture.
Whatever
way
it's
loaded,
multiple
times.
H
In
that
case,
we
will
suddenly
lose
the
telemetry
that
that
is
emitted
by
the
application,
and
we
will
continue
seeing
the
one
that
is
emitted
by
auto
instrumentation.
Just
fine.
H
And
if
suddenly,
the
application
changes
and
the
way
how
diagnostic
source
load
becomes
valid
again,
then
we'll
automatically
rediscover
the
application
telemetry.
So
essentially
we
all
we
always
collect
using
the
stub.
A
A
H
Is
necessary
because
we
need
apis
from
a
library
that
is
not
all
that
is
not
always
built
into
the
net
which
is
diagnostic
source,
so
so
yeah.
H
G
Clarify
your
question
robert,
you
can
think
of
diagnostic
source,
so
greg
mentioned
the
word
event.
It's
letting
you
know
that
something
interesting
happened
in
some
library
or
the
application,
and
then
the
instrumentation
would
then
turn
that
into
either
a
span
or
an
activity
or
used
to
update
some
metric.
Okay
right
behind
the
scenes.
B
Yes,
and
just
to
to
mention
related
to
metrics,
is
that
eventually,
when
the
runtime
implements
some
kind
of
support
to
metrics
via
some
api
that
they
are
working
on
now,
then
eventually,
we
need
to
do
that
to
be
able
to
capture
these
metrics.
If
we
our
interest
in
the
metrics
and
if
we
also
use
metrics
instrumentation,
you
know.
H
Yeah
but
there
was
some
email
from
david.
Thank
you
about
metrics.
I
was
doing
this
in
a
hackathon
mode,
so
I
like
skipped
emails
for
four
weeks,
I'll
be
catching
up
on
this.
G
Yes,
oh
you
mentioned
something
interesting
in
your
demo
and
and
I
want
to
make
sure
that
I'm
understanding
it
correctly.
So
you
talked
about
in
the
case
where
they're
using
some
sort
of
plug-in
architecture,
so
there's
multiple
versions
of
diagnostic
source
loaded,
so
let
let's
say
you're
listening
for
these
events
via
the
stub,
because
they're
using
this
plug-in
model.
G
I
think
you
mentioned
that
you
we
wouldn't
be
able
to
see
events
emitted
by
those
plug-ins.
Is
that
correct.
H
Correct
because
the
thing
is
the
whole
eventing
mechanism
is
not
through
some
sort
of
memory.
Sync,
it's
you
have
to
subscribe
to
actual
objects
for
diagnostic
source
and
the
thing
is
it:
it
becomes
very
flaky
if
we
have
multiple
of
them,
which
one
is
the
right
one.
So
essentially
I'm
saying
I
think
this
scenario
will
be
very,
very
rare
and
in
those
cases
I
prefer
application
stability
over
over
support
and
simplicity
over
support.
H
So
when
I
see
this
that
we
load
the
diagnostic
source,
more
than
once
I
give
up
and
say
I
I'm
not
going
to
make
a
decision
which
one
is
the
right
one,
I'm
just
going
to
stop
using
both
of
them
and
instead
fall
back
to
the
vended
version.
G
Yeah,
I
think
that's
a
fair
simplification
and
in
the
future
based
on
requests,
things
could
be
reevaluated
yeah
and
then
I
forgot
my
other
question.
But
if
I
remember
I'll
I'll
ask:
oh
so.
G
H
Not
as
thorough
as
performance
test
should
be,
and
I
like,
as
I
said,
this
was
a
hackathon
style
coding
thing
I
just
sat
down
for
a
week
and
nothing
else,
and
so
the
way
it's
implemented
is
I
use
compiled
expressions.
So
if
I
can
quickly
show
so
in
the
dynamic
invokers
in
here.
H
Yes,
so,
for
example,
say
I
want
to
call
that
is
enabled
api
of
diagnostic
diagnostic
source
right,
so
essentially
the
first
time
I'm
calling
this
api.
H
I
am
creating
a
a
expression
that
essentially
looks
like
this,
like
like
the
commented
thing,
so
it
creates
a
lambda
expression
that
simply
call
directly
calls
into
sorry.
It's
a
subscriber.
F
H
So
here
the
right
api
so
of
of
diagnostic
source.
So
essentially
I
create
such
a
lambda
using
using
expressions
and
then
I
compile
it
and
then
I
end
up
with
it
with
a
delegate,
essentially
with
a
function
point
and
I
store
it
so,
the
second
time
I
come
I
come
here.
H
I
just
use
the
delegate
so
this
I
didn't
measure
it,
but
I
expect
that
it
should
be
very,
very
close
to
to
using
statically
with
some
small
overhead,
because
at
the
end
of
the
day
there
are
some
ifs
and
no
checks
and
things
like
and
lookups
not
table
lookups,
but
like
pointer
lookups.
So
it
will
have
some
small
overhead,
but
probably
not
very.
B
So
this
is
because
a
long
time
that
I
don't
look
at
diagonal
stars,
I
don't
remember
so
when
you
create
the
listener
for
a
diagnostic
source,
you
have
to
know
the
name
exactly
of
the
the
ones
that
you
want
to
listen.
Or
do
you
have
some
kind
of
mask
that
you
can
use.
H
You,
the
api,
the
stop
dpi
and
the
actual
api
are
exactly
the
same.
I
show
you.
H
So
when
you
create
the
listener,
you
have
a
you,
have
a
api
where
you
subscribe
to
essentially
an
event
that
says
a
new
listener
became
available,
but
all
the
existing
ones
will
be
given
to
you
as
well,
and
you
are
being
passed
a
listener
and
the
listener
really
only
has
a
name,
but
you
can
do
with
the
name.
Whatever
you
want,
you
can
match
against
it
or
you
can
match
against
the
prefix
or
you
can
do
whatever
logic
you
like
and
then
once
you
just
decided
that
this
source
is
interesting
to
you.
H
You
subscribe
to
events
for
this
particular
source,
which
is
like
you
know,
listening
source.
They
they
have
a
confusing
terminology
in
the
in
the
library
and
they
kept
identical
terminology
so
that
it's
easier
to
transform.
And
then
you
subscribe
to
events
and
on
events.
When
you
subscribe,
you
essentially
give
it
two
delegates.
One
is
the
handler
for
the
actual
event,
but
also
you
can
give
like
a
filter
that
allows
if,
if
the
payload
for
the
event
is
expensive
to
construct,
then
you
can
call
is
enabled.
H
So
the
calling
site
looks
like
this,
so
you
have
the
diagnostic
source,
you
say:
is
this
event
enabled
and
then
you
can,
if
it's,
if
it
is
enabled
you
construct
the
payload
for
the
event
and
you
you
send
it
and
you
see
the
stub
api,
but
the
actual
diagnostic
source
repair
looks
in
the.
H
In
the
ripple
right
now
it's
in
a
different
repo
and
I
have
to
work
out
throughout
the
next
couple
of
days.
What
is
the
right
way
to
share
this
because
we
have
now
another
ripple.
That
is
all
the
shared
components
that
are
not
specific
to
the
tracer,
but
are
specific
like
that
are
shared
between
all
the
different.net
products
and.
H
Going
to
be
the
same
license,
but
I'm
not
exactly
sure
what
is
the
best
way
to
actually
merge
it
back
and
forth,
but
it
will
be
the
same
license
that
will
be
open
source.
So
we
can
like
start
using
it
right
away
and
then
the
whole
code
flow
thing.
We
have
to
actually
figure.
H
H
And
the
background
of
it
is,
of
course,
that
now
that
it
works
with
a
diagnostic
source,
what
I
would
like
to
do
in
terms
of
I
would
like
to
start
using
this
component
instead
of
so
right
now
in
the
tracer,
we
are
listening
to
diagnostic
surface,
so
I
would
like
to
start
using
this
right
now.
Actually,
we
are
restricted
to
only
asp.net
core
scenarios,
because
there
we
are
likely
to
find
it
and
we
don't
support
it
in
the
framework.
H
So
with
this
we
can
support
it
in
the
document
framework,
and
so
after
that
we
now
that
the
library
loading
works.
We
can
start
adding
more
stubs,
of
course,
including
activity
stops
so
that
in
the
mid
to
long
term,
we
can
use
the
same
logic
to
also
stop
activities,
and
then
we
can
look
into
using
activities
instead
of.
F
F
H
You
so
I'll
share
I'll
share
the
the
link
to
the
code,
and
we
can
take
it
from
there.
I
don't
know
what
is
the
best
way
to
to
merge
it
into
the
into
the
repos,
but
I'm
guessing
that
it
might
make
sense
to
do
it
from
data
dock
side,
because
we
do
need
to
address
the
problems
that
we
have
with
some
customers
who
would
like
to
use.
H
Who
would
like
to
listen
to
diagnostic
sources
on
the
dotnet
framework?
So
that
means
it
has
relevance.
It's
not
just
a
hecatons.
It
has
product
relevance,
so
the
reason
why
it
might
be
better
to
do
it
first
in
data
dock
is
because
then
we
will
solve
whatever
whatever
dealings
we
have
with
these
two
repos
will
solve
it
and
then
suddenly,
auto
can
just
pick
it
up.
B
Yeah,
I
I
I'm
I'm
thinking
about
also
the
the
active
source
and
that
that,
if
I
remember
correct
that,
if
to
get
to
that,
besides
doing
the
implementation
kind
of
to
what
you
did
for
a
diagnostic
source,
there
is
a
process
to
kind
of
do
the
switch
in
one
big
step
right.
So
you
have
to
kind
of
do
all
the
work
first
to
then
switch
to
to
fully
use
active
source,
and
that
is
something
that
I
think
they
will
tell
people
here
can
help
when
we
get
to
that
time.
H
Yeah,
I
think
I
think
you're
right
it's
just
with
this.
First,
we
make
a
big
first.
We
like
we
solve
a
big
complexity
problem
with
the
how
to
load
the
library
correctly,
and
then
we
can
get
maturity
by
once.
We
use
this
in
the
product
for
a
couple
of
you
know
for
for
a
period
of
time,
then
we
can,
you
know,
there's
two
risky
steps
in
activities
right,
one
is
the
library
loading
logic
and
the
other
is
activities
themselves.
H
So
by
going
this
route,
we
can
mature
the
library
loading
part
of
it
and
be
be
have
a
good
feeling
about
that.
That
will
make
the
change
to
activities
much
less
risky.
B
B
All
right,
then
I
I
I
just
wanna
mention
briefly,
because
I
I
see
they
here
david,
we,
we
were
changing
the
time
of
the
meeting
to
10
30
to
facilitate
the
people
in
europe.
I
hope
that
that's
okay
with
you
yeah
it
should
be
fine.