Couple issues with SDBG64

And still sometimes SDBG64 does not like some variables and does not list them in the window or expose their value in bubble help if you put the mouse cursor on it. So to see the value of variable1 i create another variable2 and this variable shows its value in bubble. Still both are not listed in the list of current variables in the debugger window

   variable2 = variable1

Did not check my code for couple years on /check /undef because SDBG64 was buggy before on this key combination and only like 9 months ago started to be mostly bug-free, not crashing by itself, showing the exact line with error and etcetc.

And spent 10 hours non-stop compiling-debugging-compiling-debugging-compiling-debugging cleaning mostly array violations i made during this time !

Use debuggers and /undef /check sometimes, people

Quoted from DanRRight ...and there still no way to stop the run in the middle and get into debugger - no appropriate window to pause run

The pause button stops your program (next to run). You can also place breakpoints whilst your program is running.

Thanks, Robert, Wow, a quarter of century i use SDBG and only today noticed this gray button thinking it was kind of useless separator 😃 Or it was added recently? Before Pause was done as a special window, to emphasize its importance. I mostly used keyboard shortcuts, they are more convenient than buttons, plus the menu reminds their definitions

I'd add Pause option to menu, all other buttons are doubled as menu items but not a Pause ! And made icons on these buttons more modern and bright. Or next user will try debugger and will think it lacks some major things for successful debugging and next time will try it like 25 years from now !

The pause button was added when the separate dialog was removed. A menu entry would be a good idea too.

You may have noticed a floating 'dot' that tracks the cursor appears after the line numbers. If you click it the debugger should do a 'get to' that line.

So this dot is analog of 'get to cursor' or F3?

Yes

Robert, If SDBG knows at each moment the line number and subroutine where the code currently is would it be possible to introduce something like the Line Tracer or Back In History feature which will allow after user pauses the code to step back where code was one step before, 3 steps back or may be even 100 steps before the current line? Of course it is much harder to undo the flow of calculations and in many cases this is almost impossible and definitely hard to implement but what i suggest is just the informational, no real undo the calculations is needed. The new menu item will just tell 'Look where the code was one step back - F12'. Hitting F12 user will be able to see the history of run 100 steps back

This would require to add just the one array which will contain say 100 cells keeping the line number and subroutine name in cyclic way overwriting itself when overfilled. Adding this trace back feature will slow a bit the code speed but clearly not much. The user who got stuck in very complex jumping logic of spaghetti-like code may be even happy to agree with this small performance hit

Situations when you need to look back at least one step back are hell often. And you feel a great frustration this is not possible and you need to restart the code and wait for this moment again

The issue is run speed. sdbg can know every line executed but to do so would make your program run like it was in treacle. sdbg effectively has to stop your program every line, take a look where it is and then continue. It could be something you could manually turn on though.

I do not know how things are rolling inside SDBG, how things will be slowed down or how difficult is to add new features, but even the speed of a turtle sometimes would fit. Our programs not always are for speed. This is why we are fans of this compiler by the way, not Intel or gFortran 😃 which sometimes show speedups up to 30x on couple tasks in Polyhedron. if speed is needed we take critical section compiled in fast compilers in the forms of DLLs and add/link it to FTN95.

Often speed even not an issue at all. The numerous IF() GOTO NNN logic, complex jumps READ(.... err=NNN, end=MMM) often require which specifically line of source code caused this jump to label NNN or MMM.

Reading initial settings files always kills me. With time and new code versions their structure becomes hell complex and always gets errors reading versions 3 or 10 years old. You will not find errors there quickly, it is bloody mess. Seeing which lines were read and which were skipped would allow to debug such places in minutes. Instead i do not touch such places for years even knowing error is there if error is not critical

And may be i was not clear. No stop on each line is needed, just keeping in the added memory array of size (2,100) the line number where code was executed and name of function/subroutine. Yes, adding the functionality in the debugger to jump to previous line as a 'curtesy' would make this process nicer. But even listing this bare array (2,100) would help