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 

New Video
Goto page Previous  1, 2, 3, 4, 5, 6
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
Kenneth_Smith



Joined: 18 May 2012
Posts: 345
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Jun 29, 2020 12:24 am    Post subject: Reply with quote

Martin,

Here is a modified version of the previous code which includes the change so that the simple splash screen appears:

https://www.dropbox.com/s/g8cg06abe8ypcj9/martin3.f95?dl=0

I have marked the changes in the code. In most cases 3 lines are added to each call back function.

And here is how it responds:-

https://youtu.be/PDrYfr_gUic

No problems with symbol = 12.

Ken
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 345
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Mon Jun 29, 2020 11:13 am    Post subject: Reply with quote

Martin,

here is a link to a slightly better implementation, which avoids the need for the global control variable. The control variable is now stored internal to the function temp_window() which creates, and removes the splash window.

The first call to the function temp_window() creates the splash window, the second removes it and so on.

https://www.dropbox.com/s/dzy1fboj21czitl/martin4.f95?dl=0

Again no problems with symbol = 12.
Back to top
View user's profile Send private message Visit poster's website
Martin_K



Joined: 09 Apr 2020
Posts: 118

PostPosted: Tue Jun 30, 2020 12:44 am    Post subject: Reply with quote

Ken,

thanks for your tips!

I found a hidden and sneaky bug in my code! It caused my big troubles with graphics in certain circumstances.

Namely, in one instance (under one IF construct), I used as a dummy argument the name, which I already used
elsewhere in the code as the name for a data object in a named COMMON statement.

This bug caused my troubles and lost of big amount of time.

Now, it is removed! Take a look at my video below, please, I will have a question.

I implemented (in a modified way) your suggestion regarding the display of info messages when the program does long calculations - thanks again for your countless inspirations!

[/url]
https://www.youtube.com/watch?v=btnBVB-CqNM&feature=youtu.be
[url]

