►
From YouTube: JupyterLab Weekly Dev Meeting, December 16, 2016
Description
Meeting of the JupyterLab development team, December 16, 2016.
Meeting Notes: https://jupyter.hackpad.com/JupyterLabNotebook-Weekly-Meetings-UUJ3gIQ3iBS
A
B
Just
been
continuing
work
on
the
state
restoration
stuff,
there
was
a
bug
that
wasn't
visible.
Unless
you
had
your
console
open,
that's
now
resolved,
but
more
fundamentally
you
know
it
just
went
in
a
couple
days
ago.
It
makes
it
a
lot
simpler
for
plugin
authors
to
take
advantage
of
state
restoration,
but
since
then
I've
had
sort
of
a
change
in
the
model
that
that
restoration,
the
the
lifecycle
demonstrations
been
Apollo
team
and
I
talked
through
this
yesterday.
Basically,
the
idea
is.
B
Your
plugin
author
and
you
are
going
to
be
adding
plugins
to
adding
widgets
to
the
application
shell.
If
you're
going
to
do
that,
if
you're
not
just
writing
some
sort
of
plugin,
that's
meant
to
be
used
by
others,
then
you
have
a
responsibility
to
hook
into
layout
restoration.
So
the
way
you
do
that
is
each
widget
that
you
create.
You
add
it
to
an
instance
tracker
and
you
import
the
global
since
restore
and
just
pass
your
tracker
into
that
and
you're
done.
The
only
work
you
have
to
do
to
upkeep
it
is.
B
Whenever
new
widgets
are
created,
you
make
sure
you
add
them
to
your
tracker
and
if
something
changes,
one
of
your
widgets,
you
call
tracker
dot,
save
and
give
it
your
widget
so
that
it
updates
itself.
So
there's
basically,
two
or
three
things
that
you
need
to
take
care
of
it
and
layout
magically
works
for
you.
Now
what
the
state
was,
what
the
instance
restore
does.
Is
it
takes
all
of
those
trackers
that
the
plugins
gave
it
waits
for
all
of
them
to
be
ready
and
have
rhian
Stan
Shih
ated
their
widgets?
B
Once
all
of
those
widgets
are
reinstated,
then
it
can
take
the
next
step
and
say:
okay,
they're
all
restored.
Now
application
go.
We
lay
out
all
the
things
based
on
the
saved
dehydrated
stick.
So
then,
the
application
internally
is
going
to
have
some
logic
that
haven't
yet
written
where
it
will
take
all
these
widgets
that
it
knows
all
this
information
about,
because
they've
been
staved
and
it's
going
to
relay
them
out
in
the
correct
places
and
the
application
will
implement.
C
B
Restored
promise
in
case
somebody's
waiting
for
the
application
to
be
restored
before
they
do
stuff,
so
the
applications
can
have
two
promises.
People
can
wait
for.
One
is
called
started,
which
just
means
all
the
plugins
exist
and
one
is
called
restored,
which
means
all
of
the
layout
has
been
correctly
we
laid
out,
and
so
that
is
that
new
life
cycle
is
what
I'm
working
on
now.
So
the
version
that's
published
recently
has
a
thing
inside
of
called
layout
restore,
but
that's
gone
because
really
layout
restoration
is
a
responsibility
of
the
application.
B
B
Well,
today's
my
last
day
for
December,
so
it's
not
happening
until
early
January,
but
you
probably
won't
notice
very
much
because
most
of
the
restorations
already
sort
of
happening
at
the
best
level
important
now,
except
for
sidebars.
So
all
you'll
really
notice
when
this
new
models
in
place
is
that
the
sidebars
will
also
save
their
state
because
until
phosphor
give
me
the
way
to
rehydrate
the
doc
panel
you're
not
going
to
see
the
full
manifestation
of
this,
but
actually
the
groundwork
that
I'm
doing
now
is
a
necessary
step
for
that
anyway.
B
The
other
other
consideration
here
is
I
want
to
make
sure
that
this
is
really
super
fault,
tolerant,
because
well,
because
of
the
obvious
reason
right,
if
you
refresh
your
page
and
stuff
is
worse
than
before,
that
is
really
annoying.
So
I
want
to
make
sure
that
the
worst
possible
thing
that
happens
is
that
maybe
something
doesn't
reopen
up,
but
never
any
errors,
and
hopefully
not
even
stuff,
not
opening
but
but
yeah.
So
so
there
are
some
spots
where
I
think
so.
For
example,
I
rely
on
local
storage.
B
Local
search
can
be
corrupted
by
others,
so
I
think
I
need
to
be
defensive
about
what
I
read
from
there.
I
already
did
an
audit
of
all
the
commands,
but
as
people
write
new
commands,
they
need
to
make
sure
commands
are
promises,
so
they
need
to
make
sure
those
promises
are
actually
returning
things
if
they
need
to
be
returning
things.
So
if
your
command
calls
another
command,
make
sure
you
return
that
command.
Does
that
commands
also
a
promise,
because
a
restoration
completely
relies
on
promises?
D
What
one
question
I
have
I
could
imagine
some
plugins,
don't
themselves
create
widgets,
but
they
monitor
the
creation
of
other
widgets
and
trigger
actions
based
on
those
one
example
would
be
the
real
time.
Collaboration
plugin,
which
would
ya
watch
for
notebooks
or
text
areas
that
are
created
and
once
they're
created,
would
enable
real-time
collaboration
for
them.
Well.
That
rehydration
process
trigger
the
right
events
such
that
those
other
things
can
happen
well,.
B
I
would
imagine
what
you
probably
do
in
that
situation
is
say:
wait
for
the
app
restored
promise
to
resolve,
and
then
you've
already
imported,
say
the
editor
widget
tracker
and
do
tracker
dot
for
each
and
then
for
each
of
those
widgets.
You
can
do
something
and
know,
what's
in
the
right
spot,
so
I
think
every
step
should
be.
E
Brian,
that's
a
that's
a
good
question.
I've
also
I've
been
trying
to
keep
an
eye
on
with
Darien's
doing.
For
that
reason,
I
don't
have
a
good
story
on
that
right,
but
for
instance,
if
it
happens
quickly
enough
you're
you're,
oh
off
token
may
still
be
valid,
and
then
that
should
be
doable.
But
if
it
doesn't,
you
know
it's
possible
that
you
would
need
to
reauthorize
another
such
thing.
So
it's
probably
there's
probably
not
going
to
be
a
way
to
do,
make
it
100
percent
bulletproof,
but
you
could
probably
get
most
of
the
way
there.
E
B
Another
thing
is
that
it
might
even
be
the
case
that
arm
right
now,
it's
up
to
the
plug
and
author
to
give
me
a
function
that
generates
a
unique
name
for
each
widget
and
a
function
that
generates
the
args
necessary
to
re-launch
that
widget
and
the
command
to
use.
So
it
might
actually
be
the
case
that
the
Ark's
themselves
will
contain
all
the
state
that
the
real-time
collaboration
needs.
B
It
might
have
the
token
in
the
arts
or
whatever
that
might
be
what
actually
gets
rehydrated
so
that
you
won't
have
to
do
a
bunch
of
work
after
stuff.
Is
there
it'll
be
upon
instantiation
that
the
work
is
done?
It's
not
clear,
I
mean
I,
think
it'll
be
different
by
a
use
case,
but
every
stage
is
over
yep
fantastic
I.
A
B
A
B
Yeah,
well,
no,
not
even
that
it's
just
that
for
this
particular
use
case,
it
actually
seems
like
promises
are
nicer,
because
a
sink
and
a
way
are
much
more.
They
seem
better
for
unitary
actions.
This
is
specifically
I,
want
multiple
promises
and
I
want
to
see
that
game
better
than
also
the
es5
code
that's
generated
by
that
is
just
impossible
to
debug.
I
would,
I
would
say
for
as
long
as
our
compilation
target
is
the
s5.
That
seems
like
a
not
great
thing
to
encumber
ourselves
with,
like
once.
We.
A
A
Why
and
I
mean
ack,
wait
doesn't
mean
promises,
go
away,
they're
just
syntactic
sugar
on
top
of
promises.
So
so
I'm
saying
from
the
point
of
view
of
plug-in
authors
using
these
api's
that
have
promises
that
might
be
simpler.
Once
we
have
a
secret
wait
but
I
agree,
it's
not
a
silver
bullet.
I
was
playing
run
with
it,
thigh-high
widgets
and
there's
a
lot
of
places
where
I
thought
oh
cool.
We
could
use
a
scene
k,
wait,
oh
wait!
It
doesn't
really
help
us
any
and
it
just
complicates
that
go
to
a
little
more.
A
F
Okay
in
general,
just
trying
to
keep
up
with
data
issues.
Refactoring
writing
tests
were
there
weren't
any
improving
that
technical
debt.
As
we
approached
beta
a
couple
issues
for
discussion
as
as
I
was
cleaning
up
the
implementation
of
the
code,
mirror
code,
editor
implementation
and
writing
tests
for
that
and
I
realized
way
too
late
in
the
game
that
the
code
mirror
doc
object
actually
contains
things
that
are
closely
tied
to
a
specific
editor
and
would
the
verification
being
there
you
can't
have.
F
Our
use
case
was
to
be
able
to
basically
show
show
your
own
cursors
and
then
other
people's
cursors
as
the
as
the
another
marker.
But
you
can't
do
that
the
way
the
doc
is
structured,
so
taking
a
step
back,
I
thought.
Okay,
what's
the
least
we
can
put
the
model
so
that
it
will
work
for
any
editor
and
in
doing
that,
it
turned
out
to
be
just
what
curses
are
associated
with
it
and
then
let
who
owns
them?
F
You
come
out
in
the
wash
the
value,
the
actual
observable
string
and
then
the
mime
type,
so
that
they're,
what
define
the
model
and
if
we
do
that,
then
a
cell
model,
as
well
as
a
document
model,
could
implement
those
interfaces
and
then
those
would
those
could
be
consumed
by
the
code
code,
editor,
implementation
and
I
from
a
class.
In
this
perspective,
we
only
have
now
we
have
avoided
a
new
book,
its
string
that
we're
coming
around
don't
for
larger
documents
with
in
memory
we
already
saved
there
and
conceptually
collapses
the
number
of
distinct
objects.
F
We
have
so
I
think
it's
actually
a
win
from
doing
this
leave
Leave
the
code
mirror
pieces
in
the
editor
part
and
make
the
model
a
more
editor
agnostic
thing
and
I
think
is
I.
Think
it
actually
will
be
a
wind.
So
if
anyone
wants
to
chime
in
on
that,
I
ask
for
opinions
on
the
issue
there
I
linked
it
on
the
heck
pad.
So
what.
D
D
A
F
A
F
So
this
it's
unfortunate
I
think
in
the
end,
it's
all
in
okay,
next
thing
else
related
to
editors
is
the
way
Microsoft
has
packaged
Monaco,
it's
it's
it's
fine,
but
it's
stuck
in
the
old
window.
Dot
defined
is
available
and
I
just
feel
that
a
question
I'm
Boca
this
morning
where
but
we're
not
outta
fine,
was
wrecking
something
they
were
trying
to
do
in
the
notebook.
I
really
think
we
don't
want
to
have
that
on
the
page.
A
F
A
A
F
A
A
F
Yeah
and
then
the
last
thing
is
almar
had
a
PR
proof
of
concept
to
be
able
to
you
flex
plug-in.
So
you
could
author,
a
jupiter
lab
plugin
from
flex,
and
it
turned
out
to
be
the
nuggets
that
were
needed.
The
changes
were
the
ability
for
a
Jupiter
live
extension
to
give
back
and
fig
data
to
the
page,
and
we
had
already
ate
dan
allen
had
already
sorted
it,
a
workaround
for
Jupiter
hub
to
be
able
to
get
config
data
onto
the
page.
So
this
is
data.
F
F
Flexing
that
dbl
dad
handlers
and
the
existing
method,
for
that
was
to
do
a
server
extension,
but
there's
no
reason
that
a
lab
extension
couldn't
couldn't
also
provide
a
hook
for
that
as
part
of
its
lab
extension.
So
if
it's
a
python-based
live
extension
as
he
building
to
provide
for
big
data
and
it
can
get
a
handle
on
the
tornado
app
to
be
able
to
add
handlers
to
it,
don't
flex
would
do
both
of
those
things.
So
it
could
be
that
we
decide
know
later
on,
though
these
are
distinct
things.
F
D
It's
I'm
if
what
you're
proposing
is
to
an
out
enable
a
jupiter
lab
extension
to
modify
the
server
by
its
installation,
I'm
probably
not
I,
don't
think.
That's
a
good
idea.
Okay,
that's
very
now.
One
thing
that
it
does
exist
is
a
single
Python
package
and
declare
a
server
extension,
a
lab
extension,
even
an
NB
extension,
and
so
there's
there's
nothing
preventing
someone
from
having
a
single
Python
package
that
installs
all
of
those
types
of
things.
D
A
A
F
Not
that
that
youse
was
what
prompted
me
to
make
it.
A
separate
thing
is,
but
I
can
see
where
you're
coming
from
Brian,
whether
they
should
be
separate
things.
So
it
could
be
that
it's
a
lab
server
extension
yeah,
but
the
issue
is
you
and
the
reason
I'm
giving
back
a
tornado
app?
Is
that,
depending
on
how
you
launch
super
lab
you're,
either
getting
a
notebook
app
or
a
lab
at
yeah?
That
was.
A
D
D
B
D
B
A
A
D
F
F
E
That
it's
sort
of
a
queue
of
things
with
strings
in
them,
though
that's
it
currently
looks
terrible,
but
more
or
less
works,
so
I've
been
forging
on
with
the
notebook
and
yesterday
got
a
a
real-time
notebook
working
which
which
Jamie
can
confirm.
So
at
this
point,
I
think
there's
a
an
API
which
kind
of
works.
E
I
would
say
it's
not
done,
but
it
kind
of
works
so
I'm
going
to
start
ripping
out
some
of
the
Google
specific
stuff
and
and
submit
a
were
compromise
API
for
what
a
real-time
plug-in
would
look
like
in
the
next
day
or
two.
So
if
I,
if
people
are
not
on
vacation
and
here,
to
get
some
feedback,
that'd
be
useful
in
that
it's.
A
Awesome
I
gave
a
talk
at
NYU
at
Spencer,
Lions,
intruder
data
science,
essentially
class
and
talked
about
Jupiter
showed
them
five
seconds
to
Jupiter
lap
and
the
first
question
that
they
asked
is:
can
we
do
collaborative
stuff
like
Google
talks?
His
head?
We've
got
those
neck
working
on
this
right
now,
great.
B
E
E
A
Usually,
along
those
lines
in
sage,
math
cloud,
I,
I,
believe
their
chat
is
sort
of
a
per
document
chat
and
then
it's
saved
with
the
document.
So
anybody
that's
collaborating
on
that
document
can
open
the
Chattan
and,
and
so
it
gives
a
sort
of
a
topic
of
focus
for
the
chat
and
then
and
then
it's
preserved.
It
sounds
like
what
the
chat
that
you're
talking
about
is
really
more
just
a
playground
for
collaborative
stuff,
but
but
if
we
could
associate
that
shot
with
particular
items
and
then
save
it
I,
let
it
back
up
again.
D
E
So
the
way
that
I've
set
it
up
is
that
I've
tried
to
define
a
more
abstract
interface,
who
the
real
time
collaboration,
so
that
I
mean.
Ultimately,
the
goal
is
to
also
include
our
own
implementation,
which
can
talk
through
the
server
and
have
something
like
a
like
a
Jupiter
hub
implication
of
the
same
thing,
so
I've
been
trying
to
target
both
of
these
at
the
same
time.
So
right.
E
Way
it
works.
Is
you
spin
up
a
handler
which
gets
associated
with
a
document
either
a
document
or
you
know
some
other
contents
model,
because
not
everything
is
backed
by
a
file
and
each
document
then
describes
itself
says:
I
want
a
real-time
version
of
a
string.
I
want
to
real-time
version
of
a
vector
and
tells
the
handler
what
it
wants,
and
so
that's
that's
the
abstraction
that
I've
been
working
with,
and
so
that
handler
currently
have
a
an
implementation
of
the
Google
version
of
the
handler.
But
you
could
do
other
things.
Ok,.
D
And
then
so,
my
next
question
is
what
it
makes
sense
to
specify
the
structure
of
the
model
using
a
formal
JSON
specification
and
so
that,
basically,
to
have
a
declarative
representation
of
a
particular
real
time
model
that
that
handler
API
can
consume
and
produce
a
real
time
model.
That
has
that
specification
that.
E
Would
be
certainly
interesting,
I
mean
possibly
I'd
be
curious.
To
I
mean
we
can
we
can
take
a
look
at
it
and
talk
more
through
it.
I'd
like
to
get
I'd
like
to
get
what
I
do
have
in
front
of
everybody's
eyes,
yeah
and
I'm
right
right
now.
I
can
get
more
granular
about
it
with
the
with
the
notebook
model
that
I've
got
up
and
running
every
time
you
make
a
change,
it's
sort
of
pushing
the
full
JSON
blob
of
the
cell
back
and
forth
across
the
network,
and
we
can.
D
Is
that
be
the
core
data
types
like
an
observable
strain
or
observable
list?
A
pretty
invariant
like
there's
going
to
be
something
like
that
in
any
real
time
back
end
and
how
the
front
end
handles
those
objects
may
be
different,
but
the
abstractions
I
think
are
really
sort
of
fairly
Universal.
I.
Think.
A
E
D
That's
yeah
hook,
hang
up
to
nested
trees
of
collaborative
observable
objects.
Is
that
that's
definitely
the
hard
part?
No
and
I
want
to
be
clear.
I
like
I
think
what
you're
doing
is
really
spectacular
and
it
sounds
like
incredible
progress
and
yeah
I.
Don't
please
don't
misunderstand
I'm,
not
downplaying
that
I
yeah
I.
A
A
I've
been
working
on
ipad,
widgets
and
so
is
sylvan
word.
We
decided
in
the
in
the
end
to
rewrite
the
tab
in
accordion
widgets
as
true
phosphor
widgets.
When
we
were
realizing
there
was
a
lot
of
sort
of
mixing
of
trying
to
deal
with
phosphor
from
the
ipad,
widgets
code,
etc.
So
what
we
did
is
we
have
a
tablet,
an
accordion
widget
and
looking
at
other
widgets.
D
It
would
probably
be
good
if
someone
else
could
take
the
lead
on
at
least
heading
up
the
API
sort
of
the
code
side.
Of
of
that,
obviously,
I
don't
think
we
need
to
have
API
stability
for
the
beta,
but
I
know.
There's
a
lot
of
ongoing
work.
That
sort
of
at
the
level
of
the
AP
is
that
we
probably
do
want
to
have
settled
by
the
beta
and
I'm
just
not
up
on
that.
But
if
I
don't
know
who
my.
F
F
A
F
You
all
yeah
I,
once
the
editor
part
is
settled.
The
the
cell
editor
specifically
I,
was
going
to
use
the
Monaco
PR
the
tease
out
what
we
can
factor
out
of
that,
because
there
they're
actually
wanting
to
provide
their
own
completion.
Widget
things
like
that
things
around
editor
are
really
all
that's
remaining
API
wise
for
beta
and
then
for
me,
the
other
beta
major
issue
is
lab
extension
compatibility.
So
we
have.
We
have
been
issue
tracking,
that
okay.
D
F
This
is
the
skinny
is
we
did
do.
We
did
make
an
attempt
at
that.
The
problem
is
c'mere,
the
run
mode
doesn't
handle
the
gutters
of
the
line,
numbers,
that's
right
and
there's
no
automatic
way
to
get
the
information
to
match
the
style
that
was
applied
to
those
things.
So
I
went
down
the
path
of
trying
to
recreate
the
gutters
myself,
but
I
was
I
was
having
a
hack
in
the
private
elements
tiles.
In
order
to
do
that
now,
this
is.
A
F
A
Visibly
alter
it
so
I
would.
What
we
do
now
is
for
the
particularly
intensive
operations
like
the
resizing
that
caused
a
complete
code
me
refresh.
We
throttle
those
quite
a
bit,
and
so
that
seemed
to
help
a
lot
with
like
dragging
a
tab,
which
was
one
big,
frustrating
thing.
It
doesn't
help
with
like
instantiating,
a
new
notebook
that
has
a
thousand
code
mirrors,
because
we
still
are
instantiating
a
thousand
code.
Mears
does
help
with
the
day-to-day
interaction.
D
A
A
I
think
I,
remember
again,
beta
is
feature
compatibility
effect.
One
point,
0
is
featured
compatibility
as
well.
You
know
the
existing
notebook
has.
These.
Has
those
performance
problems
we
fixed
Jupiter
lab
to
to
not
have
any
more
performance
problems
than
the
current
notebook.
I
think
I
think
we're
fairly
close
to
that
I.
D
A
F
The
ones
that
are
blocked
are
being
able
to
maximize
in
a
doc
panel.
Fernando
said
you
wanted
that
for
beta,
so
that
that
has
a
change
to
phosphor.
That
has
to
go
on
that
cue.
The
work
chris
is
doing
right
now
is
to
make
it
to
change
the
way
we're
packaging
phosphor.
To
avoid
this,
that's
the
live
extension
compatibility
problem,
we're
having
turns
out
that
we
were
trying
to
bring
individual
modules
and
indeed
OOP
those
after
the
fact,
but
that
that
was
too
brittle.
So
we
need
to
make
things.
F
We
neither
change
the
unit
of
measure
to
a
package
instead
of
module
pounds.
So
what
he's
doing
some
refactoring
to
make
that
happen,
and
then
we
got
to
bring
that
into
Jupiter
lab.
So
in
my
mind,
that
is
I
think
we
want
to
have
extensions
working.
We
don't
want
to
up
right
out
the
gate
say
again.
The
extension
is
brutal,
so
that's
my
minimum
baseline
but
I.
Don't.
F
F
C
C
C
So
that's
that
God
gone
through
algorithms
and
collections
so
far
and
continue
moving
on
it's
not
too
much
work.
I
was
clean.
Doing
some
cleanup
around
the
algorithms
and
collections
trying
to
make
some
things
less
complex
and
try
to
unify
some
concepts
around
there
between
data
structures
and
sequences
and
whatnot,
but
that
should
general
nitty-gritty
clean
up
that
I.
C
That
decision,
also
in
the
minds
also
using
the
mindset
that
eventually
we'll
be
able
to
tear
off
tabs
into
their
own
free
floating
windows,
free
floating
browser,
separate
browser
and
pop-up
window
type
things.
So
I
can't
I
can't
code
that,
until
we
kind
of
make
a
decision
on
what
we
want
to
behavior
to
actually
be
the
layout,
save
restore
that's
just
a
matter
of
implementing
it
and
so
that'll
be
linear.
So
I
can
start
on
that
chain.
B
Also
bears
because,
because
what
Chris
is
doing
now
isn't
just
repackaging,
but
there's
some
refactoring
going
on
there
will
be
some
cost
to
us.
Switching
to
it
because
we'll
be
switching
up
some
things
in
Jupiter
lap,
it
won't
be.
It
won't
be
as
much
as
when
we
switch
to
the
new
phosphor
mono
repo,
but
there
will
be
something
like
that:
yeah.
C
A
D
D
C
B
B
There
are
I
think
Steve's
in
the
right
ballpark,
but
you
know
that
if
everything
goes
without
without
one
of
those
bugs
that
takes
forever
to
figure
out,
because
it's
just
insanity
when
that
that
makes
sense,
but
occasionally
we
have
these
things
where
we're
just
like
wait.
What
is
mana
doing
note
that
sort
of
thing
yeah
but
yeah
I,
think
what's
the
right,
ballpark,
okay,.