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
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
Robert



Joined: 29 Nov 2006
Posts: 390
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: 2446
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: 390
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: 2446
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
Page 3 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