Searched +hist:59 +hist:ea286f (Results 1 - 6 of 6) sorted by relevance

/haiku/src/apps/debugger/user_interface/gui/team_window/
H A DVariablesView.hdiff b6c4fc96 Sat Nov 01 16:42:59 MDT 2014 Rene Gollent <rene@gollent.com> Debugger: Implement #9946.

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.
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff b6c4fc962c6b0d6a0f071069fd0e90053e58f135 Sat Nov 01 16:42:59 MDT 2014 Rene Gollent <rene@gollent.com> Debugger: Implement #9946.

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.
diff 59ea286fac914a808edc6989becc77dadff10383 Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DTeamWindow.hdiff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286fac914a808edc6989becc77dadff10383 Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DVariablesView.cppdiff 3995592c Wed Jan 10 17:21:59 MST 2018 Rene Gollent <rene@gollent.com> Debugger: Fix #13939, more work on #13800.

- Fix various cases where OpenHashTables weren't being cleared properly.
- Fix various reference counting errors.
- Simplify FileManager reference handling.
- Fix bug in LocatableDirectory where the directory named '/' would have its
name returned as empty. This would lead to failed lookups for entries already
in the table, and ultimately corrupted the hash table when deleting unused
entries, leading to #13939. This was previously never noticed due to the
entries not being freed properly.
- AbbreviationTable wasn't clearing its entries.
diff 5b026a29 Sat Jun 13 22:27:59 MDT 2015 Rene Gollent <rene@gollent.com> Debugger: Improve variable tooltips.

VariablesView:
- Tooltips now indicate if there was a problem resolving either the location
or the actual value of a given variable, as well as whether or not the
variable is editable in its current location.
diff 40d79c05 Fri Dec 12 14:59:28 MST 2014 Rene Gollent <rene@gollent.com> Debugger: Fix type value display in VariablesView.

- When retrieving the type to display for a given model node, ask its
underlying value node for its corresponding type rather than relying
on the one initially stored in the model, as the latter can change
as a result of typecasts.
diff 06901787 Sat Nov 22 22:12:59 MST 2014 Rene Gollent <rene@gollent.com> Debugger: Further improvements to expression handling.

VariablesView:
- ModelNode now acquires a reference to its target variable. This
is necessary because in the case of expression variables, the
model node is ultimately the only one aware of it, and therefore
needs to manage its lifetime.
- AddSyntheticNode() now discriminates between the case where it
needs to create a node child on behalf of the caller versus when
it's given an already created one, as is the case when an expression
resolves to a value node. Consequently it also detects whether
it needs to request value resolution or not, and handles accordingly.
- _AddExpressionNode() now supports value node results and handles
them accordingly.
diff b6c4fc96 Sat Nov 01 16:42:59 MDT 2014 Rene Gollent <rene@gollent.com> Debugger: Implement #9946.

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.
diff 8a4cdf3e Sun Nov 04 08:22:59 MST 2012 Rene Gollent <anevilyak@gmail.com> Fix handling of notifications. Basic typecasting now works.

Still needs a bit of work to properly grok pointer/reference types.
diff 781a7c36 Sat Jul 23 20:54:59 MDT 2011 Rene Gollent <anevilyak@gmail.com> Relocate incorrectly placed call, and guard it as needed.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42471 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 5b026a2960484d7c862ed8e9142d57b8f71fb797 Sat Jun 13 22:27:59 MDT 2015 Rene Gollent <rene@gollent.com> Debugger: Improve variable tooltips.

VariablesView:
- Tooltips now indicate if there was a problem resolving either the location
or the actual value of a given variable, as well as whether or not the
variable is editable in its current location.
H A DTeamWindow.cppdiff a6543e68 Mon May 27 19:59:59 MDT 2013 Rene Gollent <anevilyak@gmail.com> When an exception/breakpoint is hit, activate...

...the team window. Resolves #9797.
diff a6543e68 Mon May 27 19:59:59 MDT 2013 Rene Gollent <anevilyak@gmail.com> When an exception/breakpoint is hit, activate...

...the team window. Resolves #9797.
diff df720531 Tue May 07 20:59:00 MDT 2013 Rene Gollent <anevilyak@gmail.com> Use B_USE_SMALL_{SPACING,INSETS} as suggested by Axel.
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff a6543e68c04261c31456b503c50295148152edd9 Mon May 27 19:59:59 MDT 2013 Rene Gollent <anevilyak@gmail.com> When an exception/breakpoint is hit, activate...

...the team window. Resolves #9797.
diff a6543e68c04261c31456b503c50295148152edd9 Mon May 27 19:59:59 MDT 2013 Rene Gollent <anevilyak@gmail.com> When an exception/breakpoint is hit, activate...

...the team window. Resolves #9797.
diff df720531e35c3f78df963af874ddf11970deaebe Tue May 07 20:59:00 MDT 2013 Rene Gollent <anevilyak@gmail.com> Use B_USE_SMALL_{SPACING,INSETS} as suggested by Axel.
diff 59ea286fac914a808edc6989becc77dadff10383 Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
/haiku/src/apps/debugger/
H A DDebugger.cppdiff 7e6e3c1b Mon Dec 05 15:59:45 MST 2016 Rene Gollent <rene@gollent.com> Debugger: Implement use of connection config roster.

Debugger:
- Initialize/Deinitialize roster as appropriate.

ConnectionConfigWindow:
- Implement config view listener interface, and use roster
to retrieve and add appropriate config view when switching
between interface types.
diff 5c8ba745 Wed May 25 21:16:59 MDT 2016 Rene Gollent <rene@gollent.com> Debugger: Refactor SettingsManager.

