a lot of re-import warnings have cropped up. While I appreciate
their studiousness on this, the problem is that removing some
of these exports in the API crate could mean that future users
who want access to some API features that aren't used in this
configuration are now unaccessible.
I think it's not a huge problem at the moment, just spam-cleaning
the warnings because there are too many to deal with carefully
at the moment.
Regenerate the font files after adjusting the template to generate files
that will not get changed by rustfmt.
Signed-off-by: Sean Cross <sean@xobs.io>
Generate code that can be put through rustfmt without being altered.
This removes an issue where the font tables can be rearraged by simply
running `rustfmt` on the repository.
Signed-off-by: Sean Cross <sean@xobs.io>
The `codec` seems to hang sometimes during `Setup8kStereo` at boot.
Did not get to the bottom of it, but suspect that the RTC I2C init
sequence is interfering with the codec init sequence. This might
be resolved while also fixing #467, but for now, a short delay
on boot works around the problem.
we need to tag out a release, so we're temporarily forking
`smoltcp` at its current head, testing it, and holding it
there until a full release is tagged out that captures all
of the good stuff that has been going on in that repo since
June.
by marking the EC as ready after all the update checks are done
we can ensure that the PDDB mount dialog does not attempt to come
up during an EC update.
The nominal purpose of this is to allow other services to delay
interactions that could interfere with an EC update.
Note that anyone could call this routine and mark the EC as not
ready, since the llio block is not secured and the API is public.
I don't think it's a security problem, but is a DoS vector.
- remove modal pop-up for wifi connection, and replace with
busy animation
- specify units of delay in the constants (_MS to indicate milliseconds;
this is a convention I'm trying to adhere to)
- partial progress on debugging why the animation isn't running
(value of animation variable is not being passed back at the GAM layer).
Also a general note on coding styles that probably is going to cause
confusion now that more people are contributing to the code base.
Generally, when a lot of "generic" library functions fail, we've been
passing an error message up the stack. However, these functions are
actually meant to be infalliable, and when you kick the error up the
stack you just end up with a panic at an unhelpful location (because
you finally catch the error only at the main loop or something and
by that point there's nothing you can really do about it but panic,
since it's supposed to be an infalliable operation).
As a result I have been trying to tamp down on needless error propagations
and having them fail with a unwrap or expect at the point where the
abstraction should be infalliable. This helps in debugging the actual
failure root cause because you're closer to the line of code that
actually broke, instead of just some line at a generic error handler.
Of course if you build with stack unwinding the top-level unwraps are more
useful because you can peer down into the call chain, but even then,
with the limited screen real estate I think deeply nested failures
would probably overflow any panic display. So even with panic unwinding
I think we stil want to keep the root cause within a few stack frames,
instead of errors being passed up sixteen levels of abstraction before
finally dying.
This only applies to things that are meant to be truly infalliable,
like syscalls that should not fail, or like unpacking a buffer or
memory message that has already been allocated. In this case the errors
are more like asserts, and are helpful if they fail at the line where
they break instead of being passed up the call stack (which was the
original architecture).
Probably I should add a note about this to the Xous Book.
XOR op should not be usable to create fake security boxes
but it also looks really ugly to have it defaced.
This small tweak makes the XOR function look decent for the initial
purpose of the function (chat status bar wait indicator).
Eventually, this will be a controversial decision, but I'll kick
that down the road.
