Guten tag Rony
Thanks for your fix !
It works, I have the colors.
Le 17 avril 2012 12:33, Rony G. Flatscher <Rony.Flatscher@...> a
> opened a bug for this after seeing that the cause is probably in the
> current beta of BSF4ooRexx (the ooRexx Terminate()-API does not get
> executed), bug nr: 3518749.
> Have a fix for that, which I would ask you to test: will send you the new
> "bsf-rexx-engine.jar" which you should use to replace your current one.
> Please report back, whether this got fixed indeed. (Also, the fixes are
> checked-in already such that you can see for yourself what changes
> On 15.04.2012 18:18, Jean-Louis Faucher wrote:
> Using rexxj, the calls to GCI are working, I get the colors.
> Seems you have correctly identified what to change :-)
> Le 15 avril 2012 17:21, Rony G. Flatscher <rony.flatscher@... écrit :
>> Bon soir, Jean-Louis,
>> Just read on oorexx-dev the e-mail exchange. Vaguely, I can think of
>> what happens and how this can be possibly changed. Will look into this
>> tomorrow, once I am back at my main dev computer.
>> What happens, if you run ooRexxShell via rexxj (note the trailing j,
>> this script gets created by the installation script of BSF4ooRexx,
>> ultimately by install/setupBSF.rex; on Unix it is named rexxj.sh, on
>> Windows rexxj.cmd), does that work for you?
>> Von meinem iPad gesendet
>> Am 15.04.2012 um 13:15 schrieb Jean-Louis Faucher <jfaucher.fr@...
>> Guten tag Rony,
>> It seems that having two activities with a same tread id is a normal
>> case, because the method ActivityManager::getRootActivity has a test for
>> that... This method is called by the API CreateRexxInterpreter, from
>> BSF.cls line 400 : interpret stmt, where stmt == "CALL BsfLoadJava".
>> I think I will forward the question to ooRexx dev list, because there is
>> something strange. The old activity is suspended by
>> ActivityManager::getRootActivity (just a flag set to true), but it
>> continues to execute, and everything works good, except that GCI no longer
>> Le 14 avril 2012 21:14, Rony G. Flatscher <rony.flatscher@... écrit :
>>> Bonsoir Jean-Louis,
>>> not being at my main computer, I cannot check the execution path to
>>> see whether BSF4ooRexx does a RexxAttachThread at all. The attachments to
>>> the Java threads (BsfAttachToTid) should not interfere with the ooRexx
>>> thread management at all, if I recall correctly.
>>> Sorry for not being able to help more, good luck!
>>> Von meinem iPad gesendet
>>> Am 14.04.2012 um 20:06 schrieb Jean-Louis Faucher <jfaucher.fr@...
>>> Guten abend Rony
>>> Today, I spent time to debug a problem that I noticed several weeks ago :
>>> In ooRexxShell, the colors are correctly displayed, until bsf.cls is
>>> Then colors are no longer displayed.
>>> Colors are managed by calling GCI routines.
>>> I use the last SVN version of BSF4ooRexx.
>>> After bsf loading, the calls to GCI registered routine are all failing
>>> because the variable pool is not enabled (fail reading a stem). This
>>> happens because the same thread is attached to two different activities.
>>> Because of that, when executing this API function called by GCI :
>>> *RexxReturnCode RexxEntry RexxVariablePool(PSHVBLOCK pshvblock)
>>> NativeContextBlock context;
>>> return context.self->variablePoolInterface(pshvblock);
>>> *the wrong activity is associated to the variable context.
>>> I did not yet investigate BSF4ooRexx.cc, maybe you will know where to
>>> look to check if there is a problem of thread attachment. I continue to
>>> Call stack showing the problem :
>>> * threadId = 57972
>>> * listIndex = 1 --> activity = 0x7f69bea8
>>> * JLF : not good ! we should have activity = 0x7eee5fa0 (see
>>> * rexx.dll!ActivityManager::findActivity
>>> activity = 0x7eee5fa0
>>> * JLF : threadId = 57972 --> Problem ! two activities for the
>>> same thread id
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> Bsf4oorexx-devel mailing list