forums.silverfrost.com

[PaulLaidler]

That is what was intended and I thought that I had tested it but you are right it doesn't work.

[DanRRight]

Not very stable DLLs, or some other conflicts there. My codes freeze immediately with access violation like that (if this tells you anything):

Within file CLEARWIN64.DLL
In _fdebug_printf at address 17C
In _send_text_message at address 3B3
In _yield_program_control at address 234
In _sleep_at at address 5A
Within file PPP.exe
in ANGULARBREMMS at address 590b

Can not start the code in the debug mode to see what's wrong. Also crashes at start with /optimize mode.
With /nocheck code may start OK but is now sensitive and crashes often, seems it does not like something. For example the code freezes when i use %ac and works ok if the same callback is called via clicking on a button %bt.

Ones code worked with such tricks and i succeeded to run the new %pl i found that it still does not like something in the data and switches to linear scale from LOG. Is there a way to push it not do that ? As we discussed before it should not switch to linear scale when zero or negative data is present if condition y_min=val is used -- there is no reason to switch (and i do not see any zero/negative data and it still switches to linear). I see the work on that is almost done, %pl plots minimum of axis at y_min if you set it like this %pl[y_min=100.] but it still plots curves below this minimum threshold line and switches to linear if data has zeroes (or it suspects that)

New feature - the axis thickness works fine and looks good
CALL winop@("%pl[axes_pen=3]")

The new way of axis numbering when it switches the styles is probably not good idea. Example of some my real axis numbering: 0, 20, 40, 60, 80, 1e2, 1.2e2, 1.4e2 does not look good.
For reasonably small numbers it should be 0, 20, 40, 60, 80, 100, 120, 140.
The numbers as large as 1.2e5, 1e12 are probably OK represented like that but when axis is plotted they all should be in the same style

[PaulLaidler]

Dan

I suggest that you just go back to a stable set of DLLs.
I am not able to do any more work on this for the time being.

[DanRRight]

Paul,
Of course i will go to older dlls, but i'm curious if this is only my compiler state/settings issue. One simple case which crashes i already found. This demo code works in usual 32 bit mode

ftn95 name.f95 /link

and if you switch to 64

ftn95 name.f95 /64 /link

it crashes if you push DRAW or hit Ctrl+Z set in %ac

[PaulLaidler]

[DanRRight]

This is not an answer, Paul. This implies that compiler is fine and the program is wrong. But if program is wrong and it is wrong 100 times per day when you develop the code then it is the debugger which must tell me where the error is or at least give a hint. I'd like to but probably will never afford to hire you guys to substitute SDBG . How I have to proceed to find the error of immediately crashing code with "Access violation writing address 0x00007ff..........."? Just inspecting by hand each of a quarter of million lines of code will take me the same quarter of million years. The debugger crashes at the start of debugging. How come such error can crash both the EXE and the debugger? The 32bit code works by the way fine hence we can not use 32bit debugger to find this bug --> we are screwed.

I see few nice new features, i'd like to use it, the LINEAR scale %pl for example already approaching ideal beating for XY plots in quality MATLAB being equally simple,

https://www.mathworks.com/products/matlab/plot-gallery.html

the LOG one is almost done and just needs final fixes (still plots outside the allowed area etc), but this was very unstable build, totally unusable because of crashing on everything. Could it be that the new dlls are conflicting with the rest of the older 8.10 compiler ?

So before you interrupt with further development of native %pl (I thought you enjoyed this work and understand how important is to have top quality and simplicity graphics utilities natively in Fortran but in reality it appears that things were going exactly opposite) can you please fix these issues with LOG scale which are demonstrated with this code below so that %pl will not plot outside the allowed area and will not switch to linear scale automatically if y_min=val exists (the data plotted often fluctuates and zeros/negatives are inevitable). That could be hopefully easy fixes. Also, though this could be not related to %pl problem: by some reason the new %pl does not react on Redraw like the older %pl was doing (to see that action remove the line CALL winop@("%pl[native]" and compile under regular 32bit). This will make %pl finally at least usable in 64bits.

[PaulLaidler]

Thanks John. I only meant development work on the native %PL. Yes I aim to fix any native %PL "bugs" but the tick mark values on the axes may not always be tidy and the behaviour for log scales and negative data values will not change (for me these are not "bugs").

I am not sure what comes next. Maybe some of the requested missing Fortran standard features. Anyway I hope that I have learned my lesson. No more ventures like the native %PL.

[PaulLaidler]

John

The question about using negative data values and logarithmic transformations has gone on for so long now that I am beginning to doubt myself. If the user supplies a negative value of y then ClearWin+ can't calculate log(y) as a real value. I know that what is taught in physics can change but not mathematics surely. The issue about what happens with negative values of log(y) (e.g. log10(1e-3)) has been fixed.

As to the values shown at ticks marks, you can usually get good results particularly if you set (for example) the y_max and maybe the dy values.

[Kenneth_Smith]

John,

Apart from the issue with setting the margins independently the V6 DLLs are running fine for myself.

Ken

[Kenneth_Smith]

John, You are correct I've not tried the log scales - must try harder! However I have not had to go back one set of dlls. Ken

[Kenneth_Smith]

Paul,
Can you point me in the right direction and confirm the syntax for using the independent option. I am struggling to make the third %pl call in the code below work, where the two graphs with different x axis values are plotted together. Code below fails to draw anything in the third %pl region. I re-read the help file many times and tried various combinations with no success.

Thanks

Ken

[PaulLaidler]

Ken

For two independent graphs together the number of points must be passed as an array. So in the third %pl, 10 becomes np with

integer np(2)
np = 10

[Kenneth_Smith]

Thanks Paul.

Might be worthwhile changing the text in the help file

from:

In this case the number of data points and the optional x-start and x-increment data must be presented as variables (for one graph) or as arrays (for one or more graphs) where the array index corresponds to the order in which the graphs are coded.

to:-

In this case the number of data points and the optional x-start and x-increment data must be presented as variables (for one graph) or as an array (for one or more graphs) where the array index corresponds to the order in which the graphs are coded.

It was the plural "arrays" which confused me.

Thanks

Ken

[PaulLaidler]

Thanks Ken. I have changed the text.