forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Not Clear diagnostics
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 604
Location: Morrison, CO, USA

PostPosted: Tue Jul 09, 2019 2:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6001
Location: Salford, UK

PostPosted: Tue Jul 09, 2019 3:22 pm    Post subject: Reply with quote

Bill

Are you saying that /CHECK_WINIO does not fault this?
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 604
Location: Morrison, CO, USA

PostPosted: Tue Jul 09, 2019 8:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2026
Location: South Pole, Antarctica

PostPosted: Wed Jul 10, 2019 3:49 am    Post subject: Reply with quote

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
Code:

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 Wink.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6001
Location: Salford, UK

PostPosted: Wed Jul 10, 2019 8:10 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2026
Location: South Pole, Antarctica

PostPosted: Wed Jul 10, 2019 8:40 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6001
Location: Salford, UK

PostPosted: Wed Jul 10, 2019 9:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2026
Location: South Pole, Antarctica

PostPosted: Wed Jul 10, 2019 10:26 am    Post subject: Re: Reply with quote

PaulLaidler wrote:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6001
Location: Salford, UK

PostPosted: Wed Jul 10, 2019 1:03 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1179

PostPosted: Wed Jul 10, 2019 1:47 pm    Post subject: Re: Reply with quote

DanRRight wrote:

Code:

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:

Code:
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".
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2026
Location: South Pole, Antarctica

PostPosted: Wed Jul 10, 2019 3:42 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1176
Location: Aerospace Valley

PostPosted: Thu Jul 11, 2019 10:15 am    Post subject: Reply with quote

Paul wrote:
Quote:
So to ask that there be no "crashes" is to ask for the moon


.... so we can rule out the legacy of 50 years - 9 days then and not expect hear 'that's one small step for the developer, one giant leap for userkind' Wink

Seriously though, as I see it is that what's needed is a simple Pre-checker, not a modification of existing checking code.

A 'pre-checker's aim would be to first pass through the code looking only at the winio statements, its variables and checking against type definitions, just like you say /CHECK_WINIO, but it wouldn't maybe have the same limitations as /CHECK_WINIO.

Trying to integrate too closely (initially, or even ever) with the compiler overall activity is running before you can walk imo.

With the speed of hurdy-gurdy's these days doing the pre-checking first folloežwed by the normal checks dutin compile would have negligible overhead.

mecej4, as for
Quote:
the bumblebee does not know aerodynamics".

... how do we know ? quite a few could maybe easily get top jobs at Boeing or Airbus :O)
I never heard of a bumblebee flying into the ground after holding back on a rapid ascent Smile
In fact bumblebees could undoubtedly be invaluable additions to AAI teams Smile
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1179

PostPosted: Thu Jul 11, 2019 11:18 am    Post subject: Reply with quote

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 http://forums.silverfrost.com/viewtopic.php?t=3753 ) 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".
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1176
Location: Aerospace Valley

PostPosted: Thu Jul 11, 2019 12:42 pm    Post subject: Reply with quote

m3cej4 .... a fqir analysis .... I guess the question your asking everyone to reply to is' is 'how long is your piece of string ?'

However your ...
Quote:
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".


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.

So there seems to be scope for a more comprehensivive pre-checker, even though I'm sure Paul has plans for enhancing CHECK_WINIO i does seem there are restrictions on what can be achieved.

As for the question regarding 'more complicated' expressions in the 'high level WINIO sub-language, surely it's a standard parsing problem just to pick out the variables from the expressions and then make sure all in a particular expression are compatible with the particular 'format' format
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6001
Location: Salford, UK

PostPosted: Thu Jul 11, 2019 1:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group