Just like Jon I see myself as a user not a developer (of ooRexx) but in rare cases I would appreciate a trace for multiple threads. We have number of test cases that work when executed as-is but that hang or fail when run in the test framework. I have no opinion on what form it should have but if
I don't know if it is helpful for me to say this, but just in case.
When creating ooDialog scripts (I think of myself principally as a USER of
ooRexx and ooDialog though I also have my users who don't code) I have
sometimes had a great need for this kind of trace.
Things can hang, and it often
On 11.02.2023 20:11, Mike Cowlishaw wrote:
Similar comments: this extra information seems to be aimed at 'developers', not users. A user
seeing the proposed output would have no idea what it means or what it's about. It's astonishing,
in every sense.
Not sure what you mean when writing
Thanks for your feedback.
> Ugh, I don't find this to be helpful information at all.
It's useful, I explained already why, see the CSV screenshot.
We don't have a rexx debugger like the orexx workbench showing the call stack.
But we can have at least the top-level of the call stack, everywhere.
On Sat, Feb 11, 2023 at 12:53 PM Rony G. Flatscher
wrote:
> On 11.02.2023 18:16, Rick McGuire wrote:
>
> Some comments:
>
> 1) the T and A columns are a bit redundant. We really only need a single
> identifier for the thread, having two is just extra clutter.
> 2) The term activity is introduced
On Sat, Feb 11, 2023 at 2:12 PM Mike Cowlishaw wrote:
> Similar comments: this extra information seems to be aimed at
> 'developers', not users. A user seeing the proposed output would have no
> idea what it means or what it's about. It's astonishing, in every sense.
>
> To me this seems
Ugh, I don't find this to be helpful information at all. I can determine
that information just by looking at the thread numbers, the activation
number has no real connection to any concept in the interpreter.
Rick
On Sat, Feb 11, 2023 at 12:33 PM Jean Louis Faucher
wrote:
> A quick feedback
Similar comments: this extra information seems to be aimed at 'developers',
not users. A user seeing the proposed output would have no idea what it
means or what it's about. It's astonishing, in every sense.
To me this seems absolutely contrary to the Rexx principles. If developers
need
On 11.02.2023 18:16, Rick McGuire wrote:
Some comments:
1) the T and A columns are a bit redundant. We really only need a single identifier for the
thread, having two is just extra clutter.
2) The term activity is introduced here without explanation. It doesn't really appear any other
place
In complement of the struct, this is how the infos are collected for each trace
line:
void GetConcurrencyInfos(Activity *activity, RexxActivation *activation,
ConcurrencyInfos )
{
InterpreterInstance *interpreter = (activity ? activity->getInstance() :
NULL);
VariableDictionary
A quick feedback about point 1:
The A column is in fact the activation identifier (RexxActivation).
It’s used to know which method/routine is executing the current line.
The name of this method/routine can be found by looking back in the trace the
first >I> for the current T.
In rexxref,
Some comments:
1) the T and A columns are a bit redundant. We really only need a single
identifier for the thread, having two is just extra clutter.
2) The term activity is introduced here without explanation. It doesn't
really appear any other place in the documentation and is really more of an
12 matches
Mail list logo
