This isn't fully tested yet, since I don't currently have fileVersion 2 samples.
It has been tested with 200X devices and doesn't change behavior there,
but the slice parsing immediately bails, so it's not really being exercised.
It seems very weird that "slices", whatever they are, would only show
up on bricks, the least capable devices. This needs more investigation.
This looks discouragingly redundant at first glance, but eventually
the import stage will probably be unified across all families, leaving
the parsers the only difference. That'll happen after all summary
importers have been split.
This looks even uglier than the F5V3 event split for now,
since portions of the fileVersion 3 parsing are still stuck in
PRS1Import, and can't be reasonably moved until all the parsers
are split into PRS1DataChunk.
Also, PRS1ParsedSettingEvent may be the wrong abstraction. That's
a first attempt, so that it can inherit PRS1ParsedEvent's notion
of gain and unit, and because m_parsedData is currently a list
of PRS1ParsedEvent pointers. But it has no notion of time (start=0)
and requires yet another enum to specify which setting it
represents.
This should be revisited once all the parsers have been split
and the summary parsing can be examined in more detail.
This doesn't look much prettier yet, since it requires double the
switch statements, but the expectation is that once all event
parsers are split out from import, the import routines will be
identical among all machines, and can then be consolidated.
Regardless, it's important to drive a wedge between file parsing
and the internal database structure.
Each input file's chunks get emitted into a single output YAML file. As parsing
gets separated from conversion/import, this will allow for testing and
examination of the parsed input files before they are transformed into
sessions.
Now that we check header checksums, it uncovered a problem parsing 1160P event
headers. It turns out that the 1160P uses a "waveform" header for its .002
events files. So we can't use the file extension to decide which header to
parse, but there's a flag in the standard header that seems to reliably indicate
a waveform header. The 1160P events are listed at fixed intervals, as are
waveforms, so the flag has been named "interval" rather than "waveform."
The 1160P event headers have more than 2 signals in the header and an interval
longer than 1sec. This clarified the meaning of multiple waveform header fields
that were previously being parsed incorrectly.
Limit screenshots to OSCAR's application window under macOS.
Use main window geometry as basis for screen capture rectangle, removing
the need for resizeing hacks.
Tested on:
* macOS 10.14
* Ubuntu 18.04
* Windows 10
It was previously working in a false-positive state, where it would behave as
expected if you ran "make" from within a subdirectory of the git repo. If you
ran make anywhere else, at least diff-index would break.
Change -C to --work-dir to work on earlier versions of git.
Add "+" to the revision number if there are uncommitted changes.
Only rewrite the git_info.h if there are changes, so that make doesn't think the file has changed.
This fix also seems like it cleans up some of the weird session IDs. It appears
that session IDs were sticking around after each machine, adding those
IDs or sessions to subsequent machines in that run of the test. Since the
test was being run piecemeal while under development, this produced
different behavior when being run with different segments of the data.
This has already exposed many limitations, and possibly some memory trampling. Before this will work as
a true regression test, we'll need to address both of those, so that this produces reliable, reproducible
output.
Currently there is a very messy tangle of dependencies between
loaders, machines, sessions, and profiles. Right now the
simplest way to create a test loader instance is to create
a test profile, under which the machine and session instances
will exist.
