- add a "dangerous debug" command that only exists when the feature
"pddbtest" is enabled. The feature can't work on real hardware, but
still, it enables things like dumping of the database and storing
the keys for inspection, so it's isolated in a feature that prevents
the code from being compiled in the first place when it's not selected.
- fix a bug where keys that have zero length aren't being created
correctly. this is a common use case for reserving some space for
data that isn't yet available.
previously blitstr2 is using usize for x/y coords, which means that
for layout purposes points could not go to the top or left boundary
without causing arithmetic overflow. Of course, you want to render
everything on-screen, but, as we have multi-line text with overflow
possibility, it's reasonable to be able to use negative coordinates
to locate text boxes that flow into the visible region.
This of course means that occassionally you can come out with
things like "negative widths", but even then, there can be reasonable
uses for this as an intermediate in calculations that ultimately
arrive at a positive result.
modals don't work when triggered in the status thread in hosted
mode (but they do, somehow, on real hardware). I think this
is an actual locking problem that would exhibit itself if
we had a true multiprocessor system, but since real hardware
is a single processor it doesn't show.
now you set time in local time. If time zone hasn't been set already,
it'll prompt you to enter a time zone.
The main oddity is now that you have to know your time zone as
an offset from UTC. This can be fixed later with a proper symbolic
TZ to numeric mapping, but, that's actually a surprisingly hard
feature to implement.
std::time::SystemTime returns time in UTC.
That's great, but a lot of times we want local time.
Unfortunately, we can't use `chrono` to do that, because
chrono figures out what your time zone is usind `libc`, which
is a thing Xous doesn't have.
the `LocalTime` server is Xous' solution to that problem. it
returns the corret time offset based on the time zone.
You can still use `chrono` to convert the returned time into
strings and to compute durations.
Time is replaced with error messages that indicate either time has not
been set ("Set Time"), or the PDDB has not been mounted (it says
"Login?"), if there is an error. otherwise it displays time
in the local timezone.
Time setting is kind of awful in that you have to enter the time
as UTC. And then a timezone as an offset in hours from UTC. It's
very bare-iron.
The test routine for shellchat "cheats" and accesses the I2C block
to test the RTC during factory operations. This is not aesthetic
and is also potentially a security hole since we don't want less
trusted stuff willy-nilly playing with i2c.
Rewrite to
1) remove i2c references from shellchat
2) replace RTC calls with the newer non-dangerous llio calls that are
limited to read out the initialized time variables.
I did observe some PDDB corruption that happened today that looks
ostensibly linked to a record that didn't sync up with the disk,
so, let's be safer and sync everything. We can work on optimizing
performance after correctness is guaranteed.
The problem with the current is_mounted() call is that it blocks
while the PDDB is requesting a password or actively formatting
(otherwise it doesn't block). It's actually just...partially blocking.
That doesn't cut it for libstd-linked system services that need to run but
before the PDDB comes up. In particular, we need to be able to respond
to time queries *somehow*, even before our timezone and offsets are
loaded from the PDDB.
I considered doing a callback mechanism for mounting, but this
is kind of complex and probably not worth it. Instead, a separate
thread that can return the value of a single boolean revealing
the mount state of the PDDB is created, and you can create an
object that's capable of inspecting that boolean.
