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 

Curiocities
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Wed Mar 25, 2015 12:22 pm    Post subject: Curiocities Reply with quote

Want me to show you true pure example of programming devilry again? Here is one damn error resolved at 4 am:

Code:

11800)           Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/
11801)      *    (RELABexSUM(IZSp1,iii)+1.e-7)
*** ':' found where not expected
*** INTEGER expression expected in substring range


Where the hell here is this damn colon? Or Integer expressions? The fun was that exactly next lines in this log file were the following

Code:

12149) 6666    b = A_exc_HULL(6,I,J,IZS)/TE_llnl
WARNING - Label 6666 is declared, but not used
11606) 66666   b = A_ion_Hull(6,I,J,IZS)/TE_llnl
WARNING - Label 66666 is declared, but not used


And even more - you think i actually eventually found the error? Not at all, after some time of harassing me it *disappeared* by itself!

And even that was not all. I decided to save this whole compilation log file for history because no one will believe me. And to find myself what was going on. But when i hit Ctrl+S the application of text viewer crashed with access violation. But the text was left on screen. I eventually succeeded to save it together with Fortran text and its BAK file. There is no colon there but the old BAK file does not compile!

May be somebody see here what i do not see?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Mar 25, 2015 3:12 pm    Post subject: Reply with quote

For me this code fragment compiles without error.
Perhaps we need more code in order to comment.
Back to top
View user's profile Send private message AIM Address
John-Silver



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

PostPosted: Fri Mar 27, 2015 8:56 am    Post subject: Reply with quote

Quote:
after some time of harassing me it *disappeared* by itself!


well, I don't believe that that's for sure ! You must have done something in the interim period.

As for the errors, as you mention it's devilry it's obviously linked to the 666's in the non-referenced labels !! LOL Wink
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Mar 28, 2015 9:38 am    Post subject: Reply with quote

Exactly. Smile As to believe or not - look at the continuation, this is interesting. Further investigation when computer compared two files instead of my faulty human eye revealed that these two lines in these files are different:



Upper part is defective, lower is not.

Binary comparison of these lines showed presence in defective file just one more ascii symbol hex 20 which is integer 32 ... which is just the space and nothing else

I checked that additional symbol does not expand the line beyond 72 symbols long, so that is not a reason of a problems.

I extracted this piece sans 666 part into small code and post it here. It produces exactly this error report. Try it yourselves and see if devilry disappears. This forum unfortunately destroys fixed fortran formatting and you may not get the effect. I can post this file zipped then

Code:

        integer NUMBlevsZ (100)
        real*4 RELABex (100,100,100)
        real*4 Ct_Hull (100,100,100)
        real*4 RELABexSUM (100,100)
 
   DO  i = 1, NUMBlevsZ (izs)
      Ctbr_Sum = 0
     Do  j = 1, NUMBlevsZ (izs+1)
     Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/
     *    (RELABexSUM(IZSp1,iii)+1.e-7)
     enddo
   enddo
   end



UPDATE: OK, to keep the experiment clean here is zipped file i posted on Microsoft OneDrive website:

http://1drv.ms/1Mf7XvO

Just compile it and see the devilry yourselves! It's just the text file so nothing to worry about. Besides the devilry
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sat Mar 28, 2015 1:30 pm    Post subject: Reply with quote

The devil's in the ASCII -- your source file has tabs. Replace them by spaces (most text editors can do that, or you can use the FTN95 /convert option) and your devils will have been put to bed.

Next time when you are typing in a program, make sure at first that your text editor is set to replace input tabs by spaces.

You can expect similar problems if other "whitespace" characters (reverse-tab, backspace, delete, form feed, ..., irregular combinations such as LF+CR) are embedded in your Fortran sources.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Mar 28, 2015 8:59 pm    Post subject: Reply with quote

Let we investigate this suggestion a bit more since it sounds like an over-forcing to my style of programming. I always reasonably - mostly for indentation if this is correct english word for beginning of line formatting - used tabs with no problems, they are still used with working file with no problems and fun is that I did not touch the offending part of the file for decades to cause this problem. Tabs were used with DEC, Cray, MS, Compaq Fortran compilers in the past with this same code as it was evolving over all these years. Binary comparison also shows that the space was added to offending line not the tab. I afraid we will throw the child, I mean devilry, with the water and it will appear again Smile.

So, first, can you guys with other compilers check how they compile this broken code?


Last edited by DanRRight on Sun Mar 29, 2015 7:01 am; edited 2 times in total
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Mar 29, 2015 6:26 am    Post subject: Reply with quote

interesting that the extra space causes the failure.
I tried changing the code to F95 format (just changing the continuation) and it compiles fine with the space left there !!!

interesting that the lack of dimensioning of the array RELABexSUM(i,j) goes without error flagging. why is that ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Mar 29, 2015 9:26 am    Post subject: Reply with quote

Quote:
...why is that?
An occurrence of a variable followed by a list of arguments within parentheses is taken to be a function reference if the variable is not known to be an array. Try linking the object file. No surprises here.

Had IMPLICIT NONE been specified, an error message regarding the type of RELABEXSUM would have been issued.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Sun Mar 29, 2015 11:51 am    Post subject: Reply with quote

Mecej4,

Would IMPLICIT NONE bring up an error if the array was in fact a function reference? Why should it? I can see that an EXTERNAL function might need to be explicitly typed so that when it is used as an argument in a call its type is clear (for example the callback in WINIO@), but the type of non-EXTERNAL functions is presumable decided later.

If it did elicit an 'error' message, surely it should be a warning rather than an error, as there would still be the opportunity for it to be a function.

I suspect that it takes more than IMPLICIT NONE to resolve this.

