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