►
From YouTube: OMR Architecture Meeting 20230126
Description
OMR 2022 Retrospective and 2023 goals [ @0xdaryl ]
A
Welcome
everyone
to
the
first
Omar
architecture,
meeting
in
2023,
hope
everyone
had
a
good
holiday
and
ready
to
start
2023
off
right,
as
is
sort
of
an
annual
tradition
for
us.
We
like
to
take
the
opportunity
at
the
beginning
of
the
year
to
look
back
at
what
the
project
was
able
to
accomplish
the
previous
year,
so
in
2022
in
this
case,
and
what
some
of
our
objectives
are,
as
we
see
them
in
January
for
the
project
this
year.
So
I'd
like
to
take
you
all
through
through
some
of
that.
A
So
just
a
summary,
so
we've
had
a
number
of
things
happen
last
year,
there's
about
438
pull
requests
that
were
merged
in
the
project.
This
is
comparable
to
the
previous
year,
so
we're
we're
holding
steady
there
in
terms
of
the
changes
in
the
code.
You
know
we're
we're
up
about
25
000
lines
of
code.
Then
we
were
earlier
this
year,
so
there
was
a
fair
number
of
new
changes
coming
and
refactoring
also
occurring
there
as
well
as
reflected
in
some
of
those
numbers.
A
So
a
lot
of
good
things
happening
there
and
in
total
right
in
total
right
now
we're
about
951
000
lines
of
code
includes
comments
as
well,
so
we're
we're
slowly
increasing
there
in
terms
of
the
contributions
that
are
being
made,
we're
fairly
consistent
throughout
the
year.
I
think
you
know.
In
large
part.
This
is
because
of
the
the
the
the
requirements
in
omr
that
are
feeding
into
the
open
j9
project,
which
is
the
largest
consumer
of
of
Omar.
A
I
mean
I
think
that
it's
just
reflective
of
the
way
that
some
of
the
code
has
been
refactored
and
how
it's
being
used.
But
it's
also
good
to
see
here
that
a
fair
number
of
contributions
have
been
made
to
the
testing
site
as
well,
and
so
these
are
tests
that
are
being
executed
on
every
CI
run
that
that
occurs.
We
before
we
emerge
a
PR,
so
I'm
glad
to
see
that
there
is
a
focus
and
a
continued
focus
on
on
testing
and
quality.
A
With
a
lot
of
these
changes
and
then
there's
a
variety
of
other
changes
that
have
occurred
in
other
components
throughout
the
throughout
the.
Throughout
the
year
we
had
one
new
committer
elected
to
the
project,
badneet
Singh
and
a
new
project
lead
myself
was
elected
as
well
earlier
last
year,
so
that's
sort
of
the
dashboard
View
drilling
down
into
some
of
the
components
like
I
said
the
the
compiler
had
of
most
most
of
the
activity.
Last
year,
a
lot
of
the
work
was
done
in.
A
This
isn't
to
say
that
there
wasn't
Cindy
support
there
before
and
some
some
platforms,
but
in
2021
and
into
2022.
We
really
started
to
make
an
effort
to
clean
up
a
lot
of
this
code.
Make
it
work
better,
make
it
more
consistent
and
easily
to
understand.
If
you
recall
we
used
to
have
well,
there
were
a
lot
of
different
ways
of
of
representing
Vector
in
in
the
IL
in
the
compiler
and
agita
koblenz
went
and
proposed
a
new.
B
A
A
A
A
A
few
months
back,
Devin
demonstrated
some
of
the
work
that
he
was
doing
on
a
scratch
memory
analysis
tool
to
try
and
identify
where
memory
is
being
consumed
in
the
jit
and
really
to
drill
down
and
try
to
understand
what
and
why
bits
of
memory
are
being
allocated.
So
I
think
that
was
a
good
demo
and
I
think
there's
some
fairly
promising
tooling
coming
there.
That
will
help
us
to
reduce
the
overall
footprint
and,
in
many
cases,
improve
the
performance
of
some
of
these
optimizations
and
some
of
the
compilations
that
are
occurring.
A
So
that's
that's
some
promising
stuff,
that's
coming
technical
debt
and
cleanup
is
always
an
important
part
of
the
compiler
just
owing
to
the
history
of
it,
and
there
were
a
number
of
changes
made
last
year
to
move
us
along
that
trajectory
toward
you
know
a
much
cleaner
implementation.
You
know
improving
conceptual
Integrity.
You
know
more
more
code
comments,
things
like
that,
so
a
lot
of
good
stuff
happening
there.
A
A
You
know.
There's
there
were
you
know,
Concepts
and
IL.
Things
like
that
that
were
a
lot
of
these
things
came
from
discussions
that
were
happening
in
various
issues
and
at
one
point
we
decided
Well.
You
know
that'll
be
a
great
thing
to
document
somewhere
so
that
someone
will
know
about
this
next
time,
so
you
would
create
a
snippet
of
documentation
for
that,
but
it
wasn't
just
like
a
a
few
words.
You
know
people
did
put
some
some
Polish
into
this
as
well
and
I.
A
A
Last
year,
the
the
there
are
other
projects
that
are
in
where
consumption
of
omr
is
in
the
works,
and
there
were
some
changes
that
needed
to
be
made
to
to
a
variety
of
the
classes.
To
make
that
easier.
It's
certainly
the
case
that
the
way
that
the
code
is
right
now
is
not
the
final
state
in
terms
of
the
way
that
it
can
be
ex
made
extensible
and
obviously,
as
another
project
comes
along
and
finds
parts
of
the
code
that
are
difficult
to
extend.
A
A
A
A
A
So
there
is,
we
will
be
resuming
the
or
and
starting
a
release
Cadence
this
year,
I
mentioned
before
that
there
are
consumers
of
omr
that
are
coming
along
and
they
would
benefit
from
a
regular
release
Cadence
from
from
Omar,
so
so
a
snapshot
version
of
the
code
that
they
can
that
they
can
standardize
on
and
they
can
stabilize
and
and
go
forward
with
that
details
here.
This
is
this
is
not
something
that
that
is
necessarily
easy
to
Define
I
know.
Last
time
we
did
the
release.
A
A
Kind
of
related
to
that,
as
as
more
projects
are
consuming
omr,
the
code
needs
to
continue
to
be
made
more
extensible
and
making
it
easier
to
to
extend
things
in
certain
places.
So
this
isn't
just
about,
for
example,
making
the
making,
let's
say,
classes
more
extensible
and
the
compiler.
It's
also
about
maybe
adding
some
tooling
to
to
check
whether
or
not
things
are
being
extended
in
the
right
way
or
to
protect
the
API
that
kind
of
thing,
so
that
really
leads
into
the
next
point
of
the
compiler
API
and
figuring
out.
A
So
that
is
perhaps
the
largest
component.
That
is
well.
Let
me
go
back
one
more
step
when
we
released
in
2019
the
compiler
API
was
not
part
of
that
release.
We
protected
the
the
GC
API
and
the
Port
library
API
and
probably
another
one
there,
but
we
really
need
to
decide
on
what
is
it
that
we're
going
to
be?
A
There
is
work
needing
to
happen.
Oh
well,
ongoing
work
to
complete
the
Cindy
support.
This
is
primarily
in
the
compiler
there's
IL
work
coming
and
there's
no
more
code.
Generator
work
coming
to
support
different
kinds
of
of
CMD
instructions
so
expect
those
to
be
dropping
steadily
over
the
next
several
months.
A
A
Another
thing
that
would
like
to
do
to
start
a
discussion
on
at
least
is
to
look
at
the
dependencies
that
this
that
omr
has
on
third-party
libraries,
mainly
in
the
sen,
mainly
for
portability
reasons
and
one
of
the
areas
that
we've
already
encountered.
Some
issues
with
on
some
projects
is
with
the
use
of
STL
and
and
some
of
the
challenges
that
that
has
in
terms
of
being
able
to
find
the
right
version
of
STL
on
a
certain
machine.
That
kind
of
thing.
A
A
Historically,
we
haven't
that
technology
hasn't
used,
C,
plus
plus
STL
containers.
They
grew
its
own
or
grew
its
own
set
of
data
structures
to
do
things
and
the
advantage
of
that
was.
They
were
very
carefully
constructed.
They
had
a
very
good
memory,
characteristics
and
they're
very
well
understood,
but
they
didn't.
A
They
didn't
have
the
versatility,
let's
say
as
some
of
the
STL
containers,
but
anyway
I
don't
want
to
go
into
that
whole
topic
right
now,
but
at
some
point
in
the
in
the
near
future,
I
think
we're
going
to
bring
up
a
topic
where
we
can
start
to
talk
again
about
our
dependency
on
the
STL
containers
and
what
we
want
to
do
about
that.
If
that
is
the
Strategic
solution,
we
want
to
go
with.
How
can
we
mitigate
some
of
the
problems
that
people
are
having
if
it
isn't
the
Strategic
solution?
A
A
B
A
Well,
I
mean
some
of
the
groups
that
we've
worked
with,
and
some
of
the
build
environments
that
they
have.
They
can
be
older
and
they
may
not
work
as
well
with
some
of
the
technology
that
we
have.
It's
just
a
means
of
reducing
the
dependencies
on
that.
The
other
thing
about
them
as
well,
is
the
use
of
templates
and
how
hairy
and
how
large
the
code
can
get.
In
some
cases.