As you can notice, at the time of about 25s from the start, I click on the menu (in EN: MAP/DISPLAY VECTOR MAP OF THE SR (Slovak Republic)



Here is a significant delay between the moment when the menu is selected and till the selected action is completed (drawing graphics for grid PLUS border line).
Similar delay can be observed at about 1m 55s from start, when I select the menu MAPA/ZOBRAZIŤ MRIEŽKU (MAP/ONLY GRID DISPLAY).

In these both cases I would like to add an info message that something is happens (processing ...), but I am not sure, where in program is the right place for it. I achieved a result
(not good), when I placed such message in the corresponding plot call-back. It worked, but the information window never dismissed, although I used the same coding like for the buttons in the graphics.

When I placed the coding in the corresponding call-back for the menu item,
it also does not work as expected.

So, where should I place the code for info message?

Thanks in advance for your tip!

Martin

P.S. I will have a look at your last post (of Mon Jun 29, 2020 11:13 am) on Thursday,, since tomorrow I am very busy with another tasks.
Back to top
View user's profile Send private message
Martin_K



Joined: 09 Apr 2020
Posts: 118

PostPosted: Tue Jun 30, 2020 9:50 am    Post subject: Reply with quote

Ken,

I identified the right place, where to put the splash window
when initially (for the first time) the graphics is drawn
(for both menu: MAP/DISPLAY VECTOR MAP SR and MAP/DISPLAY GRID ONLY).

Now, I see the splash window in the right place and it automatically dismisses when the selected task (via menu) is finished.

Do not waste your time with this!
(I will still have another topic for discussion Laughing ).

Martin

P.S.

Added a short video how it looks now:
[url]
https://www.youtube.com/watch?v=ZXD9r8hHphs
[/url]

BTW - why compiler did not make a notice that I used not allowed
use of the same name for a variable and the same name for a data object in a named COMMON statement? This was extremely time-consuming issue
for me.

As I detected the problem yesterday, I have no more problems with graphic symbols of points!


Last edited by Martin_K on Tue Jun 30, 2020 10:35 am; edited 1 time in total
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 345
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Jun 30, 2020 10:33 am    Post subject: Reply with quote

Good.

COMMON blocks can always cause problems, I prefer to put global variables in a MODULE.

At t = 32 s in the video I see the windows processing icon appear and you may get the program “not responding”. This can be avoided by a call to TEMPORARY_YIELD@() within CPU consuming loops.

Ken
Back to top
View user's profile Send private message Visit poster's website
Martin_K



Joined: 09 Apr 2020
Posts: 118

PostPosted: Tue Jun 30, 2020 10:43 am    Post subject: Reply with quote

I will add the function TEMPORARY_YIELD@() to the corresponding
part of my code.

I also use the MODULE possibility in the code (it is - by far - the most important part of my code), but I also have quite big amount of
COMMON statement (first of all an mainly in my main program and in a subroutine) and to re-code them would also be quite time-consuming task.
Anyway, I will minimize their use.

Martin
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Jun 30, 2020 11:07 am    Post subject: Reply with quote

Ken,

I've always used COMMON blocks, without the slightest problem - at least once I mastered what they did. Putting global variables in a module is a great idea, but it does rather destroy the fundamental tenet in earlier versions of Fortran that the scope of a variable name was limited to a single subprogram, and that in fact there are no global variables! While I have no doubt that this is in many scenarios a great idea, it can be the very devil when you deal with old codes that relied on that scoping rule and implicit typing and mixing the two is where you can generate all sorts of problems.

And don't knock the old code base - for example, it was used to analyse things much better than we have today, like aeroplanes that got you from Heathrow to New York in a little over 3 hours.

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



Joined: 18 May 2012
Posts: 345
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Jun 30, 2020 5:05 pm    Post subject: Reply with quote

Eddie,

Knuckles have been wrapped with my steel ruler. Never did get a flight on Concorde.

Ken
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



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

PostPosted: Wed Jul 01, 2020 8:09 am    Post subject: Reply with quote

Ken,

What a pity. Only £3000 each way in the 1990s, and being December there was a double air miles offer. As Concorde was always double First Class airmiles already, a trip for a meeting with New York lawyers provided the air miles or a family holiday. Frequent flyers left behind the leather 'gifts' and silver pens, and I collected enough for my Christmas presents that year.

On a subsonic flight the windows get cold, but on Concorde they got hot, and the aisle seat (2 each side like a 707) was the best. I've always asked for an aisle seat ever since ...

Incidentally, we won the case before an Arbitration Tribunal, but not before I'd also been to meetings in Australia and a day-and-a-bit site visit in Indonesia.

The business of mixing modules and COMMON is likely to create mayhem in a way that one or the other exclusively will not, after that it's a matter of taste.

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



Joined: 16 Feb 2006
Posts: 2184
Location: Sydney

PostPosted: Wed Jul 01, 2020 9:35 am    Post subject: Reply with quote

Eddie,

I have been gradually transitioning COMMON to MODULE.

The disadvantage of COMMON was they could be (re)defined each time they were used, but this was overcome by only using COMMON in an include file. Nevertheless, we are told COMMON is bad programming style, by those who make Fortran much more complex.

The advantage of MODULE is it allows derived types, which can assist with organising data property tables. ALLOCATE is also a big change (post F77) which is useful in modules.

A disadvantage of MODULES has been the vaguaries of using EQUIVALENCE.
It is interesting, that early on, I tried EQUIVALENCE in a MODULE and got an error message, which discouraged me from persisting with that approach.
However, equivalence can be used in modules, although its use is less of an issue; mostly can now be done differently.
I have seen COMMON used in a module, although I don't know why ! There is a SEQUENCE statement.

As for Common on the Concord, only £3000 each way might not be compatible.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1336

PostPosted: Wed Jul 01, 2020 9:39 am    Post subject: Re: Reply with quote

Kenneth_Smith wrote:

Knuckles have been wrapped with my steel ruler.
Ken


Hard to unwrap with just one or zero hand free. Unless you meant the Iron Lady. :)
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1336

PostPosted: Wed Jul 01, 2020 10:05 am    Post subject: Reply with quote

COMMON has one bad property that one must contend with. It forces a specific order on sets of variables, when in most cases the user wishes to access just a few members the block as it it contained an unordered set -- just those variables in one or more common blocks that are needed in a subroutine.

Here is an example, that AKS brought up in his recent posts. The US Navy SMP program contains scores of subroutines. Many subroutines are about 100 lines of code, of which about 80 lines are COMMON and type declarations. Most of the variables in the common blocks are never used in the subroutine, but they have to be present (and their types declared if leaving the types implicit based on the initial letter is going to affect the memory layout).

https://apps.dtic.mil/sti/citations/ADA282341
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Wed Jul 01, 2020 12:13 pm    Post subject: Reply with quote

Mecej4,

That is simply bad programming style, perhaps because the compiler first used had a limitation on the number of named common blocks. One could do the same bad thing in a module full of unused declarations, with the disadvantage that when such a module is USEd, you don't usually get to see those declarations when reading the source code, as you would not, for example, if the COMMON blocks were simply INCLUDEd.

