FR: Automate the start of the debugging session.

[eugeniodilo]

When you run a debug session by animating the program, you always start from the first statement of the Procedure Division. Now the program starts by displaying the debug window from the first line of the code, normally the Identification Division. To start the session you have to scroll through the entire source for example the working-storage (often many lines of code to scroll through) to select the first instruction after the procedure division, at which point you insert a breakpoint with the command B and then you must execute the R command. Both of these initial commands (both B and then R) are always repetitive and therefore could be executed automatically every time you start a debugging session.

Request:

• automatic insertion of a breakpoint at the first statement or paragraph of Procedure Division
• automatic execution of the R command
• first screen showed in a debugging session will be the starting point of Procedure division next, from this point you can then proceed with the debugging session, for example with the S command.

This behavior could be driven within a configuration file.

[marcsosduma]

Hello Prof. Eugenio! I believe I arrived at something close to the suggestion. Thank you.

[eugeniodilo]

Hi Marcos, thanks again for your effort, I'm doing some tests and I'll let you know. In any case I have to say once again that you are really doing a wonderful job ! It's exactly what we've been waiting for for a long time.

[marcsosduma]

Hi Prof. Eugenio! Thank you very much. I think the major work was done by Oleg Kunitsyn (https://github.com/OlegKunitsyn/gnucobol-debug). I am just trying to translate his code into a command-line application.

[eugeniodilo]

ok I know.

But your work makes the debugger independent from any IDE ! This way it could become an integral part of the GnuCOBOL suite. Consequently, when you go to install GnuCOBOL you will already have the debugger available. In the same way as other compilers, for example Micorofocus, AcuCoBOL, RealiaCOBOL etc etc

PS. Can you tell me where I can find a functional description of the improvements you are introducing these days? for example the use of the mouse is really a major improvement. Click to activate / deactivate a breakpoint, click to proceed with debugging, click to see a variable... really great job!

[GitMensch]

@eugeniodilo all ocumentation is currently at https://github.com/marcsosduma/cobgdb/blob/main/README.md; it would be quite nice if you may suggest which parts to split out into which other files.

A common separation is "README -> what is this, some highlights, possibly notes on how start using it, link to other files, dependencies (+, if it isn't much: how to build/install)" + CONTRIBUTING + docs/multiple-files.

I could then set this up which would allow you to then easily contribute (if you are fine with that and can handle the git part, then a pull request to split the files would be useful, too; actually you don't have to know the git parts if you open the online editing with pressing "." at https://github.com/marcsosduma/cobgdb - as then this could be handled in the vscode online editor).

[eugeniodilo]

That's fine but a README file cannot be considered like documentation. I have already produced a document (something like a User manual and a user Demo ) which I have attached to https://sourceforge.net/p/gnucobol/discussion/contrib/thread/058d5c44de/?limit=50#b465

I could update this document and upload it here in github perhaps in a new "Documentation" folder. What would be needed is a concise and summary description of the changes and new features that are introduced by the developers. At the moment I am discovering the new features on my own initiative by trying to use the product and clicking here and there....

[GitMensch]

Agreed:

• there should definitely be a CHANGELOG
• the README should only contain the "big picture"
• the documentation should be kept separate; would you adjust your documentation to be split and in markdown files?

I'd suggest something like https://github.com/redhat-developer/vscode-xml, with the README pointing to the docs, both in general and to specific elements https://github.com/redhat-developer/vscode-xml/tree/main/docs, and guess @marcsosduma is fine with that if "we" do that work.

Once a CHANGELOG is available it is quite easy to add to it.

[marcsosduma]

Good morning, everyone! We can proceed, indeed. I don't see any issue. Thank you.

[eugeniodilo]

isuue closed.