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 

FTN95 beta testing
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Thu May 03, 2018 10:52 am    Post subject: FTN95 beta testing Reply with quote

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. The demo has not changed. It should be extracted to its own folder.

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

https://www.dropbox.com/s/eosju489vghv4i7/Beta169.zip?dl=0
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri May 04, 2018 9:09 am    Post subject: Reply with quote

Paul,

I see few bugs fixed, DEC style parameters, for example, work OK, "framed" size can be changed etc. Was no time to check if "/TABS 6" makes tabs 6 spaces like with gFortran, and numerous nice new options like "top_or_left", AUTO_SCALE_FONT@ etc

This respond better fits Clearwin+ section... major is that finally LOG_LOG plot works reasonably, which is big deal: numbering is better aligned, axis numbering is correct. Need just few last tunings:

1) resizing plot with mouse works now OK but ultimately decreasing plot to zero size causes crash.
2) not clear how to change %PL "title" size/font only keeping all other fonts and sizes on axis intact, i get error "winop_hdl@ is missing"
3) simpleplot_update@ still crashes my code, I do not know where conflict is, is it with my log_linear plot or data, but I am close to prepare much smaller size demo.
4) one small issue with length of tics: when you change its length %pl[tick_len=val] the minor tics in LOG scales are the same size, not changed, but they have also change and be approximately 0.6-0.7 of length of major tics (i intentionally made them larger below)
5) little bit a problem with alighning relative axis appears for the 10**n style log axis numbering if exponent value n varies in broad range from, say, zero to 20-30. It is good or much better now if n had the same number of digits.
6)frame line width now can be changed but as a matter of discussion how about making it automatically the same size as axis_pen by default? Now default is 1pixel. This will cover 99.999% of need of changing frame_pen because typically if you need thicker axis you need similarly thicker frame. The same depth sizes for axis and frame was a default in initial stages of native PL, to me it was enough, but then frame default was changed to 1 pixel.
You can use my demo as an example, with the temporally commented line
"CALL winop_hdl@("%pl[title_hfont]",hTitleFont)" it does not work

Code:
   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   integer (7) ititle_hfont

   Data X/1e1, 1e2, 1e3,  1e4, 1e5/
   Data Y/2.2, 66, 8e10, 1111, 777/

   i=winio@('%sf%ts%bf%gf%es&', 3d0, ititle_hfont)
!   CALL winop_hdl@("%pl[title_hfont]",hTitleFont)
   call winop@("%pl[title='Log-Log Plot']") 

   CALL winop@("%pl[tick_len=25]")
   i=winio@('%sf%ts%bf%es&', 2d0)
   call winop@("%pl[axes_pen=2,frame_pen=2,width=2,x_axis='X (m)',y_axis='Y (rel.un.)']") 
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]', 625,500, n, X, Y) 
   end


Last edited by DanRRight on Sat May 05, 2018 3:58 am; edited 8 times in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1031

PostPosted: Fri May 04, 2018 11:08 am    Post subject: FTN95 beta, 8.3.169 Reply with quote

Thanks Paul, and this is a release with an impressive number of bugs removed. I went back to a number of my bug reports and tried the beta compiler on the test codes in them. Here is a list that other users may find useful.

Fixed in 8.3.169:

http://forums.silverfrost.com/viewtopic.php?t=3090 (Format string with long Hollerith strings)
http://forums.silverfrost.com/viewtopic.php?t=3711 (False error: uninitialised argument to routine)
http://forums.silverfrost.com/viewtopic.php?t=3725 (Compiler insists on type declaration for subprogram name)
http://forums.silverfrost.com/viewtopic.php?t=3730 (False error: assigned go to variable not integer)
http://forums.silverfrost.com/viewtopic.php?t=3752 (With /opt /64, fails on code with namelist)
http://forums.silverfrost.com/viewtopic.php?t=3753 (/check causes program run 800 times slower)
http://forums.silverfrost.com/viewtopic.php?t=3763 (namelist input causes access violation in RNML__)
http://forums.silverfrost.com/viewtopic.php?t=3771 (ishft, Rudnei)
http://forums.silverfrost.com/viewtopic.php?t=3790 (Winio@ adjusts ESP incorrectly, Wahorger)
http://forums.silverfrost.com/viewtopic.php?t=3793 (substring of element of string array in I/O list)

