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... .000000000C 000000000C
000000000C 000000000C
..........................................
......................................................................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 <rony.flatsc...@wu.ac.at>:
>
> Dear P.O.,
> On 24.02.2018 11:16, oor...@jonases.se <mailto: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&R 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 <rony.flatsc...@wu.ac.at
>>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>
>>> 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
