View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Jan 31, 2018 11:09 am Post subject: |
|
|
The issue has not been resolved yet. In cases like this we would aim to have a fix in place for the next full release (which will be v8.30). We normally have one or two full releases in a given calendar year. The personal edition (which is free) may be released less frequently. The last full release was in November 2017. |
|
Back to top |
|
|
narayanamoorthy_k
Joined: 19 Jun 2014 Posts: 142 Location: Chennai, IN
|
Posted: Wed Jan 31, 2018 1:27 pm Post subject: |
|
|
PaulLaidler wrote: | The personal edition (which is free) may be released less frequently. The last full release was in November 2017 |
Thanks Paul. But the personal edition V8.20 is yet to be released to public. When can I expect that release to public? I am seeing the major fixes include in V8.20 personal edition including ClearWin+. That helps a lot to our community. _________________ Thanks and Regards
Moorthy |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Jan 31, 2018 3:37 pm Post subject: |
|
|
Moorthy
I don't have any further information on this at the moment. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Jan 31, 2018 7:26 pm Post subject: |
|
|
This bug in FTN95 has now been fixed for the next release. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Sun Feb 04, 2018 6:56 pm Post subject: |
|
|
Just out of interest:
Routine A calls a subroutine B with the statement:
Code: | CALL B ( RGB@(25,0,0) ) |
(amongst other arguments)
Routine A lacks Code: | INCLUDE <WINDOWS.INS> | or equivalent.
Floating point stack fault appears.
Reason: Programmer fault. Solution: Write conforming Fortran code!
Eddie |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Feb 04, 2018 10:04 pm Post subject: |
|
|
Programming error is always subjective.
I'll comment with the full quotation of my 'signature' which I added to my profile today ...
Quote: | "This is the triumph of folly.
So much genius and so much zeal is devotedto the creation of this monstruous thing, which ought to remain a tool, but instead becomes our master.
The machine, which knows no rest,will swallow up our life and soul" ... Luigi Pirandello |
The forum wouldn't accept the full quotation, too long - I'll let you decide .... programming error or limitation ?
Probably the latter.
But what about the length limitation of posts to the forum - same question - more difficult to answer maybe ? _________________ ''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 ... " |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Mon Feb 05, 2018 10:26 am Post subject: |
|
|
There are more things in heaven and earth, John, than are dreamt of in your philosophy. Now who said that?
The point is that the error message, while true, is unhelpful to a user who has no knowledge of the workings of the compiler. Would IMPLICIT NONE show up the error? Maybe, but a programmer declaring RGB@ to be REAL would also get it. Using the appropriate INCLUDE at least makes sure that the types of all Clearwin+ entities are correctly declared, whether they are used or not.
The floating point stack fault may, indeed, result from FTN95 generating code that upsets the x87 stack, but it can also be generated by the programmer making a mistake.
Eddie |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Feb 06, 2018 3:39 am Post subject: |
|
|
I don't suppose Lord Nelson took any notice of that comment, he was a practical man
'Dreamt' is used in the wrong context (as it opten is) because philosophy isn't meant to in dreamland, it's meant to point out realities, which are oft derided by supporters of the very things philosophies oppose, hence the attempts to marginalise t�philosp�ophers as 'dreamers'.
As for error messages, you're perfectly right. Dan has had a pop a few times, justifiably, about the often meaningless messages (to the layman) which are regurgitated by compilers.
Error messages in reality, for the most part only give the end symptom, and rarely the cause.
Sure there can be several causes for �a single symptom, but the challenge is to try to give �as many pointers as possible to the likely cause.
We are lucky with ftn95 in havin�g both a highly reactive forum-meister and a number of very capable contributors the combination of which provides us with a very pleasurable user-experience.
Nobody's perfect of course, but a few more 'humanistic' error messages wouldn't go amiss !
Such as ...
"Stack Overflow and underflow detected ..... now are you sure you haven't:
a) blah blah blah
b) been a silly boy and .....
c) checked all your input data
d) initialised evertthing that should be to zero
e) used IMPLICIT ALL
etc ...
etc.... _________________ ''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 ... " |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Tue Feb 06, 2018 12:15 pm Post subject: |
|
|
In pointing out the symptom that caused the program not to function, and in protecting the computer from side effects such as destabilizing Windows, Paul & Co have done their job. It's a cultural thing, but I have sensed in the past that whereas we Fortran users see this as a crash, a crash means something else at the compiler programming end - what has been produced is a sensible and proper report and conclusion to trapping something wrong. The fact that it is written in Klingon doesn't mean that it isn't clear to Klingons.
The deep gulf is the result of the lack of a dictionary-manual that explains what it all means, perhaps giving hints on where to look and what to do about it. I'm not sure that a homily on what a bad boy or girl or whatever you've been really cuts it nowadays in the absence of corporal punishment. On the grounds that FTN95.CHM is hard enough to get through, perhaps the answer is another file like CWPLUS.ENH (That was intended to be a serious suggestion).
I'll make a couple of suggestions for it:
1. Floating point stack fault
(a) You passed a function to a subprogram without declaring the type of the function correctly when necessary. (NB, Clearwin+ routines are not intrinsic functions).
(b) Something went wrong with FTN95 (rare).
(c) It is devilry. Exorcists can be found via Google.
2. Floating point divide by zero (floating point coprocessor fault)
(a) You divided something by zero. (Win32). If you test all denominators against zero, you will get compiler warnings, but can trap this condition for yourself. An alternative is to test ABS(denominator) .LT. TINY(denominator), which doesn't give a compiler warning but does do the test.
(b) You divided something by an uninitialised static variable, (because FTN95 sets those to zero).
(c) It is devilry. Exorcists can be found via Google.
The serious point is that there's no middle ground document to explain what some of the more arcane error messages actually mean. Perhaps there should be. Perhaps it's up to the user base. You know who that means.
Eddie |
|
Back to top |
|
|
|