Clearing Coverage From Prior Debug Session

[jmmittan]

I was able to obtain accurate coverage highlighting once the extension was set up properly. However, if I stop my debugging session and start a new session, the coverage highlighting from the prior session is still present. This would be a perfectly good feature if I could find a method of clearing highlighting whenever I wish. I wish to know that I have retested everything after I have made my last changes to my program. Am I missing something, or is this a missing feature? I am running under Windows 10 , not using Docker if that makes a difference.

[OlegKunitsyn]

You are right, atm a reset point of the coverage is recompilation. You may turn coverage off, but its not the case. Can you suggest an event when the coverage must be turned off.

[GitMensch]

The event should be an extension command "clear coverage data".

[GitMensch]

Also: could you possibly split this extension into two? That would be very useful:

• gnucobol-debug can depend on the new one, so installing it would install both
• the split "coverage-data" would visualize the data and provide commands like "clear coverage data"

In this case the coverage-data part can also be used for any other GCC based project (or clang, not sure if they have the same format or this extension already support both) - and also GnuCOBOL programs that were compiled outside of gnucobol-debug.

[jmmittan]

Oleg, you are probably right that recompilation causes "clear coverage data", but that may not be the problem area. Rather, it may be a problem with the red and green highlighting in the editor. Being new to VS code, extensions, JavaScript, etc. I verified external to VS code that compilation did occur on entering a new debugging session (Windows File Explorer shows that the Modified Date of my .exe file changed to start date and time of the new session.) There was a breakpoint set on the first executable line in the procedure division, so when I started a new session, I expected to see all the green highlights from my prior test to be removed when that breakpoint was reached. Instead, all highlights were still there. Playing around, adding additional lines of procedure division code would occasionally result in the new line of code showing as green, even though there was no possibility that it had been executed, This is probably due to an adjacent line of code that was already green, and the editor cloning the highlighting on the new line. Being new, I did not try debugging the extension, or verifying that the coverage data in the gcovFiles array was correct.

I see two possible ways of addressing this issue. One is providing a way for the user to clear the highlights. The other is to clear all highlights at the beginning of each new debugging session. I do not have a preference as to which option is chosen. I will say that I have a large (7000 line) program that I plan to switch to VS code/GnuCobol from OpenCobolIDE. I am hoping that subprogram support is better here, and that this issue does not reoccur when subprograms are involved.

BTW, this is not a show stopper for me. I am just happy to have access to a Cobol debugger that allows me to fully control what compiler options I use.

[OlegKunitsyn]

I'll reopen it as a feature request.

[GitMensch]

I'm sad to tell you that sub programs (compiled as separate modules) is not very well supported in this extension, because it currently (re-) compiles the modules that you debug. There is a (likely) open issue about the option (or, which is prefer) to split the compilation from the debugging, so either with a build task (which also have pattern matchers, support pre-parsing,..) or outside the ide (obviously needs -g and possibly coverage flags) and to just read the C files on the first call. Without this done, I see no way of using this otherwise quite well working debugger in already existing production environments consisting of hundreds or even thousands of programs. If you switch from OCIDE you may want to at least check out Gix IDE, which also comes with a debugger (I've only seen the docs so far, bit they look very promising).

[jmmittan]

Thanks for managing my expectations with respect to subprograms. I have checked out Gix IDE, and found that it is a non-starter for my application at present, as my app employs several arrays where the indexes/subscripts are allowed to be zero or even negative. Gix IDE compilation options cause the debugger to reject these references at run time. Recompiling everything under this extension is not a big deal, as currently, my app is one massive program, and the debugger definitely allows non-positive values for subscripts. OCIDE's linter was quite irritating, as it flags every line of a data division copybook as an error, and that in turn makes normal methods of linking to subprograms too much of a hassle. And since OCIDE is no longer supported, I will probably make the switch to VScode.