SLINK64 diagnostics

I find it as a disadvantage of 64bit SLINK64 vs regular 32bit SLINK when former and newer one provides less diagnostics then latter. For example SLINK64 does not check common block size mismatch like here

WARNING - Common block 'VIEWDATA_SPECTRA/' was previously defined in object file c:\SPECTRA\_Srces\SPECTRAV.obj as size 64 but is now defined as size 56 (c:\SPECTRA\_Srces\SPECTRAK.OBJ)
WARNING - Common block 'VIEWDATA_SPECTRA/' was previously defined in object file c:\SPECTRA\_Srces\SPECTRAV.obj as size 64 but is now defined as size 56 (c:\SPECTRA\_Srces\SPECTRAK.OBJ)

Older SLINK also gave me other warnings, some of them look strange, for which I did not find the reason (could be its mistake or most probably my own really devious bugs somewhere) I can not imagine that MIN or or WINDOW_UPDATE@ can be defined differently for any reason. Or that DRAW_CHARACTERS@ are missing :

WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file c:\SPECTRA\_Srces\SPECTRAW.obj (c:\SPECTRA\_Srces\SPECTRAK.OBJ)
WARNING - Module component MIN has been defined differently here than previously in object file c:\SPECTRA\_Srces\SPECTRA.obj (c:\SPECTRA\_Srces\SPECTRAX.OBJ)
WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file c:\SPECTRA\_Srces\SPECTRAW.obj (c:\SPECTRA\_Srces\SPECTRAX.OBJ)
WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file c:\SPECTRA\_Srces\SPECTRAW.obj (c:\SPECTRA\_Srces\SPECTRAX.OBJ)
WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file c:\SPECTRA\_Srces\SPECTRAW.obj (c:\SPECTRA\_Srces\SPECTRAX.OBJ)
WARNING the following symbols are missing:
EXPORT_PNG#                              c:\SPECTRA\_Srces\SPECTRAW.obj
                                              (C:\SPECTRA\_Srces\SPECTRAW.FOR)
PNG_TO_SCREEN_BLOCK#                     c:\SPECTRA\_Srces\SPECTRAU.obj
                                              (C:\SPECTRA\_Srces\SPECTRAU.FOR)
EXPORT_IMAGE#                            c:\SPECTRA\_Srces\SPECTRAV.obj
                                              (C:\SPECTRA\_Srces\SPECTRAV.FOR)
DRAW_FILLED_ELLIPSE#                     c:\SPECTRA\_Srces\SPECTRAG.obj
                                              (C:\SPECTRA\_Srces\SPECTRAG.FOR)
DRAW_CHARACTERS#                         c:\SPECTRA\_Srces\SPECTRAR.obj 

May be I am missing some new compilation switches in 64bit linker?

Dan,

Looks to me that you have left out an 'include <clearwin.ins>' from one routine. It would be good if the message identified the routine, rather than just the file. The devils have been given a lot more freedom in SLINK64.

There have been indications that SLINK64 may be enhanced shortly.

John

John, I will try to find subroutines with missing clearwin.ins in these files, though there could be 100-200 of them to check in each file. Completely support you that much better would be if linker tell in which subroutines were found problems instead of files.

But why the hell intrinsic MIN got defined differently - this smells like a pure devilry. Could not find this bug for years.

SLINK64 does not appear to check for miss-matched common block sizes. I will ask if this can be added.

You have to translate EXPORT_PNG# to EXPORT_PNG@ etc. to get the name of the missing routine. Maybe SLINK64 could be improved to do this transcription for you.

Paul,

Yes, check for miss-matched common block sizes is very importasnt. I had a hell amount of bugs in common blocks over 40 years of my codes. Without that the codes be full of so many bugs they would be all dead by now

As to other thing, I do not have any subroutines ending with #, that ones with # were what's linker wrote

Dan

Yes. The problem is within SLINK. I think that SLINK64 is OK. I am not sure that I want to go digging into SLINK at this late stage.

Thanks.

Now one more question, now about SDBG64: when you are in debugging if you press and keep right arrow the entire page of text gets progressively cut from the left. If you then push left arrow the text will reappear again. What for this at first glance useless and annoying feature (everyone missing keys if not look at the keyboard and touch these keys) was done ?

That is just weird!

In the next release, FTN95 or SLINK64 will give a warning when common block sizes do not match (FTN95 when they are in the same file otherwise SLINK64).

