Menu
▾
▴
1 Attachments
#1576 Problems when running Macrospace testgroup on a MAC
When running the macrospace.testgroup the execution breaks and no results are found at the end. I have gone through all the assertions and commented out the ones that breaks the execution. For some tests the execution continues but the testgroup finishes with a to low number of assertions.
I have tried my own installer (without an rxapi daemon) but also th installer for BSF4ooRexx, WITH a daemon running, both have these problems.
I have attached a file where I have commneted out the assertions that break the execution, all other tests run as they should.
The commandline I used was
rexx testOORexx.rex -R ./ooRexx/base/rexxutil -s -S -X native_api -f Macrospace.testGroup
(Please note: I could not make the simpler syntax proposed by Erich rexx testOORexx.rex -f Macrospace.testGroup work, no testgroups are found with this syntax, I need the ./ on the MAC to locate the testgroups in subdirectories)
Related
Discussion
Anonymous
You have merely commented out all of the tests that involve significant communication with rxapi. This is not really useful information.
I am sorry this was not helpful. When I "say" the items commented out I get this info
::method test_add_three_args_option
Event: [SYNTAX 98.986] raised unexpectedly.
Reference to unassigned variable "TEST_ADD".
Line: 176
176 - say 'test_add' test_add
Event: [SYNTAX 98.986] raised unexpectedly.
Reference to unassigned variable "OPTION".
Line: 178
178 - say 'option' option
So it seems that the variables going into the test are not defined. If that is on purpose to provoke the error I can not tell.
If you do not want to pursue these items please close the ticket, I will comment out the problem cases and keep a log of what I did for later.
Since test_add is not a variable, that is the correct result. test_add() should be the name of an external function that has been added to the macrospace. That is the part that requires the rxapi daemon.
Just for my understanding;
you are saying that this code is correct
::method test_add_three_args_option
do option over "a", "b", "A", "B"
self~assertEquals(self~OK, SysClearRexxMacroSpace())
self~assertEquals(self~OK, SysAddRexxMacro("test_add", self~macroPath, option))
self~assertEquals(option~upper, SysQueryRexxMacro("test_add"))
/Dbg self~assertEquals(self~macroRc, test_add())/
end
In particular the call SysAddRexxMacro("test_add", self~macroPath, option) have the correct syntax, it is just failing (on the MAC) because of some problem with rxapi?
Please note that I DO have the rxapi daemon running when I do the test, this is done with the BSF4ooRexx installer that have stood up to every other test I have thrown on it until now, except these ones.
I have no idea on how to check this further at the moment but maybe the general discussion will provide the answer eventually.
Von meinen Macbook gesendet
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1576Yes, that is what I am saying. It runs fine on Windows and as far as I know, fine on every other platform (including Sun). Assuming you have an up-to-date build, this likely points to an issue with the rxapi daemon. Given you are not running a build provided by the project, this is not my problem to solve.
ooRexx in BSF4ooRexx is built with the project's CMake definitions right from the project's trunk without any edits.
If I understood P.O. correctly all other tests run successfully also those that interface with rxapi, but the macrospace tests exhibit problems. So the setupaccording to Apple's rules works in principle.
Short of being able to look into this myself right now (will be able to do so on the weekend) two speculative ideas: maybe the constant relaunching of rxapid on MacOSX causes this, or maybe the write flag needs to be set for rxapi* group or world, which would be prohibited on MacOSX for daemons.
it looks like your rxapi is the one for oorexx v4.
[bugs:#1388] gives details about what's wrong with rxapi v4.
You could confirm by checking the full path of your rxapi, using pathfind.c
https://stackoverflow.com/questions/14805896/how-do-i-get-the-full-path-for-a-process-on-os-x.
Macrospace.testGroup is ok for me when using rxapi v5.
Related
Bugs:
#1388Thanks, I will look into that tomorrow, it relates to the Bsf4ooRexx installer as well so I have CCed Rony.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1388Bugs:
#1576dear jfaucher (sorry I do not have your name),
I did just that and the result is
proc 2019: /Library/Frameworks/ooRexx.framework/Versions/A/Commands/rxapi
which is the expected result, this is the place where BSF4ooRexx puts its binaries. But this does not give any further information as to what version it is. I only have one installation on the machine at the time, I wipe everything between changes (for the testing).
Also I cannot compare to installations I have built on my own, there are slight changes in size on all files depending on what compiler version is made, what optimization is done etc so I would need more information
I will try to take the rxapi from my own build and put it in …/Commands in the BSF4ooRexx installation, if that makes a difference I will let you know.
Also I will seek advice from the BSF community.
Von meinen Macbook gesendet
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1388Bugs:
#1576I just went ahead and did some brain surgery on the BSF4ooRexx installation, I replace all files with the ones from my build 18.11.2018 and could then confirm that test cases that failed earlier due to missing classes where now running without error. I could also see that the test had picked up the date of my build.
However, the behavior for the macrospace testgroup was the same, when I tried to run the full test it failed miserably. Everything else runs now so I need to find out why this happens. Either there is something specific to my machine (I run macOS High Sierra with no special features) or the installation picks up the wrong rxapi for DARWIN. I can not think of anything else.
Please advice how to find out what rxapi I have.
Using a Hex editor I looked at the beginning of the binary, this is what I saw:
librexx.5.0.0.dylib 0librexxapi.5.0.0.dylib 82‰/usr/lib/libSystem.B.dylib 0 ê/usr/lib/libc++.1.dylib&h‚)Ä„ Ä( /opt/oorexx5.0.0/lib
Seems to point to version 5, no?
Gotta go, back this afternoon
Von meinen Macbook gesendet
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oorexx@jonases.se
Related
Bugs:
#1388Bugs:
#1576Just finished creating a new BSF4ooRexx installation package for MacOSX which includes ooRexx from trunk (can be obtained from https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/).
Ran all ooRexx test units in test/trunk/ooRexx/base/ which includes the Macorspace.testGroup and all tests pass in that environment.
This looks like an invalid setup, not a bug in the code.
Hmm, I have to correct my statement: running the Macrospace.testGroup tests on the latest MacOS stops the execution of testOORexx.rex without an error message or statistic output, rather:
Not sure what the reason could be.
rc is zero (0).
Ran it with address...with to be sure to get the pristine rc.
Forgot the rexxtry.rex-session:
I've set up a Jenkins client on P.O.'s Mac to build and run tests for the rxapi sandbox version.
It builds fine and passes all tests.
I noticed, that it was difficult to get the recently built sandbox rxapi version of Rexx to run, as some older, already-installed components would always be picked up. Setting PATH was insufficient, and I had to CD into the install directory and start rexx from there.