Re: [Oorexx-devel] Question ad solution for two trace related tests failing in trace exits

[Rony G. Flatscher]

After having gone through the code and running the RXTRC Java exit handler the traceObject works 
there as well. Not sure why the objectname gets displayed in the testbinaries test case rather than 
the makeString.


Anyway, will adjust the testcase accordingly as there seems to be no need to change anything in the 
native code.


---rony



On 13.03.2024 19:21, Rony G. Flatscher wrote:


There are two trace related tests in the test suite failing (all other pass):

[failure] 20240313 18:16:37.50
  Test:   TESTIOEXITTRACE
  Class:  RexxStart.testGroup
  File: ...\oorexx\test\trunk\ooRexx\API\oo\ProcessRexxStart.testGroup
  Line:   244
  Failed: assertEquals
    Expected: 47 *-* call trace OFF
    Actual:   a TraceObject

[failure] 20240313 18:16:41.827000
  Test:   TESTIOEXITTRACE
  Class:  RexxStart.testGroup
  File: ...\oorexx\test\trunk\ooRexx\API\oo\RexxStart.testGroup
  Line:   248
  Failed: assertEquals
    Expected: 47 *-* call trace OFF
    Actual:   a TraceObject

The tests use the classic Rexx exit interface and it seems that in these cases where now an 
instance of TraceObject gets returned instead of a string, then the result of sending "objectname" 
gets used ("a TraceObject"), instead the traceObject should get "request('String')" gets sent to 
it which would return the string "47 *-* call trace OFF".


---

Where should the change made in this case, in the testcase (it can be adapted to collect the 
generated trace object and then return its traceLine entry instead of the trace exits generated 
string "a TraceObject") or in native code? If in native code, where exactly should the change be 
applied?


---rony

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

Re: [Oorexx-devel] Question ad rexx.img

[Rony G. Flatscher]

On 07.01.2024 20:00, Rick McGuire wrote:


On Sun, Jan 7, 2024 at 1:21 PM Rony G. Flatscher  
wrote:

Is rexx.img dependent on the architecture and bitness?


Yes, it contains LOTS of binary data that depends on the bitness of the architecture. There are 
some bits that might even be dependent on the compiler used to compile the interpreter that 
created the image file.



With other words: can a rexx.img be used at the same time for arm64 and 
amd64 (Intel)?


Not a chance.


Thank you for the clarification, Rick!

---

Testing the current beta of ooRexx for the macOS which is a universal package. The binaries are all 
universal (both, arm64 and amd64 in one file) such that the loader is able to decide to pick the 
version that is appropriate for the platform. "rexx.img" is located in the lib directory 
(/usr/local/lib) next to the universal libraries.


So for the macOS universal installer we need to come up with some solution for this problem like 
having the installer pick the target platform's rexx.img version. Alternatively, we should not 
produce a universal macOS package for ooRexx, but rather have two different installers, one for 
amd64 and one for arm64.


What do you think would be the most appropriate approach?

---rony

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

Re: [Oorexx-devel] Question ad rexx.img

[Rick McGuire]

On Sun, Jan 7, 2024 at 1:21 PM Rony G. Flatscher 
wrote:

> Is rexx.img dependent on the architecture and bitness?
>

Yes, it contains LOTS of binary data that depends on the bitness of the
architecture. There are some bits that might even be dependent on the
compiler used to compile the interpreter that created the image file.


>
> With other words: can a rexx.img be used at the same time for arm64 and
> amd64 (Intel)?
>

Not a chance.


>
> ---rony
>
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad native tests ...

[Rony G. Flatscher]

On 02.02.2023 18:02, Rick McGuire wrote:



On Thu, Feb 2, 2023 at 11:53 AM Rony G. Flatscher  
wrote:

While looking into what is needed to formulate native tests I found


... cut ...


The native test code is not located under test/trunk, but rather in 
main/trunk/testbinaries.
Why are these files not located under test/trunk/testbinaries? What is the 
reason for this?

They were moved there years ago so that they always get built as part of the build rather than 
requiring a separate build step that was more difficult to set up.


Thank you.

So the testbinaries get generated whenever ooRexx gets built (residing in the bin directory 
afterwards), so they just do not get installed.


Hmm, then speculating from test/trunk/ReadMe.first:

1.)  Simple command line, running the entire test suite at one time.


   NOTE: Starting with ooRexx 4.0.0, the test suite contains tests that require
   external executables.  These are tests to exercise the ooRexx native API.
   Running these tests makes things slightly more complex.  There are 3 options
   here, simplest to hardest.

   1.) Skip the native API tests altogether.  The best option if you are just
   getting familiar with the test suite.

   2.) Download the pre-compiled external binaries for your system.  Details on
   picking and installing the proper set are in the Release.notes in the doc
   directory.

   NOTE: at this time the pre-compiled binareies are NOT available.  If you are
   interested enough to want the pre-compiled binaries, post a note to either
   the ooRexx developers list or the ooRexx users list requesting the binaries
   and one of the developers will make thenm available.

   3.) If you understand, somewhat, compiling C / C++ files you can compile
   your own binaries as part of running the automated test suite.  Details for
   this step have not been written, just post a question on the ooRexx
   developers list or the ooRexx users list.

   Start in the root directory, the directory that contains this file.  The
   Rexx program that runs the tests is: testOORexx.rex

   That is the only file you need to use to begin with.  We will assume that
   you are using option 1 above, skipping the tests for the native API
   binaries.  The program file will run the ooRexx test suite.  Depending on
   the horse power in your system this could take 5 or 6 minutes, maybe longer
   on a real old system.

   Once you invoke testOORexx everything runs automatically and you will see
   the results printed on the screen when the test finishes.

   The argument: '-X native_api' in the following examples tells the framework
   to eXclude the native API tests.

So one needs to build ooRexx and then make its bin directory available on PATH and can then run the 
native tests successfully?


Is that correct? Is there anything else to be aware of?

---rony

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

Re: [Oorexx-devel] Question ad native tests ...

[Rick McGuire]

On Thu, Feb 2, 2023 at 11:53 AM Rony G. Flatscher 
wrote:

> While looking into what is needed to formulate native tests I found
>
> F:\work\svn\oorexx\test\trunk>grep -R LoadPackage
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackage EXTERNAL "LIBRARY 
> orxmethod TestLoadPackage"
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackageFromData EXTERNAL 
> "LIBRARY orxmethod TestLoadPackageFromData"
>
> F:\work\svn\oorexx\test\trunk>grep -Rl orxmethod *
> ooRexx/API/oo/CONVERSIONPackage.cls
> ooRexx/API/oo/METHODPackage.cls
>
> but lack the native (C++) files that would implement the test methods.
>
> Also have not been able to find any usage of TestLoadPackage[FromData] in
> any of the test units:
>
> F:\work\svn\oorexx\test\trunk>grep -Ri TestLoadPackage
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackage EXTERNAL "LIBRARY 
> orxmethod TestLoadPackage"
> ooRexx/API/oo/METHODPackage.cls:::method TestLoadPackageFromData EXTERNAL 
> "LIBRARY orxmethod TestLoadPackageFromData"
>
> The native test code is not located under test/trunk, but rather in
> main/trunk/testbinaries. Why are these files not located under
> test/trunk/testbinaries? What is the reason for this?
>
They were moved there years ago so that they always get built as part of
the build rather than requiring a separate build step that was more
difficult to set up.



> Is there anything else one needs to be aware of (regarding locations of
> files belonging to the test framework)?
>
> How can one just run the native tests, how would one have to invoke them?
>
> ---rony
>
> P.S.: This is for creating tests for:
>
> Bugs
>
>  126: # 1625 NewRoutine() and LoadPackageFromData() raise error 13.1 on
> tokenized Rexx code
>  (entered by Rony G. Flatscher on 2019-04-06 -> 2019-07-16)
> ***TODO: [doc+test]
>
>  127: # 1624 .Routine~newFile(rexxc-program) raises error 13.1
>  (entered by Rony G. Flatscher on 2019-04-06 -> 2019-04-17)
> ***TODO: [doc+test]
>
> RFE
>
>   27: #  754 'rexxc' binary (compiled/tokenized) data: please encode as
> plain text (7-Bit-ASCII) to allow it to be read as a string (e.g. from Java
> java.io.Reader)
>  (entered by Rony G. Flatscher on 2019-04-07 -> 2020-03-08)
> ***TODO: [tests]
>
>
> ___
> 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

Re: [Oorexx-devel] Question with ooRexx 5.0.0 and some error "Error:94.101 - Error connecting to 127.0.0.1 on port 5757: "No error"" while issuing a command

[Rony G. Flatscher]

On 10.01.2023 16:29, Rick McGuire wrote:
Just a shot in the dark, but is it possible you are accidentally picking up the Regina version of 
rxqueue?


Yes, I think that is the problem (found a link on the Internet with the error message, which I 
posted and which overlapped with your message). Thank you for your shot!


---rony




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

Re: [Oorexx-devel] Question with ooRexx 5.0.0 and some error "Error:94.101 - Error connecting to 127.0.0.1 on port 5757: "No error"" while issuing a command

[Rick McGuire]

Just a shot in the dark, but is it possible you are accidentally picking up
the Regina version of rxqueue?

Rick

On Tue, Jan 10, 2023 at 10:20 AM Rony G. Flatscher 
wrote:

> Received the following rexxtry.rex session on a Windows 10 machine:
>
> C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>*rexx rexxtry*
> REXX-ooRexx_*5.0.0*(MT)_64-bit 6.05 23 Dec 2022
> rexxtry.rex lets you interactively try REXX statements.
> Each string is executed when you hit Enter.
> Enter 'call tell' for a description of the features.
> Go on - try a few... Enter 'exit' to end.*command="java -cp . 
> JavaInfo4BSF4RexxInstallation | rxqueue"*
> ... rexxtry.rex on WindowsNT*address 
> system command**Error:94.101 - Error connecting to 127.0.0.1 on port 5757: 
> "No error"*rc = 101 .. rexxtry.rex on 
> WindowsNT
> exit
> C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>
>
> It seems that a socket is tried to be opened which does not succeed and
> yield an error "94.101" which looks like a Rexx error number, but is not
> defined nor documented. The error string is in addition contradictive: "...
> Error connecting ..." and ending in "No error".
>
> What can be the cause, how could one overcome this problem?
>
> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question with ooRexx 5.0.0 and some error "Error:94.101 - Error connecting to 127.0.0.1 on port 5757: "No error"" while issuing a command

[Rony G. Flatscher]

Possibly solved, cf. .

According to the above URL it seems that Regina's rxqueue gets picked up and 
not ooRexx' rxqueue.

---rony

On 10.01.2023 16:19, Rony G. Flatscher wrote:


Received the following rexxtry.rex session on a Windows 10 machine:

C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>*rexx rexxtry*
REXX-ooRexx_*5.0.0*(MT)_64-bit 6.05 23 Dec 2022
rexxtry.rex lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
Go on - try a few... Enter 'exit' to end.
*command="java -cp . JavaInfo4BSF4RexxInstallation | rxqueue"*
... rexxtry.rex on WindowsNT
*address system command*
*Error:94.101 - Error connecting to 127.0.0.1 on port 5757: "No error"*
rc = 101  .. rexxtry.rex on WindowsNT
exit
C:\Users\Walter\Downloads\tmp\bsf4oorexx\install>

It seems that a socket is tried to be opened which does not succeed and yield an error "94.101" 
which looks like a Rexx error number, but is not defined nor documented. The error string is in 
addition contradictive: "... Error connecting ..." and ending in "No error".


What can be the cause, how could one overcome this problem?

---rony

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

Re: [Oorexx-devel] Question ad updating copyright statement in sources

[Rick McGuire]

In general, we only update the copyrights in the source files if they have
an update. It doesn't always get done, but it's ok if the files have
different copyright dates.

Rick

On Fri, Dec 23, 2022 at 5:34 AM Rony G. Flatscher 
wrote:

> Just noticed that there are plenty of files in the code area that have
> their copyright statements not updated to 2022.
>
> Question: shall we update the copyright notice there like we did for the
> documentation?
>
> If so, what patterns should we use for SysFileTree to look for existing
> copyright text that should be updated? E.g.:
>
> *.html *.txt *.rex *.cls *.?pp *.h
>
> ---rony
> ___
> 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

Re: [Oorexx-devel] Question ad copyright string

[Rony G. Flatscher]

On 23.12.2022 00:08, Chip Davis wrote:
While I agree with Jon about readability, I scanned the web for "how to format a copyright notice" 
and found not a single example that used a comma (or any break besides a space) between the date 
and the copyright holder.


Thank you too!

As you both are native English speakers and prefer the comma I would leave it 
that way.

---rony




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

Re: [Oorexx-devel] Question ad copyright string

[Chip Davis]

While I agree with Jon about readability, I scanned the web for "how 
to format a copyright notice" and found not a single example that used 
a comma (or any break besides a space) between the date and the 
copyright holder.


-Chip-

On 12/22/2022 11:59 AM, Sahananda Sahananda wrote:

It reads better WITH the comma imho, but then, who reads it?

Jon

On Thu, 22 Dec 2022 at 16:53, Rony G. Flatscher 
mailto:rony.flatsc...@wu.ac.at>> wrote:


While creating a little script that does bulk updates to the
copyright statements in all files I noticed that there are two
styles in use, one with a comma immediately following the year
portion, one without that comma, e.g.:

ooconsole/en-US/ooconsole.xml:10:# Copyright (c) 2014-2014 Rexx 
Language Association. All rights reserved.
   ootest/en-US/testoorexx.xml:10:# Copyright (c) 2005-2014*,*  
Rexx Language Association. All rights reserved.

Which form should the updated copyright string take, with the
comma or without the comma after the year portion?

---rony

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

Re: [Oorexx-devel] Question ad copyright string

[Sahananda Sahananda]

It reads better WITH the comma imho, but then, who reads it?

Jon

On Thu, 22 Dec 2022 at 16:53, Rony G. Flatscher 
wrote:

> While creating a little script that does bulk updates to the copyright
> statements in all files I noticed that there are two styles in use, one
> with a comma immediately following the year portion, one without that
> comma, e.g.:
>
> ooconsole/en-US/ooconsole.xml:10:# Copyright (c) 2014-2014 Rexx Language 
> Association. All rights reserved.
>   ootest/en-US/testoorexx.xml:10:# Copyright (c) 2005-2014*,* Rexx 
> Language Association. All rights reserved.
>
> Which form should the updated copyright string take, with the comma or
> without the comma after the year portion?
>
> ---rony
> ___
> 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

Re: [Oorexx-devel] Question ad release documentation ...

[Rony G. Flatscher]

Dear P.O.,

On 21.12.2022 11:24, ooRexx wrote:
I have no objection to the changes below but I would like the revision information still visible 
somewhere in the beginning of each book; that is useful for trunk later on as the date may reflect 
the build date of the book so if it is built later (without updating SVN) the date may be 
misleading. Would it be possible with something like the below on the second page, after ENTITY 
EDITION


What do you think?


Actually I have been thinking of the revision strings seeing that the generated installation 
packages for the release have the hightest revision number at the time of building. Just did not 
have the time to go after it (maybe it is possible to change CMakeLists.txt file accordingly but 
again, short of time I would postpone that, but anybody who is able and wants to give a helping hand 
would be very welcome!).


Ad revision information about the docs: yes, this has been in the back of my mind and again, short 
of time I have not been able to tackle that yet. The idea would have been to add a string containing 
the book's revision number and the date of that revision using e.g. "tools\svnListRevisions.rex 
rexxapi" and then writing to a text file like rexxapi\revisionInfo.txt containing "(r12560 as of 
2022-12-20T15:29:51.959801)" and including it on the second page right next to EDITION. There would 
be a script that would do that for all books.


As I was planning of writing a script that allows to update the entity values for YEAR, VERSION and 
EDITION in bulk for all the books (using the appropriate ${book}\en-US\${book}.ent) I might as well 
add that revision string to the EDITION entity when the program changes the EDITION entity value.


2nd item: I read somewhere that you split a book? What book? Do I need to change the build 
procedure? Sorry for asking but I am getting drowned by mails to wade through  :-)


Well, there has been a little burst in e-mails lately ... :)

This has already been done successfully: the split was for "rexxpg.pdf" which originally included a 
beginner's introduction to Rexx and ooRexx and also the C and C++ native API documentation. After 
the split there were two books, "rexxpg.pdf" (intro) and "rexxapi.pdf" (C/C++ API documentation).


So no action item needed here.

Best regards

---rony




On 20. Dec 2022, at 14:28, Rony G. Flatscher  wrote:

While updating the documentation ent files for trunk I also changed the date 
related information.

The ent (entity files) contain the following book/version related information, here from 
"rexxapi/en-US/rexxapi.ent":








... cut ...

I suggest to change this for all release books to:







... cut ...

This way the documentation reflects the release date date.

Is this seen to be reasonable?

---rony

N.B.: Noticed that after splitting the old "rexxpg" into "rexxapi" and "rexxpg" that the book id 
should change for rexxapi to "rexxapi": will do that for branches/5.0.0 and in parallel for trunk.


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

Re: [Oorexx-devel] Question ad release documentation ...

[ooRexx]

Dear Rony,

I have no objection to the changes below but I would like the revision 
information still visible somewhere in the beginning of each book; that is 
useful for trunk later on as the date may reflect the build date of the book so 
if it is built later (without updating SVN) the date may be misleading. Would 
it be possible with something like the below on the second page, after ENTITY 
EDITION

What do you think?

2nd item: I read somewhere that you split a book? What book? Do I need to 
change the build procedure? Sorry for asking but I am getting drowned by mails 
to wade through  :-)

Hälsningar/Regards/Grüsse,
ooRexx
oor...@jonases.se



> On 20. Dec 2022, at 14:28, Rony G. Flatscher  wrote:
> 
> While updating the documentation ent files for trunk I also changed the date 
> related information.
> 
> The ent (entity files) contain the following book/version related 
> information, here from "rexxapi/en-US/rexxapi.ent":
> 
> 
> 
> 
> 
> 
> 
> ... cut ...
> I suggest to change this for all release books to:
> 
> 
> 
> 
> 
> 
> 
> ... cut ...
> This way the documentation reflects the release date date.
> 
> Is this seen to be reasonable?
> 
> ---rony
> 
> N.B.: Noticed that after splitting the old "rexxpg" into "rexxapi" and 
> "rexxpg" that the book id should change for rexxapi to "rexxapi": will do 
> that for branches/5.0.0 and in parallel for trunk.
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad redirection handlers and input, output, error ...

[Rony G. Flatscher]

On 03.09.2022 11:26, Rick McGuire wrote:

Nothing. If redirection is not active, then ooRexx is not handling the input 
and output.


Thanks.

---rony


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

Re: [Oorexx-devel] Question ad redirection handlers and input, output, error ...

[Rick McGuire]

Nothing. If redirection is not active, then ooRexx is not handling the
input and output.

Rick

On Sat, Sep 3, 2022 at 5:21 AM Rony G. Flatscher 
wrote:

> In a redirection handler it may be the case that redirection is not active
> for the invocation
> (isRedirectionRequested() returns false).
>
> Question: if redirection is not active, what happens if one still uses
> ReadInput[Buffer](),
> WriteOutput[Buffer](), WriteError[Buffer]()? Will ReadInput[Buffer]() read
> from stdin,
> WriteOutput[Buffer]() write to stdout and WriteError[Buffer]() write to
> stderr?
>
> ---rony
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad exit "1.15.2.4. RXCMD"

[Rony G. Flatscher]

On 30.08.2022 18:11, Rick McGuire wrote:



On Tue, Aug 30, 2022 at 11:07 AM Rony G. Flatscher  
wrote:

While testing a RXMCD exit, implemented in Java and preconfigured for the 
Rexx instance,
commands trigger the exit, however the DLL information is not supplied, but 
empty (expecting
"BSF4ooRexx850.dll" as that is the library that contains the callback 
function).  Also, trying
it with AddCommandEnvironment()-API would not supply the dll name.

The sequence is: a Java program loads and configures a Rexx instance, 
setting a RXCMD exit
handler (implemented in Java) and a RexxRedirectingCommandHandler 
(implemented in Java),
the callback functions are in the native DLL ("BSF4ooRexx850.dll"). 
Both handlers get
invoked, the RXCMD exit handler does not get a dll name (it is empty).

In addition, the exit intercepts also commands to CMD, however the dll name 
is empty as well.

rexxapi.pdf says among other things:

Example 1.43. API — Rexx_IO_Exit parameter list
typedef struct {
struct { /* Condition flags */
unsigned rxfcfail : 1; /* Command failed. Trap with */
/* CALL or SIGNAL on FAILURE. */
unsigned rxfcerr : 1; /* Command ERROR occurred. */
/* Trap with CALL or SIGNAL on */
/* ERROR. */
} rxcmd_flags;
const char * rxcmd_address; /* Pointer to address name. */
unsigned short rxcmd_addressl; /* Length of address name. */
*const char * rxcmd_dll; /* dll name for command. */unsigned short 
rxcmd_dll_len; /* Length of dll name. 0 ==> *//* executable file. */*
CONSTRXSTRING rxcmd_command; /* The command string. */
RXSTRING rxcmd_retc; /* Pointer to return code */
/* buffer. User allocated. */
} RXCMDHST_PARM;

