►
From YouTube: Silk.NET Coffee & Code Catchups
Description
Join the Silk.NET team for a quick catchup. This is a more informal stream wherein we'll be discussing what we've been doing on the Silk.NET project, what we've been doing outside of Silk.NET, bouncing ideas off each-other, and (most importantly!) provides us an opportunity to answer any questions the community may have.
These streams are impromptu and the VOD will be unlisted as a result.
GitHub: https://github.com/dotnet/Silk.NET
Discord: https://discord.gg/DTHHXRt
Background music by HOME.
A
A
A
B
C
Right,
hello,
hello,
we
are
I,
think
we're
live
well,
we
seem
to
have
some
feedback
in
there.
Oh,
that's
safe,
yeah,
I
swear
one
day,
I'll
be
I'll,
get
good
at
these
and
know
what
the
hell
I'm
doing.
But
today
is
not
that
day.
So,
hello,
everyone.
How
is
everyone.
E
A
A
C
Damn
good
good,
it's
I
spent
the
morning
replacing
well,
let's
say
replacing,
adding
some
hard
drives
to
my
nails,
so
I
can
actually
back
stuff
up
because
today,
I
don't
back
anything
up.
D
C
E
Hardware
a
few
months
ago
and
I
ended
up
not
buying
the
net,
because
I
found
at
the
same
price
like
a
pcie
4
m.2
SSD
like
for
two
two
gigabytes
of
high-end,
pcie,
4
storage.
So
I
just
got
that
two.
D
C
A
F
F
G
C
I
missed
something:
have
you
in
the
in
the
Discord
server?
Why
is
everyone's?
Why
is
everyone's
name
change
it
to
dot
dot.
D
C
D
A
D
B
B
F
D
You
can
just
yeah,
which
is
why,
by
default
it'll,
lower.
H
C
Yeah
all
right
well,
we'll
hope
that
Tana
kind
of
shows
up
so
yeah
I
mean
we've.
You've
all
had
your
opportunity
to
speak
on
the
Not
Silk
aspects
of
things.
How
has
has
anyone
found
time
for
silk
so
far.
D
Not
since
I've
been
on
my
trip,
but
before
then
I've
been
working
a
lot
on
2018
getting
that
ready
for
release,
I've
updated
all
of
our
bindings.
Finally,
web
GPU
is
in
a
more
consistent
State
across
the
implementations.
So
now,
hopefully
you
can
rely
Less
on
vendor
extensions.
You
no
longer
have
to
dispose
objects
through
vendor
extensions,
Mozilla
and
Google
have
finally
agreed
to
reference
counting,
so
web
GPU
is
a
lot
better
of
a
state
right
now,
18
comes
out.
D
C
E
D
Yeah,
it's
it's
a
bit
Jank,
but
it
can
it's.
It's
I'd
say
you
can
actually
build,
build
a
build
something
in
it
without
having
to
worry
about
everything
changing
nowadays.
Now
that
they've
settled
on
deleting
GPU
objects,
which
I
think
should
have
been
like
priority
number
two
or
three
behind
creation,
but
Nella,
that's
standardized!
It's
it's
probably
going
to
be
a
lot
easier
to
build
apps
with
it
which
I'm
excited
for
because
web
GPU
is
a
nice
API.
D
Earliest
people
working
on
wgpu
had
been
thinking
about
it
for
a
while
about
switch
to
it,
but
they
just
hadn't
bothered
with
implementation
yet
and
once
it
was
merged
in
the
Upstream
web
GPU
native
web
GPU,
headers
repo,
that's
when
they
finally
bothered
moving
to
reference
Counting,
because
people
from
wgp
and
Don
had
both
agreed
that
that
was
probably
the
way
to
go.
D
C
It's
just
but
yeah
it
sort
of
goes
to
show
how
influx
everything
is
given
that
these
decisions
are
only
happening
now,
so
I
guess
yeah,
but.
D
D
So
oh
yeah,
you
can
either
it
over
right
now
and
like
to
like
do
what
you
do,
what
you
do
with
Vulcan,
where
you
can
choose
the
optimal
one
for
what
you
need
like
before.
You
would
give
it
a
power
preference
and
that's
all
you
could
change
like
you'd
request,
a
high
power
or
low
power
device,
but
now
you
can
be
more
granular
about
your
decisions.
C
H
C
Of
hoping,
but
but
WWE
native
eventually
would
work
with
the
wasm
backend
for
the
wgpu
quote,
but
there.
D
Is
there's
a
PR
open
to
do
that
and
but
it's
it's
stale
so
once
that
get
merged,
we
can't
actually
explore
web
GPU
in
the
browser.
Yes,
although
get
real
it'd
be
a
bit
it'd
be
a
bit
tricky
for
me
to
work
on,
because
Chrome
still
hasn't
shipped
web
GPU
on
Linux
in
the
browser,
so
I
don't
think
any
I,
don't
think
it
works
on
arm
either
I,
don't
think
Kirby
from
publishes
arm64
binary,
so
yeah
it'll
leave
a
trick
for
me
to
work
on,
but
I'll
find
some
way
to
do
it.
F
I,
don't
think
Firefox
supports
WP
at
all,
yet
right.
F
F
D
D
To
fake
compute,
with
like
fragment
shaders
like
there
are
Bitcoin
miners
written
with
fragment
shaders,
which
can
run
in
webgl,
which
are
cursed
but
like
rock
rock
compute
grunt.
Is
it
available
in
the
web
right
now,
which
is
like
the
main
use
case
for
web
GPU?
If
you
need
to
run
compute
heavy
stuff,
and
you
like
working
with
JavaScript
Chrome
with
web
GP,
was
a
really
really
good
option
because
I,
don't
think
node
or
any
other
any
of
the
other
JavaScript
runtimes
that
run
outside
of
a
browser
have
webq
support.
D
F
But
so
I
guess
just
all
people
that
want
to
like
experiment
with
gpus
but
using
JavaScript.
F
D
D
F
I
don't
feel
like,
then,
for
us
at
least
like
like
supporting
awesome
web
gpus
kind
of
pointless
right
because,
like
there's
no
point
in
using
it
for
someone
that
wants
to
like
just
like
experiment
with
web
GPU
to
like
get
because
they
can
just
use
the
native
version.
There's
no
point
to
like
compiling
your
C
shortcut
to
like
wasn't
slash,
JS
and
then
running
it
through
like
a
new
Chrome
version
and
then
going
back
right.
F
D
If
we
have
support
code,
also
it'll
just
help
mature
those
still
branches
I
have
for
wasm.
If
we
can
get
that
into
at
least
a
partially
mergeable
State
I
think
that
alone
will
be
nice,
because
it
means
that
people
can
start
improving
the
wasm
support
and
silk,
because
currently
sdl
can
sometimes
kind
of
run.
Glfw
still
I
haven't
worked
on.
D
F
D
D
I've
been
I'll
I'll
recompile,
the
wasm
samples
we
currently
have,
and
that
was
them
take
three
branch
and
I'll
run
them
against
the
latest
on
an
eight
runtime
and
SDK,
and
it
still
is
the
exact
same
bug
that
it
had
like
a
year
ago.
So
we're
currently
still
blocked
on
something
something:
input,
breaks,
sdl,
initialization,
something
something
runtime
error:
yeah,
that's
all
I
have
yeah.
F
I
I
think
that's
essentially
where
we
were
like
two
years
ago
with
open
six.
Also
I
think
it's
pretty
much
the
exact
last
time.
I
checked
so
yeah
I,
don't
think
it
was
a
native
basically
so
like
calling
into
browser
like
native
symbols
or
whatever
you
want
to
call
it
on
like.net.
Wasn't
it's
like
possible
really
so.
D
There
there
is
something
experimenting
with,
and
that
is
a
web
GPU
runtime
for
wazzy,
which
actually
does
sound
like
something
I'd
want
to
support,
I'm,
not
sure
how
windowing
would
work
through
wazzy,
but
they
there's
an
open
issue
in
the
web.
Gpu
headers
repository
for
wazzy
support
for
webvpu,
which
I
think
would
be
actually
really
cool
to
support,
because
it
would
mean
single
binary.
You
publish
and
run
time
whatever
on
mobile
machines,
which
is
very
similar
to
what.net,
can
do,
but
just
doesn't.
D
F
To
expand
on
Aussie
for
a
second,
because
I'm
I'm,
really
beating
I,
wasn't
right
now
I
think
was
it
was
a
small
set
I,
don't
think!
There's
any
native
support
there.
Yet
it's
mostly
about
like
I
think.
But
then
there
is
a
newer
extension.
I
guess:
I,
don't
think,
there's
as
yeah
exactly
I'm,
not
a
big
fan,
but
it's
good
to
worry
about
that
anything
like
that.
Posix,
but
I,
don't
think!
There's
any.net
supports
and
it's
also
just
really
it's
Yankee
in
the
first
place,
so
yeah
I
don't
know
yeah.
D
Was
he
I've
seen
Wuzzy
x
a
lot
because
it's
been
the
creators
I've
been
pushing
a
lot
for
Zig
support,
so
I've
been
saying
them
in
the
zig
Discord
a
lot?
It's
it's
quite
it's
quite
Jing,
but
yeah.
All
Wazi
needs
to
be
able
to
do
full
soap.
Stuff
is
the
ability
to
deal
open,
dlcm,
Deal
close,
but
the
web
GPU
people
have
not.
The
wazzy.
People
have
been
hesitant
on
that
for
reasons
of
sandboxing
and
security.
D
Etc
and
none
of
the
implementations
of
wazumwazi
have
been
interested
in
it
either
because
they
just
say
go
to
Wazi
Wazi
says
go
to
the
impotations.
So
it's
a
back
and
forth
catch-22.
F
D
Yes,
I
mean
yeah
I,
see
it's
it's
Jank
and
either
way.
The.Net
wasm
sport
is
also
a
drink.
So
in
its
current
state
we
can't
really
support
web
wazy,
stuff
I.
Think
someone
was
trying
a
couple
days
ago
to
get
webgl
running
through
and
scripting
or
something
I
don't
know
if
they
got
anywhere
with
that
I
said.
C
But
should,
in
theory,
be
what
what
the
info
code,
those
p
in
book.
D
D
F
There's
definitely
some
there's
definitely
like
the
the
pin
book
for
the
right
is
a
really
weird
I,
probably
wouldn't
recommend
using
it
on
something
as
loud
as
opengl,
because
there's
so
many
endpoints
you'll
have
a
huge
amount
of
code
and
and
like
the
aot
compiler
will
probably
cry
all
night.
We
will
generate
that
much
code,
but
it
is
definitely
the
way
to
get
things
to
work
on.
Wasn't
because
there's
no
lip
C.
Obviously
in
wasn't,
there's
no
alternative
and
wasn't
so
you
have
to
import
it.
D
In
the
case
of
my
branch
of
wasm,
what
I
do
is
what
I
did
originally
was
no
changes
to
anything.
I
just
call
them
to
sdl
to
get
the
function,
pointers
for
GL
and
then
the
runtime
was
crashing
because
of
missing
function,
definitions
or
it
basically,
it
didn't
have
so
when
wasm
does
p
invoke,
it
calls
into
a
table
with
different
function.
Definition
type
so,
like
four
floats
for
the
parameters
for
GL,
clear.
D
It
wasn't
generating
those
tables
for
opengl,
so
stuff,
like
GL,
clear,
which
is
a
really
weird
function.
Parameters
of
four
floats
would
cause
the
run
time
to
crash,
so
solution
was
to
create
a
p
invoke
override
and
then
never
call
into
it,
so
the
runtime
would
generate
that
table
and
then
just
use
sdl's
function,
loading
which
unscripted
provides
to
then
load
the
function,
pointers
into
a
GL
context.
F
Also
pretty
possible
solutionally
if
we
would
just
ship
ship,
essentially
GL
specific,
that
works
really
well.
You
can
just
make
a
like
a
custom,
was
a
module
and
then
load
that
and
then
essentially
reference
that
for
all
your
function,
loadings
and
that
will
work
decently.
Well,
because
you
have
that
table
manually
generated
and
it
will
like,
then
you
can
pretty
much
reference
everything,
but
it's
just
really
slow
from
my
experience
and
there's
so
many
other
runtime
bugs
that
yeah.
D
Yeah
and
scripting
I
think
for
performance
is
the
way
to
go
because
that's
what
everyone
else
is
doing.
So
it's
going
to
be
what's
focused
on
by
the.net
team,
so,
unfortunately
for
performance
and
maintainability
and
scripting
is
probably
the
way
to
go,
but
we're
so
heavily
limited
by
runtime
bugs
that.
F
Yeah
but
I
I
think
what
I,
what
I
would
suggest
is
exactly
that.
We
essentially
make
a
a
model
that
just
wraps
some
scripting,
but
it's
still
so
slow
and
then
also
the
runtime
will
just
die
very
frequently
for
a
lot
of
reasons.
D
I
struggle
to
even
like
reduce
down
some
of
the
bugs
I
hit
like
with
our
input
test
in
the
lab
that
causes
something
about
sdl
initialization
just
fail.
You
can't
call
any
sdl
functions
in
that
project.
For,
for
some
reason,
I
haven't
been
able
to
reduce
it
down
to
some
subset,
but
if
I
run
the
the
blank
window
example,
then
that
runs
fine
and
I'm
able
to
call
sdl
functions.
D
F
The
problem
is
that
a
lot
of
the
bugs
are
triggered
by
the
Linker
deciding
to
link
specific
things
in
and
then
there's
not
you
don't
even
have
to
call
the
function.
You
just
have
to
think
it
should
link
that
in
and
then
for
some
reason
that
will
cause
a
bug
and
it's
essentially
possible
to
properly
track
because
breaking
when
the
Linker
will
use
things
and
when
it
won't
is
essentially
impossible.
So
yeah
I
have
no
way
of
of
reporting
that
either.
C
Yeah
I
suppose
one
other
thing
is:
where
does
Native
aot
lvm
fit
into
all
of
this,
because
I
know
that
that's
currently
a
that's
a
community
project.
It's
not
not
an
official
implementation
of
wasm
support
buttons
on
that
team,
but
it
is
it.
It
is
something
that's
being
worked
on
in
the
runtime
lab
and
it's
I
have
a
feeling.
It
will
end
up
being
you're
actually
ready
at
some
point.
D
I
haven't
tested
it.
Some
people
on
the
c-sharp
server
recommended
me
to
try
it
over
the
current
wasm
support
and
I've
tried,
building
it
and
had
no
luck
because
I
can't
even
build.net
locally
on
my
machine
I.
Just
the
instructions
don't
work
for
me
and
I.
Don't
know
why
and
I
haven't
been
bothered
to
figure
out.
Why
so
I
haven't
I,
haven't
bothered
trying
the
native
aot
lovm
stuff,
but
I
think
eventually,
once
I
get
the
runtime
building
I'll
give
it
a
shot.
I
just
haven't
found
a
way
to
do
that.
Yet.
C
Yeah
because
I'd
imagine,
the
intention
will
unfortunately,
will
be
to
put
the
native
aot
lvm
implementation
through
the
same
shoddy
process
that
the
the
current
implementation
does.
I.E,
that
custom
that
custom
JavaScript
code
gen
module
that
it
goes
through.
That
originally
said
that
a
pointer
was
not
an
unmanaged
type.
I
have
a
feeling.
I
got
to
keep
the
backgrounds
for
compatibility
reasons
if,
if
and
when
it
becomes
production
ready,
but
you.
D
Know
cause
even
more
nightmares
because
it
regressed
a
lot
in
my
first
in
my
first
try.
My
first
try
to
revive
wasm
from
kaizel
Branch
enums
were
no
longer
oblitable,
not
just
pointers.
E
numbers
were
also
enough
level
anymore.
F
D
Regressed
then
I
think
was
fixed
again
because
I
haven't
I,
haven't
had
it
since,
because
I
I
initially
reported.
You
know
people
because
they're
faster
to
respond
to
my
wasm
woes
and
they
were
basically
like.
Okay,
we're
gonna
we're
gonna
push
out
a
more
a
more
Cutting
Edge,
build
to
the
beta,
the
beta
nougat
and
that
seemed
to
work.
I.
D
Think
it
regressed
at
some
point
and
then
was
fixed
again,
because
I
I
think
it
was
like
some
pre-net
7
build
worked
and
the
Net
7
didn't
and
then
afternet
seven
some
beta
bill
is
started
working
again,
I
think
that's
what
I
think.
That's
when
enums
stopped
being
political!
That's
when
that
happened.
C
Kai
that
thing
you
were
talking
about
for
custom
was
a
modules.
I
mean
I've
posted
a
small
season
a
bit
because
I
was
trying
to
understand
what
you're
saying.
Is
that
basically,
what
you're
on
about.
F
So
that
the
normal
meetings
are
not
the
voice,
you
know,
but
yes,
that's
sort
of
what
it
would
look
like
enough,
that
the
generator
wasn't
yourself
and
then
probably
instead
of
yeah.
Instead
of
doing
the
the
whole
re-export
everything
you
just
export
it
a
get
frog
address
from
there
and
then
you
just
have
a
it's.
Essentially,
a
p
invoked
override,
but
written
in
like
wasn't,
and
then
it
will
work.
F
Because.Net
has
no
part
in
it
and
that'll
like
load,
fine
it'll
like
work
easily,
and
then
you
just
imported
that
and
use
it
as
get
proc
address.
And
then
things
word
of
run,
I
think.
D
F
Yeah,
you
just
actually
have
to
generate
it
and
then
it
and
it
works,
but
it's
not
really
worth
the
effort,
because
the
runtime
will
die
for
no
reason
anyways,
especially
when
doing
like
when
actually
trying
to
do
high
performance
things
it'll
just
die
for
no
reason
all
the
time
and
there's
nothing.
You
can
do
really.
D
C
We
just
need
to
somehow
convince
the
Azure
people
that
wansum
is
somehow
important
for
Marx
Microsoft
issue
and
then
they'll
they'll
quite
quickly
fast
track
it.
That's
certainly
what
happened
with
Native
aot.
D
F
D
Okay,
yeah
perksy's
bike
has
just
failed.
A
F
A
C
I
was
gonna,
say:
webassembly
is
pretty
much
the
closest
thing
that
we've
we've
come
to
so
far
to
a
universal
like
binary
assembly,
interchange
format,
because
I
mean.
C
G
F
It's
pretty
impressive,
but
I
feel
like
it's
right
now.
It's
it's
pretty
much
at
the
stage
that
IL
has
been
for
like
20
years,
but
it's
like.
F
We
have
a
good
enough
run
time
that
I'm,
like
runs
well
on
like
most
computers,
but
then
the
only
problem
is
standardizing
apis
and
well
that's
going
really
great
with
it
wasn't
time
just
doing
their
own
thing
now,
and
so
so
yeah
I,
don't
I'm,
not
so
confident
it's
pretty
cool
in
general,
but
yeah
I,
don't
know
if
it'll
stick
around
because
they
just
can't
figure
out
how
to
stand
in
those
things.
D
C
D
C
That
did
Implement
a
custom,
libdl
but
literally
manually
reads
the
the
L
file
and
then
created
some
memory
and
Mark.
That
memory
is
executable
and
jumped
into
it.
It
was.
It
is
nuts.
C
It's
amazing
the
things
that
people
do
for
fun:
yeah
like
silk.net,
3.0
Segway,
so
actually
we're
still
on
Bailey
Kai.
What
have
you
been
doing
with
that.
F
F
Yeah
I'll
start.
If
I've
essentially
quit
my
job
now
and
I'll
start
Union
like
six
months
four
months,
I,
don't
know
something
like
that.
So
hopefully
I
have
more
time
then,
but
I'm
not
yeah,
we'll
see
how
much
I
have
to
study
and
shipment
yeah
I
think
maybe
I'll
have
more
time.
Soonish.
C
Soon
to
him,
yeah
cool,
one
I
suppose
Thomas
you're,
the
last
maintainer
we
haven't
covered
off.
E
C
C
Go
to
a
community
contributor
and
say:
hey
Implement,
a
whole
generator
system
and
make
a
library
for
us
please
so
because
I
know
that
that
a
lot
of
Kai's
work
has
been
very
very
in
instrumental
in,
but
yeah
I'm,
pretty
confident
that
once
we've
got
once,
we've
got
Kai's
Kai's
version
of
silk
search
working
like
the
whole,
simple
abstraction
thing
and
it
you
know
it's
like
it's
like
a
fully
abstract
pipeline.
C
We
we
could
speak
that
to
our
hearts
content
for
years
to
come
and
in
theory,
never
need
a
3.0
4.0.
Sorry,
but
none
of
us
none
of
us
have
time
to
work
on
something
with
that
large
of
a
scope.
D
Aside
from
the
the
new
spirit,
bindings,
I
haven't
really
added
too
many
new
features
to
that's
going
to
be
added
in
the
next
2.x
release,
which
I
guess
I
should
mention
the
other
new
stuff
that
I've
edited
since
2017..
We
have
spear
V
cross
spear,
V
reflect
and
Shader
C
bindings,
all
all
with
Native
libraries
on
every
platform
for
every
architecture.
I
D
C
D
F
D
It
shouldn't
be
at
last,
I
saw
at
least
when
I
got
the
email.
The
pr
wasn't
that
large.
So
it
should
be
easy
to
review.
I
There's
that
here's
that
PR
in
question,
yeah,
I
I,
got
distracted
by
other
stuff
so
haven't
worked
anything
even
remotely
silk
related
lately,
although
I
may
have
some
stuff
that'll
help
people
wanting
to
use
an
async
like
main
game
Loop
or
that
you
to
use
a
sync
and
a
weight
for
the
main
game
Loop
rather
at
some
point
soon,
but
that's
really
early
stages.
Still.
D
Sense
but
yeah
we'll
we'll
try
to
get
experimental
releases
rolling
again
and
then
from
there
we'll
make
sure
there
hasn't
been
too
many
changes
in
any
of
our
apis
will
update
anything
that
needs
to
be
updated
and
then
hopefully,
we'll
have
2
to
18
out
at
some
point
within
the
next
month.
I've
said
that
every
month
for
the
past
couple
months,
but
I'm
hoping
it'll
be
true,.
F
I
The
the
idea
like
at
its
core
is
that
you
it's
basically
it's
I
mean
it's
the
same
way
you
can
use
asynque
weight
in
WPF
or
Windows
forms.
It's
a
custom.
It's
a
it's
a
class
that
wraps
around
like
a
loop
that
just
where
it's
a
cue
that
gets
continuations
and
stuff
added
to
it
and
then
executes
through
the
loop
until
it
gets
a
signal
that
whatever
your
main
thing
has
exited,
and
it's
a
single
threaded,
synchronization
context
that.
E
Just
adds
it's
not
about
like
turning
the
I
understood
like
turning
the
events
into
like
something
async,
but
no
idea
the
idea.
So
just
so,
you
can
use
async
weight
for
like
UI
and
stuff.
I
Yeah
and
what
one
thing
it
would
allow
you
to
like,
you
could
make
a
custom
awaitable
thing
that
waits
for
the
next
frame
of
graphics,
for
instance,
or
for
the
next
update
call
or
you
could
or
you
could
use
the
bread,
the
regular
stuff
with
that
you
use
in
a
normal
UI
app
to
have
something
go
off
on
the
thread
pool,
that's
like
IO
or
whatever,
and
you
can
await
it
on
your
main
Loop
and
be
brought
back
into
the
main
Loop
once
it
completes
without
I.
E
Meant
something
similar,
or
at
least
that
very
raw,
and
they
basically
just
made
a
synchronization
context
that
stores
EQ
of
what
needs
to
be
executed
and
at
the
end
or
start
of
each
update.
I
will
just
go
through
the
queue
and
flash
everything
basically,
and
that
was
enough
to
have
some
asynchronous
like
async
await,
so
I
can
do
on
the
UI
stuff,
enable
little
things
like.
E
Let's
say:
I
want
some
UI
element
to,
and
what's
the
word
I'm
looking
for,
like
it
go
back
and
forth,
like
the
red
like
just
to
show
the
warning
or
something
I
would
just
like:
set
the
color
to
red
a
white
half
a
second
set,
the
color
to
original
about
half
a
second
and
repeat
three
times,
and
it
will
just
look
like
it.
It's
popping
red
yeah.
G
I
D
D
C
C
Sorry
guys,
let
me
hear
you
so
yeah,
so
it's
a
sort
of
reiterate,
sorry,
you've,
I
shall
repeat
myself
so
as
part
of
as
part
of
the
work
that
I've
been
doing
now
that
I
have
more
time
on
my
hands
because
I
no
longer
work
obligations
like
Kai
I'm,
trying
so
I'm
trying
to,
in
addition
to
the
day-to-day
maintenance
I
was
doing
on
2.0,
because
I'm
now
trying
to
figure
out
how
we
can
design
3.0
in
a
way
where
we,
where,
where
we
can,
we
can
still
implement
it
without
without
running
into
the
problem
that
no
one
has
time
to
implement
on
the
maintenance
team
and
part
of
that
is
trying
to
figure
out
how
much
code
we
can
delegate
to
the
but
well
how
much
work
we
can
delegate
to
code
that
we
know
Works
already
and,
and
part
of
that
is
evaluating
right.
C
Okay,
what
have
we
got
on
Clank
shop
already?
What
have
we
got?
What
do
we
actually
need
because
as
much
as
the
symbol
layer
is
amazing
in
that
it
makes
generating
so
much
easier
and
so
much
more
efficient?
At
the
same
time,
if
we
can
make
sacrifices
by
using
like
Rosalind
or
whatever
and
sort
of
making
making
it
less
the
the
completely
general
purpose
solution
we
wanted
it
to
be,
then
we
can
accelerate
design
because,
ultimately
we
need
we
need
to
get
sold
on
that
in
a
place.
C
That's
not
only
is
stable
for
our
users,
because
I
mean
to
be
honest.
C
2.X
is
starting
to
get
there,
especially
with
all
of
the
with
all
the
Windows
SDK
improvements
that
we've
had
recently
with
the
comp
pointer
and
also
all
the
all
of
the
all
of
the
stuff
that
you've
been
doing,
Bailey
with
spurvy
and
just
the
abundance
of
Bindings
that
you've
been
adding
I
I
feel
like
it's
starting
to
get
to
get
to
a
place
where
it
was
stable
for
for
users,
but
Bailey
in
your
opinion,
is
2.x
stable
for
maintainers.
D
Retainers,
definitely
not
because
every
couple
months
we'll
have
some
binding
or
some
native
Library,
which
will
change
or
break
silk
touch
or
break
RCI,
builds
or.
J
D
It'll
get
bigger
and
then
suddenly
the
GitHub
Runners
can't
compile
it
anymore.
So
then
I
have
to
stare
at
the
CI
files
for
an
hour
figuring
out
what
I
don't
need
to
clone
and
what
I
don't
need,
what
I
don't
need
just
to
get
it
to
build
again.
It's
been
like
three
times
now,
where
the
GitHub
Runners
have
run
out
of
disk
space
when
compiling
something
like
we've
had
to
disable.
Our
Swift
Shader
and
angle
builds
I
believe
because
the
projects
have
grown
to
such
a
size
that
we
cannot
compile
them
in
CI
anymore.
D
Not
so
touch
I
mean
build
tools,
build
tools
has
had
many
breakages
as
bindings
change
like
currently.
A
D
We're
stuck
on
Clank
sharp
15
right
now
as
something
about
how
either
clang
or
clang
sharp
handles
types
is
completely
changed,
and
it's
fully
borked
generation
in
a
really
weird
way
that
I
haven't
been
able
to
figure
out
we're
not
tight
mapping
properly
and
such
I
think
perksy
put
more
time
into
it
than
I
did
and
basically
said
that
it's
a
lot
of
time
to
fix
that
we
don't
have,
and
it
would
probably
be
breaking
even
after
we
did
fix
all
the
bugs
all
the
like
breaking
changes
to
existing
code,
which
we're
trying
to
avoid
with
2.x.
D
F
So
I
I
thought
about
this.
When
I
read
the
text,
I
actually
wrote
about
the
silk
X
or
whatever
you
want
to
call
it.
I,
don't
really
know
I
think
it
might
be
quite
reasonable
to
just
for
now
build
something
that
works
around
essentially
the
Tariff
X
definitions
and
then
I
think
for
making
it.
F
So
here
we
can
still
reuse
a
lot
of
what
so
fudge
does
because
I
think,
while
it
has
horrendous
compilation
times,
it's
pretty
stable
so
far,
I
don't
think
it
broke
once
since
essentially
two
point
like
four
or
something
it
was
just
like
over
a
year
at
this
point,
so
it
might
be
possible
to
only
replace
that,
like
lower
layer,
we
have
and
some
of
the
build
tools,
mix-ins
I
think
we
call
them
and
then
it
should
be
fairly
easy
to
like
generate
most
of
the
code
without
too
much
work.
F
Yeah.
It's
not
great,
because
compilation
is
still
that
good
and
silk
touch
isn't
really
that
easy
to
modify,
but
we
didn't
really
have
to
modify
it
so
far,
so
it
might
be
worth
a
shot.
Yes,.
C
C
Clank
show
up
just
as
the
the
current
Celtics
3.0
does,
but
instead
of
having
to
redefine
the
configuration,
it
essentially
takes
the
existing
Terror
effects
response
files
that
would
otherwise
be
passed
directly
to
to
Clank
show
up,
and
it
gives
the
opportunity
for
us
to
modify
those
we'll
do
grammatical
modifications
to
those
response.
C
Files
then
invoke
Lang
sharp
and
then
it
gives
silt
search
another
it
another
opportunity
to
modify
the
syntax
trees
that
have
been
generated
by
by
Clank
show
up
using
the
Priceline
apis
and
then
finally
is
output.
So,
currently
at
the
moment,
there's
only
one:
silk
search
modification
implemented
and
it's
the
changing
namespace
mod,
but.
C
That
in
the
generator
configuration
we
can
just
add
a
list
of
mods
like
oh
I,
want
to
change
namespace.
Here
it's
going
to
change,
namespace
parameter
or
like
it.
Eventually,
there
will
be
a
mod
that
with
like
use,
silk
touch
and
then
it
will.
C
It
will
convert
the
dll
Imports
generated
by
clang,
sharp
to
be
native
apis
and
instead
of
externs
at
the
partials
and
then
run
the
silt
touch
generator
and
then
bring
the
generator
code
together
because,
as
exactly
as
you
said,
code
cell
search,
while
it's
not
in
its
it
in
its
best
shape
it
works,
and
it
is
just
about
maintainable
I
mean
yeah.
C
It's
it's
got
a
lot
of
things
that
aren't
necessarily
there's
some
there's
some
mental
cannon.
That's
been
lost
with
time,
I
think
but
All
In,
All
We
we've
been
able
to
make
changes
before
we
can
make
changes
again
to
it
and
really
we
need
to
focus
on
getting
a
stable,
3.0
out
there
so
that
we
can
ease
the
maintenance,
that's
better
on
us
and
finally
deliver
on
the
promises
that
we've
made
to
our
users.
F
Yeah
I
haven't
really
looked
into
exactly
what
you've
done
before
I.
Don't
want
to
point
out
to
you
again
that
this,
like
mod
system
and
all
that
it
completely
agree
with
it
and
I
think
it's
like
that's
all
the
way
to
go,
but
a
silk
touch,
as
it
exists,
already
has
exactly
this.
So
you
really
only
need
to
write
like
a
small
amount
of
glue
code
between
essentially
Terror
FX
style
output
and
so
touch
so
yes,
read
anything
like
namespaces
and
all
that
we
we
still
have
to
do,
but
at
the
function
level.
F
So
that's
just
all
of
this
right
now
so
like
I'm,
not
super
sure
how
much
overlapping
word
there
is,
so
it
might
be
worth
looking
at
I
can
send
you
the
folder
later
at,
like
the
modifications
or
I.
Don't
know
what
they're
called
that
we
already
have,
because
yeah
I
think
there's
a
lot
of
code
there.
That,
which
is,
we
would
just
write
again
essentially.
C
Sure
but
I
mean
you've
got
the
whole
symbol
system
you're.
Reading
the
XML
instead
of
the
C
sharp
codes,
I'm
trying
to
eliminate
as
many
possible
variables
that
we
can,
because
the
XML
the
XML
system
that
I
originally
wrote
for
crankshop.
C
F
F
Yeah,
but
what
I
mean
with
what
I
meant
in
this
case
is
the
old
Silk
Touch.
Essentially
here
are
Central
Link
one
second.
So
if
you
look
at
I'll
just
put
in
a
voice,
chat,
chat,
right,
I
hope
you
can
see
that.
So,
if
you
look
at
that,
folder.
F
That
basically
has
all
of
the
like
relevant
code.
There's
a
small
amount
of
built
overload,
Generation
stuff
that
we
would
still
have
to
replace,
but
like
most
of
the
silky
things
right
now,
I
just
in
there
and
then
everything
around
it
is
just
ceremony.
C
Yes,
so
my
intention
is
to
essentially
copy
and
paste
all
of
the
files
within
current
silk
search
and
Hammer
them
into
new
silk
touch.
Oh
sorry,
salt,
such
X-
and
you
know
it's
make
it
so
it's
a
full
pipeline
down
from
taking
the
terrifax
inputs,
getting
the
output
modifying
them
and
then
passing
them
into
old,
Silk
Stitch.
If
you
like,
so
that
we
generate
the
final
bindings,
there
is
still
some
stuff
that
we
need
to
do
before.
We
invoke
that
so,
like
we've
got
to
rename
all
to
Pascal
case
and
everything.
C
C
Exactly
yeah
I
always
feel
sorry
for
someone
when
they
try
to
use
a
new
compoint
stuff.
I
have
to
sort
of
advise
them
to
just
follow.
Half
eventually
the
compiler
will
be
happy
but
yeah.
So,
but
that's
basically
because
of
the
whole
again
the
whole
simple
transformation
layer
stuff.
C
It
would
be
a
lot
better
than
using
rosin,
but
it's
also
a
lot
more
code
than
using
wrestling
so
I'm
just
trying
to
go
with
the
lean
and
mean
approach,
and
hopefully
we
can
accelerate
3.0,
because
I
do
want
to
start
getting
to
a
point
where
we
can
have
regular
pre-alphas
up
on
an
experimental
feed.
So
we
can
consistently
integrate
and
get
those
bleeding
edge
users
to
give
us
regular
feedback.
D
F
C
Cool
so
I
suppose,
if
we're
all
agreement,
then
then
I
will
I.
C
I
will
carry
on
with
that
and
see
where
I
get
to
be
honest,
if
if,
if
I
get
a
prototype
working
where
the
bindings
look,
roughly
silky
I
mean
they
won't
have
overloads,
but
you
know:
it'll
look
like
our
style
of
buying
things,
then
perhaps
we
should
have
a
discussion
in
either
these
catch-ups
or
perhaps
even
a
working
group
meeting
to
discuss
whether
we
want
to
make
that
the
primary
3.0
effort
again
bearing
in
mind
people's
time
and
but
yeah,
there's
a
reason
why
I
wanted
to
keep
it
separate
is
that
we
don't
know
whether
this
leaner
mean
approach
will
be
the
primary
approach
going
forward
and
I
want
I
want
to
make
sure
that
until
we
have
evidence
that
this
will
work
that
we're
not
jumping
in
replacing
all
the
3.0
work.
F
Yeah
I
agree:
we
we
should
talk
about
it,
then
the
main
thing
that
I'm
concerned
about
I
think
is
that
to
me
the
the
like
biggest
goal
of
like
3.0
is
replacing
all
of
the
like
the
weird
resolving
infrastructure
we
have
in
core
and
I.
Don't
see
how
this
will
work
then.
C
I
think
my
plan
is
to
integrate
more
closely
closely
with
Native
library.
To
be
honest,
I
think
recent
conversations
that
I've
observed
in
the
low
level
Channel
an
unsafe
channel
in
the
C
sharp
Discord
is
that
the
whole
loading
thing
is
still
a
very
common
issue
for
everyone.
C
So
I
think
it's
going
to
be
less
us
having
the
whole
native
context
thing
and
Morris,
making
a
framework
around
the
native
Library
dll
import
resolve
call
back,
so
a
lot
of
code
can
probably
be
used
because
we
know
we
we
spent
ages
getting
our
resolution
working,
but
I
think
the
cope
will
still
be
there.
It's
just
not
integrated
in
the
same
way,
because
we
know
that
the
current
way
it's
integrated
is
clunky.
F
Yeah
I
mean
the
thing
is
I'm,
just
so
I
think
the
plan
for
3.0
was,
and
at
least
my
mind
sort
of
is
that
we
just
get
rid
of
all
of
this
resolving
infrastructure,
because
it's
really
like
at
least
to
me.
F
It
doesn't
seem
like
this-
is
the
way
the
runtime
really
likes
to
import
native
symbols,
and
it
seems
like
there's
a
lot
of
newer,
tooling,
like
nfaot,
and
also
all
the
tooling
like
mono,
that
just
breaks
when
you
do
this
and
then
we
also
have
a
bunch
of
like
operating
system
incompatibilities
there,
where
there's
an
older
C
or
like
there's
so
many
issues
there
that,
ideally,
we
can
just
get
rid
of
those,
and
just
do
p,
invoke
everywhere.
Right,
yeah,.
D
One
one
place
where
the
current
way
just
does
not
work
at
all
is
FreeBSD,
which
a
bunch
of
people
have
been
trying
to
like
properly
champion
in
a
supported
platform
for
net
for.net
I
think
they're
going
for.net
they're.
Our
current
resolution
code
is
completely
broken
on
FreeBSD
because
of
how
their
lib
C
works.
You
can't
DL
open
DL
open
is
the
main
problem,
so
we
have
to
fall
back
to.
F
Yeah
I
think
I,
don't
even
need
I.
Ideally
we
don't
even
need
that
because,
ideally,
we
just
ask
the
runtime
to
import
the
symbols
we
want
and
then
we
don't
deal
with
any
ellipsy
elliptiel
whatever
it
is.
Yeah.
C
That
is
exactly
my
intention
is
the
where
possible
I
do
not
want
to
be
using
the
current
2.0
silk
touch.
That's
that's
only
a
fullback
for
things
like
opengl
and
Vulcan,
where
we
do
have
a
custom.
Rock
address,
loader
that
isn't
the
platform
default,
the
static
ones
like
yeah.
We
should
use
Dingle
import,
there's
no
reason
why
and
if
we
really
wanted
to
do
the
marshalling
ourselves
rather
than
using
things
like
Library
import,
then
yes,
we
can.
C
We
can
provide
some
of
the
middlewares
from
2.8
still
touch,
but
yeah
I
only
want
to
resort
to
our
current
style
of
bindings,
our
current
style
of
loading
where
possible
and
where
we
can't
do
that.
C
My
intention
is
to
try
and
integrate
all
of
the
stability
that
we
currently
have
with
regards
to
us
always
being
able
to
resolve
which
shared
object,
we're
current,
currently
trying
to
open
and
doing
it
in
a
way
that
the
runtime
actually
likes
so
obviously
native
the
native
Library
class
has
a
dll
import
callback
now,
but
if
it
can't
find
the
shared
object,
you're
talking
about
you
can
give
it
a
power
it
well,
you
can
load
it
yourself
and
obviously
runtimes
that
don't
support
that
won't
do
that,
but
that's
kind
of
the
point,
because
if
we,
if
we're
going
against
the
grain,
it
just
won't
invoke
a
horrible
resolution
code
and
it's
a
bit
to
be
honest.
C
If
that's
the
case
like,
for
example,
you
brought
the
native
aot
example
realistically,
you'll
be
linking
against
that
shared
objects
as
part
of
your
build-time
script
or
whatever
you'll
be
explicitly
telling
the
link,
rather
than
you're,
trying
to
use
Liberty
L
to
or
use
dll
import
for
example,
or
rather
dll
input
will
do
that
resolution
for
you
rather
than
us
having
to
do
it.
C
So,
yes,
all
of
our
actual
function
points
are
loading
for,
like
the
the
the
simple
cases
like
glow,
like
basically,
anything
that
is
an
opengl
or
Vulcan
or
open
XR,
or
anything
that
doesn't
have
a
custom,
get
Block
address.
I
intend
to
use
dll,
import
or
Library
import.
F
Yeah
I
mean
I
I
think
we
should
still
allow
essentially
so
I
think
we
should
still
be
invoke
on
Vulcan
directly.
So,
like
you
look
at
algorithms
thing
and
I
link
to
that
directly,
but
yeah
I
agree.
It
should
be
yeah.
It
should
be
as
starting
as
possible.
I
guess.
C
D
F
Well,
the
only
you
should
really
only
it'll
open
VK
gets
instance,
block
errors,
I
think
foreign.
F
Yeah
and
then
I
think
everything
else
we
can
dynamically
load,
but
the
point
is
more
than
that
should
be
like
guaranteed
specifically
linked.
Would
you
be?
You
know
whatever
yeah
but
like
the
the
thing
is
you'll
get
very
ugly
code
around
that
again
and
it's
not
so
so
it's
not
that
clear.
What
the
what
like
handling!
F
We
can
do
there
really,
because
you
also
have
like
you,
have
newer
drivers
now
that,
like
takes
back
very
seriously
here
and
then
you
get
things
where
you
get
different
addresses
based
on
like
the
instance
and
so
yeah
I
I
think
the
the
handling
code.
There
is
just
very
ugly
in
general
and
I'm
not
sure
how
we
can
solve
that
with,
like
the
easiest
thing,
design.
D
F
I
think
I
think
we've
discussed
exactly
this
last
time
that,
like
for
woken
and
poorly
also
for
opengl
I,
don't
know
that
opengl
is
back
that
well
really
having
that
object.
Api
is
kind
of
critical
to
even
providing
a
technically
correct,
binding,
there's,
not
really
a
way
to
provide
it
to
provide
a
technically
correct,
Vulcan
binding.
Without
having
that
object
API,
you
can
see
nothing
to
associate
the
the
the
functions
too
as
well.
F
Just
instance:
devices
have
the
exact
same
thing
where
drivers
are
free
to
do
whatever
they
want
with
the
device
get
program
address
and
they
may
just
export
different
functions
for
different
devices,
and
it's
not
that
unreasonable
to
have
multiple
devices
in
one
application.
It's
pretty
unreasonable
to
have
multiple
instances
but
multiple
devices,
which
he
normal
I
think
so
there
it's
not
technically
correct
now
and
it's
very
difficult
to
solve
those
I
think
yeah.
D
In
the
case
of
opengl,
we
don't
have
to
worry
about
this
as
much
as
all
you
need
is
the
global
GL
context,
object
and
everything
else.
Let's
see
in
the
case
of
Vulcan,
we
will
need
for
for
a
fully
correct
set
of
bindings
of
Vulcan.
We
will
need
some
way
of
differentiating
the
functions
for
instances
and
device
which
yeah
Will
basically
be.
D
What
we've
been
experimenting
with
for
object,
wrappers
I
think
that'll
basically
be
what
we
have
to
do
to
provide
a
a
fully
correct
set
of
bindings
for
Vulcan
will
have
to
have
that
sort
of
wrapper
on
both
instances
and
devices.
At
the
very
least.
A
C
F
Yeah
you
have
that
internal
I
think
concurrent
dictionary,
which
makes
it
technically
correct,
but
it's
very
bad
I
think
and
I.
Don't
think.
That's
really
designed
to
continue
using
in
whatever
shape
3.0
turns
out
to
be
I.
Think
that's
something
we
definitely
need
to
eliminate,
because
that
that,
like
Lambda
native
context,
is
just
like
that's
terrible
both
performance
and
also
just
for
maintainability
I.
Think.
C
I
think
we
yeah
we'll
explore
that
when
we
get
get
to
actually
making
welcome
bindings
because
there's
a
lot
to
be
discussed
there,
I
suppose
what
I've,
what
I've
currently
got
in
terms
of
silk
such
X
progress
is
I,
have
managed
to
get
the
skeleton
of
the
pipeline
working
in
that
we
now
have.
C
We
now
have
Windows
SDK
Bindings
that
are
exactly
like
the
terafx
bindings,
but
with
a
change
name
space.
Oh
it
even
has
the
exact
same
copyright
head.
There
was
the
terrafx
bindings,
but
it's
a
work
of
progress.
Okay,
but
obviously
we
were
discussing
this
yesterday
and
we
realized
that
hey
we
can.
We
can
change
things,
we
can
we
we
need
to
decide
well,
package
structure.
We
have
so
obviously
we're
discussing
what
on
Earth.
We
can
call
our
windows
by
and
there's
obviously
for
terrafx.
This
is
terrafx.interrupt.windows.
C
We
have
a,
but
the
problem
is
that
would
be
very
confusing
if
we
have
a
Windows
and
a
windowing,
so
yeah
I
guess,
let's
resume
that
discussion.
D
Yeah,
so
there
are
a
couple
paths
we
have
to
take
consider,
so
we
can't
just
change
like
we
can't
put
it
under
like
a
different
name.
Space
like
we
can't
just
do
silk.net.wind
or
dot
platform
dot
Windows,
because
the
class
name
will
still
be
windows,
so
I
think
I
I
think
we
do
want
to
have
since
we're
in
3.0
we're
going
to
try
to
do
Objective
C
bindings,
it's
the
plan,
at
least
when
I
think
yeah,
I,
think
I.
D
C
C
Sorry
we're
talking
about
windowing,
so
so
you
so
you
may
look
up
platform
instruction.
Leyland.
D
Not
really
platform
abstraction,
there
I
mean
I
mean
like
bindings
to
the
specific
platforms
apis
so
like
there
will
be
Windows,
posix,
Linux,
Darwin
and
whatever
else
we
would
want
to
bind
to
so
like
and
then
we
could
scope,
graphics
and
then
windowing
and
such
since
we
have
the
opportunity
in
3.0
to
change
namespaces
and
class
names,
and
since
this
is
relevant
to
the
point
of
topic
of
what
do
we
name
when
SDK
I
think
we
should
Explore
More
changing
how
we
manage
namespaces,
because
I
think
it
could
lead
to
easier
searchability.
C
C
It
doesn't
sound
like
the
worst
thing
in
the
world
because
I
suppose,
if
you
have
one
for
like
every
I
guess
header
set
but
like
you
have
a
you,
have
an
SD
a
platform
or
an
SDK
for
for
Windows
or
you
have
one
for
like
the
Linux
headers
or
whatever
it
does.
It
does
make
sense.
C
I!
Guess
it's
just
bike
shedding
on
the
name
a
bit
because
calling
it
platform
might
have
the
platform
connotation,
the
the
platform,
abstraction
layer
conversations
because,
especially
when
you
consider
the
naming
conventions,
the
some
of
our
related
libraries.
Some
similar
libraries
are
using
light
open
TK
when
they
say
platform,
they
refer
to
the
platform,
abstraction
layer
and
given,
given
how
many
of
the
zilt.net
users
are
for
more
open.
C
Zk
users
I'm
worried
about
that
us
calling
a
a
set
of
bindings
for
a
particular
platform
in
a
platform.
Namespace
might
cause
confusion.
D
We
could
do
silk
smart.os.132
instead
of
dot
platform.
I
think
that
might
give
a
more
clear
and.
F
F
D
Like
the
the
sys
calls
and
the
Linux
libsy
header
extensions,
and
it
was
like
there's
the
posix
standard
of
things
and
then
Darwin
also
has
its
own
extended.
Lib
C
I
think
it
does
make
sense
on
those
platforms
in
terms
of
libsy
because
they
don't
all
have,
because
you
have
the
base
positive
slip.
C
you
have
the
bass,
C
standard,
lib
C,
and
then
you
have
the
extensions
on
top
of
those.
C
I
think
we're
talking
about
different
things,
because
when
the
win32
package,
as
it
currently
stands,
includes
basically
the
entirety
of
the
windows,
SDK
and
likewise,
obviously
Mac
OS
has
a
Mac,
OS
SDK,
which
I'd
imagine
will
be
a
similar
process.
C
It
will
have
the
Basics
everything
from
basic
kernel
stuff
to
all
of,
like
the
the
metal
kit,
the
AR
kit
and
everything,
and
all
of
all
of
the
other
various
libraries
that
the
Mac
OS
SDK,
provides
under
the
same
with
the
iOS
SDK
Linux
is
the
outlier
there
because
it
doesn't
have
a
standard
set
now.
I
know
that
a
terror
before
I
misspeak
I'm,
going
to
double
check
but
I,
think
Terror
FX
has
some
posix
stuff.
C
Well,
there's
certainly
the
next
level
yeah
yeah,
there's
other
stuff.
D
F
So
maybe
I'm
wrong
here,
because
I'm
not
that
that
Red
Apple
news
right
now,
but
I
I,
think
all
of
those
would
be
essentially
layering
on
each
other
and
not
so
much
to
completely
separate
subsets
yeah.
D
I
think
I
think
we
might
maybe
we
should
go
with
the
there's,
a
single
silk.net.lib
C
with
all
the
platforms,
and
then
you
just
expected
to
use
trimming
like
with
like
within
32,
where
it'll
have
the
entire
win32
the
entire
Windows
SDK.
Maybe
we
could
do
a
single
silk.net.lib
C
package,
which
has
the
base
C
standard,
then
posix,
then
Darwin
and
Linux
and
freebhd
on
top
of
that,
and
then
I
mean
maybe
Min
GW
or
something
I.
C
I
think
I
still
think
that
the
the
these
sort
of
concepts
are
blurring,
though
so
I
agree,
I
agree
with
libsy
in
the
but
libsy
it's
a
standard
interface
for
multiple
for
multiple
implementations
of
it.
Obviously
there
are
different
Library
names
and
whatnot,
but
fundamentally
it's
a
standard
and
we've
we've
we've
bind
it.
We've
made
bindings
for
standards
a
million
times
before
we
it's
not
going
to
be
different
for
libsy,
the
obviously
the
windows
SDK
other
than
the
libsy.
In
fact,
yeah
Lipsy
stuff
for
Windows
is
not
in
the
windows.
Sdk.
C
That's
in
the
C
plus
SDK,
a
totally
different
thing.
The
windows
SDK
refers
to
the
apis
that
the
wind
that
the
Windows
operating
system
exposes.
So
that's
everything
from
DirectX
at
the
kernel
32
to
the
user,
32,
it's
the
GDI
plus
it's.
Basically
everything
and
I
mean
I.
Think
I,
remember
Tana,
saying
in
a
Discord
comment
at
some
point
saying
it's
basic
the
window.
The
Terra
effects
are
interrupt.windows.
Package
is,
as
close
as
you
can
get
to.
C
Hashtag
include
insert
Windows
header
name
here
in
C,
sharp
and
I
think
that's
very
much
what,
where
I
want
it
to
remain,
and
in
the
its
logical
subsets
of
apis,
or
at
least
the
subsets
of
apis
that
are
packaged
together.
So,
for
example,
we'd
have
a
Mac
OS
SDK,
because
there's
an
actual
Mac
OS
SDK
same
with
the
iOS
SDK
and
it
you
know.
This
is
an
established
precedent
as
well.
If
you
look
at
xamarin.mac,
that's
all
of
the
Mac
OS
bindings
in
one
package
or
in
one
SDK,
I,.
F
Think,
well,
yes,
I
guess,
but
it's
not
really
so
much
of
an
outline.
It's
just
two
systems
right,
it's
like
essentially
a
micro
ssdk
will
enlarge.
Parts
include
everything
that
you
would
find
on
Unix.
So
those
who
are
like
closely
related,
of
course
on
Windows,
it's
very
simple,
because
you
just
get
the
latest
Windows
release
and
then
that's
essentially
win32
so
like
that.
There's
no
ambiguity
there,
because
you
just
get
the
latest
version
and
that
that
that's
the
that's
a
grand
truth
essentially,
but
for
Unix
and
and
essentially
also
for
Mac
OS.
F
You
have
the
problem
of
there's
just
some
very
loose
standards
that
are
very
old
and
then
in
large
Parts
have
evolved
that
different
people
have
different
interpretations
or
different
extensions
with
them,
and
so
it's
much
more
difficult
to
model
that,
and
then
it's
essentially
similar
to
opengl,
where
you
have
many
different
versions
and
many
different
extensions
at
opengl.
We
just
barely
managed
to
represent
that
and
then
I
don't
see
how
we
would
do
this
with
Unix
the
same
way.
We
could
do
it
with
n32
just
because
there's
so
much
more
diversity.
There.
D
Yeah
I
think
yeah,
it's
It's
Tricky
with
Unix
and
positive,
because
there's
there's
like
four
layers
of
extensions
that
you
would
need
to
do
because
posic
extends
lib
C,
then
you
have
Linux
extending
posix
and
then
gnu
extending
Linux
and
there's
also
musical
extending
Linux,
but
muzil
also
implements
some
of
the
new
stuff
and
gnu
influence
on
them.
It's
a
complete
mess
on
Linux,
so
it's
it'd
be
tricky
to
provide
a
complete
lib
C
thing
without
having
a
nightmare.
D
C
D
F
It's
definitely
something:
we've
won
because
it's
like
fairly
straightforward
in
terms
of
Maintenance
also-
and
we
would
cover
all
the
basics,
and
then
we
would
also
I
mean
we
would
also
cover
things
like
War
X
and
things
like
that.
The
problem
is
Maybe
I'm
Wrong
here,
but
isn't
project
so
minimal
that
really
the
existing
like
they
just
existing
standard
Library,
already
contains.
Basically
everything
you
could
want
from
posix.
D
Not
everything
I
think
I
think
modern
posix,
the
the
modern
project
API,
is
actually
quite
expansive.
It
has
a
lot
of
stuff
that
people
find
very
nice
When
developing,
like
Linux,
apps
or
yeah
I,
think
I
think
it
is
worthwhile
to
do
it
just
for
some
of
the
stuff.
H
Posix
is
strictly
a
superset
of
lib
C
and
yeah.
There
is
some
functionality
that
you
can
only
get
through
politics,
like
all
of
the
all
of
the
OS
level,
timer
apis,
the
the
equivalent
of
query
performance
counter
on
Linux
is
defined
by
posix.
That's
what
they
get
clock
clock
monotonic
is
from
is
is
from
the
posix
spec,
but
yeah
posix
spec
is
also
huge
and
it
is
very
non-deterministic
across
platforms.
Sometimes
even
between
like
red
hat
and
Ubuntu,
you
can
get
vastly
different
definitions
for
some
of
the
underlying
type
defs.
D
F
Thought
of
what
I
would
probably
recommend,
so
we
just
basically
just
take
like
the
standard
ellipse
implementations,
which
I
think
is
basically
just
muzzle.
F
Maybe
GCC
probably
has
some
differences,
I'm,
not
sure
quotations
on
Linux
and
then
we
basically
take
those
and
just
make
two
separate
packages.
They'll
have
a
bunch
of
overlap,
but
it's
probably
the.
F
D
G-Lib
c
can
differ
from
distro
to
distro.
That's
what
Tanner
was
talking
about.
The
definitions
of
the
types
differs
from
distro
to
distro,
sometimes
even
if
they're,
even
if
they're,
both
using
lib
C,
it
can
differ,
which
is
why
it
may
actually
be
as
silly
as
it
sounds.
D
We
can
package
our
own
implementation
of
lib
C,
just
a
shared
Library
version
of
muscle
and
muscle
will
talk
directly
to
the
kernel
through
ciscals
and
that
that
would
give
us
a
stable
syscolor,
a
stables,
lip
C
interface
on
all
distros,
because
the
Linux
Cisco
interface
is
stable.
So,
instead
of
instead
of
binding
to
the
user's
system
libsy,
we
package
our
own
and
then
bind
to
that
which
would
give
us
a
single
standard
Target
for
posix
spikings
on
Linux.
F
I
guess
that's
sort
of
what
like
native
applications
would
do
anyways
by
by
just
statically,
linking
most
of
but
you'd
find
that
look
bigger,
yeah.
F
Yeah
I
guess
I
I
guess
I
will
work
I'm,
just
not
sure
what
the
native
iot
you
know
what
what
would
come
out
there
but
I
I
guess
it
will
work.
Fine
yeah.
D
F
Yeah,
that's
I
think.
Ideally
we
would
do
whatever
the
runtime
tries
to
do
here
as
much
as
possible,
but
I'm
just
not
sure
how
possible
that.
D
Actually
is
I
think
the
run
time
just
presumes
you're
using
glibsy,
because
I
I
think
I
I
had
problems
running
a
donut
runtime
on
muscle
on
muscle
systems,
I
think
I
had
to
install
G
compat,
so
I
think
I
think
we
may
have
to
rely
on
dynamically,
linking
muscle
even
on
even
even
with
Native
aot
I.
Don't
we'd
have
to
test
it
to
be
sure,
but
I
don't
think
we'd
be
able
to
statically
link
muscle
with.
H
Way
it
works
is
basically
that
we
link
against
the
whatever's
built
into
the
system.
So
on
Ubuntu
we
link
into
glibc
on
sent
to
West.
We
link
into
musil
right.
H
You
have
to
use
the
the
version
of.net
that
was
built
for
the
system
for
it
to
kind
of
work.
We
do
support
both
out
of
the
box,
but
we
also
have
our
own
wrapper
Library,
which
we
call
system.native,
and
that
is
basically
our
own
C
plus
library
that
wraps
various
C
apis
and
make
sure
that
we
can
call
them
in
a
deterministic
fashion,
handling
any
plus
platform
differences
right,
basically
how
it
works.
F
So
so,
there's
basically
no
way
for
us
to
reuse
any
different
like
any
OS
difference
handling
at
all.
You.
H
Can
do
various
tricks
to
kind
of
make
it
all
work
like
you
can
do
checks
such
as
if
runtime
information
or
operating
system
is
you
know,
specific,
distros
and,
and
things
like
that
and
I
do
some
of
those
tricks
in
various
libraries,
like
my
me,
malic
port
or
my
own
terafx
interopolib
c,
but
you
know
it
can
get
quite
complicated
at
times
and
and
you
really
want
to
try
and
avoid
those
scenarios
as
much
as
possible,
where
you
can.
D
Yeah
I
think
I
think
to
avoid
distro
messiness
and
just
make
sure
we
can
provide
a
consistent,
posix
interface
I
think
by
default
at
least
we
should
always.
We
should
always
call
into
a
dynamic,
muzzle
compilation
that
we've
had
like
any
other
native
Library.
We
would
pack
I
think
that's
the
only
way
to
actually
provide
a
stable
interface
on
Linux,
because
muscle
I
think
I,
don't
know
if
we
can
package
glibcy
I
think
blipsy
is
just
way
too
massive
for
us
to
package
properly
and
even
then
I
think
it
has
some
compact
problems.
D
F
They
will
probably
work
I
feel
like
that's
kind
of
moving
the
problem
down
to
a
model
which
I
guess
is
fine,
I'm,
not
sure
how
much
it
really
helps
solve
anything
given
I
mean
Mausoleum
just
has
to
figure
out
basically
how
to
do
things,
and
then
it's
just
like
it's
the
same
problem.
We
have
just
moved
down
once.
D
It
isn't
because
muscle
doesn't
interact
with
the
system
at
all.
It
talks
with
the
kernel
directly
through
the
the
Linux
Cisco
interface,
which
is
stable
across
releases,
so
so,
and
so
it
wouldn't
have
to
do
the
the
per
distro
hacking
nonsense,
because
it
it
doesn't,
it
doesn't
work
at
that
level.
It
works
one
level
behind
that
it
works
at
the
Cisco
interface.
I
C
A
C
C
C
C
The
main
thing
for
me
is
that
you
know
claim
shop
has
proved
itself
to
be
very,
very
stable
and
sort
of
like
a
a
reliable
source
of
Truth
when
it
comes
to
generating
bindings
and
Terror
effects
is
basically
just
an
extension
of
that
in
that
it
pre-configures
it
for
the
various
bindings,
and
we
can
because
of
the
vast
user
base,
that
it
is
the
Terra
factors
well
I,
say
fast
user
base.
You
know
you've
got
projects
like
paint.net
using
it.
C
You've
got
projects
like
compute
sharp,
which,
by
extension
even
has
the
Microsoft
store
using
it.
You
know
it's
a
it's
a
reputable
set
of
bindings
and
it's
one
you
can
count
on
being
correct
more
so
than
our
podged
version
of
our
bodged
trim
down
and
hacked
version
of
of
the
various
clang
sharp
functions
that
make
that
was
taken
at
a
subset
in
time
that
make
build
tools
work.
C
So
if
we're
burning
down
build
tools
and
replacing
it
with
the
the
important
bit
with
Clank
sharp
might
as
well
use
some
known
vetted
configurations
for
it
and
therefore
thereby
anything
the
terafex.interop
has
we
can.
We
can
take
those
known
good
configurations
and
make
them
silkier.
So
if,
if
there's
already
a
terafex
that'll
interrupt.lib
C,
we
can
have
libsy
bindings
so
at
no
cost
to
us.
C
Obviously
we're
not
going
to
be
just
limiting
ourselves
to
everything
that
terrafx.interop
has
because
we're
gonna
have
things
like
opengl
binding,
so
we're
going
to
have
more
bindings
in
the
future.
Again
we're
going
to
revive
all
of
this,
but
it
this
pervy
Bindings
that
you've
had
and
all
of
the
the
ascent
bindings
and
everything
that
we
can
that
we
already
have
but-
and
we
can
always
add
more
to
that
portfolio
but
I-
guess
anything
that
we're
not
getting
for
free.
We
probably
shouldn't
include
for
3.0's
initial
development.
D
C
D
F
I'm,
just
so
the
reason
I
bring
it
up,
isn't
necessary
because
I
think
we
shouldn't
say
make
these
minings
it
is
about.
C
To
be
honest,
that's
kind
of
where
I'm
at
at
this
point
is
that
I
think
I
think
we've
proven
in
this
call
that
they're
all
very
unrelated
sets
of
bindings
and
we
can't
really
put
them
under
one
umbrella,
so
I
think
I'm
a
lot
more
content
with
having
dot
win32
than
I
was
at
the
start
of
this
court.
Put
it
that
way,
probably
because
there's
so
many
intricacies
and
I
feel
like
win32.
C
It
differentiates
it
enough
that
all
of
our
core
concerns
are
addressed
and
if,
if
there
is
a
future
categorization,
we
can
make
that
categorization,
but
I
think
that
those
bindings
in
particular
win32
is
fine.
I,
don't
know.
What's
everyone
else
think.
C
Cool
right,
she'll
update
my
note
so
I
think
that's
the
bindings
portion
pretty
much
complete.
Obviously
we
have
trimmers
now
so
we're
not
gonna
have
extension
packages
hooray,
so
I
guess
that
moves
us
on
to
bindings,
not
binding.
Sorry,
we've
just
done
bindings,
the
blue,
the
high
level
utility.
So
that's
things
like
windowing
and
input.
C
F
I
think
we've
had
a
lot
of
the
discussion
when
we
initially
planned.
The
group
at
all
I
think
I
still
agree
what
we
discussed
back
then,
but
I
think
we
basically
I
I,
think
the
solution
we
came
up
with-
and
that's
also
like
documented
in
proposals
is
I
still
feel
the
same
way.
I
did
back
when
we
came
up
with
it.
Initially,
it's
a
good
idea,
but
it's
just
working
working
around
an
inherent
limitation
and
how
C
sharp
analysis.
So
there's
not
that
much.
We
can
do
to
improve
just
further
I
think.
F
The
only
thing
we
can
really
do
is
simplify
and
then
we
go
towards
something
like
we
have
right
now
with
2x,
but
it's
much
simpler,
but
also
less
typesafe
and
less
extensible.
F
That's
probably
a
scale
that
we
can
go
either
way
on,
but
I'm
pretty
happy
with
where
we
landed
last
time.
Basically,.
C
So
that's
the
windowing
and
input
and
the
structure
that
goes
along
with
that
yeah
who's
relatively.
F
Happy
with
what
we
decided
on
first
to
get
it
but
I
mean
so
I
think
the
core
of
that
proposal
is
basically
the
interface
type,
checking
and
yeah
I
think
that's
it's
still
decent.
C
Skye,
do
you
have
much
experience
with
the
open,
ZK
pal,
because
I
know
you've
discussing
that
yesterday?
Do
you
know
roughly
what
the
outline
is
for
just
concept
context
for
what
other
libraries
were
doing,
because,
obviously
we're
gonna
look,
we've
discussed
about
looking
into
avalonia
how
they
structured
it
and
I
guess
really.
We
need
to
get
as
much
information
as
possible
if
we
want
to
start
raising
these
questions,
obviously
whether
we
want
to
even
start
raising
these
questions
is
another
discussion,
but
you
know
if
we're.
C
Having
these
discussions,
if
you've
got
information
on
opentk-
and
you
can
explain
it
to
us-
that'll
be.
J
Great
I
mean
I,
mean
I
mean
to
my
knowledge,
it's
literally
just
something
like
sdl,
it's
it's
low
level
windowing
and
then
they
write
all
the
high
level
stuff
around
it.
I
don't
think
it's
much
beyond
that.
I,
don't
think
it
does.
I
think
it
does
more
than
glfw,
but
it
doesn't
do
as
much
as
sdl
and
yeah,
so
it
does
the
windowing
and
input
and
that
sort
of
stuff-
and
that's
about
it,
really
I
think.
D
Makes
sense
one
thing:
I
would
like
to
see
in
at
least
some
capacity
built
into
silk,
because
if
we're
going
to
be
going
down
to
the
level
of
per
platform
implications
of
windowing,
which
I
believe
is
planned
for
3.0
like
directly
implementing
yeah
300X
at
some
point,
I
think
3.0
will
have
glfw
as
just
the
Baseline
but
for
3.x
I.
Think,
since
we're
going
to
be
going
that
deep,
we
should
be
able
to
provide
some
very
basic
facilities
like
message
boxes
and
like
a
file.
Picker
I
think
that's
something
that.
A
D
D
F
Think
that's
just
an
unsolved
problem
in
general,
I
I,
don't
know
if
anyone
who
has
like
an
idea
how
to
actually
accurately
open
like
a
file
player
in
every
platform,
I
think
that's
not
really
something.
That's
like.
F
D
A
C
library
which,
which
actually
does
it
relatively
well,
it
will
pick
between
win32
Coco,
QT
and
gtk.
It
it'll
determine
based
on
the
platform
and
what
desktop
environment
you're
using
and
it'll
it'll
open
the
correct
file,
picker
for
said
platform
and
worst
case
I,
think
it
falls
back
to
some
immediate
mode.
Api.
F
So
so
maybe
I'm
missing
something
but
gtk
and
qt
are
both
native
right.
Like
I,
say:
we've
opened
a
new
window
and
then
use
those
to
like
Draw
Something
themselves.
D
Both
gtk
and
cute
will
open
a
window
themselves
and
draw
to
it,
but
that's,
unfortunately,
the
only
way
to
make
things
look
native
on
Windows
and
Mac
OS.
This
is
really
easy.
There's
there's
set
apis
for
message,
boxes
and
file,
Pickers
that
are
the
correct
ones
to
use,
but
on
Linux
it's
a
bit
more
finicky,
I
think
for
Linux.
Our
best
option
is
if
you're
on
KDE
you
dynamically
load
queue
and
open
a
message
box.
If
you're
on
gnome
dynamically
load.
F
Unix,
you
can
look
to
Firefox
and
how
to
do
this.
They
do
it
fairly
well,
I'm
more
about
like
other
platforms,
so
Android
and
iOS.
It's
very
difficult,
I
think
to
do
this
in
a
way
that's
compatible
everywhere
and
then
on
on
other
platforms.
It
gets
even
more
complicated
with
something
like
tizen
or
with
something
like
a
web
browser.
It
gets
more
complicated,
even
so.
I
think
that's
very
hard
personally,
I'd
be
very
happy
if
we
could
even
just
get
clipboard
to
work,
for
example,
everywhere.
D
Yeah
think
best
bet
for
stuff,
like
clipboard,
is
just
attempt
to
you.
The
windowing
apis
and
X11
have
their
own
clipboard
apis
I.
Think
Windows
has
a
global
one
same
with
Mac
OS
I'm,
not
sure
about
the
I'm,
not
too
I
haven't
messed
too
much
with
the
clipboard
apis
on
those
platforms,
but
for
clipboard
I
think
we
can
reasonably
get
something
working
for
all
platforms
with
file.
Picker
is
a
lot
harder
like
to
have
a
truly
cross-platform
file.
Picker.
The
only
things
you
could
expose
are
open
file,
picker
and
path
to
file
or
not.
D
F
I
think
that
the
only
thing
that
you're
like
able
to
do
efficiently
everywhere
is
get
and
set
text
and
then
also
clearing
it.
F
So
again,
this
is
something
I'm,
just
like
picking
up
from
looking
at
what
avalonia
does
here,
I
think
looking
at
how
they
handle
this
from
this
pretty
good
way
of
doing
it,
because
they
just
know-
and
they
are
widely
used
and
like
they
probably
know
what
they're
doing
but
yeah.
C
Yeah
I
mean
looking
looking
at
the
current
panel
2.0
implementation
in
opentk.
It
basically
just
looks
like
a
glorified
dependency
injection
container,
but
done
manually
for
the
various
things
like
clipboard
and
and
mice,
which
I
guess
is
fair,
but
also
that
model
I.
Suppose
those
models
don't
really
work
when
you
have
for
something
like
Android
and
iOS,
where
you've
got
a
Central.
Main
activity
objects
that
you
need
to
create.
C
All
of
this
within
so
I'm
still
confident
that
our
surface
API
is
designed
in
a
way
that
is
that
is
compatible
with
sort
of
both
I
guess,
but.
F
F
Api
hits
that
very
well
it's.
It
is
truly
right
once
one
everywhere.
The
problem
is
that
it's
super
verbose,
so,
for
example,
I'm
looking
at
52
essentially
have
to
extract
some
kind
of
clipboard
object
from
your
servers
and
then
pass
it
around
everywhere,
which
which
then
quickly,
if
you
don't
use
like
a
a
fancy
injection
framework
of
some
sort,
you'll
quickly
end
up
with,
like
passing
around
like
10
15
variables,
just
to
like
get
those
partialities
everywhere
and
even
with
even
worth
the
integration.
F
C
And
I
suppose
something
that
something
like
right
like
this
is
what
isn't
why
I
guess
in
this
scenario,
the
open
TK
scenario
is
that
it
this
isn't
intended
to
be
used
directly
by
users,
whereas
the
surface
API.
The
reason
why
we've
kept
it
so
close
to
the
existing
windowing
apis,
because
we
do
intend
for
users
to
use
it.
C
But
it's
trying
to
figure
out
how
do
we
make
that
work
because
I
mean
2.0?
Sorry,
1.x
even
has
the
very
lazy
decision
of
well.
You
have
a
view
and
you
have
a
window,
those
your
two
boxes,
whereas
try
to
make
something
that
works.
That
is
truly
right
ones
and
run
everywhere
without
having
it.
I
mean
it's
fundamentally
not
solvable,
because
I
mean
if
you,
if
you
want
to
dynamically
check
that
some
specific
functionality
is
available,
you're
going
to
use
an
interface
card.
C
C
F
Thing
is
ideally
there
will.
There
would
be
a
way
to
combine
interfaces
dynamically
somehow,
so
you
only
have
to
pass
around
exactly
once
exactly
one
object,
but
that
sort
of
thing
it's
C,
sharp,
unfortunately
so
I
think
we'll
just
have
to
live
with
passing
around
a
lot
of
objects.
C
Yeah
right
now,
yesterday
we
just
discovered
terafex
terafex,
proper,
not
Terror,
effects
or
interrupt,
and
because
because
I
know
you
mentioned
that
you
have
a
UI
package
and
mentioned
something
about
that.
Did
you
have
to
tackle
any
of
these
problems?
Do
we
have
an
easy
out.
H
D
Yeah
windows,
at
least
you
can
rely
on
win32,
always
being
there
on
Linux.
You
have
no
guarantees,
you
must.
You
must
suffer
well.
C
C
To
make
Sergio
happy
and
it's
Sergio
happy
and
Implement
YouTube
uwp
sport.
H
H
So
you
know
you're,
even
if
you're,
just
trying
to
Target
x-lib
or
just
Wayland
or
just
xcb,
no
matter
which
one
you
target
you're
still
going
to
be
stuck
doing
her
Destro,
acting
to
make
various
things
happy
and
and
dealing
with
things
like
the
the
message
pump,
not
guaranteeing
messages
go
in
a
certain
order,
so,
if
you're
shutting
down
the
app,
for
example,
you
have
to
you
have
to
be
robust
in
the
face
of
not
receiving
messages,
saying
that
things
are
being
closed
down
and
or
being
robust
in
the
face
of
something
shutting
down
down
and
then
sending
you
a
message
after
the
fact
that
was
technically
from
before
the
window
was
supposed
to
be
closed,
some.
D
C
C
D
C
Yeah
so
are
we?
Are
we
going
to
just
stick
with
what's
already
approved
there,
because
I
know
there
was
a
lot
of
discussion
yesterday,
but
if
we,
if
we
think,
if
that's
the
conclusion,
then
we
can
just
stick
with
what
we've
got.
I
know
that
a
Community
member
try
to
implement
I'm,
not
sure
how
that
went.
B
F
Mostly
because
when
we
ended
up
or
when
I
ended
up
reviewing,
it,
I
ended
up
discovering
that
there's
a
bunch
of
problems
with
the
platform
with
the
proposal
holders
that
we
like
waved
through
basically-
and
we
didn't
do
a
good
enough
job
of
reviewing
those
proposals.
F
So
when
we
didn't
actually
saw
you
can
just
like
the
type
definitions,
because
he
was
only
working
on
just
getting
the
type
definitions
in
there
were
so
many
problems
that
he
it
was
unreasonable
to
expect
him
to
like
finish
it,
and
then
it
never
went
anywhere
after
that,
because
we
essentially
we
we
have
to
revisit
all
those
proposals
and
they
were
more
in-depth
and
proper
analysis
of
like
is
this?
Actually
what
we
want?
Does
it
even
makes
sense?
F
Internally,
basically,
yeah
there's
a
bunch
of
problems
there
you
can
look
at
the
VR,
there's
I.
Think
I
left,
like
20
plus
comments,
so
yeah.
C
Cool
so
I
guess
we'll
leave
the
proposals
there
unless
there's
any
immediate
wins
that
anyone
can
think
of
on
the
spot,
but
yeah
I
think
with
I
I.
Think
the
I
guess.
The
conclusion
for
yesterday's
discussions
is
that
it
would
be
nice
to
do
a
lot
more
with
this,
but
there's
not
an
easy
way
to
do
it.
C
Let's
just
stick
with
what
we
got
cool,
so
I
guess
with
with
3.0
going
forward.
So
obviously
I'm
going
to
carry
on
with
my
silk
X
I
guess
is
there?
C
Is
there
anything
from
you,
the
maintainers,
that
you
would
that
you'd
like
to
see
from
it
like
in
terms
of
actual
you
know,
I
guess
how
do
we
want
to
track
the
progress
of
it
really.
E
A
C
Realistic
right
now,
this
is
an
offshoot
project
and
we
need
to
decide
when
it
well,
if
and
and
when
it,
the
effort
to
recombine
and
how
we,
how
we
track
that
Apex
I,
guess
that
Nexus,
whatever
the
word.
F
F
C
And
I
suppose
what
is
it
that
you're
actually
looking
to
get
out
of
this
like?
Do
you
want
a
full-blown
pull
request?
Out
of
all
this
I
mean
eventually,
but
I
mean
I,
guess
if
this,
if
this
is
going
to
end
up
in
the
main
repo,
eventually,
what
will
you
be
looking
for
going
up
to
that
point,
you,
the
maintainers,.
C
Have
like
one
big
gigantic
pull
requests
when,
whenever
there's
some
arbitrary
line,
that
means
it's
ready
to
be
merged
or
ready
to
go
up
for
review
is
met,
but
I
guess
is:
is
there
anything
we
can
do
to
more
well-defined
that
or
does
it
just
play
it
by
ear.
D
I
guess
we
could
have
I
guess
once
we
feel
it's
in
a
decent
enough.
State
I
think
we
could
have
a
photographer
or
a
work
group
meeting
to
go
through
the
code
and
just
decide
whether
it's
the
right
path
to
go
like
once.
We
feel
it's
in
a
good
enough
state
to
be
a
possible
replacement
for
the
current
3.0.
D
H
F
So
to
me,
the
like
absolute
minimum
thing
that
I'd
probably
I
mean
you
can
always.
You
can
always
talk,
obviously,
but
to
me
like
the
the
like
minimum
to
like
consider
or
like
talk
about,
if
this
direction
makes
sense
is
making
like
glfw
bindings
that
that's
at
least
always
the
standard
that
I
held
what
I
did
for
3.02.
So,
like
the
the
point
where
I
put
out
Alpha
releases
for
3.0
on
my
work
would
be
like
fully
working
jlsw
findings,
because
those
are
aluminous
bar
that
you
can
reach
it
fairly
easily.
F
But
it's
also
something
that
actually
works,
and
you
can
look
at
some
basic
like
Transformations.
You
can
that's
where
they
actually
works,
so
I
I
think
at
least
some
basics
of
w
writings
would
be
really
nice
to
look
at
where
this
could
go.
D
F
F
C
Cool
because,
like
the
point
that
it
starts
the
point
that
it
it's
merged
into
back
into
the
main
repo
I
I
do
want
to
start
getting
like
night
leads
well
a
nightly
feed
up,
essentially
so
that
people
can
start
pulling
it
down
for
the
bleeding
edge
people
I'm
thinking
about
the
skies
in
the
room
that
just
want
the
absolute
bleeding
edge
of
everything.
Oh
that,
basically,
anyone
who
has
ever
used
the
experimental
weed
ever
is
able
to
if
they
want
to
just
try
it
out
and
see
a
noble
trial.
C
D
Recently,
we
did
speak
more
about
the
a
lot
of
Team
talk.
Someone
wrote
a
rapper
for
webg
for
a
current
2017
2017.1
web
GPU
bindings
like
a
more
higher
level
rapper,
and
that
brought
back
on
the
discussion
of
the
object
wrappers
that
I
had
proposed
in
the
last
coffee
and
code,
and
we
talked-
and
we
discussed
a
lot
more
about
how
those
would
actually
work
in
depth
and
how
that
would
interact
with
a
possibly
even
higher
level.
D
Rapper
like
currently
in
web
GPU,
there's
a
lot
of
unsafe
and
what
the
person
I
forgot
their
name,
but
they
had
made
a
rapper
which
removes
a
lot
of
the
unsafe
and
replaces
it
with
like
type
safe,
structs
and
such,
and
so
we
were
discussing
how
that
kind
of
higher
level
abstraction
would
fit
with
the
lower
level
abstraction
that
I
was
talking
about
where,
like
instead
of
wgpu
device,
create
buffer,
it
would
be
buffer.create
device
and
the
buffer
with
the
the
device
object
would
store
the
device
pointer
and
the
web
GPU
instance,
or
not
the
instance
d.
D
It
would
store
the
web.
Gpu
c-sharp
managed
object.
We
were
discussing
how
that
would
interact
with
higher
level
bindings,
and
it
would
probably
do
it
through
extension
methods,
well
kind
of
like
how
we
do
it
with
com
with
with
computers.
Right
now,
where
we
have
extension
methods,
but
instead
of
just
running
the
base
methods,
there
would
be
the
base
wrapper
and
then
a
second
higher
level,
rapper,
probably
in
silk
community
and
having
them
interact
in
a
clean
way.
D
Maybe
you
think
about
possibly
exposing.
D
We
do
we
do
have
the
build
cache
which
they
could
swallow
to
generate
like
some
of
the
higher
level
stuff,
but
yeah
I
was
thinking
a
lot
about
how
how
we
could
help
keep
a
community
project
wrapping
over
ours
easier
in
sync,
with
findings
updates,
since
web
GPU
is
still
mostly
in
flux.
Easing
the
life
of
someone
else
rapping
over
us
I
think
is
something
I've
been
thinking
about
and
I.
D
Think
one
of
the
things
is
going
to
be
making
our
bill
Our
Generation
cache
is
a
bit
easier
to
digest,
because
currently
it's
a
bit
nightmarish,
I
I've
tried
writing
something
to
to
ingest
the
build
caches
to
do.
J
F
So
so
maybe
I'm
missing
something
here,
but
what's
wrong
with
this
having
a
sub
module
and
then
like
they
have
they
having
a
sub
model
of
Turbo
net
and
then
just
like
updating
the
latest
commit.
D
D
Some
of
the
work
of
generating
these
extension
methods,
so
a
lot
of
them
should
be
able
to
be
easily
generated
just
through
a
second
post-processing
step,
but
how
to
have
that
post-processing
step
be
entirely
separate
and
after
the
fact
more
easily
is
something
I
I'm,
not
sure
how
to
do,
because
our
current
build
caches
just
aren't
easy
to
work
with.
D
C
Is
it
is
definitely
a
valid
concern,
I
suppose
well,
especially
in
the
Advent
of
all
the
clang
sharp
issues,
and
that
we
can't
upgrade
our
clang
sharp
version
trivially
now,
we've
basically
declared
build
tools
unmaintainable
through
that
issues,
so
any
Solution
on
the
build
caches
would
be
or
anything
derived
from
the
build
caches
in
the
similar
mechanism
would
be
a
stock
Gap,
Solution
One
things
I
do
want
to
do
for
sorts
of
tracks
is
to
so.
C
Obviously
we
have
the
mod
system,
but
I
also
want
to
allow
other
things
to
hook
into
that.
So
in
theory,
you
could
just
put
in
a
new
a
new
get
package
ideas
in
that
mods
list
and
it
automatically
downloads
it
and
add
it.
You
know:
I
want
silk,
touch
to
be
extensible
and
to
provide
the
generation
mechanisms
of
this.
Obviously,
it
would
then
mean
we
have
to
catch
the
outputs
of
Clan
sharpen's
trust
that
someone
will
hook
into
our
bindings
this
way,
but
yeah
I
guess.
C
We
can't
really
make
any
solution
for
that
today,
because
any
solution
will
be
built
around
2.x,
and
that
has
a
end-of-life
date.
That
is
all
in
everyone's
heads,
but
it's
not
really
it's
Schrodinger's
end
of
life
date
in
fact
he's
shredding
his
build
tools.
F
I
mean
I
think
the
story
goes
into
the
main
design
goal
of
still
there's
three,
where
it's
like
there.
We
can
very
easily
solve
this
by
just
well
by
just
having
by
just
having
that,
like
internal
representation,
where
we
can
save
two
files,
I
think.
F
But
it's
like
a
it's
like
a
chicken
and
egg
you,
if
you,
if
you
want
extra
accessibility,
you
have
to
put
in
the
extra
work
and
we
just
don't
have
the
time
for
it,
and
so
we
can't
really
solve
the
accessibility
problem
as
well
as
it
would
be
nice
to
do.
C
C
Cool
any
more
for
any
more.
J
D
B
D
Want
the
next
one
to
be
next,
one:
okay,
well
I'm,
still
going
to
be
in
Washington
until
August
1st,
so,
ideally,
I
don't
have
to
hook
up
my
developer
kit
to
a
TV
and
be
sitting
in
a
chair
with
my
mouse
on
the
very
tiny
armrest.
So
ideally
we'd
schedule
it
for
I,
don't
know!
Maybe
the
weekend
after
I
get
back
so
like
August,
5th,
sometime,
I,
think
I
think
that's
the
weekend
after
I
get
back
home.
C
D
Yeah
but
I,
don't
I,
don't
want
to
subject
to
people
to
my
phone's
microphone.
It's
not
very
good
right.
F
That
makes
sense,
yeah
yeah
I
mean
sure
the
fifth
was
fine
for
me,
but
pretty
much
anytime
works
fine
for
me,
just
paying
me
and
I'll
be
there.
C
Well
yeah,
so
the
idea
is
with
these
copies
and
codes.
Is
that
it's
not
like
the
community
meetings
where
it
has
a
fixed
date
where
everyone
at
every
single
relevant
stakeholder
is
meant
to
turn
up
and
give
their
opinions?
It's
meant
to
be
whenever
we
have
anything
to
discuss-
and
this
is
just
a
a
vessel
by
which
we
can
get
community
input
in
those
discussions
and
also
so
that
we
can
record
them.
So
we
remember
what
we've
discussed,
although
to
anyone
watching,
if
you
can
figure
out
a
way
to
make
chat.
D
C
Just
just
automated
meeting
that
generation
really
so
that
we
know
what
we've
discussed
and
can
make
a
decision
look
but
yeah
I.
Suppose
the
coffee
and
codes
are
meant
to
be
informal
whenever
we
have
anything
to
discuss
really
and
so
that
we
can
record
it
discuss
it
with
other
people
as
well
so
yeah.
Whenever
anyone
wants
to
hold
one
just
just
hold
one
or
say
that
you
want
to
hold
one
well.
All
of
the
maintainers
are
access
to
the.net
Foundation
Channel.
If
they
want
to
do
one
themselves.
C
D
For
today,
I
have
nothing:
I
actually
have
nothing
planned
for
the
day.
I.
Those
are
the
best
days.
Yeah
I.
F
Mean
and
even
you
know,
I
have
to
get
up
at
like
five
in
the
morning
I'm
holding
not
that
much
today.
But
you
know.
C
Hopefully,
this
please
be
productive
and
not
just
a
drag
on
everyone's
days,
because
I
do
I
do
like
having
these
meetings.
It's
good
to
describe.
F
I
have
to
say
sitting
in
meetings
and
like
listening
to
people,
it's
always
a
very
for
some
reason
that
makes
me
always
very
productive
and
when
I
like
code,
while
doing
that,
I,
don't
know
why.
But
yeah
I
feel
that
very
much.
B
D
To
be
honest,
we'll
figure
a
way
to
reduce
allocations.
It's
to
just
remove
allocator,
don't
end.
I
F
I
have
to
say,
I,
always
loved
that
story
of
the
like
the
map
platform
on
like
rocket
or
something
where
they
just
ended
up
putting
in
like
the
null
GC,
because
I
mean
once
once
it
hits
the
ground
all
the
memory.
Will
you
feed
anyway
so
but
no
need
for
GC.
C
Awesome
cool
so
lots
to
go
on
with
well.
Thank
you
all
everyone
for
coming
to
this
good
old
coffee
and
codes.
I
know
we
didn't
discuss
what
drinks
everyone
was
having,
because
you
know:
listen,
listen
to
my
accent,
there's
no
way!
I'm
drinking
coffee.
F
Can
recommend
a
very
good
it's
cooler,
it's
great
lots
of
caffeine
in
my
bloodstream.
C
Oh
nice
yeah,
so
yeah.
Thank
you
all.
Hopefully
we
see
you
again,
not
in
when's
the
last
one
five
months.
What.
C
Anyway,
so,
thank
you
all
for
coming
see
you
next
time,
foreign.