User friendly Clearwin error messages

I got one more property sheet crashing (third during 20 years) and i can not find the bug.

Do people agree that Clearwin should always keep the debugging information about the line where error happening no matter if the code compiled with /nocheck or even /optimize ? So if crash happens the line information will be displayed in readable format, not with hex address or relative continuation #. This will not add much to the exesize or not make the code slower, the human-to-computer interactions are slow anyway and /optimize or /nocheck are useless in Clearwin where reaction on mouse or keyboard are of the order of 0.1 second

Currently Clearwin only gives the bug report of this sort 'you got an error in continuation #146' suitable only for the future cyber brains in 22d century. And even worse recently i get the crashes with the error report 'Invalid initial value for %rf format. Are you sure that variable initialized at address a1c0004423443344323656535677456234 ?' which no one can find besides may be with one month of efforts mecej4 but he does not use Clearwin.

Worst ever part is that when you run the program through the debugger to find the bug the error disappearing no matter which compiler switch was used even the /nocheck. If compile the code with check or undef the crash also does not happen even without debugger

Dan

When developing ClearWin+ programs you need to use at least /DEBUG in order to get line number information on trace back.

This information is only built into the executable when using /DEBUG or options that imply /DEBUG.

Basically, if you need this information then you have to ask for it because it involves an overhead that is undesirable in release mode.

I always use /debug, even /full_debug when develop. As i wrote when /debug or /check or /undef is used the crash in %ps does not appear. If use /nocheck the code crashes but same code does not crash if run it through SDBG. Something is wrong with %ps. It does not allow to find the bug giving wrong error message. I suspect un-initialized variables may cause wrong message and the crash of this parts of the code which use %ps even though all variables used by all controls (like %rf %rd etc) are initialized variables. I mean, just the assignment at the end of file after all Clearwin GUI was completed like a statement A=B when B is not initialized ones caused the crash of my GUI with %ps.

As to not desirable additional debug information in the EXE file i agree but only for the Fortran text itself. Fortran is a language used, documented and polished by many people for decades. Clearwin is totally propitiatory, its logic, capabilities and complexity understands only its developer, all users just use it intuitively and good is that mostly it works great though sometimes you do not know how 😃. As to overhead associated with additional Clearwin debug information is totally, i mean TOTALLY, negligible as it was developed in 1990th when harddrives were 1 GB in size and RAM in 10 MB range and nobody cared about exe sizes due to Clearwin even then. Since then all the Harddrive and RAM sizes grew not 20%, not 100%, not even 1000% but 4 orders of magnitude while EXE sizes remain approximately the same

As to slowdown associated with this a bit larger weight of exe files if you compile Clearwin code with /debug was not a problem even in 1990th with their toy computers based on 80486 as the response time of GUI even then was orders faster than human's 0.1 second lag.

Conclusion : loss of users time when we write and debug Clearwin code it the major problem with it. That so much limits its adoption and usabily, that i personally ready to give some GUI speed and exe size in favor of simplicity of finding of any problems. Actually even if my EXE size was not 20 MB but 200 i'd do not even blink an eye. Intel compiler EXE sizes always were many times larger than FTN95 ones and starting with middle of 1990th not a single user ever cared or complained

Dan

You keep going back to this issue and I have tried to explain to you that what you are asking for is just not feasible. There is nothing more that I can say.

Dan,

As you know, hunting down a bug is difficult if not impossible when we are given only a verbal description. You have to be willing to provide a 'reproducer'.

The chances of a reproducer leading to a successful identification of the bug are higher if the reproducer is smaller. You may have to spend some time in creating a small reproducer but in return you (and possibly other users with similar code) will be rewarded with not having to worry about the same bug giving you problems in the future.

Let's have that %PS bug reproducer, please?

John S., you said:

an overhead wouldn't exist in the 'production compile' because one wouldn't use DEBUG for that (as all the (known) show-stopper bugs wold have been eliminated.

For that to be true, there would probably have to be available two versions of the Clearwin library and DLL, one with traceback capability (i.e., the debug version) and the other without (the production version).

An analogous situation exists with the Microsoft Visual C compiler and libraries. There are debug and non-debug versions of many of the C libraries; for example, LIBCMT.LIB and LIBCMTD.LIB.