> Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw <m...@speleotrove.com>: > > As for the 'spaced out' case (excerpt below) ... this really would not work > for me. I often have 5-9 windows open when I'm programming and these are 80 > characters wide so I can minimise overlaps. With the suggested layout this > would only work for programs less than ~40 characters wide! Here's how the > excerpt looks for me (and this example has very short lines -- most of my > programs use 72 or more characters per line for better commentary): > > ---> mt91.rex_nr_1_via_JSR223 > R1 T1 A1 3 *-* t=.Test~new > R1 T1 A2 V1 1* 21 *-* say "arrived in:" .context~name > arrived in: INIT > R1 T1 A2 V1 1* 22 *-* counter=0 > R1 T1 A1 >>> "a TEST" > R1 T1 A1 4 *-* t~m1 > R1 T1 A3 V1 1* 27 *-* counter+=1 -- increase counter > R1 T1 A3 V1 1* 28 *-* say "arrived in:" .context~name > "before reply" > > Almost any line of any length will wrap. That's why the trace headers in > Rexx are kept as short as feasible. Yes trace has been well thought out and well designed.
It seems that you are under the impression that this extra trace information should get added to trace by default? If so, that is not the case. In effect as designed and communicated (maybe badly), you need to activate this extra trace information explicitly which you would do only, if you have an important reason: needing additional information in order to become able to debug multithreaded programs. You would so only, if it helps, if it benefits the programmer in understanding and debugging. Otherwise the option would not be used. You would probably not be a candidate needing this extra information (assuming that you are not employing ooRexx‘ multithreading) so you would not activate it and everything would remain the same for your specific configured working environment. Nothing changes for you. Those who are in need will be more than happy to get these extra information to save a lot of time and becoming able to analyze and to understand multithreaded problems. Without this extra, multithreaded related trace information it would not be possible the more complex, the more interleaved multithreaded execution takes place. Just look at the trace, trace with thread number and with extended/mulithreading-related trace e.g. with the mt91.rex example in my earlier post: without the multithreaded/extended trace no one could understand what really happens there. This is the core of the problem: trace has not been extended to supply this necessary multithreaded/extended information in case multithreading causes problems and the programmer requests the multithreaded-related/extra information with trace. > Adding an unexplained 27 characters on the front of each line makes little > sense, „Unexplained“, hence „surprising“? Seriously, this extended trace information would get created only if the ooRexx programmer/user requests it explicitly. To be able to request the multithreaded trace one needs to be aware a) it exists and b) the option to get it activated. This is only possible if the programmer/user reads the documentation which will include the explanation of what the extra trace information is about: ‚R‘ is the Rexx instance, ‚T‘ is the thread number, ‚A‘ is the activation (invocation), ‚V‘ is the variable pool, the number column shows the number of requested locks, the asterisk the owner of the lock (that may cause deadlocks for others). The mnemonics make it easy to remember. Everyone who read that or got the explanation for the letters will be able understand what is being presented. So, they get explained and everyone who read the documentation would understand. Also, it is easy to explain (hence also easy to understand), but only if this information is made available. > especially as the information is the same on most lines, The information repeats in some columns in these traces. The purpose of this is to become able to spot and analyze immediately lines that deviate, e.g. the Rexx instance number changes, the thread number changes, the activation number changes etc. which is the case when concurrently other parts get executed, interleaving with the trace lines that otherwise have a few columns in common. Without the multithreaded/extra information one is not able to notice that at all! This is exactly the problem in multithreaded programs, the more concurrency the more important to become able to notice that in order to become able to analyze and for that reason you need to carry these information! > and as I mentioned before is not user-friendly (here I mean 'user' as being a > writer of Rexx programs, not someone who runs a Rexx program without looking > at it or caring which language it is written in). This is where we differ: leaving that away to make it ‚user-friendly‘ by your definition (keep what you see as redundancy out, saving space to keep the lines within 80 columns etc.) makes it impossible for the ‚user‘ to find out how his program gets executed in a multithreaded environment (application hosted and/or self induced) and in case of a problem to become able to find the cause. The ‚user‘ is rendered helpless in such a situation. Of course you are right that this extended information is not necessary for non-concurrent Rexx programs, which classic Rexx programs are by nature (not having the means in the language to kick off multithreading). Therefore it goes without saying that the multithreaded/extended trace needs to be off by default. A user will activate multithreading trace only if he gets additional helpful information for his program and problem. As I teach every semester newcomers to ooRexx and can observe where and why students get into problems and loose (sometimes literally weeks) because of problems in multithreaded environments because of lack of related trace information supplied by ooRexx. This is typically in GUI environments (awt/swing, JavaFX), something that is very important to master in today‘s world. They would become able to see and analyze how their Rexx programs execute in such an environment. Currently, they can only try to code SAY debug statements scattered over their code and still will not have information like which activation owns at a certain point in the execution thread the lock and which ones are blocked etc. (The available multithreaded trace supplies exactly these insights which would help them immediately and a lot.) To sum up: the multithreaded trace is not meant to be active by default. A programmer/user needs to activate it and if he is doing so, there must be a good reason as the produced extra debug information may be overwhelming (but extremely helpful and time-saving). Any Rexx programmer/user that does not employ multithreading will never activate that option and everything remains untouched and the way it has been for the last 40 years. —- If you have alternative ideas about how one could come up with the same information for multithreaded ooRexx programs in a manner, that you see more user friendly and carries comparable explanation and problem solving power then I really would be interested in it. The main use case is a deadlock due to multithreading issues in some ooRexx program(s). —-rony
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
