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.
the u64 in and of itself is meaningless, without the context
from the PDDB that adds the offset to wall clock time plus
time zone. This is glued together by the time.rs stub inside
the status service.
