|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Mon Jan 21, 2019 6:56 pm Post subject: |
|
|
That's nice to hear. Thanks. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Tue Jan 22, 2019 3:00 am Post subject: |
|
|
Commenting on the addition of TR15581 functionality:
When using FTN95 at present, the approach required for modifying allocatable arrays is to place the allocatable array in a MODULE and address it directly in the routine. As well as allocating, the other task is to check and re-size allocatable arrays if they are required to store more information.
This approach is limiting, as only a specific array can be defined.
TR15581, allows allocatable arrays to be routine arguments and so can be defined or adjusted when required, rather than designed in the routine hierarchy. This provides for routines to be more general and deal with multiple arrays of the same rank.
The other complexity of this additional functionality is the use of INTENT with ALLOCATABLE which can imply automatic deallocation.
TR15581 is not a trivial change, but would be very helpful.
The other changes I have been requesting are hopefully less complex. They are :
1) to include "information" intrinsic procedures that have been provided in F2003 and F2008. This assists in standardising the approach/name for information that is often available with other FTN95 library routines.
2) to provide other information routines that are becoming more useful (hopefully to others as well), such as GlobalMemoryStatusEx and others that have been identified lately.
3) to provide a version of ISO_FORTRAN_ENV module that covers the features in FTN95 that are included in the F2003 and F2008 module definition.
I would hope that the features selected in this list are easy to implement and so provides a coding path for improved portability and extent the usefulness of FTN95, which is my primary development compiler.
The other wish I would have is support for some OpenMP functionality, using the !$OMP directives. FTN95 has recently provided some multi-threaded capability, but the addition of PRIVATE variable construction would be very helpful. Unfortunately, this may be a much more complex addition. I would like to suggest support of OpenMP Version 3.0 or 3.1, but I am sure requests for later more complex versions would soon come.
Some indication on what is more likely or easier to achieve would be informative.
(apologies this post is similar to my previous post, but does provide some additional info. I have been on holidays on the beach, so have forgotten what I did last year, which is becoming an issue for us Fortran programmers !!) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Tue Jan 22, 2019 8:46 am Post subject: |
|
|
John
Thank you for the feedback.
I understand about TR15581 but your items 1-3 are somewhat vague. If you can be more specific then that would help. OpenMP seems to be unrealistic to me at the moment.
I am not sure if you know this but GlobalMemoryStatus@ already provides access to GlobalMemoryStatusEx. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Tue Jan 22, 2019 3:36 pm Post subject: |
|
|
In the category 1) of John's post there are routines for parsing the command line used to run a user program, such as COMMAND_LINE, GET_COMMAND, etc. Some of these are FTN95 extensions, some are from F2003, and it would be useful to know whether each such routine is standard or an extension.
Consider an example. In the FTN95 8.3 help file, when I look up the description for "Command line parsing routines", I can see COMMAND_LINE and GET_COMMAND listed with the description "Reads the whole command line." If the help file told me (with an 'X', or a check mark) that only the latter was from F2003, when writing new code I would use that in preference to the nonstandard one. Similarly, when I look up COMMAND_LINE, the help file could inform me (with a mark, a distinct background colour, etc.) that there exists a standard routine with the same functionality.
Last edited by mecej4 on Wed Jan 23, 2019 4:27 pm; edited 4 times in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Jan 23, 2019 8:23 am Post subject: |
|
|
mecej4
Thanks for the feedback. I will see what can be done. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Jan 23, 2019 12:14 pm Post subject: |
|
|
would it not be good form to start periodically (say every 3 months) publishing the 'wish list' to the forums, just for information so we know in general the direction(s) this great software is taking ?
You know my area of interest (which I don't even know if it appears on the infamous list or not let alone it's priority) and I'm sure lots of people have an interest to know if past reauests are in imminent danger of being adressed. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon Mar 18, 2019 10:20 am Post subject: |
|
|
The next release of FTN95 will allow dummy arguments to be ALLOCATABLE arrays. This will include the corresponding INTENT restrictions. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Wed Mar 20, 2019 2:51 am Post subject: |
|
|
Paul,
Thanks very much for this addition.
I shall be interested to test it when it is released.
This has the potential to simplify the code structure for resizing allocatable arrays.
It will be interesting to adopt in existing projects, as it can involve removing the old messy approach that is now working.
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon May 27, 2019 2:20 am Post subject: |
|
|
No GETENV yet? |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon May 27, 2019 5:37 am Post subject: |
|
|
Dan,
I don't see it mentioned in the v8.5 revision history (neither in announcements nor in documentation - we're all human and can forgt to add things in such lists), but clearly it has bheen addd (presumeably in v8.5 as that is what Paul said back on 12 Dec 2018)
No doubt Paul also has his own spreadsheet to keep track of, what is sometimes a bit of a mysterious black box to us, his 'wish list' ... his 'hit list' .... of what needs addressing, and it's priorities.
... because it's here in the online documentation ... https://silverfrost.com/ftn95-help/system/getenv.aspx _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Mon May 27, 2019 7:43 am Post subject: |
|
|
See the announcement for v8.50...
Quote: | Fortran 2003 standard intrinsic GET_ENVIRONMENT_VARIABLE added. |
|
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon May 27, 2019 1:46 pm Post subject: |
|
|
Indeed Paul ... apologies, my error in not realising that GETENV@ (the documented new function I assume) wouldn't be mentioned in the release notes.
Maybe it would be a good idea to avoid other dumbo users like myself from searching for non-existent terminology, to mod the description to something like:
Quote: | Fortran 2003 standard intrinsic GET_ENVIRONMENT_VARIABLE added via the introduction of new ClearWin+ function GETENV@ |
It might be a goof�d idea too to mention in the description of GETENV@ that it is based on calls to the windows API: GET_ENVIRONMENTAL_VARIABLE.
That would have help me pick up my faux pas too. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon May 27, 2019 10:20 pm Post subject: |
|
|
I know about GETENV@, users here played with it a lot. Here is for example the code to find the processor parameters.
Code: |
Integer, external :: processor_id
jj= processor_id ()
end
!=====================================
integer function processor_id ()
!
! With thanks to John Horspool 2008-04-02
!
use mswin
CHARACTER*400 LDATA
CHARACTER*80 getenv@, IDENTIFIER
CHARACTER*80 CPU_stepping, CPU_description
integer n_processorsTotalGetEnv
character*256 ResultsToSave(10)
integer iVersionOfTesrResFile
LSTR=400
k = REGOPENKEYEX(HKEY_LOCAL_MACHINE, &
'HARDWARE\DESCRIPTION\System\CentralProcessor\0', 0,KEY_READ,MyKey)
CPU_description= ' N/A '
if (MyKey.GT.0) then
k = REGQUERYVALUEEX(MyKey,'ProcessorNameString', &
CORE4(0),CORE4(0),LDATA,LSTR)
! WRITE(*,'(a,a)')' Processor : ', LDATA(1:LSTR)
CPU_description = LDATA(1:min(80,LSTR))
endif
k = REGCLOSEKEY(MyKey)
! write(*,*) getenv@('PROCESSOR_IDENTIFIER')
! write(*,*) 'Number of cores=', getenv@('NUMBER_OF_PROCESSORS')
READ(getenv@('NUMBER_OF_PROCESSORS'),*)n_processorsTotalGetEnv
Write (*,*) ' Number of Processors/cores/threads= ', &
n_processorsTotalGetEnv, ' ', getenv@('PROCESSOR_IDENTIFIER')
Read (getenv@('PROCESSOR_IDENTIFIER'),'(a)') CPU_stepping
processor_id=2
end function
|
But now I compile some third party code which has the line
Code: | if(qui.eq.' ') call getenv('USER',qui) | and clearly this GETENV has different I/O |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Tue May 28, 2019 7:12 am Post subject: |
|
|
As far as I am aware GETENV is not in the Fortran standard.
It commonly takes the form CALL GETENV(NAME, VALUE) so this could be added to the FTN95 library. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Tue May 28, 2019 1:56 pm Post subject: |
|
|
Fortran codes developed on Unix/Linux may make calls to routines in the "3f" group. The following is the Oracle/Sun man page for GETENV:
https://docs.oracle.com/cd/E37069_01/html/E54439/getenv-3f.html
If this routine is added to FTN95, the 3f way of handling insufficient argument string sizes may also need to be implemented. |
|
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
|