Not Clear diagnostics

Bill

The crash with %ty has now been fixed for the next release of the DLLs.

Thanks, Paul!!

/CHECK_WINIO checks the type of the arguments against what is expected for the corresponding format codes. It also checks that the number of arguments is correct.

This checking process is, of necessity, less comprehensive than that which is carried out at runtime.

This is a relatively new and experimental feature so false error reports and the occasional crash may occur. Please report these for fixing.

/CHECK_WINIO is unlikely to work with code containing complicated winio@ constructions that use DO loops or IF constructs.

Paul,

I'm not sure this qualifies for 'fixing', but I did have the occurrence where the argument should have been an external, but was actually a variable. I swapped the two when I typed the argument list. Of course, caught at run-time.

Don't know whether or not that feature could be added.

Just a thought. Bill

Bill

Are you saying that /CHECK_WINIO does not fault this?

That was my experience. But when I just tried to re-create it in a small example, I could not. I'll try to experiment with more complex examples (i.e. several controls defined in a single winio@() call).

Sorry if this was a red herring.

I encourage all to try /CHECK_WINIO for faster rate of its bug fixes and improvement of functionality. Right now compiling with /CHECK_WINIO crashes a half of my files but because the large amount subroutines in each compiled file extracting of offensive part would be a hell.

As to functionality i'd still like for /CHECK_WINIO to complain about error with this simplest code compiled FTN95 aaa.f95 /link /check_winio

i=winio@('%rb[]&',ir)
i=winio@(' %rd',ir)
end

as it swallowed undefined variable and clearly malfunctioning showing radiobutton ON. With the same compilation but added /64 it behaves differently. I have seen before that undefined variable in %rd or %rb can crash the property sheet %ps. I still have crashing %ps in /64 and can not find crash source for years. The only way how i use this %ps is to run the code via debugger. Even if the code is compiled with /nocheck the run via debugger makes %ps to work. Run of code with /nocheck via debugger does not slow down the code speed. Poor man hack 😉.

It is true that ClearWin+ does not check for the use of undefined values and I guess that in some contexts it could. Using /UNDEF may catch most of these errors independently of ClearWin+.

Maybe if someone wants to provide a list of cases that could be tested then this task could be added to the 'todo' list.

This reminds me that there is no perfect programming environment and the developer's work is never ending - the goal post are always moving.

One thing that I have in mind is to get ClearWin+ to write Fortran (winio@) code for you for simple dialogs. This is not as far-fetched as it sounds. Visual ClearWin+ already allows you to interactively design a dialog with the data going into a .rcx resource file. The next step would be to automatically convert this into Fortran code.

Having said this, there does not seem to have been much interest in Visual ClearWin+ presumably because there is an associated learning curve and users rarely need to work from scratch in this way. So I am not convinced that it this kind of development would be of interest.

The problem is that /undef does not catch uninitialized variables with Clearwin. CWP just does eat them for breakfast. And after that sometimes hiccups no one knows where. With this text above: FTN95 aaa.f95 /link /check_winio /undef all looks rosy, but...

As to the acceptance rate - there is no barely used software, there is little advertisement. CWP needs more bright examples.

There is no connection between /UNDEF (which causes FTN95 to plant checking code into your object files) and ClearWin+ which is in an external DLL. But ClearWin+ could possibly check for undefined values at runtime in certain contexts.

p.s. But you would need to use /UNDEF in order to plant the 'undef' values in your code then ClearWin+ could look for these values if it had a mind to.

Quoted from PaulLaidler But ClearWin+ could possibly check for undefined values at runtime in certain contexts.

This is what i wanted in CWP to see. At the end checking for undefined variables is one of the greatest debugging feature. The fact it is in different DLL is a minor obstacle if this is your own software

Another what'is missing in CWP is: GUI should never crash: it has always try explaining first what's wrong (as much as reasonably possible) and then giving user some options. Same like you have done that couple weeks ago with my crashing or malfunctioning %pl and simpleplot_update@. When %pl gets the supplied data and considers it bad it tells in pop up window which data is wrong, and even exactly which element of data is bad, and after that gives the option not to proceed or proceed at your own risk