Quoted from DanRRight Thanks.

Now one more question, now about SDBG64: when you are in debugging if you press and keep right arrow the entire page of text gets progressively cut from the left. If you then push left arrow the text will reappear again. What for this at first glance useless and annoying feature (everyone missing keys if not look at the keyboard and touch these keys) was done ?

For entertainment?

I see this strange behavior in FTN95/SDBG64 8.10 when the cursor is on a source line that stretches beyond the current right-margin of the source window, and the right-arrow is pressed. Columns 1-19 in the whole source get blanked. Subsequent presses of the right arrow key blank one more column; each press of the left arrow key reveals one more column to the left.

Showing mis-matched sizes common blocks in SLINK64 would be great, thanks for superquick fix !

And one more thing about SDBG64: if you right click on variable to show its value in popup window, the size of window is calculated incorrectly and the name of variable on the top bar of window is not completely seen. You can not increase the window size to make it visible. The value of variable is visible OK and the size for its complete visibility is calculated i think correctly (but i need to double check how large character variables look like)

Dan

I can not imagine that MIN or or WINDOW_UPDATE@ can be defined differently for any reason.

Well, MIN could really be MINI or MINE or somesuch accidentally edited, although I at first suspected column 72 overspill.

You get into trouble with some Clearwin+ intrinsics if you accidentally CALL a function or put a subroutine in an assignment, but do so in a separately compiled file so that it only becomes obvious as link time.

Eddie

Eddie, Possible though still less and less probable after Paul made checking for over-the-border errors avoiding mess caused implicit none (JohnC wants me to declare 40 000 variables, which is hell but ok, but loosing convention for integer variables to be ijklmn and the rest not-integer may create an error i will never find in such forest like my own programs) I will revisit that, may be this checking mechanism already found the error but made only warning or by mistake i suppressed some errors to become just the warnings. This error is serious and has to stop compilation for sure.

Hopefully this warning also will be made reporting bugs with more detailed position, telling not just the file but the subroutine in the file or even the line of code if /check or /debug are used. Right now I have to scan couple hundred subroutines in the file and not find quickly just give up if code works reasonably

Dan,

I'm not a fan of IMPLICIT NONE either, but there is no constraint on variable names, and even with IMPLICIT NONE you can declare all your INTEGERs with names that start with ijklmn if you choose. Therefore, you can incorporate IMPLICIT NONE step by step, routine by routine.

Eddie

My advise to anyone would be if your code gets beyond 100k lines use one convention all over the entire code either with or without implicit none. Or you will not find hidden errors. Step by step will not go, Eddie. All or none.

I tried implicit none 20 years back and now convinced to be strictly against of it in my codes. Two reasons: ones I made an error which was not found for years because i thought that variable was int kind but there was implicit none used. FTN95 or any other compiler has no facility to tell you that the usage of integer in place of fp or fp in place of integer could be inappropriate. And second is increased difficulty to search and double check what type variable is this or that when the code is growing and growing and eventually there will be too many variables and errors to slow down the code further development to total stall. Even without implicit none I am moving now like a turtle, each smallest change in the code is like a brain surgery.

By their nature the arithmetics and usage of int and fp are very different. They perform different play in the codes. Remembering or finding types of few variables is easy. Remembering 100k of them could be trickier. Imagine the world with no externally visible gender differences where all people looking, say, like men and every time to be 100% sure you have to go to the city council and ask if this is a man or woman?

There are two other reasons to not use implicit one: FTN95 has facilities better then implicit none in catching errors which find not just the static errors like stupid typos. First is /undef or /checkmate for catching both static errors and errors in logic, or dynamic errors, with just 1-2 rarely happening exceptions mecej4 demonstrated (we extensively discussed this few years back) and this is immensely better. And second is new addition to armory: it is eliminating one of the main reasons of generation of hidden static errors which is 72/132 character limit trespassing by applying some new compiler switch. Unfortunately latest changes in FTN95 made this switch to issue only warning not error message. This is wrong, by nature hitting border limit must generate an error the same way as implicit none is doing this (is this because of not so clear Tab issue?).