The different lengths of variables is a 'useful stupidity' that arose when byte-orientated memory layouts became the norm: when one had two 24-bit words or a single 60-bit one, REAL and INTEGER were the same length. You lost the benefits of the same length while gaining a better utilisation of memory - but also usually created more problems of INTEGER overflow as shorter INTEGERs were the main benefit. Having implicit type (and I know that you don't like that, but I do) means that I can tell the variable type at a glance. Yep, and I know that you can stick to the I-N for integers convention with explicit typing, but explicit type declarations also make the declaration section longer than perhaps it strictly needs to be (your complaint, not mine), especially if you have a lot of local variables (I try to keep the number of those as small as possible).

I respectfully submit that the argument against COMMON in your observation is not so much an argument against a particular thing like COMMON, but is an argument against how it might be badly employed.

The same may be said against the use of a hammer, which may be used for driving in both nails and woodscrews, but although it may be used to get nails out (if it has a claw) is not so good for getting screws out, whereas a screwdriver is good for getting screws out as well as putting them in,so it must be superior - forgetting that a screwdriver is no good for driving nails in or getting them out. (Incidentally, a hammer is sometimes colloquially termed a 'Birmingham Screwdriver', and for some types of carpentry works it is far quicker at getting large woodscrews into rough timbers than a conventional screwdriver).I don't advise the use of this technique in aerospace applications, by the way!

You also find that some layouts, for example the traditional 80-column card format lead to lots of continuation 'cards', but of course, any statement that takes many lines of continuation has very little chance of being understood easily by anyone years after it was written, the fault lying not with the restriction on the length of each line, but in the complexity of the statement. Certainly, one can lay out the elements of an overcomplicated statement in a way that helps readability, but this is true whether one has a longer line length or spread it over several lines, and indeed the latter may prove preferable when printing or even using some editors.

To return to COMMON, it would be completely barmy to include a COMMON block in a subroutine that did not access any of the COMMON block's variables, and it is still barmy to put too much in a single COMMON block when you can divide the content over 2 or more. This was perhaps more obvious with the early Microsoft Fortran 77 versions where COMMON blocks were limited in any case to 64k, with the limit on how many blocks there were restricted by total memory and one's imagination in giving them names.

Eddie.
(Not from Brum, by the way)

PS. What happened to the old preference in FTN of starting arrays on 8-byte boundaries? Is it still a good idea? In which case how do we do it?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1336

PostPosted: Wed Jul 01, 2020 1:13 pm    Post subject: Reply with quote

My point is not that bad programming practices should be followed. It is that some aspects of old Fortran make it impossible or very tiresome and error-prone to do things right.

I have rarely come across large programs in which the order of the variables in COMMON was of any use or interest to the programmer. Rather, it makes the compiler's job easy and allows the symbol tables to be broken up into short blocks.

In the card-deck days, there was no INCLUDE 'abc.inc', and if you did not have a card duplicator, punching multiple sets of cards containing large common blocks was non-trivial.

On the other hand, many small common blocks increase the load on the linker. You may remember MS Fortran 3.3 and MS Link on MSDOS. Sometimes it took longer for the linker to finish than for the compiler to process the many source files that were part of a large program.

Hollerith strings longer than 56 characters form another example.
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Wed Jul 01, 2020 4:26 pm    Post subject: Reply with quote

That's interesting. I don't think that I ever timed a linker, but you may have a point. I always thought that the MS Fortran linker had a bigger job than the compiler, which in the first version(s) I used had 2 completely separate passes, and I never compiled a whole program in one go after moving to a PC until relatively recently. I would expect compiling a single subprogram to be quick. In any case, the whole process on a PC was infinitely faster than sending a deck of cards off in a box with a courier, and waiting until the end of the day or the next day to get the results back. It was also faster than waiting for the normal day to end and getting the computer room key so that the mainframe machine could be restarted, in the case of a machine I used for some years by operating big circuit breakers like the ones in Frankenstein's lab! The margin of difference was so huge that it didn't occur to me until I got my second PC that 'virtually instant' could actually be speeded up.

Oddly, I never found that duplicating cards was a big job, using 026 and 029 card punches - but I do find it tedious with cut and paste. This must surely be to do with the pace at which one can work nowadays. (And there aren't that many of them to duplicate if you have arranged your COMMON blocks appropriately. (I don't think that I had any views about the order of variables in a particular COMMON block, what I hoped that I was saying was that the choice of variables that go in particular COMMON blocks can impact on what is needed for particular subprograms, and therefore it didn't make sense to have large sections of COMMON blocks in any subprogram).
Also, I found that IBM card punches could also copy a card that the reader had mangled, usually without too much difficulty.

You said somewhere that you worked originally on CDC machines, and the high speed card reader on a 6400 at Imperial College could, on occasions, spew 500 or so cards in the air in a matter of seconds. Afterwards, it wasn't just a matter of getting them back in order, it was also a question of replacing those that were irreparable or missing.

And anyway, wasn't card punching mainly a job for that room with four or more middle-aged women who punched the cards (or tape) from coding sheets while discussing the previous night's episode of Coronation Street and filling the air with cigarette smoke? Or the card duplicator that could punch n copies of a small deck? (If you could get it working, that is. Mostly the effort wasn't worth it, and the hardly-used duplicator was scrapped along with the worn out punches and the computer that had become a museum piece.)

I fear that we'll never agree on the ancient v. modern approaches, but I found your comments particularly valuable, as it never occurred to me that COMMON blocks made the compiler's job any easier. One lives and learns.

Eddie
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 -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6
Page 6 of 6

 
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