on the window, not just the active tab. Also fix window resizing
with tabs open. It wasn't taking into account the height of the
tab bar.
This fixes#8108
- Rework quick stack range check as suggested by Ingo.
- If the ref count is > 1 we invoke the debugger unconditionally.
- If equal to 1, we first perform a quick heuristic check to see if the
var might be on the stack. If we can't conclusively determine that is,
we make certain by comparing to the thread's actual stack range.
- If a BReferenceable object is deleted with a non-zero reference count,
we now test to see if the object was allocated on the stack. If so,
we don't flag a warning if the reference count is currently 1.
Slightly amended patch from Tyler Dixon. This fixes#8434.
Tested on my new GPT-disk with:
jam run ":<build>makebootable" --dry-run /dev/sda4
Signed-off-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* It's painfully obvious to me now that we will
need to manage our own framebuffers still in
the latest gallium code.
* GalliumFramebuffer works pretty cleanly as a
class.. we have to remember to lock and unlock
the Framebuffer object however when we access
fBuffer directly. (which needs to occur by design)
* I'm really starting to have problems with the
amount of downcasting Gallium3D does now.
- Since we currently limit the maximum number of child elements we'll
show, it's helpful information to know the actual capacity of the list
in case it contains more, especially when we later support requesting
additional elements to be retrieved.
- Since BasicTargetInterface is a BReferenceable, we must not create it
on the stack, else it will be destroyed while others still have
references to it. Fixes various random crashes, though most frequently
observable when typecasting with more complex types.
Love this feature, but, color schema is not a thing, it is a color
scheme. Change both the display text and the variable names.
Also changed "Retro Terminal" color scheme to just "Retro". Terminal
is redundant.
The value computed isn't actually used anywhere. It just ensured that
a panic would be triggered if we "skipped" to virtual addresses further
along. This shouldn't be problematic however.
This makes it less likely that uninitialized entries cause troubles.
Also panic if we encounter an unknown entry type instead of defaulting
to 4K pages.
And actually use the virtual address for it later on. This wasn't
problematic as the virtual and physical addresses are identity mapped,
but it seems more correct to do it in this order.
