SDBG64 couple improvements

1. Suggestion for Settings: SDBG64 has to allow user to set the format of real4 and real8 variables (by the way same problem also exists with Clearwin which is doing the same). Currently is what i get when displaying values of variables like in this case REAL*8 variable EnOfEl as

Definitely this would be perfect if i was a robot or AI. For us dumb humans such detalization is typically not needed and such F format numbers mostly hard to comprehend. I'd prefer to see all REAL numbers in E or D format like 1.23456789.e12 or something i'd set in Settings. Or even better - the numbers larger than 100k or a million displayed in E and D format and smallr in F format

2. SDBG32 allowed to see the names (or open UNITs ) of opened files. 64bit one miss that. As a result i got some usual 'present from the hell' again in my Saturdays which i can not quickly resolve. The code opened for me one of numerous files (during its run the 50 years old code opens hell lot of different files purpose of which are now mostly forgotten) with has the name with 256 Euro signs

   €€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€ where data has no any hints what is this (just usual set of numbers) . Can anyone suggest how to catch which part of 710,000 lines code doing this witchcraft? Clicking the code step by step in debugger would take ages.

Was this a hint that i will get or lose many Euros soon? 😃

More small defects of SDBG64

• Sometimes when you try to scroll the text up and down using mouse wheel the text gets right instead. I think this did not exist in SDBG, and I never needed this functionality but i watched for it for few years to find a single case when it could be useful. Never found one. May be others? But looks like it is a bug, because to return text back only using arrow keys work.

I do not know how to reproduce this feature/bug. It just happened after mouse was on sleep after some time of inactivity

• Over time when you open and close the debugger multiple times the debugger's source code window get little bit smaller and smaller until you have to correct its size manually

Thanks for these Dan. Did you find the money 😉

The Euro signs are probably the result of two facts: (a) The Windows-1252 code page uses the byte Z'80' to represent the Euro, and (b) bytes with value Z'80' are used to represent and catch undefined variables in FTN95-compiled programs.

So Dan, enjoy your ephemeral opulence!

Robert, Nope. I still have may be dozen such bugs for which I simply have no time. Every time I add something serious to the code something else will be broken. Is something in the debugger which simplify finding such bugs? For example there exist very nice option to stop on use or write on specific variable. Can be added here an option to stop on opening any new file or opening file second time etc? I have 500 different files which could be potentially opened in 700k lines source code. It was developed for 40 years.

Mecej4, ok, but how to catch in which of 500 files?

Also there could exist some debugging option I don't know

Dan, if the large program that you are working with contains some parts/files that were developed in the old days, it is possible that the program uses 'I/O to implicitly connected files'. From the IBM XL Fortran manual:

'All other units can be implicitly connected when an ENDFILE, PRINT, READ, REWIND, or WRITE statement is performed on a unit that has not been opened. Unit n is implicitly connected to a file that is named fort.n. These files need not exist, and XL Fortran does not create them unless you use the corresponding units implicitly.'

If such an implicit connection has occurred, the name of the particular file is undefined, and that is what you may be seeing in SDBG as a string made up of Euro signs.

It would help if you can create a small test case to investigate this possibility.

Mecej4,

Remember you have made one long confusing program which extracts demos from the codes? I was lost in it even more than i am lost in my own codes. And never succeeded due to usual lack of free time.

Isn't it time to suggest an improvement for FTN95, create it again possibly using ChatGPT and include into debugger? You will tell debugger: 'extract me from this long spaghetti code smallest possible demo which includes this subroutine which causes me trouble'

And instead of typically weeks, months or often even never for the most cases it will be done in 3 seconds

better still; possibly using ChatGPT and include into debugger. You will tell debugger !! 'extract me from this long spaghetti code smallest possible demo which includes all the bugs which causes me trouble'

I wonder how they debug that stuff (ChatGPT). The amounts of data are enormous.

My son who took the class on AI at MIT now often uses like 4 different accounts of his friends who are not using it actively 😃. But the version 3.5 which is i think enough for Fortran (though i always remember about 640k which supposed to be enough for everyone) is unlimited and free

Another great application of AI would be C/C++ to Fortran translation. Compilers will be also AI based, that's exactly its best apps. Start early, guys, don't delay. Years ago Salford/Silverfrost was the first at everything in Fortran. Paul, you have already tried it, any further progress at it ?