►
From YouTube: YUI Open Roundtable 12/06/2012
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
D
A
Alright,
so
let's
good
things
started,
thank
you
guys
for
coming
to
the
second
weekly
open
ye.
Ye
hang
out
around
cable,
where
your
color
now
but
number
of
things
we
want
to
go
over,
but
to
kick
things
off.
One
things
we've
been
doing
with
the
roundtables
has
been
covering
pull
requests
and
trying
to
get
those
resolve.
Things
that
ever
have
outstanding
are
they've
been
around
for
a
while
and
one
for
some
to
one
of
the
cover,
which
is
really
the
main
one.
A
A
Can
never
be
more
on
their
on
their
own
air,
but
they're
not
exactly
being
visiting
I'm
getting
notices
from
IRC
anyway.
So
there's
been
a
lot
of
discussion
about
the
complexity
of
the
methods
and
Ryan
and
Matt
and
didn't
come
back
and
forth.
So
the
question
is
where
we
want
to
take
this
forward
by
Saguna.
Continue
the
development
of
this.
Do
we
want
to
you
know,
split
off
make
changes
are
so
let
Ryan
positive
that
yeah.
G
G
G
What
we
have
to
do
is
walk
through
each
array
and
then
compare
all
of
the
items
with
every
item
in
every
other
array
and
build
a
result
array,
and
then
what
most
implementations
do
in
other
programming
languages
or
in
other
libraries
is
they'll,
also
ensure
that
the
resulting
array
from
an
intersect
is
deduced
so
that
you
only
have
one
of
each
value
in
that
resulting
array.
So
there
was
some
disagreement
about
whether
this
implementation
should
do
that.
To
my
feelings
on
it.
G
G
I
think
it
would
definitely
be
a
great
gallery
component.
I
also
think
I
mean
they're
low
level
enough
that
I
I
wouldn't
object
to
them
being
in
the
library,
but
I
kind
of
feel
like
putting
them
in
the
same
place
as
the
other
array
extras
would
convey
the
idea
that
these
are
I
don't
know
just
as
efficient
as
the
other
array
extras
or
just
as
widely
useful
I.
G
G
E
B
E
I'm,
seeing
is
that
there's
a
that
there's
like
other
stuff,
you
can
do
with
array
that
are
implementations
of
other
common
patterns
and
then
there's
stuff.
That's
either
you
know
coming
in
yes,
next
or
whatever,
in
that
it's
going
to
be
or
is,
is
implementable
through
es5
if
it's
possible
to
shim
up
so
there's
two
different
categories
of
things
right
now,
but
right
now,
there's
only
the
one
name
of
array
extras
and
it
seems
like
it's.
Maybe
it's
a
naming
thing.
A
G
It's
not
just
a
naming
thing,
I
mean
I,
don't
really
care
so
much
about
the
name
and
I
think
them.
There
are
a
few
things
and
array
extras
now
that
weren't
that
aren't
in
es5
and
that
you
know
have
no
plans
to
be
in
the
language.
So
it's
already
we've
already
kind
of
gone
away
from
that
initial
naming
choice.
G
But
for
me
it's
just
that,
because
implementing
a
generic
intersection
and
implementation
or
Union
implementation
in
JavaScript
requires
it
to
be
pretty
slow,
I
just
feel
kind
of
uncomfortable
about
giving
these
things
the
same,
the
same
level
of
of
relevance
as
everything
else
in
a
reactors.
So
you
know
the
other
stuff
in
re
extras
is
actually
most
for
the
most
part.
It's
pretty
performant,
it's
pretty
decent,
so
I,
just
I
wouldn't
want
people
to
see
this
and
start
using
it
and
not
realize
the
performance
if
they're
causing
themselves
the.
F
E
G
E
G
A
Pretty
soon
why,
then
y
I's
bless
this
right,
so
so
then,
there's
data
unless
you
included
in
the
core
or
you
included
gallery.
Otherwise
people
will
just
have
to
write
their
own
implementations
right.
So
the
one
of
this
is
that
you're,
giving
them
least
something
that
enable
something
good
I.
Don't.
E
G
G
I
mean
again
I'm
not
opposed
to
these
things
going
into
the
let
going
into
core
or
even
going
into
ray
extras
I'm
just
a
little
iffy
about
it.
I
really
think
the
majority
of
the
discussion
that
happened
on
that
pull
request
was
about
the
actual
implementation
of
them.
I
had
a
lot
more
issues
with
the
implementation
than
with
the
idea
of
these
things.
G
There
were
a
couple
of
edge
cases
that
that
the
proposed
implementation
was
trying
to
cover
like
it
it.
It
tries
to
allow
a
custom
comparison
function,
which
actually
adds
a
lot
of
complexity
and
and
I
think
kind
of
kind
of
violates
the
point
of
having
a
generic
low-level
library
utility.
Because
really,
if
you
want
to
do
a
custom
comparison,
you're
gonna
be
much
better
off
doing
the
entire
thing
yourself.
If
you,
if
you
know
about
the
data
that
you're
comparing
that's.
E
That's
relatively
true,
but
it
meant
even
back
to
Yui
to
and
well
especially
the
the
stuff
that
comes
to
mind
mostly
is
in
latitude.
I
think
that
this
is
also
true
in
the
node
API,
that
there
are
access
methods
that
include
that
except
a
function
to
do
special
filtering
them,
so
there's
precedents
in
the
library,
even
though
it
is
slower
to
do
that.
You
could,
you
can
certainly
implement
it
manually
in
it
would
be
faster
than
going
through
those.
It's.
G
Just
a
convenient:
it's
not
just
the
it's,
not
just
the
performance
thing,
it's
that
it.
It
would
encourage
people
to
use
this
thing.
That's
inherently
very
generic,
even
if
they
provide
their
own
comparison
function,
they're
still,
they
would
still
be
comparing
values
and
still
be
iterating
over
every
single
array,
while
iterating
over
every
single
other
array.
G
A
G
I
think
if
we
just
had
the
generic
thing
always
be
generic
and
say
this
is
how
it's
going
to
work.
It's
going
to
compare
values
by
triple
equals
equality,
and
if
you
want
something
more,
do
it
yourself,
then
I
think
for
one
thing:
we
encourage
people
not
to
rely
too
heavily
on
this
slow
generic
thing,
but
we
also
encourage
them
to
think
about
what
it
is
they're
doing
and
what
did
what
the
data
is
there
working
with
and
how
to
compare
that
efficiently
and
it
makes
the
generic
implementation
library
much
less
complex,
I.
A
G
Well,
I
think
narrowing
the
scope
is
good,
as
I
suggested
I
mean
I
suggested,
like
removing
the
comparison
function,
removing
some
of
the
specific
edge
cases
that
it's
trying
to
cover
and
I
suggested
some
code
that
would
that
would
be
more
along
the
lines
of
an
implementation
that
I
would
want
to
see
for
I.
Think
this
for
intersect
I
think
we
were
just
hoping
that
other
people
would
chime
in
because
right
now
I
think
it's
just
me
and
Matt
talking
about
this.
E
Yeah,
and
also
folks
that
are
going
to
watch
the
the
recording
of
the
open
conversation
of
the
open
meeting
will
possibly
also
contribute
to
the
pull
request
as
well.
I
guess
you
know
my
perspective
on
it
is,
and
I
haven't
read
the
details
of
the
implementation.
I
haven't
read
the
pull
request,
so
the
specifics
of
the
implementation
completely
devoid.
E
You
know
that
that's
not
part
of
what
I'm
saying
I
think
if
the
implementation
is
inelegant
or
or
not
very
performant
than
it
needs
to
be
improved
as
a
prerequisite
to
it
going
into
the
core
the
question
of
whether
or
not
it
should
go
into
the
core
man.
You
know
I
think
that
it
sounds
fine
I'm,
not
overly
concerned
with
it
going
into
core
in
terms
of
things
like
the
comparison
function,
I.
E
Think
that
they're
there
are
two
things
that
play
there.
One
is
the
expectation
of
a
library
to
add
convenience
to
your
development,
and
so,
if
it
adds
convenience
by
having
this
having
support
for
comparator
function,
then
you
end
up
with
a
slower
implementation
than
you
would
write
by
hand,
but
you
end
up
writing
less
code
as
a
result
of
it.
So
the
question
the
second
part
of
that
is
then
you
are,
you
are
writing,
let's
lower
code
as
a
result
of
it.
How
much
is
that
going
to
affect
you
so
and
and
how
do
we?
E
How
do
we
broadcast
that
it
is
not
very
performant,
or
is
it
going
to
be
a
matter
of
choosing
to
respond
to
feedback
on
this
particular
API?
To
say
you
know,
people
saying
its
really
bloody
slow,
say:
well,
yes,
its
really
bloody
slow,
because
you
have
to
use
comparator
function
and
so
I
I
guess
I,
err
on
the
side
of
a
little
bit
more
rope
to
hang
you
by,
but
allowing
the
comparator
function
worry
about
the
implementation
that
it
can
be
as
fast
as
possible.
E
You
can
add
things
into
the
into
the
API
Doc's
that
say
if
you're
using
a
comparator
function,
it's
likely
you'll
get
better
performance
out
of
hand
coding
something
yourself,
but
in
non
performance,
critical
situations
getting
through
that
code
faster.
Just
writing
the
code
faster
is
is
reason
enough
to
include
that
support,
I
think
but
I
mean
I'm,
not
really
passionate
one
way
or
another
about
it.
Personally,
because
I
totally
see
the
argument
of
starting
simple
and
expanding
it
based
on
feature
requests
to
so.
D
E
So
there's
there's
two
things
there.
It
there's
actually
the
documentation,
including
the
caveats
which
I
would
argue,
is,
is
worthy
in
the
case
of
including
comparator
function.
If
it
really
does
impact
the
performance
of
is
significantly,
then
it
should
be
documented
to
such,
but
then
there's
the
other
part
to
the
data
table
side
of
things,
which
is
that
behavior
was
the
access
to
the
node.
E
Behavior
was
explicitly
removed
and
offered
up
some
other
way,
and
you
know
great
lengths
were
taken
to
add
support
in
other
ways
for
the
typical
use
cases
that
would
normally
have
warranted
the
use
of
this
really
slow
method.
So
there's
there's
the
separation
of
AP
is
and
then
there's
the
documentation
side
of
things
so
providing
two
separate
AP
is
for
doing
one
with
or
without
a
comparator
function.
You
know
that's
that
is
an
option,
as
opposed
been.
H
I
agree
that
people
would
probably
be
better
off
writing
their
own
and
that's
something
that
developers
would
just
start
by
using
these
and
then,
if
they
noticed
any
performance
issues
and
their
code,
then
they
would
naturally
start
going
through
and
do
some
performance,
benchmarking
and
measuring.
And
then
at
that
point
it
they
might
pinpoint
that
some
of
these
are
slow
methods
that
they're
used
in
which
they
might
create
their
own
custom
implementations
or
they
might
just
say,
screw
it.
It's
not
worth
the
time
I
mean
if
we,
if
we
had
the
documentation
as
well.
H
G
I
think
at
the
point
that
somebody's
noticing
a
performance
problem
and
then
has
to
start
benchmarking
it
and
stepping
through
the
code
setting
through
our
code
I
think
that's
a
point
where
our
API
has
failed,
or
at
least
our
docs
have
failed.
I
think
the
API
should
generally
guide
people
towards
doing
the
right
thing
by
not
making
it
too
easy
for
them
to
do
the
wrong
thing.
G
Well,
the
right
thing
in
my
opinion
is
that
I
think
I
think
intersect
and
union
and
diff
should
be
as
low
level
as
possible
for
the
generic
implementation
and
I.
Think
that
means
not
having
a
custom
comparator
function
not
doing
anything
super
special,
just
comparing
arrays
containing
values,
because
I
think
so
here's
the
way
I
see
it.
G
I
think
this
set
that
is
going
to
need
that
custom
comparison
function
and
actually
benefit
from
is
going
to
be
so
small
that
I
don't
think
it's
worth
serving
that
set
of
people
in
these
low-level
utilities.
Maybe
we
maybe
we
add
the
low
level
stuff
and
then
we
think
about
adding
something,
a
little
higher
level
for
people
who
need
to
do
more
with
it.
A
G
E
G
G
It's
just
that
I
think
supporting
that
would
potentially
lead
people
down
a
bad
path
because
I
think
before
they
should
before
they
should
consider
passing
a
custom
comparison
function
to
this
thing.
They
should
consider
doing
this
on
their
own,
so
I
think
if
we
make
it
harder
for
them
to
use
this
thing
to
do
something
they
should
do
on
their
own,
then
they're
more
likely
to
consider
that,
and
if
we
here
people
clamoring,
you
know
why
doesn't
this
thing
support
comparison
function
y?
A
A
So
the
only
other
topic
I
asked
for
today
was
just
to
talk
briefly
about
a
contributor
mailing
list.
We
just
introduced
that
a
few
days
ago
and
right
now
invites
are
moderated
just
keep
the
spam
bots
out,
but
it'll
be
eventually
open
to
whoever
wants
to
join.
There
won't
be
that
sort
of
barrier.
You
have
to
wait
for
an
approval,
but
for
now
we're
having
a
that's
it
up,
I,
just
an
open
discussion
up
to
questions
about
that
or
any
comments
about
the
new
ballas.
I
Alright,
so
one
of
the
things
I'm
working
on
is
I'm
working
on
better
build
emails.
That
will
actually
tell
us
when
a
build
fails
versus
passes,
because,
right
now
it
just
gives
it
just
drops
into
a
link
to
the
results
I'm
having
to
do
some
Jenkins
to
get
that
to
work
once
I
once
I
get
that
to
work,
though
I
should
be
able
to
have
filtered
titles
that
you'll
be
able
to
say
you
know
when
this
build
pastor
when
it
failed,
it.
I
F
A
G
I
G
A
D
A
A
E
A
A
E
No,
the
roadmap
actually
calls
it
up
pretty
explicitly
the
things
that
I
had
planned
to
build
and
I
had
some
in
development
stuff.
The
way
that
I
went
over
it
with
him
and
just
some
of
the
tension
points
about
the
current
architecture
and,
in
particular,
how
it,
how
it
deals
with
progressive
enhancement
or
not
really
deals
with
progressive
enhancement
and
how
that's
going
to
impact
other
features
as
they
come
along.
Okay,.
A
Yeah
I
have
to
say,
if
I
as
I,
look
on
the
IRC
channel,
that
like
data
tables
like
the
number
one
conversation
topic:
okay,
so
yeah,
if
they're
going
to
be
having
a
dedicated
person
for
that
becoming
so
he's
already
looking
at
all
requests.
So
if
you
have
new
stuff
go
ahead
and
not
so
that
heaven
is
over.
I
Right,
can
you
guys
see
that?
Yes,
all
right,
this
is
the
the
new
server
page
for
yogi
serve?
You
can
actually
see
that
pulls
in
with
the
latest
gallery.
Build
was
when
your
next
CD
and
deployment
is
the
current
version
of
Yui
3
some
cool
little
toys
in
here
now
you
can
render
/
right
from
the
browser
whoa
there
it
is
you
can.
You
can
also
run
shifter
too.
I
I
D
I
In
the
old
way,
you
would
have
gotten
something
like
this
see
where
it
fetched
one
and
then
it
went
off
and
did
a
single
request
here
for
the
first
one
to
get
this
dependency.
So
now
it
actually
knows
what
it
is,
because
it's
fetching
loader
metadata
and
there's
the
loader
metadata.
We
forgot
our
modules
here.
I
I
Right
now
it
is
yes,
okay,
yeah!
So
right
right
now,
it's
actually
doing
that.
You
know
yeah,
so
that
was
actually
run
with
the
the
yogi
loader
command
inside
of
the
gallery.
So
it
would
picked
up
anything
that
had
a
meta
directory
and
built
metadata
for
it
and
then,
if
you
just
attach
that
to
your
combo
URL,
give
it
a
built
tag
BAM,
it
works.
D
G
I
E
Okay,
then
I
have
an
open
pull
request
right
right
now
for
deferred
zand
promises,
and
just
yesterday,
or
today,
I
Brian,
cavalier
in
and
Dominic
Nicola
and
I
and
I
guess
some
some
other
folks.
It
closed
out
on
version,
1
point
0,
0
or
so
of
promises,
a
plus
specs.
That
means
that
the
implementation
of
the
promises
API
at
least
in
terms
of
the
promised
object,
not
so
much
the
deferred
or
resolve
or
object
itself,
is
finalized,
which
means
that
I'll
be
able
to
proceed
on
that
and
make
changes
to
that.
G
E
B
A
A
E
D
E
E
E
I
think
at
this
point,
if
it's
that,
if
Dominic's
happy
with
the
state
of
the
test
suite
then
re-implementing
it
using
Yui
tests,
the
only
risk
that
we
run
there
is
that
the
types
of
assertions
aren't
exactly
the
same,
and
so
the
test
isn't
exactly
the
same,
but
I'm
not
sure,
but
I
think
an
attempt
to
implement
it
as
y
UI
tests
would
be
nice
because
that
would
be
effectively
test
coverage
for
at
least
part
of
the
implementation.
The
promise
is
part
of
the
implementation.
C
So
certain
more
problems
are
coming
up,
which
is
good,
so
yeah
we're
working
on
those
I'm
going
through
them
all
and
once
it's
a
little
bit
more
stable
than
we
can
start
throwing
down
our
regular,
build
step
between
you'll
see
all
the
time
said.
They
are
pretty
exciting,
so
stay
tuned
for
that,
the
next
three
weeks
and
early
next
year,
so
cool
so
yeah.
C
We
have
like
a
pretty
awesome,
set
up
and
involves
of
dish,
rack
and
tons
of
tablets
that
are
that
are
stacked
and
all
charging
we
use
that
yesterday
and
tested
ran
multiple
runs,
but
last
afternoon
I
think
we
had
140,000
tests
running
with
kitty,
which
is
just
oh,
why
you
my
rent
many
many
times
so
yeah,
it's
pretty
cool,
so
I'm
looking
forward
to
having
that
published
on
my
way
to
get
I've
got
columns
to
work
out
the
testability
stuff.
Is
it.