From: Jean-Louis F. <jfa...@gm...> - 2012-03-29 08:16:25
|
Hi Rony I have a crash when running this code from ooRexxTry.rxj (using rexx from trunk under winXP) : say "one" reply say "two" No crash with this code : .stdout~lineout("one") reply .stdout~lineout("two") I did not investigate a lot... Maybe you have an idea of what happens ? Seems that the redirection to GUI streams does not work if called from another thread. This case is quite common with coactivities, this is how I met the problem in my sandbox : {::coactivity say "something"}~do Jean-Louis |
From: Rony G. F. <Ron...@wu...> - 2012-03-29 13:56:08
|
Hi Jean-Louis, On 29.03.2012 10:16, Jean-Louis Faucher wrote: > I have a crash when running this code from ooRexxTry.rxj (using rexx from trunk under winXP) : > > say "one" > reply > say "two" > > No crash with this code : > > .stdout~lineout("one") > reply > .stdout~lineout("two") > > I did not investigate a lot... Maybe you have an idea of what happens ? Hmm, no, no idea. In either case the error one 2 *-* reply Error 99 running F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\utilities\test\test2.rex line 2: Translation error Error 99.919: REPLY can only be issued in an object method invocation should be raised. [Looking into the current implementation .method is used to create the executable, which allows for the reply keyword statement; maybe an instance of .routine should be used instead for executing the code?] In the first case the .output-monitor is used, in the second case explicitly the stream object .stdout. Not sure, why Rexx behaves differently. > Seems that the redirection to GUI streams does not work if called from another thread. Not sure whether it has to do with the GUI at all. > This case is quite common with coactivities, this is how I met the problem in my sandbox : > {::coactivity say "something"}~do Hmm, I see. :( Unfortunately, currently ("fully land under water") I am not able to dig further into it in order to find out what the problem(s) could be. From the "gut feeling" it should have something to do with ooRexx, rather than BSF4ooRexx. --- The crash seems to occur in ooRexx itself, so maybe you can have a debug instance of ooRexx to look into it to see why it works in one case, but not in the other? ---rony |
From: Rony G. F. <Ron...@wu...> - 2012-03-29 14:38:45
|
Bonsoir Jean-Louis, thinking about it, the difference is that indeed the say-output is redirected to the GUI, which means that actually Java gets involved. If a new Rexx thread executes and interacts with Java (have to analyze that as that code is not from me but by a student who is not available anymore), one first needs to use BSFAttachToTID(tid) before interacting with Java and before ending that Rexx thread a BSFDetach() should be carried out. The "tid" should be retrieved using BSFGetTid() from the Rexx thread which has an established communication with Java. It could be then the case, that for whatever reasons (need to get to see the stack trace and values of the ooRexx object references) a situation arises which causes NULL to be submitted to Rexx where it is expected that NULL does not get supplied and then causing the crash. Again, sorry, that currently I am not able to really look into it! Best regards, ---rony On 29.03.2012 15:55, Rony G. Flatscher wrote: > Hi Jean-Louis, > > On 29.03.2012 10:16, Jean-Louis Faucher wrote: >> I have a crash when running this code from ooRexxTry.rxj (using rexx from trunk under winXP) : >> >> say "one" >> reply >> say "two" >> >> No crash with this code : >> >> .stdout~lineout("one") >> reply >> .stdout~lineout("two") >> >> I did not investigate a lot... Maybe you have an idea of what happens ? > Hmm, no, no idea. In either case the error > > one > 2 *-* reply > Error 99 running F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\utilities\test\test2.rex line 2: > Translation error > Error 99.919: REPLY can only be issued in an object method invocation > > should be raised. > [Looking into the current implementation .method is used to create the executable, which allows > for the reply keyword statement; maybe an instance of .routine should be used instead for > executing the code?] > > In the first case the .output-monitor is used, in the second case explicitly the stream object > .stdout. Not sure, why Rexx behaves differently. > > >> Seems that the redirection to GUI streams does not work if called from another thread. > Not sure whether it has to do with the GUI at all. > >> This case is quite common with coactivities, this is how I met the problem in my sandbox : >> {::coactivity say "something"}~do > Hmm, I see. > :( > > Unfortunately, currently ("fully land under water") I am not able to dig further into it in order > to find out what the problem(s) could be. From the "gut feeling" it should have something to do > with ooRexx, rather than BSF4ooRexx. > > --- > > The crash seems to occur in ooRexx itself, so maybe you can have a debug instance of ooRexx to > look into it to see why it works in one case, but not in the other? > > ---rony > |
From: Rony G. F. <Ron...@wu...> - 2012-03-29 14:50:05
|
Bonsoir Jean-Louis, just tested the idea and indeed it works: say "one" tid=BsfGetTId() say "tid:" tid reply /* new Rexx thread */ say "BsfAttachToTid("tid"):" bsfAttachToTid(tid) say "two" call bsfDetach Can run this sucessfully and repeatedly. HTH, ---rony On 29.03.2012 16:38, Rony G. Flatscher wrote: > Bonsoir Jean-Louis, > > thinking about it, the difference is that indeed the say-output is redirected to the GUI, which > means that actually Java gets involved. > > If a new Rexx thread executes and interacts with Java (have to analyze that as that code is not > from me but by a student who is not available anymore), one first needs to use BSFAttachToTID(tid) > before interacting with Java and before ending that Rexx thread a BSFDetach() should be carried > out. The "tid" should be retrieved using BSFGetTid() from the Rexx thread which has an established > communication with Java. > > It could be then the case, that for whatever reasons (need to get to see the stack trace and > values of the ooRexx object references) a situation arises which causes NULL to be submitted to > Rexx where it is expected that NULL does not get supplied and then causing the crash. > > Again, sorry, that currently I am not able to really look into it! > > Best regards, > > ---rony > > > On 29.03.2012 15:55, Rony G. Flatscher wrote: >> Hi Jean-Louis, >> >> On 29.03.2012 10:16, Jean-Louis Faucher wrote: >>> I have a crash when running this code from ooRexxTry.rxj (using rexx from trunk under winXP) : >>> >>> say "one" >>> reply >>> say "two" >>> >>> No crash with this code : >>> >>> .stdout~lineout("one") >>> reply >>> .stdout~lineout("two") >>> >>> I did not investigate a lot... Maybe you have an idea of what happens ? >> Hmm, no, no idea. In either case the error >> >> one >> 2 *-* reply >> Error 99 running F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\utilities\test\test2.rex line 2: >> Translation error >> Error 99.919: REPLY can only be issued in an object method invocation >> >> should be raised. >> [Looking into the current implementation .method is used to create the executable, which allows >> for the reply keyword statement; maybe an instance of .routine should be used instead for >> executing the code?] >> >> In the first case the .output-monitor is used, in the second case explicitly the stream object >> .stdout. Not sure, why Rexx behaves differently. >> >> >>> Seems that the redirection to GUI streams does not work if called from another thread. >> Not sure whether it has to do with the GUI at all. >> >>> This case is quite common with coactivities, this is how I met the problem in my sandbox : >>> {::coactivity say "something"}~do >> Hmm, I see. >> :( >> >> Unfortunately, currently ("fully land under water") I am not able to dig further into it in order >> to find out what the problem(s) could be. From the "gut feeling" it should have something to do >> with ooRexx, rather than BSF4ooRexx. >> >> --- >> >> The crash seems to occur in ooRexx itself, so maybe you can have a debug instance of ooRexx to >> look into it to see why it works in one case, but not in the other? >> >> ---rony >> |
From: Rony G. F. <Ron...@wu...> - 2012-03-29 16:24:30
|
Bonsoir Jean-Louis: just checked-in a fix for this behaviour, such the reported code should run, hence just check out "trunk/bsf4oorexx.dev/utilities/ooRexxTry.rxj" to get at this verison. Please let me know whether this fixes also your observed problem with co-routines. HTH, ---rony On 29.03.2012 16:49, Rony G. Flatscher wrote: > Bonsoir Jean-Louis, > > just tested the idea and indeed it works: > > say "one" > tid=BsfGetTId() > say "tid:" tid > > reply > /* new Rexx thread */ > say "BsfAttachToTid("tid"):" bsfAttachToTid(tid) > say "two" > call bsfDetach > > Can run this sucessfully and repeatedly. > > HTH, > > ---rony > > > > On 29.03.2012 16:38, Rony G. Flatscher wrote: >> Bonsoir Jean-Louis, >> >> thinking about it, the difference is that indeed the say-output is redirected to the GUI, which >> means that actually Java gets involved. >> >> If a new Rexx thread executes and interacts with Java (have to analyze that as that code is not >> from me but by a student who is not available anymore), one first needs to use >> BSFAttachToTID(tid) before interacting with Java and before ending that Rexx thread a BSFDetach() >> should be carried out. The "tid" should be retrieved using BSFGetTid() from the Rexx thread which >> has an established communication with Java. >> >> It could be then the case, that for whatever reasons (need to get to see the stack trace and >> values of the ooRexx object references) a situation arises which causes NULL to be submitted to >> Rexx where it is expected that NULL does not get supplied and then causing the crash. >> >> Again, sorry, that currently I am not able to really look into it! >> >> Best regards, >> >> ---rony >> >> >> On 29.03.2012 15:55, Rony G. Flatscher wrote: >>> Hi Jean-Louis, >>> >>> On 29.03.2012 10:16, Jean-Louis Faucher wrote: >>>> I have a crash when running this code from ooRexxTry.rxj (using rexx from trunk under winXP) : >>>> >>>> say "one" >>>> reply >>>> say "two" >>>> >>>> No crash with this code : >>>> >>>> .stdout~lineout("one") >>>> reply >>>> .stdout~lineout("two") >>>> >>>> I did not investigate a lot... Maybe you have an idea of what happens ? >>> Hmm, no, no idea. In either case the error >>> >>> one >>> 2 *-* reply >>> Error 99 running F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\utilities\test\test2.rex line 2: >>> Translation error >>> Error 99.919: REPLY can only be issued in an object method invocation >>> >>> should be raised. >>> [Looking into the current implementation .method is used to create the executable, which allows >>> for the reply keyword statement; maybe an instance of .routine should be used instead for >>> executing the code?] >>> >>> In the first case the .output-monitor is used, in the second case explicitly the stream object >>> .stdout. Not sure, why Rexx behaves differently. >>> >>> >>>> Seems that the redirection to GUI streams does not work if called from another thread. >>> Not sure whether it has to do with the GUI at all. >>> >>>> This case is quite common with coactivities, this is how I met the problem in my sandbox : >>>> {::coactivity say "something"}~do >>> Hmm, I see. >>> :( >>> >>> Unfortunately, currently ("fully land under water") I am not able to dig further into it in >>> order to find out what the problem(s) could be. From the "gut feeling" it should have something >>> to do with ooRexx, rather than BSF4ooRexx. >>> >>> --- >>> >>> The crash seems to occur in ooRexx itself, so maybe you can have a debug instance of ooRexx to >>> look into it to see why it works in one case, but not in the other? >>> >>> ---rony >>> |
From: Jean-Louis F. <jfa...@gm...> - 2012-03-30 06:47:15
|
Gutem morgen Rony, Thanks a lot for your fix, it works perfectly ! After searching for BsfAttachToTid in trunk, I see in the testgroups that it must be called at the begining of each ooRexx thread. I assume that any call to Java needs a proper thread attachement. I will modify the class .Coactivity to add support for class methods ~onStart and ~onTerminate. Ideally, we should have an exit in ooRexx which is called when a thread starts, and an exit which is called when a thread ends. That would allow to manage transparently BsfAttachToTID and BsfDetach. Something similar to RXINIT and RXTER, but at the thread level. Jean-Louis Le 29 mars 2012 18:24, Rony G. Flatscher <Ron...@wu...> a écrit : > Bonsoir Jean-Louis: > > just checked-in a fix for this behaviour, such the reported code should > run, hence just check out "trunk/bsf4oorexx.dev/utilities/ooRexxTry.rxj" to > get at this verison. > > Please let me know whether this fixes also your observed problem with > co-routines. > > HTH, > > ---rony > > > > On 29.03.2012 16:49, Rony G. Flatscher wrote: > > Bonsoir Jean-Louis, > > just tested the idea and indeed it works: > > say "one" > tid=BsfGetTId() > say "tid:" tid > > reply > /* new Rexx thread */ > say "BsfAttachToTid("tid"):" bsfAttachToTid(tid) > say "two" > call bsfDetach > > Can run this sucessfully and repeatedly. > > HTH, > > ---rony > > > > On 29.03.2012 16:38, Rony G. Flatscher wrote: > > Bonsoir Jean-Louis, > > thinking about it, the difference is that indeed the say-output is > redirected to the GUI, which means that actually Java gets involved. > > If a new Rexx thread executes and interacts with Java (have to analyze > that as that code is not from me but by a student who is not available > anymore), one first needs to use BSFAttachToTID(tid) before interacting > with Java and before ending that Rexx thread a BSFDetach() should be > carried out. The "tid" should be retrieved using BSFGetTid() from the Rexx > thread which has an established communication with Java. > > It could be then the case, that for whatever reasons (need to get to see > the stack trace and values of the ooRexx object references) a situation > arises which causes NULL to be submitted to Rexx where it is expected that > NULL does not get supplied and then causing the crash. > > Again, sorry, that currently I am not able to really look into it! > > Best regards, > > ---rony > > > On 29.03.2012 15:55, Rony G. Flatscher wrote: > > Hi Jean-Louis, > > On 29.03.2012 10:16, Jean-Louis Faucher wrote: > > I have a crash when running this code from ooRexxTry.rxj (using rexx from > trunk under winXP) : > > say "one" > reply > say "two" > > No crash with this code : > > .stdout~lineout("one") > reply > .stdout~lineout("two") > > I did not investigate a lot... Maybe you have an idea of what happens ? > > Hmm, no, no idea. In either case the error > > one > 2 *-* reply > Error 99 running > F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\utilities\test\test2.rex line 2: > Translation error > Error 99.919: REPLY can only be issued in an object method invocation > > should be raised. > [Looking into the current implementation .method is used to create the > executable, which allows for the reply keyword statement; maybe an instance > of .routine should be used instead for executing the code?] > > In the first case the .output-monitor is used, in the second case > explicitly the stream object .stdout. Not sure, why Rexx behaves > differently. > > > Seems that the redirection to GUI streams does not work if called from > another thread. > > Not sure whether it has to do with the GUI at all. > > This case is quite common with coactivities, this is how I met the problem > in my sandbox : > {::coactivity say "something"}~do > > Hmm, I see. > :( > > Unfortunately, currently ("fully land under water") I am not able to dig > further into it in order to find out what the problem(s) could be. From the > "gut feeling" it should have something to do with ooRexx, rather than > BSF4ooRexx. > > --- > > The crash seems to occur in ooRexx itself, so maybe you can have a debug > instance of ooRexx to look into it to see why it works in one case, but not > in the other? > > ---rony > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Bsf4oorexx-devel mailing list > Bsf...@li... > https://lists.sourceforge.net/lists/listinfo/bsf4oorexx-devel > > |
From: Rony G. F. <Ron...@wu...> - 2012-03-30 09:09:58
|
Bonjour Jean-Louis, On 30.03.2012 08:47, Jean-Louis Faucher wrote: > Thanks a lot for your fix, it works perfectly ! *Super*, thank you for letting me know! > After searching for BsfAttachToTid in trunk, I see in the testgroups that it must be called at the > begining of each ooRexx thread. > > I assume that any call to Java needs a proper thread attachement. Yes. > I will modify the class .Coactivity to add support for class methods ~onStart and ~onTerminate. Ad onTerminate: a BsfDetach() should only be carried out, if BsfAttachToTid() was carried out successfully in onStart. > Ideally, we should have an exit in ooRexx which is called when a thread starts, and an exit which > is called when a thread ends. That would allow to manage transparently BsfAttachToTID and > BsfDetach. Something similar to RXINIT and RXTER, but at the thread level. Yes, that would be really great! (The thread init should also carry the TID which is about to create the new thread, if that is possible at all.) ---rony |