What does "Length of dll name. 0 ==> executable file" mean, when would that 
take effect? Is
there anything I need to/can do to get at the DLL-name in the exit?

Nothing, it appears. I don't know what that field was every used for, and from the documentation, 
it sounds like it was intended for something other than the dll name of the exit. This is born out 
by the fact that the other exits that can be registered as dlls don't have that field. However, as 
far back as 3.1.2, it has always been set to null.


Thank you! Maybe we should  add/change a comment to the effect "rxcmd_dll is always set to null" and 
"rxcmd_dll_len is always set to 0"?


---rony


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

Re: [Oorexx-devel] Question ad exit "1.15.2.4. RXCMD"

[Rick McGuire]

On Tue, Aug 30, 2022 at 11:07 AM Rony G. Flatscher 
wrote:

> While testing a RXMCD exit, implemented in Java and preconfigured for the
> Rexx instance, commands trigger the exit, however the DLL information is
> not supplied, but empty (expecting "BSF4ooRexx850.dll" as that is the
> library that contains the callback function).  Also, trying it with
> AddCommandEnvironment()-API would not supply the dll name.
>
> The sequence is: a Java program loads and configures a Rexx instance,
> setting a RXCMD exit handler (implemented in Java) and a
> RexxRedirectingCommandHandler (implemented in Java), the callback functions
> are in the native DLL ("BSF4ooRexx850.dll"). Both handlers get invoked, the
> RXCMD exit handler does not get a dll name (it is empty).
>
> In addition, the exit intercepts also commands to CMD, however the dll
> name is empty as well.
>
> rexxapi.pdf says among other things:
>
> Example 1.43. API — Rexx_IO_Exit parameter list
> typedef struct {
> struct { /* Condition flags */
>unsigned rxfcfail : 1; /* Command failed. Trap with */
>/* CALL or SIGNAL on FAILURE. */
>unsigned rxfcerr : 1; /* Command ERROR occurred. */
>/* Trap with CALL or SIGNAL on */
>/* ERROR. */
> } rxcmd_flags;
> const char * rxcmd_address; /* Pointer to address name. */
> unsigned short rxcmd_addressl; /* Length of address name. */*const char *   
> rxcmd_dll; /* dll name for command. */**unsigned short rxcmd_dll_len; /* 
> Length of dll name. 0 ==> */**  /* executable 
> file. */*
> CONSTRXSTRING rxcmd_command; /* The command string. */
> RXSTRING rxcmd_retc; /* Pointer to return code */
> /* buffer. User allocated. */
> } RXCMDHST_PARM;
>
> What does "Length of dll name. 0 ==> executable file" mean, when would
> that take effect? Is there anything I need to/can do to get at the DLL-name
> in the exit?
>
Nothing, it appears. I don't know what that field was every used for, and
from the documentation, it sounds like it was intended for something other
than the dll name of the exit. This is born out by the fact that the other
exits that can be registered as dlls don't have that field. However, as far
back as 3.1.2, it has always been set to null.

Rick



> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad ADDRESS keyword statement

[Rony G. Flatscher]

On 25.08.2022 17:35, Rick McGuire wrote:

No, it should not, at least not the way you are expecting. This falls into the

address expression

branch of the syntax diagram, which can only be used to change the current address target and not 
to issue a command. The new address environment is set to "TEST ping", the result of evaluating 
the entire expression.


Ah, I see, thank you!

---rony



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

Re: [Oorexx-devel] Question ad ADDRESS keyword statement

[Rick McGuire]

No, it should not, at least not the way you are expecting. This falls into
the

address expression

branch of the syntax diagram, which can only be used to change the current
address target and not to issue a command. The new address environment is
set to "TEST ping", the result of evaluating the entire expression.

Rick

On Thu, Aug 25, 2022 at 11:27 AM Rony G. Flatscher 
wrote:

> Should the following ADDRESS statement work?
>
> environment="TEST"
> say 'environment:' pp(environment)
> say .line "command:" pp(sourceline(.line+1))*address (environment) "ping"*
> say " RC:" pp(rc) ".rs="pp(.rs) "| RESULT="pp(result)
>
> Running the above ADDRESS keyword statement seems to have no effect at
> all, here is the output:
>
> environment: [TEST]
> 49 command: [address (environment) "ping"]
>  RC: [RC] .rs=[.RS] | RESULT=[RESULT]
>
> It is as if this form of the address statement gets ignored (the
> environment handler for TEST does not get invoked).
>
> ---rony
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad ReadInputBuffer

[Rony G. Flatscher]

On 22.08.2022 20:39, Rick McGuire wrote:

Yes, all of the lines get terminated by an eol marker.


Thank you!

---rony



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

Re: [Oorexx-devel] Question ad ReadInputBuffer

[Rick McGuire]

Yes, all of the lines get terminated by an eol marker.

Rick

On Mon, Aug 22, 2022 at 2:10 PM Rony G. Flatscher 
wrote:

> When reading with ReadInputBuffer() from input that has only one element,
> then this function appends
> .endOfLine nevertheless. Eg. a single input item like the string "one"
> becomes "one"||.endofline
>
> Is this intentionally?
>
> ---rony
>
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad Write{Output|Error}Buffer

[Erich Steinböck]

>
> how about using WriteOutput()/WriteError() to supply binary data?

WriteOutput and WriteError write the supplied data unmodified to any
redirection object.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad Write{Output|Error}Buffer

[Rony G. Flatscher]

On 18.08.2022 12:24, Rick McGuire wrote:

The data written is split at linend boundaries.


Thank you for the clarification!

One remark ad codepage here (as Strings in Java are always codepage related): if there is UTF-16 or 
UTF-32 text exchanged then it may be the case that LF and CR-LF characters are not correct. Here a 
rexxtry session:


   call bsf.cls
  ... rexxtry.rex on WindowsNT
   lf="0d0a"x;a="one"lf"two";say a; say a~c2x
   one
   two
   6F6E65*0D0A*74776F
  ... rexxtry.rex on WindowsNT
   b=bsf.iconv(a, "CP437", "UTF-16")
  ... rexxtry.rex on WindowsNT
   say b;say b~c2x
   o n e
 t w o
   FEFF006F006E0065*000D000A*00740077006F
  ... rexxtry.rex on WindowsNT
   d=bsf.iconv(a, "CP437", "UTF-32")
  ... rexxtry.rex on WindowsNT
   say d;say d~c2x
   o   n   e
   t   w   o
   006F006E0065*000D000A*00740077006F
  ... rexxtry.rex on WindowsNT

With UTF-8 this would not be a problem:

   say c;say c~c2x
   one
   two
   6F6E65*0D0A*74776F
  ... rexxtry.rex on WindowsNT

---

Would you think it to be feasible at this time to have also "raw" versions like ReadInputBufferRaw, 
WriteOutputBufferRaw, WriteErrorBufferRaw such that one could process and produce binary data 
exploiting the new redirecting command handlers?


---rony




On Thu, Aug 18, 2022 at 6:01 AM Rony G. Flatscher  
wrote:

The Write{Output|Error}Buffer API states:

Adds a string composed of strings separated by the platform-specfic 
line-end characters as
separate
items or lines to an output redirection Rexx object that was specified 
using the WITH
subkeyword of
an ADDRESS instruction.

Is there any processing done on the received data or does the 
Write{Output|Error}Buffer-API
just take the receive data as is and place it as a single item to the 
output sink? In this
case it would become possible to produce binary data as a result of a 
command (and will
motivate the need of an additional API on the Java side to become able to 
distinguish between
Strings (Reader,Writer, codepage dependent) and Streams (byte oriented, raw 
data)).

---rony

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

Re: [Oorexx-devel] Question ad Write{Output|Error}Buffer

[Rick McGuire]

The data written is split at linend boundaries.

Rick

On Thu, Aug 18, 2022 at 6:01 AM Rony G. Flatscher 
wrote:

> The Write{Output|Error}Buffer API states:
>
> Adds a string composed of strings separated by the platform-specfic
> line-end characters as separate
> items or lines to an output redirection Rexx object that was specified
> using the WITH subkeyword of
> an ADDRESS instruction.
>
> Is there any processing done on the received data or does the
> Write{Output|Error}Buffer-API just take the receive data as is and place it
> as a single item to the output sink? In this case it would become possible
> to produce binary data as a result of a command (and will motivate the need
> of an additional API on the Java side to become able to distinguish between
> Strings (Reader,Writer, codepage dependent) and Streams (byte oriented, raw
> data)).
>
> ---rony
>
> ___
> 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

Re: [Oorexx-devel] Question ad new ThrowException API...

[Rick McGuire]

On Sat, Aug 13, 2022 at 10:44 AM Rony G. Flatscher 
wrote:

> On 13.08.2022 15:16, Rick McGuire wrote:
>
> On Sat, Aug 13, 2022 at 8:45 AM Rony G. Flatscher 
> wrote:
>
>> E.g. rxapi.pdf "1.17.189. *NEW* ThrowException/0/1/2" states: "Throw a
>> SYNTAX condition. The API call doesn't return and the current method,
>> routine, or exit is exited immediately.".
>>
>> Testing ThrowException1() however will end the running Rexx program
>> immediately not the current call, here the calling sequence:
>>
>>- test.rex requires some testpkg.cls, creating an object o of a class
>>residing in testpkg.cls
>>- test.rex will send an unknown message with two arguemtns to o
>>causing the unknown method to call a routine in the native code
>>- the native code will cause a runtime exception to be thrown if one
>>of the two arguments has the value 1
>>
>> Using RaiseException1() will cause that exception to be raised and the
>> control gets back to the unknown method and then back to test.rex.
>>
>> Using ThrowException1() however will cause ending Rexx altogether as if
>> it causes not only the call to the native routine to be exited immediately,
>> but also the unknown method from which the call started and info.rex where
>> o's unknown method gets invoked from. Is that to be expected?
>>
> Are you using the correct context instance when calling ThrowExeption()?
> That's the behavior I would expect if an instance other than the context
> for the external call was used.
>
> Hmm, good question!
>
> Here is what is done in this test program (trying to get a small,
> self-contained example that would exhibit the reported behaviour, WIP):
>
>- define a RexxRoutine in native code that makes its RexxInstance
>globally available with 'ri', then calls a plain function with the
>following signature "RexxObjectPtr work(RexxCallContext *rcc, RexxObjectPtr
>o, int64_t val)"
>
>- work() will use the RexxInstance to carry out an
>ri->AttachThread() which will be used to send a message to the supplied
>object 'o'; if val has the value 1, then an unknown message gets sent to 
> 'o'
>
> Why are you doing an AttachThread()? This is totally unnecessary and
deactivates the current thread stack. Using the attached thread to raise an
exception will not percolate back to the calling routine because you just
drew a line in the sand. If you need to raise something in the caller, they
you will need to do a DetachThread() and use the original call context to
raise the exception.

Rick




>
>-
>- if rtc->CheckCondition() is true, then a debug message is shown
>   followed by the rcc->RaiseException1() call before returning; using
>   rcc->ThrowException1() instead ends the entire Rexx program as reported,
>   although the RexxCallContext gets used for it
>
>   - however, doing a rtc->DetachThread() before calling
>   rcc->ThrowException1() will yield the documented behaviour!
>
>
>
> This could also explain some of the problems you've been seeing with your
> calls.
>
> No, what happens in the bridge is the following:
>
>- for each Rexx instance a peer Java instance gets created. If there
>is a callback to Rexx the native code fetches the appropriate Rexx instance
>and carries out an AttachThread(), interact with ooRexx (e.g. sending an
>ooRexx object a message) and will do a matching DetachThread() prior to
>returning from the native code,
>
>- the invoked Rexx code (some Rexx method) may be calling back again
>into Java and if on the Java side there is a callback to Rexx needed, the
>same as above occurs recursively,
>
>- eventually returning from (possibly nesting) callbacks.
>
> In the case that a call to Java causes an exception to be thrown on the
> Java side an appropriate RaiseException gets prepared and raised such that
> upon return from Java that condition can be trapped on the Rexx side (and
> access to the Java Throwable becomes possible).
>
> The RaiseException gets prepared and raised in another native function
> that is written to deal with either a RexxCallContext or a RexxExitContext
> (Java implemented command and exit handlers are fully supported) with an
> argument indicating which type of context is currently supplied. In the
> past (and it used to work) RaiseCondition1() was invoked using the
> RexxThreadContext (fetching it e.g. with "((RexxCallContext *)
> argCtxt)->threadContext" to simplify the native code by using the
> threadContext for plain vanilla calls to e.g. ArrayPut, FindClass,
> NewArray, ReleaseLocalReference, SendMessage1, String, StringLength,
> StringData and the like). A few days ago I have changed it to use the
> supplied contexts to invoke RaiseException1(), which did not make a
> difference, unfortunately. (As reported  SetContextVariable() works and
> upon return to Rexx the BSF_ERROR_STRING variable can be used.)
>
> As the condition does not get raised it is also not possible to get at the

Re: [Oorexx-devel] Question ad new ThrowException API...

[Rony G. Flatscher]

On 13.08.2022 15:16, Rick McGuire wrote:

On Sat, Aug 13, 2022 at 8:45 AM Rony G. Flatscher  
wrote:

E.g. rxapi.pdf "1.17.189. *NEW* ThrowException/0/1/2" states: "Throw a 
SYNTAX condition. The
API call doesn't return and the current method, routine, or exit is exited 
immediately.".

Testing ThrowException1() however will end the running Rexx program 
immediately not the
current call, here the calling sequence:

  * test.rex requires some testpkg.cls, creating an object o of a class 
residing in testpkg.cls
  * test.rex will send an unknown message with two arguemtns to o causing 
the unknown method
to call a routine in the native code
  * the native code will cause a runtime exception to be thrown if one of 
the two arguments
has the value 1

Using RaiseException1() will cause that exception to be raised and the 
control gets back to
the unknown method and then back to test.rex.

Using ThrowException1() however will cause ending Rexx altogether as if it 
causes not only the
call to the native routine to be exited immediately, but also the unknown 
method from which
the call started and info.rex where o's unknown method gets invoked from. 
Is that to be expected?

Are you using the correct context instance when calling ThrowExeption()? That's the behavior I 
would expect if an instance other than the context for the external call was used.


Hmm, good question!

Here is what is done in this test program (trying to get a small, self-contained example that would 
exhibit the reported behaviour, WIP):


 * define a RexxRoutine in native code that makes its RexxInstance globally 
available with 'ri',
   then calls a plain function with the following signature "RexxObjectPtr 
work(RexxCallContext
   *rcc, RexxObjectPtr o, int64_t val)"

 * work() will use the RexxInstance to carry out an ri->AttachThread() 
which will be used to
   send a message to the supplied object 'o'; if val has the value 1, then an 
unknown message gets
   sent to 'o'

 o if rtc->CheckCondition() is true, then a debug message is shown followed 
by the
   rcc->RaiseException1() call before returning; using 
rcc->ThrowException1() instead ends the
   entire Rexx program as reported, although the RexxCallContext gets used 
for it

 o however, doing a rtc->DetachThread() before calling 
rcc->ThrowException1() will yield the
   documented behaviour!



This could also explain some of the problems you've been seeing with your calls.


No, what happens in the bridge is the following:

 * for each Rexx instance a peer Java instance gets created. If there is a 
callback to Rexx the
   native code fetches the appropriate Rexx instance and carries out an 
AttachThread(), interact
   with ooRexx (e.g. sending an ooRexx object a message) and will do a matching 
DetachThread()
   prior to returning from the native code,

 * the invoked Rexx code (some Rexx method) may be calling back again into Java 
and if on the Java
   side there is a callback to Rexx needed, the same as above occurs 
recursively,

 * eventually returning from (possibly nesting) callbacks.

In the case that a call to Java causes an exception to be thrown on the Java side an appropriate 
RaiseException gets prepared and raised such that upon return from Java that condition can be 
trapped on the Rexx side (and access to the Java Throwable becomes possible).


The RaiseException gets prepared and raised in another native function that is written to deal with 
either a RexxCallContext or a RexxExitContext (Java implemented command and exit handlers are fully 
supported) with an argument indicating which type of context is currently supplied. In the past (and 
it used to work) RaiseCondition1() was invoked using the RexxThreadContext (fetching it e.g. with 
"((RexxCallContext *) argCtxt)->threadContext" to simplify the native code by using the 
threadContext for plain vanilla calls to e.g. ArrayPut, FindClass, NewArray, ReleaseLocalReference, 
SendMessage1, String, StringLength, StringData and the like). A few days ago I have changed it to 
use the supplied contexts to invoke RaiseException1(), which did not make a difference, 
unfortunately. (As reported  SetContextVariable() works and upon return to Rexx the BSF_ERROR_STRING 
variable can be used.)


As the condition does not get raised it is also not possible to get at the Java throwable object 
(available at the second index position in the additional array) and as such it is not possible to 
find out the root cause of a Java exception.



If so, when would one want to use ThrowException[0|1|2|3] over 
RaiseException[0|1|2|3]?


I would want to use it if I don't want to worry about unwinding my call chain 
to do a normal return.


Ok! But, if there are malloc() calls in the call chain that need to have matching free() calls then 
ThrowException() should probably not be used.


---rony

___

Re: [Oorexx-devel] Question ad new ThrowException API...

[Rick McGuire]

On Sat, Aug 13, 2022 at 8:45 AM Rony G. Flatscher 
wrote:

> E.g. rxapi.pdf "1.17.189. *NEW* ThrowException/0/1/2" states: "Throw a
> SYNTAX condition. The API call doesn't return and the current method,
> routine, or exit is exited immediately.".
>
> Testing ThrowException1() however will end the running Rexx program
> immediately not the current call, here the calling sequence:
>
>- test.rex requires some testpkg.cls, creating an object o of a class
>residing in testpkg.cls
>- test.rex will send an unknown message with two arguemtns to o
>causing the unknown method to call a routine in the native code
>- the native code will cause a runtime exception to be thrown if one
>of the two arguments has the value 1
>
> Using RaiseException1() will cause that exception to be raised and the
> control gets back to the unknown method and then back to test.rex.
>
> Using ThrowException1() however will cause ending Rexx altogether as if it
> causes not only the call to the native routine to be exited immediately,
> but also the unknown method from which the call started and info.rex where
> o's unknown method gets invoked from. Is that to be expected?
>
Are you using the correct context instance when calling ThrowExeption()?
That's the behavior I would expect if an instance other than the context
for the external call was used. This could also explain some of the
problems you've been seeing with your calls.



> If so, when would one want to use ThrowException[0|1|2|3] over
> RaiseException[0|1|2|3]?
>

I would want to use it if I don't want to worry about unwinding my call
chain to do a normal return.

Rick


> ---rony
>
> ___
> 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

Re: [Oorexx-devel] Question ad parsing

[Rony G. Flatscher]

On 6/8/2022 4:58 PM, Rick McGuire wrote:
The triggers get applied first, then things get broken in words using the variable list. The +2 
trigger matches to the second position, "c ", which is then broken into words and assigned to the 
variables.


I see, thank you!

---rony



On Wed, Jun 8, 2022 at 10:51 AM Rony G. Flatscher  
wrote:

Consider the following:

parse value "c fgh" with v1 v2
   ... rexxtry.rex on WindowsNT
say "v1=["v1"] v2=["v2"]"
v1=[c] v2=[fgh]
   ... rexxtry.rex on WindowsNT

parse value "c fgh" with v1 v2 +2
   ... rexxtry.rex on WindowsNT
say "v1=["v1"] v2=["v2"]"
v1=[c] v2=[]
   ... rexxtry.rex on WindowsNT

Why would v2 in the second parse refer to an empty string (would have expected the 
string "fg")?

---rony

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

Re: [Oorexx-devel] Question ad parsing

[Rick McGuire]

The triggers get applied first, then things get broken in words using the
variable list. The +2 trigger matches to the second position, "c ", which
is then broken into words and assigned to the variables.

Rick

On Wed, Jun 8, 2022 at 10:51 AM Rony G. Flatscher 
wrote:

> Consider the following:
>
> parse value "c fgh" with v1 v2
>   ... rexxtry.rex on WindowsNT
> say "v1=["v1"] v2=["v2"]"
> v1=[c] v2=[fgh]
>   ... rexxtry.rex on WindowsNT
>
> parse value "c fgh" with v1 v2 +2
>   ... rexxtry.rex on WindowsNT
> say "v1=["v1"] v2=["v2"]"
> v1=[c] v2=[]
>   ... rexxtry.rex on WindowsNT
>
> Why would v2 in the second parse refer to an empty string (would have
> expected the string "fg")?
>
> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad new .Message methods reply/replyWith

[Rick McGuire]

Those are not equivalent. The target message object is updated with the
supplied arguments and the copy is made after the update. The
original message object has a copy of the arguments used for the
invocation.

Rick

On Thu, May 19, 2022 at 4:21 AM Rony G. Flatscher 
wrote:

> While going through the send/With and start/With methods I "stumbled" over
> reply/With which I was not aware of that they got added.
>
> If understanding correctly, then reply/With is the same as start/With just
> creating a copy of the target message object to dispatch. If so, the same
> effect can be simply achieved in plain ooRexx code like:
>
> dispatchedMsg=msg~copy~start/With(...)
>
> If that is the case why would it be important to have new reply/With
> methods added for the .message class?
>
> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad "samples\ole\adsi\adsi{1|3|4}.rex"

