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 

Extra checking in Clearwin
Goto page 1, 2  Next
 
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: 2210
Location: South Pole, Antarctica

PostPosted: Sun Apr 19, 2020 2:36 am    Post subject: Extra checking in Clearwin Reply with quote

In the 8.62 I see nice new feature of extra checking for undefined variables in Clearwin. If something is not initialized we now get such messages

I understand that this is still not the final production version, but is it possible to display either which line has a problem or better also add one more button "Go do error" and it will be shown in debugger. Is this doable?

Currently what is going on is that the code goes to the last statement of Clearwin Fortran text without any warnings, swallowing the things without the hiccups and at the last its line only when GUI is jumping into the screen all these messages start to appear one by one without saying where the error occurs.

If it is not easily doable of course the current method is still way better than what we had before when such errors were not reported. When the user will debug he then will answer No and will look in the Fortran source text window in Debugger at all variables on the subject of forgotten undefined variables and will find the problem. But the difficulty is when GUI is very large, and actually there are many of them, then finding right place with undefined variable is like searching for the lost needle in the forest
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Apr 19, 2020 8:01 am    Post subject: Reply with quote

If you abort you should get a traceback with line numbers. Is that not the case?
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Mon Apr 20, 2020 5:56 am    Post subject: Reply with quote

Unfortunately no, when you abort on the messages shown above even if you have multiple errors in the same piece of Clearwin text, there is no traceback, the SDBG cursor always stays on last line of the execusion of GUI.

The only you can do is just to manually sniff with the mouse popup bubbles all the variables on the subject of finding undefined variables.

As I understand, the Clearwin operates in this specific case with checking undefined variables not on line by line basis (like all Fortran compilers/debuggers checking for bugs) but it initially loads the whole Clearwin text and then when displays GUI it checks undefined variables are or not
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Apr 20, 2020 8:12 am    Post subject: Reply with quote

I now understand the situation.

The check can only be undertaken after the window has been created and when the data is first read in. At this point, the usual "continuation number" (the number of ampersands used in a sequence of winio@ statements) is no longer available.

Perhaps ClearWin+ could store this number as part of the %rf data. In practice a given window will have a limited number of %rf values and it should be relatively easy to work out which one is undefined from the values displayed in the debugger.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Tue Apr 21, 2020 4:21 am    Post subject: Reply with quote

OK, here is my first experience with undefined variable error which compiler found in %rf in the 5000 lines subroutine.

I found this error on the line 3100 after looking through each and every line for two hours. Things are that I have 500 %rf there. This is totally impractical. One more such bug and the user will refuse to find it manually again. Imagine Linux code with its 100 million lines got the message that it has the error somewhere Smile

So my request to you guys is to please modify the bug reporting differently and find the way to tell which exactly line has an error. Because currently compiler essentially tells user: "I found the undefined variable error in %rf somewhere in the code higher than this line"

Another useful feature which might help here is to add to the debugger missing for years Search for variables or just for any arbitrary text. That would speed up this search too. Currently SDBG searches only for subroutines

Also have I missed the FTN95 key which if used at compile time will create and error if undefined variable is found. Before temporally I used "/set_error_level error 298" for that as an equivalent of "implicit none" checking for undefined variables. I think this approach worked OK so far but looks like it is failing if undefined variables are arrays.

As one more suggestion would be great if SDBG highlighted in red all undefined variables. At the end, searching for undefined variables was one of the strongest features of this compiler from its start

UPDATE. Oh, no, no more line-by-line manual inspection of almost each and every line of 5000 lines code! After finding two errors in %rf, the compiler found two more uninitialized variables in %rd Sad . Looks like this method of reporting of undefined variables is impractical. One minutes job requires the whole day of hell

One more defect: compiler is continuing to hide variables declared as parameters. When you hover the mouse over such variables, SDBG shows no information at all.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

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

Dan

There is too much detail here for me to deal with but here are some pointers.

1) I don't understand why you need to search through the whole of your code. I would expect you to be able to use the traceback to find the current window and winio@ list.

2) For a search facility, why not use an IDE (like Plato) in parallel with SDBG/SDBG64, assuming you don't want to (or can't) run the debuggers directly from Plato.

