Not Clear diagnostics

Usually spending hell of time to decipher where is my error due to such diagnostics. Would it be possible for compiler to tell exactly what's wrong - which variable is bad ? The one like below was acceptable when the cars were not self-driving 😃))

 i=winio@(' Angle, delta %30^sl %10`rf %30^sl %10`rf %ff&', &
 Slider_Angle,      0d0, 180.01d0, PrepDataForSlider_f_E, Angle_f_E,&
 Slider_AngleDelta, 0d0,  90.01d0, PrepDataForSlider_f_E, AngleDelta_f_E)

*** Error 1221: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, 
    INTEGER(3), INTEGER(4) or REAL(2)

*** Error 1221: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, 
    INTEGER(3), INTEGER(4) or REAL(2)

In similar situations, where it is not clear which variable has an improper type and causes the compiler to issue an error message but without the name of the variable that is responsible for the error, we can specify /xref and look at the types in the cross-reference listing.

I tried this code based on your report:

program drw
implicit none
integer i
real Angle_f_E  ! not suitable as argument to WINIO@
double precision Slider_Angle, PrepDataForSlider_f_E,AngleDelta_f_E, Slider_AngleDelta
!
i=winio@(' Angle, delta %30^sl %10`rf %30^sl %10`rf %ff&', & 
   Slider_Angle,      0d0, 180.01d0, PrepDataForSlider_f_E, Angle_f_E,& 
   Slider_AngleDelta, 0d0,  90.01d0, PrepDataForSlider_f_E, AngleDelta_f_E) 
end program

The 8.51 compiler produced a zero-length file for the cross-reference list.

I am making so many typos and errors per day that usually avoid any xref or lis or any other additional files besides the standard output of diagnostics because afraid to break my head in these additional kilometer long files. The standard compilation output warning and comment output is also hell long but there it is possible to search for the pattern *** and this is the only i can afford doing 200 times per day 😃

BTW, in my case all variables were real*8. The final place for error was in not declaring integer, external:: PrepDataForSlider_f_E.

Compiler kept mum about this and that caused me to lose an hour swearing on myself and a devilry 😃

Compiler diagnostics should be much more specific and more verbose in explaining errors. We are living in the times when computers with artificial intelligence overcome humans, why they can not find such easy for them errors for themselves?

Quoted from John-Silver Mecej4 ...

The 8.51 compiler ?

where did that materialise from ?

See Paul's post of Fri May 31, 2019, https://forums.silverfrost.com/Forum/Topic/3557 .

Duplicate, please DELETE!

[quote='John-Silver']

[quote:26dfad43d0] Not a chance ! computers with articiììficial intelligence are only as good as the human programming them ! (same goes for all programs actually 😃

We program into computer models so complex things that we can not find the solutions by ourselves. Computers can follow simultaneously 1000 things, we humans barely 1, 2 or 3. The most of human activity is usually just to choose one way which we think is optimal among several possible variants. Like one your guy ones said 'Americans are always eventually doing things right way... after exhausting all other possibilities' 😃)) Not just Americans, obviously.

Computers can do optimization work much faster and take larger sample base. Generally we lose even to a fish or simple fly: the fly is smarter to escape than any human initially think, and it takes time before we really learn how to kill a fly (even then we lose in score win-lose ). Do you think 99% of people do way different things than simple ant is doing? Robots can substitute most of their activity in the life easily

Quantum mechanics theory for example was found by simple random try process to find the mathematical formulas which fit the experiment. We completely lost understanding of things at this moment, we can only find appropriate mathematics which fits the life. That what now is called 'understanding'. Robots will be able to do this even better. Not even mentioning again the solution of complex things we are barely capable of on very simplified models. That all means end of humans

In future these error messages for winio@ will take the form

error 140 - WINIO@ cannot process REAL(KIND=1) argument XMAX, only CHARACTER, INTEGER(3) or REAL(2)

for a REAL(1) variable XMAX.

For an invalid constant it will give the number of the argument.

Quoted from PaulLaidler In future these error messages for winio@ will take the form

error 140 - WINIO@ cannot process REAL(KIND=1) argument XMAX, only CHARACTER, INTEGER(3) or REAL(2)

for a REAL(1) variable XMAX. For an invalid constant it will give the number of the argument.

Nice addition. So now wrong variable will be called by name explicitly together with its position, like 'argument #21 in continuation @143 ? That would be great. I think almost all winio@ code should be compiled with the switch /full_debug even if the entire fortran source is compiled /nodebug /nocheck /optimize because nobody cares how superfast windows are popping into face. Much more important that GUI will diagnose itself fully when problems occur. Clearwin is not a standard Fortran and people forget its rules easily, or even did not even know at all, and almost definitely do not understand how its magic works.