Still Open:

http://forums.silverfrost.com/viewtopic.php?t=3710 (compiler remembers more than it should, gets scope wrong)
http://forums.silverfrost.com/viewtopic.php?t=3743 (local allocatable array initial status set to ALLOCATED when subprogram ENTRY is called)
http://forums.silverfrost.com/viewtopic.php?t=3757 (SDBG64 does not show correct information on array argument)
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 05, 2018 12:53 am    Post subject: Reply with quote

Am I right in deducing from the cwplus.enh file that, as far as clearwin+ is concerned, this 'beta' version is just the same as dlls23 (for v8.3) with just the addition of the last 2 notes concerning 'improvements' to the windows handles definition of graphic regions ?
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 05, 2018 1:47 am    Post subject: Reply with quote

Dan, running your test code above
(note , using v8.3P with dlls23 on the basis there's no differences introduced with beta169 - see my question above):-

1. the scales on each axis are different ! (scientific on X-axis; exponential on Y-axis !!!

2. the Y-axis label still overlaps the axis labels !!!

3. if you re-size the window, even just slightly but also for any size change, then the scales styles switch ! i.e. scientific on Y axis and exponential on X-axis, with on X-axis the strange spacing (not powers of 10) appearing !

4. on the other hand, the problem of overlapping Y axis labls disappears !

added pm 05/05/2018:
5. you'll also notice that the curves are still somewhat less than 'suave and sophisticated' - I could be mistaken but I thought there was anti-aliasing by default for native %pl ?


I also tried adding 'grid_lines' as a %pl option (on a winop@) and it failed saying it was an invalid option !

Just a few morsels to add to the 'to fix eventually' list of th work in progress.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Sat May 05, 2018 3:15 pm; edited 2 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat May 05, 2018 3:33 am    Post subject: Reply with quote

Paul,
Major of course is the crash of simpleplot_update@ which looks like due to some internal corruption of plotting engine which violates array boundaries. Working several weeks already to make the test demo for it.

John,
I am curious...exactly what you have just described was before this latest update...

Use latest code above, i made small change
1) increasing one point of Y from 8333 to 8e10 to show that exponents hit the axis and
2) increased major tics (they look ugly now but do not look at this fact for a moment) to hit the numbers while minor ones do not grow and numbers do not move to the left
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat May 05, 2018 7:30 am    Post subject: Reply with quote

I have restarted this thread in order to shift the focus from Dan and John's concerns about %pl...

http://forums.silverfrost.com/viewtopic.php?p=24863#24863
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 05, 2018 1:45 pm    Post subject: Reply with quote

Dan ... I DID use the code above !!!!

*** 12/5/2018 Clarification ***
Well I did ... nd I didn't !
See later comment for full explanation.
I actually used tohe ORIGINALLY posted code which was subsequently changed.
Here it is for reference ....

use clrwin
parameter (N=5)
real*8 X(N), Y(N)
integer (7) ititle_hfont

Data X/1e1, 1e2, 1e3, 1e4, 1e5/
Data Y/2.2, 66, 8333, 1111, 777/

i=winio@('%sf%ts%bf%gf%es&', 3d0, ititle_hfont)
! CALL winop_hdl@("%pl[title_hfont]",hTitleFont)
call winop@("%pl[title='Log-Log Plot']")

CALL winop@("%pl[tick_len=9]")
i=winio@('%sf%ts%bf%es&', 2d0)
call winop@("%pl[axes_pen=2,frame_pen=2,width=2,x_axis='X (m)',y_axis='Y (rel.un.),title_hfont']")
i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]', 625,500, n, X, Y)
end



The things I listed above we have for the most part seen before, although the sudden change of scale types on expansion I hadn't noticed.

I've also just added above that the 'smoothėness' of the curves leaves a lot to be desired - I thought anti-aliasing was default for native %pl.

As Paul has now duplicated the post for non-%PL comments (1) (note - it was never my intention to hijack this post, I was just feeding in to Dan's example for Paul's future reference) I'll now post the plots here for clarity of the comments I made above...

the plot on opening the program ...


and the plot after a simple re-size ...


of course all the other issues documented on other things identified on other previous posts shouldn't be forgotten when the subjct is revisited in ... 3001 ... a plotting odyssey Wink

