ed/raddebugger
1
0
Fork 0
mirror of https://github.com/Ed94/raddebugger.git synced 2026-06-18 10:02:23 -07:00
Code Issues Packages Projects Releases Wiki Activity

clear completed task log

Browse Source
This commit is contained in:
Ryan Fleury
2024-12-16 13:02:37 -08:00
parent 5f1d0b4d1c
commit 78309209ae
1 changed files with 0 additions and 272 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/raddbg/raddbg_main.c
-272
View File
@@ -276,278 +276,6 @@
////////////////////////////////
//~ rjf: Recently Completed Task Log
//
// [x] UI_NavActions, OS_Event -> UI_Event (single event stream)
// [x] better discoverability for view rules - have better help hover tooltip,
// info on arguments, and better autocomplete lister
// [x] source view -> floating margin/line-nums
// [x] watch window reordering
// [x] standard way to filter
// [x] autocomplete lister should respect position in edited expression,
// tabbing through should autocomplete but not exit, etc.
// [x] pipe failure-to-launch errors back to frontend
// [x] bit more padding on the tabs
// [x] unified top-level cursor/typing/lister helper
// [x] collapse text cells & command lister & etc. into same codepath (?)
// [x] page-up & page-down correct handling in keyboard nav
// [x] interleaved src/dasm view
// [x] in watch window when I enter some new expression and then click mouse
// away from cell, then it should behave the same as if I pressed enter.
// Currently it does the same as if I have pressed esc and I have lost my
// expression
// [x] pressing random keyboard keys in source code advances text cursor like
// you were inputting text, very strange.
// [x] It's confusing that ENTER is the way you expand and collapse things in
// the watch window, but then also how you edit them if they are not
// expandable? It seems like this should be consistent (one way to edit,
// one way to expand/collapse, that are distinct)
// [x] Dragging a window tab (like Locals or Registers or whatnot) and
// canceling with ESC should revert the window tab to where it was.
// Currently, it leaves the window tab reordered if you dragged over its
// window and shuffled its position.
// [x] ** I couldn't figure out how to really view threads in the debugger.
// The only place I found a thread list was in "The Scheduler", but it
// only lists threads by ID, which is hard to use. I can hover over them
// to get the stack, which helps, but it would be much nicer if the top
// function was displayed in the window by default next to the thread.
// [x] ** It would be nice if thread listings displayed the name of the
// thread, instead of just the ID.
// [x] TLS eval -> in-process-memory EXE info
// [x] unwinding -> in-process-memory EXE info
// [x] new fuzzy searching layer
// [x] robustify dbgi layer to renames (cache should not be based only on
// path - must invalidate naturally when new filetime occurs)
// [x] rdi file regeneration too strict
// [x] raddbg jai.exe my_file.jai -- foobar -> raddbg consumes `--` incorrectly
// [x] mouse-driven way to complete file/folder selection, or more generally
// query completion
// [x] it would be nice to have "show in explorer" for right click on source
// file tab (opens explorer & selects the file)
// [x] asan stepping breakage
// [x] what's up with decimal number coloring where every group of 3 are in
// different color? can I turn it off? And why sometimes digits in number
// start with brighter color, but sometimes with darker - shouldn't it
// always have the same color ordering?
// [x] fix tabs-on-bottom positioning
// [x] colors: consistent tooltip styles (colors, font flags, etc.)
// [x] colors: scroll bars
// [x] colors: watch window navigation visuals
// [x] floating source view margin background/placement
// [x] "interaction root", or "group" ui_key, or something; used for menu bar interactions
// [x] theme colors -> more explicit about e.g. opaque backgrounds vs. floating
// & scrollbars etc.
// [x] Pressing the left mouse button on the menu bar and dragging does not
// move through the menus as expected - instead, it opens the one you
// clicked down on, then does nothing until you release, at which point it
// opens the menu you released on.
// [x] Similarly, pressing the left mouse button on a menu and dragging to an
// item, then releasing, does not trigger that item as expected. Instead,
// it is a nop, and it waits for you to click again on the item.
// [x] Using the word "symbol" in "Code (Symbol)" seems like a bad idea, since
// you're referring to non-identifier characters, but in a debugger
// "symbol" usually means something defined in the debug information.
// [x] I couldn't figure out how to affect the "dim" color in constants that
// have alternating bright/dim letters to show sections of a number. Is
// this in the theme colors somewhere?
//
// [x] ** Scrollbars are barely visible for me, for some reason. I could not
// find anything in the theme that would fill them with a solid, bright
// color. Instead they are just a thin outline and the same color as the
// scroll bar background.
//
// [x] Many of the UI elements, like the menus, would like better if they had
// a little bit of margin. Having the text right next to the edges, and
// with no line spacing, makes it harder to read things quickly.
// [x] colors: memory view
// [x] Hitting ESC during a color picker drag should abort the color picking
// and revert to the previous color. Currently, it just accepts the last
// drag result as the new color.
// [x] It was not clear to me why a small "tab picker" appeared when I got to
// a certain number of tabs. It seemed to appear even if the tabs were
// quite large, and there was no need to a drop-down menu to pick them. It
// feels like either it should always be there, or it should only show up
// if at least one tab gets small enough to have its name cut off?
// [x] I found the "context menu" convention to be confusing. For example, if
// I left-click on a tab, it selects the tab. If I right-click on a tab,
// it opens the context menu. However, if I left-click on a module, it
// opens the context window. It seems like maybe menus should be right,
// and left should do the default action, more consistently?
//
// [x] double click on procedure in procedures tab to jump to source
// [x] highlighted text & ctrl+f -> auto-fill search query
// [x] double-click any part of frame in callstack view -> snap to function
// [x] Menus take too long to show up. I would prefer it if they were instant.
// The animation doesn't really provide any useful cues, since I know
// where the menu came from.
// [x] user settings (ui & functionality - generally need a story for it)
// [x] hover animations
// [x] press animations
// [x] focus animations
// [x] tooltip animations
// [x] context menu animations
// [x] scrolling animations
// [x] background blur
// [x] tab width
// [x] ** In the call stack, I would like to be able to click quickly and move
// around the stack. Right now, you can do that with the first and third
// column, but the second column drops down a context menu. Since right
// click is already for context menus, can it not just be that double-
// clicking any column jumps to that stack frame?
//
// [x] ** I find it really hard to read the code with the heavyweight lines
// running through it for breakpoints and stepping and things. Is there a
// way to turn the lines off? AFAICT they are based on thread and
// breakpoint color, so you can't really control the line drawing? I might
// be fine with them, but they would have to be much more light (like
// alpha 0.1 or something)
// [x] zooming behaves very strangely - sometimes it zooms source code,
// sometimes both source code and menu/tab/watch font size, sometimes
// just menu/tab/watch font size not source size.
// [x] colors: fill out rest of theme presets for new theme setup
// [x] I LOVE ALT-W to add watch under cursor, but I would prefer to have it
// add what's under the MOUSE cursor instead of the keyboard cursor. Can
// we get a command for that so I can bind ALT-W to that instead?
// [x] editing multiple bindings for commands
// [x] inline breakpoint hit_count
// [x] to count hit counts, resolve all bps to addresses, check addresses
// against stopper thread's
//
// [x] PDB files distributed with the build are not found by DbgHelp!!!
// [x] Jai compiler debugging crash
//
//- 2024/8/29
//
// [x] fix HRESULTs
// [x] fix escape char literals
// [x] eval: indexing into string literals
// [x] fix incorrectly consuming keyboard inputs, preventing fallback-to-filtering, when
// selecting null selection in watch views
// [x] ui_next_event(...), built-in focus filtering, no need to manually check
// if(ui_is_focus_active())
// [x] Theme window should include font scaling. I was able to find the
// command for increasing the font scale, but I imagine most people
// wouldn't think to look there.
// [x] n-row table selection, in watch window & other UIs, multi-selection
// ctrl+C
// [x] target/breakpoint/watch-pin reordering
// [x] move breakpoints to being a global thing, not nested to particular files
// [x] EVAL SPACES - each rdi gets an rdi space, rdi space is passed to
// memory reads & so on, used to resolve to value space; REPLACES "mode"
// [x] fix selecting hover eval, then hover eval disappearing, causing
// busted focus, until a new hover eval is opened
// [x] `text[:lang]` - interpret memory as text, in lang `lang`
// [x] `disasm:arch` - interpret memory as machine code for isa `arch`
// [x] `memory` - view memory in usual memory hex-editor view
// NOTE(rjf): When the visualization system is solid, layers like dasm, txti,
// and so on can be dispensed with, as things like the source view, disasm
// view, or memory view will simply be specializations of the general purpose
// viz system.
// [x] view rule hook for standalone visualization ui, granted its own
// tab
// [x] collapse frontend visualization systems - source view, disasm view,
// callstack, modules, scheduler, should *all* be flavors of watch view
// [x] globally disable/configure bp/ip lines in source view
// [x] @cleanup naming pass over eval visualization part of the frontend,
// "blocks" vs. "canvas" vs. "expansion" - etc.
// [x] @cleanup collapse DF_CfgNodes into just being MD trees, find another way
// to encode config source - don't need it at every node
// [x] @cleanup in the frontend, we are starting to have to pass down "RD_Window"
// everywhere, because of per-window parameters (e.g. font rendering settings).
// this is really better solved by implicit thread-local parameters, similar to
// interaction registers, so that one window can "pick" all of the implicit
// parameters, and then 99% of the UI code does not have to care.
// [x] @cleanup simplification pass over eval visualization pipeline & types,
// including view rule hooks
// [x] engine/frontend commands situation
// - currently, there is an interesting bifurcation of commands in the
// frontend; you can either push a command *at a root level*, or push a
// command to a locally-accessible list if you want that command to run
// on the same frame (root level commands are deferred by a frame, since
// the engine must see them first).
// - things would be simpler if there was only a single "push command"
// mechanism, and codepaths only ever saw these commands at most once.
// this would require an alternate strategy of the initial "gather" of
// commands, and instead it would just be a global queue, or something...
// it is a little weird since commands are not just consumed in order...
// - this will clean up the various different ways that codepaths
// parameterize commands.
// [x] command params -> d_regs
// - currently there are two almost-identical concepts relating to commands:
// the parameters struct, and D_Regs. D_Regs is a registers struct which
// is used to manage a stack of contextual information in various debugger
// codepaths. it is used so that codepaths can register information they
// know about, without passing it down to everyone explicitly - but those
// later codepaths can still pass that information along. e.g. a window
// calls into a watch window, watch window calls into visualizer, visualizer
// pushes command, which needs to pass which window it occurred on along.
// - i think D_Regs needs to expand a bit in order to encompass all of the
// things that the command parameters were being used for, but at that point
// commands can just be a spec * regs, and then the push-command API can
// just have ways of overriding regs values explicitly, when the codepath
// needs to be opinionated about which things are affected by which commands
// [x] frontend entities vs. engine entities
// - currently, the engine has entities like "watch", and the frontend
// has entities like "windows", "panels", and "views".
// - because "watch" entities ideally have a hierarchical relationship
// with windows, panels, and views (enabling things like drag/drop
// from watch window -> tab, or tab -> watch window, trivially), it
// would be much better if all entities could collapse into engine
// entities.
// - now, the frontend requires various specialized resources for things
// like windows, so what I am thinking is that the engine just controls
// all of the stateful windows/panel/view/watch mechanisms, and then
// the frontend pure-functionally queries stuff like os/r handles
// on-demand, and then prunes them, immediate-mode cache style.
// [x] ensure "prefer_disasm" is calculated correctly - disassembly-focused
// stepping
// [x] file path map editor
// [x] file path map building
// [x] meta eval system
// [x] codebase readme pass
// [x] target editor
// [x] modules view
// [x] eval writing/committing
// [x] breakpoint hit count resetting
// [x] reset bp hit counts - not just on NewProcess, but on RUN! because
// we are now evaluating them on the control thread...
// [x] fix bug where text info is evicted, and switching back to a tab scrolls
// to the top
// [x] reset bp hit counts - not just on NewProcess, but on RUN! because
// we are now evaluating them on the control thread...
// [x] fix bug where text info is evicted, and switching back to a tab scrolls
// to the top
// [x] targets view
// [x] ensure launch controls parameterize commands correctly)
// [x] ensure ctrl+click
// [x] scheduler view
// [x] eval committing
// [x] fix registers
// [x] file overrides -> always pick most specific one! found with conflicting
// overrides, e.g. C:/devel/ -> D:/devel/, but also C:/devel/foo ->
// C:/devel/bar, etc.
// [x] fix memory view
// [x] global evaluation across DLL boundaries
// [x] mohit-reported callstack-frame-selection bug (with inlines)
// [x] @feature entity views: filtering & reordering
// [x] @feature eval system -> somehow evaluate breakpoint hit counts? "meta"
// variables?
// [x] @feature types -> auto view rules (don't statefully fill view rules
// given types, just query if no other view rule is present, & autofill
// when editing)
// [x] decay arrays to pointers in pointer/value comparison
// [x] new universal ctx menu, hover, tooltips systems
// [x] `switch` replacement (recent files history)
// [x] resolving name as file or #include
// [x] entity listers - kill-specific-process, etc.
// [x] remainder of @msgs pass:
// [x] new `restart processes` path
// [x] remainder of @msgs
// [x] empty user file causing failure to launch
// [x] post-@msgs TODOs:
// [x] ensure the following issues are resolved with this new pass:
// [x] debugger readme pass
// [x] per-target stdout/stderr file output paths
// [x] fix quote input in quoteless watch window value editors
// [x] double click on breakpoints/watch-pins/etc. to go to location
////////////////////////////////
//~ rjf: Build Options