►
Description
We are aware of audio issues in Vincents talk and are working on providing subtitles as a replacement.
Arvid E. Picciani (https://github.com/aep)
Application container deployment for the Internet of Things with Rust
Solving containerization on very constrained devices will enable a new way we deliver system updates to embedded systems. We'll learn about one possible approach with korhal's bolter and how it ties into the interplanetary hash router to deliver content addressable system updates to microcontrollers anywhere, without a cloud.
Arvid is a controversial break-the-whole-box-thinker getting hired to put Linux on stuff where Linux would prefer to not be with deadlines you'd prefer to not have. He's currently CTO of superscale networks and Founder of korhal.io, an organization dedicated to liberating IoT and preventing consumer lock-in.
Vincent Esche (https://github.com/regexident)
rspec and what it takes to make a BDD test framework in stable Rust
While the existence of native language-level support for unit testing in Rust is a blessing, classical JUnit-style unit testing can feel a bit antiquated at times. You. Just. Keep. Repeating. Yourself. This is where BDD frameworks come in with their shared scopes and user-friendly matchers. Rspec's aim is to provide the BDD testing experience to Rust without the need to bend over backwards or drink the nightly kool-aid. Tests should be just as stable as the rest of your code, if not more. After all who tests your tests if those break?
A mobile dev lead writing Swift at an emerging fitness/health and IoT startup in Berlin by day, and Rustacean by night, Vincent authored cargo modules and rustfmt's comprehensive configuration guide and is currently working on a modern and extensible Support Vector Machine implementation in Rust.
A
Alright,
let's
just
start
hello,
everyone
thanks
for
being
here.
This
is
the
rust
Berlin
meetup,
the
second
one
in
this
wonderful
new
office,
I'm,
really
glad
that
you're
all
here
we
have
two
Talk's
today.
The
first
is
a
bead
who
talks
about
application
content,
container
deployment
for
the
Internet
of
Things
with
rust,
which
is
really
exciting.
Then
we
have
a
five
minutes
break
and
then
Vincent
will
talk
about
our
step
back
and
what
it
takes
to
make
a
bdd
test
framework
in
rust,
which
is
also
really
exciting.
A
If
you
want
to
do
a
talk,
please
reach
out
to
me
via
personal
communication,
or
you
know,
email
or
message
on
meetup
or
in
any
way
you
like,
if
you're,
not
sure,
if
it's
good,
we
can,
we
can
talk
about
it
and
we
can
like
work
something
out,
I'm
sure.
It's
good,
there's,
also
the
rust
tech
and
learn,
which
is
our
co
learning
group,
which
is
kind
of
in
cooperation
with
open
tech,
school
and
I,
can
totally
recommend
you
to
go
there.
A
It's
every
second
Wednesday,
so
it
would
be
today
but
we're
having
the
rust
meetup.
So
that's
why
it's
not
today.
So
that
it
means
it's
next
in
two
weeks
from
now
in
this
office
in
the
community
space
at
7
p.m.
so
feel
free
to
come
there,
and
it's
like
a
open
hacking
learning
session,
where
you
can
just
work
on
rust,
stuff
and
get
stuff
explained
from
other
people
or
explain
stuff
to
other
people.
A
Last
but
not
least,
we
have
a
code
of
conduct
and
we're
ready
to
enforce
it.
So
if
you
notice
anything,
if
somebody
isn't
treating
you
as
they
should
please
reach
out
to
me
or
reach
out
to
Valerie,
who
is
our
security
person
now
I
can
get
you
in
touch.
If
you
would
like
to
talk
to
a
woman
and
we
will
handle
it
and
yeah
that's
about
it.
Thank
you.
C
B
C
B
Works
cool,
so
hey
welcome
everyone.
Thank
you
for
coming:
I'm,
Arvid,
I'm,
the
CTO
of
superscalar
networks
and
also
founder
of
Korhal
I'm
gonna.
Today
talk
about
Kohala
the
project
dedicated
to
liberating
the
Internet
of
Things
I'm,
going
to
introduce
our
con
and
vulture
today,
two
of
our
projects
that
we
that
were
working
on
closer
this,
which
are
just
working
last
week.
So
if
the
demo
also
broken,
please
bear
with
me,
you
know
that
that's
the
usual
thing
people
say!
Then
they
break
but
I
tested
them.
Two
more
air
today,
so
cool.
B
B
There
is
something
specific
I
mean
by
that,
and
so
it's
important
to
get
the
perspective
of
that
there.
It's
certainly
interesting
to
get
deployments
working
or
applications
to
deployments
when
system
deployments
working
on
small
computers.
But
that's
not
what
I'm
gonna
talk
to
about
today
about
today,
I'm
gonna
talk
about
much
smaller
and
cheaper
devices,
specifically
things
like
edge
gateways
or
gateway
devices.
I
call
them
embedded
also
things
like
small
computer
and
consumer
devices,
like
the
Amazon
echo.
B
If
you
have
one,
those
are
little
devices
that
I
put
in
the
middle
and
then
we
have
constrained
devices
on
the
on
the
far
right
of
the
picture,
which
are
something
like
the
sensor
nodes
things
like
that
they
don't
even
run
Linux.
So
it's
important
to
understand
that
this
is.
This
is
IOT.
When
I
talk
about
that,
it's
it's
not
about
raspberry
PI's.
B
Let's
do
a
test
so
so
to
see
it
a
test
to
see
if
everyone's
awake
not
just
kidding.
Let's
do
a
test
raise
your
hands.
You
know
that
wpa2,
the
Wi-Fi
encryption
is
broken.
That's
a
lot
of
educated
people,
I'm,
really
glad
I.
Don't
have
to
explain
that
now
we
do
something
more
harder
raise
your
hands.
If
all
of
your
devices
in
your
home,
including
your
router,
your
phone,
your
toaster,
your
lightbulbs
are
updated.
B
That's
absolutely!
No
one!
Let's
face
it.
We
have
an
update
problem
in
IOT
and
it's
dramatic,
so
what
I
mean
by
dramatic
is
take
the
Mirai
botnet,
which
is
which
took
down
a
million
telecom
bruders
in
2016
and
almost
broke
the
internet.
It
took
down
github,
it
runs
on
I,
think
IP,
cameras
yeah,
something
like
that,
and
these
IT
primers
don't
get
any
updates
anymore
and
I'm.
B
Not
even
going
to
talk
about
things
like
I
mean
it's
just
IP
cameras
you
could
think
right,
but
we
also
have
other
IT
device
which
are
much
more
critical
things
like
nuclear
power
plans,
but
we're
not
going
to
talk
about
that
today
because,
as
we
say
in
Germany
untie
design
for
video
before
conference,
each
other
I'm
going
to
leave
you
with
that.
So
now
let
me
try
to
explain
what
I'm
a
part
of
what
I'm
doing
with
quarrel.
B
It
is
essentially
a
solution
to
some
of
the
problems
that
have
been
seen:
the
last
15
years,
working
on
embedded
devices,
we're
embedded
Internet
connected
devices.
Specifically,
if
you
work
in
embedded
devices,
you
know
that
our
tool
chains
are
terribly
broken.
You
were
to
look
within
yet
web
developers.
We've
got
things
like
docker
we've
got
things
like
radar,
DES
and
great
languages,
I
mean
not
that
javascript
is
great,
but
you
know
other
languages
specifically
engineered
for
web
developers,
which
are
which
are
great.
B
There's
a
vast
echo
system
out
there
with
embedded
devices
we're
pretty
much
stuck
with
printf
C
debugging
and
a
screwdriver
if
you're
lucky.
So
it's
not
great
until
rust
came
along.
Rust
really
gave
me
hope
that
someone
is
designing
an
ecosystem,
that's
actually
going
to
work
on
automatic
and
constraint
systems
and
what
I'm
gonna?
What
I'm
going
to
present
now
is
my
part
in
that
ecosystem
and
in
the
hope
that
someday
we're
gonna
have
tools
in
in
embedded
that
are
actually
equal
in
quality
to
what
we
have
in
embedding
in
web
development.
B
I'm
gonna
keep
this
brother
short
today,
there's
a
whole
bunch
of
things
we
do
with
Korhal,
but
I'm
going
to
talk
about
arcane
and
bolter,
which
are
fairly
interesting
things
and,
as
I
said,
they
work,
unlike
what
we're
planning,
for
example,
with
the
Crypt
incentivized
edge
network,
which
doesn't
work
yet
so
I'm
not
going
to
talk
about
that.
Yet
specifically,
Archon
is,
in
its
use
case
very
similar
to
to
docker.
B
It
allows
you
to
to
just
to
just
store
a
bunch
of
files
in
an
image,
and
you
can
deploy
that
image
as
a
single
file.
Unlike
docker,
it
thought
it
doesn't
use
layers
docker
uses
layers.
What
we
do
is
we
use
a
content.
Addressable,
storage,
okay,
I'm,
gonna,
explain
what
that
is.
A
content
in
the
rest
of
the
storage
is
very
similar
to
what
you
think.
B
Dropbox
will
hopefully
do
or
similar
service
instead
of
indexing
data,
like
your
filesystem
does,
by
name
it
indexes
it
by
a
content
or
by
the
address
of
the
content
supplied
by
its
hash.
So
imagine
you
and
me
both
of
a
music
library
on
Dropbox
or
a
similar
storage
service,
we're
both
kind
of
storing
heavy
mp3
there
in
in
my
picture
and
now
what
what
you
think
is
heavy
and
what
I
think
is
heavy.
It
might
be
different.
B
I
think
your
music
is
rather
lame,
so
they're
gonna
be
different,
although
we
both
call
them
heavy
right,
but
we
can
kind
of
both
agree.
Then
Taylor
Swift
is
cool,
so
we
both
store.
The
same
file
and
Dropbox
or
similar
service
can
figure
out
that
there
is
the
same
file
based
on
their
content
and
can
store
only
one
of
those,
so
in
those
picture
of
four
files,
but
Dropbox
is
only
going
to
store
three
and
give
us
both
a
reference
to
one
of
these
fights.
This
is
country
content
or
estimate
storage.
It's
not
new.
B
Some
of
you
will
probably
know
what
it
is.
Just
explaining
your
context,
leading
me
to
update
safety
on
embedded
update
safety
means
that
if
we
screw
up
anything
on
a
device
during
update
and
I've
screwed
up
things,
we
need
to
be
able
to
undo
this
because
user
interaction
with
devices
with
embedded
devices
they're
out
there
with
IOT
devices
is
really
expensive.
If
you
think
of
sending
one
fridge
might
be
okay,
but
sending
like
a
millions
of
fridges,
it's
going
to
be
bankrupt.
Company.
B
Typically,
what
we
do
is
called
dual
systems,
so
we
just
put
two
versions
of
the
same
system
on
it
and
if
one
has
a
back
or
something
we
just
boot,
the
other
one
and
sometimes
what
people
do
is
called
a
fat
bootloader
to
just
put
the
update
capabilities
inside
the
boot
order,
so
that
you
have
a
way
if
your
system
breaks
your
bootloader
can
still
update
your
system.
That
means
you're
putting
the
updater
in
the
region
of
the
memory
that
isn't
updated.
You
can
get
yourself
why
that
a
bad
idea?
B
This
is
actually
what
Android
does
it's
really
really
complicated?
What
I'm
proposing
to
do,
if
is
doing,
updates
with
content
or
storage?
This
is
again
not
new.
We've
tried
this
before
it
didn't
work.
I'll
tell
you
why?
What
you
do
there
is
you
take
both
systems,
both
versions
of
the
system's
like
we
did
before,
but
instead
of
storing
them
separately
as
full
systems,
we
just
store
the
part
that
changed
you
see
when
we
do
system
updates
on
embedded.
We
do
really
big
changes.
B
Sometimes
we
just
do
a
little
bit
of
tweaking
and
then
we
do
store
the
whole
thing.
That's
really
inefficient.
It's
also
Network
inefficient.
We
do
know
how
to
share
code.
I
mean
we
do
how
to
know
how
to
make
multi
call
binaries.
This
is
something
we
do
for
any
something
with
busybox
on
embedded,
it's
kind
of
like
your
shell,
toolkit
and
stuff,
like
that,
just
in
one
binary
now,
that's
that
we
know
we'll
also
learn
how
considerable
storage
can
be
done.
B
We
do
this
with
our
con
and
now
what
we
don't
know
so
far
is
how
to
do
it
with
executables,
and
this
is
the
reason.
No
one
does
this
yet
because
executables
are
not
like
a
linear
story
of
like
a
poem
or
something
like
that.
Executables
are
mostly
just
addresses,
so
they
jump
to
each
other
and
continuously
jump
to
other
memory
regions.
If
you
change
the
tiny
part
of
it
all
of
these
addresses
change,
and
this
is
why
you
can't
do
it
with
controversial
storage,
because
and
because
these
won't
match
with
another
executable.
B
The
address
is
going
to
be
completely
different,
even
if
it
just
changed
how
the
world
into
hello
something
right
now.
What
we
do
with
bolter
bolter
is
a
completely
new
elf
linker
that
replaces
kin
uld,
it's
completely
written
in
rust,
and
it's
completely
written
from
scratch.
There
is
no
new
code
in
there.
Nothing
like
that.
B
There's
no
license
infection,
it's
all
MIT,
all
open-source,
open
and
github,
and
what
we
do
with
that
is
we
link
executables
in
a
way
that
they're
globally
the
same,
which
means
that,
if
you
link
to
executables,
both
of
which
contain
the
same
static
library
like
a
lip
see
or
a
lip
OpenSSL,
or
something
like
that,
no
matter
where
you
link
it
on
earth
or
in
space
they're
the
same
that
allows
us
to
deduplicate
most
of
that
code.
That
is
shared
very
similar
to
a
music
example.
B
We
had
this
problem
that,
if
you,
if
you
deploy
shared
code
on
a
system,
that
the
code
that
gets
executed
at
runtime
on
the
user's
machine,
might
not
be
the
one
that
you're
expecting
at
linked
time,
because
the
user
might
have
updated
different
application.
That
also
need
a
library,
but
a
new
version
and
your
application
code
might
be
completely
incompatible
with
that
new
version.
You
don't
have
any
guarantees
in
shared
libraries
with
bolter.
We
have
this
guarantee
because
we're
linking
by
content
we're
not
linking
by
name.
B
So
when
you
link
a
Lib
C,
it
is
linked
by
its
hash
and
that
hash
is
the
content
as
well
as
put
into
the
binary.
So
if
you
have
two
different
applications
using
incompatible,
libraries
they're
just
going
to
be
not
deduplicated
they're,
both
gonna
have
the
original
C.
In
there,
but
with
the
the
reason
that
they're
actually
actually
expect-
and
we
either
going
to
store
just
one
of
the
Lipsey's
or
both
of
them,
and
we
can
also
later
decide
to
change
that
automatically,
of
course
based
on
based
on
the
hash
of
the
content.
B
I
got
to
say
with
that.
Actually
we
have
the
this,
not
in
production.
We
have
a
work
at
super
scale
networks
as
a
CTO,
and
we
have
there's
8,000
devices
out
there
with
a
complete
rest
stack,
but
we
didn't
they're
deploying
this
yet
so
since
I
just
got
it
working
last
week,
we're
not
that
crazy,
I
hope,
okay,
cool,
so
I
prepared
a
little
test
here.
This
is
this
is
just
to
test
files.
Really.
This
is
hello
world
in
C.
B
Now
this
looks
very
simple
and
to
some
of
you
know,
C,
probably
all
of
you
and
this
just
hello
world,
but
in
terms
of
what
it
links
into
Lib
C
is
actually
pretty
crazy.
You're
gonna
see
that
in
a
second
and
Mona's,
not
library
and
we've
got
hello
to
see,
which
is
which
is
almost
the
same
thing.
It's
just
going
to
print
the
local
you
name,
which
is
the
name
of
the
operating
system
whirring.
B
This
is
hello
to
the
LOD
binary
link
with
can
ult
and
that's
a
trick
here
could
show
you
to
make
file,
but
it's
not
that
interesting,
and
so,
if
you
could
expect
these
binaries
to
be
very
similar,
and
if
we
looked
at
it
from
a
considerable
storage
perspective,
they're
not
gonna,
be
so
I'm.
Gonna
use
our
cone
here
and
I'm
gonna
store
actually
need
to
make
sure
that
my
test
thing
is
removed
or
actually
it
just
in
a
sec.
I'll
just
use
a
different
different
storage
oops.
B
I'm,
just
gonna
store
these
both
into
a
contour
decibel
storage,
and
this
one
was
seventeen
kilobytes,
because
it
includes
the
Dipsy
boosted
static,
linking
and
I'm
going
to
store
the
other
one
and
it's
gonna
try
to
deduplicate
it
based
on
something
that
our
sync
uses
as
well,
which
is
the
bop
algorithm.
Sbo
piece
is
from
our
so,
and
it
basically
tries
to
go
through
a
binary
and
try
to
find
cutting
points
that
it
can
use
based
on
its
content.
B
It's
basically
also
the
CI
sink
uses
or
any
contra
does
of
a
storage
really
they're,
all
very
similar.
So
we've
seen
that
what
we
see
here
is
that
we
we've
stored
17
kilo
bytes
on.
Actually,
let
me
do
this
in
the
other
screen.
Ok
reach
my
mouse
over
there
we
stored
this
is
so
much
intimate
delight,
I'm
not
gonna,
be
able
to
do
it.
We
stored
17
kilobytes
with
one
binary
and
the
other
binary.
We
still
have
to
store
15
kilobytes,
so
we'll
only
be
able
to
share
a
minor
part
of
it
between
those
binaries.
B
This
is
because
all
the
addresses
have
changed
now,
if
you
do
this
with
bolter,
if
you
just
build
a
binary
link
with
bolter,
if
you
just
do
this
with
just
gonna
make
up
around
them
in
here,
I'm
gonna
store
hello,
one
and
also
18.4
for
kilobytes.
You
notice
that
this
is
slightly
bigger
than
the
you
know,
LD
of
by
library,
there's
a
reason
for
that
which
I'm
gonna
explain
a
sec
having
a
store
or
hello
to
you're,
going
to
see
that
this
is
significantly
better
we're
only
storing
five
kilobytes.
B
These
are
these
are
basically,
this
is
what's
going
to
enable
you
to
do
partial
system
updates
and
it
completely
safe,
Y
by
deduplicating
most
of
your
application
code
that
is
shared
between
two
different
binaries.
Now.
The
reason
that
the
Bolton
link
fire
is
slightly
bigger
is
because
we
first
of
all
I
just
got
the
linker
working
last
week.
B
So
there's
a
lot
of
optimization
missing,
but
there's
also
an
index
into
the
content
inside
which
are
can
uses
for
for
cutting
points
like
it's
going
to
know
exactly
which
contents
in
there
so
I
can
compare
it
to
any
other
thing.
It
has
already
in
the
store-
and
this
is
something
you
would
do
in
an
embedded
device,
for
example
from
the
outside.
You
would
say:
push
this
device
push
this
image
on
there
with
that's,
really,
not
cool,
okay
and
really
glad
this
didn't
show
them
in
yellow
screen.
B
B
B
Now,
where
I'm
going
with
core
Hall
is
I'm
trying
to
change
the
Internet
itself,
the
Internet
of
Things
itself
from
an
engineering
perspective,
we
need
much
better
tools
to
deal
with
things
like
end
of
life.
Clouds,
service
disruption,
monopolize
data
infrastructure
and
coronal
is
larger
project
I'm
trying
to
set
up.
B
So,
if
you're,
if
you're
interested
in
Internet
of
Things
infrastructure,
specifically
decentralized
Internet
infrastructure
that
doesn't
need
a
cloud
I'm
gonna
talk
about
that
in
another
talk,
give
a
shout
out
to
me
after
the
talk
or
stalk
me
and
github
or
stalk
any
of
my
project
members
on
github
and
help
me
fix
IOT.
Thank
you.
I.
B
B
You
also
don't
need
a
specialized
bootloader,
actually
because
everything's
inside
the
binary
that
also
allows
you
to
do
something
that
I
find
really
important,
which
is
reproducibility.
So
if
you,
if
you
put
this
on
one
device
and
you
and
it
works,
you
know
test
device.
You
can
be
sure
that
it
also
works
on
another
device,
because
the
images
are
going
to
be.
The
same
great
question,
though,.
C
B
That
that's
going
a
bit
further
than
than
what
I
would
have
set
here.
This
is
this
is
not
well
thought
out,
I
got
to
say
so.
I
don't
have
a
direct
answer
because
I'm
not
sure
where
you're
going
with
this,
especially
because
this
is
in
the
direction
of
the
decentralized
network
that
I
haven't
talked
about
yet,
but
you
right,
it
has
a
risk
of
fraud,
and
this
is
why
there's
a
crypto
element
to
it
that
did
tries
to
prevent
fraud.
B
B
The
initialization
order
is
is
deterministic
in
a
sense
of
if
you
have
the
same
input,
you're
always
going
to
get
the
same
result.
It's
not
hidden
mystic
in
a
sense
of
you
feeling
something
else.
That's
correct!
Yeah!
If
you
link
something
else
in
the
the
orders.
Gonna
change,
that's
correct,
but
it's
not
gonna
change
in
the
sense
of
that.
If,
if
you
have
the
same
application,
no
matter
what
underlying
code
you
share,
it's
still
going
to
be
the
same
initialization
order
because
that's
not
part
of
the
runtime
at
runtime.
B
B
E
B
A
great
question
this
is
this
is
address
page
one
address
space
randomization.
This
is
to
prevent
break-ins
when
you're
already
found
a
buffer,
overflow
and
application
that
you
can't
just
run
jump
to
a
known
address
where
you
can
execute
code,
and
this
is
enabled
by
default
in
Linux
and
the
the
demo
that
you
just
saw
those
are
with
address
space
randomization.
The
way
we
do
it
is
the
the
global
address
space.
You
see,
it's
shifted
by
the
load
base,
so
it
run
at
what
happens
at
run.
Time.
B
Is
the
Linux
loads
this
at
a
specific
address
that
it
just
randomly
thinks
up,
and
we
just
lay
out
the
entire
address
space
after
that
relative
to
that
base
address.
This
is
how
it
works.
It's
it's
a
bit
fancy.
It
could
show
you
the
internal
details,
but
it
does
not
conflict
with
with
random
with
randomization.
Okay.
Thank
you
great
question.
A
G
G
G
Yeah
and
then
you
can
further
nest
those
and
have
arbitrarily
deep
nested
tests
there,
and
the
interesting
part
is
that
these
ones
share
the
same
set
up
right.
You,
don't
you
don't
repeat
yourself
over
and
over
again,
and
they
can
also
like
fork.
If
you
are
right,
so
they
could
diverge
here
and
here
as
well,
but
still
share
the
same
origin
up
here,
and
if
you
express
this
in
some
kind
of
hierarchy,
then
this
stuff
on
the
right
would
look
like
this
diagram.
G
G
This
subtree
and
if
you
look
in
the
rust
ecosystem
for
BDD
frameworks,
then
they're,
basically
three,
that
I
found
that
are
usable,
another
iPhone
usual
there's
shiny,
which
has
a
very
nice
syntax
by
using,
by
basically
being
a
compiler
flag,
plug-in
and
using
macros
to
be
able
to
have
a
very
nice
DSL
to
define
those
those
cases.
The
big
downside
of
shiny
is
that
it's
single
level,
so
you
have
you
can
kind
of
define
multiple
bags
but
they're
still
bags.
G
It's
not
a
hierarchy
for
any
kind,
and
you
can
define
those
before
each
before
each
snippets,
which
then
basically
like
what
Johnny
does.
Is
it
compiles
down
and
it's
basically
some
kind
of
templating
language?
If
you
will
so
what
it
does.
Is
it's
instantly?
It's
that
instantly
its
initial
individual
test
functions,
which
then
are
recognized
for
the
test,
Runner
and
rest
natively,
and
simply
like
copy
and
pastes
those
before
each
blocks
into
those
test
functions.
G
So
you
get
like
you're
repeating
yourself,
but
like
the
compiled
repeating
for
yourself,
you
don't
have
to
do
it
manually,
but
still
is
repeated
all
over
again
and
also
obviously
also
has
to
be
executed.
All
over
again
next
one,
this
famous,
which
is
kind
of
similar,
also
in
syntax,
is
bit
more
sophisticated.
It
also
has
these
after
each
companions,
which
are
like
behave
similar
to
before
each
just
that
are
executed
afterwards.
G
The
big
problem
here
is
that
again
this
is
templating,
so
you
cannot
like
define
the
behavior
up
here
and
then
further
use
whatever
is
like
whatever
you
reached
at
this
point
of
the
current
state
and
further
specify
behavior
like
add
something
to
a
set
then
further
at
other
options.
Other
elements
to
the
set
and
stuff
like
this
is
the
only
thing
you
get
is
adding
some
structure
to
your
tests,
but
it's
just
in
the
structure,
not
in
the
behavior,
so
we're
not
quite
there
yet.
G
If
you
compare
to
what
this
gherkin
language
should
actually
allow
you
to
do,
and
also
in
the
expressiveness.
So
this
is
how
this
would
look
in
r-spec.
It's
a
bit
more
noisy
because
we
don't
have
the
the
benefit
of
a
DSL,
because
we
want
to
be
stable
at
some
point.
I
would
like
to
add
a
DSL,
but
it's
right
now
likely
the
stable
part
at
least
has
to
be
like
this.
G
So,
instead
of
inferring
some
some
implicit
context,
we
actually
have
to
always
like
pass
the
context
to
the
further
down
contexts
to
then
further
append
them.
So
we
add
an
it
Clause,
one
after
and
after
block
to
the
current
context
and
then
in
every
further
nested
context.
The
context
actually
is
the
sub
context.
That's
initiated
here,
and
one
interesting
part
is
in
the
top
like
this
is
a
convenience
runner.
You
can
further
specify
how
you
want
to
run
this
stuff.
G
So
only
stuff
within
the
environment
is
actually
accessible
in
here,
which
is,
it
is
a
feature,
but
it's
kind
of
tedious
on
some
points
so
and
you
only
get
access
to
the
environment
in
certain
places,
so
you
get
access
in
those
beforeeach,
in
which
case
the
environment
that's
being
passed
into.
The
closure
is
moodily
burrowed
same
for
the
after
and
in
signed
it
you
get
the
immutable
environment
within
these
like
within
here,
you
actually
don't
have
any
access
to
it
and
it.
G
This
completely
issue
ensures
that
you're
not
like
messing
with
the
data
at
places
and
times
when
you
shouldn't
be
messing
with
the
data,
because
one
of
the
goals
of
us
of
this
project
is
to
not
only
be
efficient
in
execution
but
also
safe.
You
shouldn't
have
to
worry
about
worry
about
how
your
code
is
executed.
You
should
only
worry
about
the
stuff
like
within
these
blocks,
not
like
what's
going
on
behind
the
scenes,
so
we
are
stable
and
principle.
We
have
arbitrarily
deeply
nested
tests
and
contexts.
It
is
fully
paralyzed
in
its
execution.
G
It
had
been
written,
the
the
first
version
had
been
written
by
by
Thomas
and
then
in
a
shamefully
large
PR,
which
had
like
two
hundred
twenty
seven
comments
and
usually
reviewed
and
I
basically
changed.
All
the
things
like
the
name
is
to
say
the
names,
the
same
and
kind
of
the
API
state
kind
of
the
same,
but
they,
the
all
underpinning,
is
pretty
much
completely
ripped
out
and
replaced.
G
G
My
favorite
is
the
given
one
then,
but
you
also
can
use
any
of
these
to
other
and
you
actually,
you
could
completely
change
them.
They're,
just
aliases
to
like
those
right,
one
to
right,
bones
or
I
use
for
the
first
ones,
and
this
would
then
either
look
like
this
in
variant
a
where
you
have
food
context,
an
example
to
to
open
those
specific
contexts
describe
specified
it
or
given
when
done.
G
But
if
you
have
some
shared
database
where
you
want
to,
for
whatever
reason,
have
one
single
shared
one,
that's
that's
be
hidden
behind
UNIX,
then
these
would
actually
differ,
but
mostly
those
won't
suffice
and
again
what
what
we
do
basically
is
by
executing
by
executing
like
these
these
pieces
of
code,
you
then
generate
a
data
structure
that
looks
like
this
or
you
have
the
suit
at
the
suite
at
the
top
and
then
those
contexts
and
further
examples
on
the
at
the
bottom.
And
then
we
have
a
test
runner
that
executed
this.
G
So
every
one
of
these
nodes
in
the
tree
has
a
header
attached
to
it,
which
then
contains
the
name
that
we
gave
them
in
a
string
and
also
the
label,
and
the
label
depends
on
the
on
the
type
of
your
structure
and,
as
you
can
see,
this
is
the
only
place
where
it
actually
matters
which
of
these
cells.
You
choose
they're
completely
interchangeable.
G
The
context
then
has
an
optional
header,
because
the
route
had
the
route
context
is
enormous
and
there's
also
an
option
for
having
anonymous
context
which
allow
you
to
to
further
specify,
before
and
after
blocks,
without
polluting
the
output.
And
then
you
store
each
of
these
execution
blocks
and
also
further
sub
structures,
which
can
be
a
block
which
is
either
a
context.
On
example,
in
case
of
an
example,
is
again
the
header
and
then
also
the
function.
G
Basically,
you
go
from
here
to
here
and
like
every
time
you
enter
one
of
these,
you
get
a
modification
to
do
your
observers
that
you
just
entered
some
scope
or
left
some
scope.
If
you
enter
it,
you
just
get
the
header.
If
you
exit
it,
you
get
the
header
plus
the
report,
so
that
you
can
then
like
implement
loggers,
for
example.
G
G
And
something
else
which
just
look
my
mind
was
not
so
important
and
then
also
because
this
is
kind
of
tedious
to
do
this
before
every
single
like
scenario.
There
also
is
this
convenience
function,
which
just
does
it
for
you
and
then
there's
this
trait,
which
you
can
implement
implement
yourself
by
default.
We
just
provide
a
simple
logger
which
does
call
console
logging.
If
you
wanted
some
some
structure
login
using
JSON
or
whatever.
You
could
easily
implement
this
yourself,
and
here
you
can
see.
G
The
nice
feature
is:
whenever
something
fails,
you
get
the
full
path
of
those
failures
and,
for
example,
if
two
of
those
failed
at
this
yeah
at
this
hierarchy,
then
this
one
would
be
shared.
So
you
would
have
those
listed
together
here.
It's
not
like
you
get
all
the
stuff
again.
Don't
repeat
yourself
is
the
principle
of
this
framework,
and
then
you
also
get
like
test
execution
durations
which
are
kind
of
like
initially
I
thought.
G
So
right
now
we're
only
showing
the
total
duration,
but
if
someone
has
a
good
idea,
how
to
do
this
more
intelligently,
to
also
give
you
with
some
reasonable
semantics,
like
individual
long-running
tests.
So
if
there
were
some
outliners
outliers,
so
you
could
like
have
us
have
a
further
part
where
you
just
have
like
long-running
tests.
They
would
be
nice
and
then
just
like
you
used
to
you
from
from
rust
itself.
You
get
this.
This
very
short
statistic.
G
Does
this
execution
to
figure
out?
What's
the
result
of
the
test
run,
so
it
basically
does
it
goes
through
its
own
sub
blocks
iterates
over
them,
then
maps
the
block
to
its
evaluation,
which
is
which
is
a
result
passing
at
the
current
context
in
its
environment
and
then
simply
collects
those
into
into
a
vector
of
reports.
G
That's
the
serial
execution,
then,
at
some
point,
I
decided
well
I
mean
given
that
most
of
this
stuff
or
all
of
the
structure
is
immutable.
Why
not
just
try
to
make
it
parallel?
So
I
did
that's
all
it
took
adding
four
four
characters
thanks
to
Ryan,
and
now
you
have
like
fearless
concurrency
right
because
basically
like
you're
running
over
this
and
creating
a
different
structure,
you're,
not
changing
anything
other
than
the
environment,
but
the
environment,
every
time
there's
a
fork
here,
you
clone
the
environment,
so
the
environment
has
to
be
horrible.
G
Obviously
you
clone
the
environment
and
then
pass
those
further
down.
But
this
way
you
have
a
very
low
memory
usage
and
also
again,
you
don't
have
like
any
calculation
is
only
done
once
instead
of
n
times
like
you
would
do
in
shiny
and
stainless
so
fully
concurrent
and
fully
safe,
because
thanks
to
rust,
we
know
that
there's
no
context
can
interfere
with
any
other
context
and
see
some
ref
sell
magic.
Whatever
menu
I
mean
that's
up
to
you.
G
G
This
part,
when
you're
entering
the
example
plus
this,
and
then
you
print
the
okay
when
you
accidental
different
contexts
at
the
same
time,
potentially
so
yeah
you
get
kind
of
like
it,
not
not
joke
here
and
the
way
we
solve
this
the
way
I
solve
this
is
by
having
an
internal
non-exposed
serial
logger,
which
then
is
wrapped
by
a
public
logger
which
reads
out
the
configuration
and
whether
it's
parallel
and
if
it
is
parallel
and
pretty
much
every
of
those
functions
from
the
runner
observer,
simply
nope.
They
don't
do
anything.
G
G
So
the
roadmap
right
now
is
I'm.
I
implemented
some
very,
very
basic
timing,
so
you
can
just
get
the
total
time,
so
you
at
least
know
how
long
you
take
your
tests
took
to
run,
but
for
the
parallel
execution
you
don't
get
any
progress
right,
because
we
do
this,
let's
just
ignore
any
result,
but
the
last
one
and
then
we
play
so.
G
And
then,
even
though
the
tests
execution
itself
is
asynchronous
that
tests
themselves
right
now
are
synchronous.
So
I
would
like
to
be
able
to
also
support
asynchronous
tests,
but
I
mean
I
think
this
would
be
better
suited
for
for
an
external
crate
using
async
measures
so
that
you
could
use
it
with
like
standard
rust
tests
or
somewhere
else
and
then
maybe
implement
a
DSL
like
you
will
you
saw
for
for
shiny
and
and
and
stainless,
but
which
then
would
still
have
the
same
semantics
as
the
stuff
here,
I'm,
not
sure
how
feasible
this
is.
G
G
Yeah,
and
if
you
want
to
contribute,
then
please
please
please
do
there-
is
there's
instructions
on
how
to
contribute
that?
Basically,
it's
just
the
the
common
common
way
of
contributing
and
Russ
project,
and
there
also
is
a
tracking
issue
for
all
the
currently
open,
open
things
which
I
think
is
number
six
here
which
is
at
about
sixty
seventy
percent
that
I
have
tackled
so
far.
So
thanks
many
questions.
I.
D
Just
started
to
think
that,
using
that
what,
if
you
in
your
context,
you
have
an
entity
like
a
database
and
then
you
have
a
parallel
tests
and
you
somehow
want
to
share
a
transaction
or
something,
and
I
don't
want
to
spoil
my
own
code
because
of
tests
so
I
could
you
know
share,
is
the
same
transaction
or
something?
How
do
you
solve
issues
like
you
know,
external
entities
in
a
context,
so.
G
D
G
These
wouldn't
be
running
all
of
them
because
they
were
due
blocking.
You
would
lose
the
parallel
nature,
but
then
you
can
in
this
case
you
would
just
pass
a
different
config
to
your
runner,
which
simply
says
it's
zero.
You
would
still
need
to
provide
those
constraints,
but
it's
at
least
then
you
wouldn't
have
any
threat
contention
of
stuff
like
this.
H
This
one
PR
yeah
yeah,
just
draw
a
girl,
grew,
grew
quite
a
lot
and
I
really
liked
it
two
additions.
There
is
already
one
one
rust
module
with
which
implements
the
gherkin
language,
but
they
don't
do
it
with
modules.
They
parse
feature
files
and
I,
think
just
tables.
So
maybe
you
can
have
a
look
there,
okay
and
check
if
we
can
maybe
interface
wisdom,
2nd
edition
to
test
frameworks.
This
also
the
galvanic
team
test
framework.
Ok,.
G
H
H
G
G
B
Any
time
you
pass
just
any
type
you
pass,
because
because
I
was
thinking
something
similar
than
the
first
question,
because
what
we
do
is
we
do
testing
with
hardware,
so
we
do
external
allocation
off
test
tracks
and
and
how
we
do
it
in
BDD,
at
least
before
rest.
What
we
did
is
we
allocate
a
test
track
in
one
of
the
upper
parent
modes
and
then
passed
that
to
the
inner
ones,
but,
but
would
that
be
something
that
we
can
do
that
way?
B
G
G
G
G
G
G
So
basically
you
you
clone
the
environment.
Whenever
whenever
you
you
reach
one
of
those
sub
sub
contacts,
and
you
don't
have
like
an
explicit
stack,
but
the
call
stack
is
your
stack.
So,
in
the
end
effectively
you
do
have
stack
yeah.
So
if
you
do
receive
a
serial
execution,
then
you
only
have
this.
They
only
have
the
current
branch
of
your
tree
in
memory.
If
you
have
power,
then
of
course
things
can
be
a
bit
different.
G
E
G
So
you
mean
like
having
a
like
a
dummy
test
function
which
simply
right,
yeah
I
mean
or
yeah,
or
you
could
just
basic.
What
you
could
do
is
you
could
just
like
put
this
into
a
single
test
function,
for
which
the
name
would
then
have
like
the
actual
name
of
your
scenario,
but
this
might
interfere
with
the
test
logging
in
test
running
because
we
do
our
own
logging,
and
we
also
that
so
you
can.
G
You
can
run
multiple
scenarios
at
the
same
time,
not
as
serious,
but
you
can
specify
whether
it
should
bail
out
once
any
of
these
fails
or
whether
they
should
continue
and
like
log,
the
certain
failures
or
successes,
but
there
is
no
way
to
easily
integrate
this
right
now.
You
pretty
much
have
to
create
a
specific
like
binary
target
for
running
this.
That's
what
I
would
like
to
fix
by
opening
some
discussion
about
how
to
make
the
rust
run
or
more
extensible
in
this
regard.
Okay,
but.
A
G
G
A
You
that
was
very
extensive
thanks
for
all
the
great
questions,
sorry
for
everyone,
who's
watching
this
live
stream
that
we
had
might
issue
in
the
first
minute
and
yeah.
Thank
you,
everyone
for
coming.
This
is
the
end
of
the
talks.
It's
not
necessarily
the
end
of
the
Meetup
I'll
be
around
for
a
bit
longer,
so
you
can
linger
here
as
well
and
and
talk
to
each
other
and
have
some
more
food,
there's
still
some
bagels,
left
and
and
free
drinks
on
the
house
and
again,
thank
you
for
coming.