And also how about real source of this error in my code (missing function, or not declaring it as integer, external) if none of the real*8 violations would be found? Would it be possible to have diagnostics like 'Declaration of the function PrepDataForSlider_f_E as integer, external is missing?'

One more suggestion - Error diagnostics should not mention Integer where there is no integers, and REAL, where is no specific reals. Also i still mix up in my head all the KINDs of this Fortran, KIND(1), KIND(3), KIND(7)... the naming scheme made by Standard is an absurd made to make Fortran to die slowly and painfully among engineering and even scientific crowd. May be a hint has to be made to name KINDs more bytes-specific. Computers are smart and can do that. People by great majority are stupid or at least for sure lazy and have great inertia.

For the FTN95, the best diagnostics compiler (but too laconic and cryptic on that) offering user friendly deep (a la 'Level 3') diagnostics is just some minor cosmetic change. This is not of any priority of course, just the suggestion for the potential distant goal. I'd personally see the Polyhedron tests speedup first

Quoted from DanRRight ... One more suggestion - Error diagnostics should not mention Integer where there is no integers, and REAL, where is no specific reals.

If you did not put in IMPLICIT NONE, either as a statement or a compiler option, Fortran implicit type rules were in force. The argument PrepDataForSlider_f_E has the implicit type REAL, so the compiler is correct to mention 'REAL' as the incorrect type for an argument that had to be integer -- indeed, the behaviour that we expect from the compiler.

In our specific case compiler was simply too lazy. In '...%30^sl...' compiler knows for sure what ^ means. It means here is expected not a variable but a function. Despite of that it did not check if something where it should be placed a function was declared as a function. Functions for winio always have to be declared, here no freedom is given like avoiding using implicit none. And by the way for more general case the compiler also knows if 'implicit none' was declared or not. If not it can give more precise diagnostics about expected reals and integers just by first letter. So, here we return to our forgotten sheep: don't use implicit none! 😁

Quoted from DanRRight In our specific case compiler was simply too lazy. In '...%30^sl...' compiler knows for sure what ^ means.

We could also say '... too efficient'.

Some checking is done at compile time, some other checking is done only at execution time, some things are never checked at all. The first argument to WINIO@ is similar to a format string in a READ or WRITE statement. Since such a string can be modified at execution time before being passed as an argument, in general such an argument cannot be checked at compile time except in a limited way. Take, for example,

integer i
...
i = 123
write(*,'(1xE12.3)')i
...

The compiler will tell you, at compile time, that the format is missing a comma, but not that the format E12.3 is inappropriate for an integer argument. If I add the missing comma, compile and run, the mismatch is detected only during execution.

The compiler behaves similarly when you use WINIO@. It appears to check only the types of the arguments at compile time ... string followed by any number of arguments of type integer, double precision, ... When the error involves passing an integer argument when the control string calls for a double precision variable, such an error is checked before execution of that WINIO@ call, not at compile time.

When the format/control string is constant and completely known at compile time, in principle the compiler could check each argument for conformity with its corresponding format/control specifier within the string. However, that would require that the checking code be duplicated in the compiler and the RTL, or that the checking code should be in one DLL that is used by both the compiler and the RTL.

Quoted from mecej4

When the format/control string is constant and completely known at compile time, in principle the compiler could check each argument for conformity with its corresponding format/control specifier within the string. However, that would require...

That is exactly what in 99.999% codes are happening, including my example above. The probability of making typo or error by the programmer is way larger than the probability to find super-picky programmer who will invent such format like above 1xE12.3 hell know what 😃 . But the compiler tells 'OK, i'm too stupid to catch these errors, and lazy too, but who cares, at run time we will see if program crash and that will find you error'. Three hours after the run started... 😭

