(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
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,
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
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
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().
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
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
>
> 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
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
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
>
> 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
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
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
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
>
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