As I have explained before, there are many points in the ClearWin+ library where there is no escape. The logic demands a certain outcome and there is no way to back track. Sometimes this is down to the way the original code was written but often there is no escape anyway. So to ask that there be no 'crashes' is to ask for the moon.

Sometimes a change can easily be made to allow continuation and I aim to make these changes when they become apparent.

Quoted from DanRRight

i=winio@('%rb[]&',ir)
i=winio@(' %rd',ir)
end

Dan, there are several reasons why what you ask for is not only difficult, but may well be impossible. As they say in the army, 'The difficult we do immediately; the impossible takes a little longer', so please be patient.

Here are two impediments to better checking:

1. It seems impossible to write Fortran interfaces to routines such as winio@. The first call has INTENT(IN) for the second argument, whereas the second call has INTENT(IN OUT) for IR. Thus, the INTENT of the second argument (the integer) changes depending on the contents of the first (string) argument. In clearwin.ins, we can see only the attributes EXTERNAL and INTEGER*4 for WINIO@ -- nothing about types of arguments, intents, etc.

2. As far as I can tell, the FTN95 compiler does not have the capability to perform data flow analysis. Consequently, the following program does not cause the compiler to tell you that IR has not been defined before being passed as an INTENT(IN) argument in a function call. I know of no Fortran compiler on Windows or Linux that can tell at compile time that the following program is in error because IR is undefined when the function is invoked:

program danx
implicit none
integer :: ir,i
interface
  integer function winiox(str,ictl)
  implicit none
  character(len=*),intent(in) :: str
  integer, intent(in) :: ictl
  end function
end interface
i=winiox('%rb[]&',ir)
print *,i
end

If the capability existed to check actual procedure arguments for definition consistency with intent, that would be fantastic; that capability could be applied to all subroutine, function and procedure invocations to everyone's benefit, not just to WINIO@ calls. But, as I said above, 'it takes a little longer'.

I suspect that Dan will reply a la 'According to the laws of aerodynamics, there is no way that a bumblebee should be able to fly. Fortunately, the bumblebee does not know aerodynamics'.

We users do not know how exactly Clearwin is made, what are its interfaces and how it treats winio@ input and output data. Why we should guess how to make things do not work? This black box somehow gets the data and somehow outputing it. And here are the developers themselves who do know all in detail.

The demand is very simple and reasonable, completely logical, and even more -- it is in style and word of what FTN95 is most strong and famous for, and hence potentially very beneficial: it is about implementing Checkmate or /undef for Clearwin+. Why this is important? Because it is hard to make GUI and because when you finally succeed and make it very complex, it might give you no info why it may become unstable crashing all further efforts. Question to developers is : is it impossible by some programming reason as a first step inside Clearwin+ to check all input data of all its functions (all these %rb, %rd, %rf, %pl, etc) for the pattern which is defined by Silverfrost as 'undefined variable' ? And as a second step tell user in popup window that this is indeed undefined variable? If user compiled code with /undef he reasonably expects that Clearwin+ also reveals undefined variables, not hides them by keeping mum and sometimes crashing.

Comment about crashes. If user supplies negative number to LOG function he will get the program crashing. This is because nobody cared about checking input data, all Fortran cares about is just the speed. With any GUI builder though this old Fortran school approach with its crashes on any step aside is exactly what can be and has to be avoided because speed is not a factor. GUI speed is 0.1 second - which is latency of a human-computer reaction. Computer can check variables for consistency 10 million times during these 0.1 seconds.

John S., there are some good ideas in what you wrote, but there is no escaping the main problem: the control strings in WINIO calls form a separate programming language that is mostly incompatible with Fortran.

A simple static pre-checker will only catch a few simple errors. If it can be implemented with little effort and may satisfy most users, it should be encouraged. However, let us recognise the pitfalls in advance:

1. For WINIO arguments that are INTENT(IN), checking is best done just before the WINIO call. For arguments that are scalar variables, this may be doable. However, what should we do if, instead of

   i=winio@('%rb[]&',ir)

