►
From YouTube: SES Meeting - Hot Module Replacement
Description
Fred Schott (Snowpack) and Jovi de Croock (Preact) join the SES community to discuss language support for hot module replacement.
A
All
right
welcome
back
hope.
Everybody
had
a
a
great
break,
the
we
today's
topic
is
hot
module
replacement
and
we
have
a
few
guests.
Daniel
has
invited
you
to
crook
and
and
fred
shot
to
join
us
and
fred
is.
I
recently
learned
the
creator
of
snowpack,
if
I'm
not
mistaken,
which
is
topically,
relevant
and
and
yovi.
Would
you
like
to
introduce
yourself.
B
A
A
D
Yeah,
I'm
glad
this
group
can
can
come
together.
I
mean
there.
There
are
multiple
ways
we
could
think
about
the
hmr
problem
at
a
high
level.
So
one
way
is
by
providing
imperative
hooks
to
the
module
loading
process,
which
is
something
that
this
group
has
been
working
on
and
also
something
that
you
know
there's
experience
within
in
user
space.
That
leads
a
lot
of
engineers
to
ask
for
this
to
be
added
to
to
javascript
and
and
environments.
D
Another
way
is
through
a
higher
level
approach,
where
we
could
add
sort
of
direct
capabilities
for
for
certain
things
outside
of
compartments,
and
I
want
to.
Hopefully
we
can
discuss
the
problem
space
in
it
at
a
high
level
like
what
what
is
the
semantics
of
hmr
that
we're
that
we're
discussing
to
to
get
the
scope
right
because
are
we
talking
about?
A
Yeah,
let's
so
much
of
this
group
is
probably
I
certainly
am
not
intimately
familiar
with
how
hmr
works
today
with
the
various
systems
that
that
support
it.
My
impression
is
that
it's
I,
but
the
the
intuitive
design
I
would
imagine
it
is-
is
that
you
would
be
from
the
point
of
of
some
subset
of
your
working
set.
A
That
is
modules
that
have
been
edited
that
you
would
you
would
be
watching
for
edits,
and
that
would
evoke
an
event
that
would
cause
those
modules
and
any
of
the
modules
that
depend
on
them
to
be
reinstantiated
with,
but
sharing
the
instances
that
were
that
were
not
modified,
that
they
depend
upon
and
that
that
would
entail
the
need
for
hooks
to
hand
off
state
that
some
applications
like
preact
would
would
be
implementing
or
libraries
like
preact
would
be
implementing.
In
order
to
conserve
some
amount
of
state.
C
A
C
E
C
C
C
It's
a
really
very
popular
feature
of
webpack
and
and
roll
up
and
any
sort
of
dev
environment.
I
think
even
going
back
before
webpack,
although
that's
certainly
reaching
into
my
my
ancient
history
but
yeah.
It's
today
at
the
very
least,
a
very
popular
workflow,
some
people
use
it
on
the
server
but
really
on
the
web.
It
is.
It
is
essentially
table
stakes
to
a
lot
of
people
and
really
useful
for
speeding
up
that
development.
C
What's
interesting
for
the
esm
story
and
for
the
browser
is
that
you
can
think
of
webpack
and
roll
up
in
any
kind
of
modern
dev
environment
today
as
the
way
they
work,
they
basically
end
up
replacing
the
module
system
or
shipping
their
own
module
system
to
the
browser.
So
at
its
core
you
know,
webpack
is
a
bundle,
but
really
what
it's
doing
is
saying.
I'm
shipping
this
code
to
the
browser,
and
I
own
it
and
control
it.
C
What
snowpack
is
is
leading
is
this
this
sort
of
new
dev
tool?
That's
really
esm
focused
and
relies
heavily
on
esm.
So,
instead
of
doing
any
bundling
in
development,
we're
just
shipping
the
esm
modules
pretty
much
directly
to
the
client,
so
letting
the
browser
do
its
native
fetching
its
native
reloading.
C
F
C
E
I've
had
experi
a
lot
of
experience
with
systems
like
small
talk
where
you
can
update
code
on
the
fly
within
a
system
of
live
objects,
and
there
were
certain
rough
edges
to
that.
That
seemed
that
were
fundamental
that
were
never
able
to
be
fixed
in
principle
manner,
and
I'm
wondering
if
they're
the
same
kind
of
rough
edges
here.
So
the
the
the
two
that
were
roughest
was
anonymous
closures
if
you've
got
a
anonymous
closure.
That's
an
instance.
C
So
it's
actually
the
the
the
request
on
the
platform
here
is
basically
the
hooks
to
to
do
this,
but
the
actual
implementation
is
actually
user
by
user
site
by
site.
The
hmr
that
we
provided
snowpack
is
essentially
just
the
kind
of
hooks
to
say.
Okay,
when
an
update
happens,
how
do
I
apply
it?
So
if
there's
any
sort
of.
D
D
F
C
C
C
C
So
this
is
a
project
that
we
started
when
we
started
looking
at
this
for
snowpack,
which
is
essentially
just
an
hmr
interface.
We
called
it
a
spec,
but
it
was
very
much
in
progress
for
interacting
with
hmr
on
the
client
side.
So,
basically
accepting
these
updates.
You
can
see
joby
here.
He
spent
some
time
on
this
evan
yu
who's
been
working
on
vitae,
has
spent
some
time
on
this
as
well.
Everything
that's
kind
of
in
this
new
esm,
based
dev
tool,
is
essentially
using
a
flavor
of
this.
C
E
C
You
can
see
us
here.
This
is
a
bit
of
our
kind
of
us
having
to
do
stuff
to
work
around
the
limitation
in
webpack.
This
is
just
kind
of
like
create
replacement,
is
the
kind
of
default
behavior?
What
we're
doing
here
is
we're
saying,
okay,
to
get
around
this
limitation,
we
apply
updates
to
the
current
module,
so
there's
a
bit
of
a
the
current
workaround
that
you're
seeing
here.
But
if
you
just
like
to
focus
on
the
interface
itself,
it's.
E
D
D
E
C
C
C
The
idea
is
that
frameworks
can
also
have
a
say
in
this
and
kind
of
how
does
a
re-rendering?
How
does
accepting
this
updated
file
end
up
re-rendering
my
page
itself
in
terms
of
the
workflow
there's?
I
don't
want
to
get
too
far
into
the
weeds
here,
but
the
basic
flow
of
an
update
happens
somewhere
in
the
leaf
node.
C
It's
part
of
that
server
client
kind
of
communication,
where
the
server
understands
the
client's
module
graph
and
we'll
basically
try
to
bubble
that
update
up
into
it,
sees
one
of
these
accept
handlers
that
can
accept
it.
So
if
a
file
with
an
accept
handler
in
it
is
the
file
that
gets
updated,
it
essentially
just
accepts
itself
the
handoff.
There
is
just
saying:
hey,
I
have
updated
browser,
go
and
fetch
this
update
and
then
apply
it
using
the
logic
found
inside
of
the
accept
handler
who.
E
E
C
C
The
bubbling
comes
into
play
where,
if
you're
building
something
like
well
really
any
one
of
these,
if
you're
building
a
react
to
pre-act
spelt,
they
all
have
this
concept
of
re-rendering
and
that
usually
really
only
exists.
This
is
kind
of
app
root.
Really
you
only
need
to
add
one
of
these
in
a
in
practice
to
one
of
those
app
routes.
That's
where
basically
says.
Okay,
any
update
that
happens
lower
down
in
this
in
this
tree
bubble
that
up
to
here,
I'm
the
thing
that
handles
rendering.
A
That
is
to
say
that
the
bulk
of
components
don't
need
to
write
anything
to
engage
with
hmr
and
there's
a
sort
of
default
behavior.
If
you
change
one
of
those
modules,
then
it
will
inform
I'm
guessing
up
the
dependency
graph
until
it
finds
until
it
finds
and
if
it
finds
one
of
these
hooks
installed.
Is
that
right?
That's.
C
F
C
Yeah,
so
we
handle
that
by
not
relying
on
anything
native
to
calculate
that
we
will
just
basically
monitor
what
we
serve
to
the
user
so
or
to
the
browser.
So
we
will,
you
know
basically
for
everything
that
we
serve.
We
will
do
a
quick
static
analysis
of
its
import
graph,
what
it
imports
and
what
it,
what
is
importing
it
and
basically
recreate.
F
C
C
F
F
C
A
C
We
very
quickly
fall
back
to
that.
As
a
kind
of
you
know,
this
is
where
this
really
benefits
us.
Someone
is
doing
pretty
rapid
development
or,
just
you
know,
they're
making
changes
to
a
single
file
and
trying
to
catch
those.
Those
updates,
if
anything,
more
complex,
happens,
and
we
can't
handle
it
successfully.
We
pretty
quickly
fall
out
to
a
full
page
refresh,
assuming
that
the
user
is
moving
files
around
maybe
doing
something
more
complex.
C
So
if
I,
I
think
yeah
there's
definitely
there's
a
lot
of
details
here.
Webpacks
documentation
is
also
pretty
standard
and
they
have
you
know
again
because
they
have
control
of
that
module
graph.
They
have
a
little
bit
more
say
in
how
an
update
gets
applied.
I
don't
think
supporting
hmr
is
a
kind
of
a
feature
of
the
platform
itself,
but
more.
There
are
certain
proposals
in
flight
right
now,
which
would
really
benefit
this
use
case.
C
A
A
A
A
C
It
will
basically
follow
the
bubbling
up
the
path,
so
if,
if
leaf,
you
know
c
gets
updated,
it
will
bubble
that
event
up
to
the
accept
handler
that
that
accepts
that
update
and
that's
kind
of
one
of
the
the
things
that
we
have
to
deal
with
here
as
an
implementation
detail
is
okay.
Well,
how
do
we
actually
apply
the
update
for
that
leaf
node
into
the
application?
We
basically
have
to
reload
everything
in
its
path
up
to
that
parent.
A
C
Okay,
all
the
way
down
to
the
file
that
was
changed.
I'm
sorry
all
the
way
down
the
module
graph
to
the
file
that
was
changed.
So
every
transitive
child
on
that
path
will
get
reloaded
yeah
because
the
url
is
again
in
the
file
imported
and
now
that
import
url
has
to
be
changed
to
point
to
the
new
update
and.
C
A
Yeah-
and
this
is
usually
done
by
appending
a
query
stream
with
a
version
of
the
version
version
number
which
we
can
do
with
yes,
yeah
with
with
web
with
the
web's
notion
of
esm.
I
think
so.
Okay,
this
this
brings
so
relevant.
Relevant
parts
of
the
compartments
api,
as
proposed
today,
are
one
we
have.
E
A
In
any
case,
that
isn't
the
only
avenue
that
we
could
use
in
order
to
introduce
the
ability
like
compartments,
also
support,
lexical,
endowments
and
and
global
object,
which
would
be
equally
suitable.
You
could
introduce
a
global
named
hot
in
the
context
of
a
compartment.
Could
you
have
a
unique
one
for
each
module?
Do
you
need
a
unique
one
for
each
one?
You
do.
You
do
need
a
unique
hot
for
every
module.
F
F
But
I
think
really,
the
idea
that
you're
going
to
send
a
signal
to
your
dependents
might
be
a
better
basis
than
trying
to
model
the
exact
api
here
and
how
to
accept
a
generic
value
roughly
so
that
that's
more
interesting
to
me
having
to
recreate
a
individual
patching
functionality
per
module.
I
don't
think
is
avoidable.
F
E
F
C
C
So
the
idea
is
that
the
accept
handler
has
to
be
written
in
a
way
that
actually
applies
the
updates
to
the
current
module,
so
this
module
anyone
that
actually
accepts
updates
doesn't
have
that
same
behavior
of
being
replaced.
The
accept
handler
exists
to
basically
apply
updates
into
the
module
graph
that
exists
in
the
moment.
It
was
first
loaded,
so
the
url
of
this
never
actually
does
change
by
accepting
updates.
It
says
I
accept
them
in
a
way
where
my
url
will
not
change.
I
will
just
instead
apply
updates
into
myself.
C
E
C
C
Yeah
we
we
are
able
to
rely
on
two
things.
One
is
that
again
in
most
applications,
your
only
integration
point
for
this
is
at
the
render
call.
So
if
you
imagine
a
react
application,
that
kind
of
renders
an
entire
route
of
something
those
render
calls
are
much
fewer
than
actual
components
in
the
site.
So
you
end
up
only
really
having
to
implement
one
of
these,
and
it's
generally
just
basically
calling
telling
react
to
kind
of
do
its
thing
render
a
new
version
of
the
application.
A
C
B
B
B
C
C
Yeah
I've
actually
kept
my
eye
out.
My
approach
was
when
someone
reports
that
we'll
deal
with
it
and
and
no
one
has
reported
it
yet.
I
think
because
it's
so
easy
to
just
refresh
the
browser-
and
it
probably
just
happens
through
the
course
of
someone
doing
web
development
over
over
a
long
enough
time.
We
have
not
seen
that
reported
as
an
issue.
I
am
sure
that
we
have
memory
issues
as
this
grows
and
as
it
grows,
the
module
graph.
A
Yeah,
this
is
actually
relevant
to
a
point
to
assade
gorick,
because
what
we're
doing
at
agorik
is
not
on
the
web.
It's
on
a
on
a
blockchain
and
we're
very
interested
in
upgradability
of
smart
contracts
and
we're
also
very
interested
in
smart
contracts,
not
indefinitely
retrain
in
training
all
of
the
state
of
prior
versions,
but
mark
had
some
really
neat
ideas
about
how
to
bring
something
like
hmr
to
bear
on
them.
E
E
Going
up
and
down
stack
frames,
see
a
bug
in
the
code,
fix
it
and
continue
the
develop.
The
the
debug
session
live
from
point
which,
when
it
worked,
was
great,
it
would
work
like
90
of
the
time
when
it
didn't
work,
then
then,
then
it
was
it
was
it
was.
You
know
it
was
fine,
because
you
just
started
again.
The
the
other
side
of
the
contrast
would
be
java,
serialization,
where
the
serialized
state
uses
the
fully
qualified
class
name.
E
E
A
Yeah
and
I
I
think
that
I
think
that
the
industry
in
general
has
decided
that
that
strategy
is
unwise
in
general
because
of
like
related
issues
with
pickles,
for
example,
with
not
being
the
like.
For
example,
if
you
serialize
your
state,
you
know
python
pickle
and
then
deserialize
it
in
a
future
version
of
your
program.
F
E
Yeah
by
the
by
the
author
of
the
code,
the
author
of
the
code,
writing
the
code
to
upgrade
old
state
to
be
state
that
instantiates
the
new
code,
and
the
key
thing
is
that
the
author
of
the
code
doesn't
know
all
of
the
instance
state
he's
deploying
the
upgrade
process
to
apply
to
instant
state
that
the
author
of
the.
That
is,
that
the
author
of
the
code
doesn't
know
about,
because
it's
it's
it's.
You
know
the
multiple
instances
out
there
in
the
world
of
the
old
code.
F
I
think
I
think
the
differentiation
seems
reasonable
to
me.
I
do
know
v8
is
removing
their
ability
to
do
that
kind
of
in-memory
replacement
that
you
were
talking
about
with
small
talk,
they've
had
that
feature,
and
it's
no
longer
supported
due
to
the
amount
of
bugs
it
has,
so
they
recommend
doing
this
live
editing
in
their
deprecation
dock
like
you're,
describing,
I
think
I
think
that
sounds
good.
I
think
there
are
a
bunch
of
other
questions.
F
F
F
More
to
it
where,
if
you
do
export
star,
you
probably
should
reload
those
modules,
even
if
they
aren't
on
the
path,
if
that
makes
sense,
but
as
long
as
it's
a
manual
process,
I
don't
see
any
major
objections.
I
think
the
the
major
objection
might
be
this
signal
propagating
out
to
the
host
to
cause
the
reload
needs
to
be
clear,
and
I
don't
think
at
least
I
don't
think
naively
will
be
able
to
find
a
cross-platform
solution
for
a
single
kind
of
signal
to
do
that.
F
F
D
F
F
B
C
The
cash
busting
is
more
the
implementation
detail
of
how
we
get
this
today
in
an
esm,
only
environment,
the
idea
of
bubbling
up
or
travel
traversing
through
the
path
through
the
graph
to
dependence
is
more
because
there
is
no
such
thing
as
an
automatic
acceptance
of
a
of
a
module
update
using
the
react
example
to
accept
it,
you
actually
have
to
re-render
your
application,
so
there
is
no
way
in
that
example.
You
could
actually
automatically,
as
the
platform
accept
it.
So
it's
more
about
the
accept
has
to
be
logic
provided
by
the
user.
C
D
D
I'm
just
trying
to
think
about
how
this
could
work
with
different
approaches
to
to
catch
busting,
because
this.
This
is
something
that
I'm
thinking
about
in
the
context
of
a
standard.
Bundling
solution
that
maybe
maybe
this
these
cache
busting
identifiers
should
be
part
of
a
separate
request
header
rather
than
part
of
the
url
or
some
something
like
that,
and
if
this
would
affect
the
the
design
at.
D
So
I
mean,
I
guess,
part
of
what
I'm
wondering
is
if
we
want
commands
in
the
to
control
the
the
esm
import
graph
to
actually
load
or
unload
modules
at
all,
or
if
the
the
current
way
that
the
esm
you
know
module
map
works
is
is
enough,
you
talked
about
import
import
maps
and
is
is
your
plan
to
make
use
of
those
at
some
point
in
connection
with
this,
because
I
think
those
also
have
this
property.
You
can't
go
and
change
them
later,
like
the
module
map.
C
In
terms
of
what
we're
looking
for
or
what
would
help
us,
because
I've
described
the
interface
and
a
lot
of
this
is
working
around
limitations,
there's
a
couple
of
things.
One
is
the
idea
of
having
to
traverse
up
the
chain
traverse
up
the
the
import
dependence
path
to
compare
that
to
sign
like
webpack.
C
They
will
not
do
that.
They
will
just
essentially
replace
the
individual
instance
itself,
basically
sending
the
code
itself
over
the
wire
eval
that
code
and
replace
it
in
the
registry
that
they
own
for
all
of
these
modules,
so
in
one
sense
the
way
that
we
do.
This
is
because
we're
using
urls
as
the
identifier
we
don't
control
it,
there's
something
there
about
the
ability
to
kind
of
patch
in
the
single
update
and
then
combine
that
with
okay,
and
then
here's
how
I
accept
it.
C
If
you
check
out
webpack
spec
for
this,
they
don't
have
the
same
problem
of
okay.
I
have
accepted
an
update,
but
I'm
still
running
the
original
accept
handler,
so
I
believe
mark
you're
the
one
who
pointed
that
out
like
what
happens.
If
you
change
the
accept
handler
code
in
a
world
where
you
control
the
module
registry,
you
can
pull
in
that
new
code
and
then
that's
actually
accepting
itself.
So
they
don't
have
the
same
problem
of
okay.
C
C
C
C
This
is
where
this
one
module
will
actually
never
change.
By
having
to
accept
handler,
we
will
never
be
replacing
this
with
some
kind
of
uniquely
generated
url.
That
will
then
kind
of
cache
bust
and
eventually
replace
the
original
one.
When
there's
an
acceptance
handler,
we
say:
okay,
this
is
a
single
instance
that
will
never
be.
There
will
never
be
two
of
these
running
in
the
same
module
graph.
Instead
as
an
accepting
module,
this
will
apply
updates
to
itself
its
url
in
the
main
module
graph
will
not
change.
C
C
Yes,
the
the
word
replaced
just
you
know,
making
the
clarification
that
it
does
not
itself
get
replaced
by
being
an
accepting
module.
It
keeps
its
own
instance
within
the
original
module
graph
and
kind
of
applies
updates
to
itself
versus
anything
else.
That
is
not
accepting
is,
is
thought
of,
as
it
can
be
kind
of
loaded,
a
second
time
or
a
third
time.
You
end
up
just
orphaning
and
you,
I
think,
pointed
out
the
the
memory
issues
here.
You
end
up
essentially
orphaning
a
lot
as
you
develop.
D
So
if
we,
if
we
had
an
api,
for
example,
that
was
like
import.meta.set
and
it
took
a
multiple
specifier
and
and
a
new,
you
know
thing
that
looked
like
a
module,
namespace
object
and
it
you
know
imperatively
changed
what
the
module
map
points
to
with
this.
I'm
not
I'm
not
saying
we
should
add
this,
but
with
this
kind
of
thing,
give
you
the
the
capability
that
that
webpack
has
right
now
in
changing
its
own
module
graph
or
what
is
the
missing
capability.
C
Yeah,
so
that
I
believe
it
would,
the
missing
capability
here
is
that
idea
of
I
want
to
load
this
new
version
of
the
module
and
whether
that's
done
via
sending
code
literally
over
the
wire
and
then
evaling
or
here's
a
new
url
load.
This,
however,
that
is
loaded.
The
missing
feature
here
for
us
is
the
idea
of
okay.
I
now
want
to
replace
the
existing
module
in
the
existing
module
graph,
so
at
the
original
url
replace
it
that
wouldn't
change
too
much
about
our
interface
right.
C
Every
time
we
bubble
up,
we
have
to
kind
of
update
the
parent
of
that
and
the
dependent
all
the
way
up
the
chain.
Instead,
we
would
just
be
loading
the
changed
file
and
then
calling
the
accept
handler
now,
not
in
a
new
context
or
a
new
module
or
anything.
It
would
just
be
called
assuming
that
it's
dependency,
its
own
already
loaded
imports
now
point
to
the
new
place,
all
the
way
down
the
tree.
C
That
would
bring
us
more
in
line
with
the
kind
of
expectations
of
hmr
today
around
not
having
to
worry
about
this
context
of
applying
an
update
to
itself
and
having
to
remap
its
own
file's
own
imports
one-to-one.
You
could
just
kind
of
say.
Okay,
by
applying
this
update
in
the
tree,
I
have
using
the
live
bindings,
basically
replaced
it
with
the
newest
version
of
this
module.
D
A
Yeah,
there's
also
the
matter
that
are
that
that
currently
the
compartments
api
assumes
an
append
only
module
identifier,
name
space,
my
my
thought,
which,
okay
so,
which
is
which
is
on
the
table.
Do
we
do
we
ma?
Do
we
alter
that
so
that
do
we
alter
the
compartment
api
so
that
it
has
some
feature
that
would
allow
some
of
its
some
of
its
internal
module
map
to
be
invalidated
and
replaced
and
which
would
have
to
be
asynchronous?
A
Incidentally,
in
any
case,
my
my
thought
on
this
with
my
intuition
on
this
is
like
suppose,
that
we
change
nothing
nothing
about
the
compartment
api.
Can
we
support
this
feature?
Can
does
the
compartment
api
better,
enable
frameworks
to
implement
implement
this
feature
using
this?
This
low
this,
this
module
loader
api
in
the
language,
and
I
think
that
the
answer
is
yes
that
that
you
would
be.
E
F
E
F
F
F
E
Yeah,
we're
not
we're
not
talking
about
instantiating
a
new
realm.
Talking
about
extension
modules
should
be
trivially,
I
mean
modules
should
be.
Featherweight.
Modules
should
be
extremely
cheap,
per
instance
of
a
module
within
one
realm
and
that's
certain,
and
we
can
already
take
a
look
at
the
excess
implementation
where
I
think
they're
they
actually
are
more
expensive
than
it
should
be,
but
there's
still
there's
multiple
mod,
there's,
multiple
compartments
being
instantiated
in
the
light
bulb.
F
So,
just
back
to
daniel's
question,
I
think
exposing
something
seems
reasonable
to
me.
At
least
I
don't
know
about
the
api
design
of
what
that
is,
I'm
not
committed
to
any
api
design.
I
think
there
I
have
lingering
questions
about
the
source
of
whatever
this
signal
is
right.
Now
it's
coming
in
from
the
server
somehow
and
then
it
needs
to
notify
the
module
graph
and
so
are.
Are
you
just
basically
sending
a
signal
to
any
any
module
by
string
by
href,
whatever
you
want
to
call
it?
D
D
F
Yeah,
so
that's
that's
one
end
that
I'm
trying
to
figure
out,
I
think
doing
it
by
url
or
something
seems
fine.
What
the
actual
signal
is.
I
don't
have
any
strong
preference,
slight
preference,
that
it
should
be
generic,
so
you
can
basically
have
the
same
ergonomics
as
try
catch
here
per
the
acceptance
criteria.
You're
you're
asking
for
some
kind
of
barrier
semantics,
which
I
I
need
to
think
on
the
barrier
would
be
basically
propagating
out
until
you
reach
a
depth
that
is
entirely
covered
with
these
handlers.
F
A
F
And
once
you
reach
a
guard
for
these,
in
this
case
the
accept
handler
you
stop
the
traversal
on
that
graph
node,
and
so
you
continue
all
other
current
traversals,
because
there
can
be
multiple
active
at
a
time.
So
if
we
have
two
and
at
depth
one
we
encounter
and
accept
on
one
of
those
traversals,
we
stop
that
traversal
and
then
in
depth.
Five
on
the
other
one
we
encounter
it
and
there
are
no
other
active
traversals.
A
I
think
that
fred's
description
of
the
semantics
of
of
of
what's
presently
implemented
with
hmr
is
a
great
deal
simpler
than
that.
I,
my
understanding
is
that
it's
by
a
complete
traversal
of
the
cog
graph
and
it
hap,
and
if
it
happens
to
be
that
there
are
multiple
accepts
in
that
in
that
traversal
of
the
code.
Co-Graphic
is
ambiguous
and
it's
discarded.
B
F
A
Given
that
we're
over
time,
I
think
that
what
we
ought
to
do
is
put
some
more
time
on
the
calendar
when
jovi
and
fred
are
both
available
and
we
meet
regularly
at
this
at
this
time
every
week.
So
a
proposal
for
a
time
is
welcome.
I
I
think
that
yeah
we
were
booked,
for,
I
think
one
or
two
meetings
ahead,
but
we
can
come.