►
From YouTube: OMR Architecture Meeting 20200604
Description
Agenda:
* Integrating OMR into Julia [ @nbhuiyan ]
* Reviewing stale issues [ @0xdaryl ]
* #800 : Doxygen comments in headers
* #1827 : OMR wiki
* #352 : How should the structure of the technical documentation be organized?
* #5050 : Hosting for presentation artifacts
* #2274 : Release process
A
And
welcome
to
this
week's
Omar
architecture
meeting
on
this
week's
agenda.
We
have
a
couple
of
topics.
The
first
is
a
presentation
from
Nazim
on
some
of
the
work
that
he
was
doing
while
he
was
a
student
at
the
University
of
Alberta
to
integrate
the
Omar
compiler
in
Julia
and
I'll
turn
it
over
to
him
now
to
take
you
through.
That
is
he.
B
Brief
presentation,
where
I
demonstrate
being
able
to
compile
some
something
from
Julia
using
the
Omar
compiler
that
was
facilitated
with
the
help
of
the
LGBT
library.
So
just
some
quick
recap
of
the
ljb
project.
It
was
initially
designed
to
provide
a
mechanism
for
interoperability
between
LLVM
and
did
builder,
and
one
of
the
primary
goals
was
for
languages
that
use
LLVM
back-end
to
try
using
the
Worman
compiler
with
very
minimal
development
effort,
and
recently
it
was
contributed
to
Omar.
And
now
it
lives
as
a
sub-project
of
jet
builder
and
I
have
provided
the
link
here.
B
Looking
at
today
is
the
julier
language.
It
was
a
starting
point
for
me
to
try
and
you
know,
experiment
on
how
we
can
use
loj
B
in
other
languages.
So
julia
is
a
general-purpose
dynamic
language
that
is
mostly
used
in
data
science
and
machine
learning
applications
and
it
uses
LLVM
back-end
for
just
out
of
time
compilation
and
their
their
approach
is
basically
upon.
First
implication,
methods.
B
To
make
sure
that
if
their
goal
is
as
fast
as
possible,
they
assumed
that
there
would
not
be
too
many
different
methods
being
called
on
the
time,
which
is
why
they're
they
claim
to
be
very
high.
Performant
and
one
very
cool
feature
of
Julia
is
that
it
is.
It
is
easy
to
call
integrate
with
external
C
and
Fortran
library,
and
it
doesn't
require
an
internal
code
and
the
overhead
is
quite
minimal.
B
B
So
we
just
have
very
basic
function,
and
then
we
use
the
code
LLVM
function
in
the
interactive
utils
module
to
generate
the
LOV
Empire
or
this
specific
function,
and
this
is
how
the
output
looks
like
it's
a
very
basic
thing.
It's
just
well.
Obviously
we
don't
get
a
different
basic
steps
here.
It
just
returns
the
constant
that
we
would
get
actually
a
pagination.
Your
this
ir
is
from
a
different
version.
It
should
be
the
bread,
I
64,
three,
not
six
I,
just
mixed
it
up
with
a
different
experiment.
B
I
was
playing
on
with,
so
the
next
step
would
be
to
pass
the
intermediate
representation
through
loj
B,
so,
like
I
mentioned
before,
julia
has
a
way
to
use
external
c
libraries
easily.
You
just
have
to
have
to
provide
the
function
name
and
the
location
of
the
library.
In
this
case,
we
just
have
to
be
able
to
an
emic
reload,
PLO,
JB
library
and
then
by
the
you
can
see.
Okay.
B
So
the
next
step
is
to
translate
that
into
OMR,
IL
and
then
compile
and
ryan.
So
the
thing
is
that,
in
the
initial
implementation,
l
jb
expects
the
L
of
the
Empire
modules
to
be
something
that
was
previously
generated
by
a
front-end
and
they
pursued
as
bit
code
files
on
disk,
so,
which
is
why
I
needed
to
introduce
nati
where
C
string,
that
is,
with
the
that,
represents
module
and
convert
that
into
another
I
love
the
M
module
to
PCM
later
on.
B
So,
okay,
here
is
how
I
just
declare
that,
as
an
external
C
function
that
can
be
called
from
Julia
and
I,
take
that
LLVM
IR
and
then
instructed
module
and
compile,
get
the
encode
entry
and
then
return
the
result
from
running
that
and
the
next
step
he
so
we
get
to
end
the
valley
from
this
and
yeah.
So
here
is
the
result
of
the
execution
that
we
have
right
here.
B
That's
it
was
very
simple
and
in
terms
of
challenges,
I
guess
the
biggest
challenge
was
trying
to
understand
the
internals
of
Julia
run
time.
What
this
proof
of
concept
shows
that
it
is
possible
to
easily
try
to
our
compiler
in
languages
that
currently
use
the
Altium
back-end.
Although
the
example
I
showed
here
doesn't
have
a
advanced
oil
that
is
being
generated,
I
have
tried
more
complex
functions
and
I
was
able
to
successfully
among
them.
B
Well,
although
like
we're
not
able
to
totally
remove
the
LLVM
back-end
and
just
kind
of
assess
the
impact
of
just
happened,
Omar
compiler
instead
of
LVN,
but
it
just
gives
you
an
idea
of
how
much
impact
this
compiler
Allen
has
or
how
much
additional
memory
footprint
it's
caused
by
the
Omar,
compiler
and
so
on
and
yeah.
So
that's
basically
all
I
wanted
to
do
talk
about
today
and
if
you
have
any
questions
about
this
little
project,
I'm
happy
to
answer
them.
D
Wanted
to
ask
you,
so
what
is
the?
What
is
the
difference
of
this
approach
between
compiling,
let's
say
was
just
JIT
builder
means
and
generating
or
MRI
L?
There's
a
do.
I
understand.
It
correctly
said
it's
just
ll
gb,
sorry,
LLVM
intermediary
representation
is
later
converted
into
or
mi
representation
and
later
compiled
by
OMR
JIT
builder
backhand
by
Testarossa.
Okay,
yes,.
B
Basically,
it's
not
supposed
to
be
something
you
use
as
like
you
would
you
ship
with
your
product
it
just
hello.
Jimy
is
meant
to
be
used
as
something
to
assess
the
benefit
of
using
the
Omar
compiler
and
just
play
around
with
minimal
effort,
and
then
you
can
decide
if
you
want
to
invest
more
time
into
really
constructing
or
more
compiler
il
directly,
in
which
case
you
would
get
much
better
results.
I.
D
See
thank
you
and
what
is
the
like?
How
I'm
sorry,
maybe
it's
a
methodology
question,
but
how
would
be
the
but
that
benefit
that
you
just
said
assessed
like
yo.
Previously,
you
were
mentioning
that
what
people
can
estimate
is
the
overhead
added
by
om
our
compiler.
So
how
can
you
like?
What's
the
methodology
you
would
suggest
for
separating
the
benefits
from
on
my
compiler
and
benefits
from
using
like
LGB,
sorry
Ella
vm
code,
like
how
would
you
separate
the
benefits
for
estimating
it
so.
B
B
B
D
You
I
see
what
you
are
saying
and
the
last
question
that
I
have
so
I
am
interested
and
working
on
Omar,
compiler
and
I
needed
a
runtime
environment
to
try
out
something
more
with
was
dynamically
at
runtime.
That
environment
was
that
supports
a
language
was
dynamic
features.
So
if
you,
if
I,
were
to
repeat
the
path
you
have
taken
and
having
what
you
have
contributed
to
om
are
how
long
would
it
take
to
recreate,
though
something
that
is
like
behaves
the
way
reproduce
your
results
in
terms
of
commitment
like?
Can
you
give
an
estimate
like?
B
D
B
Once
you
understand
once
like
I,
am
still
the
julia
runtime,
it
was
not
really
much
effort
to
do.
This.
I
just
had
to
implement
this
API
to
accept
the
intermediate
representation
from
Julia,
and
this
is
basically
just
teaching
like
basically
setting
up
loj
me
to
consume
that
past
intermediate
representation
and
other
than
that.
There
is
no
other
changes
that
I
really
needed
in
loj
base
code
or
doing
Julius.
B
E
B
So
that
was
the
roadblock
which
I
do
not
really
invest
much
time
on
pursuing,
but
other
than
that
I
was
able
to
generate
a
low
B
Empire
for
most
of
the
currently
supported
interview.
Resignation
in
loj
be
able
to
make
more
company
functions
and
I'm
sorry
little
more
complicated,
Julia
functions
that
had
generated
things
like
reloads
and
also
like
conditional
blocks
and
so
on.
B
A
B
Contribution,
so
one
thing
is
the
one
thing
I
could
take
from
this
is
that
we
could
provide
some
api's
different
ideas
that
that
will
allow
using
LGB
as
an
as
a
body
library
for
any
language
to
basically,
you
know
pass
in
what
it
needs
to
compile
and
it
can
be
easily
just
compiled
and
run
and
the
result
obtained
for
different
scenarios
right
now.
We
don't
really
have
that
and
that's
what
I
had
to
add
as
part
of
that
shared
library.
A
B
B
F
B
A
B
What
next
it
depends
on
what
the
Omar
community
would
feel
about
how
organ
it
is
like
whether
it's
worth
investing
some
more
time
in
industry,
placing
LLVM
in
Julia
or
whether
we
just
work
on
making
LJ
be
more
consumable
by
maybe
adding
features
to
have
like
adding
more
capability
in
terms
of
handling
of
the
yellow,
cam
IR
that
is
related
to
vector
operations,
for
example,
but
and
then,
and
so,
prevent
adding
more
API
to
it.
So
and
right
now,
I'm,
leaning,
more
towards
making
LOD
be
more
accessible
and
capable
of
handling
different
internet
affiliations.
E
Just
the
other,
interesting
piece
of
it
that
you
mentioned
is
the
interaction
with
the
GC
that
an
area
where
we've
traditionally
haven't
made
very
a
whole
lot
of
progress
in
integrating
the
compiler
component
and
how
the
DC
component
or
how
the
how
the
compiler
computed
Kitty
degree
into
another
GC
component
that
we've
had
some
research
projects
that
have
been
looking
at
issues
like
that.
But
I
think
that'd
be
an
interesting
area
to
investigate
too.
E
F
E
A
A
As
an
open
issue.
They
should
be
closed
and
maybe
what
their,
what
the
disposition
of
them
of
them
should
be.
So
I
looked
at
ones
that
were
so
I
picked
a
bunch
here
for
today
and
the
ones
that
I
picked
were
discussion
where
there
were,
there
were
labeled
discussion
issues
and
the
first
four
are
kind
of
related
to
each
other,
all
around
documentation
and
and
that
sort
of
thing,
and
then
the
fifth
one
being
a
release
process
and
what
we
want
to
do
with
with
with
that
one.
A
So
what
I
thought
that
we
could
do
is
to
discuss
to
talk
through
the
various
issues
that
I
have
here
to
see
whether
or
not
this
is
something
that
that
we
want
to
continue
to
if
it's
still
relevant
I'm,
not
sure
if
me
sharing
them
is
going
to
help
or
if
anybody
wants
to
sort
of
look
at
them
on
their
own
I'll.
Try
to
summarize
the
first
one
here
800.
So
what
this
one
is
was
a
I
guess.
A
A
If
you
was
maybe
more
of
a
generic
thing
about,
where
do
we?
Where
should
we
be
putting
Docs
in
the
comments?
I
think
that
there's
some
differences
of
opinion
as
to
whether
or
not
they
should
live
in
header
files,
where
the
API
is
actually
defined
or
whether
or
not
they
should
live
in
C++
files,
where
they,
where
they
might
be,
providing
less,
where
there
may
be
less
less
clutter.
E
It's
the
benefit
of
of
having
it
listed
in
an
agenda
for
a
meeting
called
my
attention
to
it.
Yeah
I
mean
I.
Think
that
mean
the
bulk
of
this
of
this
issue
was
whether
or
not
we
should
be
asking
for
doxygen
Commons
to
be
placed
in
headers
for
api's.
That's
that's
a
defined
public
API
is
I.
Think
that's
basically
what
it
boils
down
to
the
coding
standard,
already
already
sort
of
describes
that
we
should
be
documenting
public
API
in
the
headers
at
the
point
where
the
functions
are
declared.
E
A
I
think
that
that's
how
things
are
going
in
practically
store
the
for
the
compiler
component,
I
think
that's
how
things
have
been
have
been
going
for
the
last
few
years
in
that
for
for
new
api's
or
for
api's
that
change
I.
Think
we've
been
pretty
good
at
insisting
that
doxygen
comments
come
along,
come
along
with
it
and
they
think
they've
pretty
much
exclusively
been
added
to
the
to
that
to
the
header
files.
A
So
I
don't
know
if
anything
really
needs
to
change
here,
because
if
it's
already
documented
in
this
coding
standard,
then
perhaps
we
don't
have
anything
to
change
here.
The
one
thing
would
be,
though,
is
that
coding
standard
isn't
necessarily
universally
applicable
through
all
areas
of
the
code
and
it's
hard
to
decide
what
to
pick
and
choose
from
that
coding
standard.
That
applies
to
different
part
to
the
code.
That's
maybe
a.
E
E
G
E
A
H
A
B
H
H
A
I
Yeah
well,
I
guess.
The
other
point
is
right
did
at
least
getting
some
documentation,
even
if
it's
not
consistent
in
the
app
and
the
slash
or
whatever.
If
you
need
to
go
in
to
standardize
it
at
some
point
with
a
script,
it's
really
not
going
to
be
as
hard
if
the
conventions
are
generally
being
adhere
to
with
just
a
few
minor
impacts,
variations
right,
yeah
and
I.
Much
rather
encourage
people
to
put
Docs
in
than
being
too
pedantic
about
how
the
Doc's
look,
at
least
at
this
point,
we
can
try
and
fix
them
later.
A
A
Artifacts,
then,
we've
got
to
figure
out
what
to
do
with
them,
which
is
maybe
leading
starting
to
lead
into
some
of
the
other
topics
that
we
have.
So
the
next
one
I
assume
the
discussion
on
that
one
is
over
the
next
one
is
1827,
which
was
simply
titled
Omar
wiki,
but
it
was
really
a
request
to
start
to
use
to
start
to
enable
the
the
wiki
and
the
Omar
project
I'd,
get
it
github
and
to
start
populating
it
with
the
information.
A
There
was
a
bit
of
a
discussion
back
and
forth
about
why
this
isn't
yoy
a
wiki
over
over
the
webpage
or
sorry
over
the
website
that
we
that
we
already
have
my
opinion
on
this
I
I
do
want
to
keep
I
too
have
too
many
places
to
go
to
look
for
information.
That's
that's
sort
of
my
my
opinion
I
like
to
keep
information
close
to
the
code
as
much
as
possible,
so
be
it
in
a
MD
format,
file
somewhere
in
the
code
or
actually
commented
in
the
code
I'm
sort
of
in
favor
of
that.
A
For
the
actual
wiki
itself,
I'm,
not
I,
guess
I'd
like
to
understand
what
kinds
of
information
would
go
in
there
that
we
wouldn't
put
into
the
code
what
kinds
of
design
information
or
whatever
so
the
originator
I,
don't
think
is
on
the
call.
So
I
don't
think
we
can
involve
him
in
the
discussion
at
this
point,
but
I
just
want
to
chime
in
here
with,
with
any
input
sort.
E
Of
concern
was
around
having
things
in
some
it's
it's
all
well
and
good
to
have
empty
files
and
documenting
things
close
to
code.
But
when
you
have
things
like
process
documents-
and
you
know
sort
of
diagnostic
documentation
on
how
to
do
things,
that
sort
of
stuff
doesn't
really
need
to
be
stored
in
the
in
the
git
repo
and
everyone
will
have
to
clone
it
all
the
time
which
maybe
it's
not
a
big
deal
until
we
have
tons
of
it.
E
But
you
know
you
you
kind
of
sneak
up
on
that
problem
and
then
there's
no
way
to
fix
it
really
so
I
think
that
and
the
idea
was
I
think
that
the
wiki
might
be
something
easier
to
work
with.
But,
as
I
think
Matthew
pointed
out
in
the
original
item,
the
wiki
would
probably
still
be
kind
of
controlled
by
or
would
only
be
writable
by
the
committers
of
the
project
anyway
and
I.
E
Think
Matthew
was
looking
for
a
place
for
a
he
to
document
some
of
the
work
that
he
was
doing
on
the
side
and
just
kind
of
make
it
accessible
document.
You
know
where
we
are
on
certain
things:
I'm
not
quite
clear
why,
if
his
weren't
the
the
right
way
to
do
that,
but
might
just
have
an
imperfect
understanding
of
what
it
was
that
Matthew
wanted
to
do
originally.
A
Yeah
I'm
just
reviewing
this,
it
seems
to
be
more
like
he
says,
project
plans
and
status
updates
and
that
kind
of
thing
more
appropriate
for
wiki.
The
the
other
thing
about
wiki's
that
I,
and
maybe
somebody
can
correct
me
if
I
am
using
them
incorrectly
in
that
you
almost
need
to
know
what
you
you
almost
need
to
know
what
you
want
to
find,
as
opposed
to
being
able
to
serve
a
browse
through
a
wiki
right.
A
H
A
D
Also,
as
user
Omar,
who
started
relatively
recently,
like
an
argument
towards
wiki,
is
that
in
wiki
you
can
easy
like
make
the
links
between
pages
way
easier
than
you
would
be
like
you
would
be
doing
in
the
comments
to
the
source
file.
For
example,
if
you
wanted
to
do
something
with
a
source
for
L,
you
basically
don't
simply
know
where
to
look
at
like
comments,
don't
link
to
other
source
files,
usually
well
in
week,
it's
easier
to
do
right,
but
that's
that
will
help
simplifying
like
beginning
of
using
Omar.
D
E
C
E
A
G
One
other
things
we
can
do
is
take
our
Doc's
directory
in
structure
it
so
that
it's
more
like
a
wiki,
so
we
could
put
like
an
indexed
MD
or
something
in
the
root
of
the
documentation
directory.
The
people
can
look
through
that
to
find
the
links
to
the
sub
documents,
so
we
could
do
the
same
sort
of
thing
in
the
docs
folder
I
also
I
thought
that
the
wiki
was
version
controlled,
I
thought
it
was
just
a
branch
or
something
off
the
main
repo
okay.
E
B
E
I
have
a
feeling
this
is
gonna,
get
it's
some
level.
It
will
get
dictated
by
how
the
Eclipse
Foundation
set
up
the
organization
somehow
but
I,
don't
know
that
for
a
fact,
I
was
just
kind
of
trying
to
figure
out
what
how
that
was,
how
that
would
work.
While
we
were
talking,
but
I
haven't
been
able
to
dig
into
the
enough
detail
yet
it's
the
first
ultimate
question
is:
do
we
need
a
wiki?
Is
the
wikia
something
that's
going
to
help
us?
E
Do
something
that
we're
not
doing
right
now,
because
it's
too
hard
for
yeah
documentation
isn't
exactly
one
of
our
strengths.
I
wouldn't
say,
although
we've
done
a
lot
better
at
this
over
the
over
the
last
couple
years,
but
I
guess
I'm
also
worried
about
creating
yet
another
entry
point
that
doesn't
really
get
curated
and
maintained.
A
H
A
Don't
the
other
thing
is
I,
don't
think
we
have
any
artifacts
at
this
point
that
discuss
releases
or
discuss
status
or
plans,
and
that
kind
of
thing
we
we
tend
to
discuss
those
sorts
of
things
on
this
call,
which
ends
up
creating
some
kind
of
an
artifacts
in
an
issue
that
gets
a
link
to
the
like
the
agenda
page
or
something.
So
if
we
did
have
a
wiki
articles,
I
think
that
would
be
pretty
sparsely
populated.
I
Could
we
just
wouldn't
it
be
make
sense,
then,
for
those
kinds
of
things
to
post
links
to
searches
that
produce
the
correct
list
of
infusor
whatever,
because
I
mean
our
issues.
Folder
is
a
nightmare
to
navigate
unless
you
really
know
what
you're
looking
for
right.
So
if
we
had
curated
searches
for
the
particular
things
that
are
of
interest
right
like
so
these
agendas
or
whatever,
then
they
might
make
it
easier
for
people
to
find
the
things
that
they
need.
G
C
G
One
other
thing:
sorry
not
to
I
guess:
I
am
changing
this
subject,
but
we
can
get
back
to
the
Rosslyn
thing.
But
one
other
thing
that
we
could
do
is
use
the
docs
folder
to
generate
a
website,
because
I
know
that
github
pages
can
generate
like
a
website
for
OMR
based
on
the
contents
of
the
docs
folder.
So
if
we
did
go
down
the
road
of
checking
everything
into
the
gate
repository
under
the
docs
folder,
we
could
still
compile
it
into
a
website
and.
B
B
E
H
D
A
A
Queries
to
filter
out
the
appropriate
information
within
the
repo,
so
I
think
maybe
what
we
could
do
is
to
explore
a
bit
about
what
what
capabilities
there
are
and
what
kinds
of
permissions
are
needed
to
do.
What
sort
of
actions
and
can
we
do
we
own?
Can
we
only
update
this
via
the
the
GUI
coming
update
it
by
the
you
know,
programmatically
so
I
think
exploring
a
few
of
those.
E
Just
like
to
make
sure
you
keep
that
conversation
in
the
context
of
you
know
what
can
our
existing
the
justing
two
mechanisms
that
we
have,
how
much
of
the
value
of
changing
it?
Can
we
get
from
our
existing
tools?
You
know
with
index
files
in
MDS
and
sort
of
curated
a
set
of
curated
links
that
that
help
people
find
sets
of
issues
that
are
of
interest
in
that
sort
of
thing.
So.
H
A
So
for
1827
I
think
we're
gonna,
leave
it
open
and
sort
of
summarize
some
of
the
discussion
that
we've
had
today
on
what
some
of
the
next
steps
are
going
to
be
there
and
what
simple,
possibly
uses
of
the
wiki
could
be.
That
does
lead
us
into
or
it
steers
us
in
the
direction
of
352,
which
is
one
of
the
one
of
the
early
issues
that
was
created
in
the
project
around.
How
do
we
want
to
structure
the
technical
documentation?
H
A
A
I
mean
I
mean
thinking
about
structure.
At
this
point,
I
mean.
Maybe
this
is
getting
back
to
a
point
that
Andrew
was
making
a
little
bit
earlier
about
I,
don't
necessarily
care
about
the
structure
of
it
at
this
point
or
how
things
are
necessarily
formatted,
but
I
would
like
to
get
people
to
actually
just
start
to
write,
more
documentation
or
create
little
artifacts
here
and
there
now
I.
Think.
A
One
of
the
points
that's
raised
in
this
issue
is
that
if
we
had
a
more
friendly
way
of
or
a
more,
if
the
docks
were
structured
in
such
a
way,
would
it
actually
encourage
people
to
write
more
documentation,
which
seems
to
imply
that
the
structure
is
what's
inhibiting
people
from
from
from
contributing
I'm?
Not
sure?
That's
true
I.
A
C
H
Then,
in
my
mind,
that's
like
if
we
had
the
right
tool,
it
would
make
it
maybe
easier
to
search
for
stuff,
for
example,
because
right
now,
if
you
were,
if
you
wanted
to
search
for
a
particular
piece
of
information
in
the
doc
directory,
for
example,
we'd
have
to
like
use
grep
or
some
tool
like
that.
Whereas
if
you
had
published
it
somewhere,
that's
more
searchable,
you
could
use
some
sort
of
built-in
search
function
or
even
Google
in
theory
to
search
for
that
information.
C
H
B
A
Yes,
I
mean
there
is
a
you
know:
there's
there's
code
documentation
required,
but
in
terms
of
actually
producing
like
is,
is
there
a
format
to
the
documentation
that
goes
along
with
it
right,
I,
don't
think
I,
don't
think
we
have
it
specified
in
that
level
of
detail
unless
someone
else
knows
of
some
documentation
somewhere
that
I
haven't
seen
yeah.
So
are
you
asking
because
you'd
like
to
know,
or
are
you
thinking
that
we
need
to
have
that
so
I
I.
D
Think
it's
one
of
the
things
that
I
will
have
to
eventually
do
for
my
contribution
to
Lamar
and
it's
just
maybe
having
like
five
headers
like,
for
example,
they're
like
what
is
your
feature
and
what
the
feature
does
and
how
to
use
the
feature,
a
description
of
requirement
of
documenting
new
feature.
Besides
the
comments
to
the
class
itself,
maybe.
A
I
tend
to
agree,
I,
think
and
maybe
going
back
to
the
I
mean.
Yes,
we
want
to
have
a
little
bit
of
structure
around
what
what
it
is
that
they're
trying
to
say,
but,
on
the
other
hand,
I
want
courage
them
to
say
whatever
they
want
to
say
right,
I
mean
we
want.
We
want
to
get
people
to
write
stuff,
so
I
don't
think
we
want
to
be
telling
them
like
thanks,
but
you
should
actually
write
it
this
way.
Instead,
oh.
I
A
The
next
one
hosting
for
presentation
artifacts-
this
has
actually
come
up
recently.
I
think
who's
Andrew,
that
Andrew
young
that
brought
this
up
so
bring
this
one
up
just
so
that
I
make
sure
I
know
what
I'm
talking
about.
This
is
the
one
to
understand
where
we
want
to
put
things
like
presentations
and
that
kind
of
thing
right.
G
Yeah,
that's
she
was
so
what
I?
What
I
was
noticing
was
every
time
we
put
up
our
material
anywhere.
It
eventually
goes
missing
and
links
on
our
front
page
reading
me
up
and
perpetually
dead.
We
updated
them
several
times,
because
I
think
that
it's
one
of
the
more
one
of
the
first
things
that
people
will
go
and
look
at
when
they're
introduced
to
our
project,
so
I
think
it's
pretty
important
to
keep
those
links
alive.
I.
G
Think,
right
now,
what
we
have
we've
been
using
IBM
box
accounts
to
host
a
lot
of
the
presentation,
materials
and
those
have
gone
missing
when
people
leave
IBM.
So
what
I
wasn't
really
saying?
It's
like
giving
any
specific
suggestions.
I
was
just
saying
that
what
we
have
right
now
is
not
exactly
working.
A
Yeah
I
mean
I,
think
that
so
I
think
there
must
be
another
issue
where
we
talked
about
this
before,
but
I
think
that
are
in
terms
of
size
that
the
largest
artifacts
that
we
have
tend
to
be.
These
calls
and
they're
all
hosted
at
YouTube.
So
we
don't
really
have
to
worry
about
something
that
can
handle
files
of
these
size.
They
tend
to
be,
like
maybe
you
know,
50
to
100
mega
boat
on
the
length
of
the
call,
but
but
for
things
like
presentations
and
documents-
and
you
know
other
things
like
that.
A
That
is
something
that
we
could
perhaps
even
just
store
in
in
in
github,
because
they
may
not
be
as
large
as
and
the
advantage
of
github
is
that
it's
just
it
isn't
necessarily
going
away
anytime
soon
and
it's
keeping
it
a
little
bit
closer
to
where
the
code
actually
is
the
drawback.
Being
that
you
may
not
want
to
clone
all
that
stuff
every
time
if
it
lives
in
the
same
repo.
So
maybe
we
need
a
separate
repo
just
for
those
kinds
of
artifacts.
A
A
A
E
Seems
there
it
opened
a
9,
some,
the
the
the
other
advantage
of
it
being
managed
by
a
github
is
that
you
have
to
do
a
pull
request
and
make
a
commit
and
the
commit
will
have
the
ECA
attached
to
it.
So
it's
basically
the
materials
are
being
contributed
into
the
same
license
and
therefore
are
accessible
under
the
same
rights
that
you
have
access
to
everything
else
in
them
that
people
have
rights
that
everything
else
in
the
community
so
I,
think
that
makes
sense
right.
You
don't
want
individuals
managing
all
of
these
things
individually.
A
A
E
A
E
A
A
A
A
C
E
Think
there's
Mon
yeah,
it
looks
like
there's
some
permission.
Denied
things
happening
in
these
runs
that
are
failing,
I'm,
not
sure
what
that's
all
about.
I
know
that
know
that
part
of
what
this
job
has
to
do
is
it
has
to
take
the
content.
That's
in
the
website
on
in
omar
dot,
website
repo
and
move
it
into
an
eclipse
repo
and
then
run
the
run.
The
Jekyll
ramshackle
there
to
generate
the
website
I
believe
that's
the
sort
of
basic
flow,
so
it
may
just
not
be
able
to.
C
A
E
G
I
do
just
want
to
say
one
thing
about
our
website:
I
think
it
would
be
really
great
if
we
rendered
our
Doc's
directory
and
included
a
copy
of
that
in
the
website,
somehow
so
that
our
Doc's
actually
showed
up
on
the
website,
because
I
know
the
website
has
some
like
instructions
for
building
that
are
totally
out
of
date,
and
things
like
that.
It
would
be
great
if
we
just
have
one
place
to
write
documentation.
A
A
Is
there
any
and-
and
this
issue
was
created
to
talk
through
the
parameters
of
how
we
wanted
to
we
wanted
to
do
those
releases
and
the
frequencies
and
the
and
that
sort
of
thing
is
there
any
thing
more?
That
needs
to
be
discussed
in
this
particular
issue
as
we
go
forward,
or
has
it
already
served
its
purpose?
You
think
I.