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 

Attributes of file
Goto page Previous  1, 2, 3, 4
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 941

PostPosted: Thu Jul 16, 2015 2:08 pm    Post subject: Reply with quote

Ah, now I see -- had you said something with "allocatable array arguments" I would have recognized the topic sooner. Rather than relying on nonstandard allocation routines or compiler options that control how allocation is done, I think that FTN95 should consider implementing TR-15581 (see ftp://ftp.nag.co.uk/sc22wg5/N1351-N1400/N1379.pdf ). This TR filled a long felt need in Fortran-95 without requiring full F2003 implementation. The case for adding the TR is stated well in the introduction of the TR by John Reid:
Quote:
There are many situations when programming in Fortran where it is necessary to allocate and deallocate arrays of variable size but the full power of pointer arrays is unnecessary and undesirable. In such situations the abilities of a pointer array to alias other arrays and to have non-unit (and variable at execution time) strides are unnecessary, and they are undesirable because this limits optimization, increases the complexity of the program, and increases the likelihood of memory leakage. The ALLOCATABLE attribute solves this problem but can currently only be used for locally stored arrays, a very significant limitation. The most pressing need is for this to be extended to array components; without allocatable array components it is overwhelmingly difficult to create opaque data types with a size that varies at runtime without serious performance penalties and memory leaks.

A major reason for extending the ALLOCATABLE attribute to include dummy arguments and function results is to avoid introducing further irregularities into the language. Furthermore, allocatable dummy arguments improve the ability to hide inessential details during problem decomposition by allowing the allocation and deallocation to occur in called subprograms, which is often the most natural position. Allocatable function results ease the task of creating array functions whose shape is not determined initially on function entry, without negatively mpacting performance.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jul 17, 2015 12:00 pm    Post subject: Reply with quote

Quote:
long felt need


By whom, and for how long?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 941

PostPosted: Fri Jul 17, 2015 1:35 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
Quote:
long felt need


By whom, and for how long?

There have been many articles written about this -- in published books and journal articles, and postings in news:comp.lang.fortran . Fortran 90 had flaws in the way that it prescribed the role and behavior pointers, and this was rectified in Fortran 95. Fortran 95 still forces you to do most of the work of memory management in your own code, and it was still problematic to clean up user-allocated memory after an error.

A great example of the benefits of using allocatable arguments could be seen in the evolution of the HSL Galahad package (http://www.galahad.rl.ac.uk/ ). See, for example, the documented problems in the release notes of the earlier versions.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Fri Jul 17, 2015 2:18 pm    Post subject: Reply with quote

Mecej4,

Not an answer, as the cited website does not (as far as I can see) state that it is a need, nor for how long. I can see that it might be a very real need for some people, and the need may have been apparent for some time, but Reid was a co-author of Metcalf's in the book on Fortran 8X (90 - where X=10, I suppose), and the standards committee have had at least 4 goes (90, 95, 2003 and 2008) to get it right and haven't in 3 decades, so their judgement is rather questionable. (He's on the committee for 2015, so maybe he'll get it right at long last).

I can see, immediately, that allocatable memory solves some problems straight away, for example, when your program has a multiple document form, and in John's case, because the memory model of Windows has deficiencies for what he wants to do. On the other hand, plenty of real world problems are usefully solvable on a heck of a lot less memory than you get even in a cheap PC.

But, all this 'angels on a pinhead' stuff pales into insignificance against the need for a graphics standard and the tools for writing GUIs, which is where Clearwin+ is so brilliant, but it does tie you to Windows.

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



Joined: 31 Oct 2006
Posts: 941

PostPosted: Fri Jul 17, 2015 3:39 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
... the standards committee have had at least 4 goes (90, 95, 2003 and 2008) to get it right and haven't in 3 decades, so their judgement is rather questionable.


I do not agree with that conclusion, and do not want to discuss the matter here. There is a procedure that you can follow if you wish to send comments or put questions to the Fortran standards committees. John Campbell has some experience with that procedure, but I don't.

Quote:

I can see, immediately, that allocatable memory solves some problems


That is not the topic of my response (Thu Jul 16, 2015) in this thread. The ALLOCATE statement (along with its friends DEALLOCATE, ALLOCATED(),..) was available in Fortran 90 and even some F77 compilers provided it as an extension in the 1980s. The topic was allocatable dummy arguments, which Silverfrost FTN95 does not have and which I suggested as a welcome addition.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jul 18, 2015 12:48 am    Post subject: Reply with quote

The advantages of /undef are very hidden from the eyes. Those with large codes who actively expand them adding new and new features will mostly see them. You change something just a tiny bit and -- prepare to pull your last hairs - that typically causes chain reaction of multiple errors you did not expect. That how it works and why i say it is 1000 more valuable then static implicit none. Implicit none also gets very strong negative value slowing speed of debugging. I debug and search for the errors 100x more times then i write the code. Just wasted 3 days on elementary stuff i already have done 2-3 times before...despite of using /undef. Few times i was searching bugs for a month. One thing i can not find till today but that's in GUI - want to try for $150 if you solve that puzzle ?

Now i write the code and think about its permanent validation and control. For each subroutine seems it will be needed to write several ones which will check the results on consistency. And will help quickly find the bug if it will be introduced

Large codes eventually die because require too much time for managing them.
Authors get tired to fix and expand them knowing that there exist some unexplained behavior caused most probably by the hidden bugs.

I wrote here how with /undef we found a gazillion of bugs in someone's 150 or 200k lines atomic code which after a decades of "improvements" literally stopped to produce anything reasonable. And /undef still is periodically used to catch new bugs. It by the way heavily used implicit none Smile

Some errors would be harder to find without graphics and GUI - i agree with Eddie - so much of data is used and so complex codes become. I do not know how to include them into Standard since that is formally not a pure Fortran but something has to be eventually done. May be this compiler will be a good example for that in future. Without easy and a LOT of graphics, without advantages of self-explanatory and verbose GUI i would stopped my crazy fight with the bugs long long ago.

And I will not buy anyone's large code without passing /undef test. By the way may be Silverfrost must implement and use /undef in their C compiler which makes FTN95 if they have not done that.

Was thinking last days about a suggestion to Silverfrost to add the feature which will make needed variable undefined dynamically - that will be useful for debugging repetitive or iterative codes

I am not trying to convince everyone in using anything i use. Specifically /undef which i find genial, the #1 in value feature of this debugger. I tried many years ago, it rarely works. Few compilers though added them eventually.
I am sure some people will find that useful to catch a deep stinking roach or two.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 941

PostPosted: Sat Jul 18, 2015 2:02 pm    Post subject: Re: Reply with quote

DanRRight wrote:

I am not trying to convince everyone in using anything i use.

Sorry, I am not convinced that you are not. Especially because I see you asking that some compiler option be made a default, when it is so easy for you to make that personal choice for yourself in your ftn95.cfg file.

Quote:

Specifically /undef which i find <...> the #1 in value feature of this debugger.

You are crediting the debugger with something that the compiler properly deserves credit for. All that the debugger does is to replace special bit patterns -- patterns that are reserved by the compiler to represent undefined values of integer, real, ..., types -- with the string 'UNDEFINED' in its variable displays. In fact, /undef works fine even when the debugger is not used at all.

The Control Data mainframes did something similar to trap indefinite and infinite real values in the late sixties and then in the seventies. See

http://gsmall.us/Computing/CDC6400/Archive/CDC-6600-R-M_files/CDC-6600-R-M-3-18a.gif

Most of us may find the representations of +0 and -0 somewhat surprising. The CDC used 1-s complement rather than the 2-s complement convention used in today's microprocessors.

On those machines, input was mostly by card deck or paper tape, and output by line printer -- of course all character based, no GUI.


Last edited by mecej4 on Sat Jul 18, 2015 7:43 pm; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jul 18, 2015 6:31 pm    Post subject: Reply with quote

Mecej4, I am not convincing anyone, i just suggest that if you have large code -- try to use /undef. I will be happy to see your face and swearing "Oh, nooooo, WT@#$%!!!"

BTW, when I did not succeed, on any programming forums, anyone, who uses VI editor, to change it, i changed my views on humanity Smile
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 941

PostPosted: Sat Jul 18, 2015 7:00 pm    Post subject: Re: Reply with quote

DanRRight wrote:
i just suggest that if you have large code -- try to use /undef.


I do use /undef regularly. But for /undef, /check and its fast compilation, I would probably have little use for FTN95. For me, however, /undef is one among many tools, suited for some purposes and irrelevant for others. I understand what it does, and I am happy with what it does. However, I don't think of it as a means of salvation.

Quote:
I will be happy to see your face and swearing "Oh, nooooo, T@#$%!!!"


I am afraid you'll have to be content with using a mirror to entertain yourself. I feel no urge to swear, although you do tempt me sometimes, and I don't anthropomorphize computer programs that way. Not every human being is a copy of DanRRight, please note. With the programs that I work with (mostly from Netlib and similar sources), it is quite normal to make a test run with known results with default compiler options, and only then make a run with /undef just as a final check. It is expected that nothing new will turn up, and that is what happens most of the time.

Quote:
BTW, when I did not succeed, on any programming forums, anyone, who uses VI editor, to change it


Ed and vi/vim are tools that I use quite often. Perhaps you should consider leaving people alone -- given that your bugs need your full time attention and TLC, and you probably seek to outlive your bugs. Please see my back-of-the-envelope calculation (in http://forums.silverfrost.com/viewtopic.php?t=3126) to assess your chances of succeeding.

Perhaps this thread has reached a point where it has become tiresome to other forum readers. Please, let us close it here.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jul 18, 2015 7:59 pm    Post subject: Reply with quote

mecej4, this is public forum, open 24/7 for everyone to come and leave, thanks for participation, happy VI-ing, come again in good and even bad mood, we will be glad to hear from you.

As to others, we will continue. I'd recommend to all this program i received from JohnCampbell few days back on file attributes. Most useful about it to me is deciphering of encoded damn DOS attributes of files which produces FILES@.

Addition: I just noticed no IMPLICIT NONE in it. You do not have to if you like them, but, many thanks, John Smile

Code:
winapp
 integer, external :: cbdropped
 integer i

 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*4, parameter :: MaxLengOfFileNames  = 128 ! 320
   integer*2, parameter :: maxNumbOfFilesInDir = 100 ! 32000

   character*(MaxLengOfFileNames) :: textsample
   character*(MaxLengOfFileNames) :: FileNameOfDroppedDataFor3D_GL02
   character*(MaxLengOfFileNames) :: FILES_InDir(maxNumbOfFilesInDir)
!
   integer*2 NumbOfFilesInDir
   integer*2 ATTR_files(maxNumbOfFilesInDir)
   integer*2 date_files(maxNumbOfFilesInDir)
   integer*2 time_files(maxNumbOfFilesInDir)
   real*8    file_size(maxNumbOfFilesInDir)
!
   character dos_date*9, dos_time*8, datest*9, timest*8, dos_date_time*16, dttest*16
 !>    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)
!
     datest = dos_date (date_files(1))
     timest = dos_time (time_files(1))
     dttest = dos_date_time ( date_files(1), time_files(1), .true. )
!
     print*, 'NumbOfFilesInDir=', NumbOfFilesInDir ! , 'textsample, NumbFiles_InDir ', textsample, NumbFiles_InDir
     print*, ' name=', trim(FILES_InDir(1))
     print*, ' attr=', attr_files(1), ' ', dttest
     print*, ' date=', date_files(1), ' ', datest
     print*, ' time=', time_files(1), ' ', timest
     print*, ' size=', int(file_size(1))

 10000 cbdropped = 2
 end function


Last edited by DanRRight on Sat Jul 18, 2015 11:28 pm; edited 6 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jul 18, 2015 7:59 pm    Post subject: Reply with quote

Code:
      character*9 function dos_date (yymmdd)
!
      integer*2 yymmdd
!
      character temp*9, label(0:12)*3
      integer*2 yy,mm,dd
      intrinsic mod
      data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',     &
                   'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' /
!
!     yyyyyyy mmmm ddddd
      dd = iand (yymmdd,31)             ! 0-31
      mm = iand (ishft(yymmdd,-5),15)   ! 0-15
      yy = ishft (yymmdd,-9)            ! 0-127
!
      yy = mod (yy+1980,100)
!
      write (temp,1001) dd,label(mm),yy
 1001 format (i2.2,'-',a3,'-',i2.2)
      dos_date = temp
      return
      end
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Jul 18, 2015 8:01 pm    Post subject: Reply with quote

Code:
      character*16 function dos_date_time (yymmdd, hhmmss, EST)
!
!   routine to return the date and time as a text string
!   to adjust time zone, the date can change > day > month > year change
!
      integer*2 yymmdd, hhmmss
      logical*4 est
!
      character temp*16, label(0:12)*3
      integer*2 max_day(0:12), yy,mm,dd, hh,mi,ss
      integer*4 values(8), dm
      intrinsic mod, iand, ishft
      data label / '___', 'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',     &
                   'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec' /
      data max_day /   0,    31,    28,    31,    30,    31,    30,     &
                      31,    31,    30,    31,    30,    31 /
!
!  use ishft to account for -ve hhmmss
!
!     yyyyyyy mmmm ddddd
      dd = iand (yymmdd,31)             ! 0-31
      mm = iand (ishft(yymmdd,-5),15)   ! 0-15
      yy = ishft (yymmdd,-9)            ! 0-127  ( 1980 to 2107 )
!
!     hhhhh mmmmmm sssss
      ss = iand (hhmmss,31)*2           ! 0-31
      mi = iand (ishft(hhmmss, -5),63)  ! 0-63
      hh = iand (ishft(hhmmss,-11),31)  ! 0-31
!
      if ( .not. EST ) goto 100
!
!   Adjust for time zone
!     Note : time zone adjustment "dm" is for now and not when file was created
!     Daylight saving adjustment would be incorrect
!
      max_day(2) = 28
      if (mod(yy,4) == 0) max_day(2) = 29
!
      call DATE_AND_TIME ( VALUES = values )
      dm = values(4)
      write (*,*) 'dm =',dm
!
      if (dm > 0) then
         mi = mi + dm
 11      if (mi > 59) then
           mi = mi-60
           hh = hh+1
           goto 11
         end if
         if (hh <= 23)          goto 100
          hh = hh-24
          dd = dd+1
         if (dd <= max_day(mm)) goto 100
          dd = 1
          mm = mm+1
         if (mm <= 12)          goto 100
          mm = 1
          yy = yy+1
      end if
!
      if (dm < 0) then
         mi = mi+dm
 21      if (mi < 0) then
           mi = mi+60
           hh = hh-1
           goto 21
         end if
         if (hh >= 0)           goto 100
          dd = dd-1
          hh = hh+24
         if (dd >= 1)           goto 100
          mm = mm-1
          dd = dd + max_day(mm)
         if (mm >= 1)           goto 100
          yy = yy-1
          mm = 12
          dd = dd + 31
      end if
!
 100  yy = mod (yy+1980,100)
!
      write (temp,1001) dd,label(mm),yy, hh,mi
 1001 format (i2.2,'-',a3,'-',i2.2, i3,':',i2.2)
      dos_date_time = temp
      return
      end
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 Previous  1, 2, 3, 4
Page 4 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