Before xous-ipc's fixed-length string guaranteed this thing
fit into a single page. Now, we can send potentially unbounded
amounts of text between servers.
I don't think it makes sense to send more than a few k of text to
render on the screen at once, given our screen sizes, so I've added
a patch that truncates the text to the previous length that things
would truncate to.
The behavior is the same as before, except that you will
over-allocate memory on the heap in the sending process
as you shove more string data into a TextView than can be rendered.
Previously, the TextView would just truncate the data and discard
the data.
The truncation happens at the point where you try to hand the
record off to another process, so, one could in theory try
to make this recoverable by adding a layer that splits the
textview into more manageable chunks or pages the data, but that
is an exercise for another day.
the implementation relied on a quirk of xous-ipc where the message
ID is 0 for string send/receives. This cleans it up so that the API
is transparent and consistent with other API calls in the system.
And I did it! and it's now fixed.
I was using xous-ipc String to make a fixed-length string in a
structure that's not strictly an IPC structure.
The solution to this is to just implement a fixed length string
directly.
I think this is safe to do because no strings can be directly
serialized into the PDDB's structures. The place to check for
this is inside the backend/ directory. For example, `DictName`
is where the name field is serialized into a structure that
goes onto the disk. It's explicitly length-checked.
What this means is that we could have calls into the pddb crate
with invalid length strings, however, if you check the lib
implementation, all of the APIs also pre-flight the length of
arguments to ensure they fit into the destination string.
So mostly what we're losing is the constraints on the intermediate
IPC representation, but the length is still checked on either side.
a bunch of lines are shorter or different length now which
triggers a mandatory reformat. this patch cleans that up,
so that going forward the manual rework patches are clearer and
not tied up with formatting patches.
note for more review by bunnie down the road to make sure
that I have not changed any behaviors accidentally in fixing
the loss of Copy on a core structure
The original loop takes advantage of the copy-trait that is
no longer available. I think the intent of the loop was to
mutate a field within the copy through each iteration so you
can update the prompt to handle field validations that failed
without re-allocating the ManagedPromtWithTextResponse structure.
This has been rewritten to alloc that each iteration to avoid
the borrow error, and instead the `prompt` itself is a string
that's initialized with the initial prompt message and is updated
on each iteration if the form validation fails.
@gsora git seems to say you wrote this code, maybe I could use
your help to review this patch.