[Rony G. Flatscher]

On 02.05.2022 21:06, Rick McGuire wrote:



On Mon, May 2, 2022 at 1:19 PM Rony G. Flatscher  
wrote:

Currently "samples\ole\adsi\adsi4.rex" looks like:

/***/
/* ADSI Sample 4:  */
/* */
/* Using filters with ADSI collections.*/
/* */
/***/

ComputerName = value("COMPUTERNAME",,"ENVIRONMENT")

computerObject = .OLEObject~GetObject("WinNT://"||ComputerName)

computerObject~Filter = .array~of("Group","Service")

/* show only objects of type Group and Service: */
do item over computerObject
   say item*~class*  ":" item~name
end

return 0

Running it via 32-bit Rexx (r12376) yields on my machine:

C:\Program Files (x86)\ooRexx\samples\ole\adsi>bkp\adsi4.rex
Group : Administratoren
... cut ...
Group : System Managed Accounts Group
... cut ...
Service : AdobeARMservice
Service : AESMService
Service : AGMService
Service : AGSService
Service : AJRouter
Service : ALG
Service : AppHostSvc
Service : AppIDSvc
Service : Appinfo
Service : Apple Mobile Device Service
Service : AppMgmt
Service : AppReadiness
Service : AppVClient
Service : AppXSvc
Service : aspnet_state
Service : AssignedAccessManagerSvc
Service : AudioEndpointBuilder
Service : Audiosrv
Service : autotimesvc
Service : AxInstSV
Service : BDESVC
Service : BFE
... cut ...

However, this seems like an error as "item~class" should yield "The OLEObject 
class" instead
of the strings "Group" or "Service".

Mark Miesfield added overrides to a number of methods on the OLEObject (copy, class, send, etc.) 
class back in 2009 to check if the underlying OLE Object has a matching method name and do the 
dispatch as if the method had been overridden.


Thank you, I did not know that!




OLE programs should employ either "item~unknown('class',.array~new)"  or
"item~dispatch('class')" to get the message "CLASS" to be transported to 
the Windows side.

How can one get at the ooRexx class object in this case ?

The answer for an OLEObject is always going to be The OLEObject class.


Unfortunately this is not always the case anymore!

---

The "class" message gets overridden, if the Windows object possesses a Method named "class", so it 
does not answer "The OLEObject class" in such cases. E.g. "item" in adsi4.rex is "an OLEObject", 
sending it the message "class" answers with "Group" or "Service", not "The OLEObject class".


(The same is probably also true, if the Windows object implements the methods "copy", "send" or 
"start" which would inhibit the usage of the .Object methods "copy", "send" or "start".)


Here a rewritten version of adsi4.rex to inspect the abilities of the first 
"item" in various ways:

   ComputerName = value("COMPUTERNAME",,"ENVIRONMENT")
   computerObject = .OLEObject~GetObject("WinNT://"||ComputerName)
   computerObject~Filter = .array~of("Group","Service")
   tab="09"x

   do item over computerObject
  say tab "---> item~class  :" pp(item~class) "(-> expected: 
'The OLEObject class')"
  say tab "---> item:" pp(item)
  say tab "---> item~isA(.oleObject):" pp(item~isA(.oleObject))
  say
  say tab "---> item~dispatch('class')  :" 
pp(item~dispatch("class"))
  say tab "---> item~unknown('class',.array~new):" pp(item~unknown('class',.array~new)) "(-> 
""item~unknown('class',.nil)"" does not work anymore)"
  say
  say tab "---> item~class:.object  :" pp(item~class:.object) -- 
<-- error 98.938
  leave
   end

   ::routine pp
  return "["arg(1)"]"

The output shows that "item" is "an OLEObject":

   C:\Program Files (x86)\ooRexx\samples\ole\adsi>adsi4.rex
 ---> item~class  : [Group] (-> expected: 'The 
OLEObject class')
 ---> item: [an OLEObject]
 ---> item~isA(.oleObject): [1]

 ---> item~dispatch('class')  : [Group]
 ---> item~unknown('class',.array~new): [Group] (-> 
"item~unknown('class',.nil)" does not work anymore)

14 *-*   say tab "---> item~class:.object  :" 
pp(item~class:.object) -- <-- error 98.938
   Error 98 running C:\Program Files (x86)\ooRexx\samples\ole\adsi\adsi4.rex 
line 14:  Execution error.
   Error 98.938:  Message search overrides can be used only from methods of the 
target 

Re: [Oorexx-devel] Question ad "samples\ole\adsi\adsi{1|3|4}.rex"

[Rick McGuire]

On Mon, May 2, 2022 at 1:19 PM Rony G. Flatscher 
wrote:

> Currently "samples\ole\adsi\adsi4.rex" looks like:
>
> /***/
> /* ADSI Sample 4:  */
> /* */
> /* Using filters with ADSI collections.*/
> /* */
> /***/
>
> ComputerName = value("COMPUTERNAME",,"ENVIRONMENT")
>
> computerObject = .OLEObject~GetObject("WinNT://"||ComputerName)
>
> computerObject~Filter = .array~of("Group","Service")
>
> /* show only objects of type Group and Service: */
> do item over computerObject
>   say item*~class* ":" item~name
> end
>
> return 0
>
> Running it via 32-bit Rexx (r12376) yields on my machine:
>
> C:\Program Files (x86)\ooRexx\samples\ole\adsi>bkp\adsi4.rex
> Group : Administratoren
> ... cut ...
> Group : System Managed Accounts Group
> ... cut ...
> Service : AdobeARMservice
> Service : AESMService
> Service : AGMService
> Service : AGSService
> Service : AJRouter
> Service : ALG
> Service : AppHostSvc
> Service : AppIDSvc
> Service : Appinfo
> Service : Apple Mobile Device Service
> Service : AppMgmt
> Service : AppReadiness
> Service : AppVClient
> Service : AppXSvc
> Service : aspnet_state
> Service : AssignedAccessManagerSvc
> Service : AudioEndpointBuilder
> Service : Audiosrv
> Service : autotimesvc
> Service : AxInstSV
> Service : BDESVC
> Service : BFE
> ... cut ...
>
> However, this seems like an error as "item~class" should yield "The
> OLEObject class" instead of the strings "Group" or "Service".
>
Mark Miesfield added overrides to a number of methods on the OLEObject
(copy, class, send, etc.) class back in 2009 to check if the underlying OLE
Object has a matching method name and do the dispatch as if the method had
been overridden.



>
> OLE programs should employ either "item~unknown('class',.array~new)"  or
> "item~dispatch('class')" to get the message "CLASS" to be transported to
> the Windows side.
> How can one get at the ooRexx class object in this case ?
>

The answer for an OLEObject is always going to be The OLEObject class.

Rick


> ---rony
>
> P.S.: Also "adsi3.rex" now causes the following error:
>
> C:\Program Files (x86)\ooRexx\samples\ole\adsi>adsi3
> 49 *-*   do member over container~members
> Error 97 running C:\Program Files (x86)\ooRexx\samples\ole\adsi\adsi3.rex 
> line 49:  Object method not found.
> Error 97.1:  Object "The NIL object" does not understand message "MEMBERS".
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad triggering garbage collector

[Rony G. Flatscher]

On 24.04.2022 19:57, Rick McGuire wrote:
A garbage collection is triggered any time an allocation request fails. At that time, all of the 
unreferenced objects are swept up and repooled and the allocation request is retried. The uninits 
on objects that have been identified as unreferenced will get run at the next "safe" boundary, 
which is usually method termination.


Thank you.

Is there any gross estimate of the number of Rexx objects that need to be created until an 
allocation request fails such that the garbage collector gets triggered?


Analyzing a few use cases (including Java web servers with ooRexx JSPs) where ooRexx gets used to 
create the text to be sent back to Java which involves translating Rexx strings to Java strings if 
using a Writer, otherwise to a Java byte array byte[] if using a Stream and passing that on.


In the case of a Java byte array a BSF ooRexx object gets created which proxies the Java byte array. 
This ooRexx Java proxy will release the proxied Java byte array upon it being garbage collected by 
ooRexx thru its uninit method. This makes that Java byte array eligible for garbage collection by 
Java which usually does so within a fraction of a second.


---

To illustrate the Java garbage collector behaviour here the output of a Java test run (without Rexx 
references), which allows for analyzing the effects of gc(), runFinalization() (gets removed from 
newer Java version) and then sleeping for half a second after which all unreferenced Java objects 
got removed (the code uses java.lang.ref.PhantomReference as the finalize() method got deprecated 
and is slated to be removed from Java):


   F:\work\svn\bsf4oorexx\trunk\bsf4oorexx.dev\source_java>java 
org.rexxla.bsf.engines.rexx.RexxCleanupRef
   RexxCleanupRef.main(): creating [123456] TestObjects and storing them in an 
ArrayList ...

   RexxCleanupRef [2022-04-24 20:32:34.31800] [main(): before nullifying]
  RefKind: Instances: Finalized: Not Yet Finalized:
   ---
   [TEST]...: [ 123.456] [   0] [ 123.456]
   [REXX_ENGINE]: [   0] [   0] [   0]
   [REXX_PROXY].: [   0] [   0] [   0]
   ---
   Totals...: [ 123.456] [   0] [ 123.456]

   ... nullifying the ArrayList ...

   RexxCleanupRef [2022-04-24 20:32:34.39200] [after gc()]
  RefKind: Instances: Finalized: Not Yet Finalized:
   ---
   [TEST]...: [ 123.456] [ 145] [ 123.311]
   [REXX_ENGINE]: [   0] [   0] [   0]
   [REXX_PROXY].: [   0] [   0] [   0]
   ---
   Totals...: [ 123.456] [ 145] [ 123.311]

   RexxCleanupRef [2022-04-24 20:32:34.41200] [after runFinalization()]
  RefKind: Instances: Finalized: Not Yet Finalized:
   ---
   [TEST]...: [ 123.456] [  16.544] [ 106.912]
   [REXX_ENGINE]: [   0] [   0] [   0]
   [REXX_PROXY].: [   0] [   0] [   0]
   ---
   Totals...: [ 123.456] [  16.544] [ 106.912]

   RexxCleanupRef [2022-04-24 20:32:34.46500] [after gc()]
  RefKind: Instances: Finalized: Not Yet Finalized:
   ---
   [TEST]...: [ 123.456] [  30.601] [  92.855]
   [REXX_ENGINE]: [   0] [   0] [   0]
   [REXX_PROXY].: [   0] [   0] [   0]
   ---
   Totals...: [ 123.456] [  30.601] [  92.855]

   main(): sleeping 500 ms
   RexxCleanupRef [2022-04-24 20:32:34.98200] [after sleeping 500 ms]
  RefKind: Instances: Finalized: Not Yet Finalized:
   ---
   [TEST]...: [ 123.456] [ 123.456] [   0]
   [REXX_ENGINE]: [   0] [   0] [   0]
   [REXX_PROXY].: [   0] [   0] [   0]
   ---
   Totals...: [ 123.456] [ 123.456] [   0]

[This class is responsible for releasing references to Rexx objects if the Java RexxProxy 

Re: [Oorexx-devel] Question ad triggering garbage collector

[Rick McGuire]

A garbage collection is triggered any time an allocation request fails. At
that time, all of the unreferenced objects are swept up and repooled and
the allocation request is retried. The uninits on objects that have been
identified as unreferenced will get run at the next "safe" boundary, which
is usually method termination.

Rick

On Sun, Apr 24, 2022 at 1:51 PM Rony G. Flatscher 
wrote:

> Trying to analyze runtime behaviours using a rexxtry.rex session in which
> BSF objects get created,
> some of which do not get assigned to Rexx variables (and hence turning to
> garbage after the
> respective statement got executed).
>
> Creating over and over BSF-ooRexx objects that do not get referenced and
> as such are immediately
> eligible to be destroyed by the garbage collector this seems to not be
> taken place while the
> rexxtry.rex program in which they got created executes. Ending the
> rexxtry.rex session after a while
> will cause the garbage collector to run (having debug statements in the
> uninit method) at that point
> in time.
>
> So when does the garbage collector get triggered? Or asked differently:
> what is needed to get the
> garbage collector to run the uninit methods of orphaned Rexx objects?
>
> ---rony
>
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad new native API w.r.t. command environments

[Rony G. Flatscher]

On 22.03.2022 13:22, Rony G. Flatscher wrote:
> The new native API "context->AddCommandEnvironment(name, handler, type);" 
> allows one to add a new
> command environment in 5.0 at runtime according to rexxapi.pdf.
>
> Is it possible to do the opposite, i.e. remove such a command environment as 
> well?

So, no answer means "no"?

Here is the background for this question: there may be use cases (in 7/24 
scenarios) that benefit if
rather than terminating Rexx interpreter instances (RII) one would become able 
to pool them (in
situations where there is just a low number of RIIs in use in parallel, but 
many RIIs are needed
during the uptime). For that to work it would be necessary to get a RII back to 
its pristine state
in which nothing got configured for it, assuming that defined command 
environments are managed per
RII. OTOH if command environments are global to all Rexx interpreter instances 
this would not apply
and one would probably have to make sure that the default environment (assuming 
that is maintained
per RII) is reset to "CMD" on Windows and "sh" on Unix (or would it be better 
to set to "SYSTEM" for
all operating systems?).

Also, only RIIs would get pooled that got created without any preconfigured 
handlers, i.e.
RexxCreateInterpreter's third argument options is NULL.

This also involves resetting .local, which would probably possible by creating 
a copy immediately
after creation, and when trying to reset them to its pristine state set a copy 
of that copy (.local
is relevant for .input/.stdin, .output/.stdout, .error/.stderr).

If possible, it would be even better if a Reset() was available to the Instance 
context to allow
context->Reset() such that ooRexx resets the RII.

Any thoughts, comments?

---rony



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

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Rony G. Flatscher]

Erich,

On 24.01.2022 15:03, Erich Steinböck wrote:
> METAVERSION was already changed to 42 for 5.0

METAVERSION gets changed each time the compiled image changes structurally as 
the comment "// gets
updated when internal form changes" clearly states, it is not dependent on a 
change in the official
ooRexx version number. Just look at the changes to METAVERSION since February 
20th, 2008:

svn log --diff interpreter/classes/support/ProgramMetaData.hpp

> no double patch please

This is not a "double patch".

---

You may be unaware of the fact that there are application developers out in the 
market who have been
taking advantage of ooRexx 5.0 features and distribute their programs in 
compiled form to protect
their source code. One very important reason being that ooRexx 5.0 fixes errors 
that are present in
ooRexx 4.2. Also, ooRexx 5.0 is faster than ooRexx 4.2. And for some the new 
features of ooRexx 5.0
are so compelling that they take advantage of them for the benefit of their 
applications.

[This observation - ooRexx 5.0 being used for application development in the 
field - and the
increase in overall quality of ooRexx 5.0 compared to 4.2 has been the 
motivation to suggest to
create a release of 5.0 ASAP to open the doors for ooRexx 5.0 into companies 
that do not allow
software dubbed as "beta".]

If compiled images are attempted to be run that are not valid then the ooRexx 
interpreter must not
run them and issue an error to make the application developer and user aware of 
this fact. This is
only possible by increasing the METAVERSION/image version indicator to inhibit 
executing ooRexx
programs that got compiled with ooRexx 5.0 between April 30th 2019 and November 
27th 2021 (the image
format changed with r12326 on November 28th 2021 and thus became incompatible 
with earlier versions).

---rony



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

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[P. O. Jonsson]

And 42 is a very nice number ;-)

Von meinem iPhone gesendet

> Am 24.01.2022 um 16:55 schrieb Erich Steinböck :
> 
> 
> Hi Jon,
> correct. No further change should be done as METAVERSION has already been 
> increased for 5.0.
> 
> ___
> 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

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Erich Steinböck]

Hi Jon,
correct. No further change should be done as METAVERSION has already been
increased for 5.0.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Sahananda Sahananda]

Hi Erich,

Can you just be clear for my understanding please.
Are you saying that Rony should not change the METAVERSION from 42 to 43,
and should leave it at 42?

thanks,

Jon

On Mon, 24 Jan 2022 at 14:04, Erich Steinböck 
wrote:

> Rony,
> METAVERSION was already changed to 42 for 5.0
> no double patch please
> ___
> 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

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Erich Steinböck]

Rony,
METAVERSION was already changed to 42 for 5.0
no double patch please
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Rony G. Flatscher]

Dear P.O.,

On 24.01.2022 13:17, P.O. Jonsson wrote:
> I have no comments on the change itself, but could you please wait a day or 
> two with this change?
> We are experiencing problems with the Jenkins build system at the moment. I 
> will let you know when
> it has been fixed.

Sure, good luck with Jenkins!

---rony


>
>
>> Am 24.01.2022 um 12:48 schrieb Rony G. Flatscher > >:
>>
>> This is the planned patch to bump the image version:
>>
>> F:\work\svn\oorexx\main\trunk\interpreter\classes\support>svn diff
>> Index: ProgramMetaData.hpp
>> ===
>> --- ProgramMetaData.hpp (revision 12347)
>> +++ ProgramMetaData.hpp (working copy)
>> @@ -1,7 +1,7 @@
>>  
>> /**/
>>  /*  
>>   */
>>  /* Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.   
>>   */
>> -/* Copyright (c) 2005-2019 Rexx Language Association. All rights 
>> reserved.*/
>> +/* Copyright (c) 2005-2022 Rexx Language Association. All rights 
>> reserved.*/
>>  /*  
>>   */
>>  /* This program and the accompanying materials are made available under 
>>   */
>>  /* the terms of the Common Public License v1.0 which accompanies this   
>>   */
>> @@ -71,7 +71,7 @@
>>  enum
>>  {
>>  MAGICNUMBER = 1,   // remains constant from 
>> release-to-release
>> -METAVERSION = 42   // gets updated when internal 
>> form changes
>> +METAVERSION = 43   // gets updated when internal 
>> form changes
>>  };
>>
>> ---rony
>>
>>
>> On 20.01.2022 20:13, Rony G Flatscher wrote:
>>>
 Am 20.01.2022 um 19:25 schrieb Rick McGuire :

 
 Yes they do. 
