Added debugger display information to TestScheduler and HistoricalScheduler

[paulomorgado]

This is very helpful when debugging tests.

[danielcweber]

@paulomorgado Nice idea. I wonder whether we want to have this for even more classes, e.g. all the observable implementations. I'm thinking outputting a readable representation of an operator chain. Then again, it might slow down the debugger big time...what do you think?

[paulomorgado]

It might, but only when evaluated.

But, for that use case, a debug visualizer might be a better match.

What do you think, @raffaeler?

[apobekiaris]

@paulomorgado Nice idea. I wonder whether we want to have this for even more classes, e.g. all the observable implementations. I'm thinking outputting a readable representation of an operator chain. Then again, it might slow down the debugger big time...what do you think?

It may be great for some cases however at least in my projects I my experience is a really bad Vs behaviour when property evaluation is on. Consider making a switch off for this as well.

[paulomorgado]

How would I do this, @apobekiaris?

[apobekiaris]

How would I do this, @apobekiaris?

Sorry no clue it just looked something that may affect me.

[raffaeler]

@paulomorgado nice work and great idea indeed.
Another approach is to add an additional field inside the class that is compiled only in the debug fields thanks to the preprocessor definitions. This field could store the timings and would work even without the debugger being attached, allowing for example to trace the timings on your logger/tracer of choice.
With regards to the debugger visualizer, it is definitely feasible but it also depends what you really want to see. It is really a 'visualizer' approach which is used to make the object representation more readable as I did for the Expression Tree which I reverse to the C# representing that tree.

[paulomorgado]

ETW-like tracing would be nice, but that's another thing.

If I recall it correctly, debug visualizations are part of the type/object and debug vizualizers can be an add-on used only by the IDE and that it's not deployed with the library (like analyzers).

[paulomorgado]

Nevertheless, if anyone has suggestions for other types that would be nice to add debug vizualizers, I can add them.

[danielcweber]

@paulomorgado There's actually great potential in this approach I think. As you might know, we would like to optimize some code away but can't because RxSpy, an inspection tool for Rx, depends on certain internals. RxSpy is not in active development and it's unclear to me how widespread its use is. A great deal of its functionality could maybe be replaced by visualizers...maybe....I'm just being visonary here.

[raffaeler]

@paulomorgado I did not mean to replace ETW tracing.
You are right about debugger visualizers. They are just a way for the debugger to "view" in an user-friendly way the state of an object.

[paulomorgado]

@raffaeler, I said ETW-like because .NET Core on non-Windows system doesn't exactly use ETW. Does it?

[raffaeler]

@paulomorgado The abstraction provided in aspnet core is the same for Windows and Linux. On Windows ETW is used. On Linux the abstraction uses LTTNG which is the 'official' way to trace.
The biggest difference is that ETW provides real-time tracing, while on Linux a file is created that you can analyze later either on Linux or on Windows.

[danielcweber]

@paulomorgado We have failing approval tests due to the added attributes on some types. Could you please fix them? I'll merge this PR then, more work on a smoother debugging experience is greatly appreciated!

[paulomorgado]

Done, @danielcweber!