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 

SDBG shows wrong variable

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Fri Apr 18, 2014 1:47 pm    Post subject: SDBG shows wrong variable Reply with quote

When the line hits the 72/132 char limit the debugger still shows offended variable as if it is not truncated, prints its value as if the code is OK. It has to shows variable as an undefined or unknown.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 732

PostPosted: Sun Apr 20, 2014 1:50 pm    Post subject: Re: SDBG shows wrong variable Reply with quote

DanRRight wrote:
When the line hits the 72/132 char limit the debugger still shows offended variable as if it is not truncated, prints its value as if the code is OK. It has to shows variable as an undefined or unknown.


The debugger does not have a sense of "code is OK". That kind of ability resides in the compiler. If you want undefined variables to be tracked, you need to compile with the /undefined option before running the code inside the debugger.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Apr 21, 2014 8:38 am    Post subject: Reply with quote

That is exactly what I do. I track undefs and the debugger stops on the line but when you hover the mouse over all variables in the offending line you see perfectly defined values for all of them
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Mon Apr 21, 2014 8:39 am    Post subject: Reply with quote

That is exactly what I do. I track undefs and the debugger stops on the line but when you hover the mouse over all variables in the offending line you see perfectly defined values for all of them
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 220
Location: Manchester

PostPosted: Mon Apr 21, 2014 10:56 am    Post subject: Reply with quote

Is the problem that the debugger is picking up words from comments and interpreting them as values OR that you have an undef error and cannot find the undef?
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Mon Apr 21, 2014 6:44 pm    Post subject: Reply with quote

The latter one. If debugger found an undef var error it has to expose this errors as error. Possibly suggesting that 72/132 limit was broken by frequency analysis of existing variables. Currently the debugger stops on error line and shows all variables are in perfect shape while one of them actually crossed the border and became a new variable.

By the way debugger found this error because truncated variable is unknown to the code and undef feature exposed it. I suggested before to treat truncation as an error by default, if the code has the variables similar to truncated one you may not find the error for years. / Because there exist infinite amount of computer codes which results coincide with the experimental data Smile. Compiler bug hunting capabilities don't have to suffer due to ancient legacy practice of commenting on punch cards
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 220
Location: Manchester

PostPosted: Tue Apr 22, 2014 6:15 pm    Post subject: Reply with quote

Don't you just need /no_truncate?

http://forums.silverfrost.com/viewtopic.php?t=1723
Back to top
View user's profile Send private message Visit poster's website
DanRRight



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

PostPosted: Tue Apr 22, 2014 10:25 pm    Post subject: Reply with quote

I know that, and thanks to Paul and all devs this switch was added. I forget to use it for quick small codes and I'm sure most people would too. I wish all try it and see that it's safe while helping to catch a lot of errors. Then just make it a default. Let those rare users of ancient codes and libraries of FORTRAN-66 use compiler switches. As time goes this becomes more and more reasonable.

The subj of this thread is different though and until "truncation = error" is not a default the debugger has to be adjusted to report what actually is in the code versus what was intended
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 732

PostPosted: Fri Apr 25, 2014 1:01 pm    Post subject: Reply with quote

There is a simple way of specifying custom options without having to type them in every time one calls the compiler. Look in the FTN95 help for a description of "FTN95.CFG". In the configuration file, you can, for instance, specify /WRAP or /NO_Truncate. A related option is /WIde_source.

That is a far better solution than imposing one person's idea of "normal" on every user of the compiler. Changing the behavior of the compiler in a way that deviates from the applicable Fortran standard could make some users form an undeservedly negative opinion of the Silverfrost/Salford compiler.


Last edited by mecej4 on Fri Apr 25, 2014 4:56 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 732

PostPosted: Fri Apr 25, 2014 1:02 pm    Post subject: Re: Reply with quote

SORRY, DUPLICATE MESSAGE, PLEASE DELETE.

mecej4 wrote:
There is a simple way of specifying custom options without having to type them in every time one calls the compiler. Look in the FTN95 help for a description of "FTN95.CFG". In the configuration file, you can, for instance, specify /WRAP or /NO_Truncate.

That is a far better solution than imposing one person's peculiar ideas of "normal" on every user of the compiler. Changing the behavior of the compiler in a way that deviates from the applicable Fortran standard could make some users form an undeservedly negative opinion of the Silverfrost/Salford compiler.


Last edited by mecej4 on Fri Apr 25, 2014 4:55 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Apr 25, 2014 3:45 pm    Post subject: Reply with quote

Look at the FTN95 list of features, it has them more then all other compilers combined. No one complained that it has too many. And all of them started with typically one person ideas and one person implementation of what is good or bad.
The rationale to use /No_truncate feature as a default is that unless you make comments in the code this ancient FortranIV way
Code:

C     PIVOT ROW REDUCTION AND ROW INTERCHANGE IN RIGHT HAND SIDE R      EDV753234         
      DO 8 L=K,NM,M                                                     EDV753235 
      LL=L+I+K                                                          EDV753236   
      TB=PIVI5432*PIVI5432*PIVI5432*PIVI5432*PIVI5432*PIVI5432*PIVR3(LL)EDV753237 
      R(LL)=R(L)*R(L)*R(L)*T(L)*B(L)*Y(L)*H(L)*D(L)*S(L)*A(L)*D(L)*R2(L)EDV753238 
    8 R(L)=TB   

