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 

GUI should never crash by itself
Goto page 1, 2  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: 2124
Location: South Pole, Antarctica

PostPosted: Fri Sep 13, 2019 10:40 pm    Post subject: GUI should never crash by itself Reply with quote

Here is another example of my suggestion to make Clearwin and OpenGL crash only deliberately at the user request.

The get_opengl_mouse_state@ is crashing the 32 bit program (64bit is OK) with error message "No OpenGL buffers are open". Not open then not open who cares, why just not wait till it will be opened if it will be opened. It takes one pixel and just microseconds to wait till the next request will come. But no, get the crash into your face because the crash is what fortraneers always used for debugging, they don't know and don't want to know advanced tools

Meantime program should tell the user in the popup bubble about this problem. I can imagine the program on the satellite flying to stars crashing due to that minor reason and no one can restart the program or recompile.

Clearrwin and OpenGL are parts of GUI by definition involving interaction with the humans. Let's people decide to crash the external shell or not!
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Sep 14, 2019 8:09 am    Post subject: Reply with quote

"Crash" implies a fault in ClearWin+ but this kind of failure is almost always due to a fault in the author's code.

As I have said a number of times before, when ClearWin+ encounters an programmer error, in most cases it has no choice but to terminate the execution.

Most errors of this kind are identified by careful testing during development and I guess that most users are happy to fix these errors one at a time during testing.

There are exceptional cases and this may be one of them but I don't know for sure.

There are over 600 error reports within ClearWin+ and (even if your request were endorsed by other users) it is not possible for us to comply.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2055
Location: Yateley, Hants, UK

PostPosted: Sat Sep 14, 2019 11:35 am    Post subject: Reply with quote

I agree with Paul, subject to the caveat that 'crash' means something different to the original programmer and the user, and so this is a question of semantics.

One can give multiple examples of the difference. For example a depressed lunatic flies a plane into an Alp. For the passengers, and the airline, it was definitely a crash, but for the aircraft manufacturer it was fully expected that the aircraft would obey the controls, even as it was giving audible warnings that the ground was becoming awfully near!

To extend this parable further, would you like it if CW+ took the initiative? Rather like the 737 Max's MCAS, that knows better than the pilot!

So, Dan, you program for Windows. Suppose you programmed for 'console'. If you wrote to a not preconnected file without OPENing it first, what would happen? What would you expect the system to do? I suspect that you might see a FORTRAN STOP message! If you expected the user to be asked for a filename, then it would be your responsibility to handle the ERR= part of the WRITE statement. No Fortran I know of would intervene and ask for a file name without that being programmed into the source code. I can't see that CW+ is significantly different, or that it should be.

On the other hand, I sympathise. Programming at the best of times is a frustrating experience. Doing it for a living probably causes insanity in the end. And if not insanity, then programming can certainly stimulate latent Tourrette's Syndrome.

Eddie
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sat Sep 14, 2019 10:40 pm    Post subject: Reply with quote

An Anecdote ...

Quote:
I can imagine the program on the satellite flying to stars crashing due to that minor reason


Indeed it could !
One close shave that I observed was saved in the Nicholas of tempus during software testing.

It was discovered an error in the calculation of relative inertias of the s/c in the 2 orthoganal directions, which would have made the craft uncontrolable had it not been uncovered and corrected.

What was uncvered was a '1' which had been typed in as '-1' !!! I jke not.

By this time the s/c was in advanced state of design/fabrication so a 'quick fix was neded.

After a number of ideas for a 'quick fix' had been put forward a mržeeting was held to decide which to plump for.

I heard that a solution was chosen and then ..... one of the younger engineers stood up and declared 'I'm glad you've chosen that one, because I did ' .... and he then proceded to give a presentation with a film of him testing ti out in his garage !

It consisted of 2 deployable booms qith counterweights at the end of each ..... which he'd re-created with ? ..... bags of sugar, and he's filmed their 'deployment' in his garage !!!

All because of a '-1'.
_________________
''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: 1232
Location: Aerospace Valley

PostPosted: Sat Sep 14, 2019 10:46 pm    Post subject: Reply with quote

