I cannot help you finding the cause of your problem but I can try to run the
program on various machines and collect some stats.
I have downloaded the complete kit and can launch startTestProgressBar.rex
I can see that the rexx program launches Java and the GUI show up with 3
buttons and a progress bar.
What should I do next? I can click the buttons but see no response (except the
buttons frame changing color to blue). I can see rexxworker in the task list
but that is all.
I have tried to click start some 100 times, no crash so far, I suspect I have
something set up incorrectly
Here are the settings for the Machine
POs-MacBook-Pro:~ po$ rexx -v
Open Object Rexx Version 5.0.0
Build date: Jul 7 2017
Addressing mode: 64
POs-MacBook-Pro:~ po$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
POs-MacBook-Pro:~ po$ rexx -e "call bsf.cls;say ..b4r~version"
When I launch the program from the command line I get the following so I guess
I have something incorrectly set up. Please advice what I should do next.
POs-MacBook-Pro:testapp po$ rexx testprogressbarcontroller
17 *-* myGuiDir=.my.app~testProgressBar.fxml
7 *-* call setupInitializeGUI
REX0097E: Error 97 running /Users/po/testApp/testprogressbarcontroller.REX line
17: Object method not found.
REX0476E: Error 97.1: Object ".MY.APP" does not understand message
POs-MacBook-Pro:testapp po$ bash rexxj.sh testprogressbarcontroller.rex
RexxDispatcher.java: Throwable of type
'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx:
getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9:
17 *-* myGuiDir=.my.app~testProgressBar.fxml
Error 97 running /Users/po/testApp/testProgressBarController.rex line 17:
Object method not found.
Error 97.1: Object ".MY.APP" does not understand message
> Am 07.08.2017 um 19:27 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>:
> Dear René:
> On 07.08.2017 17:10, René Jansen wrote:
>> Memory in multihreaded programs should be strictly guarded.
> AFAIK I am doing that everywhere in BSF4ooRexx.cc (cf. e.g. RgfAcquireLock()
> and RgfReleaseLock()).
>> I know of a few debuggers that can set memory modification watches/traps,
>> one is OS/2’s kernel debugger and the other is MVS’s SLIP SET trap
>> mechanism. From what I see sometimes the register save area is clobbered
>> (assuming you are linking correctly) and you could set a memory modification
>> trap on the register save areas on the stack. Or use any kind of dump
>> service to dump all stacks and investigate the ones of the errant processes.
>> One more thought: if Rexx has a concurrency lock, what would be the point of
>> traversing Rexx code in more than one thread?
> There may be a multithreaded execution of Rexx programs and/or Java programs.
> It should be (and has been) possible to call from any Rexx thread Java and
> from any Java thread Rexx.
> E.g. it has been possible in Java to use any number of RexxEngines (each
> becoming a separate RexxInstance) on the same thread or running on different
> threads concurrently.
>> Wouldn’t it be beneficial to make sure your Java component only calls Rexx
>> sequentially, so you can clean up everything between invocations?
> Everything gets cleaned up between invocations by design (e.g. there are
> reference counters maintained for the objects in Rexx and Java registries
> that control the life time of the stored objects; the key for the Rexx
> registry - a directory - is the Rexx object's identityHash value; the key for
> the Java registry - a Map - is usually the Java Object.toString() value, and
> if needed a counter to make it a truly unique key).
>> I did not read the whole thread very well, but does this also occur on Linux
>> and macOS?
> (Tested it a few minutes ago on a fresh 64-bit Ubuntu ooRexx 5.0beta from
> Sourceforge, August 1st, and the latest BSF4ooRexx, hs_err_-log-file is on
> Best regards,
> On 7 Aug 2017, at 16:55, Rony G. Flatscher <rony.flatsc...@wu.ac.at
> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>> One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx ->
>>> Samples" to get an explorer window. Then changing into "JavaFX" and loading
>>> "index.html" will explain how to run those JavaFX nutshell examples. You
>>> will see why I think it is so important to get the JavaFX support stable by
>>> finding the root cause.
>>> On 07.08.2017 16:31, Rony G. Flatscher wrote:
>>>> Dear Moritz:
>>>> On 07.08.2017 15:02, Moritz Hoffmann wrote:
>>>>> without going into too much detail I would say it's hard to track down
>>>>> the root cause just from the stack traces. It still looks like a memory
>>>>> corruption issue that you're facing, especially because it's not a
>>>>> deterministic failure.
>>>> Yes, it definitely looks like it!
>>>>> I don't see why you want to call into Rexx from different Java threads.
>>>>> Rexx has a global interpreter lock so you won't benefit from parallelism
>>>>> unless you have fully independent Rexx instances.
>>>> The reason is simple: when employing a Java GUI, then it should be
>>>> possible to write event handlers in Rexx and to interact with the GUI
>>>> objects from Rexx.
>>>> If an event is fired by Java, it will be fired on the GUI thread such that
>>>> the Rexx code is able to directly interact with the GUI objects.
>>>> If a Rexx programmer needs to interact with GUI objects from a non-GUI
>>>> thread, then this would hang the GUI. Rather, one needs to make sure that
>>>> the Rexx interaction gets carried out on the GUI thread sometimes later.
>>>> This is
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> Oorexx-devel mailing list
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Oorexx-devel mailing list