Applying your patch and re-running the problematic test-cases, it seems to be
indeed the case that
the problem is solved! Many thanks!
---rony
On 30.04.2017 13:00, Rony G. Flatscher wrote:
> On 30.04.2017 12:53, Rick McGuire wrote:
>> I want to verify something first. In this scenario, Rexx cod
After the failure, it is possible to skip over the failures by reissuing:
nmake /i /k
---rony
P.S.: Of course it should be possible to build "out-of-the-box" without an
error, so please advise
about the necessary setup of the MS tools.
On 30.04.2017 21:43, Rony G. Flatscher wrote:
>
> Whi
While following the build instructions for Windows, the following error occurs
while building the
32-bit Windows version:
[ 61%] Building CXX object
CMakeFiles/orexxole.dir/extensions/platform/windows/ole/events.cpp.obj
events.cpp
F:\work\svn\oorexx\main\trunk\extensions\platform\wi
On 30.04.2017 12:53, Rick McGuire wrote:
> I want to verify something first. In this scenario, Rexx code makes a call to
> a Java method (i.e.,
> the parser) which then makes a lot of callbacks all on the same thread?
Yes.
> If so, then I think I might see where the problem could be. The code tha
I want to verify something first. In this scenario, Rexx code makes a call
to a Java method (i.e., the parser) which then makes a lot of callbacks all
on the same thread? If so, then I think I might see where the problem could
be. The code that handles nested thread attaches (that is, attaching to
Having slept I went over the debug statements, just to learn that I concluded
wrongly yesterday: the
reference decreases did not come from the Rexx objects with uninits, but from
the Java side! :(
With new debug statements on the Rexx side (in the destructores) it is clear
that no proxy Rexx
ob
