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 

User friendly Clearwin error messages

 
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: 2187
Location: South Pole, Antarctica

PostPosted: Mon Apr 06, 2020 8:28 am    Post subject: User friendly Clearwin error messages Reply with quote

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


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

PostPosted: Mon Apr 06, 2020 8:59 am    Post subject: Reply with quote

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



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

PostPosted: Mon Apr 06, 2020 8:00 pm    Post subject: Reply with quote

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


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

PostPosted: Tue Apr 07, 2020 8:22 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1273

PostPosted: Tue Apr 07, 2020 9:19 am    Post subject: Reply with quote

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



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

PostPosted: Thu Apr 09, 2020 12:25 pm    Post subject: Reply with quote

I don't think Dan is asking for nybody to 'debi=ug' this particular problem he has, he's just saying that basic info should be accessible (like line number where error occurs) so that the user can more effectively debug n the first instance without having to rely on the developinf entity's degugger (Paul) , or the more astute amongst the user-community (mecej4, for example) to analyse the problem for them.

While I appreciate the verity in Paul's statement that the overhead to output all DEBUG informationmight be considerable (depending on the program):-

a) I don't think Dan is asking for everything (it could be develpoed progressively)
b) 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

Would it really be that difficult to include be able to output say just the line number where the failure occurred, for example ?
That on it's own would be a massive starting point, I would agree with Dan there.
_________________
''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
mecej4



Joined: 31 Oct 2006
Posts: 1273

PostPosted: Thu Apr 09, 2020 5:53 pm    Post subject: Reply with quote

John S., you said:
Quote:
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.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Fri Apr 10, 2020 2:07 am    Post subject: Reply with quote

I based my comment on comments I've seen before on the forum, not based on any experience as I have no need to use debug.
I thought everything was activated simply by the presence or otherwise of the /DEBUG.
Previous comments I've seen indicated that by calling the debugger the executable code was more ponderous/slower but that in 'production mode' (i.e. without the /DEBUG) it was hence faster.
I stand corrected.

Could this be the reason for those abnormlly slow polyhedron tes results then ?
_________________
''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
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
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