View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Sun Feb 11, 2018 11:44 am Post subject: 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
Code: | 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 :
Code: | 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?
Last edited by DanRRight on Mon Feb 12, 2018 4:06 am; edited 2 times in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sun Feb 11, 2018 11:30 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Feb 12, 2018 4:11 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Feb 12, 2018 10:33 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Feb 13, 2018 2:29 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Feb 13, 2018 10:21 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Feb 13, 2018 11:59 am Post subject: |
|
|
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 ? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 447 Location: Manchester
|
Posted: Tue Feb 13, 2018 1:22 pm Post subject: |
|
|
That is just weird! |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Feb 13, 2018 1:36 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1891
|
Posted: Tue Feb 13, 2018 2:06 pm Post subject: Re: |
|
|
DanRRight wrote: | 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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Feb 13, 2018 2:12 pm Post subject: |
|
|
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) |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Tue Feb 13, 2018 7:53 pm Post subject: |
|
|
Dan
Code: | 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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Tue Feb 13, 2018 10:27 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Wed Feb 14, 2018 2:58 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Wed Feb 14, 2018 10:09 pm Post subject: |
|
|
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?).
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
Last edited by DanRRight on Thu Feb 15, 2018 3:16 pm; edited 2 times in total |
|
Back to top |
|
|
|