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 <[email protected]> wrote:
> 
> 
>> Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw <[email protected]>:
>>  
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to