Hi, I think Gil talks sense. Most of the time, most or all of the users do not need or want this feature, but when they do, it would be important and should provide all the information they might require.
I may be covering old ground here, but as a user I don't do multithreading on a whim. When I first learnt about it, I got excited about the prospect of improving performance, but then, and probably still now, on Windows all the ooRexx threads run on the same core, so if there are any performance advantages, it seems to me that they would be negligible. Apart from a very few exceptions I pretty much only indulge in multi-threading when forced to by the GUI package. Gil's suggestion provokes two responses in me which I offer in the spirit of helpfulness. 1) If one accepts that this could be an external package, then is it really such a leap to sanction having it contained within the interpreter and subject to our regression testing etc., but requiring something from the user to turn it on. Many applications and services honour the concept of a verbose mode. It doesn't have to be called verbose tracing, it could be called advanced multithread tracing mode or some such. 2) If on the other hand, it does become a separate package in the incubator, and special hooks have to be built into the interpreter for it, then should we not perhaps be more ambitious and aim for the hooks that would be needed to provide a future toy like the IBM Object Rexx Workbench. There must have historically been hooks provided for that, and perhaps they are still there. I mention the workbench, because that is the sort of thing that I'm led to believe young programmers value. Having grown up with merely Xedit and a flowchart template as my IDE I did not miss The Workbench too much personally, but in my opinion, providing a workbench with breakpoint and variable modification capabilities as well as auto-complete and context sensitive help would be a good strategic move for rexx (I am aware of the intelliJ offering, but would advocate taking it further). In case this paragraph might read like I'm demanding the development team pull this rabbit out of a hat here and now, that is not what I'm expecting. I just want us to adopt a strategic direction. I have no idea how, if or when we would get there. just my two-pennies/cents worth On Wed, 15 Feb 2023 at 22:45, Gilbert Barmwater <gi...@bellsouth.net> wrote: > Not being a user who writes multi-threaded ooRexx programs, I have > remained silent until now. However, it seems to me that there are enough > objections to the proposal that would add this to TRACE that we should > consider alternatives. I appreciate the need for the information and the > work done both by Jean-Louis and Rony but perhaps this is better provided > as a stand alone package in the Incubator similar to ooSQLite. Then those > that need the information that this package supplies could retrieve the > package and add the appropriate ::requires directive(s) to their program. > I understand this will require some redesign and may still need additions > to the interpreter to expose the needed data to an external package but I > think we should consider going this route as I do not see a compromise that > will satisfy everyone. Just my 2 opinion for what its worth. Gil > On 2/15/2023 1:59 PM, Rick McGuire wrote: > > I’m in complete agreement with Mike on this. There are better ways to make > this sort of information available than trying to force fit it In to > trace. > > Rick > > On Wed, Feb 15, 2023 at 12:58 PM Mike Cowlishaw <m...@speleotrove.com> > wrote: > >> Thanks for the multiple examples! >> >> 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. Adding an unexplained 27 characters on >> the front of each line makes little sense, especially as the information is >> the same on most lines, 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). >> >> Mike >> >> >> >> >> >> >> >> Multithreading trace output activated: >> >> ---> 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" >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > _______________________________________________ > Oorexx-devel mailing > listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
