►
From YouTube: JupyterLab Weekly Dev Meeting, May 19, 2017
Description
Meeting of the JupyterLab & Notebook development team, May 19, 2017
Meeting Notes: https://paper.dropbox.com/doc/JupyterLabNotebook-Weekly-Meetings-rIhXeFWYRgCiCFKiz2gv4
A
Hello,
everyone
welcome
to
the
Jupiter
lab.
Did
you
put
a
notebook,
weekly
meeting
or
Friday
May
19th?
And
let's
see
here
where
our
meeting
notes
are
on
Dropbox
paper
and
looks
like
not
sure
who
should
start?
We
have
a
smaller
number
of
notes
today.
This
one
want
to
talk
about
the
0.2
to
release
from
from
yesterday.
B
Yeah
sure
so
we're
looking
we're
taking
more
about
ApS
stability
as
we
go
to
data
basically,
and
there
were
just
some
outstanding
bugs
that
were
recently
wrapped
up,
so
that
went
into
the
0.2
just
to
kind
of
have
another
iteration,
because
we're
getting
really
close
to
a
lot
of
things
being
stable
enough,
but
there
it
wasn't
like
one
of
those
huge.
You
know.
Here's
some
new
feature
to
play
with
the
releases
and
she's
been
working
on
auditing
the
API
just
to
see
which
things
are
likely
to
change.
B
So
this
is
this
is
to
put
stuff
in
that
matrix
that
you
created
that
and
some
of
those,
some
of
the
ones
that
are
going
to
change
are
I'm,
not
sure
that
they're
necessarily
API
changes
just
things
on
the
backlog
like
like
switching
keys
and
virtual
dumb
and
more
places,
not
exactly
sure
where
the
extension
system
stuff
is
as
of
today,
but
I.
Think
there's
a
couple
links
in
the
docs
that
explain
the
current
state
of
affairs.
There.
B
Let's
see
what
else
I've
been
working
on
the
setting
system
for
1.0
I
originally
planned
to
have
used
the
services
API
and
just
write
stuff
to
the
normal
user
land
file
system
and
then
swap
those
four
dedicated
settings.
Api
is
in
the
future,
but
that
seems
like
it's
too
high
a
barrier
for
getting
people
to
even
test
a
PR.
So
then
I'm
switching
to
just
using
local
storage
at
the
back
end
for
a
setting
system.
B
But
you
know
the
api's
won't
change
it'll
just
be
swapping
it
for
a
different
back-end
in
the
future
and
Ian
you
have
a
bunch
of
stuff.
Would
you
like
to
talk
about
it?
Yeah.
C
I've
got
some
rows
behind
me,
so
hopefully
you
can
hear
me.
Okay,
but
so
I've
been
I've
been
traveling
a
lot.
The
last
couple
weeks,
so
I
fallen
a
little
behind,
but
one
thing
I've
been
working
on
a
few
days
is
what
we've
talked
about
about.
Having
giving
the
contents
manager
an
idea
of
multiple
drives,
and
so
the
idea
is,
you
can
add
different
sort
of
network
drives
in
quotes
to
the
contents,
manager
and
disambiguate,
then
broadly
path,
so
hopefully,
within
a
day
or
two
I
should
have
a
PR
ribbon
on
that
I.
C
Is
the
concept
of
the
currently
active
cell
I
know
that
in
a
lot
of
ways,
that's
sort
of
morally
part
of
the
view,
but
that
would
be
something
that
would
be
useful
in
a
real-time
collaboration
context
to
have
on
the
model
so
that
you
could
have
various
UI
indicators
to
indicate
you
know
who
is
currently
editing
a
given
cell.
It
simplified
certain
things.
From
that
perspective,
we
have.
We
have
some
precedent
for
doing
that.
We
currently
have
selections
living
on
the
model
for
text.
C
B
C
Do
keep
cursor
one
of
the
issues
with
tracking
cursors
is
that
it
becomes
really.
It
becomes
really
easy
to
have
us
a
proliferation
of
cursors.
You
know
every
time
something
happens
in
a
text.
Editor
code
mirror
says:
hey
I
got
a
cursor
change.
You
try
to
render
that
cursor
and
you
end
it
because
a
lot
easier
to
add
cursors
and
remove
them
so
I
found
you
have
to
be
really
pretty
aggressive
about
calling
cursors
and
one
of
the
ways
that
that
would
simplify
things.
C
For
me,
just
from
an
implementation
standpoint
is
to
have
a
notion
of
which
cell
is
currently
being
edited
and
only
show
cursors
for
that
cell.
Okay
got
it,
so
this
is
in
a
sense.
This
is
this
is
something
going
to
be
much
simpler
implementation,
but
it's
something
that
I'm
really
going
to
be
super
than
I
would
have
thought
is
being
able
to
aggressively
remove
cursors
once
you've
added
them.
You
guys
so.
D
C
B
C
A
And
everybody,
but
for
you
so
if
the
same
would
be
true
of
some
sort
of
active
cell
notion,
you
would
have
a
structure
that
list
that
that,
in
a
given
person's
model,
has
their
own
active
cell
and
then
other
people's
active
cells,
and
we
could
choose
to
render
the
other
beforeand
active
cells
in
in
some
suitable
way.
Yeah.
A
C
So
what
they
have
is
the
there's,
the
concept
of
a
user
ID
and
a
session
ID
and
there's
and
they're
separate,
so
the
user
ID
is
meant
to
be
persistent
if
or
is
meant
to.
You
know
be
shared
if
the
user
has
multiple
views
on
the
same
document
and
also
across
time,
and
then
the
session
ID
is
meant
to
be
unique
for
a
given.
You
know
router
tab
and.
D
They
don't
have
the
concept
of
multiple
documents
open
in
the
same
browser
tab
not
that
I'm,
aware
yeah
I.
A
Mean
I'm
definitely
open
to
that
I
think
it
would
simplify
some
of
the
design
and
usability
aspects
of
it
it
if
it
clip
the
file
you're
yeah,
yeah
I
could
imagine
right
now,
if
you
don't
have
that
that
stuff
stored
on
the
model
that
it's
very
difficult
for
you
to
represent
that
you,
you
could
like
dive
into
the
editor
and
see
if
there's
a
cursor,
the
editor
for
that
cell
and
propagate
that
up
to
some
notion
of
active.
But
it
sounds
like
that's
not
not
not
going
to
be
very
reliable,
because
multiple
cursors
are
possible.
D
C
D
D
But
if
I
delete
a
couple
of
cells,
but
I
can
imagine
maybe
showing
that
I
have
cells
5
through
10
selected
in
the
UI,
or
maybe
that
gets
too
confusing,
I
don't
know,
but
if
you're
not
showing
sort
of
the
cells
I
have
selected,
then
it
makes
it
using
when
I
delete
cells,
hey
there's
a
lot
of
things
that
we
could
do
along
the
whole
spectrum
of
the
notion
of
what
another
user
state
is
one
another.
What
abuse
data
is
right.
E
A
C
D
A
D
With
that
Jason
yeah
I
mean
I
think
it
can
naturally
be
extended.
It's
as
long
as
our
selections
or
cell
collections
are
contiguous.
I
think
it
can
be
pretty
naturally
represented
in
the
same
way
we
do
have
cursors
represented
in
the
model
visually
yeah.
We
don't
have
the
notion
of
indicating
to
others
what
the
current
active
cell
is
visually,
so
yeah.
You
know
who
knows
that
that's
going
to
be
sort
of
too
complex.
B
I
would
like
I
would
like
maybe
to
have
people
to
play
with
next
week,
but
if
you're
is
the
more
is
linked
and
you
can
see
where
it's
headed,
okay.
A
It's
it's.
A
factory
function
for
V
Dom
elements
that
basically
have
the
right,
CSS
classes,
etc,
and
the
start
to
work
on
the
next
at
the
drop-down
and
the
pattern
that
I'm
thinking
of
is
that
the
our
existing
VM
render
class.
So
we
have
a
right
now
we
have
the
V
Dom
model
and
Avedon
render
class,
and
the
basic
picture
is
that
the
model
is
your
state
for
a
set
for
a
a
V
Dom
tree.
A
It
fired
an
on
change
event
and
then
the
V
Nam
render
class
has
a
render
method
that
basically
would
use
these
UI
controls
and
other
native
Dom
nodes
and
just
return
a
virtual
Dom
tree
that
gets
rendered
and
I'm
thinking
about
us
starting
to
use
this
in
places.
Basically,
where
we
have
sort,
we
don't
need
nested
widgets,
so
a
great
example
would
be
to
toolbars
sell
two
of
our
extensions
dialogues.
A
Things
like
that
and
then
I
think
the
the
logic
for
these
components
will
be
simplified
greatly
by
this
pattern
and
also
I
think
it
will
give
us.
You
know
reusable
UI
controls
that
we
can
sort
of
consolidate
our
design
work,
our
interaction
work.
So
we
don't
have
to
worry
about
fine-tuning
buttons
and
toolbars
and
everything
across
all
the
different
parts.
The
other
place
where
I
think
we're
quickly
going
to
see
is
people
building
extensions
and
needing
these
core
UI
controls
and
I.
Think
it'll
really
help
them.
A
Give
people
consistent,
UI
controls
that
they
can
reuse
that
match
styling
and
things
like
that.
But
this
is
not
in
any
way
beta
work
and
it's
probably
going
to
shift
lower
on
my
priority
as
I
try
to
work
on
the
beta
stuff,
but
it's
something
that
I'll
keep
picking
away
at
the
other
is
and
in
doing
a
little
bit
of
work.
I've
noticed
a
little
bit
of
inconsistency
about
what
how
we're
making
decisions
about
what
things
are
in,
who
vs.?
Who
extension
and,
in
some
cases,
things
related
to
the
extension
like
functions.
A
That
add
thing
add
things
to
the
command
palette
are
in
the
base
NPM
package
and
in
other
places
those
things
are
in
the
extension
I.
Don't
I'm
not
opinionated
about
what
things
go
where
really
I
just
think.
We
probably
want
to
audit
that
and
make
sure
it's
consistent
for
the
beta
and
I
did
I,
don't
I'm
yeah,
so
I,
don't
know,
I,
know
Steve
isn't
here
today
he
probably
would
have
comments
or
thoughts
on
that
Darren.
Do
you
have
any
thoughts
on
that
or
yeah.
B
I
think
the
idea
was
meant
to
be
all
the
things
that
you
all
you
would
consider
putting
in
any
other
NPM
package
that
is
meant
to
be
used
on
its
own.
You
put
that
in
the
core
you
put
only
the
things
that
are
Jupiter
lab
specific.
So,
for
example,
that's
where
you
add
commands,
because
your
command
ideas
aren't
something
you're
going
to
export
and
that's
where
you
create
an
instance
and
create
an
instance
tracker.
B
It's
the
core
class,
the
thing
that
you
want
to
keep
track
of
within
jupiter
lab,
so
I
think
with
guidance
on
it.
I,
don't
think
I,
don't
think
I
actually
think
they
probably
won't
be
much
disagreement.
If
we
audit
a-
and
we
find
some
things
that
look
out
of
place-
I'm,
just
not
sure,
we've
been
hyper
vigilant
about
it
and
maybe
that's
what's
happened.
Okay,.
A
We
should
kind
of
spacing
speed,
one
sees
back
gulia
and
then
the
last
thing,
a
lot
of
note
is
I've
got
another
PR
open.
That
is
refactoring
our
ambassador
right
now
we
have
a
default
clean
package,
and
that
includes
both
our
theme.
Assets
such
as
images
and
icons,
and
then
also
our
default
theme,
CSS
variables
and
I'm
splitting
that
into
multiple
pieces.
A
A
Themes,
but
that
that
may
be
a
possibility
and
I
think
this
from
talking
to
different
folks,
it
sounds
like
the
theme
ability
of
Jupiter
lab
is
probably
beta
material.
There's
a
number
of
people
who
want
to
I
think
immediately
start
to
use
Jupiter
lab,
but
the
first
thing
that
they
would
do
would
be
to
seen
it.
You
know,
and
so
I
think
that
that's
probably
data
level
work.
D
Yeah,
so
we've
had
a
lot
of
activity
and
PRS
merged
and
in
particular,
we
had
a
bunch
of
new
contributors
partner
from
the
hackathon,
as
well
as
some
other
people
that
have
contributed
some
code,
we're
down
to
a
handful
of
PRS
that
are
open
with
a
couple.
More
PR
handful
of
issues,
open
47.0,
put
out
a
new
alpha
testing
out
the
extension
system
for
drupal,
a
bo
point
22,
and
it
was
great.
A
The
OL
it
just
I
have
one
thing:
I
forgot,
the
only
thing
we
ran
into
and
doing
the
extension
stuff
is
that
I
think
we
can
fill
out
the
first
I'll
say
what
Jason
said
was
also
true
for
us
in,
like
the
the
new
extension
system,
has
worked
fantastic
building
extensions
based
on
cookie
cutters,
working
like
everything
just
work.
The
only
thing
we
ran
into
is
the
I
think
we
can
improve
the
documentation
of
the
command
line.
Programs
like
a
number
of
don't
have
any
documentation
beyond
the
default.
A
Trail
it's
auto-generated,
stuff
and
I
can
submit
a
full
request
on
that.
I
think
that'll
help
people,
you
know
things
like
I
was
I
stumbled
over
the
fact
that
Jupiter
lab
extension
list
didn't
list.
My
linked
extensions,
individual
separate
list
linked
sub
command,
and
you
know,
and
that
list
linked
to
command
isn't
listed.
It
was
hard.
It
was
hard
to
find
that
that
that
command
existed
so,
but
everything
worked
fantastic
Rafael.
That
was
the
only
thing
I
ran
into.
E
E
The
canvas
that
was
being
used
as
the
surface
to
draw
on
was
resized
to
examine
exercise
the
viewport
and
it
turns
out
that's
fine
when
there's
only
one
grid
on
the
screen,
but
if
you
get
more
of
them
on
the
screen,
it
turns
out
with
resizing
the
canvas
I'm
assuming
due
to
the
memory
reallocation,
but
the
covers
actually
gets
pretty
expensive.
So
what
I
did
was
I
changed
to
allowing
that
canvas
to
only
grow
in
increments
of
512
pixels,
which,
like
somewhat
you
know,
anecdotally
an
optimum,
and
what
that
means.
E
Is
that
as
you
as
usual,
are
expanding
the
great
deep
or
the
canvas
under
under
under
the
covers
will
expand,
but
it's
never
going
to
shrink
again.
So
once
you,
you
know
maximize
your
browser
window
or
something
like
that.
The
underlying
canvas
is
delivery
and
you
resize.
So
everything
remains
quite
speedy,
so
you
can
actually
do
the
interactive
drag-and-drop
resizing
infamous
phonemic
now,
so
that
was
a
big
big
performance
win
on
top
of
all
the
other
stuff
that
we're
doing
for
orbits.
E
E
I'm,
you
know,
I,
don't
know
I
just
looked
at
the
JSON
table,
schema
stuff
and
I
have
something
that
is
designed
to
work
easily
with
that
JSON
table
schema,
but
the
JSON
table
scheme
does
it
as
far
as
I
can
see,
doesn't
specify
a
format,
but
the
data
itself
is
actually
sorting.
It's
just
metadata
about
a
particular
data
set.
E
So
I'm
not
I'm,
not
entirely
sure
you
hear
it.
I
just
haven't
solved
that
problem,
so
but
they're
not
going
to
be
a
whether
I'm
going
to
assume
the
data
is
colander
or
whether
I'm
going
to
zoom.
It's
you
know,
row
based
or
something
outside
of
I
would
cite
it
yeah
happy
good
happy
to
take
input.
If
you
have
some
datasets
you're
wanting
to.
A
A
It
may
make
sense
to
just
support
those
formats.
I
mean
it
and
part
of
it
is
each
of
the
format's
is
great
for
certain
things
and
horrible
for
others,
and
either
that
or
have
one
sort
of
optimal
in-memory
format.
And
then
you
know
simple
converters
between
the
format's
or
something
like
that.
But
but
in
my
mind
those
those
are
going
to
be
the
main
formats
that
we
would
get
out
of
our
data
in.
A
Not
yet
and
I
don't
know,
yeah
I
I
am
not
yet.
A
E
Mean
that's
going
to
really
be
up
to
whatever
the
user
of
the
library
does,
because,
presumably
your
your
your
data
frame
is
going
to
live
on
your
server,
not
on
the
client
and
so
like
that
specs
more,
like
out
of
my
purview,
so
I
don't
want
to
make
anything.
That's
like
here's
a
you
know:
I'm
not
going
to
I'm
not
going
to
baked
into
the
concept
it's
big
into
fostering
the
concepts
of
the
pen
is
a
thing
like
that
house
yeah.
E
But
if
we
can
find
out
hey
you
know,
most
things
are
going
to
have
data
in
this
type
of
format
or
something
then
you
know
I'm
in
a
video.
If
I
can
find
a
suitably
general
enough
format
where
you
can
just
shove
some
in
memory
data
into
a
data
model,
then
then
I'll
do
that.
But
again
the
idea
is
that
people
are
going
to
implement
for
their
particular
use
cases.
You
know
their
own
implementations
of
data
models
that
do
what
they
need
and
so
for
Jupiter
labs
case.
A
And
even
I
mean
part
of
what's
a
little
bit
messy
is
you
know?
Sometimes
when
it's
row
oriented
the
rows?
Are
our
dictionaries
and
not
not
an
ordered
sequence,
and
so
the
and
the
the
keys
would
be
to
me
the
columns,
column
labels
and
the
values
would
be
that
the
data
for
that
row
and
column
the
difficulty
there
is
that
the
order
isn't
have
you
have
to
refer
to
another
structure
that
has
the
ordering
of
the
column
names,
and
so
you
have
a
sort
of
a
double
looked
up
to
figure
out.
A
A
A
A
E
E
The
field
is
a
pair,
which
is
a
name
and
type
and
it
maps
directly
to
the
content
of
the
field
in
JSON
table
schema,
which
maps
also
well
onto
sequel
and
other
sorts
of
things,
and
that
name
and
type
is,
can
be
used
to
dispatch
to
lookup
custom
cell
renders
that
can
handle.
You
know,
columns
of
the
given
name,
Andy
or
columns
of
a
given
type
or
a
combination
of
the
two
or
lack
thereof,
and
so
you
know
it's.
E
It
may
be
useful
to
have
base
JSON
data
model
include
that
notion
that
hey
like
these
are
I've
got
columns
and
they
have
this
name
in
this
pipe,
and
so
people
can
get
their
data
into
that
format.
Then
we
can,
actually,
you
know,
be
more
intelligent
about
how
we
render
it
or
at
least
give
you
the
option.
E
This
is
some
more
stuff
to
think
about
yeah.
How
do
you
Louise
do?
The
trick
is
going
to
be
having
a
default
data
model
that
people
don't
expect?
Is
the
end-all-be-all
data
model
that
oh,
when
we
use
the
data
grid?
We
use
this
data
mount
like
I.
Don't
we
need
to
be
real
careful
about
the
messaging?
This
is
just
an
example
of
a
data
model
at
certain
stage.
One
particular
use
case,
like
the
real
data
model,
was
completely
abstract
and
virtual
and
you
can
implement.
E
E
So
the
only
other
option
needs
so
the
so
you
register
renders,
by
right
now
three
three
properties,
so
the
region
and
the
region
is
either
the
body
row,
header,
the
column,
header
or
the
corner
header,
and
then
two
optional
parameters,
field,
name
the
field
type.
And
if
you
don't
provide
those
there
wildcards,
you
know
anything,
you
know
other
things
can
match
like.
E
The
config
object,
which
contains
row
index
column
index
bounding
box
of
its
drawing
into
the
data
value
that
sort
of
thing
and
if
it
wants
to
delegate
some
other
internal
render-
and
it
has
not
in
a
special
way,
then
it
can
do
that.
The
reason
that
I
did
it
include
mapping
by
row
and
column
index
in
the
data
grid
is
because
your
data
model
by
insert
and
remove
rows
or
columns
in
the
course
of
its
lifetime
and
then
what
does
the
data
grid
do
at
that
point?
E
To
did
ship
Excel
renders
that
are
based
on
row
and
column
and
enter
on.
You
know
what,
if
you
go
to
the
row,
for
the
thing
that
you
have
a
double
reader
for,
and
so
it's
better
to
not
have
that
mapping
done
BB,
dumb
row
and
column
index
at
that
level.
If
you've
got
some
weird
case,
where
you
know,
you've
got
a
fixed
grid
in
there
dimensions
are
all
in
the
same,
and
you
can
do
that
index
based
mapping
there,
but
you
still
have
escaped
apps
to
do
that
with
across
the
render.
A
No,
that's
I
mean
that's
part
of
the
nightmare
of
Excel.
Is
you
know
what
are
the
semantics
of
the
grid
when
you
add
and
remove
rows-
and
you
know
the
for
matters-
the
equations
all
that
stuff
in
it
there's
a
lot
about
the
usability
bugs
that
Excel
continues
to
have
because
of
all
those
edge
cases,
so
that
yeah
I
think
it
makes
not
bake
that
into
the
renders
itself.
Yeah.
E
A
not
saying
that
same
problem
occurs
when
you
start
talking
about
where
we're
in
the
where
the
pipeline
do
you
introduce
the
concept
of
stands
like
row.
Column
stands
is
that
is
that
a
concept
that
lives
on
the
data
grid
is
a
concept
that
lives
on
the
data.
All
the
same
question
happens.
If
you
start
now
inserted
in
remove
rows,
say
statement
borders
to
redraw
borders
on
another
layer.
They
need
to
be
aware
of
some
fans
and
and
so
on,
and
so
so
there
so
there's
some
lingering
to
shoot
there.