FTN95 beta testing

The latest FTN95 and DLLs are available for beta testing via the following download link. This is for users who have v8.30 and want to test the latest fixes. An archive called demo.zip contains an additional program that illustrates new features in ClearWin+. This archive should be extracted to its own folder.

Please do not post replies on this thread relating to %pl or %fr failures.

Please be careful to create backup versions and make sure that each file is copied to its corresponding installation folder.

https://www.dropbox.com/s/n4xhgkdz71viqrf/Beta279.zip?dl=0

Yes that is correct. That file only needs to change when exports used by clearwin64.dll are added to salflibc64.dll (very rare). It is usually rebuilt for a full release just to make it look right.

John Silver: I have seen similar problems occur when (by mistake) I used a PATH setting that caused a the FTN95 DLLs were not all from the same release or if some of the DLLs and the compiler (FTN95.EXE) were not from the same release.

Here is what I see from compiling demo.f95 from the 8.30.169 release, using only the .169 release tools, 32-bit mode.

1. The warnings regarding variable I being given a value but never used are appropriate, but the wrong line numbers are shown. The lines containing the assignment to variable 'I' are 261 and 533, whereas the messages give 259 and 526.

2. When there is more than one such assignment to a variable the value of which is never used later, only the first instance is listed. This is appropriate, although '...only the first occurrence is flagged...' would be more helpful in fixing the code to remove those warnings.

3. Linking demo.obj produces the puzzling warning message

WARNING - Module component WINDOW_UPDATE@ has been defined differently here than previously in object file s:\FTN95\demo\demo\demo.obj (s:\FTN95\demo\demo\demo.obj)

Is there something that we should fix so that this linker warning goes away? The EXE that is produced appears to run fine (I did not check if the graphical output and GUI behaviour are correct).

In 64-bit mode, we again see the behavior noted in Items 1 and 2 above, but not 3. Instead, the 64-bit EXE fails, with a pop up saying 'clrwin is not available as an icon resource at address 1c008559'. John reported seeing this pop up at the link stage, but if he used /LGO the demarcation between linking and execution may not be obvious. The 32-bit compilation logs a call to the resource compiler '[Silverfrost SRC/WIN32 Ver 4.07 Copyright (c) Silverfrost Ltd 2018]', whereas the 64-bit compilation does not do so; perhaps the latter failed to call a 64-bit built-in version of SRC to process the RESOURCES section of the source file DEMO.F95. This problem occurs only if the compilation and linking are done separately. If the /link or /lgo options are used, no problem is seen, and an invocation of SRC.EXE is flagged.

As far as compiler-linker behaviour as applied to DEMO.F95 is concerned, I find that the new beta release is no different. In short, if you use the /link or /lgo option with /64, the new beta release produces a 64-bit EXE that runs fine.

Both programs work correctly for me but I tested using Plato under Windows 10 and not Windows 7.

The warning about WINDOW_UPDATE@ can be ignored. This routine is unusual in that it can take arguments of various types. The linker has noted what it thinks might be an inconsistency and issued a warning.

The problem about the missing icon relates to the need to use /r on the SRC command line when compiling the resource script. The linker should then be presented with the resulting .res file. I tested from Plato so I guess that Plato sorts this out automatically.

Paul, May be good idea to post the full this beta release with the installer on your website. I was unable to run my programs with this beta from start. Sometimes the mix of releases do not work well for testers. Specifically sensitive is Clearwin+ part of the FTN95.

John Silver:

You do not need a batch file for such a simple job; however, if you use one, don't expect some lines in the batch file to be treated as commands and some lines to be input directives for the linker.

The personal edition produces EXEs that differ from paid-up compiler generated EXEs only in that the former throw up a banner for a few seconds.

If you give the linker a file name with no suffix, it will add '.obj' by default. Therefore, you must explicitly add '.res' to the compiled resource file.

The following commands produced an EXE and ran it for me.

ftn95 demo2.f95 /64
src resources /r
slink64 demo2.obj resources.res /file:demo2
demo2

Resource scripts have the .rc extension and a different form to that shown above.

Why not just run the demo from Plato?

Remove the first two lines, i.e., the lines starting with '!' and 'RESOURCES', as well as the last line, with '!', from the input file to SRC.EXE, which should be given the suffix '.RC', as Paul noted.

You may have a corrupted or otherwise faulty version of the resource compiler. My SRC.EXE is 1,221,632 bytes long, dated 03/13/2018 (mm/dd/yyyy) and has a CRC checksum of 1221632. It prints a version number of 4.07 when run.

P.S. Correction: the checksum is 3295731287 according the the Cygwin cksum utility, and F1BB23AE according to the crc32.exe from http://esrg.sourceforge.net/utils_win_up/md5sum/ . The discrepancy needs to be resolved, but I'll leave that for another time.

Quoted from John-Silver