>>> Thank you!
>>>
>>> Shouldn‘t we bump the imageversion (?) field then such that running 
>>> previous image versions
>>> yield a runtime error?
>>>
>>> —-rony
>>>
>>> Rony G. Flatscher (mobil/e)

 On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher >>> > wrote:

 At the end of November there were the following changes to
 interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev 
 12327, "svn diff -r
 PREV ProgramMetaData.*") :

 Index: ProgramMetaData.cpp

 ===

 --- ProgramMetaData.cpp(revision 12327)

 +++ ProgramMetaData.cpp(working copy)

 @@ -304,10 +304,6 @@

  data++;
  }
  
 -// pass back the pointer to the metadata location, assuming 
 for now that
 -// here is metadata.
 -metaData = (ProgramMetaData *)data;
 -
  // adjust the length for everything after the shebang
  length -= data - buffer->getData();
  
 @@ -314,6 +310,21 @@

  // Now check in binary form of the compiled version
  if (length > strlen(compiledHeader) && strcmp(data, 
 compiledHeader) == 0)
  {
 +// the problem with having a shebang in front of the data 
 is that it opens the
 +// possibility that the flattened program data is not 
 aligned on an object grain
 +// boundary. This can either cause invalid objects to 
 created on the heap or even
 +// result in data exceptions if the fields are not 
 aligned on a proper word boundary.
 +// If this is anywhere other than the front of the 
 buffer, we need to shift it to
 +// the front.
 +
 +// the returned metadata will be at the beginning
 +metaData = (ProgramMetaData *)buffer->getData();
 +
 +// once we've shifted it
 +if (data != buffer->getData())
 +{
 +   memmove((void *)buffer->getData(), (void *)data, 
 length);
 +}
  return true;
  }
  
 @@ -327,8 +338,13 @@

  
  size_t decodedLength;
  
 +// Note that we are decoding to the beginning of the 
 buffer, which overwrites any
 +// shebang and the binary header while also ensuring the 
 data is aligned on a proper
 +// object grain boundary,
 +metaData = (ProgramMetaData 

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[P.O. Jonsson]

Dera Rony,

I have no comments on the change itself, but could you please wait a day or two 
with this change? We are experiencing problems with the Jenkins build system at 
the moment. I will let you know when it has been fixed.

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



> Am 24.01.2022 um 12:48 schrieb Rony G. Flatscher :
> 
> This is the planned patch to bump the image version:
> 
> F:\work\svn\oorexx\main\trunk\interpreter\classes\support>svn diff
> Index: ProgramMetaData.hpp
> ===
> --- ProgramMetaData.hpp (revision 12347)
> +++ ProgramMetaData.hpp (working copy)
> @@ -1,7 +1,7 @@
>  
> /**/
>  /*   
>  */
>  /* Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
>  */
> -/* Copyright (c) 2005-2019 Rexx Language Association. All rights reserved.   
>  */
> +/* Copyright (c) 2005-2022 Rexx Language Association. All rights reserved.   
>  */
>  /*   
>  */
>  /* This program and the accompanying materials are made available under  
>  */
>  /* the terms of the Common Public License v1.0 which accompanies this
>  */
> @@ -71,7 +71,7 @@
>  enum
>  {
>  MAGICNUMBER = 1,   // remains constant from 
> release-to-release
> -METAVERSION = 42   // gets updated when internal form 
> changes
> +METAVERSION = 43   // gets updated when internal form 
> changes
>  };
> 
> ---rony
> 
> 
> 
> On 20.01.2022 20:13, Rony G Flatscher wrote:
>> 
>>> Am 20.01.2022 um 19:25 schrieb Rick McGuire  
>>> :
>>> 
>>> 
>>> Yes they do. 
>> Thank you!
>> 
>> Shouldn‘t we bump the imageversion (?) field then such that running previous 
>> image versions yield a runtime error?
>> 
>> —-rony
>> 
>> Rony G. Flatscher (mobil/e)
>>> 
>>> On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher >> > wrote:
>>> At the end of November there were the following changes to 
>>> interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev 
>>> 12327, "svn diff -r PREV ProgramMetaData.*") :
>>> 
>>> Index: ProgramMetaData.cpp
>>> 
>>> ===
>>> 
>>> --- ProgramMetaData.cpp (revision 12327)
>>> 
>>> +++ ProgramMetaData.cpp (working copy)
>>> 
>>> @@ -304,10 +304,6 @@
>>> 
>>>  data++;
>>>  }
>>>  
>>> -// pass back the pointer to the metadata location, assuming for now 
>>> that
>>> -// here is metadata.
>>> -metaData = (ProgramMetaData *)data;
>>> -
>>>  // adjust the length for everything after the shebang
>>>  length -= data - buffer->getData();
>>>  
>>> @@ -314,6 +310,21 @@
>>> 
>>>  // Now check in binary form of the compiled version
>>>  if (length > strlen(compiledHeader) && strcmp(data, compiledHeader) == 
>>> 0)
>>>  {
>>> +// the problem with having a shebang in front of the data is that 
>>> it opens the
>>> +// possibility that the flattened program data is not aligned on 
>>> an object grain
>>> +// boundary. This can either cause invalid objects to created on 
>>> the heap or even
>>> +// result in data exceptions if the fields are not aligned on a 
>>> proper word boundary.
>>> +// If this is anywhere other than the front of the buffer, we need 
>>> to shift it to
>>> +// the front.
>>> +
>>> +// the returned metadata will be at the beginning
>>> +metaData = (ProgramMetaData *)buffer->getData();
>>> +
>>> +// once we've shifted it
>>> +if (data != buffer->getData())
>>> +{
>>> +   memmove((void *)buffer->getData(), (void *)data, length);
>>> +}
>>>  return true;
>>>  }
>>>  
>>> @@ -327,8 +338,13 @@
>>> 
>>>  
>>>  size_t decodedLength;
>>>  
>>> +// Note that we are decoding to the beginning of the buffer, which 
>>> overwrites any
>>> +// shebang and the binary header while also ensuring the data is 
>>> aligned on a proper
>>> +// object grain boundary,
>>> +metaData = (ProgramMetaData *)buffer->getData();
>>> +
>>>  // we now have the encoded data, decode it in place, overwriting 
>>> the compiled header
>>> -if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, 
>>> data, decodedLength))
>>> +if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, 
>>> buffer->getData(), decodedLength))
>>>  {
>>>  reportException(Error_Program_unreadable_invalid_encoding, 
>>> fileName);
>>>  }
>>> Index: ProgramMetaData.hpp
>>> 
>>> ===
>>> 
>>> --- ProgramMetaData.hpp 

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Rony G. Flatscher]

This is the planned patch to bump the image version:

F:\work\svn\oorexx\main\trunk\interpreter\classes\support>svn diff
Index: ProgramMetaData.hpp
===
--- ProgramMetaData.hpp (revision 12347)
+++ ProgramMetaData.hpp (working copy)
@@ -1,7 +1,7 @@
 
/**/
 /* 
   */
 /* Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.  
   */
-/* Copyright (c) 2005-2019 Rexx Language Association. All rights reserved. 
   */
+/* Copyright (c) 2005-2022 Rexx Language Association. All rights reserved. 
   */
 /* 
   */
 /* This program and the accompanying materials are made available under
   */
 /* the terms of the Common Public License v1.0 which accompanies this  
   */
@@ -71,7 +71,7 @@
 enum
 {
 MAGICNUMBER = 1,   // remains constant from 
release-to-release
-METAVERSION = 42   // gets updated when internal form 
changes
+METAVERSION = 43   // gets updated when internal form 
changes
 };

---rony


On 20.01.2022 20:13, Rony G Flatscher wrote:
>
>> Am 20.01.2022 um 19:25 schrieb Rick McGuire :
>>
>> 
>> Yes they do. 
> Thank you!
>
> Shouldn‘t we bump the imageversion (?) field then such that running previous 
> image versions yield
> a runtime error?
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>>
>> On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher > > wrote:
>>
>> At the end of November there were the following changes to
>> interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev 
>> 12327, "svn diff -r
>> PREV ProgramMetaData.*") :
>>
>> Index: ProgramMetaData.cpp
>>
>> ===
>>
>> --- ProgramMetaData.cpp  (revision 12327)
>>
>> +++ ProgramMetaData.cpp  (working copy)
>>
>> @@ -304,10 +304,6 @@
>>
>>  data++;
>>  }
>>  
>> -// pass back the pointer to the metadata location, assuming for 
>> now that
>> -// here is metadata.
>> -metaData = (ProgramMetaData *)data;
>> -
>>  // adjust the length for everything after the shebang
>>  length -= data - buffer->getData();
>>  
>> @@ -314,6 +310,21 @@
>>
>>  // Now check in binary form of the compiled version
>>  if (length > strlen(compiledHeader) && strcmp(data, 
>> compiledHeader) == 0)
>>  {
>> +// the problem with having a shebang in front of the data 
>> is that it opens the
>> +// possibility that the flattened program data is not 
>> aligned on an object grain
>> +// boundary. This can either cause invalid objects to 
>> created on the heap or even
>> +// result in data exceptions if the fields are not aligned 
>> on a proper word boundary.
>> +// If this is anywhere other than the front of the buffer, 
>> we need to shift it to
>> +// the front.
>> +
>> +// the returned metadata will be at the beginning
>> +metaData = (ProgramMetaData *)buffer->getData();
>> +
>> +// once we've shifted it
>> +if (data != buffer->getData())
>> +{
>> +   memmove((void *)buffer->getData(), (void *)data, length);
>> +}
>>  return true;
>>  }
>>  
>> @@ -327,8 +338,13 @@
>>
>>  
>>  size_t decodedLength;
>>  
>> +// Note that we are decoding to the beginning of the 
>> buffer, which overwrites any
>> +// shebang and the binary header while also ensuring the 
>> data is aligned on a proper
>> +// object grain boundary,
>> +metaData = (ProgramMetaData *)buffer->getData();
>> +
>>  // we now have the encoded data, decode it in place, 
>> overwriting the compiled header
>> -if (!StringUtil::decodeBase64(beginEncodedData, 
>> encodedLength, data, decodedLength))
>> +if (!StringUtil::decodeBase64(beginEncodedData, 
>> encodedLength, buffer->getData(), decodedLength))
>>  {
>>  
>> reportException(Error_Program_unreadable_invalid_encoding, fileName);
>>  }
>> Index: ProgramMetaData.hpp
>>
>> ===
>>
>> --- ProgramMetaData.hpp  (revision 12325)
>>
>> +++ 

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Rony G Flatscher]

> Am 20.01.2022 um 19:25 schrieb Rick McGuire :
> 
> 
> Yes they do. 
Thank you!

Shouldn‘t we bump the imageversion (?) field then such that running previous 
image versions yield a runtime error?

—-rony

Rony G. Flatscher (mobil/e)
> 
>> On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher  
>> wrote:
>> At the end of November there were the following changes to 
>> interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev 
>> 12327, "svn diff -r PREV ProgramMetaData.*") :
>> 
>> Index: ProgramMetaData.cpp
>> 
>> ===
>> 
>> --- ProgramMetaData.cpp  (revision 12327)
>> 
>> +++ ProgramMetaData.cpp  (working copy)
>> 
>> @@ -304,10 +304,6 @@
>> 
>>  data++;
>>  }
>>  
>> -// pass back the pointer to the metadata location, assuming for now that
>> -// here is metadata.
>> -metaData = (ProgramMetaData *)data;
>> -
>>  // adjust the length for everything after the shebang
>>  length -= data - buffer->getData();
>>  
>> @@ -314,6 +310,21 @@
>> 
>>  // Now check in binary form of the compiled version
>>  if (length > strlen(compiledHeader) && strcmp(data, compiledHeader) == 
>> 0)
>>  {
>> +// the problem with having a shebang in front of the data is that 
>> it opens the
>> +// possibility that the flattened program data is not aligned on an 
>> object grain
>> +// boundary. This can either cause invalid objects to created on 
>> the heap or even
>> +// result in data exceptions if the fields are not aligned on a 
>> proper word boundary.
>> +// If this is anywhere other than the front of the buffer, we need 
>> to shift it to
>> +// the front.
>> +
>> +// the returned metadata will be at the beginning
>> +metaData = (ProgramMetaData *)buffer->getData();
>> +
>> +// once we've shifted it
>> +if (data != buffer->getData())
>> +{
>> +   memmove((void *)buffer->getData(), (void *)data, length);
>> +}
>>  return true;
>>  }
>>  
>> @@ -327,8 +338,13 @@
>> 
>>  
>>  size_t decodedLength;
>>  
>> +// Note that we are decoding to the beginning of the buffer, which 
>> overwrites any
>> +// shebang and the binary header while also ensuring the data is 
>> aligned on a proper
>> +// object grain boundary,
>> +metaData = (ProgramMetaData *)buffer->getData();
>> +
>>  // we now have the encoded data, decode it in place, overwriting 
>> the compiled header
>> -if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, 
>> data, decodedLength))
>> +if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, 
>> buffer->getData(), decodedLength))
>>  {
>>  reportException(Error_Program_unreadable_invalid_encoding, 
>> fileName);
>>  }
>> Index: ProgramMetaData.hpp
>> 
>> ===
>> 
>> --- ProgramMetaData.hpp  (revision 12325)
>> 
>> +++ ProgramMetaData.hpp  (working copy)
>> 
>> @@ -80,8 +80,16 @@
>> 
>>  uint16_t   imageVersion;   // version identifier for validity
>>  uint16_t   wordSize;   // size of a word
>>  uint16_t   bigEndian;  // true if this is a big-endian 
>> platform
>> -LanguageLevel  requiredLevel;  // required language level for 
>> execution
>> +uint32_t   requiredLevel;  // required language level for 
>> execution (NB: this needs to be an explicitly sized item)
>>  uint32_t   reserved;   // padding to bring imageSize to a 
>> 64-bit boundary
>> +
>> +size_t pad;// We need to add an extra pad here 
>> to force imageData field to be on an object grain
>> +   // boundary so front of the buffer 
>> can be chopped off without creating an invalid object.
>> +   // The offset of imageData needs to 
>> be in integral number of grain increments from the beginning.
>> +   // so for 32 bits we are 16 + 4*2 + 
>> 2*4 + 4 + 4 = 40 bytes for the offset, and
>> +   // for 64-bit we are 16 + 4*2 + 2*4 
>> + 8 + 8 bytes for the offset. This will allow things
>> +   // go aligned on a grain boundary on 
>> all architectures//
>> +
>>  size_t imageSize;  // size of the image
>>  char   imageData[4];   // the copied image data
>>  };
>> 
>> Do these changes invalidate compiled ooRexx programs (with the "-e" switch) 
>> that got compiled before these two changes took effect by any chance? 
>> 
>> ---rony
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Rick McGuire]

Yes they do.

On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher 
wrote:

> At the end of November there were the following changes to
> interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev
> 12327, "svn diff -r PREV ProgramMetaData.*") :
>
> Index: ProgramMetaData.cpp
>
> ===
>
> --- ProgramMetaData.cpp   (revision 12327)
>
> +++ ProgramMetaData.cpp   (working copy)
>
> @@ -304,10 +304,6 @@
>
>  data++;
>  }
>
> -// pass back the pointer to the metadata location, assuming for now that
> -// here is metadata.
> -metaData = (ProgramMetaData *)data;
> -
>  // adjust the length for everything after the shebang
>  length -= data - buffer->getData();
>
> @@ -314,6 +310,21 @@
>
>  // Now check in binary form of the compiled version
>  if (length > strlen(compiledHeader) && strcmp(data, compiledHeader) == 0)
>  {
> +// the problem with having a shebang in front of the data is that it 
> opens the
> +// possibility that the flattened program data is not aligned on an 
> object grain
> +// boundary. This can either cause invalid objects to created on the 
> heap or even
> +// result in data exceptions if the fields are not aligned on a 
> proper word boundary.
> +// If this is anywhere other than the front of the buffer, we need 
> to shift it to
> +// the front.
> +
> +// the returned metadata will be at the beginning
> +metaData = (ProgramMetaData *)buffer->getData();
> +
> +// once we've shifted it
> +if (data != buffer->getData())
> +{
> +   memmove((void *)buffer->getData(), (void *)data, length);
> +}
>  return true;
>  }
>
> @@ -327,8 +338,13 @@
>
>
>  size_t decodedLength;
>
> +// Note that we are decoding to the beginning of the buffer, which 
> overwrites any
> +// shebang and the binary header while also ensuring the data is 
> aligned on a proper
> +// object grain boundary,
> +metaData = (ProgramMetaData *)buffer->getData();
> +
>  // we now have the encoded data, decode it in place, overwriting the 
> compiled header
> -if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, data, 
> decodedLength))
> +if (!StringUtil::decodeBase64(beginEncodedData, encodedLength, 
> buffer->getData(), decodedLength))
>  {
>  reportException(Error_Program_unreadable_invalid_encoding, 
> fileName);
>  }
> Index: ProgramMetaData.hpp
>
> ===
>
> --- ProgramMetaData.hpp   (revision 12325)
>
> +++ ProgramMetaData.hpp   (working copy)
>
> @@ -80,8 +80,16 @@
>
>  uint16_t   imageVersion;   // version identifier for validity
>  uint16_t   wordSize;   // size of a word
>  uint16_t   bigEndian;  // true if this is a big-endian 
> platform
> -LanguageLevel  requiredLevel;  // required language level for 
> execution
> +uint32_t   requiredLevel;  // required language level for 
> execution (NB: this needs to be an explicitly sized item)
>  uint32_t   reserved;   // padding to bring imageSize to a 
> 64-bit boundary
> +
> +size_t pad;// We need to add an extra pad here 
> to force imageData field to be on an object grain
> +   // boundary so front of the buffer 
> can be chopped off without creating an invalid object.
> +   // The offset of imageData needs to 
> be in integral number of grain increments from the beginning.
> +   // so for 32 bits we are 16 + 4*2 + 
> 2*4 + 4 + 4 = 40 bytes for the offset, and
> +   // for 64-bit we are 16 + 4*2 + 2*4 + 
> 8 + 8 bytes for the offset. This will allow things
> +   // go aligned on a grain boundary on 
> all architectures//
> +
>  size_t imageSize;  // size of the image
>  char   imageData[4];   // the copied image data
>  };
>
>
> Do these changes invalidate compiled ooRexx programs (with the "-e"
> switch) that got compiled before these two changes took effect by any
> chance?
>
> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad Apple versions

[P.O. Jonsson]

> Am 28.10.2021 um 21:15 schrieb CVBruce :
> 
> Well, I don’t think this will be popular, but I think that a lot of these 
> problems are caused by treating ooRexx as an application.
> 
> To me ooRexx is a tool used to create applications, like clang, or python.
> 

I do not think anyone disagrees :-)

> I use the MacPorts package manager, and have tried Brew and fink package 
> managers, and they never have a problem with all of the security issues that 
> you mention. Or if they do, they seem to work them out so that they are 
> transparent to me. All three package managers install to their own areas of 
> the directory that don’t seem to interfere with Apple’s security.

The current DMG „installer“ is sudo-free and install to any place the user 
desires to put it in. All that is needed is to modify the path to include the 
/bin directory of ooRexx.
 
That said it would indeed be desirable to create packages for Homebrew, 
MacPorts and any other packet handling system, It would be great if you have 
connections and can reach out to them and ask what they need. The installation 
package for ooRexx is universally relocatable and would be easy to put in at 
least a „bottle“ for Homebrew. The current DMG is nothing more than a zipped 
copy of the files built and could be mounted and dragged along to any place on 
the machine.

> 
> Upgrades from one MacOS level to the next do require some work, but  work 
> that I would be doing anyway for all the other tools that I use, for example 
> to build ooRexx from source.

This upgrade problems are not to be ignored. On Catalina Homebrew was in 
/usr/local per default whereas in Big Sur is appears to be in /opt? When 
upgrading a Catalina machine to Big Sur I found myself with a non-standard 
setup. Apple are notorious in moving things around. The move from /usr to 
/usr/local for user defined installations some versions ago is what broke the 
(still only) Official ooRexx 4.1.2 installer for instance.
> 
> Rather than a .DMG file that you can download and run the mac installer, I’d 
> rather have something that the MacPorts package manager can download and 
> install.
> 

I don’t see why we can´t have both?

> Anyway that’s my 2¢
> 
> Bruce
> 
>> On Oct 28, 2021, at 7:25 AM, Rony G. Flatscher  
>> wrote:
>> 
>> Just got an upgrade option from BigSur 11.6 to Monterey 12.01.
>> 
>> It seems that with each upgrade of macOS there are new "security" related 
>> crash walls erected (some
>> things that used to work all of a sudden do not work anymore as before). 
>> Short of time wondering
>> whether it is seen to be important to upgrade to Monterey now or whether it 
>> would be o.k. to wait a
>> few months until enough new Apple users with that macOS enter the scene. 
>> What do the Apple users in
>> this list think?
>> 
>> ---rony
>> 
>> 
>> 
>> 
>> ___
>> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad Apple versions

[Chip Davis]

Let's hope that's a false equivalence, P.O.  Godot never showed up, 
and those waiting for him eventually decide to move on, but remain 
stuck where they were.


-Chip-

On 10/28/2021 11:16 AM, P. O. Jonsson wrote:

I see no reason to wait with a release. We have been waiting for Godot long 
enough :-(




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

Re: [Oorexx-devel] Question ad Apple versions

[P. O. Jonsson]

Dear Rony,

My advise would be to wait for the first major update release, i.e. 12.1. I 
have burned  my fingers once to many on macOS releases.

In any case I expect the changes to be for the M1 processor only.

I recently upgraded the Jenkins Mac Mini to Big Sur (so it now build fat 
binaries). That machine can not be upgraded to Monterey, it lack hardware 
necessary for the upgrade.

All my other machines are even older and run High Sierra.  The VMs on these 
machines can also not be upgraded for the same reason. Maybe when Mark upgrade 
we can have a go at testing.

I see no reason to wait with a release. We have been waiting for Godot long 
enough :-(

Von meinem iPhone gesendet

> Am 28.10.2021 um 16:33 schrieb Rony G. Flatscher :
> 
> Just got an upgrade option from BigSur 11.6 to Monterey 12.01.
> 
> It seems that with each upgrade of macOS there are new "security" related 
> crash walls erected (some
> things that used to work all of a sudden do not work anymore as before). 
> Short of time wondering
> whether it is seen to be important to upgrade to Monterey now or whether it 
> would be o.k. to wait a
> few months until enough new Apple users with that macOS enter the scene. What 
> do the Apple users in
> this list think?
> 
> ---rony
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question on user defined classes

[Gil Barmwater]

Thanks Rick and Rony.  Further research after posting the question led 
me to the fact that the "package" was the most likely candidate but the 
details as well as the pointer to the documentation helped me understand 
how this works.


Gil

On 10/12/2021 2:24 PM, Rick McGuire wrote:
The first place that gets searched is the package that defines the 
currently executing code. The package has directory of all the classes 
that are defined within that package unit. The search is for any 
public classes that are made available by ::requires packages. Only 
after that are .local and .environment checked. Each package thus has 
its own namespace for resolving classes, avoiding conflicts with other 
packages.


Rick

On Tue, Oct 12, 2021 at 1:27 PM Gil Barmwater 
 wrote:


When I include a "::class whatever" in my program, any code that uses
that class is able to find it somehow.  It does not appear that
"WHATEVER" is placed in either .environment, where the predefined
classes are listed, nor .local. So how does a reference to
.whatever get
resolved at run time?

Gil



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

Re: [Oorexx-devel] Question on user defined classes

[Rick McGuire]

The first place that gets searched is the package that defines the
currently executing code. The package has directory of all the classes that
are defined within that package unit. The search is for any public classes
that are made available by ::requires packages. Only after that are .local
and .environment checked. Each package thus has its own namespace for
resolving classes, avoiding conflicts with other packages.

Rick

On Tue, Oct 12, 2021 at 1:27 PM Gil Barmwater 
wrote:

> When I include a "::class whatever" in my program, any code that uses
> that class is able to find it somehow.  It does not appear that
> "WHATEVER" is placed in either .environment, where the predefined
> classes are listed, nor .local. So how does a reference to .whatever get
> resolved at run time?
>
> Gil
>
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad native API and resolving an environment symbol

[Rony G. Flatscher]

On 15.08.2021 18:03, Erich Steinböck wrote:
> the FindPackageClass API should do what you want.
> It doesn't just resolve a package name, but will resolve any dot variable 
> name.

great, thank you very much, Erich!

---rony





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

Re: [Oorexx-devel] Question ad native API and resolving an environment symbol

[Erich Steinböck]

Rony,
the FindPackageClass API should do what you want.
It doesn't just resolve a package name, but will resolve any dot variable
name.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Just for the record: Enrico wrote that the empty post was unintentional and 
regarding the drag
packages and "rexx -v":

> What is needed to create the "drag and drop packages"?
>
Just run cmake with 
-DBUILD_DMG=1

After that in the build directory 
./build_macOS_dmg.sh

I am almost done with ….
rexx -e "say .RexxInfo~processor"                                           
          
arm64


And with  
rexx -v                                                                     
                
Open Object Rexx Version 5.0.0 r12266
Build date: Jun  7 2021
Build mode: arm64.universal, 64 bits

I just have to check the cross builds and backward portability

---rony


On 10.06.2021 08:54, Rony G. Flatscher wrote:
>
> Hi Enrico,
>
> it seems that your posting from yesterday does not carry any new text of 
> yours?
>
> ---rony
>
>
> On 09.06.2021 16:41, Enrico Sorichetti via Oorexx-devel wrote:
>>
>>
>>> On 9 Jun 2021, at 15:51, Rony G. Flatscher >> > wrote:
>>>
>>> Enrico,
>>>
>>> just two quick questions inline, if you get some time on your hands:
>>>
>>> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:

> only installs once or a few times so I don’t see a benefit in spending 
> developers time in
> making big beast.

 I would not call adding from 6 to 12 lines of code to the cmakelists a big 
 effort

 6 for the simple task of adding the universal build and backwards 
 compatbility to high sierra
 around 6 more lines if you want to inform the user about the arch and the 
 universal build
 when issuing *rexx -v
 *
>>>
>>> What would these lines look like? :)
>>>
>>>
 and you do not need to build two different drag and drop packages
 also you can build from a x86_64 machine  the universal for the arm64  
>>>
>>> What is needed to create the "drag and drop packages"?
>>>
>>> TIA,
>>>
>>> ---rony
>>>

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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Hi Enrico,

it seems that your posting from yesterday does not carry any new text of yours?

---rony


On 09.06.2021 16:41, Enrico Sorichetti via Oorexx-devel wrote:
>
>
>> On 9 Jun 2021, at 15:51, Rony G. Flatscher > > wrote:
>>
>> Enrico,
>>
>> just two quick questions inline, if you get some time on your hands:
>>
>> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>>>
 only installs once or a few times so I don’t see a benefit in spending 
 developers time in
 making big beast.
>>>
>>> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
>>> effort
>>>
>>> 6 for the simple task of adding the universal build and backwards 
>>> compatbility to high sierra
>>> around 6 more lines if you want to inform the user about the arch and the 
>>> universal build
>>> when issuing *rexx -v
>>> *
>>
>> What would these lines look like? :)
>>
>>
>>> and you do not need to build two different drag and drop packages
>>> also you can build from a x86_64 machine  the universal for the arm64  
>>
>> What is needed to create the "drag and drop packages"?
>>
>> TIA,
>>
>> ---rony
>>

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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

