Ryan Fleury
@ryanjfleury • 15,656 subscribers
Digital Grove | Working on the RAD Debugger at @radgametools / @epicgames (opinions my own)
Shorts
Videos
Makes you wonder what the hell programmers were doing for the last 20 years, doesn't it?
Ryan Fleury113,954 görüntüleme • 1 yıl önce
The next release will come bundled with a single-header library with new source markup features—from helpers for common debugger-interop (thread names, checking if attached) to new features for the RAD Debugger (thread colors, auto view rules, watch pins, etc.)
Ryan Fleury52,638 görüntüleme • 1 yıl önce
The “everything palette” has been in the back of my mind for years. I feel that, when correctly automated, it demonstrates an important property of a GUI system, which is an internal interface represented structurally (a common substrate by which all higher level interfaces communicate), and several projections of that interface to higher level interfaces (GUIs, CLIs, hotkeys), such that the internal interface is not substantially duplicated in the projections themselves. Thus, small changes in the internal interface representation immediately and automatically reflect in all such projections. All information for a new setting, for example, is simply expressed in one location, and all interfaces which could access that setting immediately can do so. That setting is automatically accessible in the associated right-click menus, the CLI, hotkeys, and the everything palette. This is because those higher level interfaces are truly *projections* of the underlying interface—they are driven using, in effect, type information of the underlying interface, rather than being special cased to the particulars of the interface (and thus needing to be extensively updated any time the internal interface is changed). The need for this in UI programming is usually first encountered with hotkeys. You write some user interface, and now you need to associate hotkeys—an entirely separate (physical) interface—with the same functionality that your software user interface exposes. You can implement this by, in effect, duplicating the internal interface in both a hotkeys path, and a GUI path. But this is far from ideal for obvious reasons. The debugger by nature enforces this design constraint (GUIs and hotkeys), along with many others, and so it pushed me to follow this to its natural conclusion. A debugger needs to offer an IPC CLI interface for the same commands and features that the main program does. Data in the debugger is already projected in a wide variety of ways—breakpoints can show up in a source view, a disassembly view, a memory view, and a breakpoints list view. My work on the RADDBG visualization engine (driven ultimately by the “watch window” interface—at its limit, a general sparse tree viewer/editor) pushed this even further—you want interfaces to be available through a watch tree evaluation language, as well as several GUIs, and the CLI, and hotkeys. I’ve now finally got the internal systems to the point where they are roughly satisfying all these constraints, and this made the “everything palette” a very simple and natural extension to the system.
Ryan Fleury22,249 görüntüleme • 1 yıl önce
Using auto view rules to visualize anything with a function type as the resultant disassembly, by default.
Ryan Fleury10,758 görüntüleme • 1 yıl önce
Daha fazla içerik yok.