Same but no crash please

I see the progress that now much more useful info is provided during the errors. Like here for example. Text points with human readable text what caused the bug, where to look precisely. And not just with the HEX gibberish for the artificial intelligence or for the only person in the entire world - mecej4 - who will never touch Clearwin at least for the next 10 years.

Great. But how about the same text but no following it crash? Like with OpenGL, it never crashes despite ultimate unimaginable torturing of millions of people (lot of games are written in OpenGL). Loading this variant to reach this error again for example will take me 30 minutes. Elon Mask would not take such software on Mars 😃 and any gamer refuse to use it for the second time after crash.

Was it possible to check the problem before the execution for example? I suspect LOG with negative argument was involved

Dan

We have already discussed this issue in some detail.

I return to these issues again and again because i kind of wondering why we still have crashes? Now much less often, but still...

OK, suppose something was wrong in data or anywhere else in the %PL. User have to get amicable message on his graphics screen about this problem, and black empty screen with no plot - that's it. He will continuing his run and plot 1000 other graphs. May be he will change too harsh smoothing or something else and try to plot same graph again.

I use calls to draw_line_between(ix1,iy1,ix2,iy2, icolor) in my plotting routines made with FTN95 graphics library. They work extremely nicely and very fast - this is why i never used third party software. There are very many screens like that in this code. A lot of data is plotted. And the last crash i remember was many years ago because integer overflow in these ix1,iy1,ix2,iy2 but checking numbers before converting real numbers to integer ix,iy fixed that forever.

I can not see latest builds where you have mentioned that something was fixed, but hope that with time we will completely eliminate these unnecessary crashes as the way of debugging of Clearwin like with Fortran itself - i mean by crashing. I do not remember you have mentioned anywhere that there even exist such design goal. Again thanks that there now exist the change in %PL to linear scale from crashing LOG, great, but seems in the example above this was not enough

Is this how you developers prefer to debug problems in your software? If so that's fine, but how about making two compilation options: detailed error report in Clearwin with all the binary data with possible crashes like today for developers and guys like mecej4 AND the option for regular users with similar or lesser reporting but avoiding crashes as much as possible ? Doable? Software possibly could be a bit slower sometimes but i doubt anyone will notice and it is easy to recompile. Crashing though will pull new users from Clearwin.

P.S. In one of my older codes there exist some unknown problem which crashes the property sheet for 10-15 years. It generates similar bug report when it aborts. Over years I published it here several times and even mecej4 was not able to suggest a clue.

In one of my older codes there exist some unknown problem which crashes the property sheet for 10-15 years. It generates similar bug report when it aborts. Over years I published it here several times and even mecej4 was not able to suggest a clue.

Dan, you have over 2,000 posts, so it would help if you provided a specific link.

One thread that seems relevant is http://forums.silverfrost.com/viewtopic.php?p=27221 . I reduced one of your problematic codes, which was over 3,000 lines and needed to read a 80+ megabyte data file, to a shorter test program of about 300 lines that needed no data files. Paul responded subsequently, and explained what was wrong with your usage of local variables as arguments that were passed to Clearwin64.

You responded, saying on 15 July 2019, 'OK this case seems is closed. ' and 'So now thing does not crash and works in demo but devilry does not go off easily. I still have problem with the same functionality in my larger code'.

It was implicitly understood at that point that you were going to apply the lessons learned from the 300 line code to your production code. Are you now claiming that you implemented the corrections but they failed? If so, note that the 3000 line code may have had, say, n bugs, and the 300 line version had only 1. The corrected version may still have n-1 bugs left over. It is even possible that the correction process introduced new bugs!

Mecej4 No, this is different bug. I tried to reduce it to short demo couple times but failed. With this demo happened couple 'devilry' stories. First, this bug was not reproducible when JohnSilver tried my demo (!). And then crash disappeared from this demo when i myself tried it few years later(!!). The main code still crashes. But it does not crash if i run it via debugger no matter how it was compiled, even with /nocheck (!!!). The only way to see the bug is to take the entire code and experience it in its glory. Crash takes place in two clicks: you click to open property sheet and you click to close it - crash!

The one you have mentioned though i fixed after discussion here but then semi-broke again (means it not perfectly works though it does not crash) because seems not completely understood what was wrong (that was anti-intuitive bug to me: i changed that damn local variable to make it global and it still corrupts the plot) and now after few fails have no time to look again what's wrong. So when i use it, it works this way: it fails without crash when i change anything in %pl plot setting (during this change callback is automatically reloads the plot which causes the graphics field to wipe out), i close and reload the plot (the failing plot does not corrupt or crash the entire code) and it works. But the other similar design subroutine works OK. Small demo i made back then worked OK too. So....hopefully i will find time to get this one back when become too annoyed by inconvenience