> On 9 Jun 2021, at 15:51, Rony G. Flatscher  wrote:
> 
> Enrico,
> 
> just two quick questions inline, if you get some time on your hands:
> 
> On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>> 
>>> only installs once or a few times so I don’t see a benefit in spending 
>>> developers time in making big beast.
>> 
>> 
>> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
>> effort
>> 
>> 6 for the simple task of adding the universal build and backwards 
>> compatbility to high sierra
>> around 6 more lines if you want to inform the user about the arch and the 
>> universal build
>> when issuing rexx -v 
> What would these lines look like? :)
> 
> 
> 
>> and you do not need to build two different drag and drop packages
>> also you can build from a x86_64 machine  the universal for the arm64   
> What is needed to create the "drag and drop packages"?
> 
> TIA,
> 
> ---rony
> 
> ___
> 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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Enrico,

just two quick questions inline, if you get some time on your hands:

On 08.06.2021 00:41, Enrico Sorichetti via Oorexx-devel wrote:
>
>> only installs once or a few times so I don’t see a benefit in spending 
>> developers time in making
>> big beast.
>
> I would not call adding from 6 to 12 lines of code to the cmakelists a big 
> effort
>
> 6 for the simple task of adding the universal build and backwards 
> compatbility to high sierra
> around 6 more lines if you want to inform the user about the arch and the 
> universal build
> when issuing *rexx -v
> *

What would these lines look like? :)


> and you do not need to build two different drag and drop packages
> also you can build from a x86_64 machine  the universal for the arm64  

What is needed to create the "drag and drop packages"?

TIA,

---rony

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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

> only installs once or a few times so I don’t see a benefit in spending 
> developers time in making big beast.


I would not call adding from 6 to 12 lines of code to the cmakelists a big 
effort

6 for the simple task of adding the universal build and backwards compatbility 
to high sierra
around 6 more lines if you want to inform the user about the arch and the 
universal build
when issuing rexx -v 

and you do not need to build two different drag and drop packages
also you can build from a x86_64 machine  the universal for the arm64   

enrico

PS
I posted the results of building the universal on the mac mini silicon
i did the other way around in february, but to be sure I will rerun the whole 
thing and post the results again



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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[P.O. Jonsson]

> Am 07.06.2021 um 18:11 schrieb Rony G. Flatscher :
> 
> The reason why I came up with the question right now is a student who has a 
> physical new M1 and gets into troubles when running BSF4ooRexx from the Intel 
> version with Java that got compiled for M1 it seems. 
> 
> 

Hi Rony, I do not think you can mix native M1 applications and ones running in 
Rosetta, at least not complex ones, I think your Student should use a Intel 
based JAVA together with the „normal“ BSF4ooRexx (compiled for Intel) in 
Rosetta 2 or use both compiled for the M1 processor. We do not (yet) have any 
M1 based Mac connected to Jenkins so I have no possibility to experiment. Maybe 
Enrico can shed some light on the combo? See also 
https://support.apple.com/en-us/HT211861 


My take on it would be to have two versions of ooRexx for MacOS, one for Intel 
and one for M1, we have different versions of ooRexx for Win32 and Win64, why 
complicate things? A normal user only installs once or a few times so I don’t 
see a benefit in spending developers time in making big beast.

/P.O.

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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

It appears that both intel and arm (by default) are little endians. arm V8 can 
be configured to be both.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---rony
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> 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 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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Buona sera Enrico,

On 07.06.2021 17:26, Enrico Sorichetti via Oorexx-devel wrote:
> BTDTGTTS ( Been There Done That Got The Tee Shirt )
> At the beginning of March I made a post 
> > 
> > I built the APPLE  ooRexx universal binaries  and the test suite runs 
> > well down to El Capitan
> > ( both the x86_64 and the apple silicon  builds)>
> > to run the multi arch, multi OS versions tests I used the drag and drop 
> > installer
>
>
> Nobody was curios on how it was done so I had no incentive to follow on with 
> the implementation
> details

*Wow*!

Sorry, you have been too quick with your solution as you did not even wait for 
a need or question to
come up back then!  ;-)

---

Seriously, just went back and found your posting from March 7th, 16:15! I am 
pretty sure that I read
it and thought wow, but we have time and in the meantime have *totally* 
forgotten about it! :(

The reason why I came up with the question right now is a student who has a 
physical new M1 and gets
into troubles when running BSF4ooRexx from the Intel version with Java that got 
compiled for M1 it
seems.

So I would be interested in having a fat binary for ooRexx, if possible at all, 
and you proofed that
it is possible as you had created such an animal already three months ago and 
tested it on both
architectures! With that I should be able to create a fat binary for BSF4ooRexx 
as well, such that
any combination with Intel/arm Java would work!

---

Would you be able to share how you did that such that the project becomes able 
to apply/incorporate
whatever is necessary for creating a fat binary for ooRexx on Apple?

I am sure, that many would *really* appreciate this a *lot*, even if this is 
not explicitly said!

Again, I am stumped about you having solved that problem already three months 
ago, kudos to you!

---rony


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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Thank-you Enrico. I guess I missed it. Thanks.

Sent by Magic!

> On Jun 7, 2021, at 8:43 AM, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> 
> BTDTGTTS ( Been There Done That Got The Tee Shirt )
> At the beginning of March I made a post 
> > 
> > I built the APPLE  ooRexx universal binaries  and the test suite runs 
> > well down to El Capitan
> > ( both the x86_64 and the apple silicon  builds)>
> > to run the multi arch, multi OS versions tests I used the drag and drop 
> > installer
> 
> 
> Nobody was curios on how it was done so I had no incentive to follow on with 
> the implementation details 
> 
> > One could put multiple copies of oorexx into the .dmg file, and then 
> > let the installer select the correct/best binary to install.
> 
> Why waste time when the system is perfectly capable of it
> 
> ~/ooRexx/testsuite % uname -a 
>   [enrico@enrico-macmini]
> Darwin enrico-macmini.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 
> 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64
> 
> 
> Open Object Rexx Version 5.0.0 r12264
> Build date: Jun  7 2021
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
> This program and the accompanying materials are made available under the terms
> of the Common Public License v1.0 which accompanies this distribution or at
> https://www.oorexx.org/license.html
> 
> ~/ooRexx/svn.src.build % which rexx   
>   [enrico@enrico-macmini]
> /opt/ooRexx/bin/rexx
> 
> ~/ooRexx/svn.src.build % lipo -info /opt/ooRexx/bin/rexx  
>   [enrico@enrico-macmini]
> Architectures in the fat file: /opt/ooRexx/bin/rexx are: x86_64 arm64 
> ~/ooRexx/svn.src.build %  
>   [enrico@enrico-macmini]
> 
> 
> 
> ~/ooRexx/testsuite % rexx testOORexx.rex -s -X native_API   
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
> OS Name:DARWIN
> SysVersion: Darwin 20.5.0
> 
> Tests ran:  23293
> Assertions: 385129
> Failures:   0
> Errors: 0
> 
> File search:00:00:00.536408
> Suite construction: 00:00:00.694814
> Test execution: 00:04:31.740606
> Total time: 00:04:33.461738
> 
> 
> 
> and here the same from a drag and drop install of the arm build on a x8664 
> machine
> 
> 
> ~/ooRexx/testSuite % uname -a 
>   [enrico@enrico-mbp]
> Darwin enrico-mbp 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 
> PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
> 
> 
> ~/ooRexx/testSuite % lipo -info /applications/ooRexx5/bin/rexx
>   [enrico@enrico-mbp]
> Architectures in the fat file: /applications/ooRexx5/bin/rexx are: x86_64 
> arm64 
> 
> 
> ~/ooRexx/testSuite % rexx -v  
>   [enrico@enrico-mbp]
> Open Object Rexx Version 5.0.0 r12264
> Build date: Jun  7 2021
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
> This program and the accompanying materials are made available under the terms
> of the Common Public License v1.0 which accompanies this distribution or at
> https://www.oorexx.org/license.html
> ~/ooRexx/testSuite % 
> 
> 
> ~/ooRexx/testSuite % rexx testOORexx.rex -s -X native_API 
>   [enrico@enrico-mbp]
> 
> NOTE NOTE 
> the error is expected because the case sensitive/case insensitive filesystem 
> detection detection and handling is still broken
> 
> ooTest Framework - Automated Test of the ooRexx Interpreter
> 
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
> OS Name:DARWIN
> SysVersion: Darwin 20.5.0
> 
> Tests ran:  23288
> Assertions: 385289
> Failures:   2
> Errors: 0
> 
> [failure] 20210607 17:09:21.128157
>   svn:r12195   Change date: 2021-03-15 17:46:10 +0100
>   Test:   TEST_SEARCHPATH1
>   Class:  File.testGroup
>   File:   .../ooRexx/testSuite/ooRexx/base/class/File.testGroup
>   Line:   674
>   Failed: assertEquals
> Expected: /Applications/ooRexx5/bin/rexx
> Actual:   /applications/ooRexx5/bin/rexx
> Message:  this may fail if rexx is run directly from a build tree
> 
> [failure] 20210607 17:10:10.527207
>   svn:r12195   Change date: 2021-03-15 17:46:10 +0100
>   Test:   TEST_SEARCHPATH_REXX
>   Class:  SYSSEARCHPATH.TESTGROUP
>   File:   

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Enrico Sorichetti via Oorexx-devel]

BTDTGTTS ( Been There Done That Got The Tee Shirt )
At the beginning of March I made a post 
> 
> I built the APPLE  ooRexx universal binaries  and the test suite runs 
> well down to El Capitan
> ( both the x86_64 and the apple silicon  builds)>
> to run the multi arch, multi OS versions tests I used the drag and drop 
> installer


Nobody was curios on how it was done so I had no incentive to follow on with 
the implementation details 

> One could put multiple copies of oorexx into the .dmg file, and then let 
> the installer select the correct/best binary to install.

Why waste time when the system is perfectly capable of it

~/ooRexx/testsuite % uname -a   
[enrico@enrico-macmini]
Darwin enrico-macmini.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 
05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64


Open Object Rexx Version 5.0.0 r12264
Build date: Jun  7 2021
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
This program and the accompanying materials are made available under the terms
of the Common Public License v1.0 which accompanies this distribution or at
https://www.oorexx.org/license.html 

~/ooRexx/svn.src.build % which rexx 
[enrico@enrico-macmini]
/opt/ooRexx/bin/rexx

~/ooRexx/svn.src.build % lipo -info /opt/ooRexx/bin/rexx
[enrico@enrico-macmini]
Architectures in the fat file: /opt/ooRexx/bin/rexx are: x86_64 arm64 
~/ooRexx/svn.src.build %
[enrico@enrico-macmini]



~/ooRexx/testsuite % rexx testOORexx.rex -s -X native_API   

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23293
Assertions: 385129
Failures:   0
Errors: 0

File search:00:00:00.536408
Suite construction: 00:00:00.694814
Test execution: 00:04:31.740606
Total time: 00:04:33.461738



and here the same from a drag and drop install of the arm build on a x8664 
machine


~/ooRexx/testSuite % uname -a   
[enrico@enrico-mbp]
Darwin enrico-mbp 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 PDT 
2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64


~/ooRexx/testSuite % lipo -info /applications/ooRexx5/bin/rexx  
[enrico@enrico-mbp]
Architectures in the fat file: /applications/ooRexx5/bin/rexx are: x86_64 arm64 


~/ooRexx/testSuite % rexx -v
[enrico@enrico-mbp]
Open Object Rexx Version 5.0.0 r12264
Build date: Jun  7 2021
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2021 Rexx Language Association. All rights reserved.
This program and the accompanying materials are made available under the terms
of the Common Public License v1.0 which accompanies this distribution or at
https://www.oorexx.org/license.html
~/ooRexx/testSuite % 


~/ooRexx/testSuite % rexx testOORexx.rex -s -X native_API   
[enrico@enrico-mbp]

NOTE NOTE 
the error is expected because the case sensitive/case insensitive filesystem 
detection detection and handling is still broken

ooTest Framework - Automated Test of the ooRexx Interpreter

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23288
Assertions: 385289
Failures:   2
Errors: 0

[failure] 20210607 17:09:21.128157
  svn:r12195   Change date: 2021-03-15 17:46:10 +0100
  Test:   TEST_SEARCHPATH1
  Class:  File.testGroup
  File:   .../ooRexx/testSuite/ooRexx/base/class/File.testGroup
  Line:   674
  Failed: assertEquals
Expected: /Applications/ooRexx5/bin/rexx
Actual:   /applications/ooRexx5/bin/rexx
Message:  this may fail if rexx is run directly from a build tree

[failure] 20210607 17:10:10.527207
  svn:r12195   Change date: 2021-03-15 17:46:10 +0100
  Test:   TEST_SEARCHPATH_REXX
  Class:  SYSSEARCHPATH.TESTGROUP
  File:   .../ooRexx/testSuite/ooRexx/base/rexxutil/SysSearchPath.testGroup
  Line:   122
  Failed: assertSame
Expected: /Applications/ooRexx5/bin/rexx
Actual:   /applications/ooRexx5/bin/rexx
Message:  this may fail if rexx is run directly from a build tree

Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 7 Jun 2021
OS Name:DARWIN
SysVersion: Darwin 20.5.0

Tests ran:  23288
Assertions: 

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Rick, thanks for keeping me honest.

Sent by Magic!

> On Jun 7, 2021, at 8:34 AM, Rick McGuire  wrote:
> 
> 
> 
> 
>> On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:
>> Now that I think about it rexx.img was the primary problem. It contains 
>> executable code, but is not in a library format. You can’t even combine x86 
>> and amd64 into one binary.
> I contains no native code, only core classes and and methods that are written 
> in Rexx in a pre-compiled format. However, all values are stored in the .img 
> file using the native architecture endian-ness. Intel is little-endian and 
> I'm pretty sure ARM is big-endian, do the images would not be compatible. 
>  
>> 
>> There was probably a good reason why rexx.img was implemented (speed or 
>> space?).
> It was a huge savings in startup time, particularly back when a really fast 
> machine ran at about 100Mhz and memory was still very expensive. It might be 
> that things have gotten fast enough now that removing this might not be a 
> huge impact, and there might even be some advantages to no longer having 
> this, but it would not be a simple experiment to perform. 
> 
>  
>> 
>> Perhaps it’s time to talk about eliminating or replacing it with something 
>> more standard.
> The replacement would be to reparse and translate all of the core classes 
> from source each time the interpreter is started. 
> 
> Rick
>  
>> 
>> Bruce
>> 
>> Sent by Magic!
>> 
>> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> > 
>> > The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> > because Rexx is   invoked during the build. There are tools to combine 
>> > single binaries into “universal” binaries, but what your are really asking 
>> > is can OORexx be cross compiled for a non-native architecture.  Even then 
>> > there were, if I remember correctly, problems with the Rexx.img file.
>> > Bruce
>> > 
>> > Sent by Magic!
>> > 
>> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> >> wrote:
>> >> 
>> >> As Apple has been selling new hardware with a proper processor, it would 
>> >> be important to support
>> >> that hardware platform.
>> >> 
>> >> In the past Apple allowed for "fat binaries" which included binaries for 
>> >> different hardware
>> >> architectures in the same file. Would it be possible with CMake to have 
>> >> such ooRexx "fat binaries"
>> >> created for the MacOS platform? If so, how would one be able to achieve 
>> >> that?
>> >> 
>> >> ---rony
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> 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 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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rick McGuire]

On Mon, Jun 7, 2021 at 10:38 AM CV Bruce  wrote:

> Now that I think about it rexx.img was the primary problem. It contains
> executable code, but is not in a library format. You can’t even combine x86
> and amd64 into one binary.
>
I contains no native code, only core classes and and methods that are
written in Rexx in a pre-compiled format. However, all values are stored in
the .img file using the native architecture endian-ness. Intel is
little-endian and I'm pretty sure ARM is big-endian, do the images would
not be compatible.


>
> There was probably a good reason why rexx.img was implemented (speed or
> space?).
>
It was a huge savings in startup time, particularly back when a really fast
machine ran at about 100Mhz and memory was still very expensive. It might
be that things have gotten fast enough now that removing this might not be
a huge impact, and there might even be some advantages to no longer having
this, but it would not be a simple experiment to perform.



>
> Perhaps it’s time to talk about eliminating or replacing it with something
> more standard.
>
The replacement would be to reparse and translate all of the core classes
from source each time the interpreter is started.

Rick


>
> Bruce
>
> Sent by Magic!
>
> > On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
> >
> > The last time I looked at this, probably ppc/x86, it wasn’t possible
> because Rexx is   invoked during the build. There are tools to combine
> single binaries into “universal” binaries, but what your are really asking
> is can OORexx be cross compiled for a non-native architecture.  Even then
> there were, if I remember correctly, problems with the Rexx.img file.
> > Bruce
> >
> > Sent by Magic!
> >
> >> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher 
> wrote:
> >>
> >> As Apple has been selling new hardware with a proper processor, it
> would be important to support
> >> that hardware platform.
> >>
> >> In the past Apple allowed for "fat binaries" which included binaries
> for different hardware
> >> architectures in the same file. Would it be possible with CMake to have
> such ooRexx "fat binaries"
> >> created for the MacOS platform? If so, how would one be able to achieve
> that?
> >>
> >> ---rony
> >>
> >>
> >>
> >> ___
> >> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

One could put multiple copies of oorexx into the .dmg file, and then let the 
installer select the correct/best binary to install.

Sent by Magic!

> On Jun 7, 2021, at 7:37 AM, CV Bruce  wrote:
> 
> Now that I think about it rexx.img was the primary problem. It contains 
> executable code, but is not in a library format. You can’t even combine x86 
> and amd64 into one binary.
> 
> There was probably a good reason why rexx.img was implemented (speed or 
> space?).
> 
> Perhaps it’s time to talk about eliminating or replacing it with something 
> more standard.
> 
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
>> 
>> The last time I looked at this, probably ppc/x86, it wasn’t possible 
>> because Rexx is   invoked during the build. There are tools to combine 
>> single binaries into “universal” binaries, but what your are really asking 
>> is can OORexx be cross compiled for a non-native architecture.  Even then 
>> there were, if I remember correctly, problems with the Rexx.img file.
>> Bruce
>> 
>> Sent by Magic!
>> 
 On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
 wrote:
