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
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Jul 05, 2019 3:53 am    Post subject: Re: Reply with quote

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



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

PostPosted: Fri Jul 05, 2019 4:59 am    Post subject: Re: Reply with quote

mecej4 wrote:

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 Smile . 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 Smile 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.


Last edited by DanRRight on Sun Jul 07, 2019 3:07 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Jul 05, 2019 7:31 am    Post subject: Reply with quote

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



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

PostPosted: Fri Jul 05, 2019 8:48 am    Post subject: Reply with quote

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



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

PostPosted: Fri Jul 05, 2019 2:42 pm    Post subject: Reply with quote

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



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

PostPosted: Fri Jul 05, 2019 3:01 pm    Post subject: Reply with quote

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

   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

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


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

PostPosted: Fri Jul 05, 2019 5:45 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Jul 05, 2019 6:02 pm    Post subject: Re: Reply with quote

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



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

PostPosted: Fri Jul 05, 2019 10:16 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Jul 06, 2019 8:14 am    Post subject: Reply with quote

Thanks for the feedback. I will take a look at the documentation.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Sat Jul 06, 2019 9:41 am    Post subject: Reply with quote

Bill

The crash with %ty has now been fixed for the next release of the DLLs.
Back to top
View user's profile Send private message AIM Address
wahorger



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

PostPosted: Sun Jul 07, 2019 1:44 am    Post subject: Reply with quote

Thanks, Paul!!
Back to top
View user's profile Send private message Visit poster's website
John-Silver



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

PostPosted: Tue Jul 09, 2019 7:50 am    Post subject: Reply with quote

/CHECK_WINIO - the Existing Documentation

According to the Revision History , which we should all read more often than we do:-

It seems a facility was initially introduced with v8.1:
Quote:

64-bit /CHECK includes a compile time check on winio@ arguments - that they have the correct type. Initially this feature is only available with /64 /CHECK.


and then in v8.4 was introduced :

Quote:
/CHECK_WINIO option to specifically check WINIO@ commands


The questions remain:

- what does this checking include, still just the arguments check or something more sofiscėticated ?

- is it still limited to 64 bit or is it also 32 bit ?


Delving into .enh file for v8.4 release then clarifies on the second query above:-

Quote:
316] In the previous release of 64 bit FTN95, the checking options (/CHECK) included the compile time checking of the type of all WINIO@ arguments. Otherwise the type of these arguments is not checked until runtime.
This part of 64 bit /CHECK has now been removed and replaced by a separate FTN95 command line option /CHECK_WINIO.
/CHECK_WINIO is provided for both 32 bit and 64 bit FTN95 and is now independent of /CHECK.



So just leaving the trivial :O) task of documentation of what it actually checks.
_________________
''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
John-Silver



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

PostPosted: Tue Jul 09, 2019 8:14 am    Post subject: Reply with quote

Last week (3rd July) Dan you wrote:-
Quote:
Quantum mechanics theory for example was found by simple random try process to find the mathematical formulas which fit the experiment.

Hence revealing the approximate nature of QM theory ! since experimental data. lest we foret, is not exact.

Quote:
We completely lost understanding of things at this moment, we can only find appropriate mathematics which fits the life.

Like 8x7 = 42 ? Wink (squeak)

Quote:
That what now is called "understanding".

if there's an enhanced understanding is it correct to call it overstanding ?

Quote:
Robots will be able to do this even better.

... provided the human(s) which program them know how to do it better.
Robots can only do things faster, not better.
Human's can programme robotically but rely on trial and error to iron out the bugs.
Like ..... self-driving cars .... I mean would YOU let a car take over with the risk of it piling head on ino the lorry(truck) coming the other way ?
Or dare I say it, the 737 MAX. I'd love to see a transcript of the minutes of some of the meetings leading up to the introduction of that self-correcting anti-stall system, I really would.

Quote:
Not even mentioning again the solution of complex things we are barely capable of on very simplified models.

That's because 'breakthroughs', even simple ones, require not just a dash of genius but a LOT of hard work behind it. A cioncept which is imo sadly lacking for many years.

Quote:
That all means end of humans

... and hence by definition the end of all robots ! Catch 22 n all that.
_________________
''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: 7916
Location: Salford, UK

PostPosted: Tue Jul 09, 2019 9:53 am    Post subject: Reply with quote

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