it will not break anything. Exactly opposite, it will find a lot of errors.
I found ~50 truncation errors in the some 200K lines code recently. The author is using G Fortran and despite my warnings still keeps producing new ones LOL. I made myself probably 1000 in my lifetime losing a lot of hairs to find the one of the most hidden errors the truncation produces.

Another rationale behind this is is that even if you use old libraries with comments like above the amount of such code respect to the modern and less error prone way of commenting using exclamation marks currently is negligible and decreasing as time goes below the noise level. More libraries got rewritten without such punchcard way of commenting, not even saying about Fortran 90 way. Let's those who use old way of commenting use switches /TRUNCATE. Amount of FortranIV people is already negligible and if someone will object no one will even notice. It's time to have that as a default in the Standard too.


Last edited by DanRRight on Fri Apr 25, 2014 4:43 pm; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Apr 25, 2014 4:37 pm    Post subject: Reply with quote

Hi Dan,

Those aren't Comments, they are sequence numbers. Useful for getting that box of 2000 cards back in the right order when you dropped them on the 5th floor of a scarily open staircase and they dealt themselves into 400 or more 'tricks'!

If you used sequence numbers and old-fashioned coding forms (and got your cards punched by a nice middle-aged lady) you never went over column 72 ...

80 column cards with a 132 column lineprinter always struck me as an odd combination back in the 1970s, but then particularly in the early 70s and before, we Brits usually used 8-hole paper tape, and line length for Algol-60 was limited by what you could print, rather than the length of a card. For a couple of decades I moaned and whined about a restricted line length in Fortran, but it eventually dawned on me that my printer (and I've had a few!) liked to put around 80 characters per line at a reasonable monospaced font size on A4 paper - you know, the paper size that around 6 billion people use - (or even US letter!) and once again there is convergence between the Hollerith card length and what is easily printable. At one time it was difficult to get more than 80 characters wide on a PC screen too.

Debugging 5 lines of someone else's code seems to me like a lot of work, and 200k lines an impossible task.

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



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

PostPosted: Sat Apr 26, 2014 10:40 am    Post subject: Reply with quote

Eddie, These could be sequence numbers, program names, anything, so people used that for all sorts of comments. I used punchcards myself when learning programming and using not just legacy but legacy legacy codes before switching to PDP and VAXes in 70th. LOL Then even before standard extended 72 limit to 132 people started to use exclamation marks because of convenience. Now probably still exist few programmers who count 72 positions and write their commentaries there making errors themselves with the slightest editions and not allowing compilers to catch truncation errors for the rest of users

As to using large old third party codes which were not compiled by FTN95 - this is truly fun stuff if their authors still exist. You can safely bet 100 bucks that FTN95 will find 100 errors per 100K lines code, 10 of which will be serious ones authors suspected but could not find all their life! They will be shocked in disbelief what compiler will find. They will be smashed by 100+KB of comments and 100+KB warnings.

/*They will be fixing the code for a year. But despite of that will still continue using their old bugotron. LOL
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sat Apr 26, 2014 1:14 pm    Post subject: Reply with quote

Quote:
Now probably still exist few programmers who count 72 positions


Dan, you are talking to one! And for a couple of reasons:

1. Familiarity - it looks right to me, and I can see the errors very quickly. I use very short lines of code, and rarely ever get to column 50, let alone 70. I use lots of white space too. It's analogous to only doing one thing at a time in WINIO@. I can't handle long, dense, statements.
2. Paul very rarely has to fix problems in Fortran 77 code, usually he is dealing with esoteric things in Fortran 90 et seq, or upgrading Clearwin+, or fixing compatibility with something Microsoft changed, so for me this is the safe subset.

In the end, it's all a matter of personal taste. I probably have many bad habits, such as deprecating the things that the Fortran committee likes, and liking some of the things they deprecate! One can have extended discussions about preferences and taste, but for me the most liberating thing about moving from punched cards and listings was the end of a restriction on the number of lines rather than the length of an individual line, so I could put in blank lines to divide the code up, and in many cases I find that this does away with the need for too much indentation.

I understand your exasperation at having to deal with other peoples code: one's own is hard enough to read after four decades (or even four days, sometimes!).

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



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

PostPosted: Sat Apr 26, 2014 2:41 pm    Post subject: Reply with quote

Oh, cmon, Eddie, stop kidding, you are late with Apr 1 stuff, or you're asking for compliments? LOL It's easy to prove the opposite: I used two of your code examples from this board in my code, both look absolutely OK, nothing like punchcard nonsense above.

http://forums.silverfrost.com/viewtopic.php?t=2774

and

http://forums.silverfrost.com/viewtopic.php?t=2645&highlight=setwindowopacity

Keep writing code in the same style and /no_truncate (though wait for new release, Paul in another thread mentioned clearing of some problem with fixed texts ) will never hurt you.
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 -> Suggestions 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