Note - (1) it would be good to re-name this post with a ' - %pl' at the end and the new one ' - General' or similar) to avoid the type of confusion we had with (at least) x 3 'Native %pl' posts.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Sat May 12, 2018 11:57 am; edited 2 times in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat May 05, 2018 7:39 pm    Post subject: Reply with quote

John,
Unless someone will confirm your plot (you still took my source before I made edition to emphasize my points above) seems you need to reinstall FTN95 and the update. All defects you show I see as being fixed.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat May 05, 2018 8:28 pm    Post subject: Reply with quote

As to Clearwin+, my opinion voiced here many times is that for well being of this compiler and even Fortran as a language in general the utilities like Clearwin+ and OpenGL made as ultimately user-friendly as in Matlab is more important then development of just the Fortran as a FORmula TRANslation language. Surprise, but the CWP is more important then the pure FTN95.

The proof is elementary: the users base of Matlab is 100x larger then combined one of all Fortran varieties. Among younger generation this factor might be even higher. And the difference between Matlab and Fortran is ? Professional integrated graphics at ultimate simplicity done in one line! And additional 10% gives integrated math libraries and 1% cooler look. This 1% percent by the way brings the same amount of users as all Fortran have.

Additionally for the FTN95 in particular as a FORmula TRANslation language the important would be future support of multithreading in OpenMP and MPI forms and ability to autoparallelize and debug multithreaded programs. Second major thing was 64bit support and it is basically now almost done.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1031

PostPosted: Sun May 06, 2018 1:48 am    Post subject: Re: Reply with quote

John-Silver wrote:
Dan ... I DID use the code above !!!!

John, I think that there is something mixed up regarding which file you used to produce the plot and which compiler version you used. Add to that the chances for more error that producing images, uploading them to a cloud server and including the URL in your post.

Here is what I find. FTN95 Version 8.1 does not produce a plot, giving instead an error message, "frame_pen= is an invalid %PL option".

The plot that you showed does not correspond to the plotted point coordinates. For example, the peak Y-value is given in the program source as 8E10, but your plot shows about 8E4.

When you compile and link at the command line, the compiler and linker display their version numbers. Please check those numbers, as well.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 12, 2018 12:01 pm    Post subject: Reply with quote

Reply to mecej4

John, I think that there is something mixed up regarding which file you used to produce the plot and which compiler version you used. Add to that the chances for more error that producing images, uploading them to a cloud server and including the URL in your post.

Indeed there is !
This is because:
1. I DID take the code as posted by Dan BUT the original posting of it - before Dan had subsequently modified it as he mentioned later:
Quote:
"... (you still took my source before I made edition to emphasize my points above) ..."

The images were correct - I've now added the code actually used to my earlier comment, leaving it as it provides a refererence.
NOTE - that as I stated previously, I used v8.3P+dlls23.
This was because I was awaiting a response to my prior comment about whether or not the beta169 was in fact (as far as Clearwin+ is concerned) the same as v8.3+dlls23.
It appears it's NOT as following results in later comments show.
Why it is different I don't know, except for the last 2 notes in the new .enh file, which I can't relate to the improvement (in the scales both being scientific) now obtained, and the lines missing from the CLEARWIN.INS (see below later).

Here is what I find. FTN95 Version 8.1 does not produce a plot, giving instead an error message, "frame_pen= is an invalid %PL option".

Well it would because unless I'm mistaken 'frame_pen' was only introduced in v.8.3 dlls23 (and in subsequentlybeta169 !
The plot that you showed does not correspond to the plotted point coordinates. For example, the peak Y-value is given in the program source as 8E10, but your plot shows about 8E4.
Thanks for pointing out the difference in plotted data -v- the coded data, your prodding was what made me check line by line the code I was running.

As I mentioned above this is because I had copied the original code posted and not the modified one.
When you compile and link at the command line, the compiler and linker display their version numbers. Please check those numbers, as well.

As mentioned above, I had already stated the version being used.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 12, 2018 12:04 pm    Post subject: Reply with quote

Results with beta169

So anyway, I have now installed the full beta169 (and modified the .INS to include the missing declarations code (as described on the other parallel post)).
Here below are the revised resulting plots, both before and after re-sizing.

