soccer jersey forums.silverfrost.com :: View topic - Couple issues with SDBG64
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Couple issues with SDBG64
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Fri May 21, 2021 8:10 pm    Post subject: Reply with quote

Robert,
What is pause button? There is no additional small dialog window where i remember was something like that. What i am saying above is that there is either the bug or the default behavior of debugger was changed as now to stop (pause) the run during the execution and fall into debugger i need to push Alt+X which in previous versions was used only to close debugger

Dietmar,
Exactly what i meant
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue May 25, 2021 9:22 am    Post subject: Reply with quote

For ftn95 version 7.10 after pressing F6 in the debug session with sdbg after some time a dialog window (with titlebar "Waiting" ) is displayed. This dialog window contains a push button with text "pause" and the text "The application being debugged is running. Control will return to the debugger when either a breakpoint or error occurs."

I thought this was exactly what Dan requested with
Quote:
How you interrupted the run ? There is no small window which was present during the run the only purpose of which was to interrupt the run and get into debugger
.

Unfortunately I do not see this dialog window for ftn95 environment 8.73 (32 bit case) and for ftn95 environment 8.10 (32 bit case which I checked this morning).

Regards
Dietmar
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Tue May 25, 2021 9:52 pm    Post subject: Reply with quote

Yes, this is what new SDBG is missing. If company decided to interrupt the run different way - this has to be clear in the menu

For example i can interrupt my programs with 1) Hot key 2) menu Run-Pause-Continue-Stop 3) Radiobutton 4) Similar little window like older debugger. All are convenient for different situations, and often you need to act quick. In earlier versions of Clearwin only 4th option was rock solid and always interrupted any code even if it froze. Currently i see all 4 work OK
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Tue Jun 08, 2021 3:47 am    Post subject: Reply with quote

I think Alt+X is still not functioning like it was with 32bits. After you hit Alt+X SDBG closes debugged file but does not exit
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Wed Jun 09, 2021 3:33 am    Post subject: Reply with quote

...and there still no way to stop the run in the middle and get into debugger - no appropriate window to pause run
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Wed Jun 09, 2021 7:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Tue Jun 15, 2021 12:26 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Tue Jun 15, 2021 8:43 pm    Post subject: Re: Reply with quote

DanRRight wrote:
...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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Wed Jun 16, 2021 5:39 am    Post subject: Reply with quote

Thanks, Robert, Wow, a quarter of century i use SDBG and only today noticed this gray button thinking it was kind of useless separator Smile 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 !
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Wed Jun 16, 2021 9:24 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Thu Jun 17, 2021 5:24 am    Post subject: Reply with quote

So this dot is analog of "get to cursor" or F3?
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Thu Jun 17, 2021 9:09 am    Post subject: Reply with quote

Yes
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Sat Jun 19, 2021 7:03 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Mon Jun 21, 2021 9:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2863
Location: South Pole, Antarctica

PostPosted: Mon Jun 21, 2021 9:16 pm    Post subject: Reply with quote

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 Smile 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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group