VariablesView::ModelNode:
- Only check if a variable's value has changed if we actually have a
valid previous value to compare against. Otherwise, e.g. variables
that just came into scope but haven't yet been initialized would
show up as changed, while their value is, at that point completely
uninteresting.
This is an external library so it should not be modified. It should be
moved to src/libs to make this clear, or even better, be outsourced as a
package.
Show the summary instead of the version. The layout still sucks, but I will
have to implement some kind of row/flow BLayout to get what I initially had
in mind. Another TODO is to highlight the clicked item somehow.
* Rework existing package listener mechanism to report any interesting
changes. Listen for prominence changes in addition to package state.
* Add featured packages to the FeaturedPackagesView when their prominence
is retrived, and also in _AdoptModel().
* In _AdoptModel(), show the featured packages view when no search filters
are active and installed packages are not shown either. Otherwise show
the list of all packages matching the current filtering.
...into MessagePackageListener and OnePackageMessagePackageListener.
The first one doesn't know which package(s) it's listening to. But it
can filter the change notifications now and only react to certain changes.
The second one knows which package it's listening to.
* Always include last caller and lock value on both UP and MP path.
* Change lock value printing to hex format, as 0xdeadbeef is more
obvious than its decimal counterpart.
TableCellValueRenderer{Utils}:
- The rendering calls now take a boolean indicating if the value
being rendered differs from its previous state. This is taken
into account by rendering it in a different color to indicate
the change. Adjust all implementing subclasses accordingly.
VariablesView::ModelNode:
- Now stores the previous value of the corresponding value node,
and can be queried if its value has changed. Used by renderers.
VariablesView::_{Add,Apply}ViewStateDescendentInfos():
- When walking the model, also store/restore the values of nodes in the
history.
In summation of all the above changes, when stepping through a function,
we now display values that have changed since the last step, or that have
appeared for the first time in a different color.
- When using variable values in an expression, we weren't ensuring
that the resulting value type matched up with the requested
type for the expression, leading to unpredictable results in some
cases.
While the NetBSD entry point is handy as we can use a single uImage
with all 3 blobs, it bypasses U-Boot's own patching of the FDT since
it's not visible to it, so we won't get the RAM size and other things
through it.
CreateThreadEvent::DoDPC() missed a reference release to balance the
acquired reference before queuing the DPC, resulting in the
CreateThreadEvent objects being leaked.
This also removes the destructor that tried to cancel the DPC. Since
the class is reference counted and only destroyed when the DPC has
run and released the last reference, this didn't make much sense.
For cases where a BMessage is passed by area, the remote team id needs
to be passed into BMessage::_SendMessage() so it can transfer the area
to the target team. It falls back to detecting the port owner if said
information is missing. However, since the input_server owns the port
in this situation, the remote team needs to be specified explicitly.
Add the app_server team id to the input acquire message, so input_server
gets the needed info.
As messages that exceed the pass by area threshold are rather rare in
general and shouldn't happen at all in this situation, this does not
fix any immediate problem.
When a message is passed by area, the sender is supposed to transfer
area ownership to the target team. If the area is not mapped within
the current team, accessing the area address would be invalid.
Also mark the area as read-only so accidental writes to the area would
become obvious.
When a message is passed by area, any modification to the message must
first trigger a copy of the message content. The success of this
operation was not checked however, possibly leading to later reallocs
on non-heap memory.
