►
From YouTube: SES-mtg: 28 October 2020 Part 1
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
so
the
agenda
topic
today
is
to
probably
conclude
my
presentation
on
on
on
topics
and
daniel
is
in
the
minutes
gathering
some
topics
for
future
meetings.
Among
those
top,
many
of
those
are
pertaining
to
modules
and
and
as
compartments
as
framed
today
are
module
loader
api,
it
seems
like
bringing
in
all
bringing
in
the
conversations
about
modules.
Here
is
a
good
idea
and
yeah.
So
with
that,
I
will
share
my
screen
and
resume
as
we
were.
A
To
recap:
we
were
discussing
the
ramifications
of
top
level
await
and
how
that
possibly
requires
changes
to
our
to
the
compartment
proposal.
It's
a
shame.
I
don't
see
salah
on
the
call.
I
think
that
he
was
trying
to
make
a
suggestion
toward
the
end
of
our
presentation
last
week,
but
I
think
that
we
can
just
continue
from
here
is
every
does
everybody
feel
feel
good
about
where
we
left
off
on
this
topic
or
or
did
anybody
have
lingering
thoughts
that
they
wanted
to
bring
into
the
conversation
today.
A
Yeah,
I
I
I'll
try,
let
let
me
let
me
just
go
over
this
slide
and
maybe
it'll
jar.
Some
memories,
so
top
level
await,
has
introduces
the
ramification
that
any
particular
entry
point
module
and
its
transitive
dependencies
are
collectively
asynchronous
and
must
re
and
and
importing
such
a
module
must
return
a
promise
if
any
of
them
have
a
top
level
of
weight.
A
This
introduces
a
hazard
where
a
module
that
that,
if
any
of
your
transitive
dependencies
introduce
their
first
top
level
of
weight
and
they're
the
first
to
do
so
among
your
transitive
dependencies
you
they
could
cause
important.
A
If,
if
the
api
we
create,
introduces
the
possibility
that
you
need
to
check
whether
a
module
is
asynchronous
or
not
in
order
to
import
it,
any
of
your
transitive
dependencies
could
break
your
import
either
by
the
fact
that
by
either
because
of
omission
of
the
logic
necessary
to
check
or
or
some
such
like
that
in
order
to
and
and
this
is
interesting
because
import
now
currently
has
this
hazard
as
designed
that
could
be
eliminated
by
folding
import
now
into
import.
A
And
you
just
always
have
a
promise,
regardless
of
whether
it's
async
or
not,
regardless
of
whether
there
is
a
top
level
of
weight
among
the
transitive
dependencies
or
not,
or
we
could
introduce
a
way
to
observe
whether
it's
async
or
not,
chip.
C
I
I
confess
to
a
point
of
confusion,
which
is,
if
I
understand
what
top
level
of
weight
is.
I
thought
I
did,
but
maybe
I
don't.
I
don't
understand
how
the
concept
of
having
a
top
level
weight
in
your
transitive
dependencies
is
even
a
thing
because
top
level
weight
is
a
top
level
away,
and
if
it's
in
your
transitive
dependencies,
it's
not
top
level.
B
C
A
Yes,
the
so
there's
another
alternative
approach
to
solving
this
problem,
that
is
to
say
that
that
we
consider
a
module
fully
initialized
at
the
point
that
it
it
reaches
its
first
top
level
of
weight.
But
I
don't
think
that
that's
a
coherent
stance,
but
but
but
I
it's
an
argument,
I
can
imagine
hearing
yeah.
So
that's
where
we
were.
A
A
I
think
that
might
not
be
necessary
if
we
do
not,
if
if,
if
execution
may
have,
may
interleave
turns,
but
my
understanding
of
the
specification
as
written
by
hearsay,
admitting
that
I
have
not
read
it
in
detail
myself-
is
that
that
it
does
allow
for
groups.
A
Groups
of
modules
that
do
not
have
a
top
level
await
to
be
executed
in
a
way
that
does
not
give
an
opportunity
for
events
to
be
interleaved
between
module,
initialization
yeah,
and
if
that's
the
case,
then
it
implies
that
we
need
the
module.
Loader
needs
to
be
able
to
by
observing,
by
looking
at
a
static
module
record,
tell
whether
whether
it
needs
to
be
grouped
synchronously.
I
think.
A
A
B
Yeah,
the
in
aggregate
means
that
you're
not
looking
you're,
not
trying
to
make
the
distinction
about
you're,
not
trying
to
detect
some
a
property
of
a
static
module
record
in
isolation
yeah.
So
so,
once
again,
the
request
very
important
now
came
from
a
peter.
Do
you
have
any
further
thoughts
on
getting
rid
of
import
now
and
just
always
having
just
import
returning
a
promise.
D
You
know
we've
actually
we've
been
discussing
that
this
week,
but
always
returning
a
promise.
Doesn't
it
really
doesn't
work
for
us.
D
And
so
we're
we're
continuing
to
look
at
ways
to
deal
with
that
I
mean
clearly
top
level
await
and
synchronous.
Import
are
are
at
odds
with
each
other,
and
I
mean
from
our
perspective.
We
don't
that's,
not
a
problem
like
we.
We
would
be
happy
we're
important
now
to
fail
in
that
case,
like
it's,
it's
it's
not
possible
to
complete.
D
So
so
it
just
doesn't
work,
but
but
the
the
way
that
that
that
works,
we
we
haven't,
we
haven't,
found
a
way
to
completely
reconcile
with
the
the
current
the
current
ses
work.
So
we're
we're
thinking.
D
I
don't,
I
don't
have
any
specific
solution
to
offer
at
the
moment.
D
Right,
that's
fair,
but
I
mean
for
us.
The
problem
is
real,
so
we
we're
spending
some
time
to
see
what
we
can.
We
can
do
to
help
here.
It
would.
A
Be
very
interesting
to
know
what
the
motivating
constraint
is,
that
that
makes
it
necessary
that
to
have
the
synchronous,
synchronous
import
now,
but
that's
that's
something
that
we
can
revisit.
I
think,
if
I
have
not
already
created
an
issue
for
this,
I
will
put
one
on
the
spec
proposal
soon
and
we
can
have
a
conversation
asynchronously.
D
Yeah,
no
sure
it's
I
mean
it's
fairly.
It's
it's!
It's
yeah,
happy
happy
to
do
that.
It's
it's!
It's
pretty
easy
to
explain!
Cool.
B
D
I
mean
I
don't
think
it
should
mess
with
import.
I
think
import
is,
is
well
defined
in
the
language
and
we've.
Never
we've
never
consciously
tried
to
mess
with
that.
So
I
don't.
I
don't
have
a
problem
with
that
part
of
it.
I
am
not
I'd
like
to
find
a
way
to
deal
with
the
synchronous
aspect
of
this
this
now
for
a
better
term.
Sorry,
if
we
can,
I
I
one
thing
I'll
note
just
because
it
struck
me
as
bizarre.
I
may
apologize.
D
If
I'm
repeating
myself,
the
committee
was
completely
fine
with
synchronous
import
when
we
were
discussing
the
standard,
the
standard
library
proposal
in
response
to
jordan's
desire
to
make
standard
modules
available
to
sloppy
mode
code.
Yeah-
and
I
mean
it's
a
fair
concern
about
that.
D
But
I
I
mean
I
understand
it
wasn't
like
universally
globally.
Lauded
is
the
greatest
thing
ever,
but
it
was
quite
quite
a
bit
less
controversial
than
what
we've
raised
here
and
yet
morally
equivalent,
and
so
I
I'm
based
on
that
a
little
more
strong
in
thinking
that
we
should
be
able
to
to
solve
this
in
some
way
it
may
be
through
an
optional
behavior.
It
may
be
through
a
host
hook.
I
don't
I
don't
know
exactly,
but
I
think
there's
there
should
be
a
solution
that
works
for
for
everybody
here.
D
If
we
can't
find
it,
we
can't
find
it,
but-
and
I
appreciate
everybody's
everybody's
effort.
A
A
Yeah,
it's
it's!
It's
action.
At
a
distance,
I
mean
it's,
it's
survivable,
it's
just
action
of
the
difference.
Suppose
the
idea
is
that
the
the
hazard
is
introduced.
When
you
have
a
large
graph
of
third-party
dependencies,
you
do
not
have
control.
C
C
A
D
But
it
but
it
does,
I
mean
I
I
don't
disagree
with
anything
you're
saying
it
does
fail
very,
very
early
and
very
strongly,
though
so,
at
least
it's
I
mean
it's,
not
something.
That's
subtle,
that'll
be
lingering
for
three
years
as
a
problem
before
you
notice
like
it
will
it
will
show
its
face.
B
That's
and
that's
a
principle
we
followed
elsewhere.
I
mean
any
error
that
reliably
happens
in
development,
so
you
can
avoid
you
know.
Deployment
surprises
is
a
a
the
least
unpleasant
of
a
surprise.
A
This
is
a
little
bit
less
easy
than
that
to
solve,
because
it
involves
cutting
a
patch
release
in
order
to
fix
we're
rolling,
rolling
back
the
change
and
releasing
releasing
a
patch
in
order
to
get
rid
of
the
top
level
of
weight.
So
so
there's
like
there's
a
social
loop,
but
that
also
is
common
in
practice.
So
yeah
I
I
again,
I
do
not
have
strong
feelings,
one
way
or
the
other
the
that.
A
I
think
that
there
are
coherent
stories
for
this,
as
as
long
as
we
tell
the
full
story
for
both
in
both
cases.
I
think
that
it's
survivable.
A
A
I
I
think
that
I
think
that
peter
has
hinted
that
the
necessity
drives
from
the
cases
where
there
are
effectively
built-ins
in
compartment
in
the
compartment
api.
The
eq,
the
moral
equivalent
of
a
built-in
is
as
a
namespace
that
was
provided
in
your
module
map
upon
construction
and
and
for
those
cases,
import
now
should
always
work,
yeah,
all
right
cool
the
conversation
to
continue
on
github,
okay.
This
was
in
order
to
the
the
the
for
the
proposal.
A
I'm
I'm
pitching
here
is
motivated
by
the
need
to
it
is
motivated
by
the
requirements
necessary
to
provide
a
somewhat
faithful
emulation
of
node's
existing
library
linkage.
A
The
import
hook
currently
returns.
It
currently
returns
a
a
static
module
record.
We
found
it
necessary
in
the
session
to
add
an
aliasing
feature
so
that,
if
you
could
say
instead
of
returning
a
module
record,
you
could
say
this.
The
module
record
you're
looking
for
exists
underneath
a
different
name
in
this
compartment
and
the
semantics
of
an
alias
are.
A
So
the
idea
here
is
to
overload
the
type
of
the
return
value
of
the
load
hook
or
import
as
it
is
written
today,
such
that
it
can
return
a
static
module
record
or
an
object
contains
a
record
and
an
alternate
specifier
and
possible
and
optionally
an
alternate
compartment
from
which
to
import.
It.
B
Let
me
clarify
something
terminology-wise,
you
said
import
hook
or
you
know,
as
it's
called
today
or
load
hook.
The
hook,
we're
talking
about,
does
not
itself
run
any
of
the
module's
own
initialization
code.
Correct.