Feedback on Debugview++

[janwilmans]

• Do you use debugview++ and it works for you? Please leave a comment in this issue.
• Do you have a problem using it, a question or request, just leave a comment here too... (or if you think it is a bug, please just submit a new issue!)

[janwilmans]

Thanks you all for your nice feedback! I will see what I can do to implement your suggestions, the only limitation is time. I try to look forward and work on http://debug.vision/ which is planned as a portable successor of debugview++.

Would any of you be interested to help implement the features? the commandline options are not to difficult, but it does require work.

Also, I consider crashes not acceptable, so if you could provide we with a reproduction scenario that works, that would be really helpful.

[Joliciel]

Hi Jan and RrnR,

It is very nice of you, responding that fast with insightful information. Well, I will try to apply what you are suggesting and letting you know. I will try out Debug.Vision.

To get you in the context, well the language that I’m using to program presently, for the past 31 years, that I still enjoy using, are database’s applications created in Clarion. The way I work is a mixture between the Clarion IDE visual designer and source code programming mostly class object oriented. DebugView is a great tool to follow all these object classes, and source code generated to screen.

Furthermore, to implement DebugView, I have created in Clarion an object class called jcDebugManager and its template integrated in the Clarion IDE to enable and disable the generated code that will display or not to DebugView. As for the result, when I look at the DebugView as I mention in preceding post, I can see the colorized code and the indentation of the logic that I’ve written. Watching at the screen the structure within the program like if I was looking through the code itself with the results, which is great. And more, the way it is formatted and written from within the editor. This permits me easily to understand what I’m programming and see where I can make an improvement over the sources.

Over the years, I found out, there are a lot of DebugView statements that I want; it can be messy between the real code and the DebugView statements. For readability, it would have been nice to get the code in and out when needed. When done manually I don’t want to remove those statements because it is so useful. With that in mind, for the other part, from within the IDE through the jcDebugManager template by turning the code generation on or off; I can effortlessly generate or not the DebugView statements. Other reasons why, when the program is done with implementing all these DebugView statements, as for the result, it is hard to read. I have to make a distinction between the real code statements and DebugView statements; I can get easily lost. Moreover, we do not need all these DebugView statements on the final version. When I program the object class manually most of the time, I keep the DebugView statements of what I’ve done with the jcDebugManager object. So to enable and disable these keep statements, I have a variable that handles a switch to turn it on or off the view to screen; this, without removing the DebugView statements from the program. From the IDE, it is another story; with the jcDebugManager template, I can remove totally the DebugView code statements from the source code program as well as implementing the variable to turn on and off DebugView.

Regarding the crash, to put you in context, it happens only on a large file when the program has just run, with the program process checked and doing the search next and pressing the previous buttons, it crashes. I have tried after with the same file with the DebugView the program did not crash everything went well. The difference between the two, one has a program process check and the other one none. I think it must have something to do with the process checked.

While talking about the process tabs another idea, it will be nice to add process sessions and a button to clear all the processes instead of doing it one by one. I’m sending in the file attachment, the DebugView file and the filter settings.

Joliciel DebugView Log.zip

Meanwhile is there a way for us to contribute. You are doing a great job; it is such a useful tool, and you have made a considerable improvement to the DebugView.

Thanks again and have a great day, Joliciel

[coderkj]

Hi.

I am running into an issue that could be configuration, but not certain. I am using the 64 bit version 1.8.0.86. When I load a log file to review at a later date, the logged "process" has been replaced with the log's filename. This prevents me from filtering a lot of noise out from processes I do not care about. If I view the .dblog in a text editor, it does look like the process name is there for each log entry. What am I doing wrong?

Here is a snippet from the raw log:

0.000000 2020/01/28 10:08:45.758 7128 devenv.exe Informational: ---------- Run started ----------

And what it shows up as in DVPP: 1 10:08:45.758 7128 2020-01-28 Std Tests.dblog Informational: ---------- Run started ----------

"2020-01-28 Std Tests.dblog" is in the process col but is the name of the log file.

DVPP is a great tool - thanks for all the hard work!

[smallscript]

I use DebugView++ practically every day as I am working :-)

I attached a sample of emitting telemetry and observing it in DebugView++. As you can possibly tell the telemetry has a format that emits multiple lines as a single record with a JSON payload.

