Motivation Programming is difficult.

Our squishy human brains struggle to simulate what the computer will do when it runs our code. As a result we make lots of errors, many of them small, requiring us to divert our attention from the main problem we're working on to fix minor implementation details. This both takes up time and makes us lose focus on the high-level design.

The computer is going to run our code anyway, so why not do so immediately to check what it does?

Tool Overview WhiteBox runs the code as it is written, capturing details about the execution. It can then give you live feedback about the run, showing you how variables change over time and other details.

This is intended to improve the developer experience by helping you to understand your code faster, and consequently:

  • catch and fix bugs earlier, before they cause major issues
  • iterate more often over your design, giving more opportunity for refinement

Tool Internals WhiteBox is written in C and C++ with few external libraries:

  • Clang/LLVM is used for lazily JIT compiling code
  • Dear ImGui is used for creating the UI
  • A few single-header libraries are used for various utilities (STB, Mattias Gustavsson, Randy Gaul's cute_headers)

Just about everything else is written from scratch, including:

  • the hash table implementation
  • DWARF debug info parsing
  • plugins for code editors
  • ...

Project Details WhiteBox has most of the initial set of features implemented and is nearly ready for alpha release.

Supported languages: C (and a small subset of C++) Supported platforms: Windows x64, Linux x64 (tested on Ubuntu 20.04) Supported code editors: 4coder, Emacs, Notepad++, Sublime Text, Vim/Neovim, Visual Studio, VSCode, (plus workarounds that should work for most other editors)

Support for more of each of these is planned or currently in-development.

Project Links

Recent Activity

&WhiteBox now has a pretty good heuristic for determining uninitialized values, which means we can show them as distinct and not include them in min/max stats: 🥳
e.g. k is uninit until line 8 finishes

&WhiteBox now has a pretty good heuristic for determining uninitialized values, which means we can show them as distinct and not include them in min/max stats: 🥳

&WhiteBox timeline data visualisation part 3: using de-emphasis for the "non-value" part of the bar instead of emphasis for "value" part itself. To me this reduces visual noise, but I'd like to hear thoughts from others. The value colour is what was the normal bar colour... it might be worth increasing the contrast somewhat.
Importantly, it also obscures the text less.
(Ignore the fact that [line] is coloured as it was previously, synthetic values need to be handled slightly differently)

&WhiteBox Noticed a bug in the previous image as I was writing about unit size: there's an off-by-"1" in max value for floats, which visually halves the 0.0-0.9 range shown.
This is now fixed:

&WhiteBox Noticed a bug in the previous image as I was writing about unit size: there's an off-by-"1" in max value, which visually halves the 0-1 range shown.
This is now fixed:

&WhiteBox timeline data visualisation part 2: lines for integral values have a height based on the span/range of values for that expression. This is particularly useful for expressions with small ranges like booleans!
This is meaningful because integers have a "unit size" of 1, but floats don't really have that. I could use "smallest non-zero exponent" or "smallest difference between values" or even "ordinal rank of all seen values (sorted)". The last of these would work for integers as well with large ranges but few values. It's better for distinguishing between values but not so good at making the actual value perceptually apparent.

&WhiteBox timeline data visualisation, part 1: horizontal lines indicating value for primitive types

&WhiteBox is prepping to go native, reading PDBs for arbitrary executables in place of the DWARF it generates internally.
Unsurprisingly, @NeGate has been doing a great job on this! 😄
Here's WhiteBox inspecting its own PDB functions, showing line info & local variables


I've been working my way through the ANSI control codes standard (+ extras) for WhiteBox's new in-built console.

We're capturing stdout & stderr from the user's process, reading ~all controls & handling more graphical ones than many terminals!

Can yours do curly red underlines?


Just playing around with a WIP build of WhiteBox after @phillip_trudeau has made some upgrades.

I'm really enjoying taking advantage of this breakout, full-width timeline 😀

(thanks to @ocornut for Dear ImGui + docking + viewports!)

I added a red line to the end of the &WhiteBox timeline when a run had an error that prevented the function from returning.
I also fixed the status message telling you what line the error occurred on.
(There's a new release coming very, very soon!)

&WhiteBox now has a welcome screen with instructions on how to install the plugin for each editor, thanks to @BaremetalBaron

I'm really excited about this update to &WhiteBox - it adds the ability to call into other functions in your code (not just the function that's being recorded).
This means you can call main() (or something else that calls your function) and see how your function behaves with all of the parameters & extra context from runtime without having to input them manually.

It's now at a point where this seems to be working, it just needs to do a little tidying up after itself...

Reworked &WhiteBox's recording of the running process' memory to be faster, simpler, and to better capture pages changing protection/accessibility

I haven't shown much for &WhiteBox recently as it's all been pretty non-visual. Here's a little expression builder I made on stream for debugging expression evaluations.
It shows the value of that expression at a given sample of the run as well as a list of all the times the value changed during the run.

Having it as a builder means that I can enforce the validity of the expression, and it also means I don't have to handle shadowed variables with the same identifier as you would for text parsing. It's a little less clear how identities should be handled when taking a large span of time into account instead of just a single instant, so this lets me defer decisions about that.