ed/raddebugger
1
0
Fork 0
mirror of https://github.com/Ed94/raddebugger.git synced 2026-07-29 02:30:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

new view rule table definition in df, merging graphical view rules & views totally

Browse Source
This commit is contained in:
Ryan Fleury
2024-09-13 13:39:40 -07:00
parent 7cd1d175de
commit 793ad8fe1e
10 changed files with 296 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/dbg_engine/dbg_engine.mdesk
-84
View File
@@ -81,90 +81,6 @@ D_CmdTable: // | | | |
////////////////////////////////
//~ rjf: Built-In View Rules
//
// @view_rule_info
//
// NOTE(rjf): View rules are subtle in that they may impact any subset of the
// eval visualization pipeline. The "array" view rule, for example, functions
// by tweaking the type of an eval from `X *` to `X (*)[N]` (where N is
// computed from whatever expression is specified by the view rule). The "list"
// view rule, on the other hand, does not require any changes to the actual
// eval nor its type - instead, it follows an alternative path in constructing
// "viz blocks", and then constructing "viz rows" from those blocks. Compare
// these to the simpler 'dec', 'bin', or 'oct' rules, which simply tweak the
// radix used when stringizing numbers, which is something that only occurs in
// single-line eval stringization building.
//
// As such, each view rule specification has a mask, which determines which
// stages it may be used for. For a given view rule specification, if the bit
// corresponding to a particular eval stage is set, then that view rule spec-
// -ification also includes a hook which can be called from that stage.
//
// Below is a list of the stages in the eval visualization pipeline, as well as
// abbreviations which are used in the tables.
//
// expr resolution, "xp" -> provides a chance for a view rule to make
// modifications to expression trees that it is
// applied to
//
// viz block prod, "vb" -> given a resolved eval, produce a list of non-
// windowed "viz blocks", which correspond to one or
// many contiguous rows in a watch-window-style UI.
// one level of expanded struct members, with no sub-
// expansions, would be one viz block. if one of those
// members - in the middle - were expanded too, then
// it would require three viz blocks - one for the
// members before the sub-expansion, one for the
// sub expansion members, and one for the members
// after, and so on. this is done recursively.
//
// viz row prod, "vr" -> given a list of viz blocks, a windowed list of viz
// rows may be produced. each of these rows has info
// for building actual UI in e.g. a watch window -
// whether or not the row can be expanded, whether or
// not the row's value can be edited, what the edit-
// able string is for a row, what the display string
// is for a row, what the expression string is for a
// row, what the type is for a row, and so on.
//
// line stringize, "ls" -> this is the stage used to produce display strings
// in the "viz row prod" stage, as well as basically
// any time UI needs to display the result of an eval
// in a single line. this also occurs recursively,
// descending into members & elements as needed,
// constrained by # of available pixels and font size
// and so on.
//
// row ui build, "ru" -> finally, after the previous stages are completed,
// ui can finally be built according to all of the
// per-row information produced. this is the stage
// where view rules can insert their own arbitrary ui
// on a per-row basis.
//
// view ui build, "vu" -> view rules which want to supply more sophisticated
// visualizers have the ability to provide full
// arbitrary UI hooks, which can either be produced
// in a minified form via watch views, or via a
// standalone tab.
//
// A few other bits are included for various ways in which a view rule may be
// applied throughout the eval visualization pipeline. A list follows:
//
// inherited, "ih" -> is this view rule included, or not included, in
// child expansions?
//
// expandable, "ex" -> does this view rule force the ability to expand
// an expression, even if traditional analysis of type
// info would not allow expansion?
//
// Not all of these stages are specified at this layer, however, since the
// "df_core" layer is for the non-graphical core debugger features. So the
// information pertaining to the eval visualization pipeline stages which
// do require graphical subsystems (e.g. UI, fonts, rendering) are specified
// in the "df_gfx" layer.
//
// For any view rules in this layer which also have graphical features, they
// are specified in both tables under the same name.
@table(coverage_check name name_lower string ih ex xp vb display_name docs schema description)
D_ViewRuleTable:
src/dbg_engine/dbg_engine_core.c
-29
View File
@@ -231,35 +231,6 @@ d_cfg_table_push_unparsed_string(Arena *arena, D_CfgTable *table, String8 string
}
}
internal D_CfgTable
d_cfg_table_from_inheritance(Arena *arena, D_CfgTable *src)
{
D_CfgTable dst_ = {0};
D_CfgTable *dst = &dst_;
{
dst->slot_count = src->slot_count;
dst->slots = push_array(arena, D_CfgSlot, dst->slot_count);
}
for(D_CfgVal *src_val = src->first_val; src_val != 0 && src_val != &d_nil_cfg_val; src_val = src_val->linear_next)
{
D_ViewRuleSpec *spec = d_view_rule_spec_from_string(src_val->string);
if(spec->info.flags & D_ViewRuleSpecInfoFlag_Inherited)
{
U64 hash = d_hash_from_string(spec->info.string);
U64 dst_slot_idx = hash%dst->slot_count;
D_CfgSlot *dst_slot = &dst->slots[dst_slot_idx];
D_CfgVal *dst_val = push_array(arena, D_CfgVal, 1);
dst_val->first = src_val->first;
dst_val->last = src_val->last;
dst_val->string = src_val->string;
dst_val->insertion_stamp = dst->insertion_stamp_counter;
SLLStackPush_N(dst_slot->first, dst_val, hash_next);
dst->insertion_stamp_counter += 1;
}
}
return dst_;
}
internal D_CfgVal *
d_cfg_val_from_string(D_CfgTable *table, String8 string)
{
src/dbg_engine/dbg_engine_core.h
-1
View File
@@ -507,7 +507,6 @@ internal String8List d_possible_path_overrides_from_maps_path(Arena *arena, D_Pa
//~ rjf: Config Type Pure Functions
internal void d_cfg_table_push_unparsed_string(Arena *arena, D_CfgTable *table, String8 string, D_CfgSrc source);
internal D_CfgTable d_cfg_table_from_inheritance(Arena *arena, D_CfgTable *src);
internal D_CfgVal *d_cfg_val_from_string(D_CfgTable *table, String8 string);
////////////////////////////////