[Oorexx-devel] An observation (hang in SystemsCommands.cpp, sometimes crash)

2023-11-02 Thread Rony G. Flatscher 
(This is using Microsoft Windows [Version 10.0.19045.3570], Open Object Rexx Version 5.1.0 r12722 - 
Internal Test Version, Java openjdk version "17.0.6" 2023-01-17 LTS). But can be observed also on 
other Java versions, older or newer.)


This has been a phenomenon for quite some time: sometimes (not always) there is a hang in ooRexx in 
the following use case:


 * a Rexx script will use a /command/ (e.g. "rexxj.cmd testRunScript.rxj") to 
start a Java program
   that will load Rexx to execute some Rexx script (SRS_1),

 o Java will load the Rexx interpreter and keep a reference to the primodal 
RexxInterpreter
   instance (RII) which will get the number 1 assigned to its name ("RE_1", 
the Java side names
   each RII and uses a counter to keep them distinguishable by name)

 o Java will create another RexxInterpreter instance ("RE_2") which gets 
used to run the Rexx
   script SRS_1, upon execution of this script RE_2 gets terminated via JNI,

 + while SRS_1 executes another RexxInterpreter instance ("RI_3") gets 
created by Java
   (implicitly done by using the Java scripting framework javax.script 
to run another
   Rexx_script) to run another Rexx script (SRS_2) on RI_3, upon return 
RI_3 gets
   terminated which will cause the Java garbage collector to be invoked 
