- The intention is to have a class which handles the actual management
of the variable node graph, creating child nodes and such. This way
the GUI, CLI and report generator don't have to each reimplement
these low-level parts and can instead concentrate on their relevant
representations thereof.
Swapped Polish typist's keymap with much more frequently used programmer's
keymap.
Signed-off-by: Przemysław Buczkowski <przemub@yahoo.pl>
Signed-off-by: Matt Madia <mattmadia@gmail.com>
Got rid of X86_ONLY and friends in HaikuImage, FloppyBootImage, etc.
Instead we use build feature specification annotated lists with
FFilterByBuildFeatures (either explicitly or implicitly where passing
the list directly to the image rules).
I just translated the variables to the respective annotatation in most
cases, though in some cases different annotation would be more correct
(e.g. for the OpenGL stuff).
Provides a simple framework for addressing #3798. The interested reader
may add the build features and add/adjust the annotations accordingly.
Sizes range from 8 to 36 but not all sizes are represented. The
progression is not linear, the font size increases first by 1,
then 2, and finally by 4.
Works by keying command-(plus)/command-(minus) or selecting
from Font size menu, or from selecting from Font menu in Terminal
settings. If you alter the settings file to put in some other font
size it should still work, but the menu item won't be checked.
Fixes#8849
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.
