I've decided after good example to write some diary pages with toughts and events.

Oh, in case anybody fails to understand, I'd like to remind them that these pages are copyrighted, and that everything found here may not be redistributed in any other way then over this direct link without my prior consent. That includes family, christianity, and other cheats. The simple reason is that it may well be that some people have been ill informed because they've spread illegal 'copies' of my materials even with modifications. Apart from my moral judgement, that is illegal, and will be treated as such by me. Make as many references to these pages as you like, make hardcopies, but only of the whole page, including the html-references, and without changing a iota or tittel...

And if not? I won't hesitate to use legal means to correct wrong that may be done otherwise. And I am serious. I usually am. I'm not sure I could get 'attempt to grave emotional assault' out of it, but infrigement on copyright rules is serious enough. And Jesus called upon us to respect the authorities of state, so christians would of course never do such a thing. Lying, imagine that.
 

Previous Diary Entries   |   List of Diary Pages   |   Home Page
 

Thu 21 june 2001, 12:13 AM

The level is let's say top programming level generally, depending a bit on the angle, and the entry level is pretty much everyone who has seriously seen computers, at least reasonable IQ, and at least the will to seriously delve into these areas, otherwise just a global and superficial look is reasonable, and the rest lets say inside ramblings of various programming areas.

Sliding over bwise and network links

I've put in 5 ovals, basically around the number 42, which is strictly speaking coincidental, though of course noteworthy enough as a little joke, in fact there should be another one, in the big slider window on the right, but it wasn't visible in this screen dump.

The idea of the experiment, except from a strictly application programming point of view, where I find bugs and incompletenesses and think about such concepts as interface layout every once in a long while, is to have two sets of sliders, in this case the left one is scaled quite small to take little space on the screen while the hardly visible right one is stretched vertically to make the sliders more accurate and visible, which are connected over network type like, that is the right sliders follow immedeately the position of the left sliders, which is fun enough.

So one points at the slider indicated by the big one, clicks and moves the slider up and down, and almost immediately the corresponding slider on the other side moves as well, to the same value, in this case between 12 dB amplification and 120 decibel attenuation, as they were intended. The numbers were included for the reason of making clear what the order of events is when a slider is touched and moved.

After we move a slider, in this case to 42, event 2 happens, because it is so programmed in the slider handler function barely visible in the function window above, and event two happens in the pcom part of the left tcl/tk interpreter. A message is sent which is visible in the pcom log window simply stating the relative slider number (1..8) and the latest position, here 42.

Also, there is information about the slider made known to the bwise part indicated by 3, which is where the block info window for bwise block Proc2 shows the output value of the block being set to 42 as well as part of the slider update routine. Setting this value only changes the value stored on the variable associated with that output pin, it triggers no bwise behaviour yet, the bwise graph remains as it is, static.

Because of the message being sent in 2, the other tcl/tk application on the left reveives this message over normal communcication channels after a little while, in this case a very little while because the communication parties are both on the same physical machine, so the event log window near 4 indicates that the message sent by the left tcl/tk application has been received. This message makes the right slider indicated by the message update its position when after it has been interpreted.

Finally, the bwise canvas window from the left application is triggered when the slider is released into its final position, that is when the user lets the mouse button go up, a handler routine is programmed which triggers the Proc2 block, which is visible right under the 'Test' text on the canvas, in this case with a Propagate command, which transfers the data on the output of Proc2 to the connected blocks, and
runs those. A Run command would first trigger the Proc2 block itself, which would in this case make it destroy its output value (replace it by another one depending on the input value, which in this case in empty), so Propagate is used. Because the connected blocks are run, the connected Mon block shows the last value put on the output of the Proc2 by the slider after it has been transfered to Mon2.in . This is shown under 5.

Two tricks make the story not completely accurate.

First, the message shown on the left pcom window under 2 is strictly speaking the echoed message from the right tcl/tk interpreter after its slider has been updated. This application still sends a standard update message when its sliders change containing simply the slider name with the new value, which shows up in the text log window on the left, but after the right slider has been updated by remote control... The left application has a new slider update routine, which for the sake of this experiment contains the keyword DO_TCL, which is interpreted in the right hand pcom application as indicating a tcl command, so the rest of the line is simply run as a piece of program. Since such a piece of program could be anything, including the equivalent of wipe the whole disc clean, it is not generally recommended distributed programming practice to run remote scripts, but in this case the experiment is like opening a remote Linux or even DOS shell, which is normal enough,
at the time the link between the who pcoms is established it just needs to be sure we connect to the party we think we're connecting to, after that the connection stays in place, which is not easy to hack through as a construction in general. Thus arranged it is fine enough as programming idea, though there is a major decency criterion at stake, which is that in fact the two applications can influence eachother almost completely, since a tcl command is just a line or more lines of text, any behaviour can be remotely called for. If the left application messes up, then it may easily mess up the right one as well, while when only messages are exchanged which are always interpreted first by the receiver, at least the other party may continue to run fine after the one makes an error.

