replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Not Clear diagnostics
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, 6, 7, 8  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2923
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: 8210
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 AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1899

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: 2923
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
mecej4



Joined: 31 Oct 2006
Posts: 1899

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
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8210
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 AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1899

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

John-Silver wrote:

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



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

PostPosted: Fri Jul 12, 2019 9:18 am    Post subject: Re: Reply with quote

mecej4 wrote:
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 !


Last edited by DanRRight on Sun Jul 14, 2019 6:12 pm; edited 2 times in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1899

PostPosted: Fri Jul 12, 2019 10:25 am    Post subject: Reply with quote

Dan, I have sent a PM to you with a suggestion.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Jul 15, 2019 9:10 am    Post subject: Reply with quote

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



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

PostPosted: Wed Jul 17, 2019 5:31 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
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 like this addition you have made working on crashing case from another thread introducing the option not to crash GUI, specifically %pl. And even more specifically like the pre-screening of input data which informs the user what could be potentially wrong (for example "Data corrupted in array variable #3, element #3233" etc.). This choice of continuing seems is great for both worlds: it allows to ignore execution of %xx control and avoid the crash with that (and potentially find the reason), OR to continue and have a crash of entire code (which usually has nothing wrong) for those who can read access violation binary gibberish and detect the error in Clearwin by that. Probably there were only couple people in 30 years who in 1% cases have succeeded to decipher such diagnostics. All these few cases were not with Clearwin for sure Smile

If anyone disagree and still likes to see for more 30 years such useless crash screens like below let's do the test: can you tell me what's the error i made (or is this the bug?) which crashes my program for last 10 years in property sheet %ps ? Good 10 years old whiskey is yours

Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Jul 17, 2019 9:35 pm    Post subject: Reply with quote

Dan

You exaggerate again! 64 bit FTN95 was first released in 2016.

What does this trace back look like for a 32 bit executable built using /DEBUG or better /UNDEF? Have you tried running the 32 bit version via SDBG?
Back to top
View user's profile Send private message AIM Address
DanRRight



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

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

I do not exaggerate a tiny bit, this first started long ago and the code crash in both 32 and 64 cases. Of course i ran it with all possible switches. Does not crash only if i launch this code via debugger (even if compile with /nocheck). This and fixed two days ago crash of graphics were (and this one still current) are my major problems with Clearwin.

Last edited by DanRRight on Thu Jul 18, 2019 11:10 am; edited 2 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Jul 23, 2019 12:59 am    Post subject: Reply with quote

I had bad luck with READ/WRITE in Fortran all my life. This is 100x worse than Clearwin+ which eventually is fun. Here is one more example of unacceptably bad elitist diagnostics typical for Fortran, not just FTN95. I've spent one more swearing hour to find what's wrong plus then some time scaling complex read statement which abruptly started to hiccup. Here is complete demo.

Code:

Read(1,'(i3, E10.3)') i, A(i)
end

And here is diagnostics which would cause anyone to hate Fortran.
Pure devilry, it worked today OK. I had to stop today.
Code:
0001) Read(1,'(i3, E10.3)') i, A(i)
*** Non-writable expression in READ statement
*** Compilation abandoned



Bet that the person who have done that hated and did not use Fortran, was lazy or was a total snob. Could it be that this was the same person who wrote FTN90 ? Smile))

And also lazy users...is a PITA. Not so many really active people FTN95 has. I propose to introduce system of ratings. The higher score people get the more priority they obtain in fixing found bugs. Such ratings have many other forums. May be this will stimulate people to report problems and suggest improvements.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Jul 23, 2019 9:46 pm    Post subject: Reply with quote

C'mon guys, please try to guess what the heck is this error. I tried to spend 15 minutes on it and already 1 day passed. At least please confirm that you get the same cryptic error and my compiler or computer is not corrupted. 20 lines before this place in my code similar READ works ;(
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, 6, 7, 8  Next
Page 3 of 8

 
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