Re: [Oorexx-devel] Problem with make string.rex sample under Windows

2019-10-02 Thread Rony G. Flatscher
On 02.10.2019 13:54, P. O. Jonsson wrote:
> Thanks for clarifying Rony, should I file a bug report?

Probably a good idea, such that it does not get overlooked.

---rony




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


Re: [Oorexx-devel] Problem with make string.rex sample under Windows

2019-10-02 Thread Rony G. Flatscher
Jeremy,

it is a problem with "samples\makestring.rex".

Running it on a Windows 7 machine yields:

C:\Program Files (x86)\ooRexx\samples>*makestring.rex*
Unable to create test file :  
C:\Users\ADMINI~1\AppData\Local\Temp\C:\Program Files 
(x86)\ooRexx\samples\tst_input.528

So the user's temporary directory location gets concatenated with the fully 
qualified path to the
temporary file.

The Rexx code up to that point looks like (starting with line # 62 after the 
comments and the
routine starting at line # 225):

--creating temporary input and output file

*file_name_in = getTempFileName('tst_input.???')*
file_name_out = getTempFileName('tst_output.???')
file_in = .stream~new(file_name_in)
file_out = .stream~new(file_name_out)

if file_in~open \= "READY:" then do
say "Unable to create test file : " file_name_in
exit
end

... cut ...

::routine getTempFileName
  use strict arg template

  fileName = SysTempFileName(template)
  parse upper source os .

  -- Add code for other operating systems here if needed.
  select
when os~abbrev(WIN) then do
  tempDir = value("TEMP", , "ENVIRONMENT")
  if tempDir == "" then tempDir = value("TMP", , "ENVIRONMENT")
  if tempDir == "" then leave  -- Give up.

  if tempDir~right(1) \== '\' then tempDir = tempDir'\'
  fileName = tempDir || fileName
end
otherwise
  nop
  end

return fileName

SysTempFileName() returns a fully qualified path to the temporary file which 
gets appended to the
temporary directory on Windows only.

Removing the entire select statement (looks awkward anyway as only one 
WHEN-branch is there) solves
the problem on Windows.

---rony


On 02.10.2019 11:59, Jeremy Nicoll wrote:
> On Tue, 1 Oct 2019, at 22:02, P.O. Jonsson wrote:
>
>> Launching makestring.rex from the home directory (if that what it is 
>> called on Win) works
> C:\Users
>
> isn't a home directory.  Indeed it's not a usual place for a Windows user
> to be at all.  If a user is in that sort of place you'd expect them to be 
> looking at their own files eg at 
>
> C:\Users\myusername
>
>
>> But launching it from anywhere else fails:
>>
>> C:\>rexx makestring.rex
>> Unable to create test file : C:\Users\po\AppData\Local\Temp\C:\tst_input.954
> You've got two complete filenames concatenated there.
>
> The "C:\tst_input.954"  part is not valid on the end of the earlier bit, 
> because ":"
> is only valid as the second character of a filepath, immediately after a disk 
> letter.

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


Re: [Oorexx-devel] ooSQLite Blob handling

2019-09-09 Thread Rony G. Flatscher
On 07.09.2019 14:22, Rony G. Flatscher wrote:
> On 06.09.2019 18:35, Erich Steinböck wrote:
>> To be able answer Paul Higgins' recent question regarding retrieval of BLOB 
>> data, I checked
>> ooSqlite's BLOB handling - see incubator/ooSQLite.
>>
>> It seems that ooSQLite will return BLOBs as ooRexx Buffer objects only. This 
>> means that its
>> content cannot be accessed through ooRexx unless there was a helper function 
>> which ooSQLite
>> doesn't seem to provide.
>>
>> As I don't know a good reason, why BLOB data should be returned as an opaque 
>> Buffer, I suggest to
>> change the code to return the data as a simple String or a MutableBuffer.
>>
>> Does anyone have concerns?
> No concerns at all! :)
>
> Maybe it would be also helpful to add the method "makeString" (and maybe also 
> "makeMutableBuffer")
> to the ooRexx Buffer class ("5.4.3 Buffer Class"), such that Rexx programmers 
> of other use cases can
> get at the data when confronted with a Buffer object if need arises?
>
> ---rony

Just another thought, should there ever be a motivation to make the data of an 
opaque Buffer from
the native side available to Rexx programmers: rather than implying that the 
data represents a
string (makestring would suggest that) a getter method like "data" could be 
used instead. It would
carry no specific meaning of the data the Buffer refers to.

---rony




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


Re: [Oorexx-devel] ooSQLite Blob handling

2019-09-07 Thread Rony G. Flatscher
On 06.09.2019 18:35, Erich Steinböck wrote:
> To be able answer Paul Higgins' recent question regarding retrieval of BLOB 
> data, I checked
> ooSqlite's BLOB handling - see incubator/ooSQLite.
>
> It seems that ooSQLite will return BLOBs as ooRexx Buffer objects only. This 
> means that its
> content cannot be accessed through ooRexx unless there was a helper function 
> which ooSQLite
> doesn't seem to provide.
>
> As I don't know a good reason, why BLOB data should be returned as an opaque 
> Buffer, I suggest to
> change the code to return the data as a simple String or a MutableBuffer.
>
> Does anyone have concerns?

No concerns at all! :)

Maybe it would be also helpful to add the method "makeString" (and maybe also 
"makeMutableBuffer")
to the ooRexx Buffer class ("5.4.3 Buffer Class"), such that Rexx programmers 
of other use cases can
get at the data when confronted with a Buffer object if need arises?

---rony




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


[Oorexx-devel] New beta of BSF4ooRexx

2019-08-21 Thread Rony G. Flatscher
Hi there,

in the process of tidying up BSF4ooRexx Javadoc warnings got handled, and ASM 
got removed by Janino
3.0.15. In order to test this version a new beta got uploaded to
:

  * the version for Windows and Linux is named: 
; after
unzipping change into "bsf4rexx/installation/{your-opsys}" and run 
"install.{cmd|sh}
  * the MacOSX version (includes ooRexx 5.0 r11896 beta) is named:
.

If you already have BSF4ooRexx installed, then make sure to uninstall it before 
installing the new
version, best via the menu "BSF4ooRexx -> Installation -> Uninstall".

Testing this version would be nice, as it more or less will be the version to 
be released by the
International Rexx symposium this September 2019. 

---rony

P.S.: The version "641" means that BSF4ooRexx runs at least on Java 6 and from 
ooRexx 4.1 up.
However, it is strongly advised to use the latest beta version of ooRexx 5.0 
due to numerous
improvements in stability, speed and features, cf.
. For 
instance, most JavaFX
nutshell samples will only run, if ooRexx 5.0 is present.

P.P.S.: BSF4ooRexx is an ooRexx-Java bridge, which camouflages Java as the easy 
to use ooRexx.

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


Re: [Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-14 Thread Rony G. Flatscher
Dear Enrico,

super, thank you very much for your example and the output of running it!!


On 14.08.2019 07:46, Enrico Sorichetti via Oorexx-devel wrote:
> IMO the logic to determine the installation directory structure is broken
>
>
> Create a test directory with the following CMakeLists.txt

This looks like pure magic in my (practically non-existent CMake "know-how") 
eyes!

:)