(using System.gc()
   followed by .runFinalization() to get as many Java RexxProxies freed 
to allow the
   proxied Rexx object's uninit methods to run) which will also free 
Java RexxProxy objects
   causing proxied Rexx objects to be freed, causing implicitly to run 
the Rexx uninit
   methods of those, as the RexxInterpreter instance will be terminated 
(and ooRexx will
   run the garbage collector at that point in time)

 + upon return of SRS_1 sometimes a hang may occur (and many times the 
Rexx garbage
   collector seems to run in parallel as an immediate ctl-c when the 
hang can be observed
   causes sometimes errors in the appropriate Rexx uninit method

If the hang occurs, then it occurs interestingly in SystemsCommands.cpp at line # 521 in the 
statement "/if (WAIT_FAILED != WaitForSingleObject ( piProcInfo.hProcess, INFINITE ) )/" which is 
highlighted bold and blue in the following snippet:


   SystemCommands.cpp

   line # 521
   code:

... cut ...
SystemInterpreter::exceptionHostProcess = piProcInfo.hProcess;
SystemInterpreter::exceptionHostProcessId = piProcInfo.dwProcessId;

   *if (WAIT_FAILED != WaitForSingleObject ( piProcInfo.hProcess, 
INFINITE ) )*
{
// Completed ok, get termination rc
GetExitCodeProcess(piProcInfo.hProcess, );
// do we have input cleanup to perform?
if (redirIn)
{
// the process has returned, but the input thread may be 
stuck
// on a write for data that was never used. We need to 
close the
// pipe to force it to complete
inputThread.shutdown();
// close the process end of the pipe
CloseHandle(siStartInfo.hStdInput);
// wait for everything to complete
inputThread.waitForTermination();
// the INPUT thread may have encountered an error .. raise 
it now
if (inputThread.error != 0)
{
ErrorRedirection(context, inputThread.error);
return false;
}
}

// did we start an ERROR thread?
if (redirOut)
{
CloseHandle(siStartInfo.hStdOutput);  // close the handle 
so readFile will stop
// wait for the ERROR thread to finish
outputThread.waitForTermination();
if (outputThread.dataLength > 0)
{   // return what the ERROR thread read from its pipe
ioContext->WriteOutputBuffer(outputThread.pipeBuffer, 
outputThread.dataLength);
}
// the OUTPUT thread may have encountered an error .. raise 
it now
if (outputThread.error != 0)
{
ErrorRedirection(context, outputThread.error);
return false;
}
}

// did we start an ERROR thread?
if (redirErr)
{
CloseHandle(siStartInfo.hStdError);  // close the handle so 
readFile will stop
// wait for the ERROR thread to finish
errorThread.waitForTermination();
if (errorThread.dataLength > 0)
{   // return what the ERROR thread read from its pipe

Re: [Oorexx-devel] Another observation, Sourceforge "release API"

2022-12-23 Thread Rony G. Flatscher 

On 23.12.2022 16:27, Sahananda Sahananda wrote:

I have a question about defaulting to the 64bit version for Windows.

Is it still the case that if you use Mark's extensions (ie: Rexx/SQL etc) you need to have the 32 
bit version even if running on a 64 bit machine?


Honestly, I do not know,  maybe Mark knows?

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Strange observation, RFC

2022-06-01 Thread Rony G. Flatscher 


On 01.06.2022 12:20, Rick McGuire wrote:



On Wed, Jun 1, 2022 at 6:11 AM Rony G. Flatscher  
wrote:

While debugging orexxole.cpp I am using the existing function 
pszDbgVarType(vt) which returns
a pointer to a zero terminated string which gets defined for the entire 
program as CHAR
szDbg[255]. The same buffer is used by pszDbgInvKind(), pszDbgTypekind(), 
pszDbgParmFlags()
and pszDbVariant(). With the exception of pszDbgVarType() these debug 
functions are there but
not used AFAICT.

It allows to get a human readable string of the type 'vt' represents, e.g. 
"VT_ARRAY
VT_VARIANT", "VT_R8" and the like.

The strange observation is using pszDbgVarType() multiple times in a single 
debug statement like:

 if (*pDestVt & VT_ARRAY)// an array in hand
 {
 VARTYPE tmpVt = *pDestVt & VT_TYPEMASK;
*fprintf(stderr, "orexxole.cpp # %d %s: --- b) VT_ARRAY: type=[%s]
*pDestVt=[%s][d=%d][x%08x] %s tmpVt=[%s][d=%d][x%08x] | 
VT_ARRAY=[%s][d=%d][x%08x],
VT_R8=[%s][d=%d][x%08x] \n\n",__LINE__, 
__FUNCTION__,"VT_ARRAY",pszDbgVarType( *pDestVt ), *pDestVt , *pDestVt," /\\ 
",pszDbgVarType( tmpVt ), tmpVt , tmpVt,pszDbgVarType(VT_ARRAY), VT_ARRAY, 
VT_ARRAY,pszDbgVarType(VT_R8), VT_R8, VT_R8);*** }

So there are four invocations of pszDbgVarType() with four different 
variables. The ouput is
surprisingly:

... cut ...
oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> 
szDbg=[VT_R8] (return value)
oorexxole.cpp # 419 pszDbgVarType, vt: d=[0] [x] -> 
szDbg=[VT_ARRAY  VT_EMPTY] (return value)
oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> 
szDbg=[VT_R8] (return value)
oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> 
szDbg=[VT_ARRAY  VT_R8] (return value)
(added linebreaks for better legibility):
*orexxole.cpp # 4359 checkForOverride: --- b) VT_ARRAY: type=[VT_ARRAY] 
*pDestVt=[VT_ARRAY
VT_R8][d=8197][x2005] /\ tmpVt=[VT_ARRAYVT_R8][d=5][x0005] 
| VT_ARRAY=[VT_ARRAY VT_R8][d=8192][x2000], VT_R8=[VT_ARRAY
VT_R8][d=5][x0005]***

Line # 419 above is a debug statement in pszDbgVarType() displaying the 
value it returns. It
uses strcat() with the szDbg buffer which upon entry in this function sets 
element 0 to 0.

VT_ARRAY has the decimal value 8192 (x2000), VT_R8 the decimal value 5 
(x0005), hence the
following should be shown:

pszDbgVarType(*pDestVt): "VT_ARRAY VT_R8"
pszDbgVarType(tmpVt)   : "VT_R8" (VT_TYPEMASK is defined as xFFF)
pszDbgVarType(VT_ARRAY): "VT_ARRAY"
pszDbgVarType(VT_R8)   : "VT_R8"

It is as if for some of those invocations of pszDbvVarType the wrong buffer 
gets returned,
hence displaying wrong information.

Well, if the buffer gets reused, then each invocation is going to overlay the information from the 
previous call, so fprintf() will be using the information from the last call when it formats.


Ah, I see, that explains it, thank you very much!


Of course, having spent an enormeous amount of time debugging I might have 
arrived at a point
where I overlook the obvious, hence this posting requesting comments.

---rony

P.S.: Contemplating to change the pszDbg...() functions to force a buffer 
to be supplied
rather than using a single global buffer, noticing that at least 
pszDbgVarType() gets also
used by orexxole.cpp. This way no wrong optimizations should be applicable 
and also
multithreaded usage of oorexxole.cpp would be improved.

Just make sure the allocated buffer gets released afterwards. This change is likely to be an 
incredible pain to accomplish.


Will make sure that that happens (this will take some time as the next slot to work on this is about 
to close and reopens this weekend due to my currently quite high workload).


---rony


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Strange observation, RFC

2022-06-01 Thread Rick McGuire 
On Wed, Jun 1, 2022 at 6:11 AM Rony G. Flatscher 
wrote:

> While debugging orexxole.cpp I am using the existing function
> pszDbgVarType(vt) which returns a pointer to a zero terminated string which
> gets defined for the entire program as CHAR szDbg[255]. The same buffer is
> used by pszDbgInvKind(), pszDbgTypekind(), pszDbgParmFlags() and
> pszDbVariant(). With the exception of pszDbgVarType() these debug functions
> are there but not used AFAICT.
>
> It allows to get a human readable string of the type 'vt' represents, e.g.
> "VT_ARRAY VT_VARIANT", "VT_R8" and the like.
>
> The strange observation is using pszDbgVarType() multiple times in a
> single debug statement like:
>
> if (*pDestVt & VT_ARRAY)// an array in hand
> {
> VARTYPE tmpVt = *pDestVt & VT_TYPEMASK; 
> *fprintf(stderr, "orexxole.cpp # %d %s: --- b) VT_ARRAY: type=[%s] 
> *pDestVt=[%s][d=%d][x%08x] %s tmpVt=[%s][d=%d][x%08x] | 
> VT_ARRAY=[%s][d=%d][x%08x], VT_R8=[%s][d=%d][x%08x] \n\n",**__LINE__, 
> __FUNCTION__,**"VT_ARRAY",**pszDbgVarType( *pDestVt  ), 
> *pDestVt  , *pDestVt,**" /\\ ",**pszDbgVarType( tmpVt ),  
> tmpVt , tmpVt,**pszDbgVarType(VT_ARRAY), VT_ARRAY, VT_ARRAY,**
> pszDbgVarType(VT_R8), VT_R8, VT_R8**);*}
>
> So there are four invocations of pszDbgVarType() with four different
> variables. The ouput is surprisingly:
>
> ... cut ...
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
> (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[0] [x] -> szDbg=[VT_ARRAY 
> VT_EMPTY] (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
> (return value)
> oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_ARRAY 
> VT_R8] (return value)
>(added linebreaks for better legibility):*orexxole.cpp # 4359 
> checkForOverride: --- b) VT_ARRAY: type=[VT_ARRAY]
>*pDestVt=[VT_ARRAY VT_R8][d=8197][x2005]  /\
>   tmpVt=[VT_ARRAY* *VT_R8][d=5][x0005] |
>VT_ARRAY=[VT_ARRAY VT_R8][d=8192][x2000],
>   VT_R8=[VT_ARRAY VT_R8][d=5][x0005]*
>
> Line # 419 above is a debug statement in pszDbgVarType() displaying the
> value it returns. It uses strcat() with the szDbg buffer which upon entry
> in this function sets element 0 to 0.
>
> VT_ARRAY has the decimal value 8192 (x2000), VT_R8 the decimal value 5
> (x0005), hence the following should be shown:
>
> pszDbgVarType(*pDestVt): "VT_ARRAY VT_R8"
> pszDbgVarType(tmpVt)   : "VT_R8" (VT_TYPEMASK is defined as xFFF)
> pszDbgVarType(VT_ARRAY): "VT_ARRAY"
> pszDbgVarType(VT_R8)   : "VT_R8"
>
> It is as if for some of those invocations of pszDbvVarType the wrong
> buffer gets returned, hence displaying wrong information.
>
Well, if the buffer gets reused, then each invocation is going to overlay
the information from the previous call, so fprintf() will be using the
information from the last call when it formats.



Of course, having spent an enormeous amount of time debugging I might have
> arrived at a point where I overlook the obvious, hence this posting
> requesting comments.
>
> ---rony
>
> P.S.: Contemplating to change the pszDbg...() functions to force a buffer
> to be supplied rather than using a single global buffer, noticing that at
> least pszDbgVarType() gets also used by orexxole.cpp. This way no wrong
> optimizations should be applicable and also multithreaded usage of
> oorexxole.cpp would be improved.
>
Just make sure the allocated buffer gets released afterwards. This change
is likely to be an incredible pain to accomplish.

Rick


>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Strange observation, RFC

2022-06-01 Thread Rony G. Flatscher 
While debugging orexxole.cpp I am using the existing function pszDbgVarType(vt) which returns a 
pointer to a zero terminated string which gets defined for the entire program as CHAR szDbg[255]. 
The same buffer is used by pszDbgInvKind(), pszDbgTypekind(), pszDbgParmFlags() and pszDbVariant(). 
With the exception of pszDbgVarType() these debug functions are there but not used AFAICT.


It allows to get a human readable string of the type 'vt' represents, e.g. "VT_ARRAY VT_VARIANT", 
"VT_R8" and the like.


The strange observation is using pszDbgVarType() multiple times in a single 
debug statement like:

if (*pDestVt & VT_ARRAY)// an array in hand
{
VARTYPE tmpVt = *pDestVt & VT_TYPEMASK;
   *fprintf(stderr, "orexxole.cpp # %d %s: --- b) VT_ARRAY: type=[%s] 
*pDestVt=[%s][d=%d][x%08x] %s
   tmpVt=[%s][d=%d][x%08x] | VT_ARRAY=[%s][d=%d][x%08x], VT_R8=[%s][d=%d][x%08x] 
\n\n",__LINE__, __FUNCTION__,"VT_ARRAY",pszDbgVarType( *pDestVt ), *pDestVt , 
*pDestVt," /\\ ",pszDbgVarType( tmpVt ), tmpVt , tmpVt,pszDbgVarType(VT_ARRAY), 
VT_ARRAY, VT_ARRAY,pszDbgVarType(VT_R8), VT_R8, VT_R8);*** }

So there are four invocations of pszDbgVarType() with four different variables. The ouput is 
surprisingly:


   ... cut ...
   oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
(return value)
   oorexxole.cpp # 419 pszDbgVarType, vt: d=[0] [x] -> szDbg=[VT_ARRAY  
VT_EMPTY] (return value)
   oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_R8] 
(return value)
   oorexxole.cpp # 419 pszDbgVarType, vt: d=[5] [x0005] -> szDbg=[VT_ARRAY  
VT_R8] (return value)
   (added linebreaks for better legibility):
   *orexxole.cpp # 4359 checkForOverride: --- b) VT_ARRAY: type=[VT_ARRAY] 
*pDestVt=[VT_ARRAY
   VT_R8][d=8197][x2005] /\ tmpVt=[VT_ARRAYVT_R8][d=5][x0005] | 
VT_ARRAY=[VT_ARRAY VT_R8][d=8192][x2000], VT_R8=[VT_ARRAY
   VT_R8][d=5][x0005]***

Line # 419 above is a debug statement in pszDbgVarType() displaying the value it returns. It uses 
strcat() with the szDbg buffer which upon entry in this function sets element 0 to 0.


VT_ARRAY has the decimal value 8192 (x2000), VT_R8 the decimal value 5 (x0005), hence the following 
should be shown:


   pszDbgVarType(*pDestVt): "VT_ARRAY VT_R8"
   pszDbgVarType(tmpVt)   : "VT_R8" (VT_TYPEMASK is defined as xFFF)
   pszDbgVarType(VT_ARRAY): "VT_ARRAY"
   pszDbgVarType(VT_R8)   : "VT_R8"

It is as if for some of those invocations of pszDbvVarType the wrong buffer gets returned, hence 
displaying wrong information.


Of course, having spent an enormeous amount of time debugging I might have arrived at a point where 
I overlook the obvious, hence this posting requesting comments.


---rony

P.S.: Contemplating to change the pszDbg...() functions to force a buffer to be supplied rather than 
using a single global buffer, noticing that at least pszDbgVarType() gets also used by orexxole.cpp. 
This way no wrong optimizations should be applicable and also multithreaded usage of oorexxole.cpp 
would be improved.


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] An observation (Re: Windows: crash upon exiting 32-bit multithreaded programs

2022-04-21 Thread Rony G. Flatscher 
Further testing on 32-bit ooRexx (r12372) on Windows with multithreaded BSF4ooRexx programs as it is 
"easier" to get the crashes there whenever ooRexx is about to terminate (using a JavaFX rendering of 
the oodialog example "stopWatch.rex"):


 * adding as the last statement of the main program "call syssleep 0.01" (1/100 
sec) reduces the
   crashes considerably,
 * doing a "call syssleep 0.1" (1/10 sec) instead makes them go away for good 
it seems (trying ten
   times).

Reporting it as this observation may help find a solution that inhibits ooRexx crashes on Windows 
upon exiting.


---rony


On 20.04.2022 14:41, Rony G. Flatscher wrote:

On 19.04.2022 14:20, Rony G. Flatscher wrote:


From time to time I get crashes upon exiting multithreaded programs on Windows. The crash occurs 
in ANSI32.dll. However, when using a debug version of ooRexx these crashes usually do not show up.


Today, I ran a few ooDialog samples ("ooRexx\samples\oodialog\examples") with a debug version of 
32-bit ooRexx r12371 and received such a crash upon exiting the sample "browsePrinters.rex" 
("pure ooRexx").


Using 32-bit 5.0.0 r12372 from the ooRexx beta download section, this program 
("browsePrinters.rex") crashes from time to time as well when it gets closed (e.g. after 
testing/running a few other ooDialog samples like "imageButton.rex" which has not yet crashed).


---

Also when running BSF4ooRexx programs sometimes a crash occurs upon closing the Rexx program (the 
stack shows the main thread in ANSI32.dll and underneath rexx stack entries). On Linux and Mac 
this does not occur.


Maybe there is some race condition problem? [1][2]

---rony

[1] 

[2] 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-28 Thread Enrico Sorichetti 
Hello Erich,
Yo can stop worrying
the library search path is one of the murky things of OSX
I was testing from an install directory not in the search path
and for some unclear reason rexx picked up the dylibs at an older revision 
from the rexx directory in the $PATH

I will keep researching and let You know the right CMAKE constructs 
to plug in the executables the right absolute path 
I am using CMAKE 3.10.2 and probably there are a few more POLICIES to set
CMP0042 and CMP0068 come to mind

I cleaned up everything, restarted from scratch and everything worked
I guess I got a brain check and forgot about cleaning up before complaining

cheers
enrico


> On 28 Feb 2018, at 09:57, Erich Steinböck  wrote:
> 
> rebuilt  Revision: 11358
> resulted in Segmentation fault: 11
> 
> Enrico, our build server seems to successfully build and run full unit tests 
> for r11358 on Windows, some Linux systems, and Darwin.
> 
> We'd need more details what's going on here. 
> Rony, can you try to build/run r11358 on Darwin and confirm whether you see a 
> failure?
> 
> 
> 
> On Sat, Feb 24, 2018 at 10:53 PM, Enrico Sorichetti  > wrote:
> unfortunately just to be sure i just rebuilt  Revision: 11358 with the 
> original cmakelists
> ( which on apple installs to $HOME/Applications/… )
> 
> and running
>  
> /Users/enrico/Applications/ooRexx5.0.0/bin/rexx -e "parse source s;say 
> s;parse version v;say v"
> 
> resulted in Segmentation fault: 11
> 
> while  Revision: 11357
> works with the original CmakeLists.txt
> 
> and  my modified CmakeLists.txt
> which obeys the -DCMAKE_INSTALL_PREFIX=somewhere invocation construct
> as per CMAKE standards 
> 
> cheers
> 
> enrico
> 
> PS. 
> from Your comment I knew it was of no  use
> but for the sake of completeness I run a svn update and a rebuild
> the result was the same ( the code was not changed )
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-28 Thread Erich Steinböck 
>
> rebuilt  Revision: 11358
> resulted in Segmentation fault: 11
>

*Enrico, *our build server seems to successfully build and run full unit
tests for r11358 on Windows, some Linux systems, and Darwin.

We'd need more details what's going on here.
*Rony, *can you try to build/run r11358 on Darwin and confirm whether you
see a failure?



On Sat, Feb 24, 2018 at 10:53 PM, Enrico Sorichetti <
enricosoriche...@mac.com> wrote:

> unfortunately just to be sure i just rebuilt  Revision: 11358 with the
> original cmakelists
> ( which on apple installs to $HOME/Applications/… )
>
> and running
>
> /Users/enrico/Applications/ooRexx5.0.0/bin/rexx -e "parse source s;say
> s;parse version v;say v"
>
> resulted in Segmentation fault: 11
>
> while  Revision: 11357
> works with the original CmakeLists.txt
>
> and  my modified CmakeLists.txt
> which obeys the -DCMAKE_INSTALL_PREFIX=somewhere invocation construct
> as per CMAKE standards
>
> cheers
>
> enrico
>
> PS.
> from Your comment I knew it was of no  use
> but for the sake of completeness I run a svn update and a rebuild
> the result was the same ( the code was not changed )
>
>
--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Hello Erich,

Without changing anything (i.e. with the typo) I did this

POs-MacBook-Pro:ootest po$ ./settestenv.sh
Setting env for MacOS
POs-MacBook-Pro:ootest po$ rexx testooRexx Package.testGroup
Searching for test containers..
Executing automated test suite..

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 22 Oct 2017
OS Name:DARWIN
SysVersion: Darwin Darwin Kernel Version 16.7.0: Thu Jan 11 22:59:40 
PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64.16.7.0

Tests ran:  77
Assertions: 166
Failures:   0
Errors: 0

File search:00:00:00.025649
Suite construction: 00:00:00.007310
Test execution: 00:00:01.029489
Total time: 00:00:02.019247

POs-MacBook-Pro:ootest po$ 

As you see my interpreter is the one from 22.10.2017, (as I suspected a mixup 
with the Test setup) i.e. not the latest one so my test will not be conclusive.

I am working on something (hence the original question to Rony) and do not want 
to uniinstall/reinstall in the middle of it. Sorry if I can not be of any help 
right now. Maybe Enricos response give a better idea on what is wrong.

As I have stated before I am more than willing to sponsor a Mac for testing 
purposes, just let me know how and when.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
Von mein MacBookPro gesendet



> Am 24.02.2018 um 22:37 schrieb Erich Steinböck :
> 
>  oorexx-code-0-11357-test-trunk/ooRexx/base/class/Package.testGroup
> Maybe Erich or someone can have a look?
> 
> I just fixed a typo in one of the test cases.  We surely shouldn't see a 
> segmentation violation when running this test case.
> Can you please  run `rexx Package.testGroup` (you'll most probably have to 
> first setup the search path for the test framework by running 
> `setTestEnv.sh´) and tell us what output you're seeing?
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Enrico Sorichetti 
unfortunately just to be sure i just rebuilt  Revision: 11358 with the original 
cmakelists
( which on apple installs to $HOME/Applications/… )

and running
 
/Users/enrico/Applications/ooRexx5.0.0/bin/rexx -e "parse source s;say s;parse 
version v;say v"

resulted in Segmentation fault: 11

while  Revision: 11357
works with the original CmakeLists.txt

and  my modified CmakeLists.txt
which obeys the -DCMAKE_INSTALL_PREFIX=somewhere invocation construct
as per CMAKE standards 

cheers

enrico

PS. 
from Your comment I knew it was of no  use
but for the sake of completeness I run a svn update and a rebuild
the result was the same ( the code was not changed )


> On 24 Feb 2018, at 22:37, Erich Steinböck  wrote:
> 
>  oorexx-code-0-11357-test-trunk/ooRexx/base/class/Package.testGroup
> Maybe Erich or someone can have a look?
> 
> I just fixed a typo in one of the test cases.  We surely shouldn't see a 
> segmentation violation when running this test case.
> Can you please  run `rexx Package.testGroup` (you'll most probably have to 
> first setup the search path for the test framework by running 
> `setTestEnv.sh´) and tell us what output you're seeing?
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Erich Steinböck 
>
>  oorexx-code-0-11357-test-trunk/ooRexx/base/class/Package.testGroup
>
Maybe Erich or someone can have a look?
>

I just fixed a typo in one of the test cases.  We surely shouldn't see a
segmentation violation when running this test case.
Can you please  run `rexx Package.testGroup` (you'll most probably have to
first setup the search path for the test framework by running
`setTestEnv.sh´) and tell us what output you're seeing?
--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Dear Enrico,

I misunderstood your proposal, I thought it was about putting ooRexx in 
/usr/bin/env, which would be a violation of Apples System Integrity Protection. 
What you propose is something different, using /usr/bin/env to redirect the 
search to whatever is in the path. Thus on my machine with symlinks to 
/usr/local/bin for ooRexx (a BSF installation)

PATH= /usr/local/bin: /usr/bin: /bin:   /usr/sbin:  /sbin: (I spaced it)

Will work just fine. AND I could temporally redirect it. Great.

A question in addition: What about /usr/local/lib? Currently libraries for 
ooRexx (and BSF4ooRexx) are syminked there. 

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
Von mein MacBookPro gesendet



> Am 24.02.2018 um 19:24 schrieb Enrico Sorichetti :
> 
> first of all sorry for the typo 
> should have been  >> #! /usr/bin/env xx
> 
> I use the suggested shebang for all my scripts 
> rexx, bash - the scripting languages I use normally
> 
> but it works for  python, perl, lua, ruby,
> i even works for sbcl which needs an argument
> #! /usr/bin/env sbcl --script
> 
> as far as the operating system 
> I have been using above shebang on
> APPLE OSX
> FreeBSD
> and a few flavors of linux
> ubuntu, debian, centos, fedora
> 
> so I guess that it should cover most of them
> 
> cheers
> enrico
> 
>> On 24 Feb 2018, at 17:29, Gil Barmwater > > wrote:
>> 
>> So my question is "Does the suggested shebang line work for all the *nix 
>> flavors we support?"
>> 
>> If so, it seems like a minimum amount of editing of the non-Windows-only 
>> *.rex files to put this issue to bed.  
>> Gil B.
>> On 2/24/2018 7:11 AM, Enrico Sorichetti wrote:
>>> IMO the most flexible shebang line is
>>> 
>>> #! /usr/env/bin xx
>>> 
>>> in this case 
>>> #! /usr/env/bin rexx
>>> 
>>> it will pick up the executable according to the precedences set by  $PATH 
>>> environment variable
>>> 
>>> most useful to test different version of Rexx
>>>  I usually have a couple of them installed in different directories
>>> (  after having changed CMakeLists.txt ways to a more reasonable behaviour )
>>> 
>>> Too bad that the rexx Developers do not let the user set the INSTALL_PREFIX
>>> according to the user standards but force Their poor choices on the user
>>> 
>>> I still wonder why for APPLE OSX They do not follow the usual *nix logic
>>> 
>>> Best regards
>>> 
>>> enrico
>>> 
>>> 
 On 24 Feb 2018, at 11:16, oor...@jonases.se  
 wrote:
 
 Dear Rony,
 
 many thanks for your insights, it brings me to ask a question:
 
 I am building a larger project with many smaller „modules“ and I wanted to 
 be a brave boy and start directly writing test cases for the modules as I 
 go along.
 
 When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
 Can I use this version also for ooRexx 5.0.0?
 
 PS I looked into the .rexx files and saw that the Shebang for Unix/Linux 
 is no longer correct, maybe you should do a S for
 
 #!/usr/bin/rexx
 
 and change it to
 
 #!/usr/local/bin/rexx
 
 in all places.
 
 Hälsningar/Regards/Grüsse,
 P.O. Jonsson
 oor...@jonases.se 
 Von mein MacBookPro gesendet
 
 
 
> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher  >:
> 
> Since the end of last December I have been working on a new "reflection 
> core" for BSF4ooRexx on the
> Java side in every free minute (including evenings and weekends). The 
> reason being that with Java 9
> some internals in the reflection area got changed and issue warnings, and 
> it is announced that with
> future versions of Java these warnings will be changed to errors.
> 
> As I would like to support a Java baseline of 1.6/6 the new reflection 
> logic has to work also on
> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
> fundamental changes in the
> experimental code I test them against all these versions on the same 
> machine using ooRexx 5.0 beta
> without rebooting. Needless to say there may be bugs that show up after 
> such a change. In order to
> be sure that the new functionality is on par with the current 
> functionality I regularly employ test
> unit runs taking advantage of the latest ooRexx test unit framework 
> ("ooRexxTest").
> 
> The observation and reason why I post this on the ooRexx developer list 
> is the following: from time
> to time there have been quite surprising problems that have shown up. In 
> a couple of instances I
> literally traced down for weeks (!) all kind of execution threads of the 
> library and the BSF4ooRexx
> infrastructure to understand what is happening.

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Hello Enrico,

I tried to use Revision 11357 as well (for the oorexx test) but had the same 
problem. In my case it is probably because I use another/older revision of 
ooRexx pre-installed so there is a conflict. Never mind, I will figure it out 
later.

I compared the revisions 11357 and 11358 and the only difference I could find 
was here:

oorexx-code-0-11357-test-trunk/ooRexx/base/class/Package.testGroup

These methods have been added in 11358:

::method test_package_local_one_arg
  self~expectSyntax(93.902) -- Too many arguments in invocation of method
  .context~package~local(1)

::method test_package_local_get_empty
  self~assertIsA(.context~package~local, .Directory)
  self~assertSame(0, .context~package~local~items)

::method test_package_local_set
  .context~package~packageTest = "DEF"
  self~assertSame("DEF", .context~package~packageTest)

::method test_package_local
  .local~packageTest = "ABC"
  package = .package~new("TESTPACKAGELOCAL", 
(".context~package~local~packageTest = 'DEF'", "::routine routine1", "  return 
.packageTest"))

  self~assertSame("DEF", package~routines["ROUTINE1"]~call)
  self~assertSame("DEF", package~local~packageTest)

Maybe Erich or someone can have a look? Hope it helps.

Regarding the „right“ shebang I will write another mail shortly. Stay tuned

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
Von mein MacBookPro gesendet



> Am 24.02.2018 um 19:49 schrieb Enrico Sorichetti :
> 
> the segmentation fault is due to Revision: 11358
> everything works well at Revision: 11357
> 
> 
>> On 24 Feb 2018, at 16:05, oor...@jonases.se  wrote:
>> 
>> POs-MacBook-Pro:ootest po$ rexx testOORexx -X native_api
>> Searching for test containers..
>> Executing automated test suite 
>> ..
>> ...
>> .Segmentation
>>  fault: 11
>> 
> 
> 
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Enrico Sorichetti 
the segmentation fault is due to Revision: 11358
everything works well at Revision: 11357


> On 24 Feb 2018, at 16:05, oor...@jonases.se wrote:
> 
> POs-MacBook-Pro:ootest po$ rexx testOORexx -X native_api
> Searching for test containers..
> Executing automated test suite 
> ..
> ...
> .Segmentation 
> fault: 11
> 



--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Enrico Sorichetti 
first of all sorry for the typo 
should have been  >> #! /usr/bin/env xx

I use the suggested shebang for all my scripts 
rexx, bash - the scripting languages I use normally

but it works for  python, perl, lua, ruby,
i even works for sbcl which needs an argument
#! /usr/bin/env sbcl --script

as far as the operating system 
I have been using above shebang on
APPLE OSX
FreeBSD
and a few flavors of linux
ubuntu, debian, centos, fedora

so I guess that it should cover most of them

cheers
enrico

> On 24 Feb 2018, at 17:29, Gil Barmwater  wrote:
> 
> So my question is "Does the suggested shebang line work for all the *nix 
> flavors we support?"
> 
> If so, it seems like a minimum amount of editing of the non-Windows-only 
> *.rex files to put this issue to bed.  
> Gil B.
> On 2/24/2018 7:11 AM, Enrico Sorichetti wrote:
>> IMO the most flexible shebang line is
>> 
>> #! /usr/env/bin xx
>> 
>> in this case 
>> #! /usr/env/bin rexx
>> 
>> it will pick up the executable according to the precedences set by  $PATH 
>> environment variable
>> 
>> most useful to test different version of Rexx
>>  I usually have a couple of them installed in different directories
>> (  after having changed CMakeLists.txt ways to a more reasonable behaviour )
>> 
>> Too bad that the rexx Developers do not let the user set the INSTALL_PREFIX
>> according to the user standards but force Their poor choices on the user
>> 
>> I still wonder why for APPLE OSX They do not follow the usual *nix logic
>> 
>> Best regards
>> 
>> enrico
>> 
>> 
>>> On 24 Feb 2018, at 11:16, oor...@jonases.se  
>>> wrote:
>>> 
>>> Dear Rony,
>>> 
>>> many thanks for your insights, it brings me to ask a question:
>>> 
>>> I am building a larger project with many smaller „modules“ and I wanted to 
>>> be a brave boy and start directly writing test cases for the modules as I 
>>> go along.
>>> 
>>> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
>>> Can I use this version also for ooRexx 5.0.0?
>>> 
>>> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is 
>>> no longer correct, maybe you should do a S for
>>> 
>>> #!/usr/bin/rexx
>>> 
>>> and change it to
>>> 
>>> #!/usr/local/bin/rexx
>>> 
>>> in all places.
>>> 
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se 
>>> Von mein MacBookPro gesendet
>>> 
>>> 
>>> 
 Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher >:
 
 Since the end of last December I have been working on a new "reflection 
 core" for BSF4ooRexx on the
 Java side in every free minute (including evenings and weekends). The 
 reason being that with Java 9
 some internals in the reflection area got changed and issue warnings, and 
 it is announced that with
 future versions of Java these warnings will be changed to errors.
 
 As I would like to support a Java baseline of 1.6/6 the new reflection 
 logic has to work also on
 Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
 fundamental changes in the
 experimental code I test them against all these versions on the same 
 machine using ooRexx 5.0 beta
 without rebooting. Needless to say there may be bugs that show up after 
 such a change. In order to
 be sure that the new functionality is on par with the current 
 functionality I regularly employ test
 unit runs taking advantage of the latest ooRexx test unit framework 
 ("ooRexxTest").
 
 The observation and reason why I post this on the ooRexx developer list is 
 the following: from time
 to time there have been quite surprising problems that have shown up. In a 
 couple of instances I
 literally traced down for weeks (!) all kind of execution threads of the 
 library and the BSF4ooRexx
 infrastructure to understand what is happening. Well, yesterday, in 
 despair, I killed rxapi and
 re-ran the test suit and surprisingly, the unexplainable, erratic 
 surfacing errors went away! One
 such error was for instance that turning a Java null into an ooRexx .nil 
 by sending an object proxy
 string to Rexx indicating the object named ".NIL" causing a replacement 
 with .nil ("The NIL object")
 all of a sudden would assign the string value of the environment symbol 
 .NIL instead (if res=".NIL"
 then res=.nil) ! After killing rxapi and re-running the test suit 
 everything worked as it should,
 the unexplainable errors went away!
 
 So it seems that there is state in rxapi that can affect a newly created 
 Rexx interpreter. In my
 complex test environment it seems that when errors occur over time 
 eventually rxapi seems to be
 affected and in turn newly started Rexx interpreters may get affected as 
 well!
 
 In case

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Gil Barmwater 
So my question is "Does the suggested shebang line work for all the *nix 
flavors we support?"


If so, it seems like a minimum amount of editing of the non-Windows-only 
*.rex files to put this issue to bed.


Gil B.
On 2/24/2018 7:11 AM, Enrico Sorichetti wrote:

IMO the most flexible shebang line is

#! /usr/env/bin xx

in this case
#! /usr/env/bin rexx

it will pick up the executable according to the precedences set by 
 $PATH environment variable


most useful to test different version of Rexx
 I usually have a couple of them installed in different directories
(  after having changed CMakeLists.txt ways to a more reasonable 
behaviour )


Too bad that the rexx Developers do not let the user set the 
INSTALL_PREFIX

according to the user standards but force Their poor choices on the user

I still wonder why for APPLE OSX They do not follow the usual *nix logic

Best regards

enrico


On 24 Feb 2018, at 11:16, oor...@jonases.se 
 wrote:


Dear Rony,

many thanks for your insights, it brings me to ask a question:

I am building a larger project with many smaller „modules“ and I 
wanted to be a brave boy and start directly writing test cases for 
the modules as I go along.


When I look at the ooRexx site the latest ooRexxTest I could find was 
4.2. Can I use this version also for ooRexx 5.0.0?


PS I looked into the .rexx files and saw that the Shebang for 
Unix/Linux is no longer correct, maybe you should do a S for


#!/usr/bin/rexx

and change it to

#!/usr/local/bin/rexx

in all places.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se 
Von mein MacBookPro gesendet



Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher 
>:


Since the end of last December I have been working on a new 
"reflection core" for BSF4ooRexx on the
Java side in every free minute (including evenings and weekends). 
The reason being that with Java 9
some internals in the reflection area got changed and issue 
warnings, and it is announced that with

future versions of Java these warnings will be changed to errors.

As I would like to support a Java baseline of 1.6/6 the new 
reflection logic has to work also on
Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there 
are fundamental changes in the
experimental code I test them against all these versions on the same 
machine using ooRexx 5.0 beta
without rebooting. Needless to say there may be bugs that show up 
after such a change. In order to
be sure that the new functionality is on par with the current 
functionality I regularly employ test
unit runs taking advantage of the latest ooRexx test unit framework 
("ooRexxTest").


The observation and reason why I post this on the ooRexx developer 
list is the following: from time
to time there have been quite surprising problems that have shown 
up. In a couple of instances I
literally traced down for weeks (!) all kind of execution threads of 
the library and the BSF4ooRexx
infrastructure to understand what is happening. Well, yesterday, in 
despair, I killed rxapi and
re-ran the test suit and surprisingly, the unexplainable, erratic 
surfacing errors went away! One
such error was for instance that turning a Java null into an ooRexx 
.nil by sending an object proxy
string to Rexx indicating the object named ".NIL" causing a 
replacement with .nil ("The NIL object")
all of a sudden would assign the string value of the environment 
symbol .NIL instead (if res=".NIL"
then res=.nil) ! After killing rxapi and re-running the test suit 
everything worked as it should,

the unexplainable errors went away!

So it seems that there is state in rxapi that can affect a newly 
created Rexx interpreter. In my
complex test environment it seems that when errors occur over time 
eventually rxapi seems to be
affected and in turn newly started Rexx interpreters may get 
affected as well!


In case others experience such a phenomenon killing rxapi may save 
you a lot of time!


---rony


--
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
Oorexx-devel@lists.sourceforge.net 


https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
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
Oorexx-devel@lists.sourceforge.net 


https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Dear Rony,

I have copied the version of ooRexxTest over as you pointed at, it works better 
but there is something (C/C++) wrong, I will clean it out and try again (and 
read the documentation)

POs-MacBook-Pro:ootest po$ rexx testOORexx -X native_api
Searching for test containers..
Executing automated test suite 
..
...
.Segmentation 
fault: 11

Would it be much work to copy everything over to a new snapshot under the 
oorexxunit folder? 

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
Von mein MacBookPro gesendet



> Am 24.02.2018 um 13:00 schrieb Rony G. Flatscher :
> 
> Dear P.O.,
> On 24.02.2018 11:16, oor...@jonases.se  wrote:
>> many thanks for your insights, it brings me to ask a question:
>> 
>> I am building a larger project with many smaller „modules“ and I wanted to 
>> be a brave boy and start directly writing test cases for the modules as I go 
>> along.
> This is actually a very smart move, if you do this! 
> :)
> 
>> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
>> Can I use this version also for ooRexx 5.0.0?
> Yes. However, there is an ooRexx 5.0.0 ooRexxTest, which you will find in 
> svn/oorexx/test/trunk. 
> 
>> 
>> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is 
>> no longer correct, maybe you should do a S for
>> 
>> #!/usr/bin/rexx
>> 
>> and change it to
>> 
>> #!/usr/local/bin/rexx
>> 
>> in all places.
> Yes, Apple has started to force everyone (but Apple) to install to /usr/local 
> (and even did a brute force action by deleting everything unknown from 
> /usr/bin et al at an update to the operating system without even informing 
> the users about it). 
> 
> Also the hash bang for plain ooRexx would need to be adjusted for the ooRexx 
> distribution on MacOS.
> 
> Best regards
> 
> ---rony
> 
>> 
>> 
>>> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher >> >:
>>> 
>>> Since the end of last December I have been working on a new "reflection 
>>> core" for BSF4ooRexx on the
>>> Java side in every free minute (including evenings and weekends). The 
>>> reason being that with Java 9
>>> some internals in the reflection area got changed and issue warnings, and 
>>> it is announced that with
>>> future versions of Java these warnings will be changed to errors.
>>> 
>>> As I would like to support a Java baseline of 1.6/6 the new reflection 
>>> logic has to work also on
>>> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
>>> fundamental changes in the
>>> experimental code I test them against all these versions on the same 
>>> machine using ooRexx 5.0 beta
>>> without rebooting. Needless to say there may be bugs that show up after 
>>> such a change. In order to
>>> be sure that the new functionality is on par with the current functionality 
>>> I regularly employ test
>>> unit runs taking advantage of the latest ooRexx test unit framework 
>>> ("ooRexxTest").
>>> 
>>> The observation and reason why I post this on the ooRexx developer list is 
>>> the following: from time
>>> to time there have been quite surprising problems that have shown up. In a 
>>> couple of instances I
>>> literally traced down for weeks (!) all kind of execution threads of the 
>>> library and the BSF4ooRexx
>>> infrastructure to understand what is happening. Well, yesterday, in 
>>> despair, I killed rxapi and
>>> re-ran the test suit and surprisingly, the unexplainable, erratic surfacing 
>>> errors went away! One
>>> such error was for instance that turning a Java null into an ooRexx .nil by 
>>> sending an object proxy
>>> string to Rexx indicating the object named ".NIL" causing a replacement 
>>> with .nil ("The NIL object")
>>> all of a sudden would assign the string value of the environment symbol 
>>> .NIL instead (if res=".NIL"
>>> then res=.nil) ! After killing rxapi and re-running the test suit 
>>> everything worked as it should,
>>> the unexplainable errors went away!
>>> 
>>> So it seems that there is state in rxapi that can affect a newly created 
>>> Rexx interpreter. In my
>>> complex test environment it seems that when errors occur over time 
>>> eventually rxapi seems to be
>>> affected and in turn newly started Rexx interpreters may get affected as 
>>> well!
>>> 
>>> In case others experience such a phenomenon killing rxapi may save you a 
>>> lot of time!
>>> 
>>> ---rony
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
>

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Dear Rony,

Thanks for the hint. I tried to use the 4.2 version and this is how it went

POs-MacBook-Pro:ootest po$ rexx testOORexx -X native_api
ooTest.frm::routine::setExternalDir() line: 171
  Need code for operating system: DARWIN
Searching for test containers.
Executing automated test suite... .0C 0C
0C 0C
..
..foo
.
...Message Catalog System: corrupt file.Message Catalog System: corrupt 
file.Message Catalog System: corrupt file.ksh: zxyabc: not found
...Message Catalog System: corrupt file.Message Catalog System: corrupt 
file.Message Catalog System: corrupt file.ksh: zxyabc: not found
..

ooTest Framework - Automated Test of the ooRexx Interpreter


And some further error messages, so I guess I need the 5.0.0 version.


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
Von mein MacBookPro gesendet



> Am 24.02.2018 um 13:00 schrieb Rony G. Flatscher :
> 
> Dear P.O.,
> On 24.02.2018 11:16, oor...@jonases.se  wrote:
>> many thanks for your insights, it brings me to ask a question:
>> 
>> I am building a larger project with many smaller „modules“ and I wanted to 
>> be a brave boy and start directly writing test cases for the modules as I go 
>> along.
> This is actually a very smart move, if you do this! 
> :)
> 
>> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
>> Can I use this version also for ooRexx 5.0.0?
> Yes. However, there is an ooRexx 5.0.0 ooRexxTest, which you will find in 
> svn/oorexx/test/trunk. 
> 
>> 
>> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is 
>> no longer correct, maybe you should do a S for
>> 
>> #!/usr/bin/rexx
>> 
>> and change it to
>> 
>> #!/usr/local/bin/rexx
>> 
>> in all places.
> Yes, Apple has started to force everyone (but Apple) to install to /usr/local 
> (and even did a brute force action by deleting everything unknown from 
> /usr/bin et al at an update to the operating system without even informing 
> the users about it). 
> 
> Also the hash bang for plain ooRexx would need to be adjusted for the ooRexx 
> distribution on MacOS.
> 
> Best regards
> 
> ---rony
> 
>> 
>> 
>>> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher >> >:
>>> 
>>> Since the end of last December I have been working on a new "reflection 
>>> core" for BSF4ooRexx on the
>>> Java side in every free minute (including evenings and weekends). The 
>>> reason being that with Java 9
>>> some internals in the reflection area got changed and issue warnings, and 
>>> it is announced that with
>>> future versions of Java these warnings will be changed to errors.
>>> 
>>> As I would like to support a Java baseline of 1.6/6 the new reflection 
>>> logic has to work also on
>>> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
>>> fundamental changes in the
>>> experimental code I test them against all these versions on the same 
>>> machine using ooRexx 5.0 beta
>>> without rebooting. Needless to say there may be bugs that show up after 
>>> such a change. In order to
>>> be sure that the new functionality is on par with the current functionality 
>>> I regularly employ test
>>> unit runs taking advantage of the latest ooRexx test unit framework 
>>> ("ooRexxTest").
>>> 
>>> The observation and reason why I post this on the ooRexx developer list is 
>>> the following: from time
>>> to time there have been quite surprising problems that have shown up. In a 
>>> couple of instances I
>>> literally traced down for weeks (!) all kind of execution threads of the 
>>> library and the BSF4ooRexx
>>> infrastructure to understand what is happening. Well, yesterday, in 
>>> despair, I killed rxapi and
>>> re-ran the test suit and surprisingly, the unexplainable, erratic surfacing 
>>> errors went away! One
>>> such error was for instance that turning a Java null into an ooRexx .nil by 
>>> sending an object proxy
>>> string to Rexx indicating the object named ".NIL" causing a replacement 
>>> with .nil ("The NIL object")
>>> all of a sudden would assign the string value of the environment symbol 
>>> .NIL instead (if res=".NIL"
>>> then res=.nil) ! After killing rxapi and re-running the test suit 
>>> everything worked as it should,
>>> the unexplainable errors went away!
>>> 
>>> So it seems that there is state in rxapi that can affect a newly created 
>>> Rexx interpreter. In my
>>> complex test environment it seems that when errors occur over time 
>>> eventually rxapi seems to be
>>> affected and in turn newly started Rexx interpreters may get affected as 
>>> well!
>>> 
>>> In case others experience such a phenomenon killing rxapi may save you a 
>>> lot of time!
>>> 
>>> ---rony
> 
>

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread oor...@jonases.se 
Dear Enrico,I do not have any opinion on what is the „best“ shebang but I take note of what you write regarding multiple versions of ooRexx. I assume you are working with macOS/Darwin?Would you mind sharing your Cmakelists.txt? I have written a „howto“ for Mac users to be put on the WIKI but I stumbled on the last stage (making an installer), maybe your changes may point me in the right direction.I have enclosed a simple script that checks the first line of each file in a directory (and its subdirectories) and changes the Shebang. There were some 300+ Changes necessary for the ooTest :-)

FixShebang.rex
Description: Binary data

Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.seVon mein MacBookPro gesendet

Am 24.02.2018 um 13:11 schrieb Enrico Sorichetti :IMO the most flexible shebang line is#! /usr/env/bin xxin this case #! /usr/env/bin rexxit will pick up the executable according to the precedences set by  $PATH environment variablemost useful to test different version of Rexx I usually have a couple of them installed in different directories(  after having changed CMakeLists.txt ways to a more reasonable behaviour )Too bad that the rexx Developers do not let the user set the INSTALL_PREFIXaccording to the user standards but force Their poor choices on the userI still wonder why for APPLE OSX They do not follow the usual *nix logicBest regardsenricoOn 24 Feb 2018, at 11:16, oor...@jonases.se wrote:Dear Rony,many thanks for your insights, it brings me to ask a question:I am building a larger project with many smaller „modules“ and I wanted to be a brave boy and start directly writing test cases for the modules as I go along.When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. Can I use this version also for ooRexx 5.0.0?PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is no longer correct, maybe you should do a S for#!/usr/bin/rexxand change it to#!/usr/local/bin/rexxin all places.
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.seVon mein MacBookPro gesendet

Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher :Since the end of last December I have been working on a new "reflection core" for BSF4ooRexx on theJava side in every free minute (including evenings and weekends). The reason being that with Java 9some internals in the reflection area got changed and issue warnings, and it is announced that withfuture versions of Java these warnings will be changed to errors.As I would like to support a Java baseline of 1.6/6 the new reflection logic has to work also onJava 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are fundamental changes in theexperimental code I test them against all these versions on the same machine using ooRexx 5.0 betawithout rebooting. Needless to say there may be bugs that show up after such a change. In order tobe sure that the new functionality is on par with the current functionality I regularly employ testunit runs taking advantage of the latest ooRexx test unit framework ("ooRexxTest").The observation and reason why I post this on the ooRexx developer list is the following: from timeto time there have been quite surprising problems that have shown up. In a couple of instances Iliterally traced down for weeks (!) all kind of execution threads of the library and the BSF4ooRexxinfrastructure to understand what is happening. Well, yesterday, in despair, I killed rxapi andre-ran the test suit and surprisingly, the unexplainable, erratic surfacing errors went away! Onesuch error was for instance that turning a Java null into an ooRexx .nil by sending an object proxystring to Rexx indicating the object named ".NIL" causing a replacement with .nil ("The NIL object")all of a sudden would assign the string value of the environment symbol .NIL instead (if res=".NIL"then res=.nil) ! After killing rxapi and re-running the test suit everything worked as it should,the unexplainable errors went away!So it seems that there is state in rxapi that can affect a newly created Rexx interpreter. In mycomplex test environment it seems that when errors occur over time eventually rxapi seems to beaffected and in turn newly started Rexx interpreters may get affected as well!In case others experience such a phenomenon killing rxapi may save you a lot of time!---rony--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___Oorexx-devel mailing

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Enrico Sorichetti 
IMO the most flexible shebang line is

#! /usr/env/bin xx

in this case 
#! /usr/env/bin rexx

it will pick up the executable according to the precedences set by  $PATH 
environment variable

most useful to test different version of Rexx
 I usually have a couple of them installed in different directories
(  after having changed CMakeLists.txt ways to a more reasonable behaviour )

Too bad that the rexx Developers do not let the user set the INSTALL_PREFIX
according to the user standards but force Their poor choices on the user

I still wonder why for APPLE OSX They do not follow the usual *nix logic

Best regards

enrico


> On 24 Feb 2018, at 11:16, oor...@jonases.se wrote:
> 
> Dear Rony,
> 
> many thanks for your insights, it brings me to ask a question:
> 
> I am building a larger project with many smaller „modules“ and I wanted to be 
> a brave boy and start directly writing test cases for the modules as I go 
> along.
> 
> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
> Can I use this version also for ooRexx 5.0.0?
> 
> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is 
> no longer correct, maybe you should do a S for
> 
> #!/usr/bin/rexx
> 
> and change it to
> 
> #!/usr/local/bin/rexx
> 
> in all places.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> Von mein MacBookPro gesendet
> 
> 
> 
>> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher > >:
>> 
>> Since the end of last December I have been working on a new "reflection 
>> core" for BSF4ooRexx on the
>> Java side in every free minute (including evenings and weekends). The reason 
>> being that with Java 9
>> some internals in the reflection area got changed and issue warnings, and it 
>> is announced that with
>> future versions of Java these warnings will be changed to errors.
>> 
>> As I would like to support a Java baseline of 1.6/6 the new reflection logic 
>> has to work also on
>> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
>> fundamental changes in the
>> experimental code I test them against all these versions on the same machine 
>> using ooRexx 5.0 beta
>> without rebooting. Needless to say there may be bugs that show up after such 
>> a change. In order to
>> be sure that the new functionality is on par with the current functionality 
>> I regularly employ test
>> unit runs taking advantage of the latest ooRexx test unit framework 
>> ("ooRexxTest").
>> 
>> The observation and reason why I post this on the ooRexx developer list is 
>> the following: from time
>> to time there have been quite surprising problems that have shown up. In a 
>> couple of instances I
>> literally traced down for weeks (!) all kind of execution threads of the 
>> library and the BSF4ooRexx
>> infrastructure to understand what is happening. Well, yesterday, in despair, 
>> I killed rxapi and
>> re-ran the test suit and surprisingly, the unexplainable, erratic surfacing 
>> errors went away! One
>> such error was for instance that turning a Java null into an ooRexx .nil by 
>> sending an object proxy
>> string to Rexx indicating the object named ".NIL" causing a replacement with 
>> .nil ("The NIL object")
>> all of a sudden would assign the string value of the environment symbol .NIL 
>> instead (if res=".NIL"
>> then res=.nil) ! After killing rxapi and re-running the test suit everything 
>> worked as it should,
>> the unexplainable errors went away!
>> 
>> So it seems that there is state in rxapi that can affect a newly created 
>> Rexx interpreter. In my
>> complex test environment it seems that when errors occur over time 
>> eventually rxapi seems to be
>> affected and in turn newly started Rexx interpreters may get affected as 
>> well!
>> 
>> In case others experience such a phenomenon killing rxapi may save you a lot 
>> of time!
>> 
>> ---rony
>> 
>> 
>> --
>> 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
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> --
> 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
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

--
Check out the vibrant tech community on one of the world's most

Re: [Oorexx-devel] An observation ...

2018-02-24 Thread Rony G. Flatscher 
Dear P.O.,

On 24.02.2018 11:16, oor...@jonases.se wrote:
> many thanks for your insights, it brings me to ask a question:
>
> I am building a larger project with many smaller „modules“ and I wanted to be 
> a brave boy and
> start directly writing test cases for the modules as I go along.
This is actually a very smart move, if you do this!
:)

> When I look at the ooRexx site the latest ooRexxTest I could find was 4.2. 
> Can I use this version
> also for ooRexx 5.0.0?
Yes. However, there is an ooRexx 5.0.0 ooRexxTest, which you will find in 
svn/oorexx/test/trunk.

>
> PS I looked into the .rexx files and saw that the Shebang for Unix/Linux is 
> no longer correct,
> maybe you should do a S for
>
> #!/usr/bin/rexx
>
> and change it to
>
> #!/usr/local/bin/rexx
>
> in all places.
Yes, Apple has started to force everyone (but Apple) to install to /usr/local 
(and even did a brute
force action by deleting everything unknown from /usr/bin et al at an update to 
the operating system
without even informing the users about it).

Also the hash bang for plain ooRexx would need to be adjusted for the ooRexx 
distribution on MacOS.

Best regards

---rony

>
>
>> Am 22.02.2018 um 10:46 schrieb Rony G. Flatscher > >:
>>
>> Since the end of last December I have been working on a new "reflection 
>> core" for BSF4ooRexx on the
>> Java side in every free minute (including evenings and weekends). The reason 
>> being that with Java 9
>> some internals in the reflection area got changed and issue warnings, and it 
>> is announced that with
>> future versions of Java these warnings will be changed to errors.
>>
>> As I would like to support a Java baseline of 1.6/6 the new reflection logic 
>> has to work also on
>> Java 1.6/6, 1.7/7 and 1.8 in addtion to Java 9. So whenever there are 
>> fundamental changes in the
>> experimental code I test them against all these versions on the same machine 
>> using ooRexx 5.0 beta
>> without rebooting. Needless to say there may be bugs that show up after such 
>> a change. In order to
>> be sure that the new functionality is on par with the current functionality 
>> I regularly employ test
>> unit runs taking advantage of the latest ooRexx test unit framework 
>> ("ooRexxTest").
>>
>> The observation and reason why I post this on the ooRexx developer list is 
>> the following: from time
>> to time there have been quite surprising problems that have shown up. In a 
>> couple of instances I
>> literally traced down for weeks (!) all kind of execution threads of the 
>> library and the BSF4ooRexx
>> infrastructure to understand what is happening. Well, yesterday, in despair, 
>> I killed rxapi and
>> re-ran the test suit and surprisingly, the unexplainable, erratic surfacing 
>> errors went away! One
>> such error was for instance that turning a Java null into an ooRexx .nil by 
>> sending an object proxy
>> string to Rexx indicating the object named ".NIL" causing a replacement with 
>> .nil ("The NIL object")
>> all of a sudden would assign the string value of the environment symbol .NIL 
>> instead (if res=".NIL"
>> then res=.nil) ! After killing rxapi and re-running the test suit everything 
>> worked as it should,
>> the unexplainable errors went away!
>>
>> So it seems that there is state in rxapi that can affect a newly created 
>> Rexx interpreter. In my
>> complex test environment it seems that when errors occur over time 
>> eventually rxapi seems to be
>> affected and in turn newly started Rexx interpreters may get affected as 
>> well!
>>
>> In case others experience such a phenomenon killing rxapi may save you a lot 
>> of time!
>>
>> ---rony

--
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Another observation (Re: Problem with SysStemSort, but ...

2009-05-25 Thread Rony G. Flatscher 
Rick,

when invoking that program via Java, then it works without a problem!

If invoked via Java then in the native layer an AttachThread() is
invoked, a Routine object is created and invoked with CallRoutine(),
followed by a matching DetachThread().

---rony



Rony G. Flatscher wrote:
 Rick McGuire wrote:
 I just thought of one more thing that could cause the error you're
 seeing.  If you do an AttachThread() at some point and neglect to do a
 corresponding DetachThread() before returning to your caller, you'll
 end up with a corrupted activaation stack that will result in problems
 with legacy callback APIs like RexxVariablePool or RexxStemSort.
 What;s showing up in this traceback very much appears to match what
 might happen in that sort of situation.
   

 In this particular program an external function BSF(), defined as

 RexxRoutine1(RexxObjectPtr, BSF, ARGLIST, argArray) {...}
   

 gets invoked to communicate to the Java side. There are no calls from
 Java into BSF4Rexx occurring, hence there AttachThread() and
 DetachThread() are not invoked in this case (at least not from BSF4Rexx).

 Also, BSF4Rexx in this case does not excercise any variable gets or
 sets. It just interacts with Java and returns a (string) value back,
 which gets stored in the stem.

 ---rony

 P.S.: Just for completeness, here is the Rexx program in question:

 /* classic Rexx version, ---rgf, 2003-02, 2003-05-10, 2003-09-04, 
 2005-12-28 */

 /* this version works on Java 1.1 too (because using wrapEnumeration()) 
 */

   /* load the BSF4Rexx functions and start a JVM, if necessary */
 if rxFuncQuery(BSF) = 1 then   /* BSF() support not loaded yet ? */
 do
call rxFuncAdd BsfLoadFuncs, BSF4Rexx, BsfLoadFuncs
call BsfLoadFuncs  /* load all BSF*() functions  */
call BsfLoadJava   /* load Java  */
 end

/* 'Class.class' is pre-registered for Rexx, cf. docs */
 system=bsf('invoke', 'Class.class', 'forName', 'java.lang.System')

 properties=bsf('invoke', system, getProperties)  /* get the System 
 properties  */

 enum=bsf('invoke', properties, 'propertyNames')/* get an enumeration 
 of the property names */

/* wrap the Enumeration object, so Java 1.1 can handle this too 
 (overcome Java inner class access restriction) */
/* the following statement is *not* necessary for Java = 1.2 */
 enum=bsf('wrapEnumeration', enum)

 say copies(=, 70)

 stem. = 0
 deli  = 010203x
 do i=1 to 5000 while bsf('invoke', enum, 'hasMoreElements') /* loop over 
 enumeration   */
key=bsf('invoke', enum, 'nextElement')
stem.i= key || deli || bsf('invoke', properties, 'getProperty', key)
stem.0=i   /* remember total of elements */
 end

 say stem.0 elements, now sorting...
 call sysStemSort stem.

 l=length(stem.0)
 do i=1 to stem.0
parse var stem.i key (deli) val
say i~right(l): pp(key)~left(31)=pp(val)
 end

 exit

 pp: procedure
return [ || arg(1) || ]
 


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers  brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,  
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA,  Big Spaceship. http://www.creativitycat.com ___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Another observation (Re: Problem with SysStemSort, but ...

2009-05-25 Thread Rony G. Flatscher 

Rick McGuire wrote:
 The other possibility is you've called RexxCreateInterpreter() on a
 thread that was already owned by Rexx.  In that case, the
 RexxThreadContext returned with the instance pushes down the active
 one and can create the same symptoms if you return without destroying
 the instance.  In that situation, you should either create the
 instance on a separate thread or just inherit the instance of the
 program that called you in the first place.
   
In the scenario that rexx.exe is used to run the program (which then
fails), no RexxCreateInterpreter() is carried out by BSF4Rexx.

---rony

 On Mon, May 25, 2009 at 5:08 AM, Rony G. Flatscher
 rony.flatsc...@wu-wien.ac.at wrote:
   
 Rick,

 when invoking that program via Java, then it works without a problem!

 If invoked via Java then in the native layer an AttachThread() is invoked, a
 Routine object is created and invoked with CallRoutine(), followed by a
 matching DetachThread().

 ---rony



 Rony G. Flatscher wrote:

 Rick McGuire wrote:

 I just thought of one more thing that could cause the error you're
 seeing.  If you do an AttachThread() at some point and neglect to do a
 corresponding DetachThread() before returning to your caller, you'll
 end up with a corrupted activaation stack that will result in problems
 with legacy callback APIs like RexxVariablePool or RexxStemSort.
 What;s showing up in this traceback very much appears to match what
 might happen in that sort of situation.


 In this particular program an external function BSF(), defined as

 RexxRoutine1(RexxObjectPtr, BSF, ARGLIST, argArray) {...}


 gets invoked to communicate to the Java side. There are no calls from Java
 into BSF4Rexx occurring, hence there AttachThread() and DetachThread() are
 not invoked in this case (at least not from BSF4Rexx).

 Also, BSF4Rexx in this case does not excercise any variable gets or sets. It
 just interacts with Java and returns a (string) value back, which gets
 stored in the stem.

 ---rony

 P.S.: Just for completeness, here is the Rexx program in question:

 /* classic Rexx version, ---rgf, 2003-02, 2003-05-10, 2003-09-04, 2005-12-28
 */

 /* this version works on Java 1.1 too (because using wrapEnumeration()) */

   /* load the BSF4Rexx functions and start a JVM, if necessary */
 if rxFuncQuery(BSF) = 1 then   /* BSF() support not loaded yet ? */
 do
call rxFuncAdd BsfLoadFuncs, BSF4Rexx, BsfLoadFuncs
call BsfLoadFuncs  /* load all BSF*() functions  */
call BsfLoadJava   /* load Java  */
 end

/* 'Class.class' is pre-registered for Rexx, cf. docs */
 system=bsf('invoke', 'Class.class', 'forName', 'java.lang.System')

 properties=bsf('invoke', system, getProperties)  /* get the System
 properties  */

 enum=bsf('invoke', properties, 'propertyNames')/* get an enumeration of
 the property names */

/* wrap the Enumeration object, so Java 1.1 can handle this too (overcome
 Java inner class access restriction) */
/* the following statement is *not* necessary for Java = 1.2 */
 enum=bsf('wrapEnumeration', enum)

 say copies(=, 70)

 stem. = 0
 deli  = 010203x
 do i=1 to 5000 while bsf('invoke', enum, 'hasMoreElements') /* loop over
 enumeration   */
key=bsf('invoke', enum, 'nextElement')
stem.i= key || deli || bsf('invoke', properties, 'getProperty', key)
stem.0=i   /* remember total of elements */
 end

 say stem.0 elements, now sorting...
 call sysStemSort stem.

 l=length(stem.0)
 do i=1 to stem.0
parse var stem.i key (deli) val
say i~right(l): pp(key)~left(31)=pp(val)
 end

 exit

 pp: procedure
return [ || arg(1) || ]


 


--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers  brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,  
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA,  Big Spaceship. http://www.creativitycat.com 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel