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 >>> |