Built-in type views (formerly "auto view rules") for basic STL types. (Support for more of this is coming as well.)
Using the new `table` view to expand multiple arrays at once (viewing SOAs side-by-side in a watch table). Also expression drag & drop.
Using the `table` view to automatically expand a 4x4 matrix type to a 4x4 grid of scalars. Also using `only` to omit redundant members in a 2-vector union.
Visualizing a discriminated union based on the tag, by filtering down to the set of "valid" fields.
Support for hardware data breakpoints.
A major upgrade to the F1 command palette: the "everything palette". Lists commands, settings, threads, targets, breakpoints, types, functions, recent files, and a whole lot more.
Greatly developed per-tab settings (done through a single system, which is also used to specify arguments to views). Available through both the "everything palette" and the tab's right-click menu.
Visualizing bounded numeric values with sliders, and plugging those values in as settings for visualizer tabs. (Settings are now simply expressions which are evaluated.)
This is just a small sample that I quickly recorded tonight, honestly there is just so much stuff to show.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
When are we going to talk about the hundreds of processes that I *didn’t* open, that are running anyways?
Or what about the enormous waste taken by each program, or each tab in a browser?
By the way, who thought that was a good marketing tactic for Dell? How does that make me want to buy a Dell? I want to buy a computer that *can* handle all the programs I have open, and a podcast, and a bunch of tabs. Completely embarrassing.
One of the most powerful lessons I learned as a programmer was to use combinatoric spaces to my advantage, rather than allowing them to explode into—for example—handwritten source code. This required relaxing, for example, an obsession with static type checking.
Instead what I learned was to use static product types to form homogeneous building blocks for large combinatoric spaces, and to organize data transforms around forming those spaces. Choosing actual points in this space becomes a completely dynamic capability.
This is related to my comment the other day on sum types. The reason you won’t find many of them in my code is that I find that they leak combinatoric spaces into the source code itself, by forming one “axis” (1 of N types), which might be multiplied by another. That puts it in the path of non-temporal physical reality—physical code—which must either be handwritten or generated. This is either slow for the programmer, or for the computer.
@Skytrias [1/n] I haven't covered that yet (I will probably do it in the next part), but I control properties like size, colors, fonts, and some other things with stacks. So, for example, you might push a default size for each axis on the stack (as well as a default font, etc.), then...
@Skytrias [2/n] ...if you want to deviate a size, color, font, etc. for a button, you would just push a new value onto the associated stack before the button call, and then pop afterwards.
@Skytrias [3/n] I am really not that big of a "go nuts with C macros" guy, but there's one exception, and that's these widget property stacks. It all comes down to this:
@AbnerCoimbre@notnullnotvoid@handmade_net I will provide my personal thoughts about Handmade, and maybe we can work towards an understanding of the manifesto, if/how it should be revised, etc. (1/7)
@AbnerCoimbre@notnullnotvoid@handmade_net My experiences with @handmade_net have provided a lot of insight here, namely in that Handmade *isn't* just about making things fast, it's about knowing when to allow things to be slow, and reasoning about reality. I like @AbnerCoimbre's "computer literacy" idea here. (2/7)
@AbnerCoimbre@notnullnotvoid@handmade_net "Handmade" isn't exactly rigorously defined, though I think it's more important that we gather as a community, dedicate ourselves to making better software, caring about the end user, and wanting to understand the reality of our problems. (3/7)