>>> 
>>> As Apple has been selling new hardware with a proper processor, it would 
>>> be important to support
>>> that hardware platform.
>>> 
>>> In the past Apple allowed for "fat binaries" which included binaries for 
>>> different hardware
>>> architectures in the same file. Would it be possible with CMake to have 
>>> such ooRexx "fat binaries"
>>> created for the MacOS platform? If so, how would one be able to achieve 
>>> that?
>>> 
>>> ---rony
>>> 
>>> 
>>> 
>>> ___
>>> 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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

Now that I think about it rexx.img was the primary problem. It contains 
executable code, but is not in a library format. You can’t even combine x86 and 
amd64 into one binary.

There was probably a good reason why rexx.img was implemented (speed or space?).

Perhaps it’s time to talk about eliminating or replacing it with something more 
standard.

Bruce

Sent by Magic!

> On Jun 7, 2021, at 7:22 AM, CV Bruce  wrote:
> 
> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
> Rexx is   invoked during the build. There are tools to combine single 
> binaries into “universal” binaries, but what your are really asking is can 
> OORexx be cross compiled for a non-native architecture.  Even then there 
> were, if I remember correctly, problems with the Rexx.img file.
> Bruce
> 
> Sent by Magic!
> 
>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> wrote:
>> 
>> As Apple has been selling new hardware with a proper processor, it would be 
>> important to support
>> that hardware platform.
>> 
>> In the past Apple allowed for "fat binaries" which included binaries for 
>> different hardware
>> architectures in the same file. Would it be possible with CMake to have such 
>> ooRexx "fat binaries"
>> created for the MacOS platform? If so, how would one be able to achieve that?
>> 
>> ---rony
>> 
>> 
>> 
>> ___
>> 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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rick McGuire]

I suspect rexx.img would not be compatible between the two because of
endian issues.

Rick

On Mon, Jun 7, 2021 at 10:23 AM CV Bruce  wrote:

> The last time I looked at this, probably ppc/x86, it wasn’t possible
> because Rexx is   invoked during the build. There are tools to combine
> single binaries into “universal” binaries, but what your are really asking
> is can OORexx be cross compiled for a non-native architecture.  Even then
> there were, if I remember correctly, problems with the Rexx.img file.
> Bruce
>
> Sent by Magic!
>
> > On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher 
> wrote:
> >
> > As Apple has been selling new hardware with a proper processor, it
> would be important to support
> > that hardware platform.
> >
> > In the past Apple allowed for "fat binaries" which included binaries for
> different hardware
> > architectures in the same file. Would it be possible with CMake to have
> such ooRexx "fat binaries"
> > created for the MacOS platform? If so, how would one be able to achieve
> that?
> >
> > ---rony
> >
> >
> >
> > ___
> > 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[Rony G. Flatscher]

Bruce, thank you very much for your insights!

So then maybe one would need two separate builds on each architecture and then 
maybe create
optionally with "lipo" the fat binaries for each dylib.

For this it would be handy to have "stick" versions of ooRexx be buildable, 
because then one could
ask for the stick version of the different architectures and become able to 
build the fat binaries
on a single system.

---rony


On 07.06.2021 16:22, CV Bruce wrote:
> The last time I looked at this, probably ppc/x86, it wasn’t possible because 
> Rexx is   invoked during the build. There are tools to combine single 
> binaries into “universal” binaries, but what your are really asking is can 
> OORexx be cross compiled for a non-native architecture.  Even then there 
> were, if I remember correctly, problems with the Rexx.img file.
> Bruce
>
> Sent by Magic!
>
>> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  
>> wrote:
>>
>> As Apple has been selling new hardware with a proper processor, it would be 
>> important to support
>> that hardware platform.
>>
>> In the past Apple allowed for "fat binaries" which included binaries for 
>> different hardware
>> architectures in the same file. Would it be possible with CMake to have such 
>> ooRexx "fat binaries"
>> created for the MacOS platform? If so, how would one be able to achieve that?
>>
>> ---rony



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

Re: [Oorexx-devel] Question ad CMake and "fat binaries" for MacOS

[CV Bruce]

The last time I looked at this, probably ppc/x86, it wasn’t possible because 
Rexx is   invoked during the build. There are tools to combine single binaries 
into “universal” binaries, but what your are really asking is can OORexx be 
cross compiled for a non-native architecture.  Even then there were, if I 
remember correctly, problems with the Rexx.img file.
Bruce

Sent by Magic!

> On Jun 7, 2021, at 5:30 AM, Rony G. Flatscher  wrote:
> 
> As Apple has been selling new hardware with a proper processor, it would be 
> important to support
> that hardware platform.
> 
> In the past Apple allowed for "fat binaries" which included binaries for 
> different hardware
> architectures in the same file. Would it be possible with CMake to have such 
> ooRexx "fat binaries"
> created for the MacOS platform? If so, how would one be able to achieve that?
> 
> ---rony
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[Rony G. Flatscher]

Refreshed the zip-archive, which now is called "oorexx_stick_20201002.zip".

After creating the Windows scripts, "%userprofile%\goto_ooRexx{32|64}.cmd" now 
also changes to the
drive where the desired ooRexx resides.

---rony


On 01.10.2020 19:57, Rony G. Flatscher wrote:
> You can get the usb stick version temporarily from my Dropbox at: <
> https://www.dropbox.com/sh/s1zyw48w74npiok/AADUAwBULbyM7AlTy0Q4Qkcua?dl=0>.
>
> ---rony
>
>
> On 30.09.2020 15:43, Rony G. Flatscher wrote:
>> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
>> drive" at this year's
>> International Rexx symposium (cf. 
>> https://www.rexxla.org/events/2020/schedule.html). In the meantime
>> I finalized the USB-package and it it should be ready for testing and will 
>> demonstrate it tomorrow
>> at the symposium.
>>
>> Now, it would probably make sense to make it also available to interested 
>> parties for evaluation and
>> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
>> 64-bit) and Windows (32-
>> and 64-bit).
>>
>> So now I am contemplating to make it available in the sandbox directory of 
>> the ooRexx project for
>> others to get access to the package. The zip-archive is appr. 40MB and comes 
>> with a short readme.txt
>> file.
>>
>> The question for the developers: is that o.k. with you? An alternative would 
>> be to use a different
>> location instead.
>>
>> It would be important to remove that particular package ASAP as new versions 
>> of ooRexx in the trunk
>> should obsolete this particular package, such that ooRexx programmers do not 
>> get outdated software
>> after a while. OTOH it allows you to check it out and contemplate whether we 
>> should also create
>> "stick"-versions of ooRexx for all the supported platforms.
>>
>> ---rony
>>



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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[Rony G. Flatscher]

You can get the usb stick version temporarily from my Dropbox at: <
https://www.dropbox.com/sh/s1zyw48w74npiok/AADUAwBULbyM7AlTy0Q4Qkcua?dl=0>.

---rony


On 30.09.2020 15:43, Rony G. Flatscher wrote:
> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
> drive" at this year's
> International Rexx symposium (cf. 
> https://www.rexxla.org/events/2020/schedule.html). In the meantime
> I finalized the USB-package and it it should be ready for testing and will 
> demonstrate it tomorrow
> at the symposium.
>
> Now, it would probably make sense to make it also available to interested 
> parties for evaluation and
> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
> 64-bit) and Windows (32-
> and 64-bit).
>
> So now I am contemplating to make it available in the sandbox directory of 
> the ooRexx project for
> others to get access to the package. The zip-archive is appr. 40MB and comes 
> with a short readme.txt
> file.
>
> The question for the developers: is that o.k. with you? An alternative would 
> be to use a different
> location instead.
>
> It would be important to remove that particular package ASAP as new versions 
> of ooRexx in the trunk
> should obsolete this particular package, such that ooRexx programmers do not 
> get outdated software
> after a while. OTOH it allows you to check it out and contemplate whether we 
> should also create
> "stick"-versions of ooRexx for all the supported platforms.
>
> ---rony
>
>
>



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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[Gil Barmwater]

At today's Symposium presentation, I announced - and demonstrated - a 
new version of the documentation build tools that are written in ooRexx 
and that does not depend on any* system commands like XCOPY or SET.  *It 
still uses Zip on *nix/mac.  Once the documentation is finished, I will 
commit it to the repository for testing in the non-Windows 
environments.  Hopefully, it will work well there as well :-).


Gil

On 9/30/2020 1:36 PM, P.O. Jonsson wrote:




But maybe you mean something more?

Yes, one zip-archive including all five platforms in a common directory 
structure and a utility that
will create scripts to run any of the stick ooRexxes.

The idea is, that someone like you who has more than one platform or friends 
with different
operating systems, that you could put that on your USB-stick and run ooRexx on 
the platform that
happens to be the one you need or your friends use.


Ok! That makes sense indeed!


---

@René: this version will not have BSF4ooRexx support, it is the initial pure 
ooRexx version. I would
like to gather experiences and user reports before going further and create 
stick versions of ooRexx
that add additional functionality.


Something for next years presentation then? :-)


More at the presentation tomorrow…

REALLY  sorry I cannot join the presentations :-(


Cheers

---rony




___
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


--
Gil Barmwater



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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[P.O. Jonsson]

>> But maybe you mean something more?
> 
> Yes, one zip-archive including all five platforms in a common directory 
> structure and a utility that
> will create scripts to run any of the stick ooRexxes.
> 
> The idea is, that someone like you who has more than one platform or friends 
> with different
> operating systems, that you could put that on your USB-stick and run ooRexx 
> on the platform that
> happens to be the one you need or your friends use.
> 

Ok! That makes sense indeed!

> ---
> 
> @René: this version will not have BSF4ooRexx support, it is the initial pure 
> ooRexx version. I would
> like to gather experiences and user reports before going further and create 
> stick versions of ooRexx
> that add additional functionality.
> 

Something for next years presentation then? :-)

> More at the presentation tomorrow…

