►
From YouTube: JupyterLab Team Meeting - June 29, 2022
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues?q=is%3Aissue+label%3A%22Dev+Meeting+Minutes%22
A
All
right
welcome
to
the
june
29th
weekly
jupiter
lab
call.
Today
we
have
18
people
on
the
call
and
hopefully
more
are
coming.
Please
find
the
link
to
today's
meeting
minutes
in
the
chat.
If
you
just
joined.
Let
me
just
paste
that
in
one
more
time
and
if
you
feel
inclined-
please
add
your
name
to
the
attendees
list
and
if
there's
something
you'd
like
to
discuss,
please
create
a
bullet
point
in
the
agenda
section
or,
if
you
think,
it'll
take
more
than
a
few
minutes.
B
Yeah
so
hi
everybody.
We
just
wanted
to
make
a
quick
announcement
for
the
because
we
bought
ambiguator
on
jupiter.
So
for
those
who
don't
know
integrators,
the
main
features
are
to
be
able
to
create
a
cement
and
to
share
a
assignment
between
a
teacher
and
student
and
then
to
grade
it
and
hear
some
feedback.
B
So
it
seems
that
I
cannot
share
my
screen,
it's
a
non-issue
from
from
zoom,
so
I
cannot
show
you
but
it's
composed
of
a
poor
server
extension
and
five
lab
extension
and
that's
almost
it.
So
it's
it
works
now
with
jupiter
and
the
next
step.
A
Do
you
want
to
do
a
screen
share
all
right?
Do
you
want
to
do
a
screen
share.
A
Maybe
maybe
in
the
next
next
week's
call
you
could
or
something
because
that
sounds
awesome
and
I
think
people
would
like.
A
A
Okay,
chung,
you
are
up
next.
E
E
Yep
yeah,
okay,
so
I
put
the
link
to
the
pull
request
in
the
is
the
markdown
document
and
basically,
for
now,
the
language
server
protocol
support
for
jupiter
lab
is
provided
by
the
reserve,
gpa
drop
fp
extension.
E
E
What
do
it
look
like
so
for
now,
for
on
the
front
in
the
running
panel,
I
add
a
new
language
server
section,
which
means
showing
the
running
language
server
with
jupiter
lab,
and
if
I
open
a
python
notebook,
it
should
be
television,
detect
the
language
of
the
notebook
and
start
the
associated
language
server.
E
E
E
This
means
the
the
pathway
handles
the
server
initiation
and
the
communication
between
the
following
the
back
end,
like
so
in
zip
diagram,
so
on
the
front
end
feature
of
the
language
server,
the
not
yet
integrated,
but
it
will
be
the
subject,
the
future
work,
but
for
the
demo
I
I
created
a
attention:
a
new
attention
for
jupiter
lab.
We
can
use
the
new
lsp
api
of
cpt
lab
to
to
add
a
complete
provider
to
jupiter
lab,
for
example,
here
in
the
setting
in
the
code
completion
session.
E
Normally
we
have
a
computer
provider
from
the
contacts
content
and
I
add
a
new
provider
for
the
language
server
from
my
attention
and
I
deactivate
the
two
default
provider
and
when
I
go
back
to
my
notebook,
the
complete
item
here,
it
comes
from
the
result
of
the
running
python
language
server
and
because
it's
a
the
result
come
from
the
language
server.
It
also
work
with
a
normal
python
file.
E
I
only
need
to
request
the
the
lsp
connection
manager
and
the
lsp
feature
manager
from
jupiter
lab,
and
then
I
will
create
the
complete
the
provider
for
the
language
server
protocol
and
even
the
provider,
if
only
about
200
likes
a
code,
because
I
don't
need
to
deal
with
setting
up
or
connecting
to
the
level
server
everything
you
provide
by
jupiter.
I
only
need
to
get
the
result
from
the
language
server
and
transform
it
into
the
format
of
the
completed
jupiter
lab
to
make
it
work,
and
this
is
the
front
end
part
because
attention.
E
The
containers
is
a
server
attention
pipe
to
handle
the
language
server,
and
we
already
discussed
with
the
team
jupiter
server
and
we
decided
to
move
the
the
server
parts.
The
server
extension
of
the
jupiter
lab
msp
extension
into
a
standalone
report
inside
the
jupiter
server
organization,
and
this
to
request
he
only
related
to
the
front-end
part
and
on
the
technical
part.
Basically
I
done,
and
if
someone
have
time
to
take
a
look
at
it,
it
would
be
great
and
that's
it
for
me.
A
F
Just
had
a
question
so
the
as
far
as
I
understand
the
plan
was
to
depend
on
the
the
server
side
package
interpret,
but
does
that
include
any
specific
language
server
implementations.
E
No,
the
language
driver
doesn't
come
with
jupiter
lab
detect
automatically.
If
you
have
a
summary
server
installed
on
your
environment,
if
not.
F
F
Okay,
yeah
good.
I
I
think
I
agree
with
that
choice,
because
so
some
of
these
language
servers
are
not.
You
know
as
open
source
and
as
open
governments,
maybe
as
you
would
always
want.
A
Mike
has
a
question
in
the
chat
about
a
pr
in
the
jupiter
lab,
lsp
org
and
whether
it
can
be
included
in
the
work
that
you've
done.
Trunk.
E
Sorry,
I
didn't
see
it,
I
think
at
first.
I
think
you
see,
I
related
only
to
the
several
parts,
but
it
contains
also
the
the
front
empire.
E
D
G
Are
they
are
just
being
added?
So
I
I'm
thinking
whether
that
is
something
which
would
be
nice
to
discuss
upfront
when
integrating
whether
we
would
have
this
user
interface
for
configuration
as
envisioned
by
the
other
pr.
E
For
the
current
pr,
we
have
a
much
more
sample
setting
ui
for
the
language
server,
but
I
think
it
we
can
integrate
it
later
on
another
step
for
the
setting
ui,
because
there
are
some
different
things
between
the
the
code
in
the
course
of
the
lab
and
the
language
server
on
android
attention,
and
I
think
we
still
need
have
some
rework
on
the
current
pr
to
make
it
work
with
in
search
with
the
lab.
D
Cool
just
for
I
don't
know
if
people
realized
realize
that
this
is
a
really
big
deal.
So
I
mean
this
is
a
big
feature
that
was
initially
in
nixon
michelle's
extension
and
there
has
been
a
lot
of
work
put
into
this
massive
request.
That's
been
rebased
quite
a
few
times
already
and
one
of
the
main
sort
of
milestones
for
jupiter
4..
So
we're
really
excited
about
this.
A
I
think
this
sort
of
functionality
being
not
just
inside
notebooks
but
inside
other
files,
is
going
to
make
jupiter
lab
a
more
compelling
place
to
stay.
If
you
only
went
for
it
for
some
tasks
and
had
to
leave
for
other
tasks,
it
might
keep
users
on
and
that's
really
cool,
and
it's
also
just
awesome
to
bring
it
into
core.
So
thank
you
for
all
the
work.
H
H
In
20
I
don't
know
2016,
maybe
2015.
I
mean
a
long
time
ago.
I
think
in
one
of
the
visits
where
I
met
with
craig
and
and
others
from
the
from
the
google
team.
H
Education
workshop
and
my
talk,
history
was
precisely
about
how
to
use
jupiter
lab
to
teach
kind
of
end-to-end
computing
to
students
who
are
doing
research
and
learning
and
how
to
do
pretty
much
all
of
their
computational
life
in
the
cloud
with
version,
control,
reproducibly
and
the
whole
story
of
duplo
lab
is
kind
of
a
linchpin
of
that
story
of
that
it's
not
just
the
notebooks,
it's
it's,
and
that
was
the
end
for
the
exact
point
of
the
talk
so
to.
H
For
me,
this
is
pretty
critical
and,
and
I'm
delighted
and
thanks
so
much
nikola
for
and
and
and
tong
for
doing
this
work
and
trump.
I'm
sorry
for
doing
this
work,
because
both
the
envy,
greater
and
and
this
work
are
really
critical
to
at
least
kind
of
the
story
we're
building
with
education
and
research.
B
You
have
it
yep,
yep,
okay,
so
I
will
just
present
you
quickly,
the
extension,
but
you
have
one
there
on
the
right
panel
here
which
work
on
the
on
the
same
metadata.
B
So
you
can
change
the
metadata
and,
and
that
will
create
specific
assignment
from
that
method
and
there
is
one
extension
to
validate
the
notebook
so
it
executed.
So
the
notebook
is
executed
on
the
server
side
and
if
there
is
no
no
cell
with
error,
it
gives
you
a
success
result.
If
I.
B
B
B
B
So
if
you
go
there,
you
can
do
autograde
and
generate
feedback,
so
I
will
not
show
you
all
the
features,
but
but
it's
not
working
on
hp.
H
H
B
I
B
A
Okay,
cool
federick:
you
are
up
and
welcome
back.
I
Thanks
ashin,
hello,
everybody
so
not
much
on
my
site.
The
first
point
is
just
I've
seen
things
and
didn't
look
much
in
detail.
What's
the
reason
for
it,
so
in
two
pr's
that
are
updating
dependency,
we
start
to
hit
a
ygs
multiple
import
error.
As
I'm
lucky
kevin
is
there,
and
maybe
I
assume
it's
because
it's
trying
we
are
trying
to
import
twice
ygs,
like
maybe
two
different
versions.
That
could
be
the
reason.
J
Yeah,
it's
either
two
different
versions,
although
I
don't
think
that's
the
case,
I
think
what
is
happening
is
that
you
import
both
the
common
js
version,
which
is
the
thing
that
node.js
usually
uses
and
the
ecmascript
version,
which
is
like
the
new
module
type
definition
that
is
often
used
by
webpack,
and
this
arrow
basically
occurs
if
you
use
two
different
versions
and
these
are
different
different
scripts.
Basically,
these
are
different
bundles
and
this
can
lead
to
serious
issues.
So
please
try
to
fix
this
other.
J
Otherwise
you
might
get
issues,
although
if
it's
just
examples,
maybe
you
don't
care
too
much.
I'm
not
sure
how
this
is
called.
I
C
J
I
think
what
you
should
do
is
just
use
semver
to
use
the
latest
version
of
version
13
and
in
next
month,
or
something
version
14,
but
use
always.
The
latest
version
try
to
do
that.
Something
that
I
can
recommend,
maybe
also
for
the
other
approach,
is
to
you
to
specify
in
webpack
or
whatever
bundle
you're
using.
I
think
that's
webpack,
that
you
want
to
resolve
to
that
specific
file
in
in
yjs,
so
you
don't
resolve
to
the
ecmascript
version.
You
always
resolve
to
the
to
the
commonjs
version,
or
always
the
ecmascript
version.
J
You
can
specify
that
and
I
think
we
already
did
something
like
this.
Maybe
it
is
not
yet
there
in
examples,
maybe
yeah.
I
You're
right,
it
may
be
only
something
missing
in
the
example
thanks
a
lot
for
the
input
sure
and
the
other
one.
So
at
one
stack
with
a
client,
that's
paying
us
for
looking
at
a
memory
leak,
so
I
start
to
push
some
fixes,
the
the
link
to
the
pr.
I
Maybe
I
will
just
try
to
be
brave
and
share
my
screen.
It's
mainly
a
design.
I
Already
I
get
another
tab,
so
we
get
a
specific
menu
that
is
called
a
ranked
menu
in
jupiter
lab
here,
and
this
guy
is
returning
a
disposable
menu
item,
and
so,
when
you
are
creating
an
item,
we
wrap
that
item
in
another
object.
That
has
a
dispose
method,
let's
say,
and
the
trouble
with
that
is
that
within
this
disposable
we
are
connecting
the
menu
to
listen.
If
the
menu
is
disposed.
I
I
For
that
is
that,
if
the,
if
the
user
is
directly
on
the
menu,
please
clear
all
items,
the
items
will
be
removed
won't
be
linked
in
the
menu,
because
the
array
will
be
reset
but
the
disposable
menu.
We
still
be
hanging
because
we
have
this
signal
connected,
and
so
this
week
reference
it
allows
to
free
the
memory
for
the
items,
but
that
disposable
menu
is
still
hanging
in
the
in
the
memory.
I
So
if
somebody
has
better
id
how
to
refactor
that
code
or
a
better
happy
pattern,
because
those
are
not
really
public,
I
think
oh
yeah.
They
are
public,
but
maybe,
if
somebody
has
some
ideas
how
to
to
do
similar
things
without
that
that
strange
wrapping
of
an
item
within
a
disposable
menu
item,
we
will
be
glad
to
to
improve
the
that
part
of
the
cook.
J
J
All
right
sounds
good,
yeah,
thanks
frederick,
so
I
joined
this
meeting
because
I
created
a
pr
first,
I
want
to
motivate
some
of
the
things
from
that
we
did
last
year
last
year.
We
we
basically
came
up
with
this
shared
model
approach
that
basically-
and
that
was
like
a
group
effort
right
eric-
was
also
eric.
J
Charles
was
also
very
involved
in
this,
and
I
I
really
like
this
approach
the
model
approach,
which
is
basically,
we
find
a
central
place
where
we
define
how
we
want
to
model
a
jupyter
notebook,
for
example,
or
file,
and
note
in
enchanter
how
we
want
to
model
that
and
yjs
expose
these
as
abstract
classes
that
are
really
easy
to
use
and
modify
and
listen
to.
J
That
was
our
approach
and,
from
my
perspective,
I
like
this
approach,
a
lot,
because
it
allows
us
to
share
this
package
with
other
people
that
maybe
want
to
implement
a
jupiter
lab
alternative,
or
that
is
actually
compatible
with
jupiter
lab.
So
based
on
the
shared
model
approach,
you
can
easily
build
your
own
custom,
jupta
notebook
using
a
different
editor
or
whatever
is
you
don't
have
to
use
all
these
components?
You
can
do
it
just
the
way
you
wanted
to,
and
I
I
feel
like
that
is.
J
That
was
a
really
nice
approach
and
I've
actually
been
thinking
of
doing
this
for
more
things,
for
example
like
calendar
data
and
editor
content
and
the
ygs
project,
so
that
was
that
was
our
intention
and
then
basically,
I've
been
absent
for
quite
a
while
and
carlos
opened
a
pr
that
basically
removes
the
shared
model
approach
and
reverts
back
to
the
model
db
approach
that
we
had
previously
and-
and
there
are
some
reasons
to
do
that
like
and
you
should
listen
to
the
discussions.
J
I
want
to
be
fair
here,
but
I
was
a
bit
like.
I
feel
this
is
not
the
approach
that
we
should
go.
I
would
like
to
retain,
but
like
that
would
be
my
favorite.
I
want
to
convince
you
of
that
to
retain
the
shared
model
approach
that
is
very
reliable
again,
like
the
other
approach,
that
reintroduces
model
db
is
a
complete
break
with
what
we
currently
have,
whereas
in
my
pr
I
simply
remove
model
db
and
simplify
the
code
base.
J
Overall,
I
remove
something
like
1400
lines
of
code
and
I
feel
everything
is
a
lot
simpler
now.
So
I
offer
this
to
you.
There
is
a
lot
of
useful
information
there
that
should
be
reused
and
you
we
know
we
should
definitely
discuss
why,
for
example,
the
double
binding
logic
is
now
much
simpler
or
how
we
solve
the
initialization
problem,
because
now
we
don't
have
model
db
anymore.
J
We
can
make
the
shared
models,
a
single
source
of
truth,
and
I
think
for
the
project
that
is
very
important
because
otherwise
you
run
into,
for
example,
overwriting
of
content,
because
there
are
two
sources
of
truth
and
one
of
them
like
model
db
or
whatever
else
you
have
can
always
override
the
the
existing
content.
That
you
have-
and
this
might
be
a
reason
why,
in
the
current
rtc
version
there
are
sometimes
there
is
sometimes
data
loss.
So
our
our
approach
was
always.
J
We
want
to
make
ygs
a
single
source
of
truth
or
shared
models
and
initialized
the
content
only
on
the
back
end-
and
this
is
now
completely
implemented
in
this
pr,
but
also
in
carlos
pr,
to
be
honest,
so
as
a
cyclist-
and
this
is
something
that
some
of
you
should
look
at,
I
wanted
to
make
the
notebook
tests
run
more
efficiently
and
reliably
because
they
always
break
for
me
for
random
reasons,
and
now
they
run
reliably.
J
So
please
check
it
out,
even
if
you're
not
interested
in
the
other
things,
but
I
would
very
much
welcome
a
a
review
of
the
pr
that
I
created.
I
will
send
it
in
the
chat
again
and
yeah.
That's
it
from
me.
A
Okay,
any
questions
comments
so
just
to
give
some
context
before
and
if
you're
still
thinking
about
it,
we
have
a
an
rtc
call
that
happens
every
other
week
and
sometimes
they
are
more
lively
than
other
times.
A
These
two
prs
are
the
subject
of
much
conversation
in
those
calls
and
also
some
discussion
and
comment
threads
and
yeah.
So
if
this
is
all
new
to
you,
cool
curious,
what
your
thoughts
are,
and
if
this
is
not
new
to
you,
also
cool
curious,
what
your
thoughts
are.
H
I
see
some
comments
from
sylvan
on
the
pr
itself
and
I
don't
know
if
maybe
we
can
get
a
bit
of
just
context
and
discussion
between
both
sylvan
and
kevin.
While
everyone
is
listening
it
it
may
help
it's
it's
a
pretty
dense
thicket
to
wade
through
and
I'm
I'm
trying
I
am
trying
to
read
through,
but
I'm
not
using
those
apis
myself.
So
if,
if
there's
a
bit
of
discussion
about
sylvan's
comments
that
might
help.
D
Oh
yeah,
this
is
more
of
a
review
comment
on
this
approach,
but
it
could
totally
be
fixed,
so
I
was
looking
at
it
earlier
and,
as
I
didn't
know,
that
kevin
was
going
to
bring
it
up
today.
I
just
checked
that
it
still
applied
to
the
latest
comments,
so
so
here's
my
take
on
it
before
I
get
into
why
I
prefer
one
approach
over
the
other,
so
in
both
pull
requests
we
remove
so
in
in
the
jupyter
3.x.
D
D
Now,
in
the
case
of
carlos
carlos,
actually
completely
removed
the
shared
models
that
were
introduced
in
3.x
and
uses
a
model
db
like
object
which
are
essentially,
you
know,
immobility,
we
had
observable
less
and
was
observable
the
dixon.
What
not
right
carlos
makes
some
kind
of
equivalent
to
that
that
is
based
in
yjs
has
a
slightly
simpler,
even
system
than
model
db
had.
But
it's
essentially
that
right.
D
D
So
this
is
really
where
it's
different.
I
would
say.
Another
aspect
of
kevin's
approach
is
that
these
shared
models
and
this
entire
hierarchy
of
classes
live
in
a
separate
npm
package
in
the
jupiter
lab
repo,
instead
of
being
spread
across
the
different
implementation
classes
for
sales
output
areas
and
whatnot.
D
So
I
think
this
part
was
of
what
I
said
was
a
fairly
purely
factual
sort
of
statement
of
what
these
two
things
did
right.
D
There
has
been
other
discussions
that
on
these
two
pr's,
that
also
touch
other
aspects
of
real-time
collaboration
regarding
the
modelling
of
metadata,
so
as
it
turns
out
in
jupiter,
3
and
earlier
versions,
there
are
some
metadata
attributes
that
have
to
be
synced,
because
the
notebook
format
is
not
well
specified
and
so
syncing
different
parts
of
the
same
dictionary
is
actually
rather
problematic
for
doing
rtc,
and
you
could
make
two
very
valid
changes
to
such
addict
and
have
the
auto
solver
like
auto
merger
like
resulting
something
invalid.
D
So
the
way
kevin
approached
that
issue
was
that
he
load
for
metadata
to
be
set
and
fetched
globally.
D
So
what
carlos
did
in
his
pr
that
could
also
be
done
in
with
kevin's
approach,
was
to
granularly,
expose
the
metadata
and
simply
resolve
this
issue
of
synced
attribute
by
just
electing
one
as
being
the
only
one
that
should
be
used,
and
you
know
sort
of
deprecating
the
other
one
and
it's
it's
a
choice,
it's
another
debate,
but
that
thing
could
be
done
in
either
approach
and
it
comes
with
a
another
thing.
D
Is
that
one
constraint
that
we
have
that
we
was
sort
of
decided
early
on
was
that
the
ygs
core
type
should
not
be
exposed
too
much
across
the
entire
difficulty
base
and
that
choice
prescribed
making
this
wrapper
on
top
of
ajs.
That
are,
you,
know
the
shot
types
of
curls
right,
which
had
quite
a
bit
of
you,
know
boilerplate
code,
basically
so
yeah.
These
are
the
two
main
things
right.
D
So
in
terms
of
who
agrees
with
what
and
which
approach,
I
would
say
that
eric
and
kevin
are
pretty
convinced
of
the
shell
types
of
the
shed
models,
and
I
would
say
that
I'm
pretty
much
in
favor
of
carlos
approach.
D
D
So
my
sense
is
that
this
split
of
application,
state
with
shared
state,
is
causes
kind
of
double
hierarchies
of
duplicated
hierarchies
of
classes
that
are
really
hard
to
maintain,
especially
as
they
live
in
two
different
places
and
in
different
npm
packages.
D
What
I
think
is
that
they're,
really
the
the
main
argument
for
that
split,
is
that
the
shared
documents
that
kevin
likes
and
wants
to
promote
really
serve
as
schemas
and
that
that's
the
role
that
he
wants
to
publish
them
separately
and
have
them
be
referenced
in
the
schemas
or,
like
you
know,
should
models
for
other
implementations
and
whatnot,
and
what
I
think
about
it
is
that
we
should
really
have
some
kind
of
schema
specification
for
this,
rather
than
like
a
reference
implementation
that
everybody
should
use
and
in
my
comments
in
the
pull
request,
I
show
that
in
the
example
like
in
the
current
state
of
kevin's
pull
request
that
he
just
opened,
there
is
already
some
schema
breaking.
D
That
happens
because
of
this
mismatch
between
the
two
hierarchies
of
classes,
and
so
for
example,
and
so-
and
I
don't,
I
think,
they're
totally
fixable
and
it's
not
really
like
in
themselves
an
argument
against
one
that
and
he
could
fix
them
in
this
fear
and
that
my
statement
would
become
wrong.
But
what
I
mean
is
that
it
illustrates
a
point
that
it's
hard
to
keep
them
missing.
D
The
bayes
y
model
has
a
source
attribute.
That
is
not
a
valid
attribute
in
in
the
book
and
we
are
inherit
from
it
in
the
book
like
things
like
this,
which
make
you
know
like
would
show
that
you
know
having
two
different
like
sort
of
parallel.
Implementation
of
the
same
thing
is
error-prone,
in
my
opinion,
so
and
kevin
also
had,
I
think,
some
arguments
about
carlos's
approach
in
how
he
does
that,
what
he
calls
the
double
bindings
so
between
views
and
models
and
thanks.
I
think
he
thinks
he
like
that.
D
A
I
think
it's
appropriate
for
kevin
to
respond,
but
let
me
just
remind
everyone:
we
have
14
minutes
left
on
this
call
and
I'm
happy
to
forgo
the
agenda
item.
I
was
going
to
talk
about
just
click,
the
link
because
there's
a
discussion,
I
invite
you
to
participate
in,
and
I
would
like
to
give
vidar
a
chance
to
talk
about
his.
So
how
about
we
got
basically
nine
more
minutes
and
we'll
leave
the
last
five
minutes
for
vidar.
Okay,
kevin.
What
do
you
think?
Okay.
J
I
wanted
to
say
right
these.
The
first
things
that
savan
said
was
was
true,
like
the
the
state
of
things
right
regarding
his
arguments,
I
I
would
account
like
I
would.
I
would
have
arguments
against
that,
for
example
when
he
said
that
that
there
are
problems
with
the
schema
well
like,
for
example,
with
the
duplicate
hierarchy.
J
I
I
think
the
code
base
as
it
is
in
the
pr
is
actually
much
simpler,
cardos
pr
at
something
like
seven
thousand
lines
of
code,
there's
a
lot
of
documentation
there,
but
it
is
some
code
that
is
added,
and
you
know
the
pr
that
I
have
strictly
just
removes
code.
Basically-
and
you
know,
changes
some
lines,
but
you
know
it's
from
a
from
a
review
perspective,
also
easier.
You
know
in
practice
it
really
makes
sense
to
separate
application
state
from
shared
state.
J
J
Somebody
has
turned
off
their
on
my
their
micro.
Fernando.
Can
you
please
turn
off
your
mic
thanks,
but
maybe
that
is
it.
I
think
in
a
separate
discussion-
and
I
please
very
much
invite
you
to
come
to
one
of
the
rtc
meetings,
because
we
we
should
really
discuss
this
as
a
community.
They
are
really.
J
This
is
really
a
big
change
and
I
I
would
like
very
much
to
convince
you
of
the
shared
models
approach
of
something
that
I
think
I
believe
is
very
simple,
very
reusable
outside
of
this
project,
and
it
would
be
great
if
we,
if
we
can
talk
about
this
a
bit
more,
that's
it.
You
have
even
much
more
time
now
unless
there
are
questions.
A
I
think
there's
probably
a
lot
of
questions,
but
I
I
do
think
that
it's
better
to
not
get
mired
in
one
question,
because
that's
what's
about
to
happen,
probably
so
what
I
think
one
last
parting
thought
I'll
leave
this
discussion
with
is
we
haven't
had
this
situation
before,
where
we
have
two
working
good
faith,
implementations
that
are
competing
with
each
other
and
we
haven't
faced
that
sort
of
decision
point
before
as
a
project
it.
A
We
do
have
now
new
governance.
That
puts
us
in
a
position
where,
if
we
cannot
come
to
a
consensus,
we
can
still
make
a
decision
by
calling
a
vote,
but
that
seems
best
left
for
a
last
resort
right,
so
brian
opened
two
votes
that
were
more
about
constraining
the
question
but,
as
kevin's
pointed
out
in
both
of
those
issues,
whatever
way,
we
decide
those
things
actually,
the
both
implementations
could
achieve
those
things.
A
So
it
doesn't
it's
not
particularly
dispositive,
although
it
would
indicate
a
preference
for
doing
for
for
not
shipping
shared
models
with
models
that
contain
counterparts
and
other
packages.
A
But
beyond
that
I
don't
know,
we
should
give
some
thought
to
how
we
resolve
a
question
like
this,
because
it
hasn't
really
come
up
before
and
how
about
this?
How
about
vdor?
You
do
your
agenda
item
and
then
whatever
is
left,
we
will
continue.
This
conversation
is
that
okay,
cool.
F
All
right
yeah,
this
is
it's
like
being
the
last
talker
before
for
dinner
or
whatever,
but
it's
yeah.
I
just
wanted
to
mention
some
pull
requests.
I
did
that.
F
I
wanted
some
input
on.
I
did
some
pull
requests
on
improving
the
performance
around
this
kernel
source
you
and
the
debugger,
especially
if
you
have
a
lot
of
imports,
or
some
of
them
are
not
rather
large
it's
it
could
be
quite
debilitating,
but
one
of
the
things
I
wanted
to
ask
for
do.
We
have
like
a
cos,
a
standardized
component
or
component.
We
use
for
virtualized
lists,
because,
if
you
have
like,
I
don't
know
a
few
thousand
modules
imported
or
whatever
few
hundreds-
I
don't
know
it's
it's.
F
I
No,
no,
no,
no
creative,
created
a
widget
other
than
that
william
in
cocark,
is
using
react.
Virtuoso,
that's
pretty
awesome.
As
far
as
he
explained
I
looked
at
it,
I
haven't
used
much
of
it
and
now
otherwise
there
is
the
for
react.
There
is
the
famous
react
window.
I
think
stuff.
That's
but
virtuoso
seems
more
powerful,
yeah.
F
I
F
I
guess
that's
the
problem,
but
I
knew
that
there
exists
a
lot
of
solutions
and
people
have
opinions.
I
wonder
if
you
already
made
a
decision,
it
seems
like
the
discussion
is
still
up
in
the
air,
so
I'll,
so
that
that
is
a
future
extension.
Future
improvement
in
that
pull
request.
So,
if
you
already
had
it,
I
thought
I
would
implement
it,
but
now
I'll
just
sidestep
that
and
punt.
F
And
yes,
I'm
so
quick
to
get
some
I'll
use
on
that.
Also,
I
did,
I
see,
is
steve's
still
here
yeah,
I
did
fix
for
the
selection
between
the
the
yard,
so
the
yarn
lock,
at
least
in
the
three
four
branches,
mostly
yarnpackage.com,
and
then
the
luminal
packages
was
npmjs.org,
which
our
current
way
of
replacing
the
repository
with
something
else
relies
on
all
of
them
being
the
same
and
all
of
them
being
the
value
that
is
hard
coded
in
this
commands.pi
file.
F
C
F
K
As
I
understand
it,
yarn
packages
is
basically
a
proxy
now
to
npm
and
it
it
if
we
were
to
switch
to
yarn
very
they.
They
do
like
just
a
prefix
in
the
yarn
lock
file.
But
this
is
reasons
we
can't
switch
maximum
value
and
effort
at
one
point,
but
there's
a
lot
of
friction
there.
K
F
F
If
the
npm
js
is,
is
more
performant
or
if
there
were
some
issues
with
the
iron
packs
repository,
we
should
switch,
but
then,
if,
if
there
isn't,
then
we
can
at
least
revert
to
your
own
package
for
now
and
then
make
a
cleaner
effort
in
the
future,
because
now
there
will
be
an
integrity
check.
So
if
somebody
tries
to
switch
to
npm.js
it
will
they
will
complain
at
you
a
bit.
I
I
I
think
I
like
what
you
have
done
vidar
to
to
just
keep
the
the
yarn
repository
as
it's,
and
maybe
we
could
switch
to.
I
We
could
answer
that
question
for
four,
oh
and
maybe
switch
to
npm
for
decide
for
for
oh
if
we
switch
it
for
or
not,
but
presumably
like
for
for
your
case
for
organization
having
to
change
the
the
repository
probably
better,
to
just
keep
things
like
that,
because
maybe
they
use
their
own
tweak
for
changing
the
the
lock
file
and
not
what
we
are
providing
so
probably
better
to
keep
keep
it
the
way.
It
was
thanks
for
the
pr.
A
Cool-
I
just
noticed
on
the
agenda
that
I
wasn't
the
only
other
person.
Isabella,
also
notes
that
the
accessibility
call
is
in
19
minutes
and
I
will
forego
my
issue,
which
please
check
out
that
link.
A
Workspaces
I
presented
five
different
improvements.
Maybe
we
should
do
all
of
them.
Maybe
we
should
do
none
of
them.
I'm
looking
forward
to
what
you
have
to
say,
and
I
also
said
I
would
stop
the
recording
in
case
somebody
wants
to
say
something
at
the
end
like
an
announcement
or
something.
So
I
will
stop
the
recording
now.