|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Jun 05, 2015 10:53 am Post subject: Attributes of file |
|
|
Which program can look at changes in attributes of file you dropped (time stamp etc) ?
files@ seems does not work with files not in current dir (files having long path) |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Jun 05, 2015 11:07 am Post subject: |
|
|
Dan,
Could you explain a bit more ?
Assuming you are having problems with the array dimensions, I use files8@ and find it very effective as:
Code: | call files8@ (local_dir, & ! C320 directory to scan
!4k call files@ (local_dir, & ! C320 directory to scan
n, & ! I2 number of entries found
nmax, & ! I2 capacity of buffers
file_name(next), & ! C320 tree name of files found
attr(next), & ! I2 DOS attributes
date(next), & ! I2 DOS date format
time(next), & ! I2 DOS time format
file_size(next) ) ! R8 File size in bytes
|
For my use, the tree name array is basically :
character file_name(32000)*320
As the number of entries (nmax) is I*2, there is a limit of 32,000 files to recover from a directory.
The tree name length of 320 is what has suited my disk use. This is 10mb, so character file_name(32000)*1024 should work. If you are using this in a utility routine, you could make it allocatable, then deallocate when no longer needed.
I have a disk scanning program that I apply date filters and sometimes file extension filters to list all files in a tree or on the disk. The only problem I have is when I don't have read access to some directories, typically network directories.
It has been a very useful utility, especially for finding hidden files, especially in hidden directories.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Jun 05, 2015 9:51 pm Post subject: |
|
|
Thanks John. Fun is that I use files@ for two decades and it is OK in a dozen of different places in many different variants. They all had problem when debugged mostly because i was missing those absurd integer*2 definitions but they all work now.
I do not know where the hell the error is here. The compiler crashes 100 times per day with other large programs though that's kind of normal since i'm permanently hitting 3-4 GB limit and stupid stack size (which moron invented it?). But the fact i can not debug 10 lines program after losing a half a day is mind torturing. I do not see some simple stupid error - this is also normal, but look what the compiler is doing! I made a demo code, may be you (others are welcome too) will tell me why the heck
1) with "ftn95 aaa.f95 /link /debug" compilation i get "Bad request for stack memory" (!!!)
2)with "ftn95 aaa.f95 /link /debug /undef" debugger does not find undefined variable even if uncommenting the line !> goto 10000 saying that the error is in line 7 (!!!). Line 7 is "end program" statement
3) the files8@ does not find (shows zero) the same file which was just dropped (!!!). For that uncomment "goto 10000"
Code: |
winapp
integer, external :: cbdropped
i=winio@('%ww%es%si! Drop file here %ff&')
i=winio@('%dr&', cbdropped)
i=winio@('%pv%50.20cw[hscroll,vscroll]%ff&', 0)
i=winio@('%cn%bt[OK]')
End program
integer function cbdropped ()
use clrwin
integer, parameter :: MaxLengFileNames=128 ! 320
character*(MaxLengOfFileNames) textsample, FileNameOfDroppedDataFor3D_GL02
integer*2 maxNumbOfFilesInDir, NumbOfFilesInDir
parameter (maxNumbOfFilesInDir = 100)
character*(MaxLengOfFileNames) FILES_InDir(maxNumbOfFilesInDir)
integer*2 ATTR_files(maxNumbOfFilesInDir),date_files(maxNumbOfFilesInDir), time_files(maxNumbOfFilesInDir)
real*8 file_size(maxNumbOfFilesInDir)
!> goto 10000
FileNameOfDroppedDataFor3D_GL02 = clearwin_string@('DROPPED_FILE')
write(*,*) 'FileNameOfDroppedDataFor3D_GL02=', FileNameOfDroppedDataFor3D_GL02
textsample = FileNameOfDroppedDataFor3D_GL02
call files8@ (textsample, NumbOfFilesInDir, maxNumbOfFilesInDir, FILES_InDir, ATTR_files, date_files, time_files, file_size)
print*, 'NumbOfFilesInDir=', NumbOfFilesInDir ! , 'textsample, NumbFiles_InDir ', textsample, NumbFiles_InDir
10000 cbdropped = 2
end function |
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Jun 05, 2015 11:23 pm Post subject: |
|
|
Adding IMPLICIT NONE to your subroutine is probably more effective in finding the bug in your program than IMPRECATE ALL.
Adding IMPLICIT NONE and compiling would tell you that MaxLengFileNames has a value, whereas MaxLengOfFileNames does not; one of these is probably a mistyped name. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Jun 06, 2015 12:35 am Post subject: |
|
|
Thanks mecej4. This solved the problem. But the debugger with /undef should find this error and it did not ! Never or rarely happens. Is this only my debugger, by the way? Please confirm.
Both methods probably have to be used, but the /undef is way more effective in finding logical swists of the large codes then implicit none and is more and more used in other compilers. That was discussed couple decades ago with good examples. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jun 06, 2015 2:06 am Post subject: |
|
|
The ways in which /undef and /debug work are quite different. You should perhaps regard them as complementary rather than alternative ways of finding bugs. Nor do /debug and /undef work as any kind of team.
The /undef option (and similar options such as /check) plants extra code into the EXE to perform checks in addition to doing the calculations required by the Fortran source. These checks happen on every line of code that is visited, without needing any interaction from you. Often, these checks slow down the execution considerably.
The /debug option, on the other hand, places the responsibility on you to watch for and catch errors, but does facilitate your detective work by translating code addresses to line numbers and highlighting the corresponding source line in the source window of the debugger, and by translating data addresses to active variable names and showing the values of those variables in human-readable decimal form. In some ways, the name "debugger" is a misnomer. If you do not have a suspicion as to where the bug is located, or if you have no idea of which values of variables are reasonable, watching the program run inside the debugger is not necessarily going to help you find any bugs, let alone de-bug the program.
The problem with both /debug and /undef is that they are of little help unless all routines contributing to the entire program, including library routines and the Fortran runtime, were also compiled with the same options.
Let me illustrate these points. Consider this program, in which a variable is used without being defined.
Code: | program tst
integer a
call sub(a)
print *,a
end program
subroutine sub(i)
integer i
i=2*i+5
return
end
|
The variable 'a' should have been defined before line-3. Indeed, a compiler that performs a thorough static analysis of the code can tell you so. If you compile with /undef, the error is detected not on line-3, but on line-9, where the undefined variable is used. Now suppose that the subroutine is in a library, which was compiled without /undef. To simulate this, break out the main and the subroutine into separate files. Compile the main program with /undef and compile the subroutine without /undef. If you now link and run, you will not see the program abort, but you get a garbage result printed out.
Something similar happened in your code, when you had two variables with slightly different names, assigned a value to one and used the other as an argument to a subroutine.
I think that FTN95 falls a bit short when it only says
Code: | 0014) character*(MaxLengOfFileNames) textsample, FileNameOfDroppedDataFor3D_GL02
WARNING - Variable MAXLENGOFFILENAMES has been used without being given an initial value |
whereas it should have rejected the declaration CHARACTER*(<an undeclared integer variable name>) because that integer character length parameter should have been a constant or a subroutine dummy argument. In contrast, another Fortran compiler says this about the same code:
Code: | Warning: cbd1.f90, line 3: Unused PARAMETER MAXLENGFILENAMES
Error: cbd1.f90, line 5: MAXLENGOFFILENAMES is not permitted in a specification expression
|
Last edited by mecej4 on Sat Jun 06, 2015 1:22 pm; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Jun 06, 2015 4:52 am Post subject: |
|
|
I agree that /debug is mis-named, but I find it a very useful option. It probably should be called /trace_back.
I always use /ERROR_NUMBERS and /IMPLICIT_NONE as it at least forces me to recognise what local variables I am using and when combined with the unused variable warning, picks up my many typing errors. Dan, you should try to introduce /implicit_none in your testing and then the compiler might crashe only 10 times per day.
With FTN95, errors where the memory is running out are poorly reported. More use of ALLOCATE for temporary arrays, and releasing them when not needed can help memory availability a lot, although there is more planning required.
We need an option to put the stack and heap at address 3.8gb! (definitely a smarter SLINK)
The difference between /undef and /check often needs to be better understood, as they pick up different errors. It can be surprising how array subscripts that =0 can remain as bugs in code for years, especially where the logic may later exclude these cases.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Jun 06, 2015 9:03 am Post subject: |
|
|
Well, despite this damn bug ... I will probably never start using "implicit none" . That is making long code even longer. That is like adding telephone book of names and addresses in front of programs and subprograms. The way to go is i think to make compiler/debugger better and better.
The error like this should be reported by the compiler. Plus the debugger must report parameters in all debugger's windows (noticed it does not? WHY?) and also check them with /undef (why it did not???)
After fixing this compiler or debugger bug or "feature" the only useful things about "implicit none" is that if you hit 72/132 limit it will report an error. But that is no longer advantage after Paul implemented an option /no_truncate we were advocating here. The /undef will also tell you about truncation with large probability
So, in short, I am too lazy (or almost incapable spending more and more time, now 14-16 hours/day, in front of monitors) to declare variables in front of the code and permanently go far up and deep down (programs are long and consist of many files) to find what the variable it is and how it is declared. Besides I like i-to-n as integer by default because that is also telling me what the variable is for. The code has to be verbose and self-explaining where it is written not somewhere in different file many miles away
Yes, this compiler crashes a lot i suspect due to very strict checking policy on underflow and not great stability of Clearwin Windows-related code. The latter one is not completely this compiler's fault i suspect. Bad genetics of unfamous FTN90 is also probably not completely pesticided. If Salford C was used then this also is not a plus. But I think compiler developers have to make no slightest checking of underflow as a default. And make sure underflow does not slow down the code too. As to stack related crashes, hopefully 64bit compiler will make stack obsolete.
Debugger still scares people with its primitive look and feel and even more when it falls into assembler. If you experienced enough you do not care and keep using debugger as if nothing happened but I am sure novices are scared to death and turn away from this compiler since only 1/1000 probably will ever use the assembler. Debugger should never show the assembler windows without millions of excuses to the programmer. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jun 06, 2015 1:55 pm Post subject: Re: |
|
|
DanRRight wrote: | Debugger should never show the assembler windows without millions of excuses to the programmer. | On the other hand, there are cases where errors in the compiled code can be next to impossible to detect without being able to look at the compiled code in a disassembly window. In these cases, we want to give the programmer a way to request and see the disassembly -- F11 does that. If you take that tool away, you prevent others from doing what they may want to do. For example, I might not have found the bug reported in http://forums.silverfrost.com/viewtopic.php?t=3075 if I could not see the disassembly while stepping through the code.
The only situation when SDBG shows assembly without being asked to do so is when a breakpoint occurs inside code that was compiled without /DEBUG. Silverfrost could provide a configurable flag in SDB that lets the user specify "do not show disassembly unless asked for".
There is yet one more technique for finding bugs caused by misspelled variable names -- generate and examine the old-fashioned cross-reference list. If, with the source file named cbd.f90, you do
Code: | ftn95 cbd.f90 /XREF
findstr /B "[A-Z]" cbd.XRF |
you see, among other lines, the following:
Code: | INTEGER, PARAMETER :: MAXLENGFILENAMES
INTEGER :: MAXLENGOFFILENAMES |
Last edited by mecej4 on Sat Jun 06, 2015 5:23 pm; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Jun 06, 2015 2:42 pm Post subject: |
|
|
Dan,
If you have a " telephone book of names " then you are doing well to find any bugs. I find by grouping variables by modules or included common blocks, the variable management is easier to control. Then you only need to consider the local variables in a routine, and if this is still at telephone book size, then your routine must be too complex.
I hope my example of using files@ might have helped.
John |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Jun 06, 2015 3:25 pm Post subject: |
|
|
Like Dan I am not a fan of IMPLICIT NONE, as I find it more valuable to know at a glance the type of a variable than to use the facility to detect misspelled names – perhaps because I am of the generation that learned to spell partly with the aid of corporal punishment, and I can read these errors (caused, I might add, usually by autocorrect, or the deletion of a highlighted letter when you type something else). Indeed, I only ever used two names that wilfully denied the implicit typing convention. One of them, LAMDA, should have been real, but I defied the Backus convention as the compiler used a maximum length of 5 letters for names, and it fitted oh so nicely. That blasted thing caused me grief for decades.
Indeed, it seems to me a little perverse that a facility for forcing the programmer to declare the type of a variable explicitly should have the dual use of indicating whether it is used uninitialized. That seems to me to be the role of something else – XREF for instance. The dual use business bothers me a lot: MODULEs for instance, as a replacement for INCLUDE as well as grouping routines and altering the very simple scoping rules of traditional FORTRAN.
I have very guilty pleasure, and that is every time an error in the compiler is found for some obscure feature of Fortran 90/95/etc, I have a warm glow inside. My programming style was locked in so very long ago that these matters rarely bother me.
Lots of naming, scoping and suchlike errors can be kept to a minimum by keeping routines simple, using as few variables as necessary, and if Dan must use NumberOfSomethingOrOther type names, then using underscores does make them easier to see errors in, as in Number_of_Something_or_Other. Lengthy meaningful names are all very well and good, but one is more likely to see if 'Cardiff' is spelt correctly than 'Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch'. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Jun 06, 2015 11:08 pm Post subject: |
|
|
There is no compulsion to use IMPLICIT NONE. Given Dan's aversion to declaring variables explicitly, and assuming that he is unwilling to enroll in a school that still uses corporal punishment in its curriculum, such as that which Eddie fondly remembers, I'd suggest using the FTN95 option /IM on Dan's unmodified sources.
Just as with the /XREF option, the output with /IM will be verbose and mostly uninteresting, which is why this output should be passed through a filter such as FINDSTR or GREP, and possibly SORT. Of course, if the search criteria are too tight, the bug (misspelled variable names) will slip through unnoticed, so different search patterns will have to be tried.
I do think that Dan is a bit unreasonable in his insistence that the compiler should have found the error. With implicit typing, the program contains valid Fortran, and most of us would want the compiler to process whatever code is given to it. The code may not do what the author intended, perhaps, but we do not expect clairvoyance from a mere compiler.
In a way, the situation is one of "pay now (by writing explicit declarations and correcting mistyped variable names) or pay later (as a result of incorrect program output)". |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sun Jun 07, 2015 9:30 am Post subject: |
|
|
let's conclude that here definitely was a compiler/debugger bug, and i hope Paul logged it for fixing.
Thanks all for help, suggestions and ideas. I learned about new function files8@. After running this code
http://forums.silverfrost.com/viewtopic.php?t=2491&start=15
with the search word 'files@' and then 'files8@' i found 30 times use of files@ and zero files8@, so indeed i did not forget -i did not know about it. Brief look showed that files8@ is missing in Help file.
Interesting was idea of using /XREF, which i may use for something in the future. For my bug searches it is unfortunately useless since it generated me 49 MB (!) of crossreferences.
And yes, after trying many ways of making text more readable I use underscores for clarity more often. Recommend it too. As well as long names for text self-explanation.
Discussion convinced me even more that declarations of everything due to using "implicit none" will be obsolete in the future, the compiler will do the work perfectly without that hemorrhaging annoyance.
How this bug could be hidden for 25 years is beyond imaginable. I think developers must issue the following warning "The condition of using this compiler free of charge for personal use is that you will get back to us with at last few reports for bug fixes and suggestions for improvement" after fixing my "french" of course. Or advertize it 10 times on the internet, more users - less bugs. Users have to be way more active reporting anything which might improve this great compiler.
Last edited by DanRRight on Sun Jun 07, 2015 7:24 pm; edited 2 times in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Jun 07, 2015 12:09 pm Post subject: |
|
|
For me, /UNDEF would be better than /IM |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sun Jun 07, 2015 1:34 pm Post subject: Re: |
|
|
DanRRight wrote: | Brief look showed that files8@ is missing in Help file. |
See the last line under "Description" at http://www.silverfrost.com/ftn95-help/file_man/h_filesa.aspx . You will find the same information by searching for "files8@" in the FTN95 help file. |
|
Back to top |
|
|
|
|
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
|