Paul wrote:
Quote:
There are over 600 error reports within ClearWin+

... messages ... error messages, reports are much longer.

Is there a list of these messages anywhere within the documentation ?

Maybe with hints and tips attached for some of them to help any sun-tanned stranded devilry victims out in cyberspace ?

I don't think Dan was expecting the full library of messages to be suddenly and completely made 'crash-free' until D-time, which indeed would be a tall task.
_________________
''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: 1232
Location: Aerospace Valley

PostPosted: Sat Sep 14, 2019 10:52 pm    Post subject: Reply with quote

Quote:
"Crash" implies a fault in ClearWin+ but this kind of failure is almost always due to a fault in the author's code.

I'd disagree.
A 'crash' for me is just that the program unexpectedly stops.
A 'crash' doesn't imply for me a clear cut fault on either side until the cause is investigated and determined.

Only then could anyone decide who the onus of 'blame' (for want of a better word) falls upon.

Which make the statement you made Paul, espcžecially the 'almost always', look maybe a teeny bit ..... pompous (for want of a better word) from a user's perspective.

I'm sure it's not meant that way, but that's the way it can come across.
_________________
''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
DanRRight



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

PostPosted: Sun Sep 15, 2019 4:38 am    Post subject: Re: Reply with quote

PaulLaidler wrote:
"Crash" implies a fault in ClearWin+ but this kind of failure is almost always due to a fault in the author's code.
As I have said a number of times before, when ClearWin+ encounters an programmer error, in most cases it has no choice but to terminate the execution.


Paul, Eddie, John,

I have absolutely different experience. It does not matter if this is user error or fault if program crashes. Of course all is user fault. But all user situations is impossible to anticipate in advance. While in programming the openGL_buffers or %pl it is possible when crash situation is unavoidable to tell users if he wants to ignore that or be safe and do not proceed with the action.

What i am asking for is mostly happening in the following situations : I run for 3 days the program and permanently control how it goes opening different graphs and change the settings using Clearwin+ and OpenGL

In vast majority cases the crashes in CW+ are unnecessary and avoidable. Yes, the user will need to correct the problem after getting warning message (what i am asking for - give me the choice) about problem instead of always 99.9% crashing like today. User needs to try to continue the run even with the faulty GUI. Have you forgotten, Paul? You just made exactly what i am asking with the %pl when you tried to fix the crash of %pl with my example we discussed couple months ago. It is doing exactly what i asked for: if problem surfaced it gives user the chance
1) to cancel the run, ignore plotting of %pl or continue to run at your risk trying to plot the graph. If with some data plot crashes i would prefer not to plot it and try different data to plot. Often effing plot is not that important. But losing 3 days of run is hell important

Other cases i have seen are
2) Two captions %ca somehow may collide in complex GUI ( only one caption per window is allowed). Who cares about damn captions? Give the warning and either plot both or none, i will find that later. But instead they get you the crash

3) no openGl buffers are open like in the example above ? Who cares? Allow user to ignore that

4) no %gr was open while some function is trying to find window dimension ? Who cares. Give user the warning but allow user to continue at his own risk (and most probably nothing will happen, user will fix the error later)

5) undefined variable may happen, denormal or out of range number may happen and it will crash the GUI ? OK, i will fix that but why not to tell that and allow to ignore the number and ignore running this %rb, or %dd ? Sometime ("%il%rd", lowLim, highLim, ird) crashed the GUI because ird was set by the program below lowLim

n) and that may go on and on and on....about all the %controls about all problems in CW+ openGL-related stuff (not in the OpenGL itself, it is done by silently ignoring all the problems and never crash or report that) about all draw_characters@ or plot_line@. Let they fail, just leave the warning, that the number is undefined, or out of range, or whatever, but do not crash the GUI and with this damn GUI crash the main program!

Will repeat : the main program being bug-free as much as possible is important. But damn GUI is in vast majority cases just the third order importance visualization tool. Yes, it is good help, it is great in finding names of variables and places when you need to debug, it is amazing eye candy but it is still third order. Of course in some cases GUI error is not acceptable but let's user decide to crash 3 days of continuous running due to damn captions or openGL buffers just 5 minutes before the run completion or not. GUI must never crash.