REALLY  sorry I cannot join the presentations :-(

> 
> Cheers
> 
> ---rony
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[Rony G. Flatscher]

Dear P.O.,

On 30.09.2020 17:33, P. O. Jonsson wrote:
> Dear Rony et al,
>
> As I assume all are aware(?) ooRexx on the Mac platform can be used on a USB 
> stick without any modification whatsoever of the official build. A simple 
> drag to a formatted USB is sufficient to make it run. This has been the 
> case for more than a year, from the brilliant intervention from Enrico. 
>
> All that is needed to make the installation on MacOS to work is to add its 
> /bin dir to the path. This is irrespective of where it runs. Also on a shared 
> drive this should work. Or in ~/Application or in /Applications or wherever. 
>
> But maybe you mean something more?

Yes, one zip-archive including all five platforms in a common directory 
structure and a utility that
will create scripts to run any of the stick ooRexxes.

The idea is, that someone like you who has more than one platform or friends 
with different
operating systems, that you could put that on your USB-stick and run ooRexx on 
the platform that
happens to be the one you need or your friends use.

---

@René: this version will not have BSF4ooRexx support, it is the initial pure 
ooRexx version. I would
like to gather experiences and user reports before going further and create 
stick versions of ooRexx
that add additional functionality.

More at the presentation tomorrow...

Cheers

---rony




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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[René Jansen]

I just assumed that this version would include bsf4ooRexx for several platforms.

René.

> On 30 Sep 2020, at 17:33, P. O. Jonsson  wrote:
> 
> Dear Rony et al,
> 
> As I assume all are aware(?) ooRexx on the Mac platform can be used on a USB 
> stick without any modification whatsoever of the official build. A simple 
> drag to a formatted USB is sufficient to make it run. This has been the 
> case for more than a year, from the brilliant intervention from Enrico. 
> 
> All that is needed to make the installation on MacOS to work is to add its 
> /bin dir to the path. This is irrespective of where it runs. Also on a shared 
> drive this should work. Or in ~/Application or in /Applications or wherever. 
> 
> But maybe you mean something more?
> 
> Von meinem iPhone gesendet
> 
>> Am 30.09.2020 um 17:05 schrieb Rony G. Flatscher :
>> 
>> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
>> drive" at this year's
>> International Rexx symposium (cf. 
>> https://www.rexxla.org/events/2020/schedule.html). In the meantime
>> I finalized the USB-package and it it should be ready for testing and will 
>> demonstrate it tomorrow
>> at the symposium.



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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[P. O. Jonsson]

I forgot: the howto can be found in my Dropbox, there should be a link to it in 
the download section. 

Von meinem iPhone gesendet

> Am 30.09.2020 um 17:05 schrieb Rony G. Flatscher :
> 
> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
> drive" at this year's
> International Rexx symposium (cf. 
> https://www.rexxla.org/events/2020/schedule.html). In the meantime
> I finalized the USB-package and it it should be ready for testing and will 
> demonstrate it tomorrow
> at the symposium.
> 
> Now, it would probably make sense to make it also available to interested 
> parties for evaluation and
> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
> 64-bit) and Windows (32-
> and 64-bit).
> 
> So now I am contemplating to make it available in the sandbox directory of 
> the ooRexx project for
> others to get access to the package. The zip-archive is appr. 40MB and comes 
> with a short readme.txt
> file.
> 
> The question for the developers: is that o.k. with you? An alternative would 
> be to use a different
> location instead.
> 
> It would be important to remove that particular package ASAP as new versions 
> of ooRexx in the trunk
> should obsolete this particular package, such that ooRexx programmers do not 
> get outdated software
> after a while. OTOH it allows you to check it out and contemplate whether we 
> should also create
> "stick"-versions of ooRexx for all the supported platforms.
> 
> ---rony
> 
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[P. O. Jonsson]

Dear Rony et al,

As I assume all are aware(?) ooRexx on the Mac platform can be used on a USB 
stick without any modification whatsoever of the official build. A simple 
drag to a formatted USB is sufficient to make it run. This has been the 
case for more than a year, from the brilliant intervention from Enrico. 

All that is needed to make the installation on MacOS to work is to add its /bin 
dir to the path. This is irrespective of where it runs. Also on a shared drive 
this should work. Or in ~/Application or in /Applications or wherever. 

But maybe you mean something more?

Von meinem iPhone gesendet

> Am 30.09.2020 um 17:05 schrieb Rony G. Flatscher :
> 
> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
> drive" at this year's
> International Rexx symposium (cf. 
> https://www.rexxla.org/events/2020/schedule.html). In the meantime
> I finalized the USB-package and it it should be ready for testing and will 
> demonstrate it tomorrow
> at the symposium.
> 
> Now, it would probably make sense to make it also available to interested 
> parties for evaluation and
> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
> 64-bit) and Windows (32-
> and 64-bit).
> 
> So now I am contemplating to make it available in the sandbox directory of 
> the ooRexx project for
> others to get access to the package. The zip-archive is appr. 40MB and comes 
> with a short readme.txt
> file.
> 
> The question for the developers: is that o.k. with you? An alternative would 
> be to use a different
> location instead.
> 
> It would be important to remove that particular package ASAP as new versions 
> of ooRexx in the trunk
> should obsolete this particular package, such that ooRexx programmers do not 
> get outdated software
> after a while. OTOH it allows you to check it out and contemplate whether we 
> should also create
> "stick"-versions of ooRexx for all the supported platforms.
> 
> ---rony
> 
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[René Jansen]

No problem with me.

What I would *most* like is that we can build the package in Jenkins and it 
will be automatically obviated by new builds.

René.


> On 30 Sep 2020, at 15:43, Rony G. Flatscher  wrote:
> 
> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
> drive" at this year's
> International Rexx symposium (cf. 
> https://www.rexxla.org/events/2020/schedule.html). In the meantime
> I finalized the USB-package and it it should be ready for testing and will 
> demonstrate it tomorrow
> at the symposium.
> 
> Now, it would probably make sense to make it also available to interested 
> parties for evaluation and
> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
> 64-bit) and Windows (32-
> and 64-bit).
> 
> So now I am contemplating to make it available in the sandbox directory of 
> the ooRexx project for
> others to get access to the package. The zip-archive is appr. 40MB and comes 
> with a short readme.txt
> file.
> 
> The question for the developers: is that o.k. with you? An alternative would 
> be to use a different
> location instead.
> 
> It would be important to remove that particular package ASAP as new versions 
> of ooRexx in the trunk
> should obsolete this particular package, such that ooRexx programmers do not 
> get outdated software
> after a while. OTOH it allows you to check it out and contemplate whether we 
> should also create
> "stick"-versions of ooRexx for all the supported platforms.
> 
> ---rony
> 
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad redirected commands

[Michael Lueck]

Greetings Rony,


Rony G. Flatscher wrote:

The current implementation of the redirection of commands seems to assume that 
only text data gets feeded and output, which is not true.




Perhaps a bit of original mfc DNA bleeding through from Classic REXX: "Everything is 
a string" ;-)

Yes, I agree with your critique / dilemma. ooRexx needs to not assume 
everything is a string.

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


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

Re: [Oorexx-devel] Question ad redirected commands

[Rony G. Flatscher]

The current implementation of the redirection of commands seems to assume that 
only text data gets
feeded and output, which is not true. All operating systems allow one to pipe 
binary data as well
and therefore there is a need to process binary data on input and output.

Now, it may be true that most of the times text gets piped, such that the 
current implementation in
ooRexx is ideal for that.

However, there is a need for being able to process binary data as well.

Maybe one could indicate the fact that binary data is to be processed by adding 
an optional keyword
BINARY, e.g.

...
address system "readbinary.rex < in\bsf4oorexx_016.png" with input binary 
output using binary (xyz)
...

Or maybe another possibility would be to imply binary if the expression in 
"using (xyz)" yields a
string value?

---rony



On 23.09.2020 15:34, Rony G. Flatscher wrote:
>
> Is it possible to redirect commands using binary data for input and output?
>
> If so how can one achieve this?
>
> ---
>
> Example: binary file (a graphic), size 976 can be processed with this Rexx 
> filter program
> "readbinary.rex":
>
> allchars=readall()-- read from stdin using charin()
> .output~charout(allchars) -- write binary
>
> ::routine readall
>   mb=.mutableBuffer~new
>   signal on notready
>
>   do counter i forever
>  mb~append(.input~charin) -- supplying a length does not work
>   end
>
> notready:
>   .error~say(i "charin reads")  -- in this sample yields: "977 charin 
> reads"
>   return mb~string
>
> Running the above program with "readbinary.rex < image.png > output.png" 
> works, the resulting file
> is identical to the original one.
>
> ---
>
> Trying to fetch the binary data with redirecting .output to an .array breaks 
> up the binary data
> and swallows CR-LF characters it seems, e.g.:
>
> out=.array~new
> cmd="readbinary.rex < in\bsf4oorexx_016.png "
> say "cmd:" cmd
> address system cmd with output using (out)
> say "out~items:" out~items
> sum=0
> do counter i data over out
>sum += data~length
>say "#" i":" edit(data)
> end
>
> .error~say("test2.rex: sum="sum)
>
> ::routine edit
>   parse arg data
>
>   str1="length=["|| (data~length)~right(4)"]"
>   str1=str1 data~left(min(3,data~length))~c2x~left(6) "|"
>
>   if data~length>3 then
>   str1=str1 "right(3)~c2x:" data~right(min(3,data~length))~c2x~left(6)
>   else
>   do
>  len=data~length-3
>  if len>0 then
> str1=str1 "right("len")~c2x:" 
> data~right(min(3,len))~c2x~left(len*2)
>   end
>   return str1
>
> In my test case this results in eight array items, and adding up the eight 
> chunks is eight
> characters short compared to the original. Here the output:
>
> G:\test\oorexx\redirect>test2
> cmd: readbinary.rex < in\bsf4oorexx_016.png
> 977 charin reads
> --->
> 
> 89504E470D0A1A0A000D49484452001000100806001FF3FF6103974944415478DA4D936D6C53651886EFF7B4A767A7675DCB76D6F6281B04C73
> 
> 580637E30995F307F8C1F10C090684C8C46C948FC831A2526447F982846D1CC294403314CD998A213AB9B83B10D261A452CD2B18F6EEBBAB6EBFABDF5F4F39CE329
> 
> 29C437B9F224CFFBBC77F23EB96F82C25194F31AB5702A6695BBF335329BB6DCEC9F78686AF84AD55232E6BEEFB9AD97EA9B6D3EBD5EE7A528CAA7CE84C8FF047492833
> 
> 4C9E3AE77820BEE8DA246A1E30B29B8A67DD9A5409099F7B889B98A975A9EBADF49B73E7C84E74BDC34AD9DBF2390EBB73F9FBA30D0E12461CAB4BB412BBA72983C338A
> 
> E0821F04125C0137529B56635B99193506665CF742EBBB66B3C97D4B20DBD7D79239D36DFF830AA6F9B6478B4A743C5C1F0DE1A66B0AA488401B4A603CE487A5750B569
> 
> 6B2305E9ECC89D6E25EDB6B7BED44191E2E53D8B495E3321C4D14686018F4E2EB8E6F20B204B9C41292114941FDF626A4E76611BEEE9293D178ACF4959D5F10
> 
> D977EE8A6F31D478F1DAAC52B28225F5B66A08B2163FB6772332E5413012458052C0180CA8B158A111534878BC4A389B22630AFA883474DC1B1338E1A537BB70EA541B0
> 
> EEC3F8AF70EB7E1BBCE5FE0199FC6355544A635B0AD1260F12E83613930EA4EA6265CC808A62491FE39911BF2C4C8D163BDD4F66DF782058D7DFB5A70E4D3B3D8B2B906
> 
> F1641283E7FFC25AC104C37400E1313F38BD1E0A91E1F0F963449AEF513EFCEAA242E834191D75E274FBAB985C08A3B367100D0DEBB0F5914D387776045AF51BAB4C2C2
> 
> E74FC00D113458950A64CA4C4189918ED901EDFF316F5F1270770F2643F5E7F71077EFDDD09319385D95C0A8666D0B4BE1A3F5DFA1B2B2B2CC8BA7C18E91A80A4A3156B
> 
> 635D8CC8735D628AA58BA8629AA8C680727506A9CA72D0460E5AAD0624964536BA0C452807A134C82C26E5C56088F89713F1CBBF5DFF9E78386EFF7CF55DEF177DF934B
> 
> 77A4D3934DD7FE2DFCF46C01E7B0655211ED15D6F60EC502BB8C76A5197A8CCA4DF6ED7D92BF8D3D36B2B1C3CBFC243EA54FF7F5B2D0CC83B1A1F287DF941B04606E2A1
> 
> 7E754926A07710B3CF6E86F4442D6A02463973F8736A408713BDB635F6CA4A73B0B979FD2D27521B01FE8327D7751A054BA3DE6CD1246ECC25020E678CB298AC86FA5A9
> 
> A5E1433C1AB8EC99FE3C9E33D06EE86D1581CDFB0E11EEFC1837BE3B7B3A0553114C8A79256D1AB30F99CA9A454A4C2ACA8125659CEF7EE84A9F0902988512AB7EF9442
> 

Re: [Oorexx-devel] Question ad supporting 32-bit Linux

[Rony G. Flatscher]

On 30.07.2020 22:44, Michael Lueck wrote:
> Rony G. Flatscher wrote:
>> Should we still support 32-bit Linux at all?
>
> Ubuntu dropped 32-bit at LTS version 16.04. That is only supported through 
> next April, I believe.

... cut ...

In the meantime Ubuntu has a new 32-bit LTS version 18.04, so support by Ubuntu 
got extended by years.

Given all the feedback, it seems we should explicitly support 32-bit Linux for 
the years to come.

In the meantime (for creating a new version of BSF4ooRexx for 32-bit and 
64-bit) I got a need to
locate a 32-bit Linux and ended up in saving me the efforts by using a 
VirtualBox image from
.

Found a 32-bit 16.04 version for which I installed (sudo apt install) the 
packages:

  * svn
  * git
  * cmake
  * rpm

Could create a 32-bit Linux version and deb and rpm installation packages from 
it without any hazzles!

Using the Ubuntu update I was able to upgrade the image to 18.04 in the 
meantime. Entering
"lbs_release -d" now yields: "Ubuntu 18.04.5 LTS".

---rony


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

Re: [Oorexx-devel] Question ad setting scope of a MethodClass object

[Rony G. Flatscher]

Patch and test scripts with .

---rony


On 06.08.2020 16:30, Rony G. Flatscher wrote:
>
> O.K., I think I found a solution that works, will post the changes as a patch 
> with a new bug
> tracker item.
>
> ---rony
>
>
> On 06.08.2020 14:03, Rony G. Flatscher wrote:
>>
>> Attached please find the patch that makes method's newFile work with 
>> compiled Rexx scripts, but
>> has a problem at runtime when trying to invoke a method that got restored 
>> from the compiled form.
>>
>> ---rony
>>
>>
>> On 06.08.2020 13:54, Rony G. Flatscher wrote:
>>>
>>> As a first step I have been trying to correct the code to accept compiled 
>>> Rexx scripts as method
>>> code (using the .method's newFile).
>>>
>>> This seems to have been successful, decoding now works.
>>>
>>> However, when assigning the method object to a class and then sending an 
>>> object of that class
>>> the message to execute the method, I get the runtime error message (Rexx 
>>> test script at the end):
>>>
>>> 15 *-*   say .context~name", return value:" o~aha(1,2,3)
>>> Error 97 running 
>>> G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\testrgf.rex line 15:  Object 
>>> method not found.
>>> Error 97.3:  Object "a TEST" cannot accept package scope message "AHA" 
>>> from a different package caller.
>>>
>>> The compiled Rexx code for the method gets successfully processed in a new 
>>> method defined in
>>> ProgramMetaData.cpp:
>>>
>>> MethodClass *ProgramMetaData::restoreMethod(RexxString *name, 
>>> BufferClass *buffer)
>>> {
>>> ProgramMetaData *metaData;
>>>
>>> // check to see if this is already translated
>>> if (!processRestoreData(name, buffer, metaData))
>>> {
>>> // nope, can't restore this
>>> return OREF_NULL;
>>> }
>>>
>>> // make sure this is valid for interpreter
>>> if (!metaData->validate(name))
>>> {
>>> return OREF_NULL;
>>> }
>>>
>>> // this should be valid...try to restore.
>>> Protected method = MethodClass::restore(buffer, 
>>> metaData->getImageData(), metaData->getImageSize());
>>> // change the program name to match the file this was restored from
>>> method->getPackageObject()->setProgramName(name);
>>> return method;
>>> }
>>>
>>> The question is, how can I inhibit the runtime error 97.3, what do I need 
>>> to do to the method
>>> object?
>>>
>>> The starting point is in LanguageParser the new method:
>>>
>>> MethodClass* LanguageParser::createMethod(RexxString *name, 
>>> PackageClass *sourceContext)
>>> {
>>> // load the file into a buffer
>>> Protected program_buffer = 
>>> FileProgramSource::readProgram(name->getStringData());
>>> // if this failed, report an error now.
>>> if (program_buffer == (BufferClass *)OREF_NULL)
>>> {
>>> reportException(Error_Program_unreadable_name, name);
>>> }
>>>
>>> // try to restore a flattened program first
>>> Protected method = MethodClass::restore(name, 
>>> program_buffer);
>>> if (method != (MethodClass *)OREF_NULL)
>>> {
>>>
>>> return method;
>>> }
>>>
>>> // create the appropriate program source, then the parser, then 
>>> generate the
>>> // code.
>>> Protected programSource = new 
>>> BufferProgramSource(program_buffer);
>>> Protected parser = new LanguageParser(name, 
>>> programSource);
>>> return parser->generateMethod(sourceContext);
>>> }
>>>
>>> Hence it would be possible to pass the sourceContext as the third arguemtn 
>>> via the new method
>>> MethodClass::restore() to ProgramMetaData::restoreMethod(...). But then, 
>>> how can I set the scope
>>> from the sourceContext which is a PackageClass, bet MethodClass::setScope 
>>> expects a RexxClass?
>>>
>>> ---rony
>>>
>>> P.S.: Here the Rexx test script that generates the above runtime error:
>>>
>>> fnames="testmethod.rex", "testmethod-compiled.rex", 
>>> "testmethod-compiled-encoded.rex"
>>> say "testing routine code from external files:"
>>> do fn over fnames
>>>o=.routine~newFile(fn)
>>>say .context~name", return value:" o[1,2,3]
>>>say
>>> end
>>>
>>> say ""
>>>
>>> say "testing method code from external files:"
>>> do fn over fnames
>>>o=.test~new~~addMethod("aha", .method~newFile(fn))
>>>say .context~name", return value:" o~aha(1,2,3)/* <--- line # 15 
>>> */
>>>say
>>> end
>>>
>>>
>>> ::class test
>>> ::method addMethod
>>>   use strict arg name, method
>>>   self~setmethod(name, method, "object")
>>>
>>> Here the three external files:
>>>
>>> testmethod-compiled.rex ... copmiled with rexxc
>>> testmethod-compiled-encoded.rex  ... compiled with the "/e" switch of 
>>> rexxc.exe
>>> testmethod.rex ... 

Re: [Oorexx-devel] Question ad setting scope of a MethodClass object

[Rony G. Flatscher]

O.K., I think I found a solution that works, will post the changes as a patch 
with a new bug tracker
item.

---rony


On 06.08.2020 14:03, Rony G. Flatscher wrote:
>
> Attached please find the patch that makes method's newFile work with compiled 
> Rexx scripts, but
> has a problem at runtime when trying to invoke a method that got restored 
> from the compiled form.
>
> ---rony
>
>
> On 06.08.2020 13:54, Rony G. Flatscher wrote:
>>
>> As a first step I have been trying to correct the code to accept compiled 
>> Rexx scripts as method
>> code (using the .method's newFile).
>>
>> This seems to have been successful, decoding now works.
>>
>> However, when assigning the method object to a class and then sending an 
>> object of that class the
>> message to execute the method, I get the runtime error message (Rexx test 
>> script at the end):
>>
>> 15 *-*   say .context~name", return value:" o~aha(1,2,3)
>> Error 97 running G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\testrgf.rex 
>> line 15:  Object method not found.
>> Error 97.3:  Object "a TEST" cannot accept package scope message "AHA" 
>> from a different package caller.
>>
>> The compiled Rexx code for the method gets successfully processed in a new 
>> method defined in
>> ProgramMetaData.cpp:
>>
>> MethodClass *ProgramMetaData::restoreMethod(RexxString *name, 
>> BufferClass *buffer)
>> {
>> ProgramMetaData *metaData;
>>
>> // check to see if this is already translated
>> if (!processRestoreData(name, buffer, metaData))
>> {
>> // nope, can't restore this
>> return OREF_NULL;
>> }
>>
>> // make sure this is valid for interpreter
>> if (!metaData->validate(name))
>> {
>> return OREF_NULL;
>> }
>>
>> // this should be valid...try to restore.
>> Protected method = MethodClass::restore(buffer, 
>> metaData->getImageData(), metaData->getImageSize());
>> // change the program name to match the file this was restored from
>> method->getPackageObject()->setProgramName(name);
>> return method;
>> }
>>
>> The question is, how can I inhibit the runtime error 97.3, what do I need to 
>> do to the method
>> object?
>>
>> The starting point is in LanguageParser the new method:
>>
>> MethodClass* LanguageParser::createMethod(RexxString *name, PackageClass 
>> *sourceContext)
>> {
>> // load the file into a buffer
>> Protected program_buffer = 
>> FileProgramSource::readProgram(name->getStringData());
>> // if this failed, report an error now.
>> if (program_buffer == (BufferClass *)OREF_NULL)
>> {
>> reportException(Error_Program_unreadable_name, name);
>> }
>>
>> // try to restore a flattened program first
>> Protected method = MethodClass::restore(name, 
>> program_buffer);
>> if (method != (MethodClass *)OREF_NULL)
>> {
>>
>> return method;
>> }
>>
>> // create the appropriate program source, then the parser, then 
>> generate the
>> // code.
>> Protected programSource = new 
>> BufferProgramSource(program_buffer);
>> Protected parser = new LanguageParser(name, 
>> programSource);
>> return parser->generateMethod(sourceContext);
>> }
>>
>> Hence it would be possible to pass the sourceContext as the third arguemtn 
>> via the new method
>> MethodClass::restore() to ProgramMetaData::restoreMethod(...). But then, how 
>> can I set the scope
>> from the sourceContext which is a PackageClass, bet MethodClass::setScope 
>> expects a RexxClass?
>>
>> ---rony
>>
>> P.S.: Here the Rexx test script that generates the above runtime error:
>>
>> fnames="testmethod.rex", "testmethod-compiled.rex", 
>> "testmethod-compiled-encoded.rex"
>> say "testing routine code from external files:"
>> do fn over fnames
>>o=.routine~newFile(fn)
>>say .context~name", return value:" o[1,2,3]
>>say
>> end
>>
>> say ""
>>
>> say "testing method code from external files:"
>> do fn over fnames
>>o=.test~new~~addMethod("aha", .method~newFile(fn))
>>say .context~name", return value:" o~aha(1,2,3)/* <--- line # 15 
>> */
>>say
>> end
>>
>>
>> ::class test
>> ::method addMethod
>>   use strict arg name, method
>>   self~setmethod(name, method, "object")
>>
>> Here the three external files:
>>
>> testmethod-compiled.rex ... copmiled with rexxc
>> testmethod-compiled-encoded.rex  ... compiled with the "/e" switch of 
>> rexxc.exe
>> testmethod.rex ... source code:
>>
>> parse source s
>> say .dateTime~new": number of args:" arg()
>> say .dateTime~new": args  :" arg(1,'A')~toString(,",")
>> say .dateTime~new": parse source  :" s
>> say .dateTime~new": .context~name :" .context~name
>> 

Re: [Oorexx-devel] Question ad setting scope of a MethodClass object

[Rony G. Flatscher]

Attached please find the patch that makes method's newFile work with compiled 
Rexx scripts, but has
a problem at runtime when trying to invoke a method that got restored from the 
compiled form.

---rony


On 06.08.2020 13:54, Rony G. Flatscher wrote:
>
> As a first step I have been trying to correct the code to accept compiled 
> Rexx scripts as method
> code (using the .method's newFile).
>
> This seems to have been successful, decoding now works.
>
> However, when assigning the method object to a class and then sending an 
> object of that class the
> message to execute the method, I get the runtime error message (Rexx test 
> script at the end):
>
> 15 *-*   say .context~name", return value:" o~aha(1,2,3)
> Error 97 running G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin\testrgf.rex 
> line 15:  Object method not found.
> Error 97.3:  Object "a TEST" cannot accept package scope message "AHA" 
> from a different package caller.
>
> The compiled Rexx code for the method gets successfully processed in a new 
> method defined in
> ProgramMetaData.cpp:
>
> MethodClass *ProgramMetaData::restoreMethod(RexxString *name, BufferClass 
> *buffer)
> {
> ProgramMetaData *metaData;
>
> // check to see if this is already translated
> if (!processRestoreData(name, buffer, metaData))
> {
> // nope, can't restore this
> return OREF_NULL;
> }
>
> // make sure this is valid for interpreter
> if (!metaData->validate(name))
> {
> return OREF_NULL;
> }
>
> // this should be valid...try to restore.
> Protected method = MethodClass::restore(buffer, 
> metaData->getImageData(), metaData->getImageSize());
> // change the program name to match the file this was restored from
> method->getPackageObject()->setProgramName(name);
> return method;
> }
>
> The question is, how can I inhibit the runtime error 97.3, what do I need to 
> do to the method object?
>
> The starting point is in LanguageParser the new method:
>
> MethodClass* LanguageParser::createMethod(RexxString *name, PackageClass 
> *sourceContext)
> {
> // load the file into a buffer
> Protected program_buffer = 
> FileProgramSource::readProgram(name->getStringData());
> // if this failed, report an error now.
> if (program_buffer == (BufferClass *)OREF_NULL)
> {
> reportException(Error_Program_unreadable_name, name);
> }
>
> // try to restore a flattened program first
> Protected method = MethodClass::restore(name, 
> program_buffer);
> if (method != (MethodClass *)OREF_NULL)
> {
>
> return method;
> }
>
> // create the appropriate program source, then the parser, then 
> generate the
> // code.
> Protected programSource = new 
> BufferProgramSource(program_buffer);
> Protected parser = new LanguageParser(name, 
> programSource);
> return parser->generateMethod(sourceContext);
> }
>
> Hence it would be possible to pass the sourceContext as the third arguemtn 
> via the new method
> MethodClass::restore() to ProgramMetaData::restoreMethod(...). But then, how 
> can I set the scope
> from the sourceContext which is a PackageClass, bet MethodClass::setScope 
> expects a RexxClass?
>
> ---rony
>
> P.S.: Here the Rexx test script that generates the above runtime error:
>
> fnames="testmethod.rex", "testmethod-compiled.rex", 
> "testmethod-compiled-encoded.rex"
> say "testing routine code from external files:"
> do fn over fnames
>o=.routine~newFile(fn)
>say .context~name", return value:" o[1,2,3]
>say
> end
>
> say ""
>
> say "testing method code from external files:"
> do fn over fnames
>o=.test~new~~addMethod("aha", .method~newFile(fn))
>say .context~name", return value:" o~aha(1,2,3)/* <--- line # 15 */
>say
> end
>
>
> ::class test
> ::method addMethod
>   use strict arg name, method
>   self~setmethod(name, method, "object")
>
> Here the three external files:
>
> testmethod-compiled.rex ... copmiled with rexxc
> testmethod-compiled-encoded.rex  ... compiled with the "/e" switch of 
> rexxc.exe
> testmethod.rex ... source code:
>
> parse source s
> say .dateTime~new": number of args:" arg()
> say .dateTime~new": args  :" arg(1,'A')~toString(,",")
> say .dateTime~new": parse source  :" s
> say .dateTime~new": .context~name :" .context~name
> return .dateTime~new
>
> Here the output of running the above test script including the runtime error:
>
> G:\oorexx.tmp\oorexxBuild\debug32.trunk\bin>rexx testrgf.rex
> testing routine code from external files:
> 2020-08-06T13:53:14.998000: number of args: 3
> 2020-08-06T13:53:14.998000: args  

Re: [Oorexx-devel] Question ad supporting 32-bit Linux

[Michael Lueck]

Greetings Rony,

Rony G. Flatscher wrote:


Should we still support 32-bit Linux at all?



Ubuntu dropped 32-bit at LTS version 16.04. That is only supported through next 
April, I believe.

Drop 32-bit +1 vote here.

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


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

Re: [Oorexx-devel] Question ad supporting 32-bit Linux

[P.O. Jonsson]

Dear Rony,

I think the Raspberry Pi is actually running 32 bit Linux.

(Sorry for the slow response, I am on holiday)

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




> Am 29.07.2020 um 18:58 schrieb Rony G. Flatscher :
> 
> Just noticed that we do not have 32-bit Linux builds for the latest ooRexx 
> trunk code (looked up
> Jenkins and the ooRexx beta download area).
> 
> Should we still support 32-bit Linux at all?
> 
> ---rony
> 
> 
> 
> 
> ___
> 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

Re: [Oorexx-devel] Question ad CMakeLists.txt (ooRexx 5 version numbers in the library name on Unix (Linux and MacOS) breaks long established Rexx convention)

[Rick McGuire]

I just checked, the only new entry points in rexx.dll are internal use only
ones required by different interpreter components. There are no new
"official" APIs introduced. The version can reasonable left at the 4 level.

Rick

On Sun, Jul 26, 2020 at 10:31 AM Rick McGuire  wrote:

> I guess the real problem is that we are inappropriately tying the uses of
> the library version to the release version. The purpose here is to allow
> linking to a version that contains the entry points required by your
> program. The links to the older versions are created because the new
> version is upward compatible to the old version, so, for example, a version
> 5 library will work with programs linked to version 4 of the same library.
> A new release of the interpreter does not warrant automatically bumping the
> library version, unless the library also contains new entry points that
> implement new APIs. I had a similar problem with the context APIs. The API
> version is not tied to the interpreter release number, but is only
> incremented when a new API is added to a given context vector. The
> different context APIs (thread, method, routine, etc.) each carries its own
> version identifier.
>
> So what is needed here is an API level identifier. The past version was
> not necessarily broken, because I'm not sure any new entry points were
> introduced between 4.0 and 4.2. I'd have to go double check, but I'm not
> sure that any new ones are being introduced in 5.0.0, which would argue
> that it should be left a the 4 level.
>
> Rick
>
> On Sun, Jul 26, 2020 at 9:48 AM Rony G. Flatscher 
> wrote:
>
>> On 26.07.2020 14:11, Rick McGuire wrote:
>> > The only reservation I have is that new APIs can get introduced in
>> minor releases as well as major
>> > releases. As such, wouldn't it be better if "5.0" were used? A library
>> for a 5.1 release might
>> > contain APIs that a 5.0 release does not. The old convention was
>> probably an error.
>>
>> It seems that you foresee situations with ooRexx that warrant at least
>> ORX_MINOR to be used, even
>> worse, you view the old convention to be in error!
>>
>> In that case it would not make sense to simplify the so version number
>> for ooRexx 5.0 to only use
>> ORX_MAJOR then and the question is whether it makes sense to change the
>> current setting of
>> ORX_VERSION at all then!
>> :)
>>
>> ---rony
>>
>>
>>
>> ___
>> 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

Re: [Oorexx-devel] Question ad CMakeLists.txt (ooRexx 5 version numbers in the library name on Unix (Linux and MacOS) breaks long established Rexx convention)

[Rony G. Flatscher]

On 26.07.2020 14:11, Rick McGuire wrote:
> The only reservation I have is that new APIs can get introduced in minor 
> releases as well as major
> releases. As such, wouldn't it be better if "5.0" were used? A library for a 
> 5.1 release might
> contain APIs that a 5.0 release does not. The old convention was probably an 
> error.

It seems that you foresee situations with ooRexx that warrant at least 
ORX_MINOR to be used, even
worse, you view the old convention to be in error!

In that case it would not make sense to simplify the so version number for 
ooRexx 5.0 to only use
ORX_MAJOR then and the question is whether it makes sense to change the current 
setting of
ORX_VERSION at all then!
:)

---rony



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

Re: [Oorexx-devel] Question ad CMakeLists.txt (ooRexx 5 version numbers in the library name on Unix (Linux and MacOS) breaks long established Rexx convention)

[Rick McGuire]

The only reservation I have is that new APIs can get introduced in minor
releases as well as major releases. As such, wouldn't it be better if "5.0"
were used? A library for a 5.1 release might contain APIs that a 5.0
release does not. The old convention was probably an error.

Note that "new APIs" in this sense only applies to new entry points added
to the libraries. APIs added to the context vectors are a different
mechanism and shouldn't cause problems.

Rick

On Sun, Jul 26, 2020 at 7:50 AM Rony G. Flatscher 
wrote:

> On 25.07.2020 20:10, Rony G. Flatscher wrote:
>
> On 25.07.2020 18:57, Rony G. Flatscher wrote:
>
> The library names of the Unix (Linux and Mac) versions of ooRexx added
> links to support earlier ooRexx versions in the form
>
>- Linux
>   - "lib" name ".so.${ORX_MAJOR}", e.g.
>  - librexx.so -> librexx.so.3
>  librexx.so -> librexx.so.4
>  
>  - librexxapi.so -> librexxapi.so.3
>  librexxapi.so -> librexxapi.so.4
>  ...
>
>  - MacOS
>   - "lib" name ".${ORX_MAJOR}.dylib", e.g.
>  - librexx.dylib -> librexx.3.dylib
>  librexx.dylib -> librexx.4.dylib
>  ...
>  - librexxapi.dylib -> librexxapi.3.dylib
>  librexxapi.dylib -> librexxapi.4.dylib
>  ...
>
> The version number in the current ooRexx 5.0 beta on Unix (Linux, MacOS)
> use in addition to ${ORX_MAJOR} the subnumbers ${ORX_MINOR}.${ORX_MOD_LVL,
> thereby unnecessarily breaking the naming system, e.g.:
>
>- Linux
>   - "lib" name ".so.${ORX_MAJOR}", e.g.
>  - librexx.so -> librexx.so.3
>  librexx.so -> librexx.so.4
>  librexx.so -> librexx.so.5.0.0
>  
>  - librexxapi.so -> librexxapi.so.3
>  librexxapi.so -> librexxapi.so.4
>  librexxapi.so -> librexxapi.so.5.0.0
>  ...
>
>  - MacOS
>   - "lib" name ".${ORX_MAJOR}.dylib", e.g.
>  - librexx.dylib -> librexx.3.dylib
>  librexx.dylib -> librexx.4.dylib
>  librexx.dylib -> librexx.5.0.0.dylib
>  ...
>  - librexxapi.dylib -> librexxapi.3.dylib
>  librexxapi.dylib -> librexxapi.4.dylib
>  librexxapi.dylib -> librexxapi.5.0.0.dylib
>  ...
>
> Suggesting to changing the versioned library names of ooRexx 5 to match
> the established convention (using only ${ORX_MAJOR}).
>
> Are there any objections to such a change?
>
> ---
>
> If not, where does "CMAKE_SHARED_LIBRARY_PREFIX" get set (which gets used
> for setting "ORX_SHARED_LIBRARY_EXT")?
>
> It seems that the above two variables play no role in the version string
> for the link file names. Rather the usage of "set_target_properties(libname
> PROPERTIES VERSION ${ORX_VERSION})" for each "libname" defines the version
> string to use [1]. So probably using "${ORX_MAJOR}" instead of
> "${ORX_VERSION}" would make the version string in the link names to consist
> of "5" only.
>
> ---rony
>
> [1] Search for "VERSION" in:
> 
>  to
> yield:
>
> "... For shared libraries VERSION and SOVERSION can be used to specify the
> build version and API version respectively. When building or installing
> appropriate symlinks are created if the platform supports symlinks and the
> linker supports so-names. If only one of both is specified the missing is
> assumed to have the same version number. For executables VERSION can be
> used to specify the build version. When building or installing appropriate
> symlinks are created if the platform supports symlinks. For shared
> libraries and executables on Windows the VERSION attribute is parsed to
> extract a “major.minor” version number. These numbers are used as the image
> version of the binary. ...".
>
> What the enclosed patch does to "CMakeLists.txt" (tested on Ubuntu):
>
>- changes the variable name in "set_target_properties" for library
>version from "VERSION" to "SOVERSION", which will self-document the purpose
>of that property (cf. [1] above),
>- changes the value from "${ORX_VERSION}" (i.e. "5.0.0") to
>"${ORX_MAJOR}" (i.e. "5")
>
> If there are  no objections I will check-in that patch.
>
> ---rony
>
>
> ___
> 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

Re: [Oorexx-devel] Question ad CMakeLists.txt (ooRexx 5 version numbers in the library name on Unix (Linux and MacOS) breaks long established Rexx convention)

[Rony G. Flatscher]

On 25.07.2020 20:10, Rony G. Flatscher wrote:
> On 25.07.2020 18:57, Rony G. Flatscher wrote:
>>
>> The library names of the Unix (Linux and Mac) versions of ooRexx added links 
>> to support earlier
>> ooRexx versions in the form
>>
>>   * Linux
>>   o "lib" name ".so.${ORX_MAJOR}", e.g.
>>   + librexx.so -> librexx.so.3
>> librexx.so -> librexx.so.4
>> 
>>   + librexxapi.so -> librexxapi.so.3
>> librexxapi.so -> librexxapi.so.4
>> ...
>>
>>   * MacOS
>>   o "lib" name ".${ORX_MAJOR}.dylib", e.g.
>>   + librexx.dylib -> librexx.3.dylib
>> librexx.dylib -> librexx.4.dylib
>> ...
>>   + librexxapi.dylib -> librexxapi.3.dylib
>> librexxapi.dylib -> librexxapi.4.dylib
>> ...
>>
>> The version number in the current ooRexx 5.0 beta on Unix (Linux, MacOS) use 
>> in addition to
>> ${ORX_MAJOR} the subnumbers ${ORX_MINOR}.${ORX_MOD_LVL, thereby 
>> unnecessarily breaking the naming
>> system, e.g.:
>>
>>   * Linux
>>   o "lib" name ".so.${ORX_MAJOR}", e.g.
>>   + librexx.so -> librexx.so.3
>> librexx.so -> librexx.so.4
>> librexx.so -> librexx.so.5.0.0
>> 
>>   + librexxapi.so -> librexxapi.so.3
>> librexxapi.so -> librexxapi.so.4
>> librexxapi.so -> librexxapi.so.5.0.0
>> ...
>>
>>   * MacOS
>>   o "lib" name ".${ORX_MAJOR}.dylib", e.g.
>>   + librexx.dylib -> librexx.3.dylib
>> librexx.dylib -> librexx.4.dylib
>> librexx.dylib -> librexx.5.0.0.dylib
>> ...
>>   + librexxapi.dylib -> librexxapi.3.dylib
>> librexxapi.dylib -> librexxapi.4.dylib
>> librexxapi.dylib -> librexxapi.5.0.0.dylib
>> ...
>>
>> Suggesting to changing the versioned library names of ooRexx 5 to match the 
>> established
>> convention (using only ${ORX_MAJOR}).
>>
>> Are there any objections to such a change?
>>
>> ---
>>
>> If not, where does "CMAKE_SHARED_LIBRARY_PREFIX" get set (which gets used 
>> for setting
>> "ORX_SHARED_LIBRARY_EXT")?
>>
> It seems that the above two variables play no role in the version string for 
> the link file names.
> Rather the usage of "set_target_properties(libname PROPERTIES VERSION 
> ${ORX_VERSION})" for each
> "libname" defines the version string to use [1]. So probably using 
> "${ORX_MAJOR}" instead of
> "${ORX_VERSION}" would make the version string in the link names to consist 
> of "5" only.
>
> ---rony
>
> [1] Search for "VERSION" in:
>  to 
> yield:
>
> "... For shared libraries VERSION and SOVERSION can be used to specify 
> the build version and
> API version respectively. When building or installing appropriate 
> symlinks are created if the
> platform supports symlinks and the linker supports so-names. If only one 
> of both is specified
> the missing is assumed to have the same version number. For executables 
> VERSION can be used to
> specify the build version. When building or installing appropriate 
> symlinks are created if the
> platform supports symlinks. For shared libraries and executables on 
> Windows the VERSION
> attribute is parsed to extract a “major.minor” version number. These 
> numbers are used as the
> image version of the binary. ...".
>
What the enclosed patch does to "CMakeLists.txt" (tested on Ubuntu):

  * changes the variable name in "set_target_properties" for library version 
from "VERSION" to
"SOVERSION", which will self-document the purpose of that property (cf. [1] 
above),
  * changes the value from "${ORX_VERSION}" (i.e. "5.0.0") to "${ORX_MAJOR}" 
(i.e. "5")

If there are  no objections I will check-in that patch.

---rony


Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 12100)
+++ CMakeLists.txt  (working copy)
@@ -668,7 +668,7 @@
 install(TARGETS rexxapi RUNTIME DESTINATION ${INSTALL_LIB_DIR} COMPONENT Core
 LIBRARY DESTINATION ${INSTALL_LIB_DIR} COMPONENT Core
 ARCHIVE DESTINATION ${INSTALL_INCLUDE_DIR} COMPONENT 
DevLib)
-set_target_properties(rexxapi PROPERTIES VERSION ${ORX_VERSION})
+set_target_properties(rexxapi PROPERTIES SOVERSION ${ORX_MAJOR})
 create_install_symlink(rexxapi)
 
  librexx.so ##
@@ -953,7 +953,7 @@
 install(TARGETS rexx RUNTIME DESTINATION ${INSTALL_LIB_DIR} COMPONENT Core
  LIBRARY DESTINATION ${INSTALL_LIB_DIR} COMPONENT Core
  ARCHIVE DESTINATION ${INSTALL_INCLUDE_DIR} COMPONENT 
DevLib)
-set_target_properties(rexx PROPERTIES VERSION ${ORX_VERSION})
+set_target_properties(rexx PROPERTIES SOVERSION ${ORX_MAJOR})
 create_install_symlink(rexx)
 
  orexx (executable) 

Re: [Oorexx-devel] Question ad CMakeLists.txt (ooRexx 5 version numbers in the library name on Unix (Linux and MacOS) breaks long established Rexx convention)

[Rony G. Flatscher]

On 25.07.2020 18:57, Rony G. Flatscher wrote:
>
> The library names of the Unix (Linux and Mac) versions of ooRexx added links 
> to support earlier
> ooRexx versions in the form
>
>   * Linux
>   o "lib" name ".so.${ORX_MAJOR}", e.g.
>   + librexx.so -> librexx.so.3
> librexx.so -> librexx.so.4
> 
>   + librexxapi.so -> librexxapi.so.3
> librexxapi.so -> librexxapi.so.4
> ...
>
>   * MacOS
>   o "lib" name ".${ORX_MAJOR}.dylib", e.g.
>   + librexx.dylib -> librexx.3.dylib
> librexx.dylib -> librexx.4.dylib
> ...
>   + librexxapi.dylib -> librexxapi.3.dylib
> librexxapi.dylib -> librexxapi.4.dylib
> ...
>
> The version number in the current ooRexx 5.0 beta on Unix (Linux, MacOS) use 
> in addition to
> ${ORX_MAJOR} the subnumbers ${ORX_MINOR}.${ORX_MOD_LVL, thereby unnecessarily 
> breaking the naming
> system, e.g.:
>
>   * Linux
>   o "lib" name ".so.${ORX_MAJOR}", e.g.
>   + librexx.so -> librexx.so.3
> librexx.so -> librexx.so.4
> librexx.so -> librexx.so.5.0.0
> 
>   + librexxapi.so -> librexxapi.so.3
> librexxapi.so -> librexxapi.so.4
> librexxapi.so -> librexxapi.so.5.0.0
> ...
>
>   * MacOS
>   o "lib" name ".${ORX_MAJOR}.dylib", e.g.
>   + librexx.dylib -> librexx.3.dylib
> librexx.dylib -> librexx.4.dylib
> librexx.dylib -> librexx.5.0.0.dylib
> ...
>   + librexxapi.dylib -> librexxapi.3.dylib
> librexxapi.dylib -> librexxapi.4.dylib
> librexxapi.dylib -> librexxapi.5.0.0.dylib
> ...
>
> Suggesting to changing the versioned library names of ooRexx 5 to match the 
> established convention
> (using only ${ORX_MAJOR}).
>
> Are there any objections to such a change?
>
> ---
>
> If not, where does "CMAKE_SHARED_LIBRARY_PREFIX" get set (which gets used for 
> setting
> "ORX_SHARED_LIBRARY_EXT")?
>
It seems that the above two variables play no role in the version string for 
the link file names.
Rather the usage of "set_target_properties(libname PROPERTIES VERSION 
${ORX_VERSION})" for each
"libname" defines the version string to use [1]. So probably using 
"${ORX_MAJOR}" instead of
"${ORX_VERSION}" would make the version string in the link names to consist of 
"5" only.

---rony

[1] Search for "VERSION" in: 

to yield:

"... For shared libraries VERSION and SOVERSION can be used to specify the 
build version and API
version respectively. When building or installing appropriate symlinks are 
created if the
platform supports symlinks and the linker supports so-names. If only one of 
both is specified
the missing is assumed to have the same version number. For executables 
VERSION can be used to
specify the build version. When building or installing appropriate symlinks 
are created if the
platform supports symlinks. For shared libraries and executables on Windows 
the VERSION
attribute is parsed to extract a “major.minor” version number. These 
numbers are used as the
image version of the binary. ...".


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

Re: [Oorexx-devel] Question ad package's local

[Rick McGuire]

One advantage of a directory is the ability to set an entry to a method so
that you can have code executed on lookup. This ability makes as much sense
for the package local as it does for .environment and .local.

Rick

On Thu, May 21, 2020 at 8:09 AM Rony G. Flatscher 
wrote:

> In ooRexx 5.0 there is a package local directory of type .Directory:
>
> G:\test\oorexx\wopi>rexx -e "say .context~package~local"
> a Directory
>
> AFAIR the new class .StringTable was intended as a faster replacement for
> .Directory, which may be slower as it is possible that methods get stored
> with it. So why is it that package's local is not of type StringTable, but
> of type Directory?
>
> ---rony
> ___
> 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

Re: [Oorexx-devel] Question on documentation, Rexxref, 8.74. SysTempFileName

[P.O. Jonsson]

Hello Erich,

I now have a testGroup for SysTempFileName, I could do 9 tests, 54 assertions 
that I could think ok. Tested on macOS, Win 10 and some 6 different Linux 
dialects.

However while modifying the text for this section in rexxref it just occurred 
to me that I had not tested with MORE than five filter chars, so I did this 
test:

rexx -e 'say SysTempFileName("MYEXEC?.txt")'
/Users/po/Downloads/MYEXEC74279.txt
rexx -e 'say SysTempFileName("MYEXEC??.txt")'
/Users/po/Downloads/MYEXEC185889.txt
rexx -e 'say SysTempFileName("MYEXEC???.txt")'
/Users/po/Downloads/MYEXEC4515095.txt
rexx -e 'say SysTempFileName("MYEXEC.txt")'
/Users/po/Downloads/MYEXEC35976017.txt
rexx -e 'say SysTempFileName("MYEXEC?.txt")'
/Users/po/Downloads/MYEXEC586659121.txt
rexx -e 'say SysTempFileName("MYEXEC??.txt")'
(the empty string)

Is it correct that you can now use up to nine filter characters on all 
platforms, and that you receive the empty string if you use more? It used to be 
five according to the docs.

How do you want the test group, should I send it by mail ?

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



> Am 23.03.2020 um 08:13 schrieb Erich Steinböck :
> 
> Hi P.O.,
> yes, SysTempFileName is expected to now work identically on all platforms.
> Providing a test case would be great
> ___
> 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

Re: [Oorexx-devel] Question on documentation, Rexxref, 8.74. SysTempFileName

[Erich Steinböck]

Hi P.O.,
yes, SysTempFileName is expected to now work identically on all platforms.
Providing a test case would be great
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question on documentation, Rexxref, 8.74. SysTempFileName

[P.O. Jonsson]

Dear Gil,

I guess running it on all platforms once does not qualify for a test :-). I´ll 
leave it to someone with more insight to do it then, or are you telling me I 
should write a test case for it? I can do that. 

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



> Am 22.03.2020 um 21:39 schrieb Gil Barmwater :
> 
> P.O.,
> 
> See RFE #745; the last comment says that the tests and doc updates are still 
> to be done.
> Gil
> On 3/22/2020 11:18 AM, P.O. Jonsson wrote:
>> Dear developers,
>> 
>> SysTempFileName now works differently (read: better) compared to ooRexx 4 
>> for Linux/macOS and I wanted to amend the documentation accordingly. 
>> 
>> From what I can see from using SysTempFileName() it behaves exactly the same 
>> for all platforms, Is this correctly understood, or is there a difference 
>> that I have not spotted?
>> 
>> If there is indeed no difference I will remove the separate sections for 
>> Win/Linux and amend the code snippet accordingly.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>> 
> -- 
> Gil Barmwater
> ___
> 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

Re: [Oorexx-devel] Question on documentation, Rexxref, 8.74. SysTempFileName

[Gil Barmwater]

P.O.,

See RFE #745; the last comment says that the tests and doc updates are 
still to be done.


Gil

On 3/22/2020 11:18 AM, P.O. Jonsson wrote:

Dear developers,

SysTempFileName now works differently (read: better) compared to 
ooRexx 4 for Linux/macOS and I wanted to amend the documentation 
accordingly.


From what I can see from using SysTempFileName() it behaves exactly 
the same for all platforms, Is this correctly understood, or is there 
a difference that I have not spotted?


If there is indeed no difference I will remove the separate sections 
for Win/Linux and amend the code snippet accordingly.


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


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


--
Gil Barmwater

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

Re: [Oorexx-devel] Question ad .rexxinfo and CLS-samples ...

[René Jansen]

Thanks for pointing that out. The NetRexx discussion was about product release 
number, i.e. the number that the translator tells you in the logo. The code 
states ‘language level’ indeed, but as far as I can go back this was never 
different from the product release level. (It was a product only for a short 
time, I think from VM/ESA 2.3 to z/VM 5.1).

> On 15 Mar 2020, at 13:45, Rick McGuire  wrote:
> 
> That is the language level, not a product release level. ooRexx also has a 
> language level that is decimal in form, but that is only updated when there 
> is a change to the language handled by the interpreter. Bug fixes would never 
> bump that, nor would new class libraries.
> 
> Rick
> 
> On Sun, Mar 15, 2020 at 8:42 AM René Jansen  > wrote:
> Not that I am really interested in this, but for your information: CMS and 
> TSO Rexx traditionally has had a decimal version number: 3.40, 3.48. 4.02.
> This is without reason: its inventor is more involved with decimal arithmetic 
> than the man in the street. There was a semi-heated discussion in the NetRexx 
> architecture board some years ago where Mike Cowlishaw did not budge. Out of 
> respect for him I kept the NetRexx numbering like this; NetRexx 3.09 will be 
> released very soon.
> 
> The argument is that decimal version numbers can be easily compared. IBM 
> never changed this for mainframe Rexx.
> 
> best regards,
> 
> René.
> 

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

Re: [Oorexx-devel] Question ad .rexxinfo and CLS-samples ...

[Enrico Sorichetti via Oorexx-devel]

Probably that’ the reason why on zOS


Parse version v
Say v

Reports

REXX370 3.48 01 May 1992


Disregarding the Version whatever of the product ( TSO extensions ) 
Which delivers the rexx interpreter 


E

> On 15 Mar 2020, at 13:45, Rick McGuire  wrote:
> 
> That is the language level, not a product release level. ooRexx also has a 
> language level that is decimal in form, but that is only updated when there 
> is a change to the language handled by the interpreter. Bug fixes would never 
> bump that, nor would new class libraries.

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

Re: [Oorexx-devel] Question ad .rexxinfo and CLS-samples ...

[Rick McGuire]

That is the language level, not a product release level. ooRexx also has a
language level that is decimal in form, but that is only updated when there
is a change to the language handled by the interpreter. Bug fixes would
never bump that, nor would new class libraries.

Rick

On Sun, Mar 15, 2020 at 8:42 AM René Jansen  wrote:

> Not that I am really interested in this, but for your information: CMS and
> TSO Rexx traditionally has had a decimal version number: 3.40, 3.48. 4.02.
> This is without reason: its inventor is more involved with decimal
> arithmetic than the man in the street. There was a semi-heated discussion
> in the NetRexx architecture board some years ago where Mike Cowlishaw did
> not budge. Out of respect for him I kept the NetRexx numbering like this;
> NetRexx 3.09 will be released very soon.
>
> The argument is that decimal version numbers can be easily compared. IBM
> never changed this for mainframe Rexx.
>
> best regards,
>
> René.
>
> On 15 Mar 2020, at 13:19, Rony G. Flatscher 
> wrote:
>
>
> On 14.03.2020 21:51, Enrico Sorichetti via Oorexx-devel wrote:
>
> There is a clash in the  nomenclature used by IBM software development
> And the one used in the *ix word
>
> The IBM terminology is explained here
>
> https://www.ibm.com/support/pages/vrmf-maintenance-stream-delivery-vehicle-terminology-explanation
>
>
> Wow, very helpful, thank you very much Enrico!
>
> On the other side the *ix is a bit murkier due also to the confusion about
> library versioning
>
> The terms used by CMAKE are
>
> PROJECT_VERSION
> PROJECT_VERSION_MAJOR
> PROJECT_VERSION_MINOR
> PROJECT_VERSION_PATCH
> PROJECT_VERSION_TWEAK
>
>
> ___
> 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