I like these suggestions. Jon
On Fri, 17 Feb 2023 at 09:14, René Jansen <rvjan...@xs4all.nl> wrote: > One idea here is to no change the options of TRACE at all (they are very > portable over variants). For implementations that have threads, why don’t > we add a > > TRACE THREADS > > before the trace statement. We can have an TRACE THREADS OFF option to > switch back to the regular trace. > > also, a > > TRACE THREAD x > > would just trace a named thread. Assuming we name them, which would be > better than following the OS. > > In this vein, I would very much like a > > TRACE TIME > > which timestamps trace messages (for performance work), combinable with > threads. > > This would have the advantage of keeping TRACE the same on implementations > and add the extra line length when asked for it. > It can also be done in OPTIONS - where the general line should be that > unknown options are just ignored. > > best regards, > > René. > > On 16 Feb 2023, at 22:42, Rony <rony.flatsc...@wu.ac.at> wrote: > > > 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 > > _______________________________________________ > 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