Eddie, I prefer that if in airplane all pilots got drunk, all monitors got out of power or just the toilet handle broke ( the best metaphor for CW+) , the airplane still safely landed on autopilot. At the end in 99.99% cases Elon Mask car will safely reach the trip San Francisco-Los Angeles by itself. I am asking not about 99.99% but say 90% cases of GUI pro
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Sep 15, 2019 7:33 am    Post subject: Reply with quote

If you were to complain that FTN95 crashes then that means there is a fault in FTN95 that we must fix. FTN95 should never crash.

If you were to complain that FTN95 provides a fatal error report when it could soldier on then we can look into it but it is not a crash.

ClearWin+ should never crash but that is not what is being asked for, and other readers might get the impression that ClearWin+ is flaky when it is not.

So I ask, please be careful in your criticism if you want Silverfrost to do well in the market place.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sun Sep 15, 2019 8:25 am    Post subject: Reply with quote

You are might be right, this crashing wording should be named differently. The things we are discussing here is on another level behind the one what people may perceive with the word "crash" more associated with no reason BSODs of DOS and first Windows era Smile. In our case we are trying to discuss the improvement of programmer's life by changing the paradigm of error reporting. This is like to change the whole programming community approach to reaction in the code flow situation. I'd call it like introducing liberalism in code-to-human interaction. We are discussing here may be a bit too heated way the things others even do not have in the plans, like trying to improve the airplane while they are still living in neanderthal era.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2055
Location: Yateley, Hants, UK

PostPosted: Sun Sep 15, 2019 3:57 pm    Post subject: Reply with quote

To be fair to Dan, suppose that his program fails to execute as intended because of an error he made that wasn't detected at compile time, but could have been, then should that be something worth rectifying or developing a solution to at SF?

My own feeling is that I am happy in the knowledge that CW+ is not tested for any but the most basic errors at compile time, and that the full development process requires 'live' testing. It probably says as much somewhere in the documentation, although my cursory examination of the start of the ClearWin+ section of FTN95.CHM didn't give me much guidance, although I did note
Quote:
This DLL will only run on a Win32 platform.
which perhaps is incomplete guidance.

I note Paul's recent announcements that go partway to providing a compile-time check on CW+ syntax, and that is a very positive step that needs to be encouraged.

Personally, I find that WINIO@ statements are best with few format codes, as otherwise they can get very confusing, and I think that testing routines before they are incorporated in large programs is a good idea.

Eddie
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Sep 16, 2019 3:44 am    Post subject: Reply with quote

To make Clearwin to sell i suggest to SF to create say 52 and then 365 small flashy programs with photos and post them every week and then every day. May be to send them in the email like a tip of the day. Every day i open my programs in Clearwin i enjoy them very much. Then i realize that no one else have even a clue how their program could be enjoyable with this tiny addition to Fortran. Decently i am shocked all my life that neither Salford or Silverfrost ever pushed all that to the market. I asked such question here many times and my last answer was that developers do not know themselves what they created because they do not use Fortran, they use C Smile

Or, may be indeed i live in a matrix and in the city called Major Devil where all has no common sense...
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2055
Location: Yateley, Hants, UK

PostPosted: Mon Sep 16, 2019 10:22 am    Post subject: Reply with quote

Quote:
Every day i open my programs in Clearwin i enjoy them very much.


To add to that, I have a program enhanced with CW+, and at first, I used to run the DOS/Command line version. I knew on the day I chose the CW+ version in preference that a new day had dawned.

The New Era began when I not only chose the CW+ version, but arrived at the point where it was rock-steady, and functioned properly in a Windows fashion.

Eddie
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Sep 16, 2019 9:19 pm    Post subject: Reply with quote

