This uses the miniz library, which is self-contained in a single
.c/.h pair and has an MIT license.
Swapping out the zip library should be fairly straightforward
if ever necessary.
Version number in Windows oscar.exe has first three numbers same as string and fourth as 0
Version number in Windows installer has first three numbers same as string and fourth indicates build type:
0 = release, 100=alpha, 200=beta, 300=gamma, 400=rc
Release/RC version: no sandbox
Testing releases (tagged prerelease version): -test
Development builds: -branchname (if at the head of a branch)
-(commitid) (if in a headless state)
And in the unlikely event someone tries to build a non-release version
from a tarball instead of git, its sandbox will be "-unreleased".
The bash script now adds a #define if the current checkout is
exactly on a tag, and it leaves all #defines empty if building
from a tarball.
The batch file still needs to be updated.
This removes git dependencies from everything except for version.cpp,
and removes the associated interfaces in version.h.
Since the full version string contains the branch and revision
number where applicable, the build information no longer needs
to report branch and revision separately. It also now queries
version.cpp for a more consistent and reliable build time.
Debug output of build information is also now more consistent with
less redundant code.
The full version now includes the build/git information embedded within
it as build metadata according to the Semantic Versioning 2.0.0 spec,
for example: "1.1.0-beta-1+branch-name-a1b2c3d".
Now the full version string, with all detail is always displayed
EXCEPT for release versions, in which case just the simple version
number ("1.1.0") is displayed in the primary UI.
- Main window title: simple version for release versions, full version
string otherwise
- Notifications: same as main window title
- System tray: same as main window title
- About window title: same as main window title
- About window release notes: always include full version string
- Reports: always include full version string
- Under the logo (about dialog, profile selector, new profile
window): removed, as it is largely redundant and can
interfere with the window geometry.
- Database upgrade alert: same as main window title
- Database newer alert: same as main window title
The full version string is also included within the preference and
profile .xml files, but because build metadata is ignored in version
comparisons, differences in builds will not cause any spurious
alerts. However, changes in prerelease versions will continue to
be significant, as they should be.
Previously it was reporting spurious information when the humidifier was
disconnected. Now it only reports settings details when the humidifier is
connected (the only time they're valid.)
It also now reports the humidification mode (fixed, adaptive, or heated
tube), and the heated tube temperature when appropriate.
No real change to functionality, other than confirming correct behavior,
documenting observed data and adding flags for anything new.
The ParseHumidifierSettingF0V4 function has now been renamed to
ParseHumidifierSetting60Series for accuracy.
Accordingly update ParseHumidifierSetting50Series to add a parameter
controlling whether parsed settings should be imported or not,
consistent with all other PRS1 humidifier parsers.
The ParseHumidifierSettingV2 function has now been renamed to
ParseHumidifierSetting50Series for accuracy, and the code and
parameters which had been used when 60-Series machines (incorrectly)
relied on it has been removed.
The last statistics events in each slice are now correctly imported.
Previously, in the surprising edge case where two statistic periods are
reported with the same end-of-slice timestamp, they were both being duplicated
when marking the end of the slice.
Also, there were scattered instances where the final statistics in a slice
weren't being imported at all or were being imported incorrectly. These are
now fixed as well.
No change in import behavior yet, but this will be needed to deal with a weird edge
case in which two statistic periods are reported with the same end-of-slice timestamp,
the first one intended to cover the preceding 2 minutes, the second one presumably
intended to cover the fractional second after the previous interval, though all
values are 0, so it's hard to be sure.
Because opening a profile already had a progress dialog open, the import
process during a forced rebuild wasn't appearing, so it would look like
OSCAR was hanging for as long as the import took.
Temporarily hiding the profile progress dialog resolves the issue.
This was bumped once already after the previous release version, but
bumping it again now will make sure that all beta testers are working
from data based on the current state of the PRS1 loader.
Settings are written as soon as a day is viewed, so anybody who viewed
their PRS1 data prior to the previous commit would have settings with the
channels expressly disabled. Changing the channel ID forces them to be
treated as new, and thus default to on.
Also add support for parsing and proceeding past a previously
unseen F5V0 event, though for now it's just getting swallowed
since its meaning isn't entirely clear.
This adds BND flagging to machines without waveform data, such as F3V3 (1160P)
and bricks (250P, 200X), as well as sessions for which waveform data was
unavailable. It also catches BNDs at the end of a session, which were
previously missed.
By duplicating the last reported event at its originally reported
event (clamped to the slice end time for F3V3), charts will now
correctly show the value during that last interval.
Also fix some slice sanity checks so they don't yell when F3V3
skips an event chunk.
This now correctly shows gaps in therapy and statistics when the
mask is off. It also corrects the initial statistics for some sessions
to 1 second later, when the initial mask-on slice begins 1 second
after the session starts.
Weird zero-length PB and LL events are now dropped on import, since
they wouldn't get drawn anyway and seem to be peculiar artifacts.
If there are no mask-on slices of nonzero duration, then there's not any
meaningful event or waveform data for the session. There is occasionally some
fragmentary data, but it's always less than 1 second.
When such fragmentary waveform data is present, it only contains 1-3 nonzero
samples, corresponding to 0.2s - 0.6s of data, which suggests that the
mask-on slice was really that long rather than precisely 0. As a result,
it appears that the timestamps of the mask-on/mask-off slices are just the
current value of the machine's internal clock, which only has 1-second
resolution.
But rather than embark on herculean efforts to derive a sub-second slice
duration from (only occasionally present) event or waveform data, we just
treat the session as having no detailed data.
Because summaries used to be parsed incorrectly, there was a bunch of ugly
logic that was designed to infer the session start & end times from other data.
Now that the summary parsers work, that can all go away. The only change to
imported data is that sessions ending with the mask off are now longer, to
reflect that extra time before the machine was turned off.
This now correctly shows gaps in therapy and statistics when the
mask is off. It currently only works for F3V3, since it has a
separate event chunk per slice. Other machines, which have only
a single large event chunk, will need to track the slices as
they import events.
This also highlights the issue with the last statistics in a
slice: only one data point is imported indicating the start of
a measured value, and so it appears that the data terminates then
instead of at the end of the slice (seconds to minutes later).
This fixes a regression introduced by fda9fcd1, which fixed import for
all the other machines but broke F3V3.
Also move the generation of HY/CA/OA events out of the parser and into
the importer.
This will let us create "duplicate" statistical events at the end of
a session (and eventually slice) to reflect the end time of each
measurement channel.
