8.10 Clearwin64 with /CHECK

Since 8.10 64bit FTN95 allows /check now I tried it and got the following error

4796.     i = winio@('%^`7ps&',ish1, ish2, ish3, ish4, ish5, ish6,
      

4797.  *  ish7, n_CurrSheetSettings01, cbupdateSettings01)
      

*** Error 1222: Argument number 4 (ISH3) of WINIO@ should be a call-back function

Just to inform, not urgent.

/* Superfast input/output speeds FTN95 is capable of course is more important and could be a huge selling point specifically if you directly compare with the speed of other compilers.

There is a new (/CHECK) checking feature that is raising some false error reports. It checks winio@ arguments at compile time for 64 bits.

You can switch off this feature by adding '/inhibit_check 16' whenever you use '/64 /check'.

Thanks. And checking WINIO@ syntax would be nice feature.

Hints of the compiler for some complex controls during error reporting would be also appreciated. Like which arguments go first if you use ^, ' #, ~, @ like in here

i=winio@('%~^bt[Run]', arg1, arg2, arg3) i=winio@('%~^?rd', arg1, arg2, arg3)

(may be introducing verbose checking mode /verbose which in the error listing tells about what standard recommends, what's better for portability, may be about some users' suggestions and their best practices, future trends etc. Of course we can read that in the HELP file but at the time when user looks at the specific reported error in his code after compilation it would be much more useful)

Here is another error of the same sort to fix in the future: debugger reports error in the wrong line in 64bit mode (in 32bit all is OK)

Real*8 C

  i=winio@('var %ta%8rd%8rd %ff&', &
     iA, iB, C) 
  i=winio@('%bt[OK]')

end

By the way the example above is not Clearwin-specific.

Took today newer SDBG64. Looks like suggestions above were missed. I'll write them again and add some new 1)does not show error line correctly in the example above and sometimes in other cases missing it by 1-2 lines both ways (show before and above actual offending line) 2)shows 2 lines in red instead of one 3)all windows do not fit well (I cannot see line number in the bottom for example). Also there is unneeded margin on top (just below menu) 4)no option to save new windows position if you more or rescale them
5)no option to restart debugging program keeping all the breakpoints 6)huge inconvenience of older sdbg is still here: if you hover mouse over variable which is declared as parameter then you can not see its value in bubble help

 parameter (iParameter=11)
   i=alog(exp(22.))
   if(i.eq.iParameter) print*,'something'
 end 

7)Ctrl+PgUp and Ctrl+PgDn do not work. If file size is large you lose time to get to the beginning or the end of file.

8)that is something for the future 'Ideal Debugger': option like one step forward F7 but to go one step back with say Shift+F7. This way would be great to catch reading errors like

READ(22,'(I3,1p,10e10.3)',err=100) ivar1, variable2, variable3,...

When reading error occurs you usually painfully catch the bad line where it took place. Reading in Fortran is always painful due to its numerous options. And if the file is huge - this is a pure hell. With go back Shift+F7 feature it would be found in no time. You just put debugger stop on line with label 100 and when error occurs you just push Shift+F7 and debugger gets one step back on that offending READ before it jumped to label 100 ! No other debugger has this !

Thank you. I have made a note of this.

6)huge inconvenience of older sdbg is still here: if you hover mouse over variable which is declared as parameter then you can not see its value in bubble help

/full_debug on the compiler command-line includes parameters

When reading error occurs you usually painfully catch the bad line where it took place. Reading in Fortran is always painful due to its numerous options. And if the file is huge - this is a pure hell. With go back Shift+F7 feature it would be found in no time. You just put debugger stop on line with label 100 and when error occurs you just push Shift+F7 and debugger gets one step back on that offending READ before it jumped to label 100 ! No other debugger has this !

Is this because you have many read statement that could go to label 100?

Quoted from Robert /full_debug on the compiler command-line includes parameters

Robert, Great, though i'd strongly feel that parameters should always be visible in debugger

When reading error occurs you usually painfully catch the bad line where it took place. Reading in Fortran is always painful due to its numerous options. And if the file is huge - this is a pure hell. With go back Shift+F7 feature it would be found in no time. You just put debugger stop on line with label 100 and when error occurs you just push Shift+F7 and debugger gets one step back on that offending READ before it jumped to label 100 ! No other debugger has this !

Is this because you have many read statement that could go to label 100?

Yes, there is often very painful to make numerous error messages for each of hundreds of complex READ statements of hundreds different large files. You immediately go into panic mode because you know to find error will be a hell. To simplify this i made the line counter like this

	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	  READ(1,'(13x,i4,16x,e10.3)',err=100) K_M...
	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	  READ(1,'(8x,i4, 21x,e10.3, 14x,a)',err=2430) Key_pro...
24310    lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	READ(1,162,err=100)  IPAKET, KEYTI...
	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	READ(1,80862,err=100) Activ_par, cALF...
	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	READ(1,...
	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
	READ(1,...
	     lineI_I = lineI_I + 1;if(kPSc.eq.1)print*,'Line=',lineI_I
        ...................
        ...................

and when reading error occurs the file is loaded into special visualization window in %eb-like editor and the offending line is highlighted - all that because it is really THAT hard to find the line where error takes place

But i am sure Back-F7 feature could find other nice usages for debugging. If it is possible to implement it of course. For example it is sometimes painful to load the entire program again and wait and click and jump for the error to occur again. But with Back-F7 feature that would be in no time: you just make one step back to the statement before the error occured. You then see immediately what were conditions which led to the error - THIS WOULD BE TRULY SUPERB FEATURE, no other compilers probably ever had or even thought about this

Quoted from Robert

6)huge inconvenience of older sdbg is still here: if you hover mouse over variable which is declared as parameter then you can not see its value in bubble help

/full_debug on the compiler command-line includes parameters

Looks like there is still no parameters even with /full_debug

2. Another problem with the debugger - if you click on the variable B in the IF comparison like this

if(A.gt.B) then

SDBG64 does not show its value. Instead the message comes 'Structure expected'

3. This debugger still has the same problem I reported before. Bug appeared 5-8 years ago when you try to use F7 'stepping by one line'. The right mouse menu then appears on screen and if you close it reappears again next time you use F7. After 20-30 times of this torture you become furious. That is the case on all my computers, and I am really surprised of impossible - that no one else reported that. Seems all users debug grand-grand-daddy way by inserting Print*, and developers do not use Fortran, they use C. Another explanation is that I live like in the 'Matrix' movie. Seriously, this is impossible.

4. Here is a suggestion not a bug problem: when the statement has continuations on many lines the breakpoint can only be set on last one. This requirement has no sense and the breakpoint on any of these lines must be allowed.

/full_debug shows parameters for me. Can a few other people try it?

I have never seen the F7 producing a right mouse menu. Does it just do it using the keypress or does the toolbar button also produce the menu?

Respect to right mouse menu: it appears not immediately but after few times using F7, may be also using F6, setting F2, looking at variable in popup window etc but it is reproducible and always appears

Here is one more request for SDBG

When you debug file containing call of DRAW_LINE@, draw_filled_ellipse@ etc the plotting does not appear as you go line by line and only appears when you end the program. Here is example. Try to debug it line by line, and you will see that plotting takes place only when the program finishes.

If this functionality does not exist, great for debugging would be to allow plotting as you go

PROGRAM main
 use clrwin
 INTEGER iw
 integer ctrl
 real sinx
 iw=winio@('%ca[ATV]&')
 iw=winio@('%gr[smooth4]&', 220, 110)
 iw=winio@('%lw', ctrl)

 call draw_filled_ellipse@(40, 40, 30, 30, RGB@(255,0,0) )
 call draw_filled_ellipse@(70, 40, 30, 30, RGB@(0,255,0) )
 ! draw this circle with opacity
 call draw_filled_ellipse@(55, 70, 30, 30, nARGB@(192,0,0,255) )
 ! set general opacity to 50% 
 call set_opacity@(128)
 call draw_filled_ellipse@(150, 40, 30, 30, RGB@(255,0,0) )
 call draw_filled_ellipse@(180, 40, 30, 30, RGB@(0,255,0) )
 call draw_filled_ellipse@(165, 70, 30, 30, RGB@(0,0,255) )
END PROGRAM main 

Unfortunately that would require significant changes to the code. ClearWin+ drawing does not go directly to the screen and the feature would have to been switchable within the DLL.