I have a question and a thought: a) In looking through the source it looks like, but I am not certain, the output could be processed as messages rather than lines. That would allow filtering by message (fabulous) rather than by line (inside a message). b) I often, and we've talked about this before, redirect console-streams with Ansi TTY sequences. Those are easy enough to detect and filter while ingesting a message. But I was not clear how hard it would be to pass those ansi-codes through to actually display their color/style values. c) I can readily set up UDP or TCP stream providers to front end filter and feed through multiple data sources, or provide multiple channels to DebugView++. Is this something that has been done, are there other examples.

Very best and greatful regards,

David Simmons

[RrnR]

Hi Jan,

I've been using DVPP with UDP successfully but I've run into a snag. It seems as if I'm exceeding a line length:

[image: image.png]

If there is a limit, can you advise what it is and I'll make sure I don't exceed it!

Best regards Ross

On Mon, Apr 13, 2020 at 4:43 PM smallscript notifications@github.com wrote:

I use DebugView++ practically every day as I am working :-)

I attached a sample of emitting telemetry and observing it in DebugView++. As you can possibly tell the telemetry has a format that emits multiple lines as a single record with a JSON payload.

I have a question and a thought: a) In looking through the source it looks like, but I am not certain, the output could be processed as messages rather than lines. That would allow filtering by message (fabulous) rather than by line (inside a message). b) I often, and we've talked about this before, redirect console-streams with Ansi TTY sequences. Those are easy enough to detect and filter while ingesting a message. But I was not clear how hard it would be to pass those ansi-codes through to actually display their color/style values. c) I can readily set up UDP or TCP stream providers to front end filter and feed through multiple data sources, or provide multiple channels to DebugView++. Is this something that has been done, are there other examples.

Very best and greatful regards,

David Simmons

[image: Capture] https://user-images.githubusercontent.com/10518175/79092478-ea73fd80-7d05-11ea-92e3-671ff227fbbc.PNG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CobaltFusion/DebugViewPP/issues/283#issuecomment-612747519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRRNAWGGYYB7ASQA4BGIODRMKKAPANCNFSM4DT2BERA .

[codenotes]

Use the app all the time, have also modified source to include some features helpful for robotics/ROS. Very near perfect, I have a small wish list, maybe I will write and submit these mods if I can get to them, but they are:

1) interpret VT100/DEC escape sequences for client app-generated color and formatting: As of Windows 10, windows joins other OSs as supporting color and highlighted console text via the old style terminal code escape sequences. Color in logging is, obviously, very helpful and many console environments, even modern ones, use them. Supporting them is trivial. But it would enable the programmer to simply include the color and highlight they want in their app as opposed to needing to create it on DVPP. Outside of coloring, the ability to have the app being debugged send a "clear" signal to DVPP to clear the old logs would be a god send. It would also be great if the client app could inform DVPP of the coloring, it, after all, "knows best."

2) repetition-suppress log filter: Ability to mark certain log messages as only printing once per some period of time so long as their contents don't change. This is very useful for real-time applications like robotics where you don't need to see a position log sent to you 1000s of times when the robot is sitting still. Just once and awhile, like a heartbeat.

3) click through to visual studio: as with the errors window window of Visual Studio, ability to click a given log and be brought back to the source line in visual studio when double-clicked. A very simple VSIX could accommodate that and, perhaps, become a foundation for other interactions.

4) UTF-8 support. This is not the same as wide-char unicode support which I believe is supported. Subtle but this is the only widely accepted way to support unicode characters without requiring a double-byte conversion of apps which is not always or even often possible, particularly for those of us working with a great deal of legacy libraries. Here is a fail case:

I am sending: u8"←"

which is turned into an ordinary C string with these bytes/chars per the UTF-8 convention: \xE2\x86\x90

I am not an expert at Unicode et. al. But I don't think the UTF-8 system aligns with the way UNICODE is conventionally handled, as UTF-8 can variably have, I think, up to 5 bytes to represent a non-ascii char. and so :

DVPP prints: "â–²""

[nirlivne]

We used DebugView and now my whole team uses DebugView++ DebugView++ is awesome! It's a huge upgrade. I love the view settings, how easy to config filter and color messages / hide noise from other processes I use multiple views and the Link views button is very usefull Keep up the good work! we love it!

[janwilmans]

@codenotes nice suggestions, however, I'm not adding new features to debugview++ anymore. I'm trying to get https://debug.vision/ off the ground. It aims to be multi-platform and also to have UTF-8 support.