As a real oldie, I have to confess that IMPLICIT NONE simply makes code unreadable to me (especially in combination with F90 formatting) - so it takes all sorts!

I think that I discovered that the TAB character stopped being useful when I moved from terminal access to a VAX 780 to my first PC, c. 1983, with Microsoft (Yah, Boo, Hiss) Fortran version 3.1, and I converted them all to spaces with WordStar in 'non-document' mode. My memory of this is hazy, but didn't the VAX map the first tab to column 7 and after that to multiples of 8 or 10? Other systems didn't, and lost valuable character positions in fixed format! I'm astonished that Dan got away with it for all this time, so perhaps the 'devilry' is, in fact, 'original sin'!

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Mar 29, 2015 12:25 pm    Post subject: Reply with quote

Eddie,

Unless there is a type declaration for a function within scope, when IMPLICIT NONE is used or the /IM compiler option is used, the result is an error message. Often, one adds IMPLICIT NONE to order the compiler not to apply implicit typing rules, thereby making explicit type declarations mandatory. In fact, FTN95 says this about Dan's code:
Code:
0009)      *    (RELABexSUM(IZSp1,iii)+1.e-7)
*** RELABEXSUM must appear in a type declaration because IMPLICIT NONE has been used

The use of tabs is an extension. Here is one vendor's specification of the rules for expanding tabs: http://docs.oracle.com/cd/E19957-01/805-4941/6j4m2sobi/index.html . I do not know if FTN95 has similar written rules.

Original sin? We do not need to hark back to Adam, the snake and the apple. Dan chose style over substance, and probably has a mess of it to handle. Fortunately for him, all that he has to do in expiation is to run his source code through a filter or to use FTN95's /CONVERT, and request the compiler to accept wide lines (expanding tabs can cause some lines to end to the right of col-72 or col-132). I think that is is wrong to shop for a compiler that will accept buggy code and produce correct results.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun Mar 29, 2015 4:41 pm    Post subject: Reply with quote

I was wondering why a 'space' should cause a problem, then I saw there are other 'space's on the line in question.
Then I spotted the problem ...... we're talking f77, and that line has 73 characters long !!!!!! so, it doesn't pick up the continuation '*' !!!!!
Just bump the end of that line to a new intermediate continuation and everything compiles fine.

Of course it compiles in f95 because there is no 72 char limit to no. characters on a line

I'm still concerned that the other 'errors' are not even flagged as warnings by the compiler.
Even though it would assume RelaBexSUM as a function, why isn't it complaining that the function doesn't exist !!!!!! ?????

Here's the code I tried which compiled

Code:
        integer NUMBlevsZ (100)
        real*4 RELABex (100,100,100)
        real*4 Ct_Hull (100,100,100)
 
   DO  i = 1, NUMBlevsZ (izs)
      Ctbr_Sum = 0
     Do  j = 1, NUMBlevsZ (izs+1)
     Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)
     *    * Ct_Hull(j,i,IZSp1)/
     *    (RELABexSUM(IZSp1,iii)+1.e-7)
     enddo
   enddo
   end


... there are of course the <tabs> in there which don't show correctly !!!!! but you see what I've done, just bumped the '* Ct_Hull.....' to the next line (leaving the 'space'.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Sun Mar 29, 2015 5:19 pm    Post subject: Reply with quote

Quote:
why isn't it complaining that the function doesn't exist
That is not the compiler's prerogative. Fortran has the associated concept of separate and independent compilation. The source code of a program can be spread across a number of files. The function subprogram may reside in a different file than the source containing its invocation. In fact, the function may not even be available in source form, but in a precompiled library or DLL. When the compiler is processing one source file, it need not have any awareness of the contents of other files (unless modules are being USEd).

It is at link time that undefined external symbols get reported.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Mar 29, 2015 5:23 pm    Post subject: Reply with quote

The function will be declared as missing at link time. For an error report at compile time try using the command line option /DCLVAR.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Mar 29, 2015 11:57 pm    Post subject: Reply with quote

Just on the comments about the use of tab characters:

I find it very annoying when tab characters are used in fixed format Fortran code, as the different editors I use do not use the same tab spacing definitions.
I have been reviewing code recently, where in the editor I am using (Plato or notepad), the use of a tab character moves code to column 5, where the original IDE (probably VS) moves the character to column 7.
This is a problem when viewing the code in different IDE/editors and I am not sure what FTN95 or other compilers do with this code, which is another more important problem.

It is this poorly defined response to tab spacing that suggests to me that there should be a compiler option to report tab characters as an error. I think that they are not in the Fortran standard character set for code and their presence could change the action of the code, especially in .for files. Code that uses tab characters should have a header to define the tab spacing rules.

I have even written my own code viewer that replaces all control characters, especially <HT> <CR> and <LF> to identify these problems.

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



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

PostPosted: Mon Mar 30, 2015 12:34 am    Post subject: Reply with quote

Not declared variable is not related issue. When extracting the line into the test code i just forgot to declare one variable which i thought is still irrelevant. It was declared in the posted code on this forum above by the way. Anyway, this code has 200000 tabs and never had any issues for 37 years with any compiler. Same with other large code written by colleagues and compiled on a half a dozen different compilers on PC, Unix and Mac. So, returning to our devilry -- what specifically caused compiler to issue this exact error report?

Respect to John's comment, few years back when i tried Plato i made a suggestion on this forum to discuss making the tab user-definable separately for fixed and free source codes. Have both types of sources in the same code but Plato does not automatically recognized them making Plato useless for me. This suggestion would solve all the tab problems i think. Substitution of tabs with respective amount of spaces option could be also useful as a bonus.
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 -> General All times are GMT + 1 Hour
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
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