3) Undefined variables are detected at runtime when using /UNDEF and similar options on the command line. Warning 298 only provides information that can be detected at compile time not at runtime which is the whole point of /UNDEF checking.

4) To get the debugger to show parameters you need /FULL_DEBUG on the FTN95 command line. This is not implied by other debugging options such as /UNDEF.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Tue Apr 21, 2020 11:36 pm    Post subject: Reply with quote

What is "the traceback to find the current window and winio@ list?"

Current window is found and opened automatically when you invoke debugger at the time the window above appears. Do you call the list of variables winio@ list? If yes, then there are a hell lot of variables there. Some are used for different purposes than winio@ and due to hell of them in total there and not so clear purpose of them (and many are undefined too but not used with winio@) I just found a bit less stressful to go trough the entire source code. For each occurrence of error you will need to go through the whole list of variables or the source text again !

About Plato: what I do not understand because just tried it few days back - does Plato use the same debugger SDBG64 we all know or it has its own debugger (or both at your choice)? If IDE is one thing and Debugger is separate thing in separate window then the use of IDE for se5arching of %rf, %rd or %rb occurrences in the text is not different then use of SDBG and my own editor - this jump 3000 times from one windo to another is very nonconvenient. If Plato IDE Fortran source and own debugger share the same window and we can use Search of variables than yes, this might help and I may start using Plato.

In summary, this new addition to search for UNDEFs is welcomed option but please think about modifying it to tell exactly where error is. Currently it only useful if GUI is tiny with just few potential places for error. When Clearwin text is 1000s of Fortran lines this will be very tough to find the offending place.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 22, 2020 8:13 am    Post subject: Reply with quote

I have thought of a new option to help tracing undefined values for %rf etc. and will aim to provide this shortly.

Regarding Plato/SDBG64, Plato has an option (in the Settings dialog) to integrate Plato with SDBG64. For the 64 bit Plato, the Plato executable contains a copy of the code for the SDBG64 executable. When debugging, Plato presents much of the output from the debugger in its own windows rather than use the debugger's own windows. This works well at least when debugging simple programs. There is an overhead when copying information from the debugger code to Plato windows and this could cause a delayed response when debugging major projects.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Apr 22, 2020 9:38 am    Post subject: Reply with quote

A new checking option is now available to detect undefined variables with %rf etc.. This is included in new DLLs that can be downloaded via the following link...

https://www.dropbox.com/s/0brs3u14m5z5hqe/newDLLs44.zip?dl=0

Here is a simple demo program...

Code:
winapp
options(undef)
program main
use clrwin
call clearwin_option@("undef")
iw = winio@("%rd", n)
end


Note the options(undef) is the same as using /undef on the FTN95 command line and should only be used whilst testing.

When clearwin_option@("undef") is not called the testing for undefined values takes place when the variable is accessed.

When clearwin_option@("undef") is present the testing for undefined values takes place when the %rf code is processed.

With this new option, when you abort you will get line numbers in the traceback. For the sample code you get the error message together with

Quote:
Within file prog.exe
in MAIN in line 6, at address 7c
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Tue May 05, 2020 10:46 pm    Post subject: Reply with quote

Thanks, had only now the time to check this option. It is good option, it works with %rd, %rb but does not yet with %rf?
Code:
winapp
options(undef)
program main
use clrwin
real*8 an
call clearwin_option@("undef")
iw = winio@("%rf", an)
end
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed May 06, 2020 8:21 am    Post subject: Reply with quote

It works OK for me.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Thu May 07, 2020 1:16 am    Post subject: Reply with quote

It dos not report the error but just straight shows the value 1e-305 in the window
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu May 07, 2020 7:45 am    Post subject: Reply with quote

I tested it for 64 bits. For some unknown reason it does not work at the moment for 32 bits. I will check it out.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Thu May 07, 2020 11:37 am    Post subject: Reply with quote

This has now been fixed for the next release of salflibc.dll.
Back to top
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Fri May 08, 2020 2:19 am    Post subject: Reply with quote

I haven't even noticed that I used 32bit for test. For everything now I only use 64bit and recommend finally all to switch to 64
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
Goto page 1, 2  Next
Page 1 of 2

 
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