Commit Graph

8 Commits (1c06605188be8aaec5b0bd39f8edf5284b4f954b)

Author SHA1 Message Date
Mike Gerwitz b30018c23b tamer: xmli reconstruction of desugared interpolated metavars
Well, this is both good news and bad news.

The good news is that this finally produces the expected output and
reconstructs sources from interpolated values on the ASG.  Yay!

...the bad news is that it's wrong.  Notice how the fixpoint test is
disabled.

So, my plan was originally to commit it like this first and see if I was
comfortable relaxing the convention that `<param>` nodes had to appear in
the header.  That's nice to do, that's cleaner to do, but would the
XSLT-based compiler really care?  I had to investigate.

Well, turns out that TAMER does care.  Because, well over a decade ago, I
re-used `<param>`, which could represent not only a template param, but also
a global param, or a function param.

So, XML->NIR considers all `<param>` nodes at the head of a template to be
template parameters.  But after the first non-header element, we transition
to another state that allows it to be pretty much anything.

And so, I can't relax that restriction.

And because of that, I can't just stream the tree to the xmli generator,
I'll have to queue up nodes and order them.

Oh well, I tried.

DEV-13163
2023-07-17 14:20:05 -04:00
Mike Gerwitz 9eeb18bda2 tamer: Replace wip-asg-derived-xmli flag with command line option
This introduces `xmlo-experimental` for `--emit`, allowing the new parser to
be toggled selectively for individual packages.  This has a few notable
benefits:

  1. We'll be able to conditionally compile packages as they are
     supported (TAMER will target specific packages in our system to try to
     achieve certain results more quickly);

  2. This cleans up the code a bit by removing awkward gated logic, allowing
     natural abstractions to form; and

  3. Removing the compile-time feature flag ensures that the new features
     are always built and tested; there are fewer configuration combinations
     to test.

DEV-13162
2023-06-13 23:23:51 -04:00
Mike Gerwitz e6325c4c1d tamer: tests/xmli: Estimate tamec time in milliseconds
Going higher than that doesn't make sense because we're in shell and
invoking commands all around this, so even milliseconds isn't going to be
entirely accurate here.  However, what I am more interested in is observing
time relative to other runs; this isn't intended for profiling, but for
eyeballing unexpected behavior.

DEV-13708
2023-03-10 14:27:59 -05:00
Mike Gerwitz b84ee356d5 tamer: tests/xmli: Formatted and more informative output
There's a lot to look at, especially in the event of failure.  Further, I
wanted to add additional statistics that could be eyeballed.

Right now, tamec is too fast (at least on my machine) for the precision of
/usr/bin/time: we need milliseconds, but we only get hundredths of a
second.  So it'll all show as 0:00.00s.  Which is okay, for now; it just
shouldn't exceed that. ;)

DEV-13708
2023-03-10 14:27:59 -05:00
Mike Gerwitz a261e75fe0 tamer: tests/xmli: Break apart single test case
This would have gotten unwieldy as time goes on, and already made looking at
traces very difficult.

DEV-13708
2023-03-10 14:27:59 -05:00
Mike Gerwitz 286f4cb679 tamer: tests/xmli: Reduce output on failure
This won't try the fixpoint test if the prior one fails, which will always
cause that one to fail.  And it further won't attempt the diff on
compilation failure.

DEV-13708
2023-03-10 14:27:59 -05:00
Mike Gerwitz 6cbcdb1774 tamer: tests/xmli: Add fixpoint test
See documentation for more information.

DEV-13708
2023-03-10 14:27:58 -05:00
Mike Gerwitz 82915f11af tamer: asg::graph::object::xir: Initial rate element reconstruction
This extends the POC a bit by beginning to reconstruct rate blocks (note
that NIR isn't producing sub-expressions yet).

Importantly, this also adds the first system tests, now that we have an
end-to-end system.  This not only gives me confidence that the system is
producing the expected output, but serves as a compromise: writing unit or
integration tests for this program derivation would be a great deal of work,
and wouldn't even catch the bugs I'm worried most about; the lowering
operation can be written in such a way as to give me high confidence in its
correctness without those more granular tests, or in conjunction with unit
or integration tests for a smaller portion.

DEV-13708
2023-03-10 14:27:58 -05:00