Clearly enough, it is more fun to let scripts pass over the channel, because otherwise all possible interaction patterns have to be understood by the other application before they are called by a simple message. For instance the normal behaviour of the pcom script is to take incoming text from the network type of connection as text to display in its second text window, and just that. There are more complicated messages it interprets for instance as having to return a list of file names, such as the 'dir' command under dos would do.

The other trick is what is in certain circuits refered to as non-determinism, in this case in relative ordering sense, of lets say the update taking place in the bwise canvas of the left application, and the slider update in the right. It is possible, because the message to the left application is sent before the Proc2.out variable is changed, that after the message is transfered to the operating system, the network part, immedeately is is conveyed to the other application, and that this application starts to get processor time to do the associated updating of the right slider before the operating system assigns running time again to the left application to proceed with the next command in its' slider handler to set the Proc2.out variable. The reverse order is also possible: then first the left application returns to idle, that is no updates needed anywhere, which means nothing needs to be done in the user interface anywhere while all actions are only started by user events (in this case), so basically the operating system knows it needs no run time, and sees if there are other processes to give time to, which in this case would be the tcp/ip network handling modules, and the other tcl application after it receives one or more new messages. Even when the slider handler of the left does finish first, it may be that the associated update of the visible number in the info window entry (3) waits until a bit later time, depending on OS and tcl/ip programming rules, the type of machine, the number of other active processes, the type of screen handling chosen in the tcl/tk graphics library, etc.

From a detailed programming point of view, lets say putting pixels on the the screen and pushing bits and bytes into network connections, a lot more needs to be said even to define this problem accurately, for instance what happens when the mouse moves over the slider area, dragging the slider knob along, an leaving all areas it normally passes over intact. The messages that are put into a standard communication channel are composed of frames with a certain lenght, and it may well be that parts of messages are received at different times, and that a text string is received in pieces, or that the receiver is still processing the previous message, so that new messages pile up in the operating systems' or applications' first in first out buffers.

Interesting enough, but of course the main point is how can in spite of all such complexities a working system be made, preferably overseeable and even more preferably in a way that works in general, on many systems and under all normal circumstances.

The answer to that question is a main point in the picture of using tcl/tk and programming the way I have, because making programs that work with all these issues taken into account is hard enough already for one type of system, and with the approach taken here I made program pieces that work fine over quite a variety of systems without much work, and that thusfar are well behaved: they do as they are expected to without much unexpected or unoverseeable behaviour.

Now what if we let both slider sets influence eachother? If I'd connect two parties like the left up, messages would start traveling arounf all te time! The principle would work, simply every slider change is copied on the other side, and every time the other side is updated, the previous one is updated again, etc., so the processor would do a lot of unnecessary work, and if there is a real network connection in between it is continuously busy, because it probably in such case is the speed limiting factor. When two users would both interact with the same slider, the story above becomes relevant.

With all these complexities, it seems hard to define a working program at all. That is luckily not the case, though there are considerations in this area of thinking that receive not enough attention in many programming environments. The main idea or call it trick to keep in mind, what am I free software university here, is that with respect to the user interface, all interactions have an effect which lasts shorter than the time to the next action of the user. That is the main idea. When that is no longer valid, good enough models must be used to make a multi-tasking environment work.

The other general idea is that user actions pace the automatically generated sequence of events after each interval of the order of the time between two user actions. Than normally nothing much happens that goes out of control.

Both ideas are dependent on the computer systems power of course, and on the various parameters therein.

As soon as multitasking either virtual or by more than one machines is involved, there are parameters in this game changing all the time. When processor time is divided between two tasks, they at best receive together the same amount of computation power as first alone. When 10 programs are running at the same time, they together still can do no more work than one program running full time could, so on average they'll run 1/10 as slow (or 90% as slow, depending on terminology). Unless programs run on seperate machines, than all virtual processes on both or all machines can achieve a speed of maximally the total processing power divided by the number of simultaneous programs. Remember the dices? That is where things are lets say optimistic. Because every time a task is switched, a little time is lost, and when process switching takes long enough in comparison with the amount of effective runtime per switch, the effective total computation power is decreased. The same holds for waiting for communication, when a process is waiting for something to be sent or received, usually another process receives runtime in the meanwhile, which takes a task switch. So when small pieces of information are communicated all the time, it may well be that task switching becomes a major fraction of the total computer activity.

Programming with this in mind is harder than just making a certain sequence of events work, and defining such criteria and parameters that go with it even harder. This is an area in major need of lets say wider and better applied theory and lets say scientific approach instead of hobbying. Though the word need may not be appropriate when no one sees it as such, but a comparison with computer building is almost lydicrous or heartbreaking or something in terms of how software is put together in comparison with for instance a decent piece of computer hardware design when done right. There is one factor that makes lets say the, if such term is understood, the programming of the world wide web and all users on it interacting with it significantly more complicated to start with, and that is not knowing what a program is going to do when such range of choices is involved as there is when actually programming distrubuted machines instead of doing remote phonebook lookups and lets say the equivalent of very long lived airplane reservation actions. When the whole problem is defined beforehand, the whole machinery could be mastered fine enough lets say the ee way, define what it should do, make sure a model is made which is used ok enough to make a design with, trick or profi built or anything else a working solution prototype together, try it as a model, think it through a few times, make a next version, try it in practice, and the whole thing may work reasonably well, depending on effort and talent.