Another good analogy if what we discuss about crashing here is this. Remember how early browsers started to adopt the tabs? You got dozens of tabs in the browser and one of tabs freezes by some reason. Years ago that caused the whole browser to freeze or crash. Then developers started to give you the warning that the tab may slow down the browsing. Then they offered you to close the JavaScript loop casing the problems. Often this was already too late, the whole browser was slow like hell so you needed to use Task Manager to kill the process. Then they offered you to close the tab after warning and this already did not affect other tabs. Finally they solved the problem completely and one tab does not cause any problems to other tabs or browser no matter what happened in faulty tab, users just not even know what is happening under the hood. That story was mostly with the Firefox. Opera solved that long ago.

Our programs with Clearwin are like these multitab browsers, they are doing a lot of things at the same time. You start long simulation and at the same time can see the results without interruption. Or also at the same time do another task, estimate something, or analyse data. During this multitasking one minor task like plotting data may crash the plot, or solution gets to division by zero ets. You can not predict everything what may happen, this is like a small universe before you secure all outcomes will go many years. The program with Clearwin has to be crash resistant, small problem in its part, related to GUI do not have to kill the whole program

So the whole approach to resolving the conflicts which will always exist in real simulations has to evolve with the trend. But again GUI should never crash as the only way of exposing you programming error.

Today i was running the long task, all was fine, but after closing and calling the plot for second time i got the crash "Too many links specified for %PL plot" in the line winop@("%pl[link=lines]"). Holy smoke...If Clearwin instead told me that there will be a crash i'd aborted this line and fixed the issue later (hell know what that error means and how it happened, all other dozens of WINIOPs were not affected but this one decided to kick in. May be it did not close with the closed windows or does not like my %lw, so many choices and possibilities for conflicts).

And with this GUI crash "Run-time error 18: This routine has been entered recursively (-ANSI mode)" users and developers have to work together. The routine is user's callback, not the Clearwin's one. But Clearwin called it when the user clicked on the tab "Next Plot" before older one finished plotting. This recursive calling might happen with the regular Fortran routines too and there such situation might indicate the true errors justifying the crash or stop into debugger, for example. But in our case of GUI the crash is not acceptable because the user just tried to see successive outputs too fast
Back to top
View user's profile Send private message
wahorger



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

PostPosted: Tue Sep 17, 2019 3:48 am    Post subject: Reply with quote

I've been interested in this thread, mainly because it describes some things I had to handle in my code to handle the Windows environment.

And the same things had to be handled in under Visual C++ (126/32-bit Windows 95) in a previous incarnation of some of this code.

It's a Windows issue. It's not ClearWin or FTN95. But you need to be aware so you can handle the outlier conditions.

Sometimes, it takes time (or a *LOT* of time) for a window/dialog to free up the resources that were allocated for its creation. Using VC++, it turns out that the window could disappear (be destroyed) BEFORE the "CLOSE" message was intercepted and processed by the defined closing routine. And, since the pointer to the data is contained in the window structure (think of %ud on the window itself), once the window was destroyed, the clean up of my data could not take place because the pointer no longer pointed to my data.

One example: With ClearWin. I allow the user to set a scale factor for their data/menu screen. If it is too large to fit the physical screen, I detect that, then start an automated process to resize the window appropriately by changing the scale factor until it is "reasonable". I had to allow a 1 second delay between the destruction of the window and the creation of its new counterpart. Without that delay, the program would crash. Technically, it shouldn't, but it most certainly did.

Even if you have a "single thread" program, there are some processes/tasks that occur asynchronously to your code. And your program has to accommodate that.
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2055
Location: Yateley, Hants, UK

PostPosted: Tue Sep 17, 2019 11:47 am    Post subject: Reply with quote

Bill,

There are some really important points in your post. Like the fact that a Window closes taking with it all the information required to exit gracefully. The CW+ analogue is the WINIO@ return code, which must be SAVEd or in COMMON. Once you know thatís a problem, it then becomes the programmerís responsibility not to let it happen.

With scaling a window, perhaps this is where FREEZE_WINDOW_CONTENTS@ (and UNFREEZE_WINDOW_CONTENTS@) might come in handy? We forget such things with the speed of modern computers.

Eddie
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 1, 2  Next
Page 1 of 2

 
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