►
From YouTube: JupyterLab Team Meeting - May 4, 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/co...
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
Okay,
welcome
to
the
may
4th
jupiter
lab
weekly
call.
Everyone
looks
like
today.
We
have
20
people
right
at
the
start.
That's
great.
I
will
warn
you
that
I
have
a
spotty
connection
and
at
some
point,
if
something
goes
wrong,
I'll
tether
to
my
phone,
but
if
I
freeze
somebody
please
start
talking,
but
with
that,
let's
get
started
so
first
on
the
agenda.
Today
we
have
frederick.
B
Hello,
hello:
I
will
try
to
be
not
too
long,
so
first,
some
announcements
we
have
released
jupiter
340
yesterday,
so
feel
free
to
try
and
report
any
back.
Hopefully
not
so
many
are
there.
Thank
you
for
everybody
that
contributed
to
that
one.
B
B
To
avoid
it
to
be
bumped,
so
how
can
I
explain
that
a
bit
clearer
so
basically
up
to
a
couple
of
days,
that
package
was
depending
on
the
translation
package,
but
that
primary
goal
of
that
package
is
just
to
provide
an
interface
for
downstream
extension,
providing
new
render
mime
and
the
trouble
of
having
translation
package
as
a
dependency
is
that
you
get
application
and
app
utils
as
dependency,
and
so
the
learn
tools
that
we
are
using
for
bumping
version
was
basically
bumping
that
interface,
even
if
we
don't
change
the
interface,
and
so
I
open
the
pr
to
break
that's
that
cycle
and
in
order
to
upgrade
that
version
only
if
needed,
and
so
the
the
question
is
that
remains
is
do
we
want
to
not
change
the
major
version
for
that
package,
or
do
we
want
for
four
to
bump
that
major
version
too?
B
B
The
main
idea,
it's
so
normally
for
v4,
it
was
decided
that
only
package
that
needs
to
be
pumped
will
be
bumped,
but
at
the
current
point,
like
all
package
has
been
done
for
like
major
version,
the
idea
was
to
not
bump
the
package
as
much
as
possible
for
avoiding
too
many
breakage
of
downstream
extension.
D
Yeah,
I
think
the
point
of
render
mime
interfaces
was
people
that
really
don't
want
to
interact
with
the
apis
at
all.
They
just
want
to
make
something
that
puts
javascript
on
the
page
in
response
to
mime
type
and
sort
of
forget
about
it.
There's
meant
to
be
a
low
barrier
to
entry
to
make
an
extension.
D
C
So
this
is
a
very,
very
unique
case.
Yes,
okay,
then
yeah.
Based
on
that
understanding,
I'm
sounds
fine
to
me.
A
So
I
misunderstood
and
I
thought
rendermine
interfaces.
The
package
was
a
lower
version
number
than
the
current
lab
version
because
of
that
exact
property,
but
does
render
mime
interfaces
track.
Major
jupiter
lab
versions,
even
if
the,
even
if
the
actual
apis
don't
change
so.
D
B
That's
that
was
very
likely
for
under
my
my
interface
to
bump.
A
B
Yep,
okay
and
I
think
the
goal
as
far
as
I'm
understood,
the
goal
is
to
go
that
direction
so
because
the
more
we
advance
and
the
more
the
could
get
matures,
normally
the
less
the
api
surface
changes
and
so
the
less
we
are
annoying
people
for
upgrading
their
extension,
because
most
of
the
api
is
the
same,
and
so
they
can
keep
using
the
old
version
go
ahead.
Steve.
D
How
the
way
we
handle
this
with
document
types
is
we
basically
inlined
portions
of
the
eye
document
type
or
whatever,
whatever
the
interface
was
into
randomize
interface,
so
like
so,
people
using
undermine
interfaces
could
still
use
that
api,
but
they're
not
depending
on
the
package,
which
then
depends
on
things
like
application,
so
might
be
something
similar
to
here
to
abstract
out
the
eye,
translation
interface,
that
is
in
this
package,
but
not
have
it
depend
on
translation
package
or
make
another
package.
That
is
just
the
interface.
A
Yeah,
that's
fair.
Carla
raises
a
point
in
the
chat
about.
Oh,
I
see
this
is
a
vulnerability
that
shows
up
in
the
render
mime
package,
so
the
render
mime
package
is
a
little
bit
more
like
the
other
packages
in
jupiter
lab,
in
that
its
versions
do
change.
B
A
A
A
Any
maybe
we
should
move
on
to
the
next
point
and
if,
if
anyone
has
anything
to
contribute
here,
they
can
look,
they
can
write
in
the
pr.
What
is
that
one?
Two,
four,
nine
three,
but
you
had
a
few
other
points
that
you
want
to
talk
about,
looks
like.
B
B
So
I
link
the
pre
as
open,
so
correct
me
if
I'm
wrong
david
or
if
I'm
saying
stupid
things,
but
basically
the
idea
is,
you
can
now
for
add
in
the
package
json
an
attribute
that
say
that
your
package
is
a
send
module
type
by
saying
it's
a
type
module.
B
E
You
know
it's
not
needed
anymore
because
of
an
experimental
option
in
nodes,
so
we
we
can't
afford
not
to
add
that,
but
we
need
to
have
the
type
module
in
the
package.json.
E
A
So,
okay,
you
tried
to
create
a
different
package.
That
package
depended
on
shared
models.
Then
you
tried
to
author
tests
using
jest
and
it
blew
up
because
the
shared
models
passed.
A
Not
just
no
directly
right,
okay
is
there
a
downside
to
doing
this?
Is
there
any
and
if
there
is
no
downside
to
doing
this,
should
this
be
on
every
package?
E
A
Okay,
so
all
packages
that
are
not
dash
extension
all
packages
that
might
feasibly
be
imported
by
someone
it
seems
like
we
should
make
it
as
easy
as
possible
to
import
them
in
as
many
ways
as
come
up
organically.
Like
you
weren't
doing
anything
weird,
you
were
just
authoring
a
package
that
depends
on
the
package
and
calling
it
with.
No
that's
not
a
crazy
thing
to
do
so.
It
seems
yeah.
It
seems
like
a
good
move
to
do
this.
A
Does
anyone
who
knows
about
this
stuff
like
is
there?
Are
we
walking
into
a
a
trap
here,
or
is
this
fine.
D
I
would
ping
jason
grout
on
the
issue,
he's
sort
of
the
expert
on
these
type
of
things,
and
then
I'd
also
say
this
is
a
good
candidate
for
the
the
integrity
script
to
just
put
it
into
all
the
different
repos
for
us.
We
have
to
it
for
new
packages.
E
Yeah,
let's
do
with
the
integrity,
update
and
but
I'll
ping
json
in
the
pr
anyway
draw
this
feedback
thanks
just.
F
E
B
So
let
me
make
my
screen
a
bit
bigger.
So
for
the
classical
one
you
can
have
a
widget
on
top
of
the
cell
for
editing
the
tags
or
like
you
can
specify
like
the
type
of
slideshows
and
so
in
classical
notebook.
There
is
no
sidebar,
so
there
is
no
such
a
such
a
widget.
So
for
v7
we
need
that
kind
of
features.
B
So
what
I'm
displaying
here
is
a
development
version
of
an
extension.
That's
called
jupiter
up
and
inside
toolbar,
and
the
question
was
raised
the
previous
goal
for
notebook
v7.
What
to
do
with
that
code?
Should
some
of
it
be
moved
to
official,
jupiter,
rap
organization
stuff
like
that,
zac
has
a
proposition
to
say.
Okay,
one
thing
that
could
be
interesting
is
to
bring
only
those
metadata
editors.
B
Should
we
bring
just
that
part
in
core
and
to
be
able
to
set
up
a
notebook,
v7
toolbar
with
the
same
code
base,
or
should
we
move
that
extension
or
a
simplified
version
of
it
under
the
jupyter
app
organization
for
with
that
features
and
make
it
as
separate
of
the
jupiter
of
core?
That's
that's
the
question.
B
G
Yeah
a
couple
things
I'll
start
with
the
ux
related
questions.
G
H
G
G
G
I
don't
know
that
it's
worse,
but
I
I
think
this
is
an
important
dimension,
that
for
for
regular
heavy
usage,
I'm
not
sure
the
exis,
the
classic
notebook
ux
is
what
we
want
to
emulate.
I
don't
know
what
a
better
idea
is,
but
I
I
want
to
emphasize
that
it's
not
clear
that
it's
the
optimal
one,
the
other
is
the
the
the
user
stories
that
we
have
in
the
the
jet
the
the
detail.
G
How
we're
gonna
go
through
with
notebook,
seven
jupiter
lab
4,
all
that
transition,
we're
pretty
clear
that
jupiter
notebook
7
will
have
sidebars
so
that
key
extensions
like
table
of
contents
and
so
on
will
still
work.
So
I'm
not
yeah,
I'm
not.
Quite
I'm
not
quite
sure.
I
understand
how
we're
saying
now:
it's
not
going
to
have
sidebars.
B
I
H
To
add
that
there
is
a
merge
request,
or
at
least
an
issue-
that's
not
sometimes
add
the
left
and
right
sidebars
to
the
class
to
notebook
7
instance.
This
is
inspired
by
work
that
I
had
started,
but
not
merged
in
for
retro
lab,
so
I'll
toss
out
a
plug
for
anyone
who's
interested.
If
this
is
a
need,
we
can
add
this
to
notebook.
7.
J
I
think
the
idea
with
notebook
7
was
to
not
have
them
displayed
by
default,
to
keep
the
classic
look
and
feel,
and
people
used
to
the
classic
notebook.
We
probably
not
want
to
use
the
sidebars,
so
they
will
look
for
something
like
they
had
in
a
classic
notebook
at
the
cell
toolbar,
and
they
could
of
course,
use
the
sidebars
when
we
add
them,
but
by
default
they
will
probably
not
be
even
aware
of
this
kind
of
gypsy
lab.
Like
features
yeah
the
beginning.
H
And
the
work
in
progress,
the
pull
request
associated
with
this
does
not
show
the
buttons
that
are
vertically
aligned
in
jupiter
labs.
So
even
when
we
add
that
you'd
have
to
make
a
positive
effort
to
even
show
those.
So
I
I
accept
that
the
ui
is
not
going
to
be
the
same.
B
We
should
do
our
best
to
make
that
material
still
valid
for
v7,
so
that's
mean
having
the
same
kind
of
workflow
having
a
menu
entry,
and
if
you
click
on
some
position,
then
that
will
add
some
kind
of
new.
That
was
the
wrong
button.
New
element
that
you
can
use
for
addition
of
the
the
metadata.
That's
that's
the
really,
the
the
the
need
or
the
features
I
would
like
to
cover
with
this.
G
So
I
I'd
like
to
just
point
to
the
original
text
of
the
jet,
where
we
detail
what
sort
of
the
supported
user
stories
and
decision
making
principles
that
we'll
use
for
making
these
decisions
and
similarity
with
notebook
with
classic
notebook
is
not
it's
not
the
top
principle
that
we
identified
and
voted
on
in
the
jet.
So
I
and
the
reason
we
put
the
those
decision
making
principles
in
there
was
to
prevent
us
from
having
to
from.
We
have
the
same
discussion
many
many
times
over.
I
So
what
we
talked
about
in
the
notebook
meeting
was
it
was
kind
of
presented
that
the
current
cell
b,
toolbar,
which
I
did
say
in
that
meeting-
I
want
to
give
a
shout
out
to
the
current
cell
toolbar.
That's
in
main,
it's
it
is
really
sweet.
The
ux
is,
is
really
really
great,
so
shout
out
to
the
group
that
worked
on
that,
but
we
were
talking
about
how
these
were
kind
of
competing
things.
I
One
of
them
really
was
attacking
kind
of
the
cell
metadata
and
the
other
one
is
like
really
common
functionality
like
moving
cells
up
and
down
copying,
pacing
and
so
on,
and
so
I
think
decoupling
that
would
be
good
so
that
we
could
really
have
these
as
two
separate
things
not
competing,
and
then
the
question
of
whether
or
not
to
bring
this
in
core
is
definitely
a
separate
discussion.
Then,
in
that
case-
and
I
think
that
you
know
I
don't-
I
don't
have
a
strong
opinion
on
that.
I
I
do
think
that
I
had
to
you
know
I
also
used
every
greater
so
maybe
as
a
counterpoint
not
to
disagree
with
you
ryan,
but
I
use
it
a
lot
as
a
as
a
teacher
too,
and
it
was
cell
tags,
for
example,
and
things
like
that
some
of
those
uis
having
them-
maybe
not
all
of
these,
but
some
of
those
on
the
per
cell
basis
is,
is
handy.
Like
you
do
find,
you
naturally
want
to
go
there
and
that's
where
you're
looking
for
it.
I
I
think
maybe
the
ux
on
how
that's
presented
and
you
know-
may
need
some
rethinking
and
and
so
on.
I
think
one
more
thing
is
isabella
could
probably
offer
a
little
bit
of
some
context
to
this
too,
when
when
markell
was
working
on
cell
tags,
one
of
the
cool
explorations
they
did
with
cell
tags
was
thinking
about.
I
How
do
you
add
color?
I
know
there
was
an
accessibility
question
here,
but
how
could
you
make
cell
tags
more
usable
in
the
sense
of
really
what
you
want
to
do
is
maybe
like
scroll
through
the
notebook
really
quickly
and
be
able
to
see
what
what
cells
might
be
related
based
on
their
cell
tag.
Right
like
these
are,
these
are
homework,
question
cells
or
whatever,
if
you're
in
the
envy,
greater
context,
and
if
they
were
all
you
know,
green
or
all
blue
or
something
you
could
really
distinguish
those
again.
I
There
was
next
accessibility
question,
but
having
the
cell
tool
cell
tags
right
there
in
the
ux
was
like
a
big
deal
for
for
envy
greater
users.
So
you
know
there
might
be
some
parts
that
we
we
can
rethink
and
and
merge
in
there,
but
I
do
think
we
want
to
keep
the
enhanced
cell
toolbar
and
the
current
cell
toolbar
as
really
solving
separate
issues
so
separate
questions,
and
then
whether
or
not
it
goes
into
core
could
be
a
a
second
leg.
To
that
conversation.
K
Adam,
I
just
wanted
to
add
something
I
really
like
about
about
vs
codes.
Interface
is
when
you
run
a
cell,
it
tells
you
how
long
it's
ran
and
presently
in
jupiter
lab.
That's
something
that
you
have
to
switch
on
and
it
doesn't.
Actually.
I
don't
think
that
that's
part
of
the
interface,
but
I
find
that
really
useful,
and
I
just
wanted
to
suggest
that.
Maybe
if,
if
that,
maybe
that
could
be
part
of
what
you're
talking
about
now,
it's
just
a
thought.
K
I
I
just
I
don't
know
if
anyone
else
likes
that,
but
I
I
find
it
like
it
gives
you
feedback
like
a
temporal
feedback
about
your
cell
running
it
rather
than
just
something
spinning
around,
and
it's
a
feature
I
liked
when
I
experienced
so
I
thought
I
should
just
suggest
that.
G
If,
if
that
interface
had
not
everything
I
mean
a
great
example
would
be
when
someone's
using
nb
greater,
it's
likely
they'll
just
need
cell
tagging
and
not
the
slide
ui
and
part
of
the
visual
clutter
and
fatigue
of
using
it
is
the
fact
that
it
you,
you
can't
disable
and
enable
individual
components
of
that.
You
get
the
whole
thing.
J
G
A
At
the
top
of
this
call,
I
proposed
that
every
bullet
point
only
take
five
minutes,
but
we've
been
talking
about
these
bullet
points
for
half
an
hour,
but
thankfully
it's
not
just
stuff.
That
is
fred
and
it
actually
extends,
but
we
should
probably
move
down
the
agenda
because
we'll
never
finish
otherwise.
B
C
Yeah,
hopefully
this
can
just
be
a
somebody
knows
the
answer
to
this
and
just
or
points
me
in
the
right
direction.
We
move
on
I'm
attempting
to
use
this
new
extensions
in
dev
mode
flag.
Well,
new
is
relative
3.0
new
to
run
both
third-party
extensions
in
dev
mode
and
core
and
dev
mode
at
the
same
time,
but
our
third
party
extension
disables
the
launcher
using
this
pagecontrol.json
feature,
but
that
doesn't
work
in
this
mode.
C
They
both
end
up
being
installed,
nothing
gets
disabled
and
they
bang
heads
against
each
other
and
explode.
So
I
was
wondering
if
somebody
with
a
familiarity
with
this
flag
and
how
it
works,
could
either
tell
me
how
or
just
straight
up
tell
me
it's
not
possible,
so
I
don't
keep
attempting
to
try
it.
F
C
To
answer
it
best,
so
a
good
example
is,
if
I'm
making
a
change,
for
instance
in
like
the
file
editor
in
core,
that
I
need
to
use
in
my
third-party
extension
that
works
with
the
file
editor,
and
so
I
am
trying
to
develop
them
both
at
the
same
time,
but
my
third-party
extension
also
disables
and
replaces
launcher
so
it's
no
longer
able
to
disable
launcher.
So
when
my
launcher
gets
enabled
it,
they
have
the
same
name
and
they
butt
heads.
G
F
Could
just
remove
the
core
extension
from
the
list
in
your
dev
area
and
not
use
the
disabled
thing,
but
actually
just
modify
the
jupiter
lab
source
to
remove
it
from
the
the
core
extensions
that
it's
pulling
in
in
the
application?
I
don't
know
if
that
would
be
in
the
state
staging
area,
possibly
I
think
steve
last
right.
He
would
be
the
person
to
answer
this
if
he
was
here,
I
think
steve
dropped.
F
If
this
is
just
for
temporary
dev
work
like
that,
where
you're
modifying
stuff
in
the
drupal
lab
report,
I
think
you
can
modify
whatever
config
file
is
pulling
in
the
core
extension
and
just
don't
pull
it
in.
C
So
but
yeah
jeremy
just
mentioned
opening
an
issue
I'll
open
an
issue
because
it
sounds
like
this
is
something
nobody
really
knows.
The
answer
to
so.
A
It
also
sounds
like
a
bug
unless
there
was
some
by
design
reason
that
disabled
extensions
were
being
explicitly
ignored
in
dev
mode.
It
sounds
like
a
bug.
F
F
C
A
Yeah
I
mean
it
seems
like
you
know,
let's
say
you
are
looking
to
build
a
totally
different
launching
experience
and
if
it's
like,
if
you
reaches
a
certain
point,
you're
happy
with
it,
then
you're
going
to
propose
it.
It
sounds
like
very
much
you
want
to
do
exactly
what
alex
is
trying
to
do
instead
of
working
from
within
the
code
base,
necessarily
unless
yeah.
G
A
C
And
I'll
flag,
steve
and
jason
since
they're,
the
ones
who
did
most
of
the
build
system
work
to
get
their
opinions
on
it
since
they're,
both
not
in
this
meeting
today.
A
H
Okay,
yeah,
we
had
a
there's
a
few
things
that
I
wanted
to
talk
about
briefly
one
is
I've
been
working
on
trying
to
pull
the
cal
poly
interns
jupiter
lab
comments
which
ends
with
an
s
repo
into
core?
H
There's
a
team
compass
issue
about,
should
we
archive
the
old
commenting
repo,
which
hasn't
been
touched
in
about
two
years
in
favor
of
pulling
the
project
entirely
into
the
jupiter
lab
project
space?
So
just
wanted
to
draw
attention
to
that.
We
can
continue
the
com.
The
commentary
on
that,
unless
anybody
has
anything
to
add
here
on
the
call.
C
H
Commenting
is
the
one
from
2020
comments
with
an
s
is
21..
We
would
pull
that
in
as
a
project
and
then
separately,
there's
a
issue
that
I'm
working
on
to
actually
pull
that
into
jupiter
lab
core.
But
that's
not
that's
outside
the
scope
of
the
team
compass
issue.
H
A
Yeah
so
one
day
soon,
jupiter
lab
core
should
ship
with
comments
as
a
feature
and
the
steps
to
get.
There
are
pick
among
the
two
existing
commenting
extensions
which
one
you're
going
to
build
on
top
of
and
the
more
modern
one
is
using
yjs
and
the
crdt
stuff.
So
it
seems
like
a
better
place
to
start,
but
that's
in
jupiter,
cal,
poly,
so
step
one
would
be
bring
that
over
and
make
it
jupiter
lab
github
org
step.
L
But
in
the
past
haven't
we
had
discussions
about
like
preserving
the
history
of
rupa,
so
I
I
understand,
if
you're
archiving
the
existing
repo,
it's
not
going
away,
but
is
there
any
way
that,
like
I
guess
my
thought
is
that
doesn't
show
any
relationship
between
the
two
and
I
from
what
I
understand
there
isn't
any
development
relationship
but
like
from
a
user
perspective
they're
both
commenting,
you
know,
would
you
like?
Would
that
be
confusing,
because
the
archive
repo
will
still
appear
like
commenting
versus
comments?
Did
that
make
any
sense?
H
H
G
H
L
I
think
I
think
vdr
is
right
too,
about
keeping
the
name
being
important
so
that
you
get
you're
not
getting
the
dedicated
package
by
accident.
A
A
F
Yeah,
so
if
it's
bringing
into
court,
it
might
make
it
irrelevant.
But
it's
you
know,
as
we
did
for
notebook
7,
is
that
we
have
a
new
major
version
where
we
completely
override
most
of
the
code
right.
A
A
A
F
A
I
don't
know
if
there
is
a
process
here
outside
of
this
is
a
decision-making
thing
where
we
either
know
via
consensus,
or
we
know
via
vote,
I'm
only
trying
to
figure
out
whether
we
have
consensus.
How
about
there
is
that
team
compass
issue
jason
may
be
on
that
issue.
You
can
say
at
this
call:
you
raised
it.
H
Okay,
yeah:
how
about
this
once
we
have
the
minutes
published
on
on
github
for
this
meeting,
I
can
like
cross-link
the
team
compass
145
to
that
just
to
kind
of
collect
that
oh.
A
H
Council,
you
got
it
okay,
I'll
do
that.
Probably
later
today,
okay,
I
know
we're
getting
close
to
the
top
of
the
hour
two
other
things
I
wanted
to
ask
about.
Hopefully
these
are
brief.
There's
a
long-running
issue
that
a
gentleman
named
tomas,
who
I
don't
know
if
he's
on
the
call
opened
about
two
months
ago.
We
at
one
point
closed
it,
but
he
reopened
it
frederick
and
I
have
tried
to
kind
of
understand
tomash's
issue,
the
frankly.
H
H
H
So
please
take
a
look
when
you
get
chance.
One
other
question:
this
is
kind
of
geared
towards
isabella
here.
When
is
the
next
jupiter
community
call?
Because,
as
discussed
at
the
previous
meeting,
we
now
have
pretty
much
every
tuesday
at
8
a.m.
Pacific
is
now
booked
with
something.
Next
week
we
have
the
security
meeting,
which
is
every
two
weeks
and
then
the
following
week,
or
maybe
not.
We
have
this
no.
H
Yeah
we
have
this
notebook
extension
migration
office
hours,
which
we
had.
I
think
for
the
first
time
yesterday
and
it's
going
to
be
like
may
3rd
may,
17th
may
31st
etc.
So
I
know
we've
we've
kind
of
played
around
with
different
times,
but
I
don't
know
when
the
next
one's
going
to
be
I've.
L
Not
publicly
committed
to
a
single
time.
My
my
current
plan,
though,
is
to
try
for
the
alternating
thing
that
people
want
anyway,
and
so
my
thought
with
that
is
the
well.
I
have
to
look
at
the
time
zones.
There
may
be
one
that
is
like
a
kind
of
early
morning
for
west
coast.
Just
since
I
know
that
was
the
group
that
was
probably
most
irked
by
them
by
the
april
community
call
time
and
then
one
that's
more
afternoon.
That's
my
current
plan,
but
I
have
not
set
a
current
time.
L
I
have
to
say
like
I
am,
I
am
mildly
disheartened
by
the
state
of
the
account.
Like
I'm
glad,
people
are
having
meetings,
but
just
because
we've
had
this
time
slot
for
a
while.
So
I'm
trying
to
sort
out
something
that
I
think
is
sustainable,
because
I
would
like
the
calls
to
keep
going
and
so
far
nobody
else
has
said
they
want
to
host.
So
that's
my
main
concern
but
yeah.
Sorry,
I
don't
have
a
single
time
for
you.
I
I'm.
L
H
I'm
not
asking
to
put
you
on
the
slot
on
the
spot
right
here
and
now
to
commit
to
something.
If
you
want
to
continue
this
by
email
or
on
github,
that's
fine.
I
will
be
out
of
town
on
vacation
just
after
memorial
day
for
a
week,
but
otherwise
my
calendar
is
generally
free.
Do.
L
F
H
There's
some
there's
some
back
and
forth
in
the
chat
that
suggests
that
the
community
call
might
display
something
else,
in
which
case
you
know
we'll
we'll
deal
with
that
again,
like
I'll
follow
up
with
you
separately
next
week.
If
we
haven't
had
a
conversation
about
that,
but
at
the
same
time
I
know
there's
a
few
other
folks
who
want
to
raise
things
up
so
I'll
yield
my
time
to
darien
who's.
Next
on
the
agenda.
A
Thanks
just
one
last
point,
I
think
the
biggest
proxy
for
whose
call
should
have
priorities
how
many
people
show
up
more
people
show
up
to
the
community
call
than
the
zero
people
who
showed
up
for
office
hours
yesterday.
So
all
the
people
who
showed
up
for
office
hours
yesterday
were
on
the
supply
side.
There
were
none
on
the
demand
side,
so
really
anytime.
Those
calls
are
overlapping.
I
think
the
community
call
wins
for
sure.
A
Okay,
so
I
opened
a
small
pr
to
lumino,
adding
a
signal
to
split
panel
fred
approved
it.
I
just
wanted
to
ask:
I
don't
know
how
to
release
versions
of
luminol.
Does
someone
on
this
call
know
how
to
do
that
and,
if
possible,
could
someone
please
do
that
because
there's
a
piece
of
code
in
jupiter
lab?
That's
that
I
meant
to
deprecate.
I
think
in
2017
it's
still
there,
and
this
would
enable
me
to
remove
that.
A
Use
the
releaser,
oh,
I
probably
have
the
right
to
I
just
don't
have
the
knowledge
to
so
maybe
you
and
I
could
basically.
B
A
This
then
cool
all
right
great.
A
I
think
the
only
person
on
this
call
that
this
might
affect
is
martha
actually,
because
I
think
she
also
used
the
same
split
panel
for
the
setting
editor,
because
the
so
so
the
gist
of
this
change
is
that
when
they
handle
when
you
resize
a
split
panel,
this
will
emit
a
signal
and
the
reason
I
wanted
a
signal
was
so
that
I
could
use
that
for
state
restoration
to
remember
where
you
left
it
when
you
refresh
the
page
split
panels
by
default,
don't
support
that
and
don't
give
you
a
way
of
knowing
when
that's
happened,
and
so
this
will
add
that
on
the
luminal
side
and
then,
if
you
want
to
use
that
signal
to
remember
the
state
of
your
split
panel,
you
can
okay
thanks
david.
E
Yes,
I
just
wanted
to
mention
briefly
the
progress
that
has
been
done
in
the
front
of
collaborative
editing
in
jupiter
lab.
So
there
is
this
pr
that
is
open
for
review.
Basically,
it's
using
more
of
a
wi-fi,
which
is
the
pattern
bindings
for
wires,
which
is
a
rust
implementation
of
ygs.
Let's
say
that
we
use
in
the
front
end,
so
now
we
can
do
more
things
in
the
back
end
and
this
pr
loads
files
from
the
back
end
and
also
auto,
saves
files
from
the
from
the
backend.
E
So
it
is
supposed
to
solve
a
lot
of
issues,
in
particular
regarding
documents
that
could
have
been
erased.
Remember
an
issue
opened
by
feminism
about
that.
I
can
just
make
a
quick
demo
just
to
give
you
a
feeling
of
how
it's
working
so.
E
E
E
H
E
G
How
are,
how
are
no
outputs
getting
into
the
document
model?
Are
they
being
sent
through
the
traditional
websocket
channel
to
the
front
end
and
then
persisted,
or
are
they
being
sent
directly
to
the
the
yjs
back
end?.
E
So
it's
also
synchronized
through
the
wedges
back
and
it's
a
shared.
It's
a
shared
property
of
the
document.
G
E
Thank
you,
I'm
actually
thinking
about
that.
I
don't
know
I
I
would
have
to
think
a
bit
more
about
that,
but
maybe
maybe
it
would
synchronize
automatically.
Also
I've
not
looked
at
it.
So
I'm
not
sure
about
what
I'm
saying
so.
Basically
yeah
the
user
is
doesn't
have
to
to
care
about
saving
the
document
anymore.
It's
it
behaves.
Basically
like
google
docs
obvious
code.
You
know
that's
the
goal.
E
Yeah,
so
it's
it's
not
implemented
yet,
but
yeah.
It's
definitely
on
the
roadmap.
I
think
it.
It
collides
a
little
bit
with
the
checkpoints
that
we
have.
Currently,
I
don't
think
they
make
sense
anymore.
Once
we
have
all
these
all
wi-fi
very
well
integrated,
I
think
maybe,
but
that
that's
that
has
to
be
discussed.
E
Maybe
we
will
just.
We
won't
save
the
source
of
the
document
in
the
wi-fi
nba
file.
I
mean
it's
a
bit
disruptive,
but
maybe
it's
going
to
be
an
opaque
binary
file
that
won't
be
visible
directly,
but
we
would
need
a
tool
to
to
look
at
it
and
all
the
information
about
the
history
of
the
file
would
be
stored
in
there.
G
Yeah,
I
don't
want
to
think
about
how
we
want
to
handle
the
checkpointing.
Ironically,
when
we
implemented
the
original
checkpointing.
We
had
already
been
talking
about
real-time
collaboration,
and
I
think
we
said
at
the
time.
Well,
we
don't
have
real-time
collaboration
yet
we'll
temporarily
checkpoint
in
this
more
pedestrian
manner
until
we
have
real-time
collaboration.
So
it's
it's
taken
us
a
long
time,
but
I
don't
know
we'll
have
to
think
about
how
to
deprecate
or
what
to
do
with
existing
checkpointing.
A
Yeah
awesome
thanks
for
the
demo,
okay,
isabella.
L
Yeah
we're
at
time
so
sorry,
real,
quick
just
in
15
minutes
we're
gonna
have
the
jupiter
lab
accessibility
call.
I
forgot
to
put
it
on
the
top,
but
everyone's
welcome
we'll
talk
about
some
new
adventure
thanks.
A
Awesome,
thank
you.
I
think
this
markdown
conversation
is
gonna
have
to
happen
next
week
and
I
think
I
might
have
to
get
better
at
time
management.
Sorry,
everybody,
I'm
gonna,
stop
the
recording
in
case
there's
anything
last
minute.
We
need
to
say:
okay.