Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

Hi Jon,

On 12.08.2021 14:38, Sahananda Sahananda wrote:
> Thanks for taking care of that.  Sorry I started this.

Nothing to be sorry about! At the time it made sense for everyone else as well. 
(Only the methods in
callbacks coming from different threads need to be unguarded such that they can 
run concurrently to
another method on a different thread that may have caused that callback, and 
the like ..)

Sometimes that is the fate of innovation: trying to improve something, but for 
unforseen
side-effects stepping back and backing out. Most of the time the innovations 
stick! :)

Cheers

---rony


>
> On Thu, 12 Aug 2021, 13:26 Rony G. Flatscher,  > wrote:
>
> Backed out and as a reslut rejecting RFE 720, cf.
> 
> .
>
> ---rony
>
> On 11.08.2021 13:21, Rony G. Flatscher wrote:
>> On 10.08.2021 18:07, Rick McGuire wrote:
>>> No, this is way too complicated to add. It would be better to just back 
>>> out the feature,
>>> which was only added under the assumption that there was no detectable 
>>> effect in doing so.
>>> The guarded/nonguarded state clearly protects more than just the 
>>> variable state of the
>>> object, it also synchronizes the order of invocations of any methods 
>>> called from within the
>>> method.
>>
>> +1
>>
>> So would revert the changes applied as recorded in
>> 
>>  in reverse 
>> order from the svn root,
>> like:
>>
>> svn merge -r 12141:12140 .
>> svn ci -m "Backed out r12141."
>>
>> svn merge -r 12006:12005 .
>> svn ci -m "Backed out r12006."
>>
>> Would that be the correct sequence?
>>
>> Anything to watch out, any suggestions otherwise?
>>
>> ---rony
>>
>>>
>>> On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher 
>>> >> > wrote:
>>>
>>> To keep the best of both worlds I propose to allow to activate this 
>>> particular feature
>>> (defaulting methods to unguarded if the first statement neither 
>>> starts with EXPOSE nor
>>> with USE LOCAL) with a new option "unguarded" on the options 
>>> directive, i.e.:
>>>
>>> ::options unguarded
>>>
>>> Enclosed please find the intended patch (tested) with request for 
>>> comment.
>>>
>>> Will update the documentation (rexxref) and the method directive 
>>> test unit accordingly.
>>>
>>> ---rony
>>>
>>> P.S.: With the patch applied the following program:
>>>
>>> say 'OPTIONS UNGUARDED set ...'
>>>
>>> do i=1 to 5
>>>m=.Test1~method("M"i)
>>>say "m"i"~isGuarded:" m~isGuarded
>>> end
>>>
>>> ::options unguarded
>>>
>>> ::class Test1
>>>
>>> ::method m1
>>>  say 'm1'
>>>
>>> ::method m2
>>>   expose a
>>>
>>> ::method m3
>>>   use local
>>>
>>> ::method m4 guarded
>>>
>>> ::method m5 unguarded
>>>
>>> will yield the following (expected) output:
>>>
>>> OPTIONS UNGUARDED set ...
>>> m1~isGuarded: 0
>>> m2~isGuarded: 1
>>> m3~isGuarded: 1
>>> m4~isGuarded: 1
>>> m5~isGuarded: 0
>>>
>>> Without the new "unguarded" subdirective of the options directive 
>>> in effect method m1
>>> will be guarded by default (the original behavior).
>>>
>>>
>>> On 07.08.2021 18:28, Rony G. Flatscher wrote:

 Sleeping and thinking more over it I would suggest to remove this 
 feature altogether!
 The major reasing being that the Rexx philosophy (and ooRexx by 
 extension) should make
 coding as easy as possible for programmers.

 The default for methods (and related) has always been "guarded" 
 such that one would not
 have to write "guarded" to the method directive. With that default 
 only in very rare
 cases (in multithreaded scenarios) would one have to write 
 "unguarded" to a method
 directive. And if doing so one must have an understanding of 
 multithreading and the
 ramifications if someone would want a method to run unguarded.

 Compare this to the current situation with this new feature on: in 
 order to fix
 BSF.CLS  all of a sudden I had to add the keyword "guarded" to 
 every method to gain the
 default behaviour for ooRexx < 5.0 and thereby re-enabling correct 
 execution of GUI
 nutshell examples.

 Ad feature: originally it was thought to be helpful to programmers 
 by saving the
   

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Sahananda Sahananda]

Rony,

Thanks for taking care of that.  Sorry I started this.

Jon

On Thu, 12 Aug 2021, 13:26 Rony G. Flatscher, 
wrote:

> Backed out and as a reslut rejecting RFE 720, cf.
> 
> .
>
> ---rony
> On 11.08.2021 13:21, Rony G. Flatscher wrote:
>
> On 10.08.2021 18:07, Rick McGuire wrote:
>
> No, this is way too complicated to add. It would be better to just back
> out the feature, which was only added under the assumption that there was
> no detectable effect in doing so. The guarded/nonguarded state clearly
> protects more than just the variable state of the object, it also
> synchronizes the order of invocations of any methods called from within the
> method.
>
> +1
>
> So would revert the changes applied as recorded in
> 
>  in reverse order
> from the svn root, like:
>
> svn merge -r 12141:12140 .
> svn ci -m "Backed out r12141."
>
> svn merge -r 12006:12005 .
> svn ci -m "Backed out r12006."
>
> Would that be the correct sequence?
>
> Anything to watch out, any suggestions otherwise?
>
> ---rony
>
>
> On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> To keep the best of both worlds I propose to allow to activate this
>> particular feature (defaulting methods to unguarded if the first statement
>> neither starts with EXPOSE nor with USE LOCAL) with a new option
>> "unguarded" on the options directive, i.e.:
>>
>> ::options unguarded
>>
>> Enclosed please find the intended patch (tested) with request for
>> comment.
>>
>> Will update the documentation (rexxref) and the method directive test
>> unit accordingly.
>>
>> ---rony
>>
>> P.S.: With the patch applied the following program:
>>
>> say 'OPTIONS UNGUARDED set ...'
>>
>> do i=1 to 5
>>m=.Test1~method("M"i)
>>say "m"i"~isGuarded:" m~isGuarded
>> end
>>
>> ::options unguarded
>>
>> ::class Test1
>>
>> ::method m1
>>  say 'm1'
>>
>> ::method m2
>>   expose a
>>
>> ::method m3
>>   use local
>>
>> ::method m4 guarded
>>
>> ::method m5 unguarded
>>
>>
>> will yield the following (expected) output:
>>
>> OPTIONS UNGUARDED set ...
>> m1~isGuarded: 0
>> m2~isGuarded: 1
>> m3~isGuarded: 1
>> m4~isGuarded: 1
>> m5~isGuarded: 0
>>
>> Without the new "unguarded" subdirective of the options directive in
>> effect method m1 will be guarded by default (the original behavior).
>>
>>
>> On 07.08.2021 18:28, Rony G. Flatscher wrote:
>>
>> Sleeping and thinking more over it I would suggest to remove this feature
>> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
>> extension) should make coding as easy as possible for programmers.
>>
>> The default for methods (and related) has always been "guarded" such that
>> one would not have to write "guarded" to the method directive. With that
>> default only in very rare cases (in multithreaded scenarios) would one have
>> to write "unguarded" to a method directive. And if doing so one must have
>> an understanding of multithreading and the ramifications if someone would
>> want a method to run unguarded.
>>
>> Compare this to the current situation with this new feature on: in order
>> to fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every
>> method to gain the default behaviour for ooRexx < 5.0 and thereby
>> re-enabling correct execution of GUI nutshell examples.
>>
>> Ad feature: originally it was thought to be helpful to programmers by
>> saving the programmers to write "unguarded" to a method directive for a
>> method that is known to be safe in unguarded mode thinking that methods
>> that have no direct access to the attribute pool (i.e. the method routine
>> would not start with "expose" or "use local") qualify for unguarded
>> execution not thinking about scenarios where this is not enough.
>>
>> To make it easy for the programmer (i.e. not having to know additional,
>> sometimes quite subtle, concepts that play a role in this context) I would
>> be in a strong favor to leave the default "guarded" in place. Then either
>> remove this new feature altogether or make it an explicit option a
>> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>>
>> What opinions have others? Do you concur?
>>
>> ---rony
>>
>>
>> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>>
>> Background: In order for ooRexx programmers getting acquainted with
>> BSF4ooRexx/Java quickly there are numerous nutshell examples in
>> "bsf4rexx/samples". Most of these nutshell examples stem from observations
>> of students over time who should get help by demonstrating them how to
>> achieve something of interest with these (mostly brief) nutshell examples.
>>
>> One interesting problem has been the interaction from ooRexx with GUI
>> objects which must be carried out on the GUI threads in Java (the "awt
>> thread" or 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

Backed out and as a reslut rejecting RFE 720, cf.
.

---rony

On 11.08.2021 13:21, Rony G. Flatscher wrote:
> On 10.08.2021 18:07, Rick McGuire wrote:
>> No, this is way too complicated to add. It would be better to just back out 
>> the feature, which
>> was only added under the assumption that there was no detectable effect in 
>> doing so. The
>> guarded/nonguarded state clearly protects more than just the variable state 
>> of the object, it
>> also synchronizes the order of invocations of any methods called from within 
>> the method.
>
> +1
>
> So would revert the changes applied as recorded in
>  in reverse order 
> from the svn root, like:
>
> svn merge -r 12141:12140 .
> svn ci -m "Backed out r12141."
>
> svn merge -r 12006:12005 .
> svn ci -m "Backed out r12006."
>
> Would that be the correct sequence?
>
> Anything to watch out, any suggestions otherwise?
>
> ---rony
>
>>
>> On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher > > wrote:
>>
>> To keep the best of both worlds I propose to allow to activate this 
>> particular feature
>> (defaulting methods to unguarded if the first statement neither starts 
>> with EXPOSE nor with
>> USE LOCAL) with a new option "unguarded" on the options directive, i.e.:
>>
>> ::options unguarded
>>
>> Enclosed please find the intended patch (tested) with request for 
>> comment.
>>
>> Will update the documentation (rexxref) and the method directive test 
>> unit accordingly.
>>
>> ---rony
>>
>> P.S.: With the patch applied the following program:
>>
>> say 'OPTIONS UNGUARDED set ...'
>>
>> do i=1 to 5
>>m=.Test1~method("M"i)
>>say "m"i"~isGuarded:" m~isGuarded
>> end
>>
>> ::options unguarded
>>
>> ::class Test1
>>
>> ::method m1
>>  say 'm1'
>>
>> ::method m2
>>   expose a
>>
>> ::method m3
>>   use local
>>
>> ::method m4 guarded
>>
>> ::method m5 unguarded
>>
>> will yield the following (expected) output:
>>
>> OPTIONS UNGUARDED set ...
>> m1~isGuarded: 0
>> m2~isGuarded: 1
>> m3~isGuarded: 1
>> m4~isGuarded: 1
>> m5~isGuarded: 0
>>
>> Without the new "unguarded" subdirective of the options directive in 
>> effect method m1 will be
>> guarded by default (the original behavior).
>>
>>
>> On 07.08.2021 18:28, Rony G. Flatscher wrote:
>>>
>>> Sleeping and thinking more over it I would suggest to remove this 
>>> feature altogether! The
>>> major reasing being that the Rexx philosophy (and ooRexx by extension) 
>>> should make coding as
>>> easy as possible for programmers.
>>>
>>> The default for methods (and related) has always been "guarded" such 
>>> that one would not have
>>> to write "guarded" to the method directive. With that default only in 
>>> very rare cases (in
>>> multithreaded scenarios) would one have to write "unguarded" to a 
>>> method directive. And if
>>> doing so one must have an understanding of multithreading and the 
>>> ramifications if someone
>>> would want a method to run unguarded.
>>>
>>> Compare this to the current situation with this new feature on: in 
>>> order to fix BSF.CLS  all
>>> of a sudden I had to add the keyword "guarded" to every method to gain 
>>> the default behaviour
>>> for ooRexx < 5.0 and thereby re-enabling correct execution of GUI 
>>> nutshell examples.
>>>
>>> Ad feature: originally it was thought to be helpful to programmers by 
>>> saving the programmers
>>> to write "unguarded" to a method directive for a method that is known 
>>> to be safe in
>>> unguarded mode thinking that methods that have no direct access to the 
>>> attribute pool (i.e.
>>> the method routine would not start with "expose" or "use local") 
>>> qualify for unguarded
>>> execution not thinking about scenarios where this is not enough.
>>>
>>> To make it easy for the programmer (i.e. not having to know additional, 
>>> sometimes quite
>>> subtle, concepts that play a role in this context) I would be in a 
>>> strong favor to leave the
>>> default "guarded" in place. Then either remove this new feature 
>>> altogether or make it an
>>> explicit option a programmer has to state ("::OPTIONS" with a new pair 
>>> "guarded|unguarded").
>>>
>>> What opinions have others? Do you concur?
>>>
>>> ---rony
>>>
>>>
>>> On 06.08.2021 15:09, Rony G. Flatscher wrote:

 Background: In order for ooRexx programmers getting acquainted with 
 BSF4ooRexx/Java quickly
 there are numerous nutshell examples in "bsf4rexx/samples". Most of 
 these nutshell examples
 stem from observations of students over time who should get help by 
 demonstrating 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

On 10.08.2021 18:07, Rick McGuire wrote:
> No, this is way too complicated to add. It would be better to just back out 
> the feature, which was
> only added under the assumption that there was no detectable effect in doing 
> so. The
> guarded/nonguarded state clearly protects more than just the variable state 
> of the object, it also
> synchronizes the order of invocations of any methods called from within the 
> method.

+1

So would revert the changes applied as recorded in
 in reverse order from 
the svn root, like:

svn merge -r 12141:12140 .
svn ci -m "Backed out r12141."

svn merge -r 12006:12005 .
svn ci -m "Backed out r12006."

Would that be the correct sequence?

Anything to watch out, any suggestions otherwise?

---rony

>
> On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher  > wrote:
>
> To keep the best of both worlds I propose to allow to activate this 
> particular feature
> (defaulting methods to unguarded if the first statement neither starts 
> with EXPOSE nor with
> USE LOCAL) with a new option "unguarded" on the options directive, i.e.:
>
> ::options unguarded
>
> Enclosed please find the intended patch (tested) with request for comment.
>
> Will update the documentation (rexxref) and the method directive test 
> unit accordingly.
>
> ---rony
>
> P.S.: With the patch applied the following program:
>
> say 'OPTIONS UNGUARDED set ...'
>
> do i=1 to 5
>m=.Test1~method("M"i)
>say "m"i"~isGuarded:" m~isGuarded
> end
>
> ::options unguarded
>
> ::class Test1
>
> ::method m1
>  say 'm1'
>
> ::method m2
>   expose a
>
> ::method m3
>   use local
>
> ::method m4 guarded
>
> ::method m5 unguarded
>
> will yield the following (expected) output:
>
> OPTIONS UNGUARDED set ...
> m1~isGuarded: 0
> m2~isGuarded: 1
> m3~isGuarded: 1
> m4~isGuarded: 1
> m5~isGuarded: 0
>
> Without the new "unguarded" subdirective of the options directive in 
> effect method m1 will be
> guarded by default (the original behavior).
>
>
> On 07.08.2021 18:28, Rony G. Flatscher wrote:
>>
>> Sleeping and thinking more over it I would suggest to remove this 
>> feature altogether! The
>> major reasing being that the Rexx philosophy (and ooRexx by extension) 
>> should make coding as
>> easy as possible for programmers.
>>
>> The default for methods (and related) has always been "guarded" such 
>> that one would not have
>> to write "guarded" to the method directive. With that default only in 
>> very rare cases (in
>> multithreaded scenarios) would one have to write "unguarded" to a method 
>> directive. And if
>> doing so one must have an understanding of multithreading and the 
>> ramifications if someone
>> would want a method to run unguarded.
>>
>> Compare this to the current situation with this new feature on: in order 
>> to fix BSF.CLS  all
>> of a sudden I had to add the keyword "guarded" to every method to gain 
>> the default behaviour
>> for ooRexx < 5.0 and thereby re-enabling correct execution of GUI 
>> nutshell examples.
>>
>> Ad feature: originally it was thought to be helpful to programmers by 
>> saving the programmers
>> to write "unguarded" to a method directive for a method that is known to 
>> be safe in unguarded
>> mode thinking that methods that have no direct access to the attribute 
>> pool (i.e. the method
>> routine would not start with "expose" or "use local") qualify for 
>> unguarded execution not
>> thinking about scenarios where this is not enough.
>>
>> To make it easy for the programmer (i.e. not having to know additional, 
>> sometimes quite
>> subtle, concepts that play a role in this context) I would be in a 
>> strong favor to leave the
>> default "guarded" in place. Then either remove this new feature 
>> altogether or make it an
>> explicit option a programmer has to state ("::OPTIONS" with a new pair 
>> "guarded|unguarded").
>>
>> What opinions have others? Do you concur?
>>
>> ---rony
>>
>>
>> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>>>
>>> Background: In order for ooRexx programmers getting acquainted with 
>>> BSF4ooRexx/Java quickly
>>> there are numerous nutshell examples in "bsf4rexx/samples". Most of 
>>> these nutshell examples
>>> stem from observations of students over time who should get help by 
>>> demonstrating them how
>>> to achieve something of interest with these (mostly brief) nutshell 
>>> examples.
>>>
>>> One interesting problem has been the interaction from ooRexx with GUI 
>>> objects which must be
>>> carried out on the GUI threads in Java (the "awt thread" or the "JavaFX 
>>> Application
>>> thread"). 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rick McGuire]

No, this is way too complicated to add. It would be better to just back out
the feature, which was only added under the assumption that there was no
detectable effect in doing so. The guarded/nonguarded state clearly
protects more than just the variable state of the object, it also
synchronizes the order of invocations of any methods called from within the
method.

Rick

On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher 
wrote:

> To keep the best of both worlds I propose to allow to activate this
> particular feature (defaulting methods to unguarded if the first statement
> neither starts with EXPOSE nor with USE LOCAL) with a new option
> "unguarded" on the options directive, i.e.:
>
> ::options unguarded
>
> Enclosed please find the intended patch (tested) with request for comment.
>
> Will update the documentation (rexxref) and the method directive test unit
> accordingly.
>
> ---rony
>
> P.S.: With the patch applied the following program:
>
> say 'OPTIONS UNGUARDED set ...'
>
> do i=1 to 5
>m=.Test1~method("M"i)
>say "m"i"~isGuarded:" m~isGuarded
> end
>
> ::options unguarded
>
> ::class Test1
>
> ::method m1
>  say 'm1'
>
> ::method m2
>   expose a
>
> ::method m3
>   use local
>
> ::method m4 guarded
>
> ::method m5 unguarded
>
>
> will yield the following (expected) output:
>
> OPTIONS UNGUARDED set ...
> m1~isGuarded: 0
> m2~isGuarded: 1
> m3~isGuarded: 1
> m4~isGuarded: 1
> m5~isGuarded: 0
>
> Without the new "unguarded" subdirective of the options directive in
> effect method m1 will be guarded by default (the original behavior).
>
>
> On 07.08.2021 18:28, Rony G. Flatscher wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
> extension) should make coding as easy as possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that
> one would not have to write "guarded" to the method directive. With that
> default only in very rare cases (in multithreaded scenarios) would one have
> to write "unguarded" to a method directive. And if doing so one must have
> an understanding of multithreading and the ramifications if someone would
> want a method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order
> to fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every
> method to gain the default behaviour for ooRexx < 5.0 and thereby
> re-enabling correct execution of GUI nutshell examples.
>
> Ad feature: originally it was thought to be helpful to programmers by
> saving the programmers to write "unguarded" to a method directive for a
> method that is known to be safe in unguarded mode thinking that methods
> that have no direct access to the attribute pool (i.e. the method routine
> would not start with "expose" or "use local") qualify for unguarded
> execution not thinking about scenarios where this is not enough.
>
> To make it easy for the programmer (i.e. not having to know additional,
> sometimes quite subtle, concepts that play a role in this context) I would
> be in a strong favor to leave the default "guarded" in place. Then either
> remove this new feature altogether or make it an explicit option a
> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
>
> ---rony
>
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with
> BSF4ooRexx/Java quickly there are numerous nutshell examples in
> "bsf4rexx/samples". Most of these nutshell examples stem from observations
> of students over time who should get help by demonstrating them how to
> achieve something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI
> objects which must be carried out on the GUI threads in Java (the "awt
> thread" or the "JavaFX Application thread"). Although they got the
> necessary information about the architecture and what to do in ordert to
> become able to send messages on GUI threads, they kept running into
> problems, losing a lot of time (even months because they could not get it
> working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that
> was very easy to understand and to employ for them. None of the students
> ran into the GUI thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows
> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system)
> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread.
> These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and
> dispatched on the GUI thread later.
>
> The nutshell examples
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

To keep the best of both worlds I propose to allow to activate this particular 
feature (defaulting
methods to unguarded if the first statement neither starts with EXPOSE nor with 
USE LOCAL) with a
new option "unguarded" on the options directive, i.e.:

::options unguarded

Enclosed please find the intended patch (tested) with request for comment.

Will update the documentation (rexxref) and the method directive test unit 
accordingly.

---rony

P.S.: With the patch applied the following program:

say 'OPTIONS UNGUARDED set ...'

do i=1 to 5
   m=.Test1~method("M"i)
   say "m"i"~isGuarded:" m~isGuarded
end

::options unguarded

::class Test1

::method m1
 say 'm1'

::method m2
  expose a

::method m3
  use local

::method m4 guarded

::method m5 unguarded

will yield the following (expected) output:

OPTIONS UNGUARDED set ...
m1~isGuarded: 0
m2~isGuarded: 1
m3~isGuarded: 1
m4~isGuarded: 1
m5~isGuarded: 0

Without the new "unguarded" subdirective of the options directive in effect 
method m1 will be
guarded by default (the original behavior).


On 07.08.2021 18:28, Rony G. Flatscher wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature 
> altogether! The major
> reasing being that the Rexx philosophy (and ooRexx by extension) should make 
> coding as easy as
> possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that one 
> would not have to
> write "guarded" to the method directive. With that default only in very rare 
> cases (in
> multithreaded scenarios) would one have to write "unguarded" to a method 
> directive. And if doing
> so one must have an understanding of multithreading and the ramifications if 
> someone would want a
> method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order to 
> fix BSF.CLS  all of a
> sudden I had to add the keyword "guarded" to every method to gain the default 
> behaviour for ooRexx
> < 5.0 and thereby re-enabling correct execution of GUI nutshell examples.
>
> Ad feature: originally it was thought to be helpful to programmers by saving 
> the programmers to
> write "unguarded" to a method directive for a method that is known to be safe 
> in unguarded mode
> thinking that methods that have no direct access to the attribute pool (i.e. 
> the method routine
> would not start with "expose" or "use local") qualify for unguarded execution 
> not thinking about
> scenarios where this is not enough.
>
> To make it easy for the programmer (i.e. not having to know additional, 
> sometimes quite subtle,
> concepts that play a role in this context) I would be in a strong favor to 
> leave the default
> "guarded" in place. Then either remove this new feature altogether or make it 
> an explicit option a
> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
>
> ---rony
>
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>>
>> Background: In order for ooRexx programmers getting acquainted with 
>> BSF4ooRexx/Java quickly there
>> are numerous nutshell examples in "bsf4rexx/samples". Most of these nutshell 
>> examples stem from
>> observations of students over time who should get help by demonstrating them 
>> how to achieve
>> something of interest with these (mostly brief) nutshell examples.
>>
>> One interesting problem has been the interaction from ooRexx with GUI 
>> objects which must be
>> carried out on the GUI threads in Java (the "awt thread" or the "JavaFX 
>> Application thread").
>> Although they got the necessary information about the architecture and what 
>> to do in ordert to
>> become able to send messages on GUI threads, they kept running into 
>> problems, losing a lot of
>> time (even months because they could not get it working in more complex 
>> programs).
>>
>> To make a long story short, I came up with a message based solution, that 
>> was very easy to
>> understand and to employ for them. None of the students ran into the GUI 
>> thread problems since then.
>>
>> The solution is an ooRexx class for awt (the Java "abstract windows 
>> toolkit") named .AwtGuiThread
>> and for JavaFX (a powerful GUI system) .FxGuiThread, both subclassing a 
>> common superclass
>> .AbstractGuiThread. These classes allow one to send the ooRexx message
>> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and 
>> dispatched on the GUI
>> thread later.
>>
>> The nutshell examples 
>> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
>> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj" 
>> demonstrate how to employ
>> this infrastructure. They have been working for years without a problem.
>>
>> While working on BSF4ooRexx I stumbled over an error (not having run those 
>> two examples for quite
>> some time) which seems to indicate that 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Michael Lueck]

Greetings,

Ruurd Idenburg wrote:

I hardly ever use EXPOSE when oo-ing, I am almost always declaring attributes 
and accessing them via self~attribute _name in the methods within the class and 
its subclasses.



EXPOSE was my standard 20 years ago before processor performance gained so 
much. Back then, I could gain performance knowing the memory layout of a class, 
and directly work with the memory.

As I build new code, I also use attributes and getter / setter methods.

I just (a couple months ago) successfully moved to my first new system since 2009. 8GB of RAM was cramped for quite many years. The new system has 32 GB of slow RAM about the slowest the 
motherboard supported, was all that Crucial had in stock.


Total processor threads: 12
This system has 1 six-core processor with hyper-threading (2 threads per core) 
running at an estimated 4.10GHz


No going back to 500 MHz single core and 128MB or 256MB RAM! ;-)

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Ruurd Idenburg]

I hardly ever use EXPOSE when oo-ing, I am almost always declaring 
attributes and accessing them via self~attribute _name in the methods 
within the class and its subclasses.


Ruurd

On 8/7/21 7:59 PM, Sahananda Sahananda wrote:

Hi Guys,

This is awkward, I think this change was made in response to my 
expressing surprise that the guard made a difference to methods which 
have no variables exposed - something that I still don't understand, 
but have no need to understand.  However, if you think it should go, 
then I'm content for it to go.


BTW, and just for correctness sake, I think the default guard state 
was changed before, sometime in version 3.x I think.  I remember that 
I had to change all my oodialog message handling methods to be 
explicitly unguarded.


Jon

On Sat, 7 Aug 2021, 18:36 Jean Louis Faucher, > wrote:


+1

If you run the example 12.4 of rexxref, you will see that it
breaks the rule written just above.


Regards


On 7 Aug 2021, at 18:28, Rony G. Flatscher
mailto:rony.flatsc...@wu.ac.at>> wrote:

Sleeping and thinking more over it I would suggest to remove this
feature altogether! The major reasing being that the Rexx
philosophy (and ooRexx by extension) should make coding as easy
as possible for programmers.

The default for methods (and related) has always been "guarded"
such that one would not have to write "guarded" to the method
directive. With that default only in very rare cases (in
multithreaded scenarios) would one have to write "unguarded" to a
method directive. And if doing so one must have an understanding
of multithreading and the ramifications if someone would want a
method to run unguarded.

Compare this to the current situation with this new feature on:
in order to fix BSF.CLS  all of a sudden I had to add the keyword
"guarded" to every method to gain the default behaviour for
ooRexx < 5.0 and thereby re-enabling correct execution of GUI
nutshell examples.

Ad feature: originally it was thought to be helpful to
programmers by saving the programmers to write "unguarded" to a
method directive for a method that is known to be safe in
unguarded mode thinking that methods that have no direct access
to the attribute pool (i.e. the method routine would not start
with "expose" or "use local") qualify for unguarded execution not
thinking about scenarios where this is not enough.

To make it easy for the programmer (i.e. not having to know
additional, sometimes quite subtle, concepts that play a role in
this context) I would be in a strong favor to leave the default
"guarded" in place. Then either remove this new feature
altogether or make it an explicit option a programmer has to
state ("::OPTIONS" with a new pair "guarded|unguarded").

What opinions have others? Do you concur?

---rony


On 06.08.2021 15:09, Rony G. Flatscher wrote:


Background: In order for ooRexx programmers getting acquainted
with BSF4ooRexx/Java quickly there are numerous nutshell
examples in "bsf4rexx/samples". Most of these nutshell examples
stem from observations of students over time who should get help
by demonstrating them how to achieve something of interest with
these (mostly brief) nutshell examples.

One interesting problem has been the interaction from ooRexx
with GUI objects which must be carried out on the GUI threads in
Java (the "awt thread" or the "JavaFX Application thread").
Although they got the necessary information about the
architecture and what to do in ordert to become able to send
messages on GUI threads, they kept running into problems, losing
a lot of time (even months because they could not get it working
in more complex programs).

To make a long story short, I came up with a message based
solution, that was very easy to understand and to employ for
them. None of the students ran into the GUI thread problems
since then.

The solution is an ooRexx class for awt (the Java "abstract
windows toolkit") named .AwtGuiThread and for JavaFX (a powerful
GUI system) .FxGuiThread, both subclassing a common superclass
.AbstractGuiThread. These classes allow one to send the ooRexx
message runLater[Latest](GUIreceiver, messageName, arguments)
which get queued and dispatched on the GUI thread later.

The nutshell examples
"bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj"
and
"bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
demonstrate how to employ this infrastructure. They have been
working for years without a problem.

While working on BSF4ooRexx I stumbled over an error (not having
run those two examples for quite some time) which seems to
indicate that ooRexx now creates an error when being used from
different threads:

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Sahananda Sahananda]

