*From:* Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
*Sent:* 22 February 2023 17:43
*To:* oorexx-devel@lists.sourceforge.net
*Subject:* Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx
programs, mt91.rex: on
two Rexx interpreter in
Absolutely agree .. colour can and does make a huge difference. I think
(there may be independent inventions) that I invented syntax colouring in
LEXX (see https://en.wikipedia.org/wiki/LEXX_(text_editor) ). But since
colour terminals had only just became available in 1985 ...
Colouring trace o
On Sun, 26 Feb 2023, at 16:48, Mike Cowlishaw wrote:
> Like Chip (I suspect), I'm beginning to think that this is outside the
> domain of the language and more suited to some external 'specialised tool'
> or just an option to write the trace to a file .. that is, not expected
> to be
> seen
n some useful way to the
human.
Mike
_
From: Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at]
Sent: 22 February 2023 17:43
To: oorexx-devel@lists.sourceforge.net
Subject: Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx
programs, mt91.rex: on two Rexx interpreter instances
As a life-long unabashed fan of Trace, I can see that anyone doing
non-trivial multithreaded Rexx programming would need far more
information than 'Trace I' can provide. However, the sheer volume of
information necessary seems to present no universally acceptable
format to interactively deal w
*Subject:* Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx
programs, mt91.rex: on
two Rexx interpreter instances (RII)
Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw :
As for the 'spaced out' case (excerpt below) ... this really would not work
for me. I often
sign might guess that "1*" refers to thread locks ... :-).
Mike
_
From: Rony [mailto:rony.flatsc...@wu.ac.at]
Sent: 16 February 2023 21:43
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx
programs, m
I like these suggestions.
Jon
On Fri, 17 Feb 2023 at 09:14, René Jansen 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 c
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 T
> Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw :
>
> 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
> wou
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
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
Lurker here... If I understand correctly, these thread numbers would be
from the underlying OS (UNIX, Windows, z/OS...)? If so, you should be aware
that on z/OS thread numbers are *huge*. What they've done under the covers
is obviously to encode other info (TCB address or something?) in the high
pa
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 wrote:
> Thanks for the multiple examples!
>
> As for the 'spaced out' case (excerpt belo
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
Here the code of "mt91.rex", changes (compared to "mt90.rex") in bold, i.e.
commenting :
say "--->" .context~name
trace r
t=.Test~new
t~m1
t~m2
*-- t~block -- wait for both methods to complete* *t**~**start(**"M1"**) **-- asynchroneous!
**t**~**start(**"M2"**) **-- asynchroneo
16 matches
Mail list logo