- SettingsManager is now a pure virtual interface. The debugger core provides
a no-op implementation of it which is used by default if no explicit manager
is provided by the client requesting a new TeamDebugger. This allows consumers
of the debugger core that have no need for settings persistence such as the
report generator to not have to care about that particular detail at all.
- Add subclass DebuggerSettingsManager which is essentially the previous
existing implementation. This one will go with the application portion
of the Debugger once the separation of app and lib has been completed.
Adjust callers accordingly.
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286fac914a808edc6989becc77dadff10383 Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
H A DJamfilediff 5c8ba745 Wed May 25 21:16:59 MDT 2016 Rene Gollent <rene@gollent.com> Debugger: Refactor SettingsManager.

- SettingsManager is now a pure virtual interface. The debugger core provides
a no-op implementation of it which is used by default if no explicit manager
is provided by the client requesting a new TeamDebugger. This allows consumers
of the debugger core that have no need for settings persistence such as the
report generator to not have to care about that particular detail at all.
- Add subclass DebuggerSettingsManager which is essentially the previous
existing implementation. This one will go with the application portion
of the Debugger once the separation of app and lib has been completed.
Adjust callers accordingly.
diff fc76f5a8 Fri Apr 29 14:31:59 MDT 2016 Ingo Weinhold <ingo_weinhold@gmx.de> Debugger: Support for reading symbols from core file images

* New class ElfSymbolLookup. Given a data source, the address of a
symbol table, symbol hash table, string table, and a few more details
it provides access to the symbol information.
* CoreFile: Add CreateSymbolLookup(). Creates an ElfSymbolLookup for a
specified image.
* CoreFileDebuggerInterface: Implement GetSymbolInfos() for regular
images (no commpage yet) via the new functionality.
diff 94acd925 Sat Aug 01 13:54:59 MDT 2015 Rene Gollent <rene@gollent.com> Debugger: Add dedicated expression evaluation window.
- Rather than dropping one-off expression evaluation results into the
current team's variables view, they will now be handled in a dedicated
window, which also allows to control the context in which the expression
is evaluated.
diff d431ff41 Mon Nov 24 20:37:59 MST 2014 Rene Gollent <rene@gollent.com> Debugger: Cleanups/adjustments to syntax interfaces.

- Add missing public keyword for SyntaxHighlightSource/SyntaxHighlightInfo.
- Add initial set of basic syntax highlight types.
- Remove SyntaxHighlightSource. Instead, add a general purpose LineDataSource
interface to the model classes. Correspondingly adjust SourceCode to inherit
from it and fixup its derivatives accordingly; also adjust SyntaxHighlighter
to take a LineDataSource rather than a SyntaxHighlightSource.
diff 04584c0d Tue Jun 21 16:59:54 MDT 2011 Rene Gollent <anevilyak@gmail.com> Add the beginnings of a BMessage type/value handler. Not yet registered with
the type handler roster since it's quite far from being complete.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42279 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286f Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff d431ff418f4c13cafd4ccb5c3e26be9027d02d57 Mon Nov 24 20:37:59 MST 2014 Rene Gollent <rene@gollent.com> Debugger: Cleanups/adjustments to syntax interfaces.

- Add missing public keyword for SyntaxHighlightSource/SyntaxHighlightInfo.
- Add initial set of basic syntax highlight types.
- Remove SyntaxHighlightSource. Instead, add a general purpose LineDataSource
interface to the model classes. Correspondingly adjust SourceCode to inherit
from it and fixup its derivatives accordingly; also adjust SyntaxHighlighter
to take a LineDataSource rather than a SyntaxHighlightSource.
diff 04584c0d6f9eb1cc69fe36df2a761a13ede381da Tue Jun 21 16:59:54 MDT 2011 Rene Gollent <anevilyak@gmail.com> Add the beginnings of a BMessage type/value handler. Not yet registered with
the type handler roster since it's quite far from being complete.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42279 a95241bf-73f2-0310-859d-f6bbb57e9c96
diff 59ea286fac914a808edc6989becc77dadff10383 Thu Nov 05 11:15:21 MST 2009 Ingo Weinhold <ingo_weinhold@gmx.de> * EnumerationValue -> EnumeratorValue
* Since some types don't have names (e.g. pointer types or anonymous structs or
unions), each type does now also have a unique ID. The global type cache
registers types by ID and by name (if they have one). This fixes clashes of
types with empty names.
* Completely refactored the code dealing with variable values. Formerly we had
Variable and TypeComponentPath to navigate to a component, mapped to a
BVariant representing the value. Now we have:
* Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to
represent a value, with the flexibility for more esoteric values.
* A tree of ValueNode+ValueNodeChild objects to represent the components of a
variable. On top of each ValueNodeChild sits a ValueNode representing the
value of the component, potentially having ValueNodeChild children. This
should allow casting a component value, simply by replacing its ValueNode.
* Interface ValueHandler and various implementations for the different value
types. It is basically a factory for classes allowing to format/display a
value.
* ValueHandlerRoster -- a registry for ValueHandlers, finding the best one
for a given value.
* Interface TypeHandler and various implementions for the different type
kinds (primitive, compound, address, etc.). It is basically a factory for
ValueNodes for that type.
* TypeHandlerRoster -- a registry for TypeHandlers, finding the best one
for a given type.

That's still a bit work in progress. It introduces at least one regression:
The VariablesView doesn't save/restore its state anymore. Will take a while
until that is added back.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96

Completed in 311 milliseconds