Hi Guys,

This is awkward, I think this change was made in response to my expressing
surprise that the guard made a difference to methods which have no
variables exposed - something that I still don't understand, but have no
need to understand.  However, if you think it should go, then I'm content
for it to go.

BTW, and just for correctness sake, I think the default guard state was
changed before, sometime in version 3.x I think.  I remember that I had to
change all my oodialog message handling methods to be explicitly unguarded.

Jon

On Sat, 7 Aug 2021, 18:36 Jean Louis Faucher,  wrote:

> +1
>
> If you run the example 12.4 of rexxref, you will see that it breaks the
> rule written just above.
>
>
> Regards
>
> On 7 Aug 2021, at 18:28, Rony G. Flatscher 
> wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
> extension) should make coding as easy as possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that
> one would not have to write "guarded" to the method directive. With that
> default only in very rare cases (in multithreaded scenarios) would one have
> to write "unguarded" to a method directive. And if doing so one must have
> an understanding of multithreading and the ramifications if someone would
> want a method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order
> to fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every
> method to gain the default behaviour for ooRexx < 5.0 and thereby
> re-enabling correct execution of GUI nutshell examples.
>
> Ad feature: originally it was thought to be helpful to programmers by
> saving the programmers to write "unguarded" to a method directive for a
> method that is known to be safe in unguarded mode thinking that methods
> that have no direct access to the attribute pool (i.e. the method routine
> would not start with "expose" or "use local") qualify for unguarded
> execution not thinking about scenarios where this is not enough.
>
> To make it easy for the programmer (i.e. not having to know additional,
> sometimes quite subtle, concepts that play a role in this context) I would
> be in a strong favor to leave the default "guarded" in place. Then either
> remove this new feature altogether or make it an explicit option a
> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
>
> ---rony
>
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with
> BSF4ooRexx/Java quickly there are numerous nutshell examples in
> "bsf4rexx/samples". Most of these nutshell examples stem from observations
> of students over time who should get help by demonstrating them how to
> achieve something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI
> objects which must be carried out on the GUI threads in Java (the "awt
> thread" or the "JavaFX Application thread"). Although they got the
> necessary information about the architecture and what to do in ordert to
> become able to send messages on GUI threads, they kept running into
> problems, losing a lot of time (even months because they could not get it
> working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that
> was very easy to understand and to employ for them. None of the students
> ran into the GUI thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows
> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system)
> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread.
> These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and
> dispatched on the GUI thread later.
>
> The nutshell examples
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
> demonstrate how to employ this infrastructure. They have been working for
> years without a problem.
>
> While working on BSF4ooRexx I stumbled over an error (not having run those
> two examples for quite some time) which seems to indicate that ooRexx now
> creates an error when being used from different threads:
>
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> screenSize: [java.awt.Dimension[width=1920,height=1080]]
> winSize   : [java.awt.Dimension[width=800,height=200]]
> xPos=[560] yPos=[440]
> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
> thread: 23808
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Jean Louis Faucher]