Dan, What constitutes a crash is different from different perspectives. From the perspective of a programmer like yourself, it is an unexpected termination of a program, and under Windows, that is not supposed to happen. However, from the viewpoint of the compiler (or its author), detecting an error poses a problem of what to do about it. The response of producing an error report and terminating gracefully (i.e. without corrupting the operating system or even halting the computer) is a very standard one. It was, in fact, the common response of a Fortran programmer in the old days to an error in data input. I think that your point is that a Windows program shouldn’t just throw its toys out of the pram and quit. If you were right that your %pl problem is the result of feeding a negative number to a log function, then I’m afraid that it is the high-level programmer’s responsibility to check – and to take the appropriate steps in advance. That goes for a lot of the devilry you report. Having said that, what I think that you are asking for is analogous to what happens with OPEN and READ as part of standard Fortran. With OPEN, there is the IOSTAT= value. If anything goes wrong, IOSTAT is returned and the code to deal with it is then the high level programmer’s responsibility – but the program does not exit, it continues. Similarly, with READ, there are the END= and ERR= options. Again, the program does not exit, even though there is a fault, and the high-level programmer can deal with it. I suspect what you are asking for is that an error in a native simpleplot should result not in a program exit, but some sort of return code, preferably an informative one. Personally, I think that would be a wonderful and really useful facility, and one that Paul could reasonably be asked to investigate. An alternative might be some exploration of the things that the graph plotting utility cannot cope with in the documentation, although it shouldn’t really require documentation to tell us that you can’t expect a negative number to be plotted on a logarithmic scale. Eddie

Eddie, Yes, this was really excellent analogy with read and write. If you called plot, property sheet, new window doing something etc and within this functional block some control fail, and this will cause chain reaction of other controls fail, ideally the safety mechanism should allow you to land to the state prior to calling plot or property sheet. As a first step the safety should ask user to ignore the fail of control and continue, then go to user defined safety exit path and only as last resort allow potential crash

Imagine all the people woke up and found there is no error handling ERR=..., END=... from READ and WRITE. They start getting crashes every time something is wrong with READ/WRITE.

People would revolt.

Mecej4 would be the only customer

ERR=, etc., were not present in Fortran 66. They were added in Fortran 77. It is probably difficult to incite a revolt whose purpose is to change the past to the present.

My understanding is that when Clearwin+ %PL generates an exception report, as well as 'QUIT', an option of 'SKIP' or 'RETURN' would be preferable, so the interactive menu based package could retain control to modify the data and try again.

I presume the SKIP option to terminate the %PL display, provide a blank plot or a plot replaced by a message then return, would involve more work to support, but this action is generally available in the Clearwin+ approach. I don't know what would be required to provide this functionality.

Maybe I have this wrong.

Then there will be the question regarding 'Invalid data value'. In my data analysis, there is always the question if a value is invalid or very significant.

There are 716 calls to the associated error function within the ClearWin+ library. A few recent additions have an option for the user to continue after the message is displayed otherwise the user's program is always terminated.

It would be a major task to provide an alternative mechanism; time that would otherwise be devoted to bug fixing or adding new features to FTN95 and ClearWin+.

Paul,

In what respect is adding a new feature to Clearwin+ not adding a new feature to Clearwin+? Just askin'.

It seems to me that the whole point of internal error handling within complicated procedures is to ultimately prevent unexpected exit from applications running under Windows, which is why I couched my reply to Dan with reference to OPEN and READ, where something outside the control of an application programmer can be managed. I also pointed out as delicately as I dared (lest it provoke a visit from a priest carrying bell, book and candle) that to do something that you know will cause an error is within the application programmer's responsibility - like specifying the input of a negative number to a LOG function.

Mecej4,

It is probably difficult to incite a revolt whose purpose is to change the past to the present.

I don't think that Dan was inciting anyone, rather telling us the likely result of not so much changing the past to the present, but of making the present re vert to the past.

You need to watch it: devilry is afoot down under - I have watched several episodes of 'Wellington Paranormal'. It may affect your Fortran in bizarre ways!

Eddie

[/b]

Eddie

OK I take your point, changing the error handling mechanism could be considered as a new feature. Never-the-less, how resources are optimally deployed is still a matter of judgement.

I don't want to enter into this discussion but as an aside, consider the READ/WRITE error 'Format/data miss-match'. Code has just now been added to the IO library to make this report more detailed... e.g. 'F-Format/LOGICAL data miss match (item 3)'. You can't do this with an IOSTAT value. You must use IOMSG or raise an exception.

It would be quite easy to extend the ClearWin+ error function so that it (say) optionally put the messages in an error output window. The time consuming part arises when the error messages are not generated at the top level. In each case it would be necessary to work out if continuation is possible and then add code to work back up the levels to the user call.

Paul wrote: 'You can't do this with an IOSTAT value. You must use IOMSG or raise an exception.'

The Fortran standard specifies that the value of the status variable specified with IOMSG= is to be set/changed only if an I/O error, EOF or EOR occurs.

The implication is that the programmer may need to specify IOSTAT= and test for one of those conditions (or ensure having reached a statement number specified with END=, ERR=, EOR=) before examining the flag variable specified with IOMSG=. Alternatively, the programmer could set ccc='???' before using IOMSG=ccc in an I/O statement and then testing for ccc == '???'.

Perhaps the governing rules for PLSTAT and PLMSG should maintain similar constraints.

My understanding of the problem is more the need to retain control if %PL experiences 'invalid data'. I have a menu based %gr display, which involves considerable computation with multiple displays, so would not like %gr to crash, without giving me the opportunity to interrogate the data via other menu options. So I understand what Dan might be requesting.

However, if for example, invalid data is due to an array that is not allocated or having been released from the stack, this is a coding error and not a data error. This can occur if the %PL arguments are local arrays that can go out of scope. Not sure what the requirement is here.

An alternative is to provide code to check the data before reaching %PL, although referencing an array that is no longer defined would still fail. Perhaps providing some basic checks on entry to %PL could be more easily recovered. If these fail, providing a report in the %PL window then returning might be better, although the degree of checking is always a challenge.