the user's code contains

 i=winio@('%rb[]&',2*ir1+3*ir2) 

or a more complicated scalar valued expression instead of a scalar variable? Do we forbid the use of expressions as arguments to WINIO calls?

2. For WINIO arguments that are in/out, we can expand the preceding to checking that the variable is (a) defined as well as definable before the call, and (b) defined/redefined immediately after the call returns. A user who writes such a call but has no further use for the redefined value, however, may object to the requirement (b).

3. Static code analysis can only catch a subset of errors. Run time checks can be expensive (for an extreme example, see https://forums.silverfrost.com/Forum/Topic/3340 ) as well as inconclusive (not finding errors in a few runs does not imply that no errors are possible).

Let us also back up a little. Those of you who are heavy users of CLEARWIN (Dan, you are the spearhead), please give us an idea of the magnitude of the problem. For example, 'My code is 20,000 lines of code, takes 3.5 hours to run on an i3-8100, contains 25 distinct WINIO calls which get executed 2.3 million times during the run, and has crashed during 7 of those WINIO calls. Of those 7 calls, 2 contained errors that could have been detected using /CHECK_WINIO or other static analysis'.

I apologise if I have given the impression that there are plans to extend CHECK_WINIO. This feature is new but at the same time complete. It goes as far as intended at its conception.

The plan was to move the checking (of winio@ argument types with respect to the corresponding format codes) from runtime to compile time. This was a nice idea but turned out to be only partly feasible.

I am interested to receive feedback about cases where CHECK_WINIO goes wrong but only for simple linear sequences of call to winio@. For example, not when the calls are embedded within IF or DO constructs.

Quoted from John-Silver

... So, we're seeing that CHECK_WINIO, in your case, only snagged approx 30% of the errors (assuming there are only 7 errors creating the 7 crashes. ...

Sorry, no, those were completely made-up numbers. I am not even a ClearWin/Simpleplot user. I merely wanted to know the nature of the WINIO errors that Dan keeps running into.

I am interested in the topic of what to do after an error is detected; especially, what can be done for graceful recovery and continuation of the run after an error has been detected at run time.

Quoted from mecej4 I merely wanted to know the nature of the WINIO errors that Dan keeps running into.

The nature of CWP errors is simple as 2x2: not too many CWP users. Needs further polishing its user-friendliness. In my specific case when i have tens of thousand of $xx controls i get eventually one or two rare problems which do not appear with smaller GUIs. These couple hard to fix problems (when you with a lot of efforts eventually extract the demo just to find that the damn thing is not malfunctioning. You put it back and it fails again) start to annoy like a nail in the shoe. As a results i want to have more debugging capabilities and suggest some of them which appear from my fox hole as very easy, almost elementary to implement: adding check for undefined variables which is the best debugging tool. Let Clearwin when doing for example i=winio@('%rd', ir) checks variable ir to make sure it's not a 8080808080 (or whatever one which is defined as undefined variable). I am surprised to disbelief that whole my life advertising Silverfrost's /undef or Checkmate among hardly convinceable fortraneers i now need to convince to implement this in Clearwin ... Silverfrost itself !

Dan, I have sent a PM to you with a suggestion.

Some further comments on ClearWin+ 'crashes'...

Within the source code for the ClearWin+ library there are 645 places where a call is made to the function clearwin_error. These arise when an error is detected in the input data supplied by the user. clearwin_error could provide a polite and graceful report and then terminate the execution but instead it 'raises an exception'. The result appears to be 'in your face' but is used because it comes with a trace back that helps you to work out where your error occurred. Also, when /DEBUG is used, you should also get the related line numbers in your code.

So a 'crash' is this context is not caused by a fault in the library but is a mechanism for helping you to find bugs in your code.

In a few cases the call to clearwin_error has been modified to give you the choice of continuing. Other cases could be identified as time permits but, as a general rule, continuation is either not possible or not advisable.

I understand that some sat-navs give you the option of being sworn at when you make a wrong turn. ClearWin+ does not give you this option and appears to be rather ungracious in its response to your errors but there is a friendly reason for this rudeness.