+1

If you run the example 12.4 of rexxref, you will see that it breaks the rule 
written just above.


Regards

> On 7 Aug 2021, at 18:28, Rony G. Flatscher  wrote:
> 
> Sleeping and thinking more over it I would suggest to remove this feature 
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by 
> extension) should make coding as easy as possible for programmers.
> 
> The default for methods (and related) has always been "guarded" such that one 
> would not have to write "guarded" to the method directive. With that default 
> only in very rare cases (in multithreaded scenarios) would one have to write 
> "unguarded" to a method directive. And if doing so one must have an 
> understanding of multithreading and the ramifications if someone would want a 
> method to run unguarded.
> 
> Compare this to the current situation with this new feature on: in order to 
> fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every 
> method to gain the default behaviour for ooRexx < 5.0 and thereby re-enabling 
> correct execution of GUI nutshell examples. 
> Ad feature: originally it was thought to be helpful to programmers by saving 
> the programmers to write "unguarded" to a method directive for a method that 
> is known to be safe in unguarded mode thinking that methods that have no 
> direct access to the attribute pool (i.e. the method routine would not start 
> with "expose" or "use local") qualify for unguarded execution not thinking 
> about scenarios where this is not enough. 
> To make it easy for the programmer (i.e. not having to know additional, 
> sometimes quite subtle, concepts that play a role in this context) I would be 
> in a strong favor to leave the default "guarded" in place. Then either remove 
> this new feature altogether or make it an explicit option a programmer has to 
> state ("::OPTIONS" with a new pair "guarded|unguarded").
> 
> What opinions have others? Do you concur?
> ---rony
> 
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>> Background: In order for ooRexx programmers getting acquainted with 
>> BSF4ooRexx/Java quickly there are numerous nutshell examples in 
>> "bsf4rexx/samples". Most of these nutshell examples stem from observations 
>> of students over time who should get help by demonstrating them how to 
>> achieve something of interest with these (mostly brief) nutshell examples.
>> 
>> One interesting problem has been the interaction from ooRexx with GUI 
>> objects which must be carried out on the GUI threads in Java (the "awt 
>> thread" or the "JavaFX Application thread"). Although they got the necessary 
>> information about the architecture and what to do in ordert to become able 
>> to send messages on GUI threads, they kept running into problems, losing a 
>> lot of time (even months because they could not get it working in more 
>> complex programs).
>> 
>> To make a long story short, I came up with a message based solution, that 
>> was very easy to understand and to employ for them. None of the students ran 
>> into the GUI thread problems since then.
>> 
>> The solution is an ooRexx class for awt (the Java "abstract windows 
>> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system) 
>> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread. These 
>> classes allow one to send the ooRexx message runLater[Latest](GUIreceiver, 
>> messageName, arguments) which get queued and dispatched on the GUI thread 
>> later. 
>> The nutshell examples 
>> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and 
>> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj" 
>> demonstrate how to employ this infrastructure. They have been working for 
>> years without a problem.
>> 
>> While working on BSF4ooRexx I stumbled over an error (not having run those 
>> two examples for quite some time) which seems to indicate that ooRexx now 
>> creates an error when being used from different threads:
>> 
>> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
>> screenSize: [java.awt.Dimension[width=1920,height=1080]]
>> winSize   : [java.awt.Dimension[width=800,height=200]]
>> xPos=[560] yPos=[440]
>> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
>> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
>> thread: 23808
>> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on thread: 
>> 7428
>>*-* Compiled method "DELETE" with scope "Queue".
>>   5727 *-*   msgQueue~delete(idx)   -- delete the guiMsg object
>>   5637 *-* forward message "REMOVEMESSAGE" continue  -- remove all GUI 
>> messages of the same name targeted to the same object
>>207 *-*   .AwtGuiThread~runLaterLatest(label, "setText", "i", str)
>> Error 93 running 
>> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
>>  line 207:  Incorrect
>>  call to method.
>> Error 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

Sleeping and thinking more over it I would suggest to remove this feature 
altogether! The major
reasing being that the Rexx philosophy (and ooRexx by extension) should make 
coding as easy as
possible for programmers.

The default for methods (and related) has always been "guarded" such that one 
would not have to
write "guarded" to the method directive. With that default only in very rare 
cases (in multithreaded
scenarios) would one have to write "unguarded" to a method directive. And if 
doing so one must have
an understanding of multithreading and the ramifications if someone would want 
a method to run
unguarded.

Compare this to the current situation with this new feature on: in order to fix 
BSF.CLS  all of a
sudden I had to add the keyword "guarded" to every method to gain the default 
behaviour for ooRexx <
5.0 and thereby re-enabling correct execution of GUI nutshell examples.

Ad feature: originally it was thought to be helpful to programmers by saving 
the programmers to
write "unguarded" to a method directive for a method that is known to be safe 
in unguarded mode
thinking that methods that have no direct access to the attribute pool (i.e. 
the method routine
would not start with "expose" or "use local") qualify for unguarded execution 
not thinking about
scenarios where this is not enough.

To make it easy for the programmer (i.e. not having to know additional, 
sometimes quite subtle,
concepts that play a role in this context) I would be in a strong favor to 
leave the default
"guarded" in place. Then either remove this new feature altogether or make it 
an explicit option a
programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").

What opinions have others? Do you concur?

---rony


On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with 
> BSF4ooRexx/Java quickly there
> are numerous nutshell examples in "bsf4rexx/samples". Most of these nutshell 
> examples stem from
> observations of students over time who should get help by demonstrating them 
> how to achieve
> something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI objects 
> which must be
> carried out on the GUI threads in Java (the "awt thread" or the "JavaFX 
> Application thread").
> Although they got the necessary information about the architecture and what 
> to do in ordert to
> become able to send messages on GUI threads, they kept running into problems, 
> losing a lot of time
> (even months because they could not get it working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that was 
> very easy to
> understand and to employ for them. None of the students ran into the GUI 
> thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows toolkit") 
> named .AwtGuiThread
> and for JavaFX (a powerful GUI system) .FxGuiThread, both subclassing a 
> common superclass
> .AbstractGuiThread. These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and 
> dispatched on the GUI
> thread later.
>
> The nutshell examples 
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj" 
> demonstrate how to employ this
> infrastructure. They have been working for years without a problem.
>
> While working on BSF4ooRexx I stumbled over an error (not having run those 
> two examples for quite
> some time) which seems to indicate that ooRexx now creates an error when 
> being used from different
> threads:
>
> 
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> screenSize: [java.awt.Dimension[width=1920,height=1080]]
> winSize   : [java.awt.Dimension[width=800,height=200]]
> xPos=[560] yPos=[440]
> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
> thread: 23808
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on 
> thread: 7428
>*-* Compiled method "DELETE" with scope "Queue".
>   5727 *-*   msgQueue~delete(idx)   -- delete the guiMsg object
>   5637 *-* forward message "REMOVEMESSAGE" continue  -- remove all GUI 
> messages of the same name targeted to the same object
>207 *-*   .AwtGuiThread~runLaterLatest(label, "setText", "i", str)
> Error 93 running 
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
>  line 207:  Incorrect
>  call to method.
> Error 93.966:  Incorrect queue index "1".
> a REXXEVENTHANDLER::windowClosing - release lock ('closeApp=.true') which 
> will allow a blocked 'waitForExit' method to resume and return
>
> 

[Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Rony G. Flatscher]

Background: In order for ooRexx programmers getting acquainted with 
BSF4ooRexx/Java quickly there
are numerous nutshell examples in "bsf4rexx/samples". Most of these nutshell 
examples stem from
observations of students over time who should get help by demonstrating them 
how to achieve
something of interest with these (mostly brief) nutshell examples.

One interesting problem has been the interaction from ooRexx with GUI objects 
which must be carried
out on the GUI threads in Java (the "awt thread" or the "JavaFX Application 
thread"). Although they
got the necessary information about the architecture and what to do in ordert 
to become able to send
messages on GUI threads, they kept running into problems, losing a lot of time 
(even months because
they could not get it working in more complex programs).

To make a long story short, I came up with a message based solution, that was 
very easy to
understand and to employ for them. None of the students ran into the GUI thread 
problems since then.

The solution is an ooRexx class for awt (the Java "abstract windows toolkit") 
named .AwtGuiThread
and for JavaFX (a powerful GUI system) .FxGuiThread, both subclassing a common 
superclass
.AbstractGuiThread. These classes allow one to send the ooRexx message 
runLater[Latest](GUIreceiver,
messageName, arguments) which get queued and dispatched on the GUI thread later.

The nutshell examples 
"bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
"bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj" demonstrate 
how to employ this
infrastructure. They have been working for years without a problem.

While working on BSF4ooRexx I stumbled over an error (not having run those two 
examples for quite
some time) which seems to indicate that ooRexx now creates an error when being 
used from different
threads:


F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
screenSize: [java.awt.Dimension[width=1920,height=1080]]
winSize   : [java.awt.Dimension[width=800,height=200]]
xPos=[560] yPos=[440]
a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
thread: 23808
The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on thread: 
7428
   *-* Compiled method "DELETE" with scope "Queue".
  5727 *-*   msgQueue~delete(idx)   -- delete the guiMsg object
  5637 *-* forward message "REMOVEMESSAGE" continue  -- remove all GUI 
messages of the same name targeted to the same object
   207 *-*   .AwtGuiThread~runLaterLatest(label, "setText", "i", str)
Error 93 running 
F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
 line 207:  Incorrect
 call to method.
Error 93.966:  Incorrect queue index "1".
a REXXEVENTHANDLER::windowClosing - release lock ('closeApp=.true') which 
will allow a blocked 'waitForExit' method to resume and return

F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>

and


F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\JavaFX>javafx_update_GUI-from-non-GUI-thread.rxj
a REXXBUTTONHANDLER::handle - starting Rexx thread
The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
thread: 24244
The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on thread: 
14124
   *-* Compiled method "DELETE" with scope "Queue".
  5727 *-*   msgQueue~delete(idx)   -- delete the guiMsg object
  5637 *-* forward message "REMOVEMESSAGE" continue  -- remove all GUI 
messages of the same name targeted to the same object
   194 *-*   .FxGuiThread~runLaterLatest(label, "setText", "i", str)
Error 93 running 
F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\JavaFX\javafx_update_GUI-from-non-GUI-thread.rxj
 line 194: Incorrect call to method.
Error 93.966:  Incorrect queue index "1".

The ooRexx code where the error occurs looks like, lines # 5637 and # 5727 are 
highlighted in green
and bold:

/* 
-
 */
   -- method replaces existing target: this way only the latest sent 
message will get executed!
/** This class method allows to define a Rexx message with its arguments 
that should
*   be processed on the GUI thread. Each invocation will create a new 
GUIMessage
*   from the supplied arguments and returns it for further inspection in 
addition to queueing
*   it for later execution on the GUI thread. Unlike runLater 
this method will
*   first remove any queued messages with the same target and the same 
message name, before
*   queueing this message.
*
*   @param target the target object to receive a message on the GUI thread
*   @param messageName the message name to send to the target on the GUI 
thread
*   @param indicator  optional; indicates