But the CRC32 checksum (obtained with a freeware program 'Checksum Tool' (from sourceforge) is ot the same, it's :-- f1bb23ae

Sorry, I had posted the file length as the checksum. The crc32.exe from http://esrg.sourceforge.net/utils_win_up/md5sum/ does give 0xF1BB23AE, so the problem is probably in one of the FTN95 DLLs. I did notice that SDBG64 started crashing more often when I used the DLLs that came with the 8.30.279 beta release.

I run Windows 10-64, but I think that you should not attribute the problems that you ran into to either the version of Windows or the versions of the various components of FTN95.

I can reproduce your second error (Error 343, from FTN95.EXE) by compiling for 32-bit when SRC.EXE is either not found by FTN95.EXE or cannot be run for some reason.

I even ran into the first error (attempt to read from address 1) once, but I do not know how to reproduce it without fail.

When /64 is specified, when FTN95 attempts to run SRC or SLINK64 and those EXEs are not found (or cannot be run), FTN95 fails to produce an output file but gives no hint of having failed. I think that this deficiency must be fixed soon. As it is, one has to list the directory contents to see if an EXE, OBJ or RES file was produced, or look for the signatures of SRC/SLINK to be output when they are run.

FTN95 fails to produce an output file but gives no hint of having failed.

FTN95 will provide a failure message in the next release.

Quoted from PaulLaidler ... The warning about WINDOW_UPDATE@ can be ignored. This routine is unusual in that it can take arguments of various types. The linker has noted what it thinks might be an inconsistency and issued a warning.

Paul, there is a discrepancy between the interface of WINDOW_UPDATE@ in mswin.mod (which is compiled from mswinmod.f90), in which WINDOW_UPDATE@ is declared with the attributes EXTERNAL and INTEGER*4; i.e., it is an integer function.

In contrast, in demo.f95 as well as at https://silverfrost.com/ftn95-help/clearwinp/dialog/updatingwindows.aspx, WINDOW_UPDATE@ appears to be a subroutine.

Thus, the discrepancy is between having a return value and none, rather than about the type of the argument(s). Please clarify.

mecej4

Thank you for pointing out this discrepancy.

mswinmod.f90 is either an old file from an earlier installation or it is included in the current installer by mistake.

window_update@ is located in the clrwin module which is compiled from clrwinmod.f95. It is also in clearwin.ins. In these files it is a subroutine.

See the following test program using Beta279. Generates IOSTAT=202 reading from file. Reads correctly in this instance, but not in others. PROGRAM FIXFORMNL C This program test the namelist statement INTEGER L1,L2,L3,L4,L5,L6,L7,L8 C Define namelist variables NAMELIST / BINP2 / L1,L2,L3,L4 NAMELIST / BINP3 / L5,L6,L7,L8 C Open & read input file, check IOSTAT OPEN(UNIT=9,FILE='DataNameList.txt') READ(9,BINP2,IOSTAT=ICODE2) READ(9,BINP3,IOSTAT=ICODE3) PRINT *, 'ICODE2 =', ICODE2 PRINT *, 'ICODE3 =', ICODE3 CLOSE(9) C Check output PRINT *, L1,L2,L3,L4 PRINT *, L5,L6,L7,L8 OPEN(UNIT=10,FILE='FFNL.OUT') WRITE(10,20)L1,L2,L3,L4,L5,L6,L7,L8 WRITE(10,25)ICODE2,ICODE3 CLOSE(10) 20 FORMAT(8I2) 25 FORMAT(2I5) END

DataNameList.txt &BINP2 L1=1, L2=2, L3=3, L4=4 &END &BINP3 L5=5, L6=6, L7=7, L8=8 &END

FFNL.OUT 1 2 3 4 5 6 7 8 202 202

Thank you for all you do. John

The input items for each namelist input should be terminated by a '/' character instead of '&End'.

Some compilers allowed other ways of formatted namelist input, including the use of '$'. Better not to rely on any of these non-standard ways.

I never used namelists so here is the question: when namelist is used - at compile/link or at run time?

Dan,

NAMELIST (which I don't use either) is a way of labelling data values which otherwise appear as semi- (or totally-) incomprehensible list of numbers etc in a datafile. The downside is that the user preparing the datafile has to know the corresponding internal variable names. It therefore appears in the source code, and the corresponding names have to appear in the datafile.

In a fully-fledged Windows program, where the user inputs data interactively and then saves the file, it's a moot point as to whether the plain list of data is that much of a difficulty, and I can see that NAMELiST might have a use if the programmer wants it.

Eddie

A namelist allows one to keep input data in a self-documenting style. Consider, for example, the thermodynamic state of a pure substance, which can be specified by any two independent properties from the set T, p, v, u, h, s, a, g. The program contains the declaration

NAMELIST /state/ T, p, v, u, h, s, a, g

and input statements such as

READ (lun, NML=state)

The corresponding input data can, for example, be

&state p = 0.1013, T = 25 /

for one state, and

&state p = 0.1013, s = 2.53 /

for another. Note that (i) the input data can appear in any order, since each value is labelled by the name of the variable that is intended to receive it; (ii) the variables whose values are altered as a result of the READ(NML=) can be any subset of the variables declared in the NAMELIST. You read only those variables that you wish to change, without having to change the READ statement; had you used an ordinary READ, you would probably have needed to specify a FORMAT specification appropriate for the list of variables being input.

I too am a namelist sceptic. It appears to be a data input format suited for the program developer, rather than the user. However it does have some flexibility that is of interest.

mecej4, for the case you outline where data inputs are optional, is there an easy way to find out what values have been updated, or do you have to check values against a previously set invalid value to confirm the value was updated by the namelist statement ?

I have struggled for years, either

1. re-writing a flexible user input approach, something like:

DO call get_next_token (...) call get_token_value (...) select case (token) case ... END DO

or

2. giving up, generating data in excel, dumping as a .prn file and reading a fixed format data layout, usually with some section headings.

I am at the stage now where my finite element data generator is a mix of Excel and Fortran, prefering the fixed layout data input option for my analysis program.