Clearly, there is no good definition of what the whole of the internet aparatus is supposed to do, except for the obvious enough passing of information, which can be modelled enough: every browsing person requires a certain amount of information to pass over some average distance, at some average times of day, which is not easy to model, but the law of large numbers make it quite reasonable to undertake the design of such system with structure and foreknowledge enough of the properties of the resulting machinery.

Unless every person in the world decides at one time to look up a certain web site connected with a slow telephone line, and won't give up that they want to reach that server. That would be a problem, and is not solved intelligently, normally speaking, for instance such as when such server would broadcast a web-radio channel.

Including the definition of timing and accurate specitfication of timed events and communication with the notion of time and protocols is a world of its own, and also in certain ways known in the communication area such as telephone exchange machines.

A program is normally a sort of machine which has no probabilisitc behaviour at all, a program can be run on every computer with the same input data it will generate the same output, always, unless there is a computer error. And mostly, the definition of a program, both in source and object form is mathematically or formally quite clear and usually unambiguous. This is quite clearly so for programs which interact with data which can be fed to it in an exactly known form, such as an input data file. When a program interacts with the outside world, less clear programming laws have come into being, which use suppositions where usually timing plays a role, and when other programs are involved where protocols play a major role. With explicit protocols involved, a completely well defined set of connected programs is in principle still possible with normal enough programming disciplines, and the main idea is than that interactions are paced somehow by either known or unknown timed events, but that the sequence of interactions is completely plannable and formally describable. When program a sends message 1, program b will do so and so and send a message 2, which after being picked up is used to decide the next behaviour, etc. All possible of such traces can be considered beforehand, and only the known data given to all the programs decides on what is going to happen at ever program and communication step. An interesting and hard question is here how many possibilities there are in terms of the possible 'traces' of events, that is on one side we have the simple case of programs exchanging messages all the time, a messages b,
and back, until both know the problem they're dealing with is solved or will not need their efforts anymore, and the complicated case of a automatic script looking up the third address of all Johnsons in every city in the world, computes the average occurence of the house number, and decides to keep a link with all the servers returning a number average below the average, repeated for the next name in the book of the first winner, and suspended when the variance of the last contributers house numbers is less then the number of nodes after the last server link network. The term 'last' in the latter example could be replaces by last after sorting alphabetically of the intermediate results, which makes the problem completely definable beforehand as long as nobody moves during the experiment, because then the course of events in the various programs linking up with eachother completely depends on the content of all the phonebooks of all cities, and the experiment is completely repeatable. Maybe not predictable, because the prediction may be too hard, it may be the the variance number is never reached, or takes a longer time then needed to make the prediction. Still the idea is clear enough, even though humans can understand that the idea is apart from insane quite sane enough in terms of its definition, the outcome is hard to predict, and also the structure involved in getting there is well defined in terms of how it is made but only predictable when the whole experiment is done.

The trick in the latter example is that the solution makes no sense. There are problems where it does, and where simular considerations play a role. Then the question is, can they be stated and programmed reliably, and in what way does such work decent or pleasant enough.
 

Sinfull guitar playing

Maybe not completely unlike the concept of manufactured uncertainty which I recently picked up in a communication science book on the growth of the internet. Need more input.
 

Magic Carpet Ride

I just thought about 'the wall', for everyone over real teenage age with completely basic development of course known for example from their Berlin concert and album and hit 'the wall'. The idea of the rock opera is not completely clear in my mind anymore, but some of the major themes certainly are, also apart from the show which I did go to see in Berlin at the time, lack of soundpressure and all. The idea of the main player going through all kinds of possible lets say mindframes, including the various ways of being against the world for various (good and selfish) is at least more illustrative than most things I've seen recently. Is that because part of my highschool experience was 'just another brick in the wall' and it just happens to have formed some 'I like' patterns in my brain when the areas easily had high plasticity? No, I don't think so, I think luckily such hits were around, heard often, and listened to by me, even if it were only for the musical learning of those type of rock songs, lyrics, song buildup, guitar solos and productions.

The magic carpet ride idea was because I was sort of taken by a version of a tcl/tk application called VisualTk, with some additions, which is realy more than little cool for building at least various serious applications in quite profi way, while looking over its options, including such pleasurable features as mouse drawing user interface layouts and development application state checkpointing. While trying this stuff out and getting those sort of things working neatly and understandable over an almost funky interface (wrong word, its sort of an association), I clicked up the 'Vintage Rock' channel on netradio.com ('.com', that sort of bow is very american language, too, in my opinion) and was treated to the title song by Steppenwolf  ('buy now / rate this track') followed by the romantics' What I Like about You. Under normal financial circumstances to be followed by a good meal, a warm enough sunset, and yet another day would have been quite, quite good. Maybe with the addition of a major amp system instead of headphones...