First for the original code (before mods for tick lengths etc ... ):-
Initial Plot followed by Plot after re-sizing



Then for the code (as of today still) posted at the top of the post, with tick lengths modified:-

Initial Plot followed by Plot after re-sizing



As we can see the scale styles are now both the same (scientific). This is good.

The problem described earlier by Dan of only the major tic marks being re-sized is evident via his increase in size of the major ones and only those changing.

It is also evident however that the positions of the tick labels are not re-adjusted for an increase in tick length. This is not so good.

Also note that the first tick on the X axis :
- has the original thinner line
- but, the label appears to be at a correctly adjusted position for the tick length increase

For the first two ticks on the y-axis, the thickness is ok, AND their labels are adjusted correctly

It appears then that the adjustment of labels is not done when there is an exponent (>1).

There's another debate, should the values 1 and 10 not be 10^0 and 10^1 respectively ? Iwould say yes.

As for the curve quality (jaggedness) see below seperate comment about how to resolve it.

Paul, It would be useful going forward to understand why the behaviour has changed relative to that obtained with v8.3+dlls23 when on the face of it the changes listed in the new .enh file are the same except for the addition of 2 relating to declaration of 3 functions which on the face of it would seem not directly related to the %pl changes.

Finally just a comment that on re-sizing, for reduction in the x-direction one reaches a point where the Y-axis title starts to disappear (as shown below). This does not occur for either the main title nor the x-axis title)


_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 12, 2018 12:12 pm    Post subject: Reply with quote

The Additional Info Relating to the beta169 Release

On 'the other' 2nd 'FTN95 beta testing' post there is additional information/comments regarding a couple of minor oversights, which I reproduce here below for future reference of anyone finding this version of the post first

The supplementary information which appears on the 'FTN95 beta testing' Version 2 post is as follows :-

The beta169 Additional Notes:-

ref. http://forums.silverfrost.com/viewtopic.php?t=3802

The download includes a new clearwin.ins but not the corresponding mod files. Declarations (bindings) for new routines can be extracted from clearwin.ins.
https://www.dropbox.com/s/eosju489vghv4i7/Beta169.zip?dl=0
Please note the following corrections to files in this download.
1) The subject of topic 407 in clwplus.enh should be SELECT_GRAPHICS_OBJECT@ and not SELECT_GRAPHICS_REGION@
2) The following lines should have been included in clearwin.ins...
Code:
C_EXTERNAL GET_CURRENT_GRAPHICS_REGION@ &
&'__get_current_graphics_region' :INTEGER(7)
C_EXTERNAL SELECT_GRAPHICS_REGION@ '__select_graphics_region' &
&(VAL) :INTEGER*4
C_EXTERNAL WINOP_FUN@ '__winop_fun'(INSTRING,REF)
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 960
Location: Aerospace Valley

PostPosted: Sat May 12, 2018 12:15 pm    Post subject: Reply with quote

About The Additional Info Relating to the beta169 Release

I have a couple of questions concerning these notes (I have been told it's better to post them here rather than cross-fertilise the parallel post with %pl issues) hence why I posted the additions above :-

1. Could the omission of the lines in CLEARWIN.INS be related to any particular recent problem(s) encountered ?

2. The instructions given relating to the first line (about the Clearwin MOD file(s) (updated) not being included in the beta release) is, for amateurs like myself a little 'light'.

I have been able to deduce that in fact it should read better something like the following:-

The download includes a new clearwin.ins but not the corresponding mod files. Declarations (bindings) for new routines can be extracted from clearwin.ins . Indeed if any of the 'new commands' introduced in this beta are used and appear not to work then the associated lines in the CLEARWIN.INS file should be cut-and-paste -ed directly into your code .

Applying this actually helps in resolving Dan's title re-sizing (bigger) problem (see below later)

3. I also have one supplementary question regarding the ensemble of the dlls & libs in the ftn95 install directory.
I've noticed when inserting various dllXXs that there are some which are not updated, these are for example:-
clearwin64.a
clearwin64f.a
clearwin64f.dll
what exactly are these files, related to using clearwin with 3rd party compiler ?
If so doesn't that mean any changes are not reflected in those files and hence not implemented for use with other compilers ?
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... Smile "
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 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