[color=green:6cda9498a1]And last moments are mostly personal, where YMMV -- how well organized programmers are, how much free time they have, how easy they write, how many errors they typically make per line (i typed 'implicit one' three times here and did not notice that till few hours later). Having now in my age good chance to compare things together with not very many illusions left, I see my bad sides and habits more clearly. That I'm totally disorganized, have too many things to do and all of them are running with years of delay, despite 26-28 hours (!) working day, causing permanent stress. Add here bad genetics of my ancestry though probably this is true for the entire country I'm from (aboriginals of one well known vodka drinking tribe), big holes in humanitarian subjects and foreign language skills. I make hell amount of typos, rewrite the texts many times and always forget small things (bad 'short memory') like a retard. Important is that i am not initially English speaking so the variable names do not posses for me any emotional component. Plus in almost four decades my codes grew too big to handle easily for such kind of disorganized person. So the implicit none additional freedom of anarchy is not for me, while any advantages of it the unique features of FTN95 nullified with the huge gain. Without these features, which are the gold standard of pest control, I'd stop around 2000-2010 because of entropy of errors made me hunt them 24 hours a day or change the area of work.

I often reuse older code. That means till my total sheez and Alzheimer I will not use implicit none. There exist one chance for implicit none for me. If I will start using Plato and it will allow to see variable types without a click [/color:6cda9498a1]

I agree that it is desirable that it should be all or nothing as far as IMPLICIT NONE is concerned, the point was that if you want it, it is possible to implement it routine-by-routine *AND *still keep the old implicit type conventions. As for me, the certain knowledge of what is INTEGER is invaluable, as I still use codes I wrote well over 40 years ago. My only type assumption error was declaring lambda to be REAL, and that drove me nearly mad. I'd lost access to machines where single precision was 48 or 60 bits, and 32 bits wasn't good enough to converge the calculation. The problem wasn't even that I thought it was INTEGER, I knew I'd 'sorted it out' a decade before. IMPLICIT NONE wouldn't have helped, as the type was declared (to be the useless 32 bit standard precision REAL).

I think that your suggestion that in Plato the different variable type could be shown colour coded is an excellent one (for those afflicted by IMPLICIT NONE). Perhaps in response to a switch. I hope that Paul takes notice.

As for everyone looking like a man, I didn't know that you had spent time in an East German Olympics squad!

Eddie

I am a bit lost about this IMPLICIT NONE discussion.

You can put an IMPLICIT NONE at the start of each (or some) routine. You then have to explicitly define the type of all variables being used, be they in MODULE, COMMON or local.

There is no requirement to make I a real variable or A1 an integer. You just have to declare their type.

What you are effectively doing is providing a dictionary of allowable variable names for each routine, so if the variable name is not in the 'dictionary', then you get an error report.

If you use include files for COMMON or modules, then declaring all variables listed in the include file replicates the work for all routines that use these includes. With modules, there is less work, as a module is typically a list of declarations.

You are then left to declare the local variables in each routine. As for 1000's of variables, how can that work ? I have always had a coding strategy of a routine can fit onto a page ( 60 lines of code ) hard to get 1000's of local variables into a single routine. I do have modules that are 1000+ lines long, with derived type definitions and global variables. I need a dictionary in this case. I think you would be surprised how many spelling errors you have in your code.

Really not sure how this destroys the spirit of I being an integer ?

John

Precisely, John. The issue of how you name your variables of different types is separate from whether or not you use IMPLICIT NONE or not, and as well as incrementally incorporating IMPLICIT NONE in your code routine-by-routine, you are right that you can do it in INCLUDE files.

E

What if i forget to declare I123453423 ? Why i need to go to another file, module or function or hell knows where to see was I123453423 declared or not and if yes then how? Why when debug or update the code i have to search I123453423 among 1000 other variables like I123423, I423343412, I52345345, I52345234534, I345345453452345, I23453456q4356w4565467e3567, i5345345345345345345, i545345w3234423234234234, i43423542345634632465, I332wersdssdfsdfsdfsdf, Ir4233423424234, I342342342345_1234, I23423434563456235423452, I2431234234234234, I423434234234. My modules have many pages of declarations only computer search can find anything there.

We have better things to do as /undef and /73 will find us more then just stupid typos without even thinking about all of the above

Calm down, Dan! You don't have to - well, at least not currently. But if you wanted to, you don't have to do it all at once. And if the Fortran Committee dictate, maybe you'll have to. As for me, I'll never use IMPLICIT NONE. It's snake oil. Fortunately, my needs will have expired long before the Fortran Committee get round to outlawing Fortran as we know it and replacing the source form with cascading columns of mixed Hiragana, Katakana and Kanji,only in green!