►
From YouTube: 2021-09-08 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
Did
you
have
the
meeting
last
week?
No,
I
was
a
very
last
week.
C
Robert
yeah,
I'm
not
sure,
let's
see
if
I
can
think.
D
Because
I
put
one
thing
on
the
agenda
and
it's
actually
related
to
some
changes
that
he
submitted
to
the
sdk
project.
E
C
D
C
C
D
Yeah,
so
if
you
want,
I,
I
can
introduce
it
so
this
was.
I
didn't,
attend
the
sdk
sig
meeting
yesterday,
but
one
of
my
co-workers
did,
and
so
there
were
some
questions
for
us
about
the
environment.
Variable
changes
that
you
were
trying
to
push
through
on
the
sdk
robert
and
one
of
the
things
that
was
brought
up
is
that
there's
no
specification
to
standardize
these
environment
variables
across
all
the
different
languages
yeah.
There
is
specification
for
for
those
ones.
D
Okay,
so
that
may
be
something
you'll
want
to
clarify
with
with
the
sdk
sig,
because
that
was
one
of
the
concerns
that
they
brought
up,
which
led
to
a
question
of.
E
Other
languages,
most
of
other
languages
like
go
like
python
java,
have
had
them
included.
D
D
Right,
so
what
they're
trying
to
do
right
now
is
scope,
their
1.2
release
for
metrics,
and
so
one
of
the
decisions
that
they
want
to
make.
Is
this
something
that
should
be
in
scope
for
that?
Or
is
this
something
that
could
be
as
as
another
experimental
release
following
the
1.2
release,
and
I
didn't
have
a
good
answer
for
that,
so
I'm
just
I'm
bringing
it
up
here.
E
Okay,
so
do
you
think
I
should
just
talk
with
cjo
or
how
should
what
was
the
best
supreme,
because
the
problem
is
that
when
I
was
on
pto
basically
yesterday
and
also
there
are
two
time
like
once
once
per
two
weeks,
I
can
join
the
second
one
is
like
three
three
a.m
for
us
or
something
like
that
right.
D
C
Thank
you.
My
connection
here
was
bad.
I
think
I
I
I
lost
a
good
chunk
of
it
so,
but
the
idea
is
that
there
is
some
question:
if,
if
stuff
is
in
this
pack
or
not,
and
you
are
gonna,
it.
D
D
The
kind
of
the
secondary
question
is,
which
release?
Do
we
need
it
in?
Do
we
need
it
in
the
upcoming
1.2
release,
or
is
this
something
that
can
be
added
in
a
follow-up
release
after
1.2.
C
E
C
E
Okay,
okay,
so
I
have
some
time
because
one
of
my
prs
needs
some
follow-ups
and
I
just
want
to
make
sure
that
the
concerns
are
addressed
because
they,
I
basically
added
extended
the
api.
I
added
some
public
classes
and
they
are
not.
They
want
to
have
the
so
all
these
types
that
I
have
introduced
that
are
parsing
with
these
environments
are
public,
but
then
I
suffer
understand
teacher
prefers
to
have
them
internal,
even
if
country
will
need
to
copy-paste
them.
C
D
D
The
assumption
there
was
that
if
the
specifications
aren't
finalized
for
those
environment
variables
that
they
didn't
want
it
to
be
in
any
of
the
the
1.0
assemblies
that
they
want
it
to
be
in
more
of
a
beta
assembly
or
alpha
assembly,.
C
D
C
C
The
next
stop
that
I
have
here
is
the
demo
from
raj.
I
think
later
we
can
go
over
the
pr's.
I
think
the
demo
will
be
more
interesting
if
you
can
go
ahead.
Raj.
F
Sure
follow
just
to
give
the
context.
Last
week
we
had
a
last
to
last
week
we
had
a
discussion
that
we
are
going
to
take
a
small
look
at
how
to
use
the
startup
hook
to
bring
the
open
telemetry
sdk.
So
I
just
have
a
prototype
of
that
with
a
console
application.
F
So
I'm
just
going
to
show
that
to
you
so
confirm
if
you're
able
to
see
my
screen
so
that
I
can
bring
up
the
visual
studio,
okay,
cool.
F
Okay,
so
first
thing
I'm
going
to
show
is
like
I
have
a
very
simple
console
app.
We
might
have
seen
this
console
app
many
times.
This
is
a
copy
from
like
the
open,
telemetry
sdk
itself.
All
I
have
here
is
just
to
create
a
few
activities
the
same
sample.
What
we
have
in
open
telemetry
has
decay
nothing
fancy
here,
and
the
only
thing
is
that
this
has
a.
I
have
a
like
a
diagnostic
version
specified
here,
so
I
will
speak
about
why
we
need
this.
F
F
So
we
don't
like,
I
don't
know
what
is
going
on
like
we
should
not.
F
F
So
what
I
do
here
is
I
there
is
a
concept
called
as
dotnet
startup
hook
that
gets
like
even
called
before
our
main
is
invoked,
so
that
can
be
enabled
by
an
environment
variable
called
as
like
dot
net
startup
hooks.
So
I
just
provided
what
is
the
library
of
our
startup
hook
url
over
here
so
the
moment?
What
I've
done
using
the
startup
look,
is
I'm
bringing
the
open,
telemetry
console
exporter
and
like
attaching
to
this
console
project,
so
I
don't
have
any
special
code
or
anything
in
this
console
apart
from
this
environment
variable.
F
So
with
this
small
change,
if
you
look
at
it,
I
don't
know
like
why
it
is
not
picking
you
up
for
the
first
time
but
yeah
it
is
picking
up
like
and
you
could
see
like
console.
Exporter
is
working
and
we
could
see
the
data,
so
no
modification
is
required
to
the
project
at
all.
So
if
I
just
need
to
speak
up,
there
are
two
projects:
important
projects.
I
use
here
one
is
this
class.
F
This
is
a
normal
class
library
which
brings
just
the
open,
telemetry
console
package
to
it.
There
is
nothing
in
it
and
if
I
go
to
the
class
library
I
just
have
only
one
method
called
enable
where
I
just
enable
the
open,
telemetry
console
exporter
over
here.
So
nothing
fancy
here.
Only
one
method
in
this
whole
class
library-
and
this
is
my
startup
hook
in
the
startup
hook-
all
the
code
important
code
should
get
inside
this
initialize.
That's
the
concept
so
and
it
should
not
be
inside
any
of
the
namespace.
F
The
startup
hook
class
should
be
named
as
databook,
and
it
should
not
be
inside
any
namespace.
So
here
all
I'm
doing
is
I'm
loading,
the
the
open,
telemetry
instrumentation
library,
what
we
created
here
and
its
dependencies.
So
what
it's
going
to
load?
Is
it's
going
to
load
all
these
libraries
over
here
that
specific
class
library
and
all
open
telemetry
standard
dependencies,
including
the
console
exporter,
so
we
know
in
dot
net.
Whenever
we
load
from
an
assembly,
it's
going
to
load
only
that
specific
file.
F
So,
in
order
to
load
the
dependencies,
I
have
a
assembly
resolver
to
do
that
work
for
us
and
once
that
is
done,
all
I'm
doing
is
I'm
using
a
reflection
to
call
the
enable
method
over
here.
F
So
this
is
a
assembly
load
of
open,
telemetry,
auto
instrumentation,
this
class
library,
and
this
code
is
nothing
but
a
reflection
or
resharp
reflection
to
just
load
the
enable
here.
So
all
I
have
done
is
I
just
built
these
two
things
and
referenced
the
startup
hook,
library
here,
which
makes
the
entire
exporter
thing
working
here
with
the
like
instrumentation,
auto
instrumentation
over
here.
F
So
there
is
a
one
caveat
in
this.
If
you
look
at
it,
I'm
using
a
dot
net
framework,
five
in
my
console
app
so
but
the
open
telemetry
brings
diagnostic
the
open,
telemetry
rings
of
diagnostic
source,
six
preview
version.
F
So
if
I
don't
have
this
one
here,
it
will
crash
the
app
because
5
dot
net
5
by
default
loads,
diagnostic
source
version
5..
If
we
don't
have
this,
we,
when
we
open
telemetry
loads,
it
will
try
to
load
a
diagnostic
source,
6
version,
and
we
will
crash
in
order
to
avoid
that.
I
have
like
this
entry
over
here,
the
diagnostic
source
package
version,
so
that
is
an
another
implementation
where
this
could
be
avoided.
F
That
is
what
this
console
application
does.
So,
if
you
look
at
this
console
application,
I
don't
have
a
diagnostic
source
at
all
and
it
is
the
same
programming
dot
cs
same
instrumentation,
no
change
in
the
code,
but
in
the
launch
setting
dot
json
I
have
a
shad
store
like
which
is
a
runtime
store.
We
call
it
as
runtime
store
and
then
additional
tips,
so
I
have
it
over
here
in
the
additional
dips.
What
I'm
saying
is
hey.
I
have
a
like.
F
I'm
just
trying
to
see
if
you
can
bring
this
yeah
all
I'm
just
saying
is
I
have
a
diagnostic
source
of
six
and
how
you
can
locate
that
this
is
the
dips
for
that
and
it
will,
after
looking
into
the
runtime.net
core
runtime
probing
path.
It
just
goes
and
looks
into
the
additional
store
which
we
have
specified.
F
F
So
if
I
execute
without
the
diagnostic
source,
it
should
load
the
latest
version
of
the
one
from
the
runtime
store
and
everything
should
work
as
expected.
So
it
is
working
like
a
magic
here
so
like
the
only
problem
is,
this
is
supported
only
with
the
in
dot
net
core.
There
are
several
deployment
models
like
self-hosting
and
framework
dependent
model.
This
is
supported
only
with
the
framework
dependent
model.
F
The
self-hosting
does
not
understand
this
two
variables,
so
self-hosting
by
default
brings
a
diagnostic
source
as
a
part
of
it.
So
still
we
have
a
challenge
like
what
we
did
in
the
other
one.
So
I
thought
like
I
wanted
to
show
the
power
of
both
the
startup
hook
and
how
we
could
even
rely
on
the
like
a
runtime
store
with
an
additional
tips
in
this
demo.
F
So
so
now
I
I'll
take
the
question:
if
you
guys
have
any
questions
about
these
things,.
C
Yeah
and
just
to
confirm,
you
said
that
they
start
up
hook,
works
without.net,
car
versions,
but
the
the
last
two
that
you
are
selecting
right
now.
They
work
you
only
five
and
above
oh,
it
works
3.1
as.
E
C
D
And
then
the
other
caveat
here
is
that
this
wouldn't
allow
us
to
do
bytecode
instrumentation,
for
that
we
still
need
to
leverage
the
profiler
hooks.
So
there's
multiple
sets
of
environment
variables
that
would
need
to
be
configured
in
order
to
get
things
to
work.
F
Yeah
so
again,
last
time
like
we
had
a
discussion
on
that
architecture
guy
like
documents,
so
I
had
a
discussion
with
raleigh
and
I
had
him
review
that.
That's
where
the
question
was
raised
related
to
the
clr
ie
and
everything.
So
we
had
an
internal
discussion
myself
and
riley
had
it.
So
he
decided
to
review
that
because
he
has
like
done
some
work
on
that
singular
part
in
the
past,
so
he
helped
review
that.
So
the
one
question
with
whatever
the
approach
we
have
it
is
like
we.
F
If
we
are
planning
to
use
clr
ie,
it
is
fine,
if
not
like
the
approach.
Whatever
we
have,
we
can
be
the
only
profiler
that
can
get
attorneys
to
the
process.
So
that
way
we
will
disallow
anyone
that
who
wants
to
attach
to
that
process.
So
I
don't
know
whether
that's
the
right
thing
to
do,
but
yeah
we
can
go
one
step
at
a
time
like
get
this
done
and
then
we
could
try
and
bring
the
clre
at
a
later
point
in
time
to
that
space.
D
Yeah
and
even
if
we
did
the
clr
ie
approach,
even
if
we
went
down
that
road,
we
could
only
interact
with
other
cooperating
profilers
if
any.
If
there's
two
things
that
somebody
wants
to
use
that
requires
byte
code
manipulation,
then
that
still
wouldn't
be
supported
with
clr.
If,
if
I'm
remembering
correctly.
C
Yeah
they
they
need
to
somehow
cooperate
and
understand,
which
other
is
doing
you
know
so
yeah
one
one.
One
thing
that
crossed
my
mind
is
that
this
approach
is
kind
of
in
a
sense
is
not
only
for
auto
instrumentation
right.
You
could
potentially
have
this
a
way
of
hooking
up
the
the
sdk
to
things
that
are
already
instrumented.
C
Let's
say
you
have
like
azure,
functional
or
aws
lambda,
and
you
could
use
the
hook
just
to
kind
of
light
up
the
open,
telemetry
data
right,
so
independent
of
auto
instrumentation
that
that's
something
that
this
could
be
used
at
this.
This
approach
I
kept
thinking
about
the
so
this
is
just
just
this
is
for
net
core.
C
So
the
good
thing
is
that
it
solves
the
problem
about
applications
that
we
don't
have
access
to
the
build
time
chains,
because
we
can
just
have
the
environment
variable
and
bring
the
the
dependence.
So
that's
the
the
thing
it's
much
simpler
than
trying
to
change,
depth,
json
or
anything
like
that
or
try
to
yeah
binding
by
the
head
direction
is
just
for
the
framework
but
is
much
simpler
than
dealing
with
depth
json.
C
F
F
How
are
we
going
to
upgrade
him
so
the
one
approach
I
like
this,
what
we
have
as
a
vendor
diagnostic
source
like
implementation,
that
is
been
in
the
previous
repo,
so
we
could
try
something
like
that.
Second
thing
is:
what
happens
if
customer
brings
an
open,
telemetry
api
with
them,
so
we
are
bringing
one
version
if
customer
brings
another
version,
so
how
are
we
going
to
handle
it
so
right
now
we
can
handle
it
in
a
different
way.
F
So
now
this
is
a
kind
of
something
we
do
internally
for
the
other
product,
so
we
use
an
il
merch
tool,
so,
whatever
the
sdk
that
auto
instrumentation
brings
so
we
merge
all
the
libraries
apis
and
sdk
we
wanted.
We
create
a
set
of
it
and
bring
that
as
a
different
library
to
the
runtime.
F
So
what
and
that
with
that
capability,
what
we
need
to
do
is
if
we
find
out
like
open,
telemetry,
api
or
sdk
within
the
customer
process.
Already
we
should
be
disabling
that
and
enabling
only
the
auto,
like
whatever
the
library
we
bring,
that
should
only
collect
the
data,
so
these
are
the
few
things
that
we
need
to
explore
in
this
area,
like
looking
at
a
very
simple
demo
like
it
looks
simple,
but
it's
not
too
much
of
work
to
get
the
other
things
done.
Also,
it's
it's
little
simpler
thing
to
get
those
done.
C
Yeah,
I
I
I
think
I
I
I
see
the
value
or
of
the
approach,
and
as
chris
mentioned,
we
also
need
the
audio.
So
let
me
say
I
perhaps
I'm
starting
with
a
very
kind
of
broad
perspective,
but
it's
kind
of
I
would
love
if
we
have
a
way
to
eliminate
the
profiler,
but
we
can't
get
to
that.
C
Just
with
this
attack
hooks
day.
Startup
hooks
helps
with
the
problem
of
the
versioning,
but
we
also
have
similar
problems
for
other
stuff
like
the
instrumentations
themselves
right,
so
we
need
also
to
bring
those
dependents.
We
can
bring
you
with
the
hook.
I'm
almost
sure
there
is
no
limitation
to
that,
but
we
still
need
to
do
the
instrumentation,
the
bytecode
instrumentation,
so.
C
I
think
that
this
is
a
area
that
we
we
should
be
exploring
trying
to
put
on
on
the
roadmap.
That's
what
comes
to
my
mind,
but
since
we
still
need
the
profiler
we
can't
perhaps
we
can,
for
instance,
delegate
the
initialization
from
the
profiler
to
the
hook,
but
we
still
have
the
question
about
the
instrumentation,
so
we
still
need
the
profiler.
C
So
I
would
say
that
in
the
short
run,
in
the
short
run
is
nothing
it's.
It's
not
gonna
solve
the
problem
to
the
point
that
we
can
kind
of
move
away
or
get
rid
of
the
profiler.
C
I
once
more,
I
think,
there's
a
lot
of
value
on
this.
You
know,
but
on
the
other
hand,
if
I
look
at
the
the
next
steps
ahead,
I
see
like
we
still
need
the
profiler,
so
we
can't
eliminate
the
profiler.
Should
we
bring
this
now
or
should
we
start
to
explore
down
the
road?
You
know
the
I
mean
the
the
hooks.
You
know.
D
Well,
so,
along
those
lines,
paulo,
perhaps
an
interesting
thing
for
us
to
consider-
is
splitting
what
we
do
for
framework
support
versus
dot
net
going
forward
and
perhaps
there's
a
simpler
thing
that
can
be
done
for
for
net
three
one
and
newer
and
dot
net
framework.
Just
kind
of
remains
in
the
more
legacy
state,
because
I
suspect,
going
forward.
D
More
and
more
libraries
will
support
open
telemetry
out
of
the
box,
yeah,
just
a
thought.
C
No,
no,
no,
no,
I
I
I
think,
makes
sense.
You
know
I.
I
think
I
have
in
my
mind
that
if
the
things
go
as
well
with
open
telemetry
and
I
think
they
are
going
through
because
of
the
involvement
of
their
runtime
and
all
the
support
there-
I
think
in
I
don't
know
four
or
five
years
there
will
be
not
that
much
need
for
bytecode
instrumentation.
C
You
know,
I,
I
think
the
the
question
is
what
happens
in
kind
of
two
years
and
three
years
that
we
need
that
kind
of
to
get
the
open
telemetry,
but
adoption
I
mean,
but
I
I
agree,
I
think
in
in
some
some
time
window.
C
My
guess,
as
I
said,
I'm
going
in
five
years,
but
my
guess
is
that
the
bytecode
instrumentation
loses
a
bit
of
import
importance,
giving
the
support
of
the
runtime.
D
D
E
F
C
On
the
other
hand,
I
always
confuse
the
big
command
with
the
other
one,
but
the
b
command
is
the
general
one
right.
C
C
And
I
think
directly
on
the
runtime
of
the
implementation
use
diagnostic
source.
Perhaps
that
you'll
be
accepted,
you
know,
and
then
it
parts
becomes
part
of
the
nextreleaseof.net
so,
but
in
between
that
happens,
and
in
between
that
version
is
shipped,
we
need
auto
instrumentation
for
that
we
need
bytecode
instrumentation
for
them
for
those.
D
C
D
C
One
question
that
I
have
raj
what
happens
and
we
are
not
addressing
that,
but
if
you
know
how
the
hooks
work
regarding
ahead
of
time
compilation,
you
know,
I
I'm
guessing
is
that
they
don't
work,
but.
C
C
Yeah
but
but
we
are
also
not
addressing
ahead
of
time
compilation
you
know,
so
it
is
just
a
scenario
that
for
us
out
right
now
is
out
of
reach,
as
I
mentioned
in
the
pr
I'm
not
that
concerned
right
now,
if
ahead
of
time
compilation
because
cheap
code,
this
is
for
client
applications,
I
didn't
encounter
much
people
publishing,
server
applications,
use,
dotnet,
publish,
read
the
to
something.
I
I
forgot
the
the
command,
but
there
is
a
way
to
already
publish
ahead
of
time.
C
Compilation,
and
I
know
that
the
runtime
is
investing
more
on
that,
but
I
I
don't
find
that
much
people
trying
to
use
that
in
practice
right
now
for
several
applications
at
least
but
but
yeah,
that
is,
is
a
gap
in
any
technology
that
we
use
for
for
doing
for
doing
this.
C
Let
me
just
take
one
kind
of
side
side
track
here,
how
this
gets
back
to
the
thing
about
the
support
of
aspect-oriented
programming.net
that
we
kind
of
is
it
lacks.
There
are
some
libraries
that
people
can
implement
but
is
not
from
their
runtime,
and
I
think
this
is
the
biggest
thing
that
makes
the
instrumentation
for
dotnet.
Being
much
harder
than
java,
you
know
we
need
the
profiler,
that's
a
very
specific
technology,
a
very
specific
set
of
skills,
the
that
need
to
be
in
place
to
be
able
to
implement
that.
C
So,
if
you
look,
we
have
the
support
of
the
the
profiler
with
the
call
target
instrumentation
the
typing
and
all
that
things
to
make
this
work,
and
in
java
a
java
programmer
can
sit
down
that
understand
the
model
and
write
just
java
code
and
the
thing
works.
C
But
but
that
is
a
an
aside
perhaps
we
should
start
to
book.net
for
folks
for
in.net
7.0
to
have
some
aspect-oriented
programming.
D
Well,
so
there
are
libraries
out
there
to
deal
with
aspect-oriented
programming,
in.net
and
they're
all
using.
I
forgot
what
the
name
of
a
library
is,
but
ultimately
it
rewrites
the
code
at
build
time
to
to
inject
stuff.
C
I
I
look
at
this
many
years
ago-
I
I
don't
remember,
but
but
they
they
required
a
bunch
of
things
like
you
have
to
realize
how
there
are
objects
and
a
bunch
of
maybe
they
evolve.
It
depends.
F
E
Think
uses
reflection
emit
these
ones
usually
require
serialization.
C
Yeah,
so
so
the
ones
using
build,
I
think,
are,
are
much
more
acceptable
and
probably
they
you
have
a
chance
to
work
with
ahead
of
time,
compilation
so
that
that
is
a
plus.
But
but
that's
a
side
note
you
know
kind
of
we,
it's
just
a
a
thing
that
in
general,
has
been
a
thing
in
our
path
to
to
make
progress.
You
know
so
yeah,
okay,
back
on
track.
Sorry.
F
C
Great
yeah
thanks
thanks.
You
appreciate
that
I
think
bringing
bringing
that
up
is
a
is
a
very
good
idea
being
a
different
perspective
and
something
that
perhaps
you
can
combine
with
something
else
to
use.
You
know.
D
Yeah
I'm
wondering
if
there's
enough
value
in
it
to
have
it,
be
it
its
own
thing
as
an
option
for
people
potentially,
because
it's
sort
of
a
hybrid
of
the
devops
scenario
where
you
you
minimally
touch
your
setup.
D
You
don't
get
all
of
the
weight
of
the
profiler,
affecting
your
your
application
performance
as
well.
So
just
just
throwing
that
out.
There.
E
I
know
basically,
I
think
that
I
was
talking
on
on
on
the.net
signating,
that
maybe
in
the
dot
net
sdk
will
create
an
assembly
that
basically
contains
all
this
stuff
needed
for
this
inverter
variables,
and
then
somebody
can
use
it.
Just
in
the
start,
half
group,
even
without
using
you
know
the
auto
instrumentation
in
theory,.
C
E
E
C
Yeah,
I
I
think
I
think
one
thing
we
should
at
least
add
some
notes
about
this,
for
our
path
and
in
the
docks,
because
it's
something
that
we
definitely
want
to
explore.
One
scenario
that
I
think
it's
very
valuable
is
especially
kind
of
functional
in
lambdas,
because
chip,
clear
people
are
really
looking
at
minimize
startup
time
and
also
minimize
the
amount
of
code
that
you
deploy.
C
So
you
can
keep
your
open
telemet
that
you
don't
update
frequently
there,
together
with
the
other,
shared
libraries
and
just
update
your
dll
and
startup,
is
not
that
much
affected
and
things
just
work.
C
Yeah,
I
think
I
I
think
it's
very
good
thanks
rush
to
to
bring
that
up
and
doing
the
demo.
I
I
want
to
be
sure
that
I
want
to
be
sure
I
I
would
like
to
try
to
to
keep
you
and
and
microsoft
involved
with
this
project.
C
But
if
you,
if
you
want
to
talk
more
about
not
today
but
or
it
could
be,
va
slack
whatever
you
prefer,
what
microsoft
goals
are
in
regarding
this
project
and
to
see
if
we
can
also
can
loop
that
in
you
know,
so
the
more
people
participate
in
the
more
companies
involved.
The
better
you
know.
So
I
want
to
be
sure
that
that's
considered
for
what
we
are
planning
to
do.
F
Make
sense
so
this
is
like
a
kind
of
bigger
discussion
for
me
to
have
a
like
speak
with
many
teams,
so
it
so.
I
am
from
like
from
the
same
team
as
of
like
and
riley
in
microsoft
just
like,
but
this
needs
a
discussion
at
this
like
a.net
level.
It
also
because
we
need
a
more
of
help
from
a.net,
rather
than
the
the
sdks
level,
the
more
this
monitoring
sdk
levels.
So
I
will
have
that,
but
I
had
a
like
talk
with
one
of
the
pms
already
from
the
dot
net.
F
F
And
also,
if
we,
if
we
can
also
like
document
somewhere,
these
are
the
asks
and
maybe
not
in
a
readme
somewhere.
These
are
the
asks
that
we
have
from
the
dotnet.
C
F
Now
they
don't
see
a
need
to
jump
in
because
they
are
not
seeing
that
that
any
asks
from
this
community
that
we
need
like
dotnet
to
solve
some
issues.
So
once
we
have
some
lists,
so
I
can
help
you
go
back
or
like
get
back
to
them
and
get
them
to
this
community.
C
All
right
sounds
very
good,
robert
and
chris.
Just
for
me
for
my
benefit,
I
would
like
to
to
know
this
aspect-oriented
programming
using
sasu
that
kind
of
does
at
build
time.
I
would
be
curious
to
to
take
a
look,
so
if
you
guys
can
send
me
the
link
later
I'd
like
to
take
a
look.
C
Yeah,
I
remember
a
lot
of
things
with
basic
kind
of
reflection
and
stuff
like
this,
and
you
had.
I
don't
remember
it
was
a
long
time
ago,
but
you
had
to
make
stuff
serializable
and
you
didn't
have
really
good
access
to
the
parameters
of
the
method.
There
was
kind
of
it.
It
was
not
smooth.
You
know.
C
All
right,
so
I
think
we
should
take
a
quick
look
at
the
pr's
yeah.
F
One
question
I
have
before
that,
like
I
just
took,
take
a
look
at
the
repo
and
I
understood
that
it's
that
rendered
library
approach
for
the
diagnostic
source.
So
I
just
wanted
to
see.
I
did
not
find
it
it's
complete,
so
I
might
be
incorrect.
Also
was
that
been
tried
ever
in
this
repo
tested
that
part
of
the
solution.
C
Sorry,
I
I
I'm
not
sure
if
I
understand
we
did,
we
all
work
on
the
poc
branch.
So
that's
the
branch
that
we
are
focusing
and.
D
C
Yeah
we
tested
loading
the
the
sdk
from
on
that
branch
using
the
profiler
okay.
C
F
C
Yeah,
so
that's
what
the
work
is
doing
by
the
way
for
us,
it's
something
that
we
should
do
relatively
soon.
We
should
switch
our
main
branch
to
be
the
one
based
on
the
plc
that
will
make
clear
for
people
coming
to
the
ripple
where
the
work
is
happening
right
now.
We
still
have
the
main
following
up
stream,
that
that
can
be
confusing
for
people
just
seeing
the
ripple.
C
C
C
Okay,
let's
start
with
the
older
one,
this
was
by
david.
He
is
adding
loader
tests.
C
So
can
you
guys
describe
to
me
what's
the
issue
here?
I
I
didn't
see
this
before.
D
Yeah
so
I
I
just
took
a
look
at
it
this
morning
and
I
saw
that
at
least
the
linux
build
and
the
mac
build
is
failing,
and
it's
probably
just
a
build
order
thing
or
build
dependency
thing
to
to
resolve.
C
G
Yeah
and
that
that
might
have
stemmed
from
comments
I
was
making
instead
of
using
or
checking
in
binaries
to
just
include
the
source
and
build
it
with
the
test
project.
So.
D
C
B
G
Can
I
can
take
a
look
at
this
if
you're
pulling
in
latest
from
our
native
side,
there's
definitely
been
a
lot
of
changes.
G
Oh
right,
that's
that
particular
appsec
stuff
is
some
newer
code
that
we
have
it's
going
to
be
completely
unrelated
from
the
tracing
I'd,
see.
C
Yes,
so
so
this
I
I
I
in
one
hand
probably
not
needed
for
open
telemetry,
because
we
we
don't
do
that
kind
of
analysis,
but
on
the
other
hand,
I
don't
know
how
easy
is
to
kind
of,
isolate
and
separate
those
and
perhaps
not
bring.
You
know,
that's
that's
the
question
that
comes
to
my
mind,.
G
I
could
try
and
take
a
look
at
some
of
the
issues
that
you
have
in
the
other
branch.
Maybe
we
don't
pull
in
so
many
changes
to
get
it
working,
but
yeah
I'll
go,
take
a
look
in
the
kit
of
actions
and
try
and
see
if
anything
in
the
failures
makes
any
sense.
I
assume
they
have
the
actions
kind
of
related.
It
shows
the
results
in
the
pr
links.
C
Okay,
yeah
yeah,
that
that
that
will
be.
That
would
be
great
zack.
If
you
could
do
that
that
that
would
be
great.
Perhaps
we
we
can
target
better
the
update
or
or
anything
like
that
as
a
result
of
you
taking
a
look
on
those.
G
One
of
the
things
that
I
do
when
I'm
testing,
if
it's
going
to
attach
or
not,
is
just
running
ldd
on
on
linux
or-
and
I
assume
it's
a
utility
on
mac
as
well,
which
because
sometimes
specifically
for
like
alpine
there's,
maybe
a
library
doesn't
resolve,
and
so
that's
the
most
common
issue
I've
seen
as
to
why
it
doesn't
attach.
Is
it
just
fails
to
load
the
profiler
library
because
there's
a
missing
system
dependency?
G
That's
like
the
first
thing
I
think
to
do
after
that,
a
lot
more
complicated.
C
Do
we
have
any
dotnet
event
for
that?
No
right,
the
old?
Now
we
can,
we
can
enable
on
linux,
but
I
don't
know
if
there
is
a
provider
for
that
information
about
the
profiling
attache.
C
I
I
I'll
show
you
the
two
erasmus
offline,
but
there
is
a
tool
that
lists
a
bunch
of
events
that
you
can
monitor.
From.Net.
It
works
on
linux.
But
my
question
is:
I
don't
know
if
there
is
something
that
you'll
be
really
telling
you
like,
the
equivalent
of
the
event
viewer,
saying:
hey
a
profiler
was
attached.
You
know
that
is
my
question
that
I
actually
don't
know
from
the
top
of
my
mind.
C
And
on
that
note
about
ll
debut,
I
think
we
should
start
getting
our
our
tools
deep
in
there,
because
most
of
these
things,
people
run
actually
in
vms
that
are
running
linux.
So
to
be
a
good
opportunity
for
us
to
to
do
that.
C
All
right,
would
you
be
back
back
to
work
then
for
me,
but
my
my
vacations
were
good.
Any
break
is
good,
so.