>
> #[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> -
>     CMakeLists.txt
>     Copyright Enrico Sorichetti 2018 - 2019
>     Distributed under the Boost Software License, Version 1.0.
>     (See accompanying file BOOST_LICENSE_1_0.txt or copy at
>     http://www.boost.org/LICENSE_1_0.txt)
> #]]
>
> #[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> -
>     Specify that the current CMake code is written for the given
>     version of CMake.  All policies introduced in the specified
>     version or earlier will be set to use ``NEW`` behavior.
> #]]
> cmake_minimum_required( VERSION 3.14 )
>
> #[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> -
>     dummy project
> #]]
> project( dummmy )
>
> #[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> -
> #]]
> function( vsnap )
>
>     set( _args "${ARGV}" )
>     list( SORT _args )
>     list( REMOVE_DUPLICATES _args )
>
>     set( _selvars "" )
>
>     get_cmake_property( _allvars VARIABLES )
>
>     foreach( _argv IN LISTS _args )
>
>         string( REGEX MATCH "([^\\*]*)" _head "${_argv}" )
>
>         if( _head STREQUAL _argv )
>             list( APPEND _selvars "${_argv}" )
>             continue()
>         endif()
>
>         string (REGEX MATCHALL "(^|;)${_head}[A-Za-z0-9_]*" _vars 
> "${_allvars}")
>
>         foreach( _var IN LISTS _vars )
>
>             if( "${_var}" STREQUAL "" )
>                 continue()
>             endif()
>
>             list( APPEND _selvars "${_var}" )
>
>         endforeach()
>
>     endforeach()
>
>     list( SORT _selvars )
>
>     list( REMOVE_DUPLICATES _selvars )
>
>     foreach( _var IN LISTS _selvars )
>         message( "[[ ${_var} '${${_var}}' " )
>     endforeach()
>
>     return()
>
> endfunction()
>
> #[[ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> -
> #]]
> include( GNUInstallDirs )
>
> vsnap( "CMAKE_INSTALL_*")
>
>
> Running cmake it will show a GNU compliant install directory structure 
>
> Tested on Fedora30 it returned 
>
> [[ CMAKE_INSTALL_BINDIR 'bin' 
> [[ CMAKE_INSTALL_DATADIR 'share' 
> [[ CMAKE_INSTALL_DATAROOTDIR 'share' 
> [[ CMAKE_INSTALL_DEFAULT_COMPONENT_NAME 'Unspecified' 
> [[ CMAKE_INSTALL_DOCDIR 'share/doc/dummmy' 
> [[ CMAKE_INSTALL_FULL_BINDIR '/usr/local/bin' 
> [[ CMAKE_INSTALL_FULL_DATADIR '/usr/local/share' 
> [[ CMAKE_INSTALL_FULL_DATAROOTDIR '/usr/local/share' 
> [[ CMAKE_INSTALL_FULL_DOCDIR '/usr/local/share/doc/dummmy' 
> [[ CMAKE_INSTALL_FULL_INCLUDEDIR '/usr/local/include' 
> [[ CMAKE_INSTALL_FULL_INFODIR '/usr/local/share/info' 
> [[ CMAKE_INSTALL_FULL_LIBDIR '/usr/local/lib64' 
> [[ CMAKE_INSTALL_FULL_LIBEXECDIR '/usr/local/libexec' 
> [[ CMAKE_INSTALL_FULL_LOCALEDIR '/usr/local/share/locale' 
> [[ CMAKE_INSTALL_FULL_LOCALSTATEDIR '/usr/local/var' 
> [[ CMAKE_INSTALL_FULL_MANDIR '/usr/local/share/man' 
> [[ CMAKE_INSTALL_FULL_OLDINCLUDEDIR '/usr/include' 
> [[ CMAKE_INSTALL_FULL_RUNSTATEDIR '/usr/local/var/run' 
> [[ CMAKE_INSTALL_FULL_SBINDIR '/usr/local/sbin' 
> [[ CMAKE_INSTALL_FULL_SHAREDSTATEDIR '/usr/local/com' 
> [[ CMAKE_INSTALL_FULL_SYSCONFDIR '/usr/local/etc' 
> [[ CMAKE_INSTALL_INCLUDEDIR 'include' 
> [[ CMAKE_INSTALL_INFODIR 'share/info' 
> [[ CMAKE_INSTALL_LIBDIR 'lib64' 
> [[ CMAKE_INSTALL_LIBEXECDIR 'libexec' 
> [[ CMAKE_INSTALL_LOCALEDIR 'share/locale' 
> [[ CMAKE_INSTALL_LOCALSTATEDIR 'var' 
> [[ CMAKE_INSTALL_MANDIR 'share/man' 
> [[ CMAKE_INSTALL_OLDINCLUDEDIR '/usr/include' 
> [[ CMAKE_INSTALL_PREFIX '/usr/local' 
> [[ CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT '1' 
> [[ CMAKE_INSTALL_RUNSTATEDIR 'var/run' 
> [[ CMAKE_INSTALL_SBINDIR 'sbin' 
> [[ CMAKE_INSTALL_SHAREDSTATEDIR 'com' 
> [[ CMAKE_INSTALL_SO_NO_EXE '0' 
> [[ CMAKE_INSTALL_SYSCONFDIR 'etc' 
>
>
> Note how it correctly determined that the libraries should be installed into 
> lib64

Indeed, *very* impressive and *great*!

> PS.
> The changes to the ooRexx CMakeLists are minimal
> The destination directories should be defined as variables properly 
> initialised, rather than hardcoded

Would you please be so kind and hint/share what should be changed in the ooRexx 
CMakeLists, given
that for a CMake guru like yourself these changes seem to be evident and as you 
write appear
"minimal" (!) to you, but for a total amateur like myself it looks like quite a 
huge and steep
mountain to climb up first, before becoming able to spot and change the 
necessary definitions? (I
have looked up CMakeLists.txt for CMAKE_INSTALL_* settings, but have not found 
settings that I

Re: [Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-14 Thread Rony G. Flatscher
Hi Mark,

On 14.08.2019 06:10, Mark Hessling wrote:
> I had the same issue when I made the changes to the CMake processing to build 
> the RPM.  To get the
> configurability of update-alternatives I had to use a user-supplied spec file 
> rather than the
> CMake-generated one. This appears to have caused CMake to not understand 
> where the generated RPM
> file is. 
>
> I updated my CMake to CMake v3 and didn't get the error, however this version 
> of CMake ignored the
> name of the RPM file and used its own name.
>
> I don't know CMake enough to determine how to fix the build issue.
>
thank you very much for your information! Just saw that Enrico (IMHO *the* 
CMake guru) has also
followed up.

Cheers

---rony




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


[Oorexx-devel] Any ideas how to fix bug 1645 ?

2019-08-13 Thread Rony G. Flatscher
Hi there,

 reports a problem when using 
CMake to create a rpm
package for ooRexx on Linux (used to work) using the command "cpack ./" after 
successfully running
"cmake -DBUILD_RPM=1 -DOS_DIST=fedora -DCMAKE_BUILD_TYPE=Release 
path-2-oorexx-trunk" followed by
"make".

The reason seems that the "make" step creates the so-files in

    
"../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib*/..."

whereas cpack tries to copy from

    
"../_CPack_Packages/Linux/RPM/ooRexx-5.0.0-11902.fedora.x86_64/usr/*lib64*/..."

which does not exist causing error messages and the abortion of the rpm 
building step.

Any ideas how to fix this?

TIA,

---rony

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


Re: [Oorexx-devel] Roundup attempt (Re: Ad compiled/tokenized Rexx code (rexxc) ...

2019-07-17 Thread Rony G. Flatscher
As ooRexx has gained this ability (kudos go to Rick, who put implemented a 
complete solution
including a rexxc option), please do not use the mentioned patch # 209 at all!

If you have a need to have the compiled Rexx program encoded, then use the new 
rexxc option "-e"
(trailing switch), tested with the latest version, revision 11896.

---rony

P.S.: If possible for the developers, maybe you could remove patch
<https://sourceforge.net/p/oorexx/patches/209/> altogether or mark it somehow 
as outdated?


On 05.07.2019 14:05, Rony G. Flatscher wrote:
>
> Hmm, it seems that I have not clearly communicated why the problem cannot be 
> solved reliably by
> third party libraries.
>
> The problem surfaced first in the Java environment: here the Java scripting 
> framework expects
> scripts to be stored as text only, such that reading script code 
> automatically causes code page
> translations to be applied (cannot be inhibited). If a script is a rexxc 
> compiled Rexx package,
> then the automatic codepage translation destroys the script's code!
>
> A solution would be to encode the rexxc compiled image with base64, which 
> makes the text immune to
> codepage translations. However, currently a base64 encoded rexxc compiled 
> image makes it
> incompatible with the ooRexx interpreter causing a Rexx runtime error.
>
> Hence the idea that a library like BSF4ooRexx would need to decode such a 
> program before handling
> it over to the Rexx interpreter, which appears to be reasonable at first.
>
> However, take a larger ooRexx written application that consists of different 
> ooRexx modules,
> mod1.rex, mod2.rex, ..., which can run standalone, but also in concert of a 
> larger application,
> that runs them, calling/requiring mod1.rex, mod2.rex,
>
> While a third party library could decode mod1.rex, mod2.rex, ..., this is not 
> possible if these
> modules get called/required by a running Rexx program!
>
> Currently, this situation cannot be handled by third party libraries, only by 
> the ooRexx
> interpreter (being the ultimate central location for executing code).
>
> So there are are three possibilities:
>
>  1. the interpreter gains the ability to handle base64 encoded compiled Rexx 
> programs: any
> combination of executing Rexx code (source code, rexxc compiled code, 
> base64 rexxc compiled
> code); codepage translations cannot hamper ooRexx programs (this is what 
> patch [1] does),
>
>  2. the interpreter allows for a new hook, where third party libraries can 
> inspect the Rexx code
> to be run, and if a base64 encoded rexxc compiled program in hand, it 
> will decode the base64
> encoded rexxc program before handing it over to the ooRexx interpreter,
>
>  3. keep the current state: rexxc compiled code cannot be run reliably in 
> environments that
> code-page translate the (raw) rexxc compiled Rexx program, thereby 
> destroying the code.
>
> ---
>
> I have created and tested a patch in [1] which solves the problem. The patch 
> can be applied to
> ooRexx on trunk, such that possibility # 1 above gets realized by it.
>
> If there was a hook for possibility # 2, I would take advantage of it and 
> implement the patch in
> BSF4ooRexx. (In this case the refactoring of RoutineClass.cpp in [1] could 
> still be applied to
> ooRexx to move all rexxc-related code into ProgramMetaData.{c|h}pp where Rexx 
> compiled code gets
> handled.)
>
> If neither possibility # 1 nor possibilty # 2 is made available, then the 
> patch may still proof
> helpful for companies developing complex ooRexx applications with rexxc 
> compiled packages: in this
> case any ooRexx application provider could apply the patch to ooRexx and 
> create a private version
> of ooRexx to be distributed with their ooRexx application.
>
> The preferable solution would be # 1 as it would solve the problem once and 
> forever, also for
> other libraries (being potentially faced with running under an environment 
> that does code page
> translations on scripts).
>
> ---rony
>
> [1] Patch # 209: <https://sourceforge.net/p/oorexx/patches/209/>; there is an 
> accompanying ooRexx
> script that carries out the base64 encoding (and allows for inspecting rexxc 
> compiled scripts).
>

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


[Oorexx-devel] Roundup attempt (Re: Ad compiled/tokenized Rexx code (rexxc) ...

2019-07-05 Thread Rony G. Flatscher
Hmm, it seems that I have not clearly communicated why the problem cannot be 
solved reliably by
third party libraries.

The problem surfaced first in the Java environment: here the Java scripting 
framework expects
scripts to be stored as text only, such that reading script code automatically 
causes code page
translations to be applied (cannot be inhibited). If a script is a rexxc 
compiled Rexx package, then
the automatic codepage translation destroys the script's code!

A solution would be to encode the rexxc compiled image with base64, which makes 
the text immune to
codepage translations. However, currently a base64 encoded rexxc compiled image 
makes it
incompatible with the ooRexx interpreter causing a Rexx runtime error.

Hence the idea that a library like BSF4ooRexx would need to decode such a 
program before handling it
over to the Rexx interpreter, which appears to be reasonable at first.

However, take a larger ooRexx written application that consists of different 
ooRexx modules,
mod1.rex, mod2.rex, ..., which can run standalone, but also in concert of a 
larger application, that
runs them, calling/requiring mod1.rex, mod2.rex,

While a third party library could decode mod1.rex, mod2.rex, ..., this is not 
possible if these
modules get called/required by a running Rexx program!

Currently, this situation cannot be handled by third party libraries, only by 
the ooRexx interpreter
(being the ultimate central location for executing code).

So there are are three possibilities:

 1. the interpreter gains the ability to handle base64 encoded compiled Rexx 
programs: any
combination of executing Rexx code (source code, rexxc compiled code, 
base64 rexxc compiled
code); codepage translations cannot hamper ooRexx programs (this is what 
patch [1] does),

 2. the interpreter allows for a new hook, where third party libraries can 
inspect the Rexx code to
be run, and if a base64 encoded rexxc compiled program in hand, it will 
decode the base64
encoded rexxc program before handing it over to the ooRexx interpreter,

 3. keep the current state: rexxc compiled code cannot be run reliably in 
environments that
code-page translate the (raw) rexxc compiled Rexx program, thereby 
destroying the code.

---

I have created and tested a patch in [1] which solves the problem. The patch 
can be applied to
ooRexx on trunk, such that possibility # 1 above gets realized by it.

If there was a hook for possibility # 2, I would take advantage of it and 
implement the patch in
BSF4ooRexx. (In this case the refactoring of RoutineClass.cpp in [1] could 
still be applied to
ooRexx to move all rexxc-related code into ProgramMetaData.{c|h}pp where Rexx 
compiled code gets
handled.)

If neither possibility # 1 nor possibilty # 2 is made available, then the patch 
may still proof
helpful for companies developing complex ooRexx applications with rexxc 
compiled packages: in this
case any ooRexx application provider could apply the patch to ooRexx and create 
a private version of
ooRexx to be distributed with their ooRexx application.

The preferable solution would be # 1 as it would solve the problem once and 
forever, also for other
libraries (being potentially faced with running under an environment that does 
code page
translations on scripts).

---rony

[1] Patch # 209: ; there is an 
accompanying ooRexx
script that carries out the base64 encoding (and allows for inspecting rexxc 
compiled scripts).


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


Re: [Oorexx-devel] Just curious ...

2019-06-06 Thread Rony G. Flatscher
As there has been no update so far, another attempt to learn about the current 
status.

Background: in the past months I have been asked from different 
people/organisations/companies about
an estimate of a release date for ooRexx 5, major reason being, that they would 
not be able/risk an
installation of ooRexx 5 as long as it is officially in beta. OTOH they need 
some lead/preparation
time and would like to start as early as possible to plan or request an upgrade 
to ooRexx 5, being
eager to get at all the nice new features, but also the speed and stability 
improvements of ooRexx 5.

[Personally, I would also be interested in an estimation as a release of ooRexx 
5 would allow me to
base BSF4ooRexx and a few other little utilities on ooRexx 5 (e.g. I have an 
ooRexx utility
developed for GNU mailman which is able to anonymize all or specific users in 
the mbox files
adhering to the GDPR, if a user asks to be anonymized after having posted in a 
public mailman list,
cf. <https://eugdpr.org/>). (Some of the new (also native) features would prove 
*quite* helpful.)]

[Also, planning e.g. an update to the ooRexx book to incorporate the new ooRexx 
5 features depend on
the release of ooRexx 5, of course. Will have a window for doing that in July 
or August, but there
are other things on the to-do-list, so I would not plan for book updates if it 
is not likely that
the release will occur over this summer (with always the possibility that 
unforeseen circumstances
may cause delays).]

As there are people willing to give a hand for the work going with the release 
process, if it is
possible for them, then maybe coming up with a list of todos that one could 
tackle, might help the
process? (A few such attempts are in the patch tracker already.)

---rony

P.S.: Ad release cycles: if one looks at 
<https://sourceforge.net/projects/oorexx/files/oorexx/> one
will learn that *every year* since the initial open source release of ooRexx 
3.0 in 2005 at least
one (minor or major) release has been done.

Since February 2014 no new release has occurred - more than five (!) years by 
now as if ooRexx was
stalled! Of course, those who have been following the ongoing development work 
know how much work
has been going on, that there has been really a *huge* effort undergoing to 
improve and incorporate
*major innovations* into ooRexx 5 in all those years! These great and highly 
welcomed enhancements
to ooRexx just have not (yet) materialized as a GA release for the public to 
see and the public to use.

Some of those sitting at the fence and watching discussions, examples of ooRexx 
5 code and maybe
have even installed over time one of the beta versions of ooRexx 5 can hardly 
wait until it gets
released such that finally they can get it in their companies installed and 
take advantage of it,
hence their questions about release dates which I just collect and carry 
forward to here, the ooRexx
developer list.


On 28.05.2019 16:09, Rony G. Flatscher wrote:

> There are quite a few open patches and I wonder what its status would be 
> (e.g. test framework
> related including offered test units, or the attempts to help with the 
> documentation of the new
> semaphore classes)?
>
> Also, is there current work going on offline or have things slowed down a bit 
> lately?
>
> What is the current state of the beta?
>
> Just curious.
>
> ---rony



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


[Oorexx-devel] Just curious ...

2019-05-28 Thread Rony G. Flatscher
There are quite a few open patches and I wonder what its status would be (e.g. 
test framework
related including offered test units, or the attempts to help with the 
documentation of the new
semaphore classes)?

Also, is there current work going on offline or have things slowed down a bit 
lately?

What is the current state of the beta?

Just curious.

---rony




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


Re: [Oorexx-devel] Suggestion: add rxSnippets to developer's Wiki

2019-05-18 Thread Rony G. Flatscher
On 17.05.2019 16:55, Rick McGuire wrote:
> It doesn't work that way. We can't just decide to take another person's work 
> and add to the
> project. This requires a specific donation from the author give us ownership 
> and permission to
> distribute under the project license and copyright.

Oh, you mean adding the project to the ooRexx project? Yes, that would be the 
best! It would allow
all those who look into the ooRexx "samples\api" directories to find also this 
"nutshell" CMake project.

Enrico put his "rxSnippets" project under the BSL (boost software license), cf.
<https://opensource.org/licenses/BSL-1.0>. ooRexx is under the CPL (common 
public license), if I
understand correctly, cf. <https://opensource.org/licenses/CPL-1.0> which in 
the meantime got
superceded by the EPL (Eclipse Public license), cf. 
<https://opensource.org/licenses/eclipse-1.0>.

The question would then be whether the boost license is acceptable and 
compatible with the CPL (or
EPL for that matter). If not, whether Enrico would agree to double-license it 
by adding the CPL to
it. (Any author can assign any number of different licenses to his work.)

---rony


> On Fri, May 17, 2019 at 9:58 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Hi there,
>
> Enrico Sorichetti has created a "nutshell" CMake project which makes it a 
> breeze to create
> external Rexx function packages using SAA and the ooRexx native API.
>
> The project he created and maintains is called "rxSnippets" and can be 
> downloaded with:
>
> HTTPS
> git clone https://3...@bitbucket.org/3481/rxSnippets.git
>
> SSH
> git clone https://3...@bitbucket.org/3481/rxSnippets.git
>
> It helped me really a few times to save a *lot* of time, hence I suggest 
> to add it to the
> ooRexx developer Wiki, such that interested programmers can get a hold of 
> this pearl!
>
> ---rony
>

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


[Oorexx-devel] Suggestion: add rxSnippets to developer's Wiki

2019-05-17 Thread Rony G. Flatscher
Hi there,

Enrico Sorichetti has created a "nutshell" CMake project which makes it a 
breeze to create external
Rexx function packages using SAA and the ooRexx native API.

The project he created and maintains is called "rxSnippets" and can be 
downloaded with:

HTTPS
git clone https://3...@bitbucket.org/3481/rxSnippets.git

SSH
git clone https://3...@bitbucket.org/3481/rxSnippets.git

It helped me really a few times to save a *lot* of time, hence I suggest to add 
it to the ooRexx
developer Wiki, such that interested programmers can get a hold of this pearl!

---rony

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


[Oorexx-devel] Problems installing 64-bit rpm on 64-bit fc

2019-05-16 Thread Rony G. Flatscher
This week I had a need to install a self-compiled ooRexx interpreter on a 
64-bit Fedora Core
workstations. The installation package was created using the ooRexx CMake.

First "uname -a":

Linux xyz.ab-cde.ac.at 5.0.14-200.fc29.x86_64 #1 SMP Thu May 9 10:46:15 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux

When trying to install with rpm the following error message comes up:

[rony@xyz xfer]$ rpm -i ooRexx-5.0.0-11875.fedora.x86_64-20190430.rpm
error: Failed dependencies:
librexx.so.5.0.0()(64bit) is needed by ooRexx-5.0.0-1.x86_64
librexxapi.so.5.0.0()(64bit) is needed by ooRexx-5.0.0-1.x86_64

Then trying to get information about the rpm content:

[rony@blue-m xfer]$ rpm -qp --provides 
ooRexx-5.0.0-11875.fedora.x86_64-20190430.rpm 
application()
application(rexxtry.desktop)
config(ooRexx) = 5.0.0-1
mimehandler(application/x-ooRexx-item)
ooRexx = 5.0.0-1
ooRexx(x86-64) = 5.0.0-1

[rony@blue-m xfer]$ rpm -qp --requires 
ooRexx-5.0.0-11875.fedora.x86_64-20190430.rpm 
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/usr/bin/csh
/usr/bin/env
/usr/bin/sh
config(ooRexx) = 5.0.0-1
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
librexx.so.5.0.0()(64bit)
librexxapi.so.5.0.0()(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)

Not having any working knowledge on rpm I would appreciate it a lot, if someone 
can advise how to
proceed from here.

If you need additional information then please advise how to fetch it from the 
system.

---rony

P.S.: I could install ooRexx from the deb-package as dpkg was installed on that 
machine. The deb
package was created from the same sources.




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


Re: [Oorexx-devel] A new draft/sketch for documenting the new classes EventSemaphore and MutexSemaphore (Re: A sketch for a documentation text for the "EventSemaphore" class

2019-05-07 Thread Rony G. Flatscher
On 11.04.2019 18:30, Rony G. Flatscher wrote:
>
> This posting was meant to define the documentation for the new Rexx classes 
> EventSemaphore and
> MutexSemaphore.
>
> Just wanted to make sure that it does not get lost, hence the question 
> whether I should submit it
> as some form of a patch?
>
> Also, if I know into which XML-file to place it, I could try to study the 
> existing documentation
> of the classes and the used tags and attributes there and supply also a XML 
> rendering that I would
> think would be appropriate. So please advise.
>
> ---rony
>
You find my attempt at <https://sourceforge.net/p/oorexx/patches/210/>.

---rony




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


Re: [Oorexx-devel] Question ad SysFile->open( (int) handle) ...

2019-05-05 Thread Rony G. Flatscher
On 04.05.2019 22:45, Erich Steinböck wrote:
> I don't think so.
> See bug 1357.

Thank you very much!

---rony



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


[Oorexx-devel] Question ad SysFile->open( (int) handle) ...

2019-05-04 Thread Rony G. Flatscher
A quick question: if one receives a "FILE *handle" and use it with
common/platform/{unix|windows}/SysFile, can one use its "open( (int) handle)" 
safely with it?

---rony



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


Re: [Oorexx-devel] Windows commands change console window title

2019-04-28 Thread Rony G. Flatscher
On 27.04.2019 23:01, Jon Wolfers wrote:
> I have found this a nuisance in the past, sometimes revealing passwords to 
> users on net use
> commands.  Glad to see it go!

+1

---rony


>
> On Sat, 27 Apr 2019 at 19:59, Erich Steinböck  > wrote:
>
> On Windows, our default command handler changes the console window title 
> to
> "path-to-cmd\cmd.exe /c executing-command" and after the command 
> finishes, reverts it to what
> it was before.
>
> Is there a good reason we're doing this? Windows batch files don't do it, 
> and most commands
> won't run long enough for a user to actually be able to read the new 
> title.
>
> I intend to make the new SYSTEM and PATH command environments skip this 
> title change.
>
> Do we want to keep the console title changing for commands running in our 
> existing
> environments CMD and "" ?
> ___
> 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] A new Mac warning

2019-04-25 Thread Rony G. Flatscher
compiling r11872 with latest Clang

[ 18%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/classes/StringClassConversion.cpp.o
/Users/rony/dev/oorexx_allura/main/trunk/interpreter/classes/StringClassConversion.cpp:196:28:
 warning: result of
  comparison of constant -1 with expression of type 'unsigned char' is 
always false
  [-Wtautological-constant-out-of-range-compare]
if (digitValue == '\xff')
~~ ^  ~~
1 warning generated.

---rony

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


Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-25 Thread Rony G. Flatscher
Just for the record: Rick and Erich have updated the code and improved the 
speed considerably, which
is really great!

---rony


On 19.04.2019 17:01, Moritz Hoffmann wrote:
> Hi,
> looking at ooRexx's implemetation of x2c I find the original code much easier 
> to understand and to
> reason about. Instead of hand-tuning an implementation I'd like to know why 
> the native
> implementation is slower than your approach. I'd suspect it's because it's 
> using strchr to
> validate each character against a set of valid characters. Might want to 
> improve that instead...
>
> It might be good to use VTune to do the actual performance analysis because 
> that will give a
> cycle-accurate break-down of instructions.
>
> Cheers,
> Moritz
>
> On Fri, Apr 19, 2019 at 4:18 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Double-checked the test hex strings and their positions of illegal 
> whitespace chars, here the
> native routine with the corrected position:
>
> int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, 
> char *data)
> {
> // check for trailing whitespace
> char tmp=(hexData[len-1]);  // get last character (must not 
> be whitespace)
> if (tmp==' ' || tmp=='\t')
> rcc->ThrowException1(93931, rcc->UnsignedInt64ToObject(len));
>
> size_t dIdx=0;
>
> for (size_t i=0; i {
>
> if  (hexData[i]>='0' && hexData[i]<='9') 
> tmp=hexData[i]-'0';
> else if (hexData[i]>='A' && hexData[i]<='F') 
> tmp=hexData[i]-'A'+10;
> else if (hexData[i]>='a' && hexData[i]<='f') 
> tmp=hexData[i]-'a'+10;
> else
> {
> // check for leading whitespace
> if (dIdx==0 && (hexData[i]==' ' || hexData[i]=='\t') )
> rcc->ThrowException1(93931, rcc->Int32ToObject(1));
>
> if (hexData[i]==' ' || hexData[i]=='\t') continue; // 
> skip on whitespace
>
> // illegal hex digit
> char buf[64];
> snprintf(buf, 64, "%c\0", hexData[i]);
> rcc->ThrowException1(93933, 
> rcc->NewStringFromAsciiz(buf));
> }
> tmp<<=4;// shift to high order nibble
> i++;// position on next hex digit
>
> if (i==len) // we are beyond the hex string and missing the 
> second hex digit
> {
> char buf[256];
> snprintf(buf, 256, "Hexadecimal string incomplete: 
> hexadecimal pair starting with the character \"%c\" in position %zd is 
> missing the second hexadecimal digit\0", hexData[i-1], len);
> rcc->ThrowException1(93900,rcc->NewStringFromAsciiz(buf));
> }
>
>
> if  (hexData[i]>='0' && hexData[i]<='9') 
> tmp|=hexData[i]-'0';
> else if (hexData[i]>='A' && hexData[i]<='F') 
> tmp|=hexData[i]-'A'+10;
> else if (hexData[i]>='a' && hexData[i]<='f') 
> tmp|=hexData[i]-'a'+10;
> else if (hexData[i]==' ' || hexData[i]=='\t')  // also 
> whitespace not allowed in between of a hex pair
> rcc->ThrowException1(93931, 
> rcc->UnsignedInt64ToObject(i*+1*));
> else // illegal hex digit
> {
> char buf[64];
> snprintf(buf, 64, "%c\0", hexData[i]);
> rcc->ThrowException1(93933, 
> rcc->NewStringFromAsciiz(buf));
> }
> data[dIdx++]=tmp;
> }
> data[dIdx]='\0';
> return (int64_t)dIdx;// return number or characters 
> in data
> }
>
> ---rony
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> <mailto:Oorexx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
> -- 
> Moritz Hoffmann;
> http://antiguru.de/

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


Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
Double-checked the test hex strings and their positions of illegal whitespace 
chars, here the native
routine with the corrected position:

int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, char 
*data)
{
// check for trailing whitespace
char tmp=(hexData[len-1]);  // get last character (must not be 
whitespace)
if (tmp==' ' || tmp=='\t')
rcc->ThrowException1(93931, rcc->UnsignedInt64ToObject(len));

size_t dIdx=0;

for (size_t i=0; i='0' && hexData[i]<='9') tmp=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp=hexData[i]-'a'+10;
else
{
// check for leading whitespace
if (dIdx==0 && (hexData[i]==' ' || hexData[i]=='\t') )
rcc->ThrowException1(93931, rcc->Int32ToObject(1));

if (hexData[i]==' ' || hexData[i]=='\t') continue; // skip on 
whitespace

// illegal hex digit
char buf[64];
snprintf(buf, 64, "%c\0", hexData[i]);
rcc->ThrowException1(93933, rcc->NewStringFromAsciiz(buf));
}
tmp<<=4;// shift to high order nibble
i++;// position on next hex digit

if (i==len) // we are beyond the hex string and missing the second 
hex digit
{
char buf[256];
snprintf(buf, 256, "Hexadecimal string incomplete: hexadecimal 
pair starting with the character \"%c\" in position %zd is missing the second 
hexadecimal digit\0", hexData[i-1], len);
rcc->ThrowException1(93900,rcc->NewStringFromAsciiz(buf));
}


if  (hexData[i]>='0' && hexData[i]<='9') tmp|=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp|=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp|=hexData[i]-'a'+10;
else if (hexData[i]==' ' || hexData[i]=='\t')  // also whitespace 
not allowed in between of a hex pair
rcc->ThrowException1(93931, 
rcc->UnsignedInt64ToObject(i*+1*));
else // illegal hex digit
{
char buf[64];
snprintf(buf, 64, "%c\0", hexData[i]);
rcc->ThrowException1(93933, rcc->NewStringFromAsciiz(buf));
}
data[dIdx++]=tmp;
}
data[dIdx]='\0';
return (int64_t)dIdx;// return number or characters in data
}

---rony

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


Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher

On 19.04.2019 15:55, Rony G. Flatscher wrote:
> On 19.04.2019 13:09, Rick McGuire wrote:

... cut ...

Sorry, the following error message is  correct, the position 6 is correct (had 
changed the hex string):
>
>   * the hexadecimal string "Ab  0 0  ff  00  ff  00  ff  12" has an illegal 
> whitespace in position
> 5, x2c() reports wrongly position 6 instead,
>
---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
On 19.04.2019 13:09, Rick McGuire wrote:
> Well, you're missing all of the logic that allows for blanks at the 
> boundaries and you're also
> assuming that you have an even number of digits to convert. If you remove all 
> of the things that
> x2c() has to account for, then yes, you can do a faster conversion.

OK, this version caters for illegal leading and trailing whitespace making sure 
an even number of
digits gets processed; it is still appr. 4,8 faster than the current x2c:

/* A Rexx hex string may include any number of whitespace after even hex 
characters, e.g.
 "00 01   02"x
 but no leading or trailing blanks like " 00 01   02 "x
*/
int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, char 
*data)
{
// check for trailing whitespace
char tmp=(hexData[len-1]);  // get last character (must not be 
whitespace)
if (tmp==' ' || tmp=='\t')
rcc->ThrowException1(93931, rcc->UnsignedInt64ToObject(len));

size_t dIdx=0;

for (size_t i=0; i='0' && hexData[i]<='9') tmp=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp=hexData[i]-'a'+10;
else
{
// check for leading whitespace
if (dIdx==0 && (hexData[i]==' ' || hexData[i]=='\t') )
rcc->ThrowException1(93931, rcc->Int32ToObject(1));

if (hexData[i]==' ' || hexData[i]=='\t') continue; // skip on 
whitespace

// illegal hex digit
char buf[64];
snprintf(buf, 64, "%c\0", hexData[i]);
rcc->ThrowException1(93933, rcc->NewStringFromAsciiz(buf));
}
tmp<<=4;// shift to high order nibble
i++;// position on next hex digit

if (i==len) // we are beyond the hex string and missing the second 
hex digit
{
char buf[256];
snprintf(buf, 256, "Hexadecimal string incomplete: hexadecimal 
pair starting with the character \"%c\" in position %zd is missing the second 
hexadecimal digit\0", hexData[i-1], len);
rcc->ThrowException1(93900,rcc->NewStringFromAsciiz(buf));
}


if  (hexData[i]>='0' && hexData[i]<='9') tmp|=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp|=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp|=hexData[i]-'a'+10;
else if (hexData[i]==' ' || hexData[i]=='\t')  // also whitespace 
not allowed in between of a hex pair
rcc->ThrowException1(93931, rcc->UnsignedInt64ToObject(i));
else // illegal hex digit
{
char buf[64];
snprintf(buf, 64, "%c\0", hexData[i]);
rcc->ThrowException1(93933, rcc->NewStringFromAsciiz(buf));
}
data[dIdx++]=tmp;
}
data[dIdx]='\0';
return (int64_t)dIdx;// return number or characters in data
}


RexxRoutine1( RexxStringObject, cppX2C, CSTRING, hexData  )
{
size_t len=strlen(hexData);
char *data=(char *) malloc (len+1);
int64_t res=(int64_t) hex2char(context, hexData,len,data);  // true, if 
translated; false, else
RexxStringObject rso=context->String(data, (size_t) res);
free(data);
return rso;
}

Here the hexadecimal test strings checked against the x2c()-BIF and the above 
hex2char():

.context~package~local~lineal="1234+6789|"~copies(7)

hexStrings=("Ab00ff00ff00ff12"  , -
"Ab 00 ff 00 ff 00 ff 12"   , -
"AB  00  ff  00  ff  00  ff  12", -
"AB  00  ff  00  ff  00  ff  1", --- not ok: hex-digit 
missing
"AB  00  ff  00  f   00  ff  12", -   -- not ok: whitespace 
in wrong position (actually hex-digit missing)
"Ab  0 0  ff  00  ff  00  ff  12"   , -   -- not ok: pairs may 
not contain whitespace
"Ab != 00  ff  00  ff  00  ff  12"  , -   -- not ok: illegal 
characters "!="
"aB 0X 00  ff  00  ff  00  ff  12"  , -   -- not ok: illegal 
characters "!="
"  aB  00  ff  00  ff  00  ff  12"  , -   -- not ok: leading 
whitespace
"aB  00  ff  00  ff  00  ff  12  "  ) -- not ok: trailing 
whitespace
do h over hexStrings
   call testHexStringWithX2ch
   say
   call testHexStringWithCppX2C h
   say
   say "="~copies(79)
end

The x2c()-BIF has two wrong error messages:

  * the hexadecimal string "Ab  0 0  ff  00  ff  00  ff  12" has an illegal 
whitespace in position
5, x2c() reports wrongly position 6 instead,

  * the hexadecimal string "AB 00 ff 00 ff 00 ff 1" is an incomplete 
hexadecimal string (last hex
digit missing), x2c() 

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
Thank you all for your feedback to my quite "dirty" ;) posting!

As Mike pointed out 'a'-'z' were not honored, but also blanks in between pairs 
of hex digits, which
Rexx allows for.

Rewriting the algorithm a little bit it runs even faster (up to 4.5 times 
compared to x2c()):

/* A Rexx hex string may include any number of whitespace after even hex 
characters, e.g.
 "00 01   02"x
*/
int64_t hex2char(CSTRING hexData, size_t len, char *data)
{
size_t dIdx=0;

for (size_t i=0; i='0' && hexData[i]<='9') tmp=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp=hexData[i]-'a'+10;
else if (hexData[i]==' ' || hexData[i]=='\t') continue; // skip on 
whitespace
else
{
data[0]='\0';
return -i;  // error: return position as negative number
}
tmp<<=4;// shift to high order nibble

i++;// position on next hex digit
if  (hexData[i]>='0' && hexData[i]<='9') tmp|=hexData[i]-'0';
else if (hexData[i]>='A' && hexData[i]<='F') tmp|=hexData[i]-'A'+10;
else if (hexData[i]>='a' && hexData[i]<='f') tmp|=hexData[i]-'a'+10;
else// also whitespace is not allowed in between of a hex 
pair
{
data[0]='\0';
return -i;  // error: return position as negative number
}
data[dIdx++]=tmp;
}
data[dIdx]='\0';
return dIdx;// return number or characters in data
}

RexxRoutine1( RexxStringObject, cppX2C, CSTRING, hexData  )
{
size_t len=strlen(hexData);

char *data=(char *) malloc (len+1);
int64_t res=hex2char(hexData,len,data);  // true, if translated; false, 
else

if (res==-1)
{
free(data);
return NULLOBJECT;  // indicate error; TODO: raise exception?
}

RexxStringObject rso=context->String(data, res);
free(data);

return rso;
}

Maybe missing something compared to the x2c()-BIF (x2c-method in the String 
class).

---rony


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


[Oorexx-devel] An alternative algorithm for x2c()

2019-04-18 Thread Rony G. Flatscher
While experimenting a little bit with C code to decode hex strings I came up 
with the following code:

boolean hex2char(CSTRING hexData, size_t len, char *data)
{
if (len % 2 == 1)   // not an even number of hex characters
{
data[0]='\0';
return false;
}

size_t dIdx=0;

for (size_t i=0; iString(data, len/2);
free(data);

return rso;
}

Comparing the duration of x2c() with the above cppX2C() 1,000 times on a 512KB 
string (
xrange("00"x,"FF"x)~copies(1000)~c2x ) the implementation of hex2char() seems 
to be about 3,8 faster
than x2c(). (This was tested on Windows, 32-bit ooRexx.) Left the RexxRoutine1 
cppX2C() in the above
pasted code, such that you could double-check it by merely copying and pasting 
the above code and
test it for yourself.

---rony




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


[Oorexx-devel] Updated the website for assorted student works using ooRexx (and BSF4ooRexx) ...

2019-04-14 Thread Rony G. Flatscher
At  you will find assorted 
works from my students
(seminar papers, Bachelor and Master thesis). (You will find quite a lot work 
employing ooRexx and
BSF4ooRexx, including programming OpenOffice/LibreOffice with ooRexx on all 
platforms.)

Just uploaded a Bachelor thesis (Daniel Langer) that used ooRexx and BSF4ooRexx 
and who (in his
abstract communicates how he) has been very impressed about how easy and fast 
one can learn (two
lectures in one semester, totalling 4 ECTS - European Credit Transfer System - 
points with a total
teaching load of 200 hours) and apply ooRexx for creating the core of a cash 
register system that
adheres to the (quite complex) Austrian regulations.

---rony




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


[Oorexx-devel] Ad rexxc'd Rexx programs, two questions

2019-04-13 Thread Rony G. Flatscher
In , Rick stated what is needed to 
run a rexxc'd
program:  "The only factors here are The bitness, the endian byte order and the 
language level
required to run the program." (So rexxc'd Rexx programs are operating system 
independent, which is
great!)

The ooRexx interpreter currently can be used to find out the current bitness
(.rexxinfo~architecture) and languagel level (.rexxinfo~languageLevel). However 
it seems there is no
means available to find out which endian byte order is in effect for the 
current system from the
ooRexx interpreter.

In addition when dealing with rexxc'd programs to the best of my knowledge 
there is currently no
ooRexx tool or function for extracting these three indicator values from the 
compiled/tokenized Rexx
program, which would be necessary for writing a script that checks the 
compiled/tokenized Rexx
programs for compatibilty against the currently running ooRexx interpreter.

So two questions (linked to the intent of creating a Rexx script that is able 
to check out the
compatibility of rexxc'd Rexx programs):

  * Where could one learn about the location and values of the three above 
indicators in a rexxc'd
program? Is there a source file where this structure is defined, such that 
one could write a
little Rexx script to check out the rexxc'd programs for compatibility with 
the current
interpreter (envisioning trees of rexxc' programs with different Rexx 
interpreters that get used
for distribution, packaging of Rexx apps)?

  * Is there already some way to figure out the endian byt order from Rexx?

---rony

P.S.: Maybe rexxc or rexx could be enhanced to accept a new switch like "-info 
someTokenized.rexxc"
which returns a blank delimited string with the three indicator values found in 
the rexxc'd file?


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


Re: [Oorexx-devel] Question ad native SendMessage*() APIs

2019-04-13 Thread Rony G. Flatscher
Filed a RFE <https://sourceforge.net/p/oorexx/feature-requests/755/>.

---rony

On 11.04.2019 17:56, Rick McGuire wrote:
> This would need a new api. We never had the need before but it seems 
> reasonable to implement at
> least the version that uses an array for the arguments.
>
> Rick
>
> On Thu, Apr 11, 2019 at 11:31 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> How would one apply the native SendMessage*() APIs to mimickry what is 
> possible in ooRexx with:
>
> o~someMessage:super  /* start searching the method 
> 'someMessage' in the superclass */
>
> Trying to code this in native code like:
>
> context->SendMessage0(oself, "someMessage:super")
>
> yields error 97.1: Object "The TEST class" does not understand message 
> "SOMEMESSAGE:SUPER".
>
> (This might be useful when implementing methods in native code.)
>
> ---rony
>

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


Re: [Oorexx-devel] A new draft/sketch for documenting the new classes EventSemaphore and MutexSemaphore (Re: A sketch for a documentation text for the "EventSemaphore" class

2019-04-11 Thread Rony G. Flatscher
This posting was meant to define the documentation for the new Rexx classes 
EventSemaphore and
MutexSemaphore.

Just wanted to make sure that it does not get lost, hence the question whether 
I should submit it as
some form of a patch?

Also, if I know into which XML-file to place it, I could try to study the 
existing documentation of
the classes and the used tags and attributes there and supply also a XML 
rendering that I would
think would be appropriate. So please advise.

---rony


On 14.03.2019 20:05, Rony G. Flatscher wrote:
> On 14.03.2019 18:10, Rick McGuire wrote:
>> A couple of notes that need to added to the MutexSemaphore section
>>
>> 1) On a single thread, acquire requests nests, so if a thread calls acquire 
>> again while already
>> having obtained the semaphore, it will be not blocked. It requires an 
>> equivalent number of
>> release calls to free up the mutex. 
>>
>> 2) If the thread holding the mutex ends without releasing the semaphore, the 
>> semaphore will be
>> released automatically.
>>
>> Rick 
>
> Thanks, this version now includes this information in the "acquire" part:
>
> 
> ===
> 5.4.x EventSemaphore Class
>
> Semaphores get used in multithreaded scenarios.
>
> An "event semaphore" allows one thread "A" to synchronize multiple threads
> (like "B", "C", ...) with whom the event semaphore gets shared.  Thread
> "A" creates the event semaphore and sends it the "reset" message.  Then
> thread "A" supplies the event semaphore to the threads "B", "C", ..., each
> of which sends the received event semaphore a "wait" message.  This will
> block the threads "B", "C", ..., until thread "A" sends the "post" message
> to the event semaphore.  At this time all threads waiting on the event
> semaphore get released and can run in parallel on their threads.
>
> 5.4.x.1 close
>
> >>--- close ---><
>
> Closes the event semaphore.
>
>
> 5.4.x.2 isPosted
>
> >>--- isPosted ---><
>
> Returns .true if the event semaphore is in the "posted" state, such that
> sending the "wait" message to this event semaphore would return
> immediately.  A return value of .false indicates that the event semaphore
> is not in the "posted" state, such that a "wait" message will block.
>
>
> 5.4.x.3 post
>
> >>--- post ---><
>
> Sets the event semaphore to the "posted" state, signalling that the event
> that other threads are waiting on has occurred, such that all threads
> waiting on this event semaphore will be released and start to run again.
>
>
> 5.4.x.4 reset
>
> >>--- reset ---><
>
> Resets (clears) the event semaphore to the non-"posted" state, such that 
> "wait"
> messages to this event semaphore will block.
>
>
> 5.4.x.5 uninit
>
> >>--- uninit ---><
>
> This method cleans up the object when it is garbage collected.  It should
> not be invoked directly except via an uninit method of a subclass of the
> EventSemaphore class.
>
>
> 5.4.x.6 wait
>
> >>--- wait(--+-+--)---><
>  | |
>  +-- timeout --+
>
> Waits (blocks) on the event semaphore until it gets "posted".  If the
> optional argument "timeout" was supplied it must be a whole number that
> represents the milliseconds to wait on the event semaphore before
> returning.
>
>
> If no "timeout" value was supplied or its value is negative, the wait will
> be forever, ie. until the event semaphore gets "posted".
>
> If the "timeout" value is zero the method returns immediately with the
> same value that the method "isPosted" would return if sent to the event
> semaphore instead.
>
> The method returns .true if the event semaphore got "posted", .false if
> the method returns prematurely because the given timeout has occurred.
>
>
> Example 5.xxx
>
> The following example will fetch the routine object "WORKER" and in a loop
> will send the routine object the message "start" (defined in the ooRexx
> root class "Object") supplying the message name ("call") to be sent on a
>  

[Oorexx-devel] Question ad native SendMessage*() APIs

2019-04-11 Thread Rony G. Flatscher
How would one apply the native SendMessage*() APIs to mimickry what is possible 
in ooRexx with:

o~someMessage:super  /* start searching the method 'someMessage' in 
the superclass */

Trying to code this in native code like:

context->SendMessage0(oself, "someMessage:super")

yields error 97.1: Object "The TEST class" does not understand message 
"SOMEMESSAGE:SUPER".

(This might be useful when implementing methods in native code.)

---rony


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


Re: [Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-10 Thread Rony G. Flatscher
On 09.04.2019 17:38, Moritz Hoffmann wrote:
> Well, the Java scripting framework will always use a Reader, which decodes 
> the input according to
> the current Charset. I don't see a way to circumvent this, either by not 
> using a Reader instance
> or by injecting a custom, non-adapting Charset. I agree with Rick that this 
> is not a problem that
> ooRexx should solve. Instead, I'd base64-encode the scripts, and decode them 
> before passing them
> to the interpreter. Base64 will survive any reasonable Java byte decoding 
> magic.

The reason why it is a request (and not an error report ;) ) is that so far the 
binary
representation has not caused a problem, because only Rexx would create and 
later read the
self-produced tokenized code (knowing its internal structure and the binary 
data part).

Now, that Rexx scripts get deployed in an environment that only processes text 
and not binary data
(in this case the Java scripting frameworks) and there are use-cases (whenever 
java.io.Reader gets
triggered in the scripting frameworks) that cannot be safely intercepted by 
BSF4ooRexx, which
enables ooRexx to be hosted by and deployed from Java (applications) and also 
making all of the Java
world available to ooRexx.

As this uncovered problem lies in the binary representation of the tokenized 
Rexx code produced by
rexxc which in this use case turns out to be actually (and unexpectedly) a 
quite fragile solution it
would nevertheless be solvable by having rexxc (or some postprocessing utility) 
store it in form of
a pure text rendering. Hence this request addressed to ooRexx.

---

Ad Rick's idea to create a utiltity in BSF4ooRexx to recode the rexxc-produced 
binary data in an
"immune" textual form (basically coding the binary data with c2x or base64) and 
change BSF4ooRexx
internal (native) code to deal with this situation has the following 
implications:

  * the 'rexxc' generated and postprocessed tokenized format is then not 
compatible with Rexx anymore,
  * hence submitting such a non-compatible text-encoded version of the 
tokenized format would not be
processable by Rexx,

  * every Rexx programmer who wishes to use Rexx as a scripting language for 
Java applications or
uses BSF4ooRexx to create demanding applications in pure ooRexx using Java 
classes for missing
ooRexx features (like portable GUIs, but also IPV6-socket connections or 
ssl-connections, etc.)
would need to know that for sheltering their Rexx code they must

  o run 'rexxc' on each script,
  o plus must not forget to run the BSF4ooRexx postprocessing script 
applied on those freshly
produced 'rexxc' tokenized scripts,
  o deploy the postprocessed versions (*not* the original and Rexx 
compatible 'rexxc' tokenized
version)

  * now take into account that application systems need to be maintained in a 
constant manner
possibly by different programmers, each maintenance change causes the need 
to 'rexxc' and in
addition to apply the non-ooRexx utility to postprocess the tokenized code 
to turn it into pure
7-bit text; adding another step, making it more cumbersome and therefore 
over time mostlikely
more error-prone.

If it was possible to encode the tokenized form rexxc currently produces in an 
agreed upon format as
text then ooRexx could process such a version by converting it back into its 
binary form, and
proceed with the resulting data as today. In this scenario one would not create 
a non-compatible
version of a tokenized Rexx program, but rather one that ooRexx would be able 
to execute without the
help of any other tool.

This is just thinking loud about the situation and the idea of creating a 
non-ooRexx compatible
tokenized version of Rexx programs in the file system.
(Still have to think about it.)

---rony


>
> On Tue, Apr 9, 2019 at 3:34 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 09.04.2019 15:13, Rick McGuire wrote:
> > And it doesn't make sense to put the onus on solving this on the 
> interpreter. If it is
> desired to
> > store binary code in an inherently text-based interface, then 
> BSF4ooRexx should handle this be
> > including a utility to perform the transform and then decoding the 
> format before passing it
> to the
> > interpreter.
>
> Well, please tell IBM, Oracle and the OpenJDK community which devised and 
> applied all of the Java
> scripting frameworks in the past twenty years such that they expect 
> scripts to be supplied as text
> only, not as binary data.
>
> If a Java program employs e.g. the "javax.script" framework and it is 
> supplied the name of a Rexx
> program file, the "javax.script" framework will use some "java.io.Reader" 
> to read the script from
> the file. In the case of r

Re: [Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-09 Thread Rony G. Flatscher
On 09.04.2019 15:13, Rick McGuire wrote:
> And it doesn't make sense to put the onus on solving this on the interpreter. 
> If it is desired to
> store binary code in an inherently text-based interface, then BSF4ooRexx 
> should handle this be
> including a utility to perform the transform and then decoding the format 
> before passing it to the
> interpreter.

Well, please tell IBM, Oracle and the OpenJDK community which devised and 
applied all of the Java
scripting frameworks in the past twenty years such that they expect scripts to 
be supplied as text
only, not as binary data.

If a Java program employs e.g. the "javax.script" framework and it is supplied 
the name of a Rexx
program file, the "javax.script" framework will use some "java.io.Reader" to 
read the script from
the file. In the case of rexxc-tokenized Rexx code the Reader will 
inadvertently destroy the binary
data due to possible codepage translations well before BSF4ooRexx receives the 
(then ruined binary)
script data.

There is nothing, BSF4ooRexx could do here as it exploits/applies and depends 
on the Java scripting
frameworks, unfortunately.

Hence asking ooRexx to the rescue;  suggesting to add a single step before 
storing the rexxc
produced binary data by turning the binary data into a hexadecimal string and 
store that lossless
rendering;  and upon receiving a tokenized Rexx program adding a single reverse 
step to turn the
hexadecimal string losslessly back into the needed binary form for unflatening.

---rony




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


Re: [Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-09 Thread Rony G. Flatscher
On 09.04.2019 14:56, Michael Lueck wrote:
> Rony G. Flatscher wrote:
>>
>> However,  since he started to use "rexxc" to compile/tokenize all of the 
>> Rexx source files that
>> comprise his elaborate application to shelter his code, he has started to 
>> run into abends/errors
>> 13.1. 
>
>
> "sheltering code" is the only reason he chose to compile/tokenize his code... 
> there is no
> requirement to do so when using BSF4ooRexx?

Indeed "sheltering code" is the only (and quite understandable) reason.

BSF4ooRexx depends on the Java scripting frameworks from IBM, Oracle and 
OpenJDK, which expect
script code to be supplied as text and not as binary data (which unfortunately 
causes this problem).

---rony




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


Re: [Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-09 Thread Rony G. Flatscher

On 09.04.2019 14:32, Rony G. Flatscher wrote:
... cut ...

> Unfortunately, running rexxc-tokenized/compiled scripts via the Java 
> scripting framework does not
> work as apprehended in my last post and causes the following runtime error:
>
> G:\test\oorexx\rexxc>rexxj test.rexx
> RexxDispatcher.java: Throwable of type 
> 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx:
> getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9:
> Rexx traceback line not available from the Rexx condition object (Rexx 
> condition may have been caused by a call or message from Java to Rexx)
> Error 3 running  line 0:  Failure during initialization.
> Error 3.903:  Program "G:\test\oorexx\rexxc\test.rexx" cannot be run by 
> this version of the REXX interpreter.]
>
> (The error text within the square brackets gets created in native code from 
> the Rexx condition
> object. The 'getLocalizedMessage():' right before the opening square bracket 
> seems to come from
> ooRexx, it is not used in the native code.)

... cut ...

The "getLocalizedMessage()" does *not* come from ooRexx, it comes from one of 
the Java programs.

---rony

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


[Oorexx-devel] MacOS warnings

2019-04-09 Thread Rony G. Flatscher
When creating the ooRexx interpreter from trunk (r11856) on MacOS the following 
(not yet reported)
warnings get generated:

wu114184:oorexx_build rony$ make

... cut ...

[  4%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/LocalQueueManager.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/rexxapi/client/LocalQueueManager.cpp:571:14:
 warning: comparison of two values with different
  enumeration types in switch statement ('ServiceReturn' and 
'ErrorCode') [-Wenum-compare-switch]
case BAD_WAIT_FLAG:
 ^

/Users/rony/dev/oorexx_allura/main/trunk/rexxapi/client/LocalQueueManager.cpp:568:14:
 warning: comparison of two values with different
  enumeration types in switch statement ('ServiceReturn' and 
'ErrorCode') [-Wenum-compare-switch]
case BAD_FIFO_LIFO:
 ^

/Users/rony/dev/oorexx_allura/main/trunk/rexxapi/client/LocalQueueManager.cpp:565:14:
 warning: comparison of two values with different
  enumeration types in switch statement ('ServiceReturn' and 
'ErrorCode') [-Wenum-compare-switch]
case INVALID_QUEUE_NAME:
 ^~
3 warnings generated.
[  4%] Building CXX object 
CMakeFiles/rexxapi.dir/rexxapi/client/LocalRegistrationManager.cpp.o



... cut ...



[ 68%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/platform/unix/SysRexxUtil.cpp.o

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:446:57:
 warning: format specifies type 'intmax_t'
  (aka 'long') but the argument has type 'off_t' (aka 'long long') 
[-Wformat]
snprintf(fileAttr, sizeof(fileAttr), "%20jd  ", finfo.st_size);
  ~ ^
  %20lld

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:454:57:
 warning: format specifies type 'intmax_t'
  (aka 'long') but the argument has type 'off_t' (aka 'long long') 
[-Wformat]
snprintf(fileAttr, sizeof(fileAttr), "%10jd  ", finfo.st_size);
  ~ ^
  %10lld

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:664:14:
 warning: 'sem_init' is deprecated
  [-Wdeprecated-declarations]
rc = sem_init(semdata->handle, 0, 0);
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note: 
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:40:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:729:5:
 warning: 'sem_init' is deprecated
  [-Wdeprecated-declarations]
sem_init(semdata->handle, 1, 0);
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:55:42:
 note: 
  'sem_init' has been explicitly marked deprecated here
int sem_init(sem_t *, int, unsigned int) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:40:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:775:13:
 warning: 'sem_destroy' is deprecated
  [-Wdeprecated-declarations]
if (sem_destroy(semdata->handle))
^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/semaphore.h:53:26:
 note: 
  'sem_destroy' has been explicitly marked deprecated here
int sem_destroy(sem_t *) __deprecated;
 ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:176:40:
 note: 
  expanded from macro '__deprecated'
#define __deprecated__attribute__((deprecated))
   ^

/Users/rony/dev/oorexx_allura/main/trunk/interpreter/platform/unix/SysRexxUtil.cpp:889:14:
 warning: 'sem_init' is deprecated
  [-Wdeprecated-declarations]
   

Re: [Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-09 Thread Rony G. Flatscher
<https://sourceforge.net/p/oorexx/code-0/11856> fixes NewRoutine(), 
LoadPackageFromDate() and also
the Routine's class method newFile() when employed with 
rexxc-tokenized/compiled code, thank you
very much!

---

Unfortunately, running rexxc-tokenized/compiled scripts via the Java scripting 
framework does not
work as apprehended in my last post and causes the following runtime error:

G:\test\oorexx\rexxc>rexxj test.rexx
RexxDispatcher.java: Throwable of type 
'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx:
getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9:
Rexx traceback line not available from the Rexx condition object (Rexx 
condition may have been caused by a call or message from Java to Rexx)
Error 3 running  line 0:  Failure during initialization.
Error 3.903:  Program "G:\test\oorexx\rexxc\test.rexx" cannot be run by 
this version of the REXX interpreter.]

(The error text within the square brackets gets created in native code from the 
Rexx condition
object. The 'getLocalizedMessage():' right before the opening square bracket 
seems to come from
ooRexx, it is not used in the native code.)

The reason for this runtime error with rexxc-tokenized/compiled code is caused 
by the implicitly
employed Java Reader object for reading the content of a file, changing the 
tokenized/compiled
binary data by applying codepage translations. (There are no Java based 
scripting frameworks that
would allow using a Stream for reading binary script data, unfortunately.)

---rony


On 07.04.2019 15:33, Rony G. Flatscher wrote:
> ... cut ...
>
> ---
>
> *Unfortunately*, there is one principal huge problem left with 
> compiled/tokenized Rexx code, that
> is beyond BSF4ooRexx' ability to solve for good: BSF4ooRexx uses two Java 
> scripting frameworks,
> one originating from IBM (DeveloperWorks) which got handed over to the ASF 
> named "BSF" (Bean
> Scripting Framework), one originating from Java itself which got introduced 
> later as the "Java
> scripting framework" in Java 1.6/6.0 (package named "javax.script", the URL 
> to the package
> documentation 
> <https://docs.oracle.com/javase/8/docs/api/javax/script/package-summary.html>).
>
> BSF4ooRexx implements under the name "RexxScript" the javax.script scripting 
> framework, which
> makes it e.g. possible for JavaFX to denote the programming language "rexx" 
> in the FXML files that
> define the GUI. The FXMLLoader class will therefore be able to create an 
> ooRexx interpreter with
> the help of "javax.script" and execute the code in any given files or Rexx 
> code supplied verbaitm
> in event attributes of JavaFX GUI elements.
>
> The Java documentation for the javax.script.Engine interface that must be 
> (and has been)
> implemented can be found here:
> <https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html>. 
> Executing ooRexx code
> from Java will be done with one of the eval() methods which either expect a 
> /java.lang.String/ or
> a /java.io.Reader/ object that represents the code to execute.
>
> A Java /Reader /will expect plain text to be read/and applies codepage 
> translations/ if necessary!
> This means that a /Reader /object if reading compiled/tokenized Rexx code 
> might transform the
> binary data! With other words, it is quite likely that compiled/tokenized 
> (binary data) Rexx code
> read by Java from a file with a /Reader/ gets destroyed by applying 
> mistakingly code-page
> translations to that binary data! :-((
>
> ---
>
> A maybe feasible solution could be to apply c2x() to the binary data that 
> results when applying
> "rexxc" and store that data right after the eye-catcher string "/**/@REXX" 
> that indicates that the
> remaining data represents the compiled/tokenized version of a Rexx program. 
> Upon loading, that
> hexadecimal string representing the binary data could be changed back to the 
> original binary
> representation with x2c() before processing it.
>
> This way all the Java defined String/Reader based interfaces would keep 
> working and there would be
> no risk whatsoever, that automatically applied codepage translations could 
> ruin/destroy the binary
> data as that data would be turned into plain text by c2x()!
>
> I would file a short RFE to this effect, but wanted to give "the long story" 
> (trying to explain
> the background and why it would be very important for allowing the Java 
> scripting frameworks to be
> applied safely to compiled/tokenized Rexx code as well) here.
>
> ---rony
>

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


[Oorexx-devel] Ad compiled/tokenized Rexx code (rexxc) ...

2019-04-07 Thread Rony G. Flatscher
In the past days I got problem reports from a professional developer who 
exclusively uses ooRexx and
for his rather complex GUIs he uses the portable JavaFX libraries via 
BSF4ooRexx. Everything has
worked out fine it seems, using ooRexx 5.0beta and BSF4ooRexx.

However,  since he started to use "rexxc" to compile/tokenize all of the Rexx 
source files that
comprise his elaborate application to shelter his code, he has started to run 
into abends/errors
13.1. This was the kick-off to analyze the code paths of BSF4ooRexx and getting 
to the ooRexx native
APIs NewRoutine() and LoadPackageFromData() that currently cause that error. 
Once these native APIs
become able to process compiled/tokenized Rexx code like LoadPackage(), these 
errors will go away.

---

*Unfortunately*, there is one principal huge problem left with 
compiled/tokenized Rexx code, that is
beyond BSF4ooRexx' ability to solve for good: BSF4ooRexx uses two Java 
scripting frameworks, one
originating from IBM (DeveloperWorks) which got handed over to the ASF named 
"BSF" (Bean Scripting
Framework), one originating from Java itself which got introduced later as the 
"Java scripting
framework" in Java 1.6/6.0 (package named "javax.script", the URL to the 
package documentation
).

BSF4ooRexx implements under the name "RexxScript" the javax.script scripting 
framework, which makes
it e.g. possible for JavaFX to denote the programming language "rexx" in the 
FXML files that define
the GUI. The FXMLLoader class will therefore be able to create an ooRexx 
interpreter with the help
of "javax.script" and execute the code in any given files or Rexx code supplied 
verbaitm in event
attributes of JavaFX GUI elements.

The Java documentation for the javax.script.Engine interface that must be (and 
has been) implemented
can be found here: 
.
Executing ooRexx code from Java will be done with one of the eval() methods 
which either expect a
/java.lang.String/ or a /java.io.Reader/ object that represents the code to 
execute.

A Java /Reader /will expect plain text to be read/and applies codepage 
translations/ if necessary!
This means that a /Reader /object if reading compiled/tokenized Rexx code might 
transform the binary
data! With other words, it is quite likely that compiled/tokenized (binary 
data) Rexx code read by
Java from a file with a /Reader/ gets destroyed by applying mistakingly 
code-page translations to
that binary data! :-((

---

A maybe feasible solution could be to apply c2x() to the binary data that 
results when applying
"rexxc" and store that data right after the eye-catcher string "/**/@REXX" that 
indicates that the
remaining data represents the compiled/tokenized version of a Rexx program. 
Upon loading, that
hexadecimal string representing the binary data could be changed back to the 
original binary
representation with x2c() before processing it.

This way all the Java defined String/Reader based interfaces would keep working 
and there would be
no risk whatsoever, that automatically applied codepage translations could 
ruin/destroy the binary
data as that data would be turned into plain text by c2x()!

I would file a short RFE to this effect, but wanted to give "the long story" 
(trying to explain the
background and why it would be very important for allowing the Java scripting 
frameworks to be
applied safely to compiled/tokenized Rexx code as well) here.

---rony


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


Re: [Oorexx-devel] Findings (Re: Question ad native API for creating routine and package objects ...

2019-04-07 Thread Rony G. Flatscher
On 06.04.2019 22:42, Rick McGuire wrote:
>
>
> On Sat, Apr 6, 2019 at 12:00 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Findings:
>
>   * NewRoutine(name,code,sz) and LoadPackageFromData(name,data,sz) behave 
> the same (including
> not running the prolog code)
>   o both are able to load plain Rexx source code,
>   o both fail for 'rexxc'-tokenized Rexx code (e.g. loaded from a 
> file or a database with
> tokenized Rexx code);
>   + will therefore file bugs for these two native APIs
>
>   * LoadPackage(filename): works for both, source code and tokenized code;
>   o however, unlike LoadPackageFromData() it will run the prolog code 
> automatically; not
> sure whether this intentional or a bug
>
> LoadPackageFromData() is the bug. The prolog should always be run with 
> package loading operations.

While filing a bug, I re-executed the test script once more, just to find out 
today that I would run
the LoadPackage() and LoadPackageFromData() tests from the same script with the 
same Rexx program
(same names). It seems that LoadPackage*() has the requires semantics, such 
that the prolog gets run
only the very first time the package gets loaded (and merely reused each time a 
LoadPackage*() gets
issued with the same name later).

With other words: LoadPackageFromData() *does* run the prolog code, if the Rexx 
script gets loaded
the first time by it! So this works as designed and there is no bug there I 
assume.

---rony


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


[Oorexx-devel] Findings (Re: Question ad native API for creating routine and package objects ...

2019-04-06 Thread Rony G. Flatscher
Findings:

  * NewRoutine(name,code,sz) and LoadPackageFromData(name,data,sz) behave the 
same (including not
running the prolog code)
  o both are able to load plain Rexx source code,
  o both fail for 'rexxc'-tokenized Rexx code (e.g. loaded from a file or a 
database with
tokenized Rexx code);
  + will therefore file bugs for these two native APIs

  * LoadPackage(filename): works for both, source code and tokenized code;
  o however, unlike LoadPackageFromData() it will run the prolog code 
automatically; not sure
whether this intentional or a bug

---rony


On 06.04.2019 14:24, Rony G. Flatscher wrote:
> On 06.04.2019 14:22, Rick McGuire wrote:
>> I'd say you should be able to. Whether you can or not is a question for some 
>> experimentation.
>
> Thank you, will start the experimentations then and report back.
>
> ---rony
>
>>
>> On Sat, Apr 6, 2019 at 8:13 AM Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> In the native APIs these methods are available for creating Rexx routine 
>> and package objects:
>>
>>  1. NewRoutine(name, code, sz), where 'name' and 'code' are of type 
>> CSTRING, 'sz' of type size_t
>>   * Question: can 'code' be any representation of a Rexx program, 
>> i.e. can one also
>> supply the tokenized/compiled code?
>>
>>  2. LoadPackage(name), where name is of type CSTRING and denotes the 
>> filename
>>
>>   * Question: can the file's content be any representation of a Rexx 
>> program, i.e. can
>> one also supply the tokenized/compiled code?
>>
>>  1. LoadPackageFromData(name,data,sz), where 'name' and 'data' are of 
>> type CSTRING, 'sz' of
>> type size_t
>>   * Question: can 'data' be any representation of a Rexx program, 
>> i.e. can one also
>> supply the tokenized/compiled code?
>>
>> ---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 for creating routine and package objects ...

2019-04-06 Thread Rony G. Flatscher
On 06.04.2019 14:22, Rick McGuire wrote:
> I'd say you should be able to. Whether you can or not is a question for some 
> experimentation.

Thank you, will start the experimentations then and report back.

---rony

>
> On Sat, Apr 6, 2019 at 8:13 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> In the native APIs these methods are available for creating Rexx routine 
> and package objects:
>
>  1. NewRoutine(name, code, sz), where 'name' and 'code' are of type 
> CSTRING, 'sz' of type size_t
>   * Question: can 'code' be any representation of a Rexx program, 
> i.e. can one also supply
> the tokenized/compiled code?
>
>  2. LoadPackage(name), where name is of type CSTRING and denotes the 
> filename
>
>   * Question: can the file's content be any representation of a Rexx 
> program, i.e. can one
> also supply the tokenized/compiled code?
>
>  1. LoadPackageFromData(name,data,sz), where 'name' and 'data' are of 
> type CSTRING, 'sz' of
> type size_t
>   * Question: can 'data' be any representation of a Rexx program, 
> i.e. can one also supply
> the tokenized/compiled code?
>
> ---rony
>

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


[Oorexx-devel] Question ad native API for creating routine and package objects ...

2019-04-06 Thread Rony G. Flatscher
In the native APIs these methods are available for creating Rexx routine and 
package objects:

 1. NewRoutine(name, code, sz), where 'name' and 'code' are of type CSTRING, 
'sz' of type size_t
  * Question: can 'code' be any representation of a Rexx program, i.e. can 
one also supply the
tokenized/compiled code?

 2. LoadPackage(name), where name is of type CSTRING and denotes the filename

  * Question: can the file's content be any representation of a Rexx 
program, i.e. can one also
supply the tokenized/compiled code?

 1. LoadPackageFromData(name,data,sz), where 'name' and 'data' are of type 
CSTRING, 'sz' of type size_t
  * Question: can 'data' be any representation of a Rexx program, i.e. can 
one also supply the
tokenized/compiled code?

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


Re: [Oorexx-devel] How about adding "rxSnippets" to the ooRexx distribution ? Also ad Windows: split "api" into "include" and "lib"? ((Re: How to build external functions using cmake

2019-03-22 Thread Rony G. Flatscher
Hi Enrico,

thank you for your update! The Windows installation of ooRexx indeed sets an 
environment variable
named "REXX_HOME" that points to the installation location, which depends on 
the bitness of ooRexx.
(And on Windows instead of using $REXX_HOME one needs to enclose the 
environment variable into
percent signs, hence %REXX_HOME% in some batch scripts.)

HTH,

---rony


On 22.03.2019 18:11, Enrico Sorichetti via Oorexx-devel wrote:
> Hello Rony
>
> I just added  
>
> -DOOREXX_INCLUDE_DIR=...
> -DOOREXX_LIB_DIR=...
>
> handling
>
> for the include/lib directories
>
> e
>
> P.S
>
> If the REXX_HOME is an environment variable 
> I could pick up the info from there 
>
> Please let know and I will fix it
>
>
>> On 22 Mar 2019, at 17:34, Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> It works (except for Windows) out of the box on Linux, Darwin, . The Windows 
>> part has currently
>> the problem that the "include" and "lib" directories are folded into the 
>> "%REXX_HOME%\api"
>> directory. Therefore I would suggest to remove "api" and split its contents 
>> accordingly into the
>> new subdirectories "%REXX_HOME%\include" (containing the *.h files) and 
>> "%REXX_HOME%\lib"
>> (containing the *.lib files).
>>

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


[Oorexx-devel] How about adding "rxSnippets" to the ooRexx distribution ? Also ad Windows: split "api" into "include" and "lib"? ((Re: How to build external functions using cmake

2019-03-22 Thread Rony G. Flatscher
Hi there,

Enrico's "rxSnippets" are just great, IMHO!

They provide a working CMake nutshell example that can be used to compile 
external Rexx function
libraries according to the SAA or the ooRexx native APIs *on all operating 
system platforms* from
*one* CMakeLists.txt!

It works (except for Windows) out of the box on Linux, Darwin, . The Windows 
part has currently the
problem that the "include" and "lib" directories are folded into the 
"%REXX_HOME%\api" directory.
Therefore I would suggest to remove "api" and split its contents accordingly 
into the new
subdirectories "%REXX_HOME%\include" (containing the *.h files) and 
"%REXX_HOME%\lib" (containing
the *.lib files).

Alternatively, one could probably add code to test on Windows only whether 
"include" and "lib"
exist, and if not, use "api" instead for both.

Any interested developer who wants to create external Rexx function libraries 
can see and learn the
gist of what is needed to do so. *Much* better than the existing examples on 
Windows in
"samples/api" which are restricted to Windows only.

So I would *love* to see Enrico's "rxSnippets" distributed with ooRexx to ease 
the creation of
external function packages considerably!

Also, as mentioned, it would be great IMHO if on Windows the "api" directory 
gets split up into
"include" and "lib" as then Enrico's CMakeLists.txt would work out of the box 
for Windows as well!

---rony



On 17.02.2019 19:09, Enrico Sorichetti via Oorexx-devel wrote:
>
> See here 
>
> git clone http://3...@bitbucket.org/3481/rxSnippets
>
>
> Have a good time 
>
> Tested only on Darwin 
>
> Working on the other platforms 
>
> I will keep You posted
>
> cheers
>
> E 

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


Re: [Oorexx-devel] Going to be away for a little while.

2019-03-18 Thread Rony G. Flatscher
On 18.03.2019 08:26, Rick McGuire wrote:
> Getting ready to head off on a little vacation. I'll be way until March 28th. 
> I'll be checking
> email while gone, but mostly on my phone, so if I respond to anything, it 
> will probably be short
> and brief. I won't be able to work on any problems until I return.

Have a great trip!

---rony




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


Re: [Oorexx-devel] A new draft/sketch for documenting the new classes EventSemaphore and MutexSemaphore (Re: A sketch for a documentation text for the "EventSemaphore" class

2019-03-14 Thread Rony G. Flatscher
On 14.03.2019 18:10, Rick McGuire wrote:
> A couple of notes that need to added to the MutexSemaphore section
>
> 1) On a single thread, acquire requests nests, so if a thread calls acquire 
> again while already
> having obtained the semaphore, it will be not blocked. It requires an 
> equivalent number of release
> calls to free up the mutex. 
>
> 2) If the thread holding the mutex ends without releasing the semaphore, the 
> semaphore will be
> released automatically.
>
> Rick 

Thanks, this version now includes this information in the "acquire" part:


===
5.4.x EventSemaphore Class

Semaphores get used in multithreaded scenarios.

An "event semaphore" allows one thread "A" to synchronize multiple threads
(like "B", "C", ...) with whom the event semaphore gets shared.  Thread
"A" creates the event semaphore and sends it the "reset" message.  Then
thread "A" supplies the event semaphore to the threads "B", "C", ..., each
of which sends the received event semaphore a "wait" message.  This will
block the threads "B", "C", ..., until thread "A" sends the "post" message
to the event semaphore.  At this time all threads waiting on the event
semaphore get released and can run in parallel on their threads.

5.4.x.1 close

>>--- close ---><

Closes the event semaphore.


5.4.x.2 isPosted

>>--- isPosted ---><

Returns .true if the event semaphore is in the "posted" state, such that
sending the "wait" message to this event semaphore would return
immediately.  A return value of .false indicates that the event semaphore
is not in the "posted" state, such that a "wait" message will block.


5.4.x.3 post

>>--- post ---><

Sets the event semaphore to the "posted" state, signalling that the event
that other threads are waiting on has occurred, such that all threads
waiting on this event semaphore will be released and start to run again.


5.4.x.4 reset

>>--- reset ---><

Resets (clears) the event semaphore to the non-"posted" state, such that 
"wait"
messages to this event semaphore will block.


5.4.x.5 uninit

>>--- uninit ---><

This method cleans up the object when it is garbage collected.  It should
not be invoked directly except via an uninit method of a subclass of the
EventSemaphore class.


5.4.x.6 wait

>>--- wait(--+-+--)---><
 | |
 +-- timeout --+

Waits (blocks) on the event semaphore until it gets "posted".  If the
optional argument "timeout" was supplied it must be a whole number that
represents the milliseconds to wait on the event semaphore before
returning.


If no "timeout" value was supplied or its value is negative, the wait will
be forever, ie. until the event semaphore gets "posted".

If the "timeout" value is zero the method returns immediately with the
same value that the method "isPosted" would return if sent to the event
semaphore instead.

The method returns .true if the event semaphore got "posted", .false if
the method returns prematurely because the given timeout has occurred.


Example 5.xxx

The following example will fetch the routine object "WORKER" and in a loop
will send the routine object the message "start" (defined in the ooRexx
root class "Object") supplying the message name ("call") to be sent on a
new (asynchroneous) thread, and as arguments the event semaphore to wait
on and the number of the loop for the respective asynchroneous message.

The main program creates an event semaphore and sends the message "reset"
to it.  Then it sends the "start" message three times to the routine
object in the loop, causing the routine "worker" to run on three different
threads, where in each thread the executed routine then waits on the event
semaphore ("wait" message to the event semaphore).  The main program then
sleeps for five seconds, before sending the "post" message to the event
semaphore, which will awake the routines on the three threads, ie.  they
return from the wait message and execute on their threads in parallel,
causing each to sleep for two seconds before returning from the routine
invocation.


eventSem=.eventSemaphore~new  -- create an event semaphore, will be 
in posted state
dt=.dateTime~new -- a .DateTime object to allow measuring 
elapsed time
say "/main\ "  pp(dt~elapsed) "currently 'eventSem~isPosted':" 
pp(eventSem~isPosted)
eventSem~reset   -- reset event semaphore, such that "wait" 
will block
say "/main\ "  pp(dt~elapsed) "after 'eventSem~reset', 
'eventSem~isPosted':" pp(eventSem~isPosted)

w=.routines~waiter   -- get routine 'WAITER' as a routine object
do i=1 to 3
   

[Oorexx-devel] A new draft/sketch for documenting the new classes EventSemaphore and MutexSemaphore (Re: A sketch for a documentation text for the "EventSemaphore" class

2019-03-14 Thread Rony G. Flatscher
O.K., got some time for MutexSemaphore and in the course of writing it, I 
corrected the draft for
EventSemaphore as well, including the code sample.

Therefore, here the suggestions/drafts for documenting the two classes 
"EventSemaphore" and
"MutexSemaphore":


===
5.4.x EventSemaphore Class

Semaphores get used in multithreaded scenarios.

An "event semaphore" allows one thread "A" to synchronize multiple threads
(like "B", "C", ...) with whom the event semaphore gets shared.  Thread
"A" creates the event semaphore and sends it the "reset" message.  Then
thread "A" supplies the event semaphore to the threads "B", "C", ...,
which each send the received event semaphore a "wait" message.  This will
block the threads "B", "C", ..., until thread "A" sends the "post" message
to the event semaphore.  At this time all threads waiting on the event
semaphore get released and can run in parallel on their threads.

5.4.x.1 close

>>--- close ---><

Closes the event semaphore.


5.4.x.2 isPosted

>>--- isPosted ---><

Returns .true if the event semaphore is in the "posted" state, such that
sending the "wait" message to this event semaphore would return
immediately.  A return value of .false indicates that the event semaphore
is not in the "posted" state, such that a "wait" message will block.


5.4.x.3 post

>>--- post ---><

Sets the event semaphore to the "posted" state, signalling that the event
that other threads are waiting on has occurred, such that all threads
waiting on this event semaphore will be released and start to run again.


5.4.x.4 reset

>>--- reset ---><

Resets (clears) the event semaphore to the non-"posted" state, such that 
"wait"
messages to this event semaphore will block.


5.4.x.5 uninit

>>--- uninit ---><

This method cleans up the object when it is garbage collected.  It should
not be invoked directly except via an uninit method of a subclass of the
EventSemaphore class.


5.4.x.6 wait

>>--- wait(--+-+--)---><
 | |
 +-- timeout --+

Waits (blocks) on the event semaphore until it gets "posted".  If the
optional argument "timeout" was supplied it must be a whole number that
represents the milliseconds to wait on the event semaphore before
returning.


If no "timeout" value was supplied or its value is negative, the wait will
be forever, ie. until the event semaphore gets "posted".

If the "timeout" value is zero the method returns immediately with the
same value that the method "isPosted" would return if sent to the event
semaphore instead.

The method returns .true if the event semaphore got "posted", .false if
the method returns prematurely because the given timeout has occurred.


Example 5.xxx

The following example will fetch the routine object "WORKER" and in a loop
will send the routine object the message "start" (defined in the ooRexx
root class "Object") supplying the message name ("call") to be sent on a
new (asynchroneous) thread, and as arguments the event semaphore to wait
on and the number of the loop for the respective asynchroneous message.

The main program creates an event semaphore and sends the message "reset"
to it.  Then it sends the "start" message three times to the routine
object in the loop, causing the routine "worker" to run on three different
threads, where in each thread the executed routine then waits on the event
semaphore ("wait" message to the event semaphore).  The main program then
sleeps for five seconds, before sending the "post" message to the event
semaphore, which will awake the routines on the three threads, ie.  they
return from the wait message and execute on their threads in parallel,
causing each to sleep for two seconds before returning from the routine
invocation.


eventSem=.eventSemaphore~new  -- create an event semaphore, will be 
in posted state
dt=.dateTime~new -- a .DateTime object to allow measuring 
elapsed time
say "/main\ "  pp(dt~elapsed) "currently 'eventSem~isPosted':" 
pp(eventSem~isPosted)
eventSem~reset   -- reset event semaphore, such that "wait" 
will block
say "/main\ "  pp(dt~elapsed) "after 'eventSem~reset', 
'eventSem~isPosted':" pp(eventSem~isPosted)

w=.routines~waiter   -- get routine 'WAITER' as a routine object
do i=1 to 3
   say "/main\ "  pp(dt~elapsed)   "running routine 'WAITER' #" 
pp(i) "asynchroneously"
   w~start("call", eventSem, i)  -- call (run) the routine object 
on a separate thread
end
say

sleepTime=5
say "/main\ "  pp(dt~elapsed)  

[Oorexx-devel] A sketch for a documentation text for the "EventSemaphore" class

2019-03-13 Thread Rony G. Flatscher
Tried to come up with a text for the documentation for the EventSemaphore class.

Please check the raildiagrams and descriptions for the methods.

Also please note that the example got simplified in the formatting somewhat 
(e.g. the date portion
is not used anymore, making the output better legible and also will not "age" 
because in five years
the dates look "outdated").

Any errors and/or bad English are mine only!
;)

Please let me know whether this is helpful or not. If so, I will try to come up 
with the text for
the MutexSemaphore class in the next days.

Here it goes:


===
5.4.x EventSemaphore Class

Semaphores get used in multithreaded scenarios.

An "event semaphore" allows one thread "A" to synchronize multiple threads
(like "B", "C", ...) with whom the event semaphore gets shared.  Thread
"A" creates the event semaphore and sends it the "reset" message.  Then
thread "A" supplies the event semaphore to the threads "B", "C", ...,
which each send the received event semaphore a "wait" message.  This will
block the threads "B", "C", ..., until thread "A" sends the "post" message
to the event semaphore.  At this time all threads waiting on the event
semaphore get released and can run in parallel on their threads.

5.4.x.1 close

>>--- close ---><

Closes the event semaphore.


5.4.x.2 isPosted

>>--- isPosted ---><

Returns .true if the event semaphore is in the "posted" state, such that
sending the "wait" message to this event semaphore would return
immediately.  A return value of .false indicates that the event semaphore
is not in the "posted" state, such that a "wait" message will block.


5.4.x.2 post

>>--- post ---><

Sets the event semaphore to the "posted" state, signalling that the event
that other threads are waiting on has occurred, such that all threads
waiting on this event semaphore will be released and start to run again.


5.4.x.3 reset

>>--- reset ---><

Resets (clears) the event semaphore to the non-"posted" state, such that 
"wait"
messages to this event semaphore will block.


5.4.x.4 uninit

>>--- uninit ---><

This method cleans up the object when it is garbage collected.  It should
not be invoked directly except via an uninit method of a subclass of the
EventSemaphore class.


5.4.x.5 wait

>>--- wait(--+-+--)---><
 | |
 +-- timeout --+

Waits (blocks) on the event semaphore until it gets "posted".  If
"timeout" was supplied it must be a whole number that represents the
milliseconds to wait on the event semaphore before returning.


If no "timeout" value was supplied or its value is negative, the wait will
be forever, ie. until the event semaphore gets posted.

If the "timeout" value is zero the method returns immediately with the
same value that the method "isPosted" would return if sent to the event
semaphore instead.

The method returns .true if the event semaphore got "posted", .false if
the method returns prematurely because the given timeout has occurred.


Example 5.xxx

The following example will fetch the routine object "WORKER" and in a loop
will send the routine object the message "start" (defined in the ooRexx
root class "Object") supplying the message name ("call") to be sent on a
new (asynchroneous) thread, and as arguments the event semaphore to wait
on and the number of the loop for the respective asynchroneous message.

The main program creates an event semaphore and sends the message "reset"
to it.  Then it sends the "start" message three times to the routine
object in the loop, causing the routine "worker" to run on three different
threads, where in each thread the executed routine then waits on the event
semaphore ("wait" message to the event semaphore).  The main program then
sleeps for five seconds, before sending the "post" message to the event
semaphore, which will awake the routines on the three threads, ie.  they
return from the wait message and execute on their threads in parallel,
causing each to sleep for two seconds before returning from the routine
invocation.


eventSem=.eventSemaphore~new  -- create an event semaphore, will be 
in posted state
dt=.dateTime~new -- a .DateTime object to allow measuring 
elapsed time
say "/main\ "  pp(dt~elapsed) "currently 'eventSem~isPosted':" 
pp(eventSem~isPosted)
eventSem~reset   -- reset event semaphore, such that "wait" 
will block
say "/main\ "  pp(dt~elapsed) "after 'eventSem~reset', 
'eventSem~isPosted':" pp(eventSem~isPosted)

w=.routines~waiter   -- get routine 'WAITER' as a routine object
do i=1 to 3
   say 

[Oorexx-devel] Building r11834 on 32-bit Windows: two warnings

2019-03-11 Thread Rony G. Flatscher
While building the r11834 for 32-bit Windows the following two warnings get 
issued:

win32
-

... cut ...
[ 59%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/runtime/RexxUtilCommon.cpp.obj
RexxUtilCommon.cpp
F:\work\svn\oorexx\main\trunk\interpreter\runtime\RexxUtilCommon.cpp(100): 
warning C4244: '=': conversion from 'int64_t' to 'std::size_t', possible loss 
of data
F:\work\svn\oorexx\main\trunk\interpreter\runtime\RexxUtilCommon.cpp(1905): 
warning C4018: '<': signed/unsigned mismatch
F:\work\svn\oorexx\main\trunk\interpreter\runtime\RexxUtilCommon.cpp(2252): 
warning C4018: '<': signed/unsigned mismatch
F:\work\svn\oorexx\main\trunk\interpreter\runtime\RexxUtilCommon.cpp(2293): 
warning C4018: '<': signed/unsigned mismatch

... cut ...
[ 77%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.obj
cmdparse.cpp
..\..\cmdparse.cpp(1152): warning C4065: switch statement contains 
'default' but no 'case' labels
..\..\cmdparse.ypp(370): warning C4018: '<': signed/unsigned mismatch

Building for 64-bit Windows is successful without any warnings.

---rony





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


Re: [Oorexx-devel] Ad new classes .eventSemaphore and .mutexSemaphore (Re: An example of the new counter modifier on loops ...

2019-03-08 Thread Rony G. Flatscher
Rick,
 
thank you very much for your kind words and the important correction!

If deemed helpful how about adopting the text and the sample for the 
documentation? Although I
cannot directly supply a suitable patch (not being able to use the publishing 
infrastructure) I
could try to edit the text and simplify the examples a little bit more to meet 
the documentation style.

---rony

P.S.: If it was possible to use reply in normal routines would allow to 
simplify even more (and put
other languages into shade :) ).

On 08.03.2019 00:10, Rick McGuire wrote:
> Rony, 
>
> An excellent write up here. One small correction I would make, when 
> MutexSempahores have multiple
> waiters, they are not necessarily queued. Which waiting thread gets the mutex 
> next is determined
> by the OS dispatch mechanisms, so which thread gets it next is not 
> predictable. 
>
> Rick
>
> On Thu, Mar 7, 2019 at 12:13 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> To run the example programs you would need a version of ooRexx from 
> "sandbox/rick/sem". The
> 32-bit Windows "sandbox/rick/sem" version of ooRexx can be temporarily 
> found here:
> 
> <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>
> 
> <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.
>
> ---
>
> Prologue
> 
>
> Semaphores get used in multithreaded scenarios. As ooRexx allows one to 
> run method routines on
> different threads in parallel, semaphores could come in handy.
>
> Even regular ooRexx routines can be called asynchroneously, such that one 
> can write a Rexx
> routine (using the "::routine" directive) and run it on a different 
> thread. This is done by
> fetching the routine object from the .routines directory (this directory 
> is set up by the
> interpreter and makes all routines of the Rexx program available to the 
> programmer). To
> invoke/run a routine object one sends it the "call" message. If arguments 
> should be supplied
> then one mereley adds them.
>
> The following two Rexx samples, one demonstrating an eventSemaphore, one 
> a mutexSemaphore,
> fetch the routine object representing the "::routine worker" routine. The 
> routine object gets
> asynchroneously run (executed on another thread in parallel to the main 
> thread) by using the
> start-message (defined in the root class object), which expects the name 
> of the method to send
> asynchroneously (in this case "call", which runs the routine) and 
> optionally arguments (in
> this case the semaphore and the invocation number for sending the "call" 
> message
> asynchroneously).
>
> The example programs may look a little bit weird, because the output 
> should be formatted in a
> way that makes it rather easy to find the output from the main thread and 
> the output from the
> three worker threads (the "worker" object gets three 'call' messages sent 
> in a loop causing
> three threads to be created on which the routine object gets executed).
>
> 
> 
>
> EventSemaphore
>
> ---
>
> An "event semaphore" allows one thread "A" to synchronize multiple 
> threads (like "B", "C",
> ...) with whom the event semaphore gets shared. Thread "A" creates the 
> event semaphore and
> sends it the "reset" message. Then thread "A" supplies the event 
> semaphore to the threads "B",
> "C", ..., which each send the received event semaphore a "wait" message. 
> This will block the
> threads "B", "C", ..., until thread "A" sends the "post" message to the 
> event semaphore. At
> this time all threads waiting on the event semaphore get released and can 
> run in parallel on
> their threads.
>
> Using introspection on the new class "EventSemaphore" the following 
> methods are currently
> defined for it: "close", "isPosted", "post", "reset", "wait".
>
> The following example will fetch the routine object "WORKER" and in a 
> loop will send the
> routine object the message "start" (defined in the ooRexx root class 
> "Object") supplying the
> message name ("call") to be sent on a new (asynchroneous) thread, and

[Oorexx-devel] Ad new classes .eventSemaphore and .mutexSemaphore (Re: An example of the new counter modifier on loops ...

2019-03-07 Thread Rony G. Flatscher
To run the example programs you would need a version of ooRexx from 
"sandbox/rick/sem". The 32-bit
Windows "sandbox/rick/sem" version of ooRexx can be temporarily found here:
.

---

Prologue


Semaphores get used in multithreaded scenarios. As ooRexx allows one to run 
method routines on
different threads in parallel, semaphores could come in handy.

Even regular ooRexx routines can be called asynchroneously, such that one can 
write a Rexx routine
(using the "::routine" directive) and run it on a different thread. This is 
done by fetching the
routine object from the .routines directory (this directory is set up by the 
interpreter and makes
all routines of the Rexx program available to the programmer). To invoke/run a 
routine object one
sends it the "call" message. If arguments should be supplied then one mereley 
adds them.

The following two Rexx samples, one demonstrating an eventSemaphore, one a 
mutexSemaphore, fetch the
routine object representing the "::routine worker" routine. The routine object 
gets asynchroneously
run (executed on another thread in parallel to the main thread) by using the 
start-message (defined
in the root class object), which expects the name of the method to send 
asynchroneously (in this
case "call", which runs the routine) and optionally arguments (in this case the 
semaphore and the
invocation number for sending the "call" message asynchroneously).

The example programs may look a little bit weird, because the output should be 
formatted in a way
that makes it rather easy to find the output from the main thread and the 
output from the three
worker threads (the "worker" object gets three 'call' messages sent in a loop 
causing three threads
to be created on which the routine object gets executed).



EventSemaphore

---

An "event semaphore" allows one thread "A" to synchronize multiple threads 
(like "B", "C", ...) with
whom the event semaphore gets shared. Thread "A" creates the event semaphore 
and sends it the
"reset" message. Then thread "A" supplies the event semaphore to the threads 
"B", "C", ..., which
each send the received event semaphore a "wait" message. This will block the 
threads "B", "C", ...,
until thread "A" sends the "post" message to the event semaphore. At this time 
all threads waiting
on the event semaphore get released and can run in parallel on their threads.

Using introspection on the new class "EventSemaphore" the following methods are 
currently defined
for it: "close", "isPosted", "post", "reset", "wait".

The following example will fetch the routine object "WORKER" and in a loop will 
send the routine
object the message "start" (defined in the ooRexx root class "Object") 
supplying the message name
("call") to be sent on a new (asynchroneous) thread, and as arguments the event 
semaphore to wait on
and the number of the loop for the respective asynchroneous message.

The main program creates an event semaphore and sends the message "reset" to 
it. Then it sends the
"start" message three times to the routine object in the loop, causing the 
routine "worker" to run
on three different threads, where in each thread the executed routine then 
waits on the event
semaphore ("wait" message to the event semaphore). The main program then sleeps 
for five seconds,
before sending the "post" message to the event semaphore, which will awake the 
routines on the three
threads, ie. they return from the wait message and execute on their threads in 
parallel, causing
each to sleep for two seconds before returning from the routine invocation.

Here is the program "testEventSemaphore.rex":

/* ---rgf, 20190307, testing new class .EventSemaphore which defines the 
methods:
  close, isPosted, post, reset, wait
*/

eventSem=.eventSemaphore~new
say "/main\"~left(11,".")  pp(.dateTime~new) 
"eventSem~isPosted="pp(eventSem~isPosted)
eventSem~reset
say "/main\"~left(11,".")  pp(.dateTime~new) "after eventSem~reset, 
eventSem~isPosted="pp(eventSem~isPosted)

w=.routines~waiter  -- get routine object
do i=1 to 3
   say "main"~left(11,".")  "running routine 'WAITER' #" pp(i) 
"asynchroneously"
   w~start("call", eventSem, i)  -- run the routine object on a separate 
thread
end
say

sleepTime=5
say "/main\"~left(11,".")  pp(.dateTime~new) " sleeping" pp(sleepTime) 
"seconds ..."
call sysSleep sleepTime -- sleep five seconds

say "/main\"~left(11,".")  pp(.dateTime~new) " awoke, about doing an 
'eventSem~post' ..."
say
eventSem~post   -- stop any thread waiting on this event semaphore
say "\main/"~left(11,".")  pp(.dateTime~new) " leaving main."

::routine waiter
   use arg eventSem, nr
   s=.dateTime~new
   say .context~name" #" 

[Oorexx-devel] An example of the new counter modifier on loops ...

2019-03-06 Thread Rony G. Flatscher
The 32-bit Windows "sandbox/rick/sem" version of ooRexx can be temporarily 
found here:
.

To illustrate how the new COUNTER subkeyword/counter works here a little 
program first:

-- rgf, 2019-03-06

-- cf. 

en_spelling1908=("Actor", "Baker", "Canteen", "Diver", "Eagle", "Fisher",  -
 "Gangway", "Halliard", "Insect", "Jockey", "Knapsack",-
 "Lugger", "Musket", "Neptune", "Oyster", "Pistol",-
 "Quadrant", "Reefer", "Shipmate", "Topsail", "Unload",-
 "Vessel", "Windage", "Xray", "Yeoman", "Zebra")

en_spelling1969=("Alfa", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot",   -
 "Golf", "Hotel", "India", "Juliett", "Kilo", "Lima",  -
 "Mike", "November", "Oscar", "Papa", "Quebec", "Romeo",   -
 "Sierra", "Tango", "Uniform", "Victor", "Whiskey",-
 "X-ray", "Yankee", "Zulu")

en_spellings=(en_spelling1908, en_spelling1969)
en_spellings_years=("1908", "1969")

do counter c1 sp over en_spellings
   say c1". Spelling Alphabet from" en_spellings_years[c1]":"
   say
   do counter c2 char over sp
  say c1"."c2":" char
   end
   say "-"~copies(40)
end

Here the output when running the above program:

e:\DropBox\Dropbox\xfer\orx\beta\sandbox_ooRexx\misc_tests\counter>test1.rex
1. Spelling Alphabet from 1908:

1.1: Actor
1.2: Baker
1.3: Canteen
1.4: Diver
1.5: Eagle
1.6: Fisher
1.7: Gangway
1.8: Halliard
1.9: Insect
1.10: Jockey
1.11: Knapsack
1.12: Lugger
1.13: Musket
1.14: Neptune
1.15: Oyster
1.16: Pistol
1.17: Quadrant
1.18: Reefer
1.19: Shipmate
1.20: Topsail
1.21: Unload
1.22: Vessel
1.23: Windage
1.24: Xray
1.25: Yeoman
1.26: Zebra

2. Spelling Alphabet from 1969:

2.1: Alfa
2.2: Bravo
2.3: Charlie
2.4: Delta
2.5: Echo
2.6: Foxtrot
2.7: Golf
2.8: Hotel
2.9: India
2.10: Juliett
2.11: Kilo
2.12: Lima
2.13: Mike
2.14: November
2.15: Oscar
2.16: Papa
2.17: Quebec
2.18: Romeo
2.19: Sierra
2.20: Tango
2.21: Uniform
2.22: Victor
2.23: Whiskey
2.24: X-ray
2.25: Yankee
2.26: Zulu


e:\DropBox\Dropbox\xfer\orx\beta\sandbox_ooRexx\misc_tests\counter>

That is really a very useful addition, thank you very much!

---rony

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


Re: [Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

2019-03-06 Thread Rony G. Flatscher
Did another update (to 11825) and now it builds successfully on 32-bit Windows 
with MSC!

Here the few warnings in case they occur on 32-bit only:

[ 59%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/runtime/RexxUtilCommon.cpp.obj
RexxUtilCommon.cpp

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\runtime\RexxUtilCommon.cpp(100):
 warning C4244: '=': conversion from 'int64_t' to 'std::size_t', possible loss 
of data

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\runtime\RexxUtilCommon.cpp(1905):
 warning C4018: '<': signed/unsigned mismatch

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\runtime\RexxUtilCommon.cpp(2252):
 warning C4018: '<': signed/unsigned mismatch

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\runtime\RexxUtilCommon.cpp(2293):
 warning C4018: '<': signed/unsigned mismatch
...

Scanning dependencies of target hostemu
[ 78%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/platform/windows/hostemu.cpp.obj
hostemu.cpp
[ 78%] Building CXX object 
CMakeFiles/hostemu.dir/extensions/hostemu/cmdparse.cpp.obj
cmdparse.cpp
..\..\cmdparse.cpp(1152): warning C4065: switch statement contains 
'default' but no 'case' labels
..\..\cmdparse.ypp(370): warning C4018: '<': signed/unsigned mismatch
...

[ 96%] Building CXX object 
testbinaries/CMakeFiles/orxexits.dir/orxinstance.cpp.obj
orxinstance.cpp
F:\work\svn\oorexx\sandbox\rick\sem\testbinaries\orxinstance.cpp(120): 
warning C4018: '<': signed/unsigned mismatch

---rony


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


Re: [Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

2019-03-06 Thread Rony G. Flatscher
Did a svn "update", here the result (warnings are gone, but still the error 
while building
"SysFileSystem" on 32-bit Windows:

F:\work\svn\oorexx>svn update
Updating '.':
Usandbox\rick\sem\interpreter\instructions\DoBlock.cpp
Updated to revision 11824.
F:\work\svn\oorexx>


G:\oorexx.tmp\oorexxBuild\sem32.trunk>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

[  0%] Killing rxapi daemon...
[  0%] Built target kill_rexxapi
[  6%] Built target rexxapi
Scanning dependencies of target rexx
[  6%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/instructions/DoBlock.cpp.obj
DoBlock.cpp
[  7%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/platform/windows/SysFileSystem.cpp.obj
SysFileSystem.cpp

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
 error C2666: 'FileNameBuffer::operator []': 3 overloads have similar 
conversions

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\memory\FileNameBuffer.hpp(205): 
note: could be 'char ::operator [](std::size_t)'

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
 note: while trying to match the argument list '(FileNameBuffer, int)'
NMAKE : fatal error U1077: 'E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : return 
code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

G:\oorexx.tmp\oorexxBuild\sem32.trunk>

---rony


On 06.03.2019 11:06, Rony G. Flatscher wrote:
> On 05.03.2019 20:45, Rick McGuire wrote:
>> Sorry, forgot to add those files to svn so the commits never picked them up. 
>> They are there now.
>
> Thank you!
>
> Cannot compile it successfully for 32-bit with MSC, here the relevant info 
> that also includes some
> warnings that seem to be new:
>
> ...
> [ 40%] Building CXX object 
> CMakeFiles/rexx.dir/interpreter/instructions/DoBlock.cpp.obj
> DoBlock.cpp
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\instructions\DoBlock.cpp(128):
>  warning C4244: 'argument': conversion from 'uint64_t' to 'wholenumber_t', 
> possible loss of data
> ...
> [ 53%] Building CXX object 
> CMakeFiles/rexx.dir/interpreter/parser/ProgramSource.cpp.obj
> ProgramSource.cpp
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\parser\ProgramSource.cpp(753):
>  warning C4244: 'argument': conversion from 'int64_t' to 'std::size_t', 
> possible loss of data
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\parser\ProgramSource.cpp(758):
>  warning C4244: 'argument': conversion from 'int64_t' to 'std::size_t', 
> possible loss of data
> ...
> [ 55%] Building CXX object 
> CMakeFiles/rexx.dir/interpreter/platform/windows/SysFileSystem.cpp.obj
> SysFileSystem.cpp
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
>  error C2666: 'FileNameBuffer::operator []': 3 overloads have similar 
> conversions
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\memory\FileNameBuffer.hpp(205):
>  note: could be 'char ::operator [](std::size_t)'
> 
> F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
>  note: while trying to match the argument list '(FileNameBuffer, int)'
> NMAKE : fatal error U1077: 'E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : 
> return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
>
> G:\oorexx.tmp\oorexxBuild\sem32.trunk>
>
> ---rony
>
>

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


Re: [Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

2019-03-06 Thread Rony G. Flatscher
On 05.03.2019 20:45, Rick McGuire wrote:
> Sorry, forgot to add those files to svn so the commits never picked them up. 
> They are there now.

Thank you!

Cannot compile it successfully for 32-bit with MSC, here the relevant info that 
also includes some
warnings that seem to be new:

...
[ 40%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/instructions/DoBlock.cpp.obj
DoBlock.cpp

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\instructions\DoBlock.cpp(128): 
warning C4244: 'argument': conversion from 'uint64_t' to 'wholenumber_t', 
possible loss of data
...
[ 53%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/parser/ProgramSource.cpp.obj
ProgramSource.cpp

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\parser\ProgramSource.cpp(753): 
warning C4244: 'argument': conversion from 'int64_t' to 'std::size_t', possible 
loss of data

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\parser\ProgramSource.cpp(758): 
warning C4244: 'argument': conversion from 'int64_t' to 'std::size_t', possible 
loss of data
...
[ 55%] Building CXX object 
CMakeFiles/rexx.dir/interpreter/platform/windows/SysFileSystem.cpp.obj
SysFileSystem.cpp

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
 error C2666: 'FileNameBuffer::operator []': 3 overloads have similar 
conversions

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\memory\FileNameBuffer.hpp(205): 
note: could be 'char ::operator [](std::size_t)'

F:\work\svn\oorexx\sandbox\rick\sem\interpreter\platform\windows\SysFileSystem.cpp(187):
 note: while trying to match the argument list '(FileNameBuffer, int)'
NMAKE : fatal error U1077: 'E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : return 
code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

G:\oorexx.tmp\oorexxBuild\sem32.trunk>

---rony

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


Re: [Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

2019-03-05 Thread Rony G. Flatscher
On 05.03.2019 19:51, Enrico Sorichetti via Oorexx-devel wrote:
> I do not see any EventSemaphore.cpp
> In main/trunk
>
> Only a SysSemaphore.cpp
>
> common/platform/unix 
> Common/platform/windows
>
It is supposed to be in Rick's sandbox "sandbox\rick\sem", from his mentioned 
posting:

Branch https://svn.code.sf.net/p/oorexx/code-0/sandbox/rick/sem

Has code in it for the new counter option on loops for anybody interested 
in playing around with
this. It also has new MutexSemaphore and EventSemaphore classes. Still 
writing test cases for
everything.

---rony

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


[Oorexx-devel] Missing "interpreter/classes/EventSemaphore.cpp" when building from "sandbox\rick\sem"

2019-03-05 Thread Rony G. Flatscher
Due to a hint from Rick in 
 about the new
modifier "COUNTER" on loops I wanted to create a 32-bit Windows version for 
ooRexx from
"sandbox/rick/sem" for testing, which unfortunately does not work due to the 
following problem when
running cmake:

G:\oorexx.tmp\oorexxBuild\sem32.trunk>cmake -G "NMake Makefiles" 
F:\work\svn\oorexx\sandbox\rick\sem
-- CMake version is 3.12.0-rc3
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building for a 32-bit architecture
-- OOREXX_SHEBANG_PROGRAM: "/usr/bin/env rexx" (default)
-- Found Subversion: C:/Program Files/TortoiseSVN/bin/svn.exe (found 
version "1.10.0")
-- SVN Revision Number is 11819
-- Looking for ctype.h
-- Looking for ctype.h - found
-- Looking for float.h
-- Looking for float.h - found
-- Looking for limits.h
-- Looking for limits.h - found
-- Looking for locale.h
-- Looking for locale.h - found
-- Looking for malloc.h
-- Looking for malloc.h - found
-- Looking for memory.h
-- Looking for memory.h - found
-- Looking for memset
-- Looking for memset - found
-- Looking for nsleep
-- Looking for nsleep - not found
-- Looking for setlocale
-- Looking for setlocale - found
-- Looking for signal.h
-- Looking for signal.h - found
-- Looking for stdarg.h
-- Looking for stdarg.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Looking for stdio.h
-- Looking for stdio.h - found
-- Looking for stdlib.h
-- Looking for stdlib.h - found
-- Looking for string.h
-- Looking for string.h - found
-- Looking for time.h
-- Looking for time.h - found
-- Looking for vprintf
-- Looking for vprintf - not found
-- Looking for fcntl.h
-- Looking for fcntl.h - found
-- Looking for nanosleep
-- Looking for nanosleep - not found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Configuring done
*CMake Error at CMakeLists.txt:920 (add_library):Cannot find source 
file:**interpreter/classes/EventSemaphore.cpp**Tried extensions .c .C 
.c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm.hpp .hxx .in .txx***

CMake Error at CMakeLists.txt:920 (add_library):
  No SOURCES given to target: rexx


-- Build files have been written to: G:/oorexx.tmp/oorexxBuild/sem32.trunk
G:\oorexx.tmp\oorexxBuild\sem32.trunk>

It seems that EventSemaphore.cpp is not checked in.

---rony


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


[Oorexx-devel] An example of taking advantage of the new variable reference feature

2019-02-27 Thread Rony G. Flatscher
While writing a little script to rewrite mailman mbox archive files to 
anonymize e-mail addresses,
the routine generating a pseudo-e-mail address would increase a counter each 
time.

While developing it a need popped up for a switch when invoking the script that 
allows one to
determine whether the counter should restart at 1 for every new mbox archive 
file or whether to use
a global counter starting at 1. This got realized with a Rexx class defining a 
class attribute
"counter" ("global counter") set to 1 in the class constructor (method 
"::method init class"), and
an instance attribute "counter" ("instance counter") set to 1 in the instance 
constructor (method
"::method init").

Using an array with two elements storing the variable references to the class 
and to the instance
attribute (changed each time a new instance gets created) I was able to solve 
this problem in a
quite easy manner: when invoking the routine that creates the pseudo-e-mail it 
will receive a
variable reference to the class or instance "counter" attribute depending on 
the switch. The routine
itself will only fetch the variable reference and increase the attribute 
counter directly without
without knowing whether it is actually the global or the instance counter!

Thought it might be interesting to see the new ooRexx 5.0 feature "variable 
reference" applied in a
real world scenario!

---rony

P.S.: BTW, the script uses the new ooRexx 5.0 ".context~package~local" 
environment to store the
supplied switch and the array with the variable references (as well as the 
current settings of all
possible options), making it easy to refer to all of them via their environment 
symbol (name of the
entry prepended with a dot '.') in the Rexx script.




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


[Oorexx-devel] A RFE for optionally allowing collection objects where stems get used in the SysUtil functions

2019-02-22 Thread Rony G. Flatscher
While working on a little utility to anonymize pipermail mbox archives from 
mailman, I have been
using sysFileTree(). In the light of the recent work on the SysUtil-functions 
and on SysFileTree()
the idea came up to optionally allow ooRexx collection objects as an option 
wherever currently a
stem is being used. Therefore the RFE at 
.

Using "do...over" over a stem would not work as the entry with the index "0" 
would be iterated as
well. However, when using a collection object instead, do...over would work 
(which would be simpler
IMHO).

---rony



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


Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-22 Thread Rony G. Flatscher
Just opened a RFE <https://sourceforge.net/p/oorexx/feature-requests/743/> 
after studying the
current DO-keyword syntax.

---rony


On 20.02.2019 16:11, Gil Barmwater wrote:
>
> Just another couple of points:
>
> 1) the ~supplier message is not needed;  ooRexx will "supply" it
>
> 2) in the case of relation collections, the [] method will return the first 
> item with the
> specified index so relation collections with duplicate indices would need 
> different handling
> (thanks Rony for pointing that out to me off-list)
>
> Gil
>
> On 2/20/2019 9:18 AM, Gil Barmwater wrote:
>>
>> I think we are on the right track but it needs a little tweaking:
>>
>> t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
>> sayt~class":"
>>
>> dowithindexiitemoovert
>> say"#"i":"pp(o)
>> end
>> say
>>
>> say"--- the desired output:"
>> i=1
>> dowithindexidxitemoovert
>> say"#"i":"pp(idx) "->"pp(o)
>> i=i+1
>> end
>> say
>>
>> say"--- how about this?"
>> dowithindexiitemidxovert~allindexes~supplier
>> say"#"i":"pp(idx) "->"pp(t[idx])
>> end
>> say
>>
>> ::routinepp
>> return"["arg(1)"]"
>>
>> Gil B
>>
>> ---
>>
>> On 2/20/2019 8:06 AM, Rony G. Flatscher wrote:
>>> On 20.02.2019 07:06, Erich Steinböck wrote:
>>>>
>>>> number a do with  over a table where the indices are not numbers, or 
>>>> over a set or bag
>>>>
>>>>  
>>>> Use
>>>> do with index i item j over c~allItems
>>>
>>> This is *not* the same collection as "c", but an array of all of the items 
>>> in the "c"
>>> MapCollection! The important information of which index is associated with 
>>> which item gets lost.
>>>
>>> The "do with...over" is meant to iterate over a supplier which is 
>>> especially important for
>>> non-orderable collections. 
>>>
>>> In the case of Map/SetCollections the index object is as important as the 
>>> item object, such that
>>> it cannot be forgone. (The supplier is the only means for 
>>> Map/SetCollections to get all
>>> index-item-pairs, cf. e.g. for .Relation collections.)
>>>
>>> ---
>>>
>>> One may be inclined to think that "do with...over" is fine for Orderable 
>>> collections as array
>>> collections demonstrate:
>>>
>>> a=("a","z","b")
>>> say a~class":"
>>> do with index i item o over a
>>> say "#" i":" pp(o)
>>> end
>>> say
>>>
>>> l=.list~of("a","y","b")
>>> say l~class":"
>>> do with index i item o over l
>>> say "#" i":" pp(o)
>>> end
>>> say
>>>
>>> ::routine pp
>>>   return "["arg(1)"]"
>>> 
>>> ---
>>>
>>> G:\test\oorexx\201902doover>test_do_over.rex
>>> The Array class:
>>> # 1: [a]
>>> # 2: [z]
>>> # 3: [b]
>>>
>>> The List class:
>>> # 0: [a]
>>> # 1: [y]
>>> # 2: [b]
>>>
>>> However the index value starting out with 0 in the List collection case! 
>>> The expected output in
>>> the case of the List class probably would have been:
>>>
>>> The List class:
>>> # 1: [a]
>>> # 2: [y]
>>> # 3: [b]
>>>
>>> However, as one can see the List does not have a numeric index that start 
>>> with 1, like it is the
>>> case with Array collections.
>>>
>>> In the case of an Orderable collection only the "allitems" array will allow 
>>> for using the index
>>> for numbering, starting with one (because an array always starts with 1):
>>>
>>> l=.list~of("a","y","b")
>>> say l~class":"
>

Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-20 Thread Rony G. Flatscher
On 20.02.2019 07:06, Erich Steinböck wrote:
>
> number a do with  over a table where the indices are not numbers, or over 
> a set or bag
>
>  
> Use
> do with index i item j over c~allItems

This is *not* the same collection as "c", but an array of all of the items in 
the "c" MapCollection!
The important information of which index is associated with which item gets 
lost.

The "do with...over" is meant to iterate over a supplier which is especially 
important for
non-orderable collections. 

In the case of Map/SetCollections the index object is as important as the item 
object, such that it
cannot be forgone. (The supplier is the only means for Map/SetCollections to 
get all
index-item-pairs, cf. e.g. for .Relation collections.)

---

One may be inclined to think that "do with...over" is fine for Orderable 
collections as array
collections demonstrate:

a=("a","z","b")
say a~class":"
do with index i item o over a
say "#" i":" pp(o)
end
say

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l
say "#" i":" pp(o)
end
say

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

G:\test\oorexx\201902doover>test_do_over.rex
The Array class:
# 1: [a]
# 2: [z]
# 3: [b]

The List class:
# 0: [a]
# 1: [y]
# 2: [b]

However the index value starting out with 0 in the List collection case! The 
expected output in the
case of the List class probably would have been:

The List class:
# 1: [a]
# 2: [y]
# 3: [b]

However, as one can see the List does not have a numeric index that start with 
1, like it is the
case with Array collections.

In the case of an Orderable collection only the "allitems" array will allow for 
using the index for
numbering, starting with one (because an array always starts with 1):

l=.list~of("a","y","b")
say l~class":"
do with index i item o over l~allItems
say "#" i":" pp(o)
end
say

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

G:\test\oorexx\201902doover>test_do_over.rex
The List class:
# 1: [a]
# 2: [y]
# 3: [b]

=

Using allItems or allIndexes would not help in the case of Map/SetCollections, 
where the index
object is as important as the item object.

Example with a Table collection:

t=.table~of(("adam","male"), ("berta","female"), ("caesar","male") )
say t~class":"

do with index i item o over t
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over t~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over t~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over t
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

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

Yielding:

The Table class:
# berta: [female]
# caesar: [male]
# adam: [male]

--- now with t~allItems:
# 1: [female]
# 2: [male]
# 3: [male]

--- now with t~allIndexes:
# 1: [berta]
# 2: [caesar]
# 3: [adam]

--- the desired output:
# 1: [berta] -> [female]
# 2: [caesar] -> [male]
# 3: [adam] -> [male]



Example of a relation (index is a human, item a child of that human; a human 
may have more than one
child):

r=.relation~of(("adam","henry"), ("adam","julia"), ("berta","julia"), 
("caesar","denise"), ("caesar","mark") )
say r~class":"
do with index i item o over r
say "#" i":" pp(o)
end
say

say "--- now with t~allItems:"
do with index i item o over r~allItems
say "#" i":" pp(o)
end
say

say "--- now with t~allIndexes:"
do with index i item o over r~allIndexes
say "#" i":" pp(o)
end
say

say "--- the desired output:"
i=1
do with index idx item o over r
say "#" i":" pp(idx) "->" pp(o)
i=i+1
end
say

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

Yielding:

The Relation class:
# caesar: [mark]
# caesar: [denise]
# berta: [julia]
# adam: [julia]
# adam: [henry]

--- now with t~allItems:
# 1: [mark]
# 2: [denise]
# 3: [julia]
# 4: [julia]
# 5: [henry]

--- now with t~allIndexes:
# 1: [caesar]
# 2: [caesar]
# 3: [berta]
# 4: [adam]
# 5: [adam]

--- the desired output:
# 1: [caesar] -> [mark]
# 2: [caesar] -> [denise]
# 3: [berta] -> [julia]
# 4: [adam] -> [julia]
# 5: [adam] -> [henry]

Having a "counter" subkeyword would allow numbering without the need to know 
the kind of collection
that is being iterated. E.g.

List 

Re: [Oorexx-devel] Ad loop counter on do...over ?

2019-02-19 Thread Rony G Flatscher
Erich:

How would you number a do with  over a table where the indices are not numbers, 
or over a set or bag where the items are not numbers, etc.?

—-rony

Rony G. Flatscher (mobil/e)

> Am 19.02.2019 um 23:15 schrieb Erich Steinböck :
> 
> That's exactly what you can do using the DO WITH syntax
> ___
> 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] Ad loop counter on do...over ?

2019-02-19 Thread Rony G Flatscher
Erich,

yes. It is about the beed to number the output while doing a do...over 
beginning wirh the number 1 (a numbered list).

Cheers

—-rony

Rony G. Flatscher (mobil/e)

> Am 19.02.2019 um 21:09 schrieb Erich Steinböck :
> 
> Rony,
> are you aware of the new `DO WITH INDEX i ITEM j OVER collection` syntax?
> ___
> 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] Ad loop counter on do...over ?

2019-02-19 Thread Rony G. Flatscher
Quite often, when using "do...over" there is a need for having a counter that 
increases
automatically on each loop.

Currently one needs to use a separate variable that gets explicitly increased 
within the loop, e.g.:

i=1
do idx over dir
say "entry #" i": idx="idx "dir[idx]="dir
i=i+1
end

It would be great if one could use optionally a counter in the do...over case 
as well, something like:

do idx over dir counter i
   say "entry #" i": idx="idx "dir[idx]="dir
end

where "counter" would be a subkeyword defining a loop variable which starts out 
with "1" and gets
increased by one after each loop.

---rony

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


[Oorexx-devel] Roundup on Windows (Re: Attempt on Windows (Re: How to build external functions using cmake

2019-02-18 Thread Rony G. Flatscher
Tested on 64-bit ooRexx as well and works like a charm, kudos to Enrico!

---

So a little roundup:

  * Enrico's CMake sample works on Windows as well, tested with both the 32 and 
64 bit Microsoft
compiler!!

  * Windows specifics:

  o the ooRexx installation copies the *.h and *.lib files to a directory 
named "api"

  + suggestion: create an "include" (for the *.h files) and a "lib" 
(for the *lib files)
directory on Windows instead of the "api" directory

  o the classic Rexx libraries need the loader function exported, pre 
ooRexx 5 interpreters need
the RexxGetPackage function exported: solution, needing at least CMake 
version 3.3: add the
switch "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE"

  + would suggest to use that switch for both, the classic and native 
libraries to allow
them to be usable by earlier versions of

  o to compile the 32- and the 64-bit versions I used the 
"USB"-installation versions of ooRexx.
Now that it has become possible (kudos to Rick!) to run 32- and 64-bit 
ooRexx in parallel on
the same machine, this excercise has become very, very easy/efficient, 
a real great and
important boon!

This will allow me to experiment with the creation of the BSF4ooRexx and 
dbusoorexx libraries for
all platforms including Windows, which may become a breeze!

---rony

P.S.: Still, this will take some time as the day-job work-load increases due to 
the beginning of the
summer semester around here.


On 18.02.2019 17:39, Rony G. Flatscher wrote:
> On 18.02.2019 17:22, Enrico Sorichetti via Oorexx-devel wrote:
>> Dear Rony 
>> I am very happy that it was useful 
>>
>> Looking at the status of variable for complex cmakelists 
>> ( and I wrote a couple of them )
>> Is usually the only way to debug cmakelists errors 
>>
>> The vdump module was the first one I wrote a long time ago
>> To get a better knowledge of the cmake ways
>>
>> Using cmake -G should have caused different errors IIRC
>>
>> It tells to cmake which generator is being used, 
>> ( I usually go with cmake -G Ninja … … … )
>> So I do not see why it should meddle with the compiler options
>>
>> I will push an update to include the proper defaults for the  c / c++  
>> compilers
>> ( obviously the msvc stuff will empty )
>>
>> Just look at the README, I posted two different CMakeLists 
>> A minimal and a platinum , the minimal does al that is needed with no frills
>
> Hmm, just see probably the "minimal" which is ideal for a newbie to CMake 
> like myself! :)
>
> Researching about the exported symbols problem on Windows I ran around the 
> following switch
> "-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE", which solves the problem for the 
> classic library
> problem. Now both Rexx scripts work:
>
> cmake -G "NMake Makefiles" -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE 
> -DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% ..\rxSnippets
> ...
> nmake
> ...
> G:\oorexx.tmp\enrico\win32>rexx rxClassic
> rxClassicVersion at line 84' '1.0.0'
>
> 1.0.0
> rxClassicWorker at line 103'
>   Argc 0
>
> rxClassicWorker at line 103'
>   Argc 1
>   Argv 0  'A'
>
> rxClassicWorker at line 103'
>   Argc 2
>   Argv 0  'A'
>   Argv 1  'B'
>
>
> G:\oorexx.tmp\enrico\win32>rexx rxClassic
> rxClassicVersion at line 84' '1.0.0'
>
> 1.0.0
> rxClassicWorker at line 103'
>   Argc 0
>
> rxClassicWorker at line 103'
>   Argc 1
>   Argv 0  'A'
>
> rxClassicWorker at line 103'
>   Argc 2
>   Argv 0  'A'
>   Argv 1  'B'
>
>
> G:\oorexx.tmp\enrico\win32>
>
> This is really just *great*, thank you very much indeed!
>
> ---rony
>

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


Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

2019-02-18 Thread Rony G. Flatscher
On 18.02.2019 17:22, Enrico Sorichetti via Oorexx-devel wrote:
> Dear Rony 
> I am very happy that it was useful 
>
> Looking at the status of variable for complex cmakelists 
> ( and I wrote a couple of them )
> Is usually the only way to debug cmakelists errors 
>
> The vdump module was the first one I wrote a long time ago
> To get a better knowledge of the cmake ways
>
> Using cmake -G should have caused different errors IIRC
>
> It tells to cmake which generator is being used, 
> ( I usually go with cmake -G Ninja … … … )
> So I do not see why it should meddle with the compiler options
>
> I will push an update to include the proper defaults for the  c / c++  
> compilers
> ( obviously the msvc stuff will empty )
>
> Just look at the README, I posted two different CMakeLists 
> A minimal and a platinum , the minimal does al that is needed with no frills

Hmm, just see probably the "minimal" which is ideal for a newbie to CMake like 
myself! :)

Researching about the exported symbols problem on Windows I ran around the 
following switch
"-DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE", which solves the problem for the 
classic library problem.
Now both Rexx scripts work:

cmake -G "NMake Makefiles" -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE 
-DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% ..\rxSnippets
...
nmake
...
G:\oorexx.tmp\enrico\win32>rexx rxClassic
rxClassicVersion at line 84' '1.0.0'

1.0.0
rxClassicWorker at line 103'
  Argc 0

rxClassicWorker at line 103'
  Argc 1
  Argv 0  'A'

rxClassicWorker at line 103'
  Argc 2
  Argv 0  'A'
  Argv 1  'B'


G:\oorexx.tmp\enrico\win32>rexx rxClassic
rxClassicVersion at line 84' '1.0.0'

1.0.0
rxClassicWorker at line 103'
  Argc 0

rxClassicWorker at line 103'
  Argc 1
  Argv 0  'A'

rxClassicWorker at line 103'
  Argc 2
  Argv 0  'A'
  Argv 1  'B'


G:\oorexx.tmp\enrico\win32>

This is really just *great*, thank you very much indeed!

---rony


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


Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

2019-02-18 Thread Rony G. Flatscher
On 18.02.2019 17:10, Rony G. Flatscher wrote:
> A remark: forgot to delete the lines:
>  cl : Command line warning D9002 : ignoring unknown option '-g'
>
> Those warnings were issued, because I used "cmake -G ...", removing the "-G" 
> (from a very, very,
> very old note) removed the warning in my second runs. So please ignore them 
> in my previous
> posting, there are not there anymore.
>
Rechecking. CMake: the "-G" switch is necessary. Doing a fresh run after 
removing the previous win32
directory does not show the above warnings anymore:

G:\oorexx.tmp\enrico\win32>cmake -G "NMake Makefiles" 
-DCMAKE_BUILD_TYPE=RELEASE -DOOREXX_INSTALL_PREFIX=%OOREXX_HOME_32% 
..\rxSnippets
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE)
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian

--
-- configuration summary for project 'rxSnippets'
--
--   version string .. : 1.0.0
--   build ... : 0
--   revision  : Final
--   RCS . :  -
--
--   requires libraries .. : rexx;rexxapi
-- found . : rexx -
-- : rexxapi -
--
--   build type .. : RELEASE
--   word size ... : 32
--   platform  : LITTLE ENDIAN
--   install prefix .. : C:/Program Files (x86)/dummy
--
--   CMake version ... : 3.12.0-rc3
--   CMake modules path .. : G:/oorexx.tmp/enrico/rxSnippets
-- : 
G:/oorexx.tmp/enrico/rxSnippets/cmake/Modules
--
--
--   generator ... : NMake Makefiles
--   generator program ... : nmake -
--
--   enabled languages ... : C;CXX;RC
--
--   C   compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   C   compiler ID . : MSVC
--   C   compiler VERSION  : 19.0.24215.1
--   C   compiler flags .. :-O2 -DNDEBUG
--
--   CXX compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   CXX compiler ID . : MSVC
--   CXX compiler VERSION  : 19.0.24215.1
--   CXX compiler flags .. :   -O2  -DNDEBUG
--
--   RC  compiler  : C:/Program Files (x86)/Windows 
Kits/8.1/bin/x86/rc.exe
--   RC  compiler ID . :
--   RC  compiler VERSION  :
--   RC  compiler flags .. :
--
--   compile definitions . : VERSION_STRING="1.0.0"
--
--   include directories . : G:/oorexx.tmp/enrico/win32
-- : 
e:/DropBox/Dropbox/xfer/orx/beta/sandbox_ooRexx/standalone/ooRexx32win/include
-- : 
G:/oorexx.tmp/enrico/rxSnippets/src/include
--
--   user options  :
--
-- end of configuration summary
--

-- Configuring done
-- Generating done
-- Build files have been written to: G:/oorexx.tmp/enrico/win32

G:\oorexx.tmp\enrico\win32>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target rxClassic
[ 25%] Building C object CMakeFiles/rxClassic.dir/src/rxClassic.c.obj
cl : Command line warning D9002 : ignoring unknown option '-g'
rxClassic.c
[ 50%] Linking C share

Re: [Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

2019-02-18 Thread Rony G. Flatscher
A remark: forgot to delete the lines:

 cl : Command line warning D9002 : ignoring unknown option '-g'

Those warnings were issued, because I used "cmake -G ...", removing the "-G" 
(from a very, very,
very old note) removed the warning in my second runs. So please ignore them in 
my previous posting,
there are not there anymore.

---rony

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


[Oorexx-devel] Attempt on Windows (Re: How to build external functions using cmake

2019-02-18 Thread Rony G. Flatscher
Tried it on Windows:

G:\oorexx.tmp\enrico\win32>call "e:\Programme\Microsoft Visual Studio 
14.0\VC\vcvarsall.bat" x86
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working C compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe
-- Check for working CXX compiler: E:/Programme/Microsoft Visual Studio 
14.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find Git (missing: GIT_EXECUTABLE)
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian

--
-- configuration summary for project 'rxSnippets'
--
--   version string .. : 1.0.0
--   build ... : 0
--   revision  : Final
--   RCS . :  -
--
--   requires libraries .. : rexx;rexxapi
-- found . : rexx -
-- : rexxapi -
--
--   build type .. : Debug
--   word size ... : 32
--   platform  : LITTLE ENDIAN
--   install prefix .. : C:/Program Files (x86)/dummy
--
--   CMake version ... : 3.12.0-rc3
--   CMake modules path .. : G:/oorexx.tmp/enrico/rxSnippets
-- : 
G:/oorexx.tmp/enrico/rxSnippets/cmake/Modules
--
--
--   generator ... : NMake Makefiles
--   generator program ... : nmake -
--
--   enabled languages ... : C;CXX;RC
--
--   C   compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   C   compiler ID . : MSVC
--   C   compiler VERSION  : 19.0.24215.1
--   C   compiler flags .. : -g -DDEBUG
--
--   CXX compiler  : E:/Programme/Microsoft Visual 
Studio 14.0/VC/bin/cl.exe
--   CXX compiler ID . : MSVC
--   CXX compiler VERSION  : 19.0.24215.1
--   CXX compiler flags .. : -g -DDEBUG
--
--   RC  compiler  : C:/Program Files (x86)/Windows 
Kits/8.1/bin/x86/rc.exe
--   RC  compiler ID . :
--   RC  compiler VERSION  :
--   RC  compiler flags .. : /D_DEBUG
--
--   compile definitions . : VERSION_STRING="1.0.0"
--
--   include directories . : G:/oorexx.tmp/enrico/win32
-- : 
e:/DropBox/Dropbox/xfer/orx/beta/sandbox_ooRexx/standalone/ooRexx32win/include
-- : 
G:/oorexx.tmp/enrico/rxSnippets/src/include
--
--   user options  :
--
-- end of configuration summary
--

-- Configuring done
-- Generating done
-- Build files have been written to: G:/oorexx.tmp/enrico/win32

G:\oorexx.tmp\enrico\win32>

G:\oorexx.tmp\enrico\win32>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target rxClassic
[ 25%] Building C object CMakeFiles/rxClassic.dir/src/rxClassic.c.obj
cl : Command line warning D9002 : ignoring unknown option '-g'
cl : Command line warning D9002 : ignoring unknown option '-g'
rxClassic.c
G:\oorexx.tmp\enrico\rxSnippets\src\rxClassic.c(12): fatal error C1083: 
Cannot open include file: 'rexx.h': No such file or directory
NMAKE : fatal error U1077: 'E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe' : return 
code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"E:\Programme\Microsoft Visual Studio 
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

ooRexx on Windows has the *.h files in "api" instead of "include".

Adjusted it by 

Re: [Oorexx-devel] How to build external functions using cmake

2019-02-17 Thread Rony G. Flatscher
On 17.02.2019 19:09, Enrico Sorichetti via Oorexx-devel wrote:
>
> See here 
>
> git clone http://3...@bitbucket.org/3481/rxSnippets

Cloned it, skimming over it, it is electrifying!!

> Have a good time

Will take a few days, but will definitely have a good time!
:)

(This should help me to create - and perhaps understand a little bit more of - 
CMakeLists.txt for
BSF4ooRexx.cc and also for the "dbusoorexx" (ooRexx external function library 
for Linux' DBus
communication infrastructure), foregoing the Makefiles.)

>
> Tested only on Darwin 
>
> Working on the other platforms 
>
> I will keep You posted

Please do so! Having a minimal CMakeLists.txt for producing external Rexx 
function libraries for the
major platforms is really a great boon!

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


Re: [Oorexx-devel] "libao: a cross platform audio library", how about creating an external Rexx function library ?

2019-02-17 Thread Rony G. Flatscher
On 17.02.2019 14:03, Rick McGuire wrote:
>
> On Sun, Feb 17, 2019 at 8:00 AM Enrico Sorichetti via Oorexx-devel
>  > wrote:
>
> Already working on a simple external function skeleton,
>
> Which does nothing but … Print the arguments passed
>
> Will not take long to polish it and post it somewhere
>
> Does not use the native approach ,
>
> I was not able to find into the docs how to determine the number of 
> arguments passed
>
> From the samples looks like that the native mode functions only support a 
> fixed number of
> arguments
>
> But I would like if somebody pointed me on hoe to do it the native day
>
>
> You can also ask for all of the arguments to be passed to you in an array. 
> When used that way, no
> maximum is enforced. See the current unix rexxutil functions SysGetMessage 
> and SysGetMessageX to
> see how this works.

Maybe also interesting: , which 
is meant at allowing
C++ programmers to jump start creating external function libraries, which 
implement routines or
methods in native code.

---

It is a talk (the pdf-file) at an International Rexx Symposium (cf.
) where I tried to give a 
conceptual overview how
to create external Rexx function routines and external Rexx method routines. 
The zip archive
contains the files (sources, binaries in 32- and 64-bit) and Makefiles for 
Windows, Apple, Linux. As
you can see by looking at the Makefiles that a CMake solution (from someone in 
the know) would have
been even better for the project.

The native C++ API is documented in chapter 8 in "rexxpg.pdf" ("ooRexx 
Programming Guide").

---rony


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


[Oorexx-devel] "libao: a cross platform audio library", how about creating an external Rexx function library ?

2019-02-17 Thread Rony G. Flatscher
While researching a little bit about audio on Linux (after reading about the 
"portable beep
problem") et.al. I stumbled over an interesting cross-platform library named 
"libao" which seems to
have arrived a stable state.

Here various links for gaining a quick overview:

  * Homepage & overview: 
  * Documentation: 
  * API overview: 

  * Linux-from-scratch (how to install):

  * Infos about Ubuntu: 

At first sight it seems that the API is small and straight-forward.

So the idea: how about creating an external Rexx function library for libao and 
compile it for the
major operating system platforms Windows, MacOS and Linux? If possible with a 
CMakeLists.txt, such
that such a library also can serve as a role model for a) how to create 
external function library
and b) how to use CMake to make it simple to compile, link and create 
installers for the different
platforms?

Anyone who would find such an external Rexx function library useful/interesting 
and would try to
create it?

---rony


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


Re: [Oorexx-devel] Testing Open Object Rexx Version 5.0.0 r11766

2019-02-16 Thread Rony G. Flatscher
What would you suggest/advise given your huge knowledge and experiences on so 
many different Unix
systems?

Should the test be adapted to check whether Ubuntu is the host system (e.g. "if
sysVersion()~caselessPos('Ubuntu')>0 then ...")?

Should the function work differently on Ubuntu to match the behaviour of other 
Unix systems? If so,
how could one determine/decide which behaviour should be expected/picked by 
Rexx programmers
employing them?

Should the functions behave according to the host system's behaviour, but 
document it? If so, then
maybe a means for querying the exact behaviour might become important for Rexx 
programmers to adjust
their logic accordingly (or pick a different function or use address).

How should differences among Unix versions be handled in principle?

Should maybe "PARSE SOURCE" return "UBUNTU" instead of "LINUX" to indicate that 
it behaves
differently compared to other Linuxes?

---rony



On 16.02.2019 15:53, Enrico Sorichetti via Oorexx-devel wrote:
> I started a bit earlier ( do You remember Slackware )
>
> After that I went for Red Hat
>
> And got used to the red-hat and friends terminology 
>
> I can agree on the Debian ways 
> But Ubuntu has taken things a bit too far
>
> Apart being too much much windowish for my taste ;-)
>
> This morning it took me  just 40 minutes to setup a Debian working 
> environment for ooRexx
> I tried last week with ubuntu and I stopped trying after one day 
>
> And … a couple of years ago developing with ubuntu
> Was really painful for the very bad choice they had made for the compiler and 
> the headers 
> Many configure.ac checks  had to be rewritten  because of that 
> ( I got burned by the atomic support detection )
>
>
> Cheers
> E
>
>> On 16 Feb 2019, at 15:31, Michael Lueck  wrote:
>>
>> Enrico Sorichetti via Oorexx-devel wrote:
>>> Unfortunately Ubuntu is well known also for its odd way of doing things
>>
>> haha...
>>
>> The Debian / Ubuntu way makes sense, the other distros are the odd ones! ;-)
>>
>> Seriously... I started out with Red Hat 5.2 back in probably 1999. Yuck. 
>> SuSE, Mandrake... more yuck.
>>
>> Then in 2004 my "right hand man in America" suggested I try Debian... which 
>> I had heard had a reputation of being "stick shift'ish"... and quickly 
>> connected with it.
>>
>> One of the big draws for me was that dpkg came with built-in package 
>> dependency checking whereas rpm lacked it.
>>
>> 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 on SysFileTree()

2019-02-07 Thread Rony G. Flatscher
On 07.02.2019 12:25, P.O. Jonsson wrote:
> Thanks for clarifying.
>
> Maybe you (or someone else) can help me with another issue: I am trying to 
> locate the build
> directory on Mac in FileUtils.cls. On the jenkins slave the build is located 
> in:
>
> //Users/jenkins/workspace/ooRexx-macOS1014-build/oorexxBuild/
>
> And in my clone installation:
>
> //Users/po/workspace/ooRexx-macOS1014-build/oorexxBuild/
>
> I was trying to locate it using SysSearchPath() but his does not work:
>
> /dir = SysSearchPath('~/workspace/ooRexx-macOS1014-build/oorexxBuild/bin', 
> "rexx")/
>
> Can you or someone else point me to a reliable way to locate the build 
> directory on Mac? I have
> tried the Unix alternatives in FileUtils.cls but they do not work.

If I understand your use case correctly, you would have a need to locate where 
"rexx[.exe]" (the
executable) that gets used is located?

If so, I do not know of a solution. If no one else has a reliable, 
multi-platform solution you could
open a RFE, e.g. that this path is supplied via the .rexxInfo class (cf. 
rexxref.pdf, 5.4.15) or the
like.

---rony


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


[Oorexx-devel] Typos in oorexxapi.h ?

2019-02-04 Thread Rony G. Flatscher
While looking up oorexxapi.h I found the following two defines (in line # 82 
and # 85) with a
trailing "-- alias":

#define REXX_VALUE___uint64_t 27  -- aliased
#define REXX_VALUE___uintptr_t29  -- aliased

---rony



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


[Oorexx-devel] New beta version of BSF4ooRexx available (version 641.20190203)

2019-02-03 Thread Rony G. Flatscher
Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from 
Sourceforge, namely from:

.


BSF4ooRexx is an ooRexx external function package that allows Rexx programs to 
exploit all Java
classes and interact with Java as if it was ooRexx! Requiring the supplied 
ooRexx package "BSF.CLS"
camouflages the strictly typed, case-sensitive programming language Java as the 
dynamically typed,
case-insensitive language Rexx, making it considerably easy to interface with 
Java.

---

Attention! This version of BSF4ooRexx does not accept abstract Java classes in
bsf.import(some_java_class) anymore!

Importing Java classes allows one to use the ooRexx new-message to create Java 
instances (the
imported Java class will be proxied as an ooRexx class and getting the class 
method new defined for
it). Clearly, abstract Java classes cannot be instantiated, hence this change! 
The error message
will point out the exact reason and a solution, namely to use 
bsf.loadClass(some_java_class)
instead, which then allows one to access the static fields and the concrete 
static methods of the
supplied Java class.

Although I have gone through all the sample code and Rexx packages coming with 
BSF4ooRexx to find
usages of bsf.importClass() with abstract Java classes and fix it, it may be 
the case that there are
samples that have gone unnoticed so far. In this case please file a bug report 
at
.

---

If after installing BSF4ooRexx you choose the menu option "BSF4ooRexx -> 
Samples" a folder/finder
window will open and display the Rexx samples. Locate the file "index.html" and 
click on it: this
will briefly describe each Rexx sample, such that you are able to quickly get 
an overview.

---

Also I would like to point out to you the latest beta versions of ooRexx 5.0 
which introduces many
valuable and helpful new features:
. Regularly 
check for new builds
there.

The quality of the current beta versions of ooRexx 5.0 is of type "release", 
includes many
interesting new features and contains many bug fixes over ooRexx 4.2.

Also please note: the BSF4ooRexx package for MacOSX already includes a fresh 
build of ooRexx 5.0
beta, revision 11636.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
 
().

Cheers,

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


[Oorexx-devel] Ad ooRexx pipe-samples

2019-02-03 Thread Rony G. Flatscher
 has another pipe-related patch by 
Matthé van der Lee
from December 3rd 2018, which might have been overlooked. Just in case a 
reminder.

Here is his statement: "For my own amusement, I have rewritten the pipe.rex 
sample, and included
support for multistream pipelines and for many of the pipeline stage commands 
as provided by CMS
Pipelines. I attach the source here, as well as that of the adapted demo 
usepipe.rex. Comments
welcomed." His version is attached to the above URL and can be directly 
downloaded for evaluation
and testing.

Would it be sensible to incorporate his changes?

---rony




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


[Oorexx-devel] Break up "rexxpg.pdf" into an "ooRexx Primer/Introduction" and a separate "C/C++ Programming Interfaces for ooRexx"?

2019-02-03 Thread Rony G. Flatscher
For unknown reasons the "Programmer Guide" of ooRexx, "rexxpg.pdf", includes a 
primer for ooRexx and
the documentation for savvy C/C++ programmers.

If a newcomer is looking for an introduction into ooRexx it would be great if 
there was a specific
pdf-book for it, like "ooRexx Primer - Introduction to the ooRexx Programming 
Language", i.e.
chapter one through chapter seven plus appendix A and appendix B, which gives a 
brief
characterizations of the ooRexx samples.

The remaining chapters 8 and 9 could then be entitled something like "Classic 
Rexx and C++ ooRexx
Application Programming Interfaces" with the appropriate appendixes.

---rony




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


[Oorexx-devel] Ad Unix-based installations missing ooRexx samples and the ooRexx documentation ...

2019-02-03 Thread Rony G. Flatscher
The Unix based installations do not come with the IMHO extremely import 1) 
ooRexx samples and 2) the
ooRexx pdf documentation!

Is there any convention to allow installing 1) and 2) with the base ooRexx 
installation? Or would
there be a possibility to have an additional installation package that simply 
includes 1) and 2)?

---rony

P.S.: My BSF4ooRexx package for MacOSX includes ooRexx and all of 1) and 2), 
accessible via the
ooRexx menu there. But that is only possible, because the installation is 
Apple-specific.




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


Re: [Oorexx-devel] Question ad AddCommandHandler()

2019-01-30 Thread Rony G. Flatscher
On 30.01.2019 11:57, Rick McGuire wrote:
>
> On Wed, Jan 30, 2019 at 5:51 AM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Thanks, one last question in this context.
>
> On 29.01.2019 21:07, Rick McGuire wrote:
>> On Tue, Jan 29, 2019 at 1:18 PM Rony G Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> Looked thru the code, a few quick questions:
>>
>> If a command handler that has no redirection, would the last 
>> argument ioctl be NULL?
>>
>> No, if the command handler is registered as a redirecting handler, then 
>> it will always be
>> passed an IOContext. You can then query the context to see if there has 
>> been any redirection
>> requested and what types.
>
... cut ...

> The type indicates what sort of handler you have written. The redirecting one 
> is passed an io
> context, the non-redirecting one does not. The non-redirecting ones are the 
> same as command
> handlers that exist for 4.2.0. The API merely allows one to be added by other 
> than an option when
> the interpreter instance is created.
>  

So then the difference is reflected in the called handler function as well,

for the non-directing signature:

RexxObjectPtr RexxEntry nonDirectingCommandHandler(RexxExitContext *context,
  RexxStringObject address,
  RexxStringObject command)

for the redirecting signature:

RexxObjectPtr RexxEntry reDirectingCommandHandler(RexxExitContext *context,
 RexxStringObject address,
 RexxStringObject command,
 RexxIORedirectorContext *ioContext)

Thanks!

---rony

P.S.: Sorry, the first reply went directly to Rick instead of to the list!

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


Re: [Oorexx-devel] Question ad AddCommandHandler()

2019-01-30 Thread Rony G. Flatscher
Thanks, one last question in this context.

On 29.01.2019 21:07, Rick McGuire wrote:
> On Tue, Jan 29, 2019 at 1:18 PM Rony G Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> Looked thru the code, a few quick questions:
>
> If a command handler that has no redirection, would the last argument 
> ioctl be NULL?
>
> No, if the command handler is registered as a redirecting handler, then it 
> will always be passed
> an IOContext. You can then query the context to see if there has been any 
> redirection requested
> and what types.

There is a new IsRedirectionRequested() function listed and documented as:

8.17.100. *NEW* IsRedirectionRequested

This API is available in context I/O Redirector since ooRexx 5.0.

logical_t flag;
// Method Syntax Form(s)
flag = context->IsRedirectionRequested();

Tests whether for the current command any redirection was requested using 
the WITH subkeyword of
an ADDRESS instruction.

Arguments: None.

Returns: 1 if any redirection was requested, 0 otherwise.

See also methods *NEW* AreOutputAndErrorSameTarget, *NEW* 
IsErrorRedirected, *NEW*
IsInputRedirected, *NEW* IsOutputRedirected, *NEW* ReadInput, *NEW* 
ReadInputBuffer, *NEW*
WriteError, *NEW* WriteErrorBuffer, *NEW* WriteOutput, and *NEW* 
WriteOutputBuffer.


The function "AddCommandEnvironment(name,handler,type)" has a "type" argument 
that may be one of
two: DIRECT_COMMAND_ENVIRONMENT and REDIRECTING_COMMAND_ENVIRONMENT.

Question:

What is exactly the difference between the two?
E.g. the REDIRECTING_COMMAND_ENVIRONMENT must use the "ReadInput[Buffer]()" 
and the
"Write{Error|Output}[Buffer]()" functions, whereas the 
"DIRECT_COMMAND_ENVIRONMENT" must use
.input for reading, .output and .error for writing instead?

Question:

Can "IsRedirectionRequested()" be issued for both handler types?

And if so, in the case of a DIRECT_COMMAND_ENVIRONMENT would then the 
functions
"AreOutputAndErrorSameTarget()", "IsErrorRedirected()", 
"IsInputRedirected()",
"IsOutputRedirected()" be available as well? If so, how about the 
"Write[*]()" functions?

---rony



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


Re: [Oorexx-devel] Question ad AddCommandHandler()

2019-01-29 Thread Rony G Flatscher
Looked thru the code, a few quick questions:

If a command handler that has no redirection, would the last argument ioctl be 
NULL?
Can one query the list (names) of the currently loaded command handlers?
Would one be able to remove a command handler by name?

—-rony

Rony G. Flatscher (mobil/e)

> Am 29.01.2019 um 14:02 schrieb Rony G. Flatscher :
> 
>> On 28.01.2019 22:24, Rick McGuire wrote:
>> I suggest you look at the test command handler that Erich just added to the 
>> test cases. This will
>> show you how the command handlers are implemented and how to use the 
>> redirection APIs.
> 
> Thanks, will do.
> 
> ---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 AddCommandHandler()

2019-01-29 Thread Rony G. Flatscher
On 28.01.2019 22:24, Rick McGuire wrote:
> I suggest you look at the test command handler that Erich just added to the 
> test cases. This will
> show you how the command handlers are implemented and how to use the 
> redirection APIs.

Thanks, will do.

---rony




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


Re: [Oorexx-devel] Question ad AddCommandHandler()

2019-01-28 Thread Rony G Flatscher
How does the implentation (have to?) differ? 

The readon of asking: once ooRexx 5 gets released, I plan a version of 
BSF4ooRexx that exploits the new ooRexx features. 

As the current version already supports command handlers implemented in Java 
(or in ooRexx via BSF4ooRexx) at interpreter creation time, I would like to 
support this new API in all of its facets.

—-rony


Rony G. Flatscher (mobil/e)

> Am 28.01.2019 um 21:15 schrieb Rick McGuire :
> 
> The two handler types have different call signatures. When you register the 
> handler, you are telling the interpreter which call signature is used to call 
> the handler. 
> 
> Rick
> 
>> On Mon, Jan 28, 2019 at 1:43 PM Rony G. Flatscher  
>> wrote:
>> Question ad new C++ method "context->AddCommandEnvironment(name, handler, 
>> type);", where the documentaiton for "type" reads: 
>> 
>> "type": The type of command handler to add. DIRECT_COMMAND_ENVIRONMENT for a 
>> command handler with no support for redirection. 
>> REDIRECTING_COMMAND_ENVIRONMENT for a command handler that supports 
>> redirection.
>> 
>> How would the "handler" become able to support the new 
>> "REDIRECTING_COMMAND_ENVIRONMENT" ability? How could the "handler" determine 
>> whether redirection is in place and if so, what should it do/support for 
>> each kind of redirection?
>> 
>> ---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] Question ad AddCommandHandler()

2019-01-28 Thread Rony G. Flatscher
Question ad new C++ method "context->AddCommandEnvironment(name, handler, 
type);", where the
documentaiton for "type" reads:

"type": The type of command handler to add. DIRECT_COMMAND_ENVIRONMENT for 
a command handler
with no support for redirection.
REDIRECTING_COMMAND_ENVIRONMENT for a command handler that supports 
redirection.

How would the "handler" become able to support the new 
"REDIRECTING_COMMAND_ENVIRONMENT" ability?
How could the "handler" determine whether redirection is in place and if so, 
what should it
do/support for each kind of redirection?

---rony


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


Re: [Oorexx-devel] Releasing ooRexx 5.0? Building on Debian Linux Shared Web Hosting as non-root

2019-01-22 Thread Rony G. Flatscher
On 22.01.2019 17:53, Erich Steinböck wrote:
> Hi Michael,
> if you do not want to build to the default ooRexx install location /usr/bin, 
> set
> CMAKE_INSTALL_PREFIX to the desired path on the cmake command. To build for 
> an install to your
> home directory, you would use
>
> cmake -DBUILD_DEB=1 -DOS_DIST=ubuntu1604 -DCMAKE_BUILD_TYPE=RELEASE
> -DCMAKE_INSTALL_PREFIX=~/oorexx ../../oorexxsvn/main/trunk
>
> To install without building a package, use make install
>
> No APIService.cpp patching, ./configure, mkdir ~/opt/oorexx/var should be 
> necessary for 5.0.  The
> latest 5.0 trunk will no longer require rxapi to run as root.
>
>
> I have just updated our How-to-build-ooRexx wiki at
> https://sourceforge.net/p/oorexx/wiki/how-to-build-oorexx/
> I'll also update CMake-build-readme.txt
>
> Please let us know of any issues you encounter.

maybe the following can be helpful after running "make":

make DESTDIR=~/oorexx5 install   

"DESTDIR=someDestinationDirectory" allows one to install ooRexx anywhere on 
one's system. Then
"~/oorexx5/bin/rexx -e 'say address()' " should work.

---rony

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


[Oorexx-devel] Releasing ooRexx 5.0?

2019-01-15 Thread Rony G. Flatscher
What would be the thoughts about releasing the current trunk version of ooRexx 
5.0 as "general
available"?
(In order for organisations/companies to adopt 5.0 or to replace older versions 
of Rexx/ooRexx with
5.0 it would be necessary that it becomes officially GA.)

It would be still possible to create some ooRexx 5.1, 5.2 and the like shortly 
after a GA release,
if new functionality would be added to it (e.g. applying sandbox development 
results or implementing
RFEs).

---rony



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


Re: [Oorexx-devel] [oorexx:code-0] New commit [r11653] by bigrixx

2019-01-14 Thread Rony G. Flatscher
Just tested that: MacOS builds Linux gcc gets an error during compilation.

---rony

P.S.: While cleaning the build directory with "rm -rf *" I mistakingly deleted 
my  home directory
"~" so I will not be able to create builds for ooRexx or BSF4ooRexx for Linux 
32- and 64-bit. :-(

[As I alotted too much time to ooRexx in the past weeks I have to make up for 
it for my day job, so
it will be a while before I become able to compile on Linux again...]


On 13.01.2019 17:49, Rick McGuire wrote:
> Hmm, the following lines in CMakeLists.txt look suspicious. I think the SET 
> commands should be
> outside the conditional. 
>
> # Extra link library definitions
> # gcc (at least on Linux) requires linking with -lcrypt
> # clang (at least on Darwin) doesn't have libcrypt
> if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
> target_link_libraries(rxunixsys rexx rexxapi crypt 
> ${CMAKE_REQUIRED_LIBRARIES})
> else ()
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -stdlib=libc++")
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -stdlib=libc++ 
> -lc++abi")
>
> target_link_libraries(rxunixsys rexx rexxapi ${CMAKE_REQUIRED_LIBRARIES})
> endif ()

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


Re: [Oorexx-devel] [oorexx:code-0] New commit [r11653] by bigrixx

2019-01-13 Thread Rony G. Flatscher
On 13.01.2019 18:27, Erich Steinböck wrote:
> Those two SET's were the fix for https://sourceforge.net/p/oorexx/bugs/1577
> Specific to CLANG on mac.  That's probably the reason why the mac builds 
> don't give those c++11
> warnings.

Interestingly there are no such warnings issued when compiling with gcc 7.3.0 
on Ubuntu.

---rony




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


Re: [Oorexx-devel] Rethinking error messages.

2019-01-11 Thread Rony G. Flatscher
Applied your commits and re-built MacOS and Linux standalone versions and my 
preliminary tests show
that this is working perfectly, *great job*!

---rony

P.S.: Cf. eg. 
.

On 09.01.2019 23:07, Rick McGuire wrote:
> The purpose of the rexx.cat  file is (in theory), that by 
> having separation
> between the executables and the error texts, we can easily translate the 
> error messages. In
> reality, there has never been any attempt at having multiple versions of the 
> messages, and I
> suspect we have really been misusing the catopen() mechanisms in a way that 
> would really prevent
> multiple languages from happening. The move toward the USB execution only 
> complicates this since
> we desire to pick up a specific rexx.cat  file rather than 
> using the DLPATH
> capabilities. 
>
> In addition, the Windows version makes no attempt at implementing NLS 
> support. The error messages
> are bound into the rexx dll as string resources. To do any sort of 
> translation, you need to
> rebuild the interpreter with a different .rc file. There is no switching.
>
> As I'm working on code to locate the specific .cat file, it occurred to be 
> that it would be a
> trivial matter to implement something like Windows uses and have an internal 
> message table rather
> than have this external artifact that needs to be located. 
>
> Rick

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


Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-10 Thread Rony G. Flatscher
On 10.01.2019 14:30, Rick McGuire wrote:
> Why are you removing Enrico's RPATH changes? They seem like a good idea and I 
> NEVER advocated
> against those. My discussion was totally about the appropriate location for 
> rexx.img.

Oh, o.k. As the changes have not been applied to trunk I thought they were not 
desired, hence going
back to the trunk version of CMakeList.txt. Will reapply and keep them (as well 
as the fixes to add
the symbolic links to let applications linked to older versions of ooRexx run 
with the current
version and fixing the rpm naming if 64-bit).

---rony




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


Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-10 Thread Rony G. Flatscher
On 10.01.2019 12:56, Rick McGuire wrote:
> I have tested exactly the situation on my Linux system, and everything works 
> fine. But I don't
> have your setup, so there's probably something different. 
>
> I suggest adding a printf() to the SystemInterpreter::loadImage() method (the 
> second one with the
> longer signature) and print out the names it is attempting to load from. One 
> concern I do have
> whether the getExecutableLocation() might need to resolve links to obtain the 
> real library
> location. I'm not sure what name dladdr() is returning. The printfs() will 
> show where it is
> looking and might give a good answer to this question.

OK, added printf's in FileSystem.cpp to the imageLoad() methods there.

However, in the process I noticed that although I had issued a "svn revert *" 
to the ooRexx
"main/trunk" the changes I had added yesterday were still present. After 
reverting them back
individually and making sure that all files were in sync with r11665 (svn 
stat), "rexx.img" got found!

Sorry for the false alarm about "../lib/rexx.img" not being found!

However the library not found problem still persists if running without 
Enrico's RPATH settings,
here a sample MacOS session:

wu114215:bin rony$ *pwd*
/Users/rony/Applications/mac64test20190110-1410/bin

wu114215:bin rony$ *./rexx*
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: 
/Users/rony/Applications/mac64test20190110-1410/bin/./rexx
  Reason: image not found
Abort trap: 6

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx*

Syntax is "rexx filename [arguments]"
or"rexx -e program_string [arguments]"
or"rexx -v".

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx -e "say '--->' 
directory()"*
---> /Users/rony/Applications/mac64test20190110-1410/bin

wu114215:bin rony$ *./rexx -e "say '--->' directory()"*
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: 
/Users/rony/Applications/mac64test20190110-1410/bin/./rexx
  Reason: image not found
Abort trap: 6

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


Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-10 Thread Rony G. Flatscher
On 09.01.2019 21:11, Rick McGuire wrote:
> This is not an acceptable patch because it imposes a directory structure that 
> is not necessary and
> is not necessarily what will be used on the other platforms. Just make the 
> simple one-line change
> to the CMakeLists.txt file to install rexx.img in the same directory as 
> librexxapi as it intended.

Unfortunately, this does not solve the problem at all in r11665.

Reverted ooRexx to trunk including CMakeList.txt and built for Mac and 
installed to the current
default directory "~/Applications". Moved ooRexx5.0.0 away from it, moved 
manually "bin/rexx.img" to
"lib" and experimented:

wu114215:bin rony$ mv rexx.img ../lib/

wu114215:bin rony$ ./rexx 
dyld: Library not loaded: @rpath/librexx.5.0.0.dylib
  Referenced from: /Users/rony/Applications/test/ooRexx5.0.0/bin/./rexx
  Reason: image not found
Abort trap: 6

Now making sure that libraries are found in "../lib":

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx *

Syntax is "rexx filename [arguments]"
or"rexx -e program_string [arguments]"
or"rexx -v".

However "Logic error: no startup image" occurs:

wu114215:bin rony$ *DYLD_LIBRARY_PATH=../lib ./rexx -e 
"out=.array~new;address '' 'ls -al' with output using
(out);say out"*
Logic error: no startup image
Illegal instruction: 4

wu114215:bin rony$ 
wu114215:bin rony$ *pwd*
/Users/rony/Applications/test/ooRexx5.0.0/bin
wu114215:bin rony$ *find .. -name rexx.img*
../lib/rexx.img

"rexx.img" is indeed located in "bin"'s sibling directory "lib".

---rony




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


Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-09 Thread Rony G. Flatscher
ld find the companion "bin" directory.

As one can see the "bin" directory on Unix includes the following binaries: 
"rexx", "rexx.img",
"rexx.cat", "rexxc", "rxsubcom", and "rxapi".
(In addition the C++ ooRexx samples "callrexx?" with "libwpipe?.dylib"get 
installed there too, which
I think should not be the case.)

So ooRexx would need to look for "rexx.img", "rexx.cat", "rxsubcom" and "rxapi" 
in the "bin"
directory, which relative to the "lib" directory can always be found with the 
relative path "../bin".

Enclosed please find an experiment with "CMakeList.txt" changed to use RPATH and
"common/platform/unix/SysProcess.cpp" to become able to locate "rexx.img" and 
the other binaries in
"bin", if moving the ooRexx directory away from its installation directory 
(currently being
"~/Applications" on MacOS)! With the enclosed patch applied it becomes possible 
to run ooRexx
without the "bin" directory being on the PATH altogether!

It got successfully tested even with using "address with":

wu114215:oha rony$ *./macos64/bin/rexx -e "out=.array~new; address '' 'ls 
-al' with output using (out); say out"*
total 0
drwxr-xr-x   4 rony  staff   128 Jan  9 13:58 .
drwxr-xr-x  89 rony  staff  2848 Jan  9 18:46 ..
drwxr-xr-x   6 rony  staff   192 Jan  9 13:57 macos64
drwxr-xr-x   6 rony  staff   192 Jan  9 13:58 old
wu114215:oha rony$ 

---

The only thing that the enclosed patch cannot handle is finding "rexx.cat", 
such that Rexx error
messages (e.g. for 'say 1/0') will instead cause a "REX0025E: Cannot open REXX 
message catalog
rexx.cat" message:

wu114215:oha rony$ *./macos64/bin/rexx -e "parse version v; say v"*
REXX-ooRexx_5.0.0(MT)_64-bit 6.05 9 Jan 2019
wu114215:oha rony$ 

wu114215:oha rony$ *./macos64/bin/rexx -e "say 'current directory:' 
directory()"*
current directory: /Users/rony/oha
wu114215:oha rony$ 

wu114215:oha rony$ *./macos64/bin/rexx -e "say 1/0"*
 1 *-* say 1/0
REX0042E: Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 42 Cannot open REXX message catalog 
rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin. INSTORE 
Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 1:  Cannot open REXX message catalog 
rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin.
REX0413E: Cannot open REXX message catalog rexx.cat.  Not in NLSPATH or 
/Users/rony/Applications/ooRexx5.0.0/bin. 42.3:  Cannot open REXX message 
catalog rexx.cat.  Not in NLSPATH or /Users/rony/Applications/ooRexx5.0.0/bin.

"/Users/rony/Applications/ooRexx5.0.0" is the directory "make install" created 
and used.

---rony


>
>
> On Tue, Jan 8, 2019 at 1:21 PM Rony G. Flatscher  <mailto:rony.flatsc...@wu.ac.at>> wrote:
>
> On 08.01.2019 19:15, Rony G. Flatscher wrote:
>>
>> While testing the standalone version on Linux, everything works out fine 
>> if issuing "rexx".
>>
> Should have also mentioned: if putting the directory where rexx resides 
> on to the path
> everything works as well.
>
> ---rony
>
>
>> However, if invoking "rexx" with a fully qualified path like:
>>
>> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>>
>> an error "Logic error: no startup image" is raised and ooRexx gets 
>> aborted with a core dump.
>> The libraries seem to be found.
>>
>> This is with r11665.
>>
>> ---rony
>>

Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 11665)
+++ CMakeLists.txt  (working copy)
@@ -52,8 +52,8 @@
 include(CheckFunctionExists)
 include(CheckSymbolExists)
 include(CheckCSourceCompiles)
-set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
-set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
+set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
+set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
 set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
 set (CMAKE_PDB_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
 set (CMAKE_SAMPLES_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/samples)
@@ -250,6 +250,24 @@
set (INSTALL_LIB_DIR ${CMAKE_INSTALL_PREFIX}/lib)
  endif ()
endif ()
+
+   # do not skip the full RPATH for the build tree
+   SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
+   # when building, 

Re: [Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-08 Thread Rony G. Flatscher
On 08.01.2019 19:15, Rony G. Flatscher wrote:
>
> While testing the standalone version on Linux, everything works out fine if 
> issuing "rexx".
>
Should have also mentioned: if putting the directory where rexx resides on to 
the path everything
works as well.

---rony


> However, if invoking "rexx" with a fully qualified path like:
>
> ~/some/path/to-standalone/bin/rexx -e "parse version v; say v"
>
> an error "Logic error: no startup image" is raised and ooRexx gets aborted 
> with a core dump. The
> libraries seem to be found.
>
> This is with r11665.
>
> ---rony
>

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


[Oorexx-devel] A crash (not finding rexx.iimg?) (Re: Experimental "standalone" ooRexx interpreters

2019-01-08 Thread Rony G. Flatscher
While testing the standalone version on Linux, everything works out fine if 
issuing "rexx".

However, if invoking "rexx" with a fully qualified path like:

~/some/path/to-standalone/bin/rexx -e "parse version v; say v"

an error "Logic error: no startup image" is raised and ooRexx gets aborted with 
a core dump. The
libraries seem to be found.

This is with r11665.

---rony

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


[Oorexx-devel] Experimental "standalone" ooRexx interpreters

2019-01-08 Thread Rony G. Flatscher
Thanks to Enrico I was able to compile ooRexx with RPATH for MacOS and Linux 
successfully which
allows one to use those interpreters "standalone" like on a stick.

The experimental standalone ooRexx interpreters for Windows (32- and 64-bit), 
Linux (64-bit) and
MacOSX (64-bit) can be temporarily found on my Dropbox:
. 
This Dropbox directory
includes a directory named "CMakeList" which contains the file CMakeList.txt 
used to create the
MacOS and Linux versions.

To use, unzip/untar the archives and run "rexx.exe"/"rexx" from the "bin" 
directory.

---rony







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


Re: [Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

2019-01-08 Thread Rony G. Flatscher
Dear P.O.,

On 08.01.2019 17:17, P.O. Jonsson wrote:
>> Am 08.01.2019 um 17:10 schrieb Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>>:
>>
>> O.K, Enrico's definitions work like a charm!
>> :)
>>
>> Ad multiple RPATHs: this works as well, one needs to separate the paths with 
>> a semi-colon, not with
>> a colon, though. However, thinking about it in the meantime, this would not 
>> be really helpful on
>> Unix based systems, although Windows users might be happy. :) The reason 
>> being that probably all
>> Unix-based builds will have a "bin" and a "lib" directory as siblings.
>>
>> Enrico's definitions should also work when installing to /usr/local as the 
>> executables land in
>> /usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib“.
>
> I would strongly advice against installing directly into /usr/local/bin and 
> /usr/local/lib. Rather
> installing into /usr/local/oorexx5.0.0 (/bin,/lib etc) and Symlink all files 
> into /usr/local/bin
> etc. This is what all other installations do. Out of 215 files in /bin 211 
> are symlinks, not
> executables.

this depends on the installation philosophy. :)

Unlike you and René I use macports which installs into "/opt/local" (and its 
subdirectories "bin",
"lib", "include", "man", "share",  etc., nowadays.

Homebrew, I understand, installs like you suggest.

mvim (the Mac version of vi improved) installs into /usr/local, etc.

No matter which philosophy one follows the "@executable_path/../lib" in the 
binaries RPATH will
allow rexx to locate its libraries in its sibling "lib" directory.

The BSF4ooRexx installation installs, as you know, according to Apple's 
installation
recommendations, hence Framework and Application bundles are used there. The 
binaries in this
environment are then symbolically linked to /usr/local/bin and /usr/local/lib. 
Thinking of this
scenario it actually may make sense to have an additional RPATH defined in this 
case (speculating
that the system will resolve the symbolic path e.g. "/usr/local/bin/rexx ->
/Library/Frameworks/ooRexx.framework/Commands/rexx" for which its libraries are 
located in
"@executable_path/../Libraries"). Will test and report back, whether this would 
really be necessary.

---rony


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


Re: [Oorexx-devel] Question ad RPATH and MacOSX

2019-01-08 Thread Rony G. Flatscher
Dear P.O.,

On 08.01.2019 16:24, P.O. Jonsson wrote:
> I am not taking about the future, it is working NOW, without any modification 
> besides the /bin
> being in the path. NO NADA NIX modifications it works out of the box. Try it.

I believe you. :)

> A relocatable installation is desirable for other reasons, such as for 
> creating an automated build
> to ~/Applications, this is NOT possible today.

With Enricos definitions this has become possible. Just tested it a few minutes 
ago successfully on
MacOSX: moved the directories in ~/Applications/ooRexx.5.0.0 to ~/oha2/test and 
successfully ran
ooRexx from ~/oha2/test/bin and all of the sample programs there as well.

Cheers,

---royn




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


[Oorexx-devel] Works and a question ad patches (Re: Question ad RPATH and MacOSX

2019-01-08 Thread Rony G. Flatscher
O.K, Enrico's definitions work like a charm!
:)

Ad multiple RPATHs: this works as well, one needs to separate the paths with a 
semi-colon, not with
a colon, though. However, thinking about it in the meantime, this would not be 
really helpful on
Unix based systems, although Windows users might be happy. :) The reason being 
that probably all
Unix-based builds will have a "bin" and a "lib" directory as siblings.

Enrico's definitions should also work when installing to /usr/local as the 
executables land in
/usr/local/bin and locating their libs is "../lib" hence "/usr/local/lib".

Will test Linux later and report back, should there be any unexpected problems.

Again, thank you very much Enrico for your advice! ooRexx now works in the most 
versatile fashion! :)

---

Just a question to the developers: is it helpful supplying a patch for 
CMakeList.txt?

The reason why I ask is that a patch got not picked up so far that creates 
symbolic links for Linux
and MacOSX. I attached it to the proper bug report, cf. 
<https://sourceforge.net/p/oorexx/bugs/1421/>.

The latest patch there is
<https://sourceforge.net/p/oorexx/bugs/_discuss/thread/4202a51e/4a68/2f6b/attachment/patch-sym-links-03.txt>
which in addition also includes two placing the libraries in the "lib" 
directory as per Enricos
suggestion and naming 64-bit rpm packages correctly. That patch got tested 
building ooRexx against
Windows, Linux and MacOSX.

---rony


On 08.01.2019 16:12, Rony G. Flatscher wrote:
> On 08.01.2019 15:52, Enrico Sorichetti via Oorexx-devel wrote:
>> Right now You cannot relocate the installed thing 
>> Because the rpath is an absolute one 
>> I posted a few emails back the right constructs …
> Hmm saw them, but was not sure what they were about and whether that was all 
> that was needed (being
> totally unfamiliar with RPATH)! :(
>
>> Here they are again
>>
>> With these settings  all works fine for me without bothering 
>> To export DYLD_LIBRARY_PATH or LD_LIBRARY_PATH
>>
>> # do not skip the full RPATH for the build tree
>> SET( CMAKE_SKIP_BUILD_RPATH  FALSE)
>>
>> # when building, don't use the install RPATH 
>> # only later on when installing 
>> SET( CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
>>
>> if( APPLE )
>>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib")
>> else()
>>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
>> endif()
>>
>> # add the automatically determined parts of the RPATH
>> # which point to directories outside the build tree to the install RPATH
>> SET( CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> Is it correct to state in this case that the executable's libraries then get 
> automatically searched
> in the sibling "lib" directory?
>
>> Without the RPATH setting the exports are required 
>>
>> ( tested on El Capitan, high Sierra, Mojave and Fedora 29 )
> This is great, thank you very much indeed (also for your patience! :) ), will 
> try it out on both
> MacOSX and Linux!
>
>> Why would anybody set multiple paths ???
> Well, in Windows the libraries are usually on the PATH and hence a standalone 
> ("stick") version of
> ooRexx on Windows might have the dlls in the same directory as ooRexx. Even 
> though Windows should
> not serve as the role model for Unix, nevertheless such layouts or solutions 
> might be attempted
> (easier understandable) for users (not developers).
>
> People coming from Windows might therefore intend to place the shared 
> libraries on Unix into the
> executable directory as well or move "lib" to become local to the executable 
> directory (this way a
> subdirectory "oorexx" would point to the ooRexx executable and include all 
> necessary files directly
> there, including the libraries or the "lib" directory).
>
> How would one add multiple RPATHs with CMake? Would just adding another 
> directory to the path rpath
> with a colon be correct, something like:
>
> if( APPLE )
>     SET( CMAKE_INSTALL_RPATH "@executable_path/../lib:@executable_path/.")
> else()
>     SET( CMAKE_INSTALL_RPATH "$ORIGIN/../lib:$ORIGIN/.")
> endif()
>
> Will test it, after first testing your "@executable_path/../lib"  definition.
>
> Again, thank you very much, Enrico!
>
> ---rony
>
>
>



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


  1   2   3   4   5   6   7   8   9   10   >