This was often an argument of users who preferred GUI builder Winteracter to Clearwin+. They did not like that CWP barely reported any errors at compile time and then when you try to run, it either crash or did not run as expected (right now CWP is better with this but still i'd prefer for it to check everything even undefined variables at compile time otherwise large GUI will be unstable and we will get some errors and crashes which will be hard to resolve). And this is also why no one uses Fortran for heart rate pacemakers. Imagine how after firmware update, the pacemaker will start running and in the typical manner of all Fortran programs will crash right in the chest of the patient 😃 Because errors are found at run time. This is like a bike with no brakes which stops by hitting something. Crash is fortraneers' best debugger and all of them think this is normal.

In case anyone has missed it, there is a relatively new FTN95 compiler option /CHECK_WINIO that does some checking of winio@ arguments which otherwise would not be checked until runtime. This will only be useful for simple winio@ calls. As mecej4 rightly points out, there are some things that can only be checked at runtime.

As for compilers (and by implication their authors) being lazy, personally I respond better to encouragement rather than to abuse, but we have been down that road before.

Paul, 'Lazy' relates to all Fortran compilers error reporting, with all other ones being much worse in finding errors, describing what the error is, and suggesting the cure. Perhaps this was done due to Fortran Standard Committee decisions to make this language operate like that. I wrote many times here that diagnostics has to be more verbose and user friendly. Even for me who used Fortran for 40 years the language of diagnostics is often unacceptable laconic and worse than it could be. It often just gives the hint and leaves more on humans to find the error while in reality could tell exactly what the error is, or at least narrow the guessing job substantially. Probably i should be mentioning more that i already see in FTN95 the changes in the areas of wording in diagnostics messages and in what is diagnosed, so that this discussion would be understood as more general than specific to FTN95. I well understand that any diagnostics (and FTN95 finds several times more problems than other compilers) is way better than no diagnostics at all. Even just the pattern *** with no diagnostics message at all, or something in Chinese, is better than no diagnostics. Here is how many common errors find other compilers for example

FTN95 49 PGI 15 Absoft 18 Gfortran 26 Intel 28

Can anyone imagine me with PGI compiler? 😃 With it i'd be dancing every time my black cat meowed with the hint when i'm on the page with the bug i could not find

And i wrote that what is missing is way smaller than what's already done: would be good to add more user friendly layer of explanation of diagnostics (say, with suggestions what could be typically wrong) and to add more deeper scanning of source texts to make error reports less general and more specific. Both are just the additions to what's already exist, so no reason for taking this thread way too personal. My productivity due to larger and larger GUI and larger main source code slowly and steadily approaching zero. We've all heard of this trend as a function of size. This is because of too many options to suspect for the possible reason of the bug. Without more and more sophisticated and targeted computer diagnostics i soon will be unable to find any bugs.

Paul,

Thanks for the reference to /CHECK_WINIO. I have been making many modifications to my code, and this has found a number of errors (typos, mostly), but also some other problems that my old eyes did not catch when typing.

It would appear that when a single error is detected using this option, the compiler immediately exits versus what I would have expected; namely to continue the compilation of the file to the end. I have /NO_QUIT turned on.

Bill

The following code with /CHECK_WINIO causes the compiler to crash. I simplified it enough to duplicate the crash that I see with my full code. It is the '%tc%ty&' line that causes the crash.

	use mswin
	integer*4,parameter::WM_MOUSEWHEEL=z'020a',max_colors=5
   
    	integer,external:: keystroke,pm_handler,process_mouse_wheel,close_full_screen
        integer:: mmc,mmr,k,tc_color(5),ty_color(5),window_handle,window_closure,i
        character*32 screen_data(20),screen_attr(20)
	K = WINIO@('%*.*^tx[USE_TABS,FULL_CHAR_INPUT,NO_POPUP_MENU]&',MMC,MMR,SCREEN_DATA,SCREEN_ATTR,MMC,MMR,KEYSTROKE)	!,FULL_MOUSE_INPUT
	k = winio@('%pm[Copy]&',pm_handler)
	k = winio@('%pm[Cut]&',pm_handler)
	k = winio@('%pm[Paste]&',pm_handler)
	k = winio@('%pm[|,Edit Clipboard]&',pm_handler)

	k = winio@('%mg&',wm_mousewheel,process_mouse_wheel) ! --- LINK THE MOUSE WHEEL INTO THE WINDOW
	DO I=1,MAX_COLORS
	  K = WINIO@('%tc%ty&',TC_COLOR(I),TY_COLOR(I)) ! SOMETHING EHRE MAKES IT CRASH
	END DO
	K = WINIO@('%hw&',WINDOW_HANDLE)	    ! GET THE WINDOW HANDLE FOR THIS WINDOW
	k = winio@('%cc&',CLOSE_FULL_SCREEN)
	K = WINIO@('%lw',WINDOW_CLOSURE)	! leave the window open with this handle linked
	end

Bill

Thank you for the feedback.

Unfortunately there is no alternative to exiting after a winio@ error report at compile time. It is a situation where the compiler can't easily recover and progress. However, I will take another look and check this.

Quoted from PaulLaidler In case anyone has missed it, there is a relatively new FTN95 compiler option /CHECK_WINIO

I can find from neither the command FTN95 /help nor the file FTN95.CHM any information regarding /CHECK_WINIO with versions 8.5-8.51, although you have described that option in this and other forum posts. Perhaps both can be fixed for the next release?

Thanks.

Paul, I can understand why it would be a 'one and done'. I appreciate you taking another look.

Also as feedback, the specific identification of the variable (or % command) in error is very helpful. Makes up for the multiple compiles it took to find all of the typos in the code!!

Bill

Thanks for the feedback. I will take a look at the documentation.