View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Jun 03, 2018 3:25 am Post subject: |
|
|
Dan,
Are you going to make the same mistake 100 times a day for the rest of your life ? ...
Imaging how much time you are wasting having a coffee each day; and all the time you have spent moving all over the world.
You should start using implicit none and get rid of most of those bugs. You must be able to do that in less than 300 days !
I'm off for a coffee, as I just found a "bug" that's been bothering me for 4 years. By your analysis, will I have more time now ?
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Sun Jun 03, 2018 4:24 am Post subject: |
|
|
John,
Of course we waste hell amount of time on humongous amount of cr#% in the world. Sometimes we can not do anything with it sometimes we can.
I use /UNDEF, which is better then implicit none, John, how may time I repeat this in 3 decades on all Fortran newsgroups and no one hear that?
I copy/paste large variables (and they usually all large for self-documenting) not typing them again and again so there is no source of error for static variables. Also I use new compilation options /NO_TRUNCATE which removes the main source of errors catched by the "implicit none" - i.e. getting over 72/132 character limit. So my mouse trap is pretty powerful.
It's the logic errors which are the main source of bugs in large codes not just damn static typos. To move even most stupid step ahead in large code (add some new obvious feature for example) i need to review if this will not interfere with the whole older stuff I added for 30 years which is why I make most of errors. All heavily used codes essentially grow and grow and at some point become unmanageable. Even if I have done that 100 times adding new feature is like a head surgery in the web of the source code.
And also the code development is the main source of lost time not run time for those who make codes in physics. BTW, today Saturday just started, but I already have done 30-40 compilations.
To get a proof that /undef is more powerful then "implicit none" take any large code made by someone which never used /undef but used only "implicit none" and make a fun of its author showing how many bugs his code has. I guarantee the code's author will spend a month in total #$%^& trying fixing all that.
Last edited by DanRRight on Sun Jun 03, 2018 10:08 am; edited 2 times in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Jun 03, 2018 6:52 am Post subject: Re: |
|
|
DanRRight wrote: | To get a proof that /undef is more powerful then "implicit none" take any large code made by someone which never used /undef but used only "implicit none" and make a fun of its author showing how many bugs his code has. |
Dan. this is a good idea. I shall try it with my graphics code. Is /64 /undef supported, as I have just started using /64 /check ? |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Mon Jun 04, 2018 11:02 am Post subject: |
|
|
Robert,
thanks for the link to the zipfile containing a new version of sdbg64.exe which fixed the problem of setting a variable within sdbg64.
Regards,
Dietmar |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Tue Jun 05, 2018 8:34 am Post subject: |
|
|
I put a new version up at that link. It closes the executable much faster. It misses out some cleanup code. Can people report any issues when closing down the debuggee. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Jun 05, 2018 8:45 pm Post subject: |
|
|
Dan, what am I supposed to see with your Hello 'program' ?
As I see it nothing happens it just lags the only line in the program. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jun 06, 2018 12:39 pm Post subject: |
|
|
Robert,
with version 8.30.2 of sdbg64 I now run into problems when opening some of the debugger's "Window" menu. When trying to debug
Code: |
integer*4 idum
idum=5
write(*,*) 'idum=',idum
end
|
(the example I mentioned above)
opening submenu "Variables" has no effect,
opening submenu "Common blocks" opens no window and makes sdbg64 hang.
Has anyone else observed similar problems with this version of sdbg64?
Regards,
Dietmar |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Thu Jun 07, 2018 8:01 am Post subject: |
|
|
Doesn't the variables window open automatically? |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 8:45 am Post subject: |
|
|
Robert,
no, the variables window does not open automatically.
The problem is even worse now.
After having started the sdbg64 debugger (version 8.30.2) once, the variables window did not open automatically.
The next start of sdbg64 did not even show the source window of the debuggee, this was the case for sdbg64 version 8.30.2, version 8.30.1 and 8.30.
I have no idea what might have happened with respect to my build/sdbg64 environment with respect to yesterday.
Regards,
Dietmar |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Thu Jun 07, 2018 8:50 am Post subject: |
|
|
It might we worth having a look at the sdbg64.ini file to see if it has any corrupted values in it. On my machine it is at:
C:\Users\Robert\AppData\Roaming |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 10:37 am Post subject: |
|
|
Robert,
thanks for the hint. I did not find any suspicious data in my current sdbg64.ini file, however, I overwrote it with a backup from 2017. This helped to be able to debug again and see windows
per default. Some observations:
1.
First line of file sdbg64.ini is
[Debugger-Win32]
which seems to be strange for a 64 bit debugger.
2.
Where do I find information about the semantic of sdbg64.ini?
3.
Some time ago I complained about not being able to see the version information window after having clicked menus "Help" and "About Debugger..." in sdbg64. This is still a problem and I wonder if this problem might be related to my sdbg64.ini file.
4.
To me it is unclear what caused the problem to the previous sdbg64.ini files which seemed to be wrong.
Regards,
Dietmar |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 07, 2018 11:47 am Post subject: |
|
|
Robert,
in connection with a problem previously mentioned I ran in another problem when trying to change an integer*8 variable from within sdbg64.
Code: |
integer*4 idum
integer*8 idum8
idum=5
idum8=4294967296
write(*,*) 'idum=',idum
write(*,*) 'idum8=',idum8
end
|
Now I stopped the debugger after the idum8 assignment and tried to change idum8 using the command tool of sdbg64 and command
; this resulted in value
Code: |
-3689348818177884159
|
for idum8 which was not what I expected.
By the way, it would be nice if I could have had the chance of copying the idum8 value to the clipboard from one of the windows displaying variable idum8 in sdbg64.
Regards,
Dietmar |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Fri Jun 08, 2018 4:52 pm Post subject: |
|
|
I have updated sdbg64 to handle the let statement with integer*8 variables. I have also added a Copy onto the context menu for the single line inspectors. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2815 Location: South Pole, Antarctica
|
Posted: Sun Jun 10, 2018 9:53 am Post subject: |
|
|
Robert, Thanks for 3 sec delay fix. Please look at other suggestions/problems of SDBG64 above.
And one more bug to fix: when compiler/SDBG64 gets overflow or denormal variable it crash with access violation instead of error report like SDBG is doing |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Mon Jun 11, 2018 12:00 pm Post subject: |
|
|
Robert,
thanks for the update to the let statement and the addition of the copy to the context menu. I have downloaded this new version (8.30.3) from the web link you mentioned above. Using the let command I could set variable idum8 to 1 as expected.
However, command
Code: |
let idum8 = 2147483648
|
still does not work in my opinion. This command results in
which I think is not correct.
Note: 2147483648 equals 2**31 which is 1 more than MAX_INT (2147483647). For variable idum (which is of type INTEGER*4) this result is ok and it is shown by sdbg64 for idum after having executed the let statement:
However, idum8 is of type INTEGER*8 !!!
I changed the original test programme to sdbg_test1.for:
Code: |
integer*4 idum
integer*8 idum8,idum88
idum=2147483647
idum8=2147483647_4
idum88=2147483648
write(*,*) 'idum=',idum
write(*,*) 'idum8=',idum8
write(*,*) 'idum88=',idum88
idum8=idum8+1
write(*,*) 'idum8=',idum8
end
|
and compiled it using command
Code: |
ftn95 sdbg_problem1.for /debug /64 /link
|
Executing sdbg_problem1.exe resulted in output lines
Code: |
idum= 2147483647
idum8= 2147483647
idum88= 2147483648
idum8= 2147483648
|
This shows that idum8 and idum88 work in the code and executable as expected.
Moreover: the ftn95 command mentioned above resulted in
Code: |
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
INTEGER(KIND=4)
|
Finally I tried using assignment
which however resulted in
Code: |
*** Invalid KIND specifier
0006) idum88=2147483648
WARNING - Constant is out of range for INTEGER(KIND=3) - has been promoted to
INTEGER(KIND=4)
1 ERROR, 1 WARNING [<main program> FTN95 v8.30.0]
*** Compilation failed
|
I wonder if sdbg64 still has a problem here.
Regards,
Dietmar |
|
Back to top |
|
|
|