►
From YouTube: OMR Compiler Architecture Meeting 20181121
Description
Compiler Architecture Meeting agenda:
* A discussion on Tril directions, desired features, and priorities.
Please add any comments/questions to the GitHub agenda issue: https://github.com/eclipse/omr/issues/3217
A
Okay,
welcome
everyone
to
today's
compiler
architecture
meeting.
So
on
today's
agenda.
We
have
one
topic,
but
I
think
that
it
might
actually
generate
a
fair
bit
of
discussion.
So
the
discussion
today
is
going
to
be
around
trill,
which
is
a
sort
of
a
testing
interface
for
the
compiler
technology,
and
it
was
developed
for
those
that
aren't
quite
aware.
It
was
developed
about
I,
guess
started
about
a
year
and
a
half
ago
to
help
with
testing
of
the
language.
Agnostic,
compiler
and
a
fair
bit
of
work
went
into
it
over
the
summer
of
2017.
A
But
but
since
then,
a
lot
of
the
work
had
been
stopped
just
basically
because
of
no
people
to
work
on
that.
So,
but
but
it
is
still
fairly
important
for
us,
and
this
project
and
I
think
that
to
help
move
things
forward,
it
would
be
useful
if
we
did
have
sort
of
a
list
of
work
that
needs
to
get
done
and
a
prioritized
list
of
work
that
needs
to
get
done
as
well.
A
As
you
know,
a
description
of
what
that
work
actually
is
so
that
those
that
do
want
to
help
out
have
something
to
to
grab
on
to
and
go
for
it.
So
the
the
issue
that
I
open
to
just
list
some
basic
ideas
based
on
discussions
that
I
knew
of
at
the
time
and
and
discussions
that
I've
had
with
other
people
is
3210,
so
you
can
kind
of
follow
along
there
or
at
your
comments,
if
you,
if
you
happen
to
have
any
to
that
particular
this.
A
But
what
I
thought
that
we
could
do
today
is
to
actually
go
through
that
list
and
and
talk
about
what
each
of
the
items
are.
If
others
have
ideas
of
things
that
I'd
like
to
see
in
tril
by
all
means
mention
those
here
and
then
hopefully,
we
can
go
through
and
and
prioritize
the
work
that
that's
there
so
that
we
can
have
something
to
go
with.
A
Okay,
so
I
guess
the
way
that
I'm
going
to
approach.
This
is
to
basically
go
through
the
items
that
I
have
in
that
in
that
issue,
one
by
one
hopefully
give
a
somewhat
cohesive,
cocka
cocka
cogent
the
description
of
what
at
what
they
are,
and
then
we
can
maybe
have
some
discussion
on
that.
So
the
first
is
replacing
the
FE
test.
A
While
that
worked,
the
the
challenge
with
that
is
that
each
platform
x86
powers,
the
arm
a,
are
64
whatever
it
happens
to
be
needs
to
write
its
own
set
of
tests.
For
that,
and
in
many
cases
it's
basically
just
duplicated
duplicated
code.
This
isn't
a
great
way
of
doing
it
and
it's
the
kind
of
thing
that
trill
can
actually
do
really
well.
A
So
the
idea
is
to
actually
take
those
tests
and
the
the
the
coverage
that
they
are
basically
replacing
those
tests
with
trill
variants
of
them
and
then
deprecating
them
and
eventually
deleting
them
all
together
and
the
advantage
there
is
that
we
have
one
set
of
tests
that
we
know
is
going
to
be
available
on
all
different
platforms,
as
it
turns
out.
There
actually
is
work
started
on
this
already.
A
If
you
are
aware
that
there's
an
AR,
64,
back-end
ports
underway
and
the
the
way
that
the
team
that's
kind
of
working
on
that
is
is
is
operating
is
under
a
sort
of
a
test-driven
development
model
where
they
are
trying
to
produce
trill
tests
for
each
of
the
back
end.
Evaluators
are
there
but
they're
writing
and
with
with
a
goal
of
building
up
sort
of
a
body
of
test
cases
as
they
go
and
what's
going
to
end
up
happening.
A
Is
that
because
they're
starting
from
scratch,
where
they
are
at
64,
they're,
really
going
to
get
full
coverage
of
all
the
different?
So
I
think
that
this
particular
task
is
going
to
be
covered
by
the
work.
That's
going
on
with
AR
64
right
now,
so
the
only
wrinkle
in
that
is
that
that
work
is
probably
going
to
take
months
to
to
to
complete.
So
we
may
not
have
a
full
set
of
test
cases
for
several
months
yet,
but
that
might
be
just
fine.
So
any
comments
or
thoughts
on
on
that
particular
point.
A
Okay,
the
next
is
allowing
platform
and
capability
specific
tests,
so
they're
actually
already
is
an
issue
open
for
this
particular
item,
so
1843.
The
one
of
the
problems
that
we
see
is
that,
even
if
you
write
a
test
in
trill,
there's
no
way
for
there's
no
way
to
distinguish
whether
or
not
the
the
features
that
are
being
tested
are
available
on
a
certain
platform.
A
So,
for
example,
if
you're,
if
you're
running
a
test
that
uses
Cindy
or
vector
instructions,
there's
no
way
of
determining
at
the
moment,
there's
no
way
of
determining
whether
or
not
those
features
are
available
on
the
test
system
that
you're
actually
running
on.
So
there
needs
to
be
some
smarts
built
in
to
I
think
the
test
infrastructure,
as
well
as
perhaps
even
to
the
way
that
some
of
these
tests
are
written
to
to
allow
them
to
be
selectively
disabled
or
enabled,
depending
on
the
the
features
of
the
target
environment.
B
A
The
next
is
to
remove
the
dependency
on
JIT
builder,
so
right
now,
when
you
want
to
build
trill,
you
also
have.
It
also
has
a
dependency
on
unzip
builder.
That
doesn't
necessarily
have
to
be
the
case.
They
actually
already
is
an
issue
that
kind
of
tracks,
this
particular
kind
of
work
and
allowing
you
to
choose
different
backends
for
it.
I'm
not
super
familiar
with
all
of
this
entails.
Are
you
Leonarda
sure
those
give
a
quick
welcome?
A
So
basically,
what
the
that
issue
was
for
was
trying
to
replace
the
chip
builder
library
with
the
test
compiler
as
a
back-end,
and
the
reason
this
is
needed
is
because,
right
now
the
OMR
compiler
can't
be
built
as
a
standalone
library.
It
needs
extra
pieces
to
be
injected,
and
so
that's
why
you
currently
have
to
add
in
the
pieces,
and
the
original
approach
was
just
to
use
what
JIT
bells
were
provided,
because
that
was
already
available.
A
Then
some
work
was
done
to
make
it
so
that
the
test
compiler
could
be
built
as
a
library
and
making
it
so
that
trill
could
link
against
the
test
compiler
and
include
the
correct
headers
when
needed,
so
that
it
now
runs
with
the
test.
Compiler
instead
of
the
Builder,
and
that
was
mostly
a
still
out
of
prototype
stage,
not
very
complete.
A
All
right,
okay,
so
the
next
item
ahead
on
my
list
was
to
persist
more
of
the
compiler
environment
in
trill
and
provide
the
ability
to
Rican
that
environment.
So
one
of
the
the
goals
of
testing
with
trill
was
to
be
able
to
produce
test
cases
from
the
output
from
the
compiler.
So
at
the
moment
we
can
actually
output
sort
of
a
representation
of
the
intermediate
of
the
nodes
that
build
up
the
intermediate
representation
and
we
have
a
means
of
actually
feeding
that
back
into
the
compiler.
A
But
there
the
the
state
of
a
compilation
includes
more
than
just
the
nodes.
It
includes
things
like
the
flags
on
the
nodes.
It
includes
symbols
and
simple
references,
and
perhaps
some
other
things
as
well,
that
are
important
to
capture
so
that
if
you
want
to
do
a
faithful
reproduction
of
a
of
a
very
specific
compile,
you
have
all
the
information
you
need
in
order
to
do
that
compilation
so
so
right
now
we
can.
We
can
output
node
information,
but
we
can't
really
output
much
else.
So
what
we
do
need
is
some
means
of
persisting.
A
So
about
a
year
more
than
a
year
ago,
I
know
Leonardo
did
try
and
attempt
to
put
some
design
together
for
the
persisting
the
symbol
reference
table.
The
issue
is
actually
now
sorry.
The
pull
request
is
now
closed
in
1552,
but
it
was
closed
more
from
more
due
to
inactivity
rather
than
the
idea
being
invalid.
A
So
I
think
what
will
actually
have
to
happen
is
that
that
particular
pull
request
will
need
to
get
revived
and
perhaps
refreshed
with
with
some
fresh
thinking,
because
we
haven't
thought
about
it
in
a
year
and
a
half,
but
that's
just
one
idea
for
moving
forward
with
a
simple
reference,
persistence,
model
and
I.
Think
it
also
included,
know
flags,
knit
worse
or
separate
one
for
that
yeah,
so
it
didn't
actually
curse.
This
note
flags.
Yet
what
happened
was
the
big
challenge
with
persisting
simple
symbol.
A
Reference
table
is
the
number
of
enums
that
have
to
be
enum,
values
that
have
to
be
serialized,
and
so
a
lot
of
them
basically
have
to
be
just
stringify
and
to
avoid
having
to
manually,
maintain
the
enum
and
an
equivalent
array
of
string.
What
I
did
was
create
a
macro
mechanism
that
kind
of
just
built
out
both
the
enum
and
the
array
of
strings
and.
B
A
B
A
B
A
It's
only
being
used
in
open,
j9,
there's,
certainly
nothing
that
would
stop
it
being
used
in
Omar
right.
It's
the
notion
that
you
can
just
state
specifically
statically
the
address
of
a
something
right,
so
this
symbol,
reference
is
referring
to
eight
things.
That
thing
happens
to
be
at
this
address
and
you
are
allowed
to
peek
into
that
something
during
compilation
right,
so
in
open,
j9,
they're
being
used
for
like
objects,
so
we
have
an
object.
We
know
this
symbol.
Reference
is
pointing
to
something
that
something
is
an
object.
A
C
A
A
Guess
just
a
sort
of
a
quick
brainstorming
other
than
single
reference
symbol,
symbol,
references
what
else
and
the
flags
in
the
knows.
Maybe
the
known
object
table.
What
else
do
we
have
to
Christus
that
can't
reconstruct
I
mean
I,
guess
even
things
like
front-end
questions
and
that
kind
of
thing
yeah.
A
Think
things
like
we
have
an
answer
for
that
yet,
but
well
so
part
of
that
I
think
the
answer
might
be
it.
We
don't
persist
some
of
that.
Instead,
what
we
do
is
provide
well
at
least
not
right
away.
What
we
do
instead
is
provide
mechanisms
for
kind
of
controlling
the
compiler,
a
very
fine-grained
level,
so
that
we
can
set
up
a
very
specific
sequence
of
optimizations
that
will
be
run.
I,
don't
know
that
it
I
were
equal
to
optimizations,
I.
C
A
C
A
A
B
A
B
A
B
B
A
So
another
thing
that
needs
work-
and
this
is
perhaps
one
of
the
more
easier
tasks-
is
to
improve
the
trill
coverage
of
vial
op
codes.
So,
like
I
said,
some
of
those
are
going
to
be
covered
by
the
work
that's
happening
in
with
air
64.
But
but
you
know
perhaps
not
everything
is
may
be
covered,
but
they,
but
though
the
one
examples
that
we
can
sort
of
think
about
and
that
we
already
have
some
issues
open
for
our
switches.
It
doesn't
do
anything
with
exceptions
at
the
moment.
A
Register
dependencies
are
going
to
be
interesting
and-
and
there
is
some
debate
at
the
moment-
about
vector,
op
codes
and
how
much
coverage
we
actually
have
with,
or
we
actually
have
an
issue
for
that,
but
I
think
there's
actually
already
some
support
for
some
form
of
them.
Someone
for
open,
j9
actually
added
some
tests
based
on
those
so
but
that's
sort
of
an
initial
set
of
the
major
ones
that
we
know
that
mean
we
need
extra
coverage
on.
A
Supporting
a
strict
mode,
so
one
of
the
goals
with
trill
was
not
only
to
test
valid,
il
representations,
but
also
to
test
invalid.
Il
representations
to
be
sure
that
the
validate
or
that
we
that
we
use
is
able
to
catch
those
cases,
so
it
can
consume
both
valid
and
invalid,
il
which
is
not
always
great,
because
if
you
really
do
want
to
be
able
to
know
whether
or
not
the
trees,
you're
passing
it
or
invalid,
it
can't
really.
A
You
won't
really
you
that,
so
the
idea
is
to
actually
introduce
some
kind
of
a
mug
strictmode,
where
it
will
report
when
the
IL
that
you're
giving
it
is
invalid
and
probably
98,
plus
percent
of
the
time-
that's
the
kind
of
mode
you
want
to
be
in
so
adding
that
kind
of
a
mode
is.
But
this
is
all
about
either.
One
thought
about
that
currently,
in
normal,
the
so
we
trill
is
set
up,
the
validator
will
always
be
run
any
timely.
A
Any
kind
of
compilation
is
done
with
it's
for
test
or
jet
builder,
or
test
compiler.
So
in
that
sense
it
it
will
already.
So
if
you
gave
a
test,
if
you
write
a
test
case
with
invalid
il
it
will
trigger
some
sort
of
failure.
So
what
I'm
wondering
is
then
does
this
mean
that
what
we
wanted,
something
where
trill
will
actually
catch
it
before
the
il
validator
runs
and.
B
B
A
It's
consuming
it
well,
I
guess
the
value
of
that
would
be
is
a
good.
Do
we
always
expect
the
validator
is
going
to
be
running,
I,
don't
know,
or
would
the
author
being
attacked?
You
have
to
turn
on
the
validator,
so
if
you,
your
strict
mode
could
be
to
turn
on
the
validators.
What
you're
saying
make
sure
that
it's
for
sure
I.
A
Think
the
distinction
here,
though,
is
more
about
like
so
you
may
see
like
sort
of
things
that
is
truly
useful
to
task
apart
from
testing
the
validator
are
those
things
that
are
defined
to
be
valid,
where
there's
no
guarantee
that
the
optimizer
or
the
code
generator
will
do
anything
sensible
with
invalid
il.
Thank
you
reason.
It
currently
does
lots
of
non
sensible
things
with
invalid
iron.
So
I
think
that
the
real
question
is
when
does
validation
happen
during
the
test
is
more
of
the
thing,
because
it's
like
right.
B
A
B
A
A
C
A
Now
I
will
validate
every
transient
immediate
state
that
I
can
lay
my
hands
on
from
yes,
so
that
definitely
a
possibility,
and
that
was
not
how
I
originally
interpreted
that,
but
yes,
you're
right
I'm,
so
currently
I
believe
there's
certain
ops
where
the
validator
is
always
run.
Yes,
because
historic
reasons
we've
had
problems
or,
let's
put
in
his
way
when,
when
any
mere
mortal
tries
to
mess
with
those
you
never
we
end
up
doing
something
wrong.
Okay,
all
right!
That's.
C
A
A
A
B
B
A
A
Well,
I
can
but
because,
if
people
are
going
to
write
unit
laps,
to
exercise
the
code
gen
or
to
exercise
the
optimizer
right,
so
you
don't
really
want
to
have
the
whole
compiler
fire
up
and
everything.
It's
Maura
I
just
want
to
check
my
my
drill
right,
great
yeah,
okay
or
it
Petrille
language
is
updated
later
on,
and
you
want
to
do
some
kind
of
like
global,
replace
that
you
just
want
to
check
if
the
files
are
all
still
valid.
The
heart
of
that
replaced
right.
A
A
A
B
A
A
A
A
Okay,
however,
you
want
to
be
able
to
apply
some
profiling
in
phone
at
whatever
profiler
infrastructure
you're
using
definitely
right,
yes,
I
mean
if
you're
going
to
do
end-to-end
tests.
I
mean
there
are
some
incredibly
competent
code
associated
with
yep
J
profiler
frequency.
Reassociation
logic
is
one
of
those
I
look
forward
to
dealing
with
that
call
graph
graphing
to
know
great.
A
Be
joy,
okay,
so
one
of
the
things
that
trail
can't
do
at
the
moment.
The
limitation
is
when
you
produce,
when
you
produce
a
compiled
body,
to
call
another
thrill
produced
compiled
body
so
basically
a
trail
method
to
trill
method,
dispatch
main
challenge
there
is
that
the
when
you
try
to
call
another
trail
method,
it
doesn't
really
know
where
to
find
the
address
of
it
or
like
there's
no
relocation
or
symbol
information
at
all.
A
So
we're
going
to
need
to
architect
something
there
to
it
to
allow
I
kind
of
dispatch
to
to
occur,
and
it
so
I
was
just
wondering
that
use
case
for
that.
One,
like
there's
opposed
to
having
like
a
compiled
native,
that
you
wanted
to
call
or
an
assembly
sequence
or
Devon.
So
that's
been
the
way
we've
been
doing
it
so
far.
A
Well
like
if,
like,
for
example,
if
you
wanted
to
have,
if
you
were
testing
out
a
certain
kind
of
linkage,
a
new
linkage
and
you
wanted
to
have
method
a
calling
method.
B,
you
want
to
make
sure
that
that
you
can't
necessarily
use
system
linkage
for
both.
Will
anyone
use
your
own
proprietary
linkage,
which
means
that
trail
has
to
be
able
to
produce
both
of
those,
so
a
called
B.
A
B
A
When
you're
looking
at
the
past
call
stuff
right,
that's
current
I
was
just
wondering
if
the
engineering
effort
of
doing
as
able
to
test
linkages
was
worthwhile,
whereas,
if
you
like
say
you
were
testing
a
linkage
right.
So
if
you
create
an
assembly
sequence,
but
does
that
sets
up
the
call?
And
then
you
trill
that
thing
to
get
an
address,
and
you
call
that
in
the
middle
of
that
assembly
sequence
right.
So
essentially
you
set
up
all
the
incoming
arguments
right.
A
B
A
A
So
do
you,
you
did
compiled
some
methods
that
call
some
other
method
that
was
also
get
compiled
right
and
now
you
persisted
both
the
trail
and
you
want
to
rerun
the
sexting
compilation
and
then
be
able
to
actually
run
those
from
that
code.
The
generated
code,
so
yeah
I'm
not
going
to
say
that
you
couldn't
find
a
use
for
it
is.
B
A
We
typically
point
people
at
Leo's,
video
and
and
the
the
copious
examples
of
better
that
exists,
but
I
think
perhaps
a
little
bit
more
softer
gentle
or
kind
of
introduction
to
to
how
to
how
to
do
these
things
as
probably
warranted
and
then
getting
it
added
to
you
know
the
added
to
the
bills.
I
guess
you
could
say
yep
so
documentation
if
we
could
have
a
nice
place
in
the
build
to
put
the
test
so
that
they
run
or
at
least
they've.
C
A
So,
for
okay,
so
figuring
out
how
to
get
this
to
work
and
open
j9
is
going
to
be
a
different
item.
Oh
I'm
not
leave
in
the
context
of
open
j9,
but
it
read.
If
somebody
for
open
Janie
is
tributing,
they
are
asked
to
write
a
tab
yep.
How
do
I
get
the
town
into
the
OPO
more
yeah
bills
with
Annabel
yeah,
yeah
yeah,
because,
okay,
yes,
so
currently
the
story
for
omr?
Is
you
create
the
test?
A
And
if
it's
a
new
new
file,
you
add
that
file
to
the
C
make
if
it's
an
existing
file,
they
will
this
the
test
framework
will
figure
it
out
and
then
the
next
time
you
run
the
PR
bills
or
whatever
continuous
build
that
those
tests
will
be
run.
I
guess
it
is
worth,
though,
documenting
just
how
to
add
to
see,
maybe
where
that,
yes
to
go
so
cuz
I
didn't
know
that.
B
C
C
Compiler
tests
do,
but
we
don't
use
the
injector
framework
because,
on
the
advice
of
people
on
the
slack,
the
injector
framework
is
going
away
and
it's
pretty
much
impossible
because
we're
working
in
a
half
broken
universe
anyway,
where
even
things
like
basic
gdb
doesn't
work,
and
you
cannot
connect
to
anything
because
gdb
server
isn't
written
yet
for
the
architecture
and
so
on,
and
so
on.
So
we're
living
in
a
world
where
the
tools
are
very
primitive
and
fighting
against
you
all
the
time.
C
So
anything,
basically
anything,
helps
right.
So
we
would
like
to
write
our
tests
in
trill
as
opposed
to
just
construct
the
aisle
programmatically
all
the
time,
especially
what
was
said
today
in
the
light
of
the
a
are
64
work
that
there
are
more
tests
real
tests
written
in
in
in
that's
the
problem
right
now
for
us
is
that
we
cannot
even
run
it
at
all,
because
there
are
too
many
dependencies
on
things
working.
C
C
B
C
When
it
comes
to
documentation,
it's
like
well,
what
are
the
use
cases
like
for
whom
is
this
documentation
for
and
and
and
I
guess
we
can
take
like
some
initial
pieces
of
that
to
say:
okay,
well,
one
use
cases
for
you
know
using
trill
for
this,
and-
and
here
is
the
caveat
we
we
got
into
and
and
from
it
from
you
know,
approaching
from
like
little
zero
point
in
here.
Here's
what
we
did
and-
and
you
know
so
others-
don't
step
on
the
same
rates
if
that
makes
any
sense.
A
Yeah,
so
it
does
so
I
mean
thanks
for
the
insight
into
the
the
project
that
you're
working
on
and
the
and
and
some
of
the
problems
you're.
Having
so
I
mean
in
in
terms
of
the
dependencies
I
mean
I
think
we
are
all
in
agreement
that
we
need
to
make
as
few
dependencies
that
having
tril
depend
on
as
few
things
as
possible
is
is
ideal
for
your
particular
circumstance.
C
C
I
like
off
of
hand?
I,
don't
know,
but
definitely
we
would
like
to
try
this
and
work
on
this,
because
this
mode
of
just
manually,
constructing
the
aisle
all
the
time
and
and
maintaining
this
out
of
the
both
of
the
main
tree.
This
is
kind
of
doesn't
go
very
far,
I
mean
it.
You
know
if
you
are
just
looking
for.
You
know,
testing
something
simple
with
three
or
four
nodes:
it
kind
of
works,
but
then
we
need
something.
C
You
know
something
like
drill
and
especially
it
to
integrate
with
other
tests
that
people
are
writing,
for
example,
in
the
case
of
air
64
architecture.
That
would
be.
You
know
it's
one
thing
to
say:
okay!
Well,
what
do
I
need?
What
kind
of
you
know
what
makes
a
fully
working
back-end
when
you
already
have
a
bunch
of
that
have
to
pass
or
you
when
you
are
writing
a
set
of
tests
like
that
with
somebody
else
working
on
another
platform?
That's
a
much
more
appealing
story:
okay,.
A
Think
for
developers
such
as
yourself
that
are
kind
of
coming
to
this
project
or
have
never
actually
written
the
test
case
before
using
trill.
A
lot
of
the
knowledge
is
kind
of
you
have
to
kind
of
go
searching
for
it
yourself
or
watch
a
video
or
look
at
example
tests.
But
nothing
really
that
says,
look
I
need
to
write
a
test
that
uses
memory
and
does
you
know
next
y
and
z,
and
then
therefore
this
is
the
this
is
sort
of
what
it
should
look
like.
This
is
where
I
should
put
it.
A
This
is
how
I
should
get
it
invoked
in
my
environment
when
I
want
to
do
the
testing,
it
is
providing
you
that
very
specific
and
simplified
information
for
that.
So
I
think
that's
going
to
help
you
for
testing.
If
you're,
specifically
interested
in
testing
the
code,
generator
I
mean
I.
Think
that
what
you
really
want
to
make
sure
is
that
your
I
all
know
that
your
il
that
you're
injecting
is
getting
straight
through
to
the
back
end,
so
that
you
can
that
start
executing
some
of
those
the
code
that's
being
produced,
I!
Think.
A
Of
the
five
organizations,
but
one
of
the
additions
that
trail
made
was
the
idea
of
the
mock,
optimization
strategy
that
lets
you
dynamically
set,
which
optimizations
are
going
to
run,
and
you
can
just
give
it
an
empty
list.
Okay,
in
which
case
things
will
go
straight
to
the
code
generator
and
even
then
you
can
tell
ask
it
to
skip
cogeneration
entirely.
Okay,
so
I'm
sure
that
was
not
known.
That
is
not
known
to
most
people.
A
So
that's,
probably
that's,
probably
one
of
the
probably
one
of
the
pieces
of
information
that
does
need
to
get
communicated
out
for
sure,
so
I
I
certainly
hear
what
you're
saying
I
know
that
we
need
to
do
more
to
make
this
more
consumable,
which
is
kind
of
why
we're
we're
trying
to
revitalize
this.
This
whole
effort
with
with
with
trail
I,
mean
a
lot
of
it,
is
being
driven
as
well
by
a
r64
and
some
of
the
experiences
that
they're
going
through
right
now
and
I
think
you're,
probably
going
through
the
same
experiences
as
well.
A
A
A
Okay,
the
last
thing
that
I
had
in
my
list
wasn't
really
one
that
I
had.
It
was
something
that
Matthew
previous
developer
here
had
suggested
and
I'm,
not
exactly
sure
what
he
meant
by
everything
here,
but
I
think
he
had
some
concerns
around
the
values
that
have
been
chosen
for
the
constant
values
template
that
gets
that
and
that
we
use
to
generate
the
constant
inputs
to
some
of
the
tests
and
whether
or
not
the
choice
of
those
constants
is
actually
the
best
and
they're
actually
exercising
all
the
corner
cases
that
need
to
get
exercised.
A
A
Yeah
I'm
for
the
constant
values
part
that
was
a
helper
I
created
just
kind
of
to
get
things
started.
My
expectation
was
that,
just
by
using
good
testing
practices,
if
you
have
an
edge
case
for
your
particular
case,
you
will
add
that
to
either
what
counts.
Value
already
provides,
or
just
create
your
own
list
of
inputs
that
exercises
the
test
cases
you
need.
B
A
So
this
doesn't
actually
built
or
trill
doesn't
actually
build
and
I'm
going
to
roll
out.
So
I
haven't
had
this
myself,
so
I'm
going
to
rely
on
the
testimony
of
others,
but
so
trill
doesn't
actually
build
on
every
build
compiler.
That
Omar
actually
supports
because
of
the
use
of
some
C++
11
or
later
features
7
suppose
for
some
features
that
aren't
available
on
most
platforms.
A
So
I
think
the
the
request
here
is
to
actually
find
a
way
of
getting
trill
to
build
on
every
compiler
that
Omar
actually
supports,
and
that
way
it
would
be
more
available
across
the
board.
So,
presumably
what
that
means
is
barring
upgrading
the
build
compilers
is
to
actually
remove
some
of
the
C++
11
features
that
are
causing
problems.
Do
you
have
inton
Leonardo?
A
Do
you
happen
to
know
what
the
I
did
at
one
point,
but
as
far
as
I
know,
everything
I
was
aware
of
that
was
breaking
bills
has
been
resolved
already
good,
so
it's
been
a
very
long
time
since
I've
run
on
trail
on
anything
other
than
Linux.
So
this
might
be
a
matter
of
them
trying
to
get
it
to
build
under
on
the
various
platforms
that
that
and
basically
documenting
what
we
see
is
breaking
yep
and
that.
A
A
B
A
Okay
and
then
I've
got
three
other
ones
for
Matthew
that
he
added
to
the
issue
already.
One
is
I,
think
we've
already
kind
of
covered
that
it's
really
the
ability
to
output
trill
and
use
it
to
build
regression
tests.
But
in
order
to
do
that
properly,
you're
going
to
need
to
persist
more
than
just
the
node
information.
That's
there
so
I
think
we've
talked
about
that
one.
Quite
a
bit,
so
I
think
we're
in
agreement
that
that
needs
to
get
used
to
get
done.
A
B
A
A
Instead
just
write
trill
directly
to
a
file
and
be
able
to
write
kind
of
annotations
right
in
the
file
that
describe
how
the
test
case
is
going
to
behave,
and
then
the
tool
resetting
and
actually
constructs
and
runs
the
test
case
from
that.
Okay.
So
it
would
be
a
much
more
direct
way
of
writing
a
test
case.
I.
A
Think
it
also
provides
certain
features
for
injecting
assert
so
that,
for
example,
if
you
were
writing
il,
you
would
be
able
to
inject
an
assert
that
some
particular
node
is
going
to
persist.
After
all,
optimization
it
doesn't
get
folded
away
or
something
do
you
think
supporting
something
like
that?
A
Can
that
be
done
later
or
do
we
have
to
start
changing
the
architecture
of
trill
now,
in
order
to
be
able
to
support
that
so
that
we
have
a
whole
list
of
other
things
that
we
want
to
get
done?
I
am
doing
probably
ahead
of
I
think
that
bug
can
be
done
in
parallel,
okay
right,
because
a
lot
of
new
basic
infrastructure
is
still
going
to
be
needed.
A
In
both
cases,
this
would
really
just
be
creating
at
least
the
web
visualizing
it
right
now
you
would
be
creating
as
essentially
a
new
front-end,
where,
instead
of
being
Google
tests,
do
you
have
this
other
more
complete
C++
program
that
is
essentially
going
to
end
up
doing
the
same
thing.
Just
the
data
Riven
would
read
what
it
needs
to
do
from
a
file
and
figures
everything
apps
out
and
sets
it
up
to
execute
the
test.
A
A
A
Well,
what
I
think,
specifically
with
that
would
we
will
have
to
think
about
is
how
we're
going
to
use
that
to
test
something
right.
So
before
we
start
thinking
about
how
we're
going
to
get
drill
to
handle,
invalidating
an
assumption.
What
are
we
actually
testing?
That
requires
invalidating
an
assumption
and
that's
going
to
be
I
think
what
drives
that
work,
mostly
I,
think
we'll
be
worried
about
oh
gosh.
That
would
have
been
my
guess.
Yes,
because
it's
the
single
hardest
thing.
A
So
just
for
the
sake
of
argument,
though,
for
something
like
testing
code
patching,
would
we
really
need
to
be
able
to
violate
a
runtime
assumption,
or
could
we
would
it
be
possible
to
just
pull
out
that
code,
patching
mechanism
and
just
when
you
run
in
some
way
or
so
you
need
some
way
of
poking
that
code,
patching
mechanism
and
I
think
we
be
invalidate
the
assumption.
Invalidation
is
sort
of
what
ends
up
poking
the
right,
but
what
I'm
asking
is?
A
Okay,
so
I
guess
we
have
a
looked
less
than
half
an
hour
left.
Are
there
any
other
ideas
or
thoughts
about
trill
that
people
want
to
kind
of
put
out
there
I
guess
at
the
moment,
I
don't
mean
I'll,
take
any
idea,
but
I
guess
I'm
more
thinking
about
short
term
things
that
we
can
immediately
focus
on
to
make
things
better.
A
A
A
Removing
the
dependency
and
jib
builder
I
mean
people
have
already
come
across
this
problem.
I
would
and
that's
very
high
priority,
and
because,
especially
now
that
jib
builder
is
evolving
yes,
yeah
yeah,
it
was
becoming
a
lot
less
feasible
to
have
the
two
linked
together
right,
so
that
one's
even
pushing
like
top
priority
trying
to
get
a
task.
Yes
right
now,
it
already
has
some
hacks
in
it
to
get
around.
The
fact
of
ship
builder
has
its
do,
front-end
to
API
generator
and.
A
A
C
A
A
A
Okay
and
then
the
other
two,
a
textual
test
case,
the
the
lit
work
and
then
perhaps
other
dynamic
language
features,
I
put
them
as
well.
They're
longer-term
items,
yeah
they're,
longer-term
items,
okay,
so
okay,
so
what
I'm
going
to
do
is
make
sure
that
there
are
issues
created
for
all
of
these
items
with
at
least
a
reasonable
description
of
what
they
actually
mean.
I
also
know
that
there
are
some
issues
that
others
had
opened
already
in.
A
There's
no
more
issues
open
for
trill
ideas,
I
guess
I
should
go
through
those
and
get
them
as
well.
I
think
they're
kind
of
some
of
them
may
be
covered
by
these
already.
Some
of
them
are
kind
of
like
bugs,
or
that
kind
of
thing
so
just
need
to
make
sure
that
that
list
makes
sense
at
the
moment
and
that
those
ideas
are
at
least
represented.