[wiz21c]

Yeah sure but I'd like to sprinkle lots of little codes in many different places, ad hoc. This happens while I'm debugging issues 'cos I have to integrate information from various places. Note also that it's not like trying to figure a clearly visible bug: sometime sI have to wander through literally hundreds of data arrays just to find what's going wrong. Since I do that close to the code (modifying bits here and there to see how it influences things), it'd be nice to have a "data analysis debug context" very close to the code.

I'm sure there's a space here where one can provide tools. For example a drop in "record_this(object)" method integrated with the debugger so that I can look at the results, without the need to build a logging structure to do it myself.

[vaughan]

I had an idea to trace all usages of values. So you can see the entire history of how a value came to be. All the places it went. All the transformations too.

Also, I think code should be written so that it can be easily visualized. Nothing else! Code is for humans to read, not machines - that's what compilers are for.

Code instrumentation is usually for code coverage...but for debugging it can be great too.

[tracnar]

Indeed, on top of stacktraces it would be great to have 'value traces' (with functional programming I suppose those would be the same). Especially in testing, what's important are the inputs with the system under test.

[db48x]

Pernosco has that!

[vaughan]

I wish it was open-source.

[db48x]

True. Thankfully RR, which Pernosco is built upon, is open source.

You can do a very simple form of value tracing with just RR by setting a watchpoint on the memory where the value is stored, and then using the “reverse continue” command to run the program backwards(!). The watchpoint will trigger when the memory changes, when will happen whenever it is “overwritten” by the previous value. This is exactly the point where the value you are tracing was written into memory.

This is not as precise as Pernosco’s value traces, but it is still immensely useful. It makes debugging buffer overruns, use after free, stack or heap corruption, etc, etc extremely easy. Since traditional methods of detecting these types of bugs are a lot more work, you can earn an astounding rate as a contractor fixing people's C++ code using RR or Pernosco.

While I also wish Pernosco were open source, there is at least reason to be glad that it is a managed service rather than something we run on our laptops. I talked to Roc about self–hosting (which is available) once and he mentioned that a trace of an application like Firefox gets turned into a database taking up dozens or hundreds of gigabytes of disk space. The only reason Pernosco can turn them around in just a minute or two is that each trace uploaded is given to it’s own 36–core instance for the conversion. Even if it were open source, we wouldn’t exactly be running it on our laptops at the beach.