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.
this it to avoid abusing the primitive to create inverted text
(for secure UI elements only). It does degrade from the aesthetics
of a busy bar but it is a computationally efficient way to patch
around the concern.
This is just the TextView primitive with a "state" variable added
that controls how far the strips should march across the screen.
Users can specify with or without a bounding box.
The exact location of the text within the bar depends on the
BoundingBox option picked.
The primitive computes the total region to animate based upon
the typesetting engine's output. Thus it is not recommended
to "compress" the amount of whitespace allocated to the animation,
because it can cause the animation to have artifacts due to
whitespace overflow of typesetting.
I noticed that I actually hadn't changed anything in the xous-rs
directory, so I got rid of the patch. I also removed a few files
that weren't being used. Furthermore, I noticed that a couple of
random files were different from upstream so I changed them back.
I also modified the README slightly.
unwrap on a routine always returns None, so the unwrap() has no meaning
(probably originally introduced just as a way to get match arms to
have the same return result without thinking too much about it).
Every entry into the sleep_heap() should be unique. Any insert()
call that returns a value means we're going to drop a wake-up event.
Add an assert()! that will trigger a panic if this invariant is not
met.
Add back in the ability to pre-unlock a Mutex. This is used for slow
path unlocking without needing to wait for a response.
Signed-off-by: Sean Cross <sean@xobs.io>
This rewrites the Mutex and Condvar backends after gaining a better
understanding of how they're supposed to work.
Additionally, the Ticktimer backend implementation has changed:
* There is now a `recalculate_sleep_offline()` call that skips starting
and stopping the ticktimer. This is an unsafe function because the
user must manually manage the ticktimer state. It is used to perform
multiple operations while the ticktimer is unscheduled.
* Ticktimers now deal in `TimerRequest` types rather than raw `i64`
types. This is a newtype that is distinct from the previous `i64`, but
should behave largely the same.
* Waking a Condvar now reports the number of items that were awoken,
provided the requester sends a blocking scalar value. This allows for
backwards compatibility.
* Attempting to wake 0 Condvars now wakes all pending Condvars.
* We no longer keep track of lock-then-unlock for Mutexes, nor
notify-then-wait for Condvars. This makes those cases undefined
behavior, which puts us in line with Posix. Don't unlock mutexes that
haven't been locked, or notify Condvar recipients when nobody is
waiting.
Signed-off-by: Sean Cross <sean@xobs.io>
