►
From YouTube: 2019-03-28 Rust and WebAssembly Working Group Meeting
Description
A
A
A
And
the
next
item
here
is:
we
are
currently
in
our
first
of
the
revamp
of
the
six-week,
sprints
and
the
end
date
is
the
end
of
April
25th.
If
you
would
like
to
contribute
to,
Reston
has
some
stuff,
but
you
don't
know
where
to
focus
on
or
like
what's
going
on,
check
out
this
list
of
sprint
issues.
These
are
things
that
you
know
we
would
like
to
fix
now.
Ish
yeah.
A
A
A
C
There
could
be
kind
of
future,
but
we
we
can
become
the
chair
promise
so
well,
but
we
can
build
the
features
on
top
of
promises
and
we
can
share
signals
using
MPs,
see
multiple
producers
single
what
see
consumer
yeah
so
I'm
just
reading
on
the
dogs
and
trying
to
figure
out
how
to
how
to
implement
it.
Actually,
originally
I
thought
it
is
something
related
to
future
signals,
but
probably
it's
not
a
mature
yeah.
C
A
No
updates
or
debugging
unless
someone
else
has
an
update.
No
okay,
there's
been
a
bunch
of
cool
stuff
in
the
Wesson
bunch
in
front
this
week.
The
first
is
that
the
NPM
dependencies
RFC
implementation,
that
merged
so
I,
don't
know
if
that
made
it
into
the
latest
release
of
plasma
engine,
but
either
with
master
or
maybe
with
the
newest
release
the
next
release.
A
D
A
Sweet
yeah
there's
this
kind
of
fun
issue.
If
you'd
like
to
read
more
about
it
without
large
u-32
is
turning
into
large
negative
numbers
when
they
get
past
JavaScript
I,
just
felt
like
that
was
worth
pulling
out
together,
is
that
the
no
modules
target
got
a
surprisingly
small
fix
and
all
of
a
sudden
it
works
in
cloud
care
workers
and
just
automatically
slits
their
awesome
thing
just.
D
Yes,
but
we
actually
ended
up
like
the
logic
in
Wesson.
Binding
was
kind
of
backwards
to
begin
with,
so
it
now
just
passes
through
and
there's,
there's
a
difference
between
the
instantiate
branch
and
a
fetch
branch,
and
we
were
like
prioritizing
fetch,
even
though
that's
not
really
the
primary
use
case.
A
And
thence
these
last
three
bullet
points
here,
provide
Punja
and
are
basically
our
reverser
going
on
spree
and
like
this,
isn't
even
all
of
the
requests
that
they
set
but
like
they're,
just
killing
it
lots
of,
like
nice,
real
world,
the
motivated
performance
optimizations
for
the
bindings
and
translation
over
ABI,
yeah,
so
good
stuff.
There
any
updates
on
Westpac's.
Yes,.
D
D
Yet
as
a
couple
fixes,
if
I'm
feeling
incredibly
ambitious
I,
might
try
and
get
that
NPM
dependency
stuff.
It
also
because
of
my
other
tasks,
I
basically
already
implemented
wrapping
cargo
generate,
and
so
I
can
just
drop
that
into
wise
and
pack
and
make
it
better.
So
hopefully
those
two
things
but
yes,
Oda
Eiichiro
release
on
Friday.
Luckily
this
awesome.
A
D
Have
like
a
doc,
see
kind
of
one
sure
which
is
so
I
had
originally
had
this
marketing
PR
on
the
Westpac
repo,
and
we
decided
that
we
wanted
to
move
it
basically
to
the
primary
landing
page
and
I'm
super
down
with
that.
But
my
tolerance
for
working
with
Jekyll
is
low
and
that's
not
to
say
nothing
of
of
Jekyll
as
a
technology
and
where
to
just
do
with
my
own
personal
impatience,
but
there
is
a
marketing
branch
on
wise
impact
where
you
can
snag
all
to
HTML.
D
D
A
A
So
this
is
there's
a
few
steps
to
to
getting
to
this
eventual
end
goal
of,
like
statically,
checked
calls
directly
into
the
C++
that
implements
the
Dom
in
browsers
without
kind
of
bouncing
through
JavaScript,
and
that
that
kind
of
depends
on
on
many
different
proposals
that
are
all
in
flight,
and
one
of
them
is
this
host
bindings
thing
and,
and
so
this
is
actually
renaming.
Host
bindings
to
web
IDL,
bindings
and
yeah
just
go.
Take.
A
D
Alex
has
made
a
PR
to
add
the
wiesen
32
unknown
wozy
target
to
the
Rose
compiler,
which
is
not
a
JavaScript
target
per
se.
It's
it's
it's
own
thing,
but
anyways
the
question
of
targets,
how
we
talk
about
them
and
which
tool
changed
to
find
what
they
are
seems
to
be
an
interesting
one
and,
at
the
very
least,
I
feel
like.
We
should
comment
on
this
issue
with
at
least
what
we've
done
so
far.
A
Interesting
is
also
there's
this
polyfill
for
these
same
api's
for
running
it
in
the
browser
and
that
like
plugs
standard
out
into
console.log
and
stuff,
like
that
great
so
yeah,
so
I
guess,
if
I
were
to
summarize
like
why
we
built
our
own
stuff
with
like
web
impact,
less
biogenics,
because
those
were
solving
the
specific
problems
and
not
the
long-term
thing,
maybe
I'm,
starting
to
just
say
the
same
thing
over
again.
So
just
yields
yield
to
the
floor
now
for
questions
or
discussion
or
something
you.
E
E
A
A
E
One
question
I
sort
of
have
along
lines
is
when
we
talk
about
targets.
Are
those
targets
having
implications
on
what
the
standard
libraries
capabilities
are
like
extensive?
It
seems
to
make
sense
to
have
a
target
because
there's
a
lot
of
standard
library
functions
that
talk
with
like
file
access
and
spawning
stuff,
but
when
it
comes
to
targets
of
like
yes,
six
and
like
web
IDL,
it's
like
there's
no
standard
library
for
those
things
at
all.
A
Yeah
I
think
I
think
so,
like
one
thing
you
could
do,
is
you
could
build
a
file
system
on
top
of
like
indexdb
or
something
right
and
like
if
you
were
to
try
and
make
standard
FS
file
work?
On
top
of
that?
That
would
require
a
rust
target,
as
opposed
to
like
a
plasma,
binder
and
less
impact
argot,
because
that
would
be
like
that.
That's
how
the
standard
library
knows
like
which
implementation
of
standard
FS
file
to
use
essentially
and
what
assumptions
to
make
yeah.
That's
that's
a
good
access
to
kind
of
divide
things
also.
E
A
Kind
of
put
forth
that
for
2019,
the
the
goal
of
the
wasm
CTE
should
be
or
like
one
of
the
top-level
roadmap
items
should
be
like
enabling
host
bindings
or
by
DL
bindings,
essentially
so
I
think,
there's
like
there's
fairly
large
consensus
in
the
community
that
like
this
is
a
thing
we
want.
The
details
I
think
are
nowhere
near
like
this
is
exactly
how
we
want
to
do
it
like
it's.
It's
just
spill
a
rough
design
at
this
point
in
time,
yeah.
A
D
F
D
B
Had
a
good
bit
about,
maybe
it's
a
silly
question,
but
targets
apologies
if
it
is
so
how
granular
are
are
they
expected
to
be
so?
For
example,
technically
I
have
access
to
lots
of
fast
stuff
and
TCP
stuff
in
electron,
but
I
still
use
a
was
a
target
for
it,
but
technically
I
can
I
can
still
should
be
able
to
access
some
of
the
things
that
normally
a
browser
would
not
be
able
to.
Are
we
saying
that
in
the
future,
I
should
be
able
to
have
a
like
electron
base
target
versus
just
a
browser-based
target?
D
A
while
back,
okay
I'm
sorry
I
did
not
see
that
in
it
no
I
mean
but
I
think
this
conversations
kind
of
about
how
we've
talked
about
this,
but
how
we
have
not
like
a
thousand
percent
resolved
it
or
communicated
it
well.
Okay,
so
I
think
it's
still
kind
of
an
open
question,
but
pawan
is
saying
that
the
consensus
massive
question
marks
here
is
that
we'll
use
cargo
features
for
that
and
I
think
that
that
is
something
that
that
people
want
to
do.
I,
don't
know
entirely
how
how
long
that
is,
though,.
B
F
A
Have
multiple
different
kinds
of
targets,
so
it's
good
to
be
specific
about
which
we're
talking
everything
out
rust
targets.
Instead,
targets
versus
wasm
pack
wasn't
benjin
targets
versus
something
else
and
I
think
the
answer
is
like
like
technically
like
we
have
the
ability
to
have
as
fine
a
grain
targets
as
we
want
right.
A
That
just
says,
I
know
that
I
have
access
to
be
certain
api's
and
I'll
define
those
API
is
unless
behind
Jen
and
then
you
can
just
use
my
crate
and
then
that's
like
the
easiest
maintainer
ship,
at
least
for
the
working
group,
because
like
we're
here,
if
it's
not
maintaining
that,
but
so
I
think
one
of
the
the
benefits
that
huazi
is
is
bringing
here.
Is
it
saying
like
here?
Are
these
like
standard
sets
of
capabilities
that
essentially
should
be
implementable?
A
Basically
everywhere,
webassembly
runs
or
like
most
places
and
so
like.
If
you
can
implement
these
y'see
syscalls
with
like
on
top
of
electron,
or
you
know,
on
top
of
your
CloudFlare
thing,
something
like
that's
nice,
because
the
maintenance
burden
for
us
is.
We
just
only
maintain
this
huazi
target,
but
it
takes
your
your
code
and
runs
it
all
over.
All
these
different
places.
A
A
A
A
Right,
so
not
all
api's
or
syscalls.
I
guess
that
this
layer
will
always
make
sense,
and
so
these
things,
so
it's
nice
about
this
thing
in
general
I
see-
is
that
it's
kind
of
capabilities
oriented
the
way
that
the
way
that
Azzam,
you
can
tell
like
what
capabilities
it
requires
by
what
imports
it
wants
right.
It
doesn't
get
any
kind
of
like
you
know
ambient
api's,
so
on
the
web.
It
doesn't
make
sense
to
talk
about
like
raw.
You
know
UDP
or
TCP
right
but
like
and
then
I
mean.
E
A
A
D
A
D
A
Think
it's
more
just
like
a
spam
avoidance
thing
I'm,
not
sure
that
it's
necessary,
but
all
right,
so
so
that
and
then
also
as
far
as
people,
to
talk
to
a
sunfish
on
IRC
that
mozilla.org
in
the
wisdom,
Channel
and
then
probably
just
following
the
relevant
repositories
that
are
all
probably
linked
from
that
hacks
post
in
the
agenda.
There's
like
I
forget
all
of
them.
There's
there's
a
couple
because
there's
one
for
like
the
sis
route,
there's
one
for
like
the
Lipsy.
A
I
expect
like,
as
time
goes
on
like
right
now
it's
been,
it's
been
like
a
few
people
kind
of
collaborating
to
get
something
together
enough
that
it
can
be
announced
and
I
expect
that
things
will
start
to
like.
You
know,
congeal
a
bit
more.
You
know,
as
things
go
on
now
right,
like
meetings
or
whatever.
D
With
that
target
I
imagine,
we
should
probably
maybe
also
have
a
separate
from
these
weekly
meetings
designed
meeting
about
what
do
we
start
doing
in
our
tool
chain
when
we
have
more
than
one
target
like
non
impact.
No
non
was
impacted
by
engine
targets,
but
like
cuz,
that's
that's
gonna,
head
up
at
a
whole
new
layer
of
complexity
to
this
whole
target
shenanigans.
So.
A
A
C
A
It
might
be
worth
we
have
like
an
awesome
page,
which
has
some
degree
of
completion.
I
guess
I,
don't
know
like
we
have
an
awesome
page
with
with
some
projects
listed,
and
maybe
it's
worth
linking
to
that
or
like
going
through
that
and
picking
out
the
most
interesting
bits.
We
also
have
the
crates.
You
should
know
page
in
the
Swazi
book
which
I.
D
A
D
So,
like
the
the
landing
page,
thing
is
already
made
that
we
need
to
move
to.
The
actual
homepage
instead
of
wise
impact
is
the
thing
that
calls
out
our
targets,
but
we
kind
of
have
like
two
units
of
things
like
our
targets
and
then
the
like
ecosystem
of
crates
around
us
and
so
I
think
creating
like
a
visually
engaging
presentation
of
those
things
will
probably
be
good
advertising
for
us,
because
it's
a
really
good
content
that,
even
though
we
do
have
a
page
for
it
and
like
that's
good
I,
still
think.
D
G
There
are
a
lot
of
different
array
data
types
that
could
be
used
and
using
the
J's
constructors
to
get
the
data
out.
There
were
just
a
lot
of
usage
enters,
so
I
feel
like
we
could
improve
that
and
then
another
issue
kind
of
writing
now
is
passing
the
WebSocket
callback
handlers
for
when
the
WebSocket
is
actually
open
like
goes
into
open
status
or
disconnects
or
encounters
in
their
various
callbacks
like
that
or
the
callback
for
when
it
actually
receives
messages.
These
have
to
be
passed
over
to
Jas
lands
currently
and
which
I
do
not
I'm.
G
Expecting
it's
going
to
be
that
way
for
a
while,
but
being
able
to
store
those
callbacks
so
that
they
can
be
appropriately
cleaned
up
when
the
objects
are
dropped
in
rust,
we
don't
have
a
clean
way
of
doing
that
right
now,
there's
no
like
recommended
way
of
doing
this.
Maybe
you
can
start
in
RC,
but
basically
one
of
the
things
that
we
could
do
that
I
was
proposing
in
this
issue
is
that
the
new
type
will
wrap
the
underlying
web
sis
socket
and
then
all
of
the
callbacks
will
basically
be
stored
in
this
higher-level
typing.
G
So
I
just
wanted
to
bring
it
up
here.
I'm
planning
on
putting
together
an
implementation,
but
I
wanted
to
ask
like
actually
Nick
everybody
else.
What
do
you
guys
think
about
it?
Is
this
something
we
should
die
or
tiser
right
now,
but
then
also
just
reading
through
the
you
know
the
contributing
documentation
in
the
repo?
Do
you
guys
have
a
recommended
way
for
building
this?
Maybe
a
new
sub
crate
within
blue.
A
So
the
the
way
we've
been
doing
it
is
that
I
think
this
would
be
a
new
crate
within
glue
and
then,
ideally,
there
would
be
like
kind
of
like
the
base
kind
of
callbacks
layer
and
then
kind
of
futures
or
streams
based
layer.
On
top
of
that,
and
maybe
there's
also
been
talk
about
implementing
Tokyo's
async,
read
and
async
write
for
these
things.
A
Maybe
just
exposing
those
directly
at
like
kind
of
like
the
the
mid-level
callback
layer
would
be
appropriate
and
then
like
building
things.
That
kind
of
contain
all
that
for
you
and
expose
futures.
On
top
of
that.
But
I
think
the
event.
Listeners
kind
of
API
that
the
Palin's
been
working
on
is
exactly
that,
like
managing
the
callbacks
and
everything
and
automatically
removing
the
Dom
listener
and
everything.
G
Okay,
yeah,
that's
that's
great
feedback
and
I,
see
Wow
on
just
mention
some
stuff
in
the
chatroom.
I'll,
take
a
look
at
the
the
events
or
requests,
and
maybe
the
the
correct
way
of
doing
this
or
the
way
that's
going
to
work
well
with
the
ecosystem
is
to
basically
expose,
like
you
just
said,
Nick
the
events
on
this
new
web
socket
type
so
that
it
uses
the
glue
event
system
and
kind
of
reports
along
those
lines.
G
A
I
think
I
need
to
go
over
the
the
issue
again,
but
I
think
what's
been
really
helpful.
For
me
when
I've
been
looking
over
like
API,
proposals
and
designs
is
having
just
like
the
function,
signatures
and
the
types
with
an
actual
implementation,
but
just
that
I
can
guess
how
they're
expected
to
work
together,
and
that
gives
me
something
a
lot
more
concrete
to
to
kind
of
work
with
and
massage
and
make
sure
we
can
get
the
best
thing
possible
and.
D
That's
I
was
actually
gonna
chime
in
at
the
end
and
just
be
like
an
example
and
like
an
example,
is
really
close
to
the
function.
Signatures
I
think
that
works.
Maybe
we
should
update
our
issue
templates
to
just
include
that
to
give
people
a
little
bit
more
direction
on
building
that
out,
so
I
think
that
it
not
only
would
help
me
sounds
like
it
would
help
you
but
I.
Imagine
it
would
help
other
people
better
evaluate
if
they
think
it's
like
improving
or
gonna
mix
or
not,
which
is
obviously
one
of
your
major
goals.
Here.