bsf4oorexx-devel — Developer list

[Bsf4oorexx-devel] Fwd: rebooting OpenJDK mobile

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

FYI a posting to the mobile OpenJDK (the opensource Java development) mailing list dealing with
mobile versions of OpenJDK with Rexx relevance.

Things useful to know:

  * Apple prohibits the use of just-in-time-compilers on their operating systems (which is
    outrageous IMHO)
  * the project tries therefore to create build-chain-tool that would be able to precompile JavaFX
    applications for mobiles to by-pass that Apple restriction for non-Apple software,
  * there is still a need for compiling Java source code at runtime, such that the resulting Java
    byte code needs to be interpreted on Apple operating systems, my postings try to make the
    continuing need for this known,
  * Johan Vos is one of *the* OpenJavaFX project leads, also his company is specialized on creating
    Java and JavaFX applications for mobiles, and also is a maintainer of the WYSIWYG JavaFX GUI
    editor named "SceneBuilder" for which they maintain installers for all operating systems

Once an ooRexx port to Android or iOS becomes available (not aware of any current efforts in that
area), it would become possible to create mobile apps with ooRexx using BSF4ooRexx, the ooRexx-Java
bridge, once BSF4ooRexx (actually a single C++ program in the package) gets ported to those
platforms as well.

Best to read from the bottom to the top.

---rony

P.S.: Would there be anyone interested in trying ooRexx ports to Android and/or iOS? Or taking
advantage of such eventual ports on those platforms?



-------- Forwarded Message --------
Subject: 	Re: rebooting OpenJDK mobile
Date: 	Tue, 2 Jul 2019 14:53:20 +0200
From: 	Rony G. Flatscher <Ron...@wu...>
To: 	Johan Vos <joh...@gl...>
CC: 	mob...@op...



Hi Johan,

On 02.07.2019 11:47, Johan Vos wrote:
> The Apple specific restrictions are still valid: you can not compile code at runtime. Hence,
> sending Java bytecode to a running app, and have it compiled there won't work. 
> The classes need to be compiled before runtime, and part of the executable. 
> I believe that in theory, it should be possible with e.g. Zero interpreter to interpret new
> bytecode, as that is not generating new native code. 
>
> Can you elaborate on your use case so that we can see how we can handle this?

Sure: one such important area is supporting dynamic scripting languages via the Java scripting
framework (javax.script package).

As an author of one such Java scripting engine implementation for ooRexx (and serving as an expert
on the JSR-223 which came up with the specifications implemented in javax.script) that itself is not
implemented in Java but in C++. [So JNI is in the picture here as well. This particular Java script
engine implementation is called BSF4ooRexx and hosted on Sourceforge; ooRexx is now an independent
open-source project hosted on Sourceforge as well.]

There is a constant need to create dynamically Java adapter classes at runtime. One example is for
extending abstract Java classes with ooRexx, another example is implementing Java interface classes
in ooRexx, another one extending normal Java classes in ooRexx.  E.g. implementing event handlers or
lambda functions in ooRexx or extending the abstract Java class javafx.application.Application with
ooRexx.

One important application area nowadays is to use this infrastructure to create JavaFX applications
without coding in Java at all, but solely in the programming language ooRexx, which has a very easy
syntax, hence is quite easy to learn (and easy to teach) but still is very powerful (ooRexx is a
message-based, dynamic, object-oriented programming language, originally developed by IBM, now in
opensource).

Therefore the (urgent) need to remain able to dynamically create and use those adapter Java classes
at runtime! [3] and [5] are slides demonstrating how one can use ooRexx to create
JavaFX-applications; the slides in [1] explain briefly the javax.script.Engine implementation for
ooRexx; [4], [6], [2] are the accompanying articles. (All these JavaFX applications created with
ooRexx run unchanged on Windows, Linux and MacOS.)

ASM [7] and later Janino [8] have been used for this purpose for more than fifteen years! Not
supporting compiling and loading Java classes at runtime will break such (and related) support.

Please note, the need for dynamically creating and using Java classes at run time is not restricted
to these use-cases, any dynamic Java programming technique would be affected.

Also, given today's power found in practically all computer devices, including mobile devices,
interpreting Java byte code in these use-cases would be fine (the overall speed improvement would be
gained by the pre-compiled run time/application anyway)!

---rony

Links:

[1] RexxScriptEngine, slides:
<http://www.rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-06-RexxScript.pdf>

[2] RexxScriptEngine, article:
<http://www.rexxla.org/events/2017/presentations/201704-RexxScript-Article.pdf>

[3] JavaFX for ooRexx - Creating Powerful Portable GUIs, slides:
<http://www.rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-07-JavaFx-201711.pdf>
Note: at the end there are screenshots of an ooRexx implementation of the classic JavaFX tutorial
"address book" which gets distributed with the BSF4ooRexx package and can be studied there.

[4] JavaFX for ooRexx - Creating Powerful Portable GUIs, article:
<http://www.rexxla.org/events/2017/presentations/201711-ooRexx-JavaFX-Article.pdf>

[5] Anatomy of a GUI (Graphical User Interface) Application for Rexx Programmers, slides:
<http://www.rexxla.org/events/2018/presentations/201803-AnatomyOfGUI.pdf>

[6] Anatomy of a GUI (Graphical User Interface) Application for Rexx Programmers, article:
<http://www.rexxla.org/events/2018/presentations/201803-AnatomyOfGUI-Article.pdf>

[7] Homepage of ASM: <https://asm.ow2.io/>

[8] Homepage of Janino, noting some projects using it: <https://janino-compiler.github.io/janino/>

P.S.: I have been puzzled by Apple's restriction, which is inhibiting any form of innovation by
non-Apple software and wonder whether such a restriction would be legal in the European Union.

P.P.S.: Also, I have been thinking on improving javax.script support in the FXMLLoader class and
maybe the WebView class a little bit.



> On Sun, Jun 30, 2019 at 1:45 PM Rony <ron...@wu... <mailto:ron...@wu...>> wrote:
>
>     Hi Johan,
>
>     would it still be possible to compile Java classes and load them at runtime?
>
>     —-rony
>
>     Rony G. Flatscher (mobil/e)
>
>     > Am 28.06.2019 um 16:09 schrieb Johan Vos <joh...@gl... <mailto:joh...@gl...>>:
>     >
>     > Hi,
>     >
>     > After a long time, it is a good moment now to restart the public work in
>     > the OpenJDK Mobile project.
>     > In the past, we had a repository with code based on OpenJDK 9 that allows
>     > to build the class libraries (including native code) and one or more VM's,
>     > for Android and iOS.
>     >
>     > While this works, we still have the limitation on iOS where dynamic code is
>     > not allowed, hence a JIT is not an option. The Zero VM works there
>     > (interpreter mode) but is slow.
>     >
>     > Today, we can use the GraalVM AOT compiler to compile the code at build
>     > time. We can link the compiled Java code with native libraries compiled for
>     > the target OS, and create executables. Most of the VM functionality is
>     > provided by a very small set of files in SubstrateVM (linked to by GraalVM
>     > native image)
>     >
>     > We already did this for iOS, based on Java 11 (see
>     > https://github.com/johanvos/openjdk-mobile11/tree/mobile) and JavaFX 13.
>     > (see our announcement at https://gluonhq.com/java-on-ios-for-real/)  The
>     > diff to the upstream code is remarkably small.
>     >
>     > It is my goal now to use project Skara to create a synchronized fork of the
>     > OpenJDK master, and to push the changes required to build the native libs
>     > for the core libraries in there.
>     > Ultimately, it would be ideal if all required changes can go upstream.
>     >
>     > At this moment, this is iOS only, but there are no showstoppers to do this
>     > for Android as well. The architectures are pretty similar.
>     >
>     > - Johan
>

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

[Rony G. F. <Ron...@wu...>]

At <http://wi.wu.ac.at/rgf/diplomarbeiten/index.html> 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

[Bsf4oorexx-devel] New syntax error in "bsf.importClass" for supplying abstract Java classes: "bsf.importClass" vs. "bsf.loadClass"

[Rony G. F. <Ron...@wu...>]

Starting with the latest betas of BSF4ooRexx there has been an important change: "bsf.importClass"
now checks, whether the Java class to be imported is abstract or not. If abstract a new syntax error
40.900 will get raised with an error message that explains the problem and how to resolve it: just
rename "bsf.importClass" to "bsf.loadClass" for abstract Java classes!

This change was incurred by <https://sourceforge.net/p/bsf4oorexx/bugs/46/>, which is a very subtle
bug that has become possible because of the needed reflection changes to access the new modular Java
system (starting with Java 9).

---

"bsf.importClass" vs. "bsf.loadClass"
------------------------------------------------

BSF.CLS defines two public routines (and BSF class methods) named "bsf.importClass" and
"bsf.loadClass". Both allow loading a Java class, returning an ooRexx proxy for them. The difference
between the two is as follows:

  * "bsf.importClass(javaClassName[,name4env])": loads javaClassName, adds the ooRexx methods "new"
    and "newStrict" and returns the ooRexx proxy object that then can be used to easily create Java
    objects by sending it the "new" (or "newStrict") message. If the optional second argument
    "name4env" is supplied, then the ooRexx proxy object gets stored in the ooRexx .environment
    under the name "name4env".
    "bsf.importClass" now raisies an error 40.900 if "javaClassName" denotes an abstract Java class.
    The error message will inform to replace the invocation of "bsf.importClass" with "bsf.loadClass".

  * "bsf.loadClass(javaClassName[,nmae4env])": loads javaClassName and returns its ooRexx proxy
    object. If the optional second argument "name4env" is supplied, then the ooRexx proxy object
    gets stored in the ooRexx .environment under the name "name4env".

In both cases the ooRexx proxy object understands all messages that cause access to public static
(class) Java fields and public static (class) Java methods.

---rony

P.S.: The ooRexx .environment is available to all ooRexx interpreter instances that execute in a
single process. (The ooRexx .local environment is scoped to a single ooRexx interpreter instance,
ie. each ooRexx interpreter instance has its own, separate .local environment.)

[Bsf4oorexx-devel] 获客管理系统，有效管理自己的商机线索

[xinpa015627 <xin...@16...>]

胇耬肽肩肉胯>go胘聠肵耠联胗肣考胡胏聟聓联胑耵聎聶肓聙老聩胞耙>og聉胬肉胜胇耿耬胶胦考聀胭耭肪胍肬胝肉聺聀肪>le免翻墙搜索，耵耦耴胷耞聵耲聜聥胎翻肮聭胕胸肠耀肗>闃閏闽镞>一键挖闍闥阧闪闃闞镀閐闩閼閐閁闯镳阑镙>掘客户閟锯镾锰阌镣閞阆闌閞镮閩锾镆镞镎>采购信息，镒閦閟阒阠阀閏锴閞镲阄镒閛闘>魮魉鬻鬡>精准鯒鬒鬌髹魡髷魙魂魶鮐鬃魲魐鬱髜魥>搜索鯓髝鮯髩魛鬿鬒鯅鮣鯉魥鬗鮒鬼鬲鬳鮣髿魎魋鮸鯀魍鮧>，高魈魺髸鬮髣魮魢魇魔魸鯕魇魞魳鮪髱鯗魹鮪魷鮯髨髧鬔>效投递，短期可见效鮕髙魹鮜魣鯆鯄髥鬕鮦鮯髙魁魚鬞魝鬥魶鮣魋>

迚遄郋郂逄遇> 欢迎咨询迣邘邻迬遣逫遥邢迧>

iqjsnx> Qqesdwxxnvbsmkvffwadguinhw>Q：aygaeuqipnowydkwthcbhcpqyf>3163745494jtycfrpxzqrntecpbctxthpkrdz>

豔谚豍> 电買谊谬豾貯貟豠賙賉賜诠賜豪诡貭谵谈谧賛貝販>话：貘询貯豈貓豱豽谓谄谫豩貢读谝谬貭豪貓賅>075豔谳貎財谱诨诞豞谇谩谞貗豲賀賈谕谍诿豼说谕豈诩谣貜貁谲豍貧谴>532801027豰豦貜谥豞谸貽豜询谝谝豑賆貏貃豵賃貇豷貘豚豽貿豹貏貱谽豢诨賜> 

[Bsf4oorexx-devel] New ooRexx 5.0 beta features added to ooRexxPlugin4Intellij

[Alexander S. <ale...@gm...>]

Hello,

I have added the recent ooRexx 5.0 beta features to the ooRexx plugin:
https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/aseik/ooRexxIDEA/beta/1.0.4/

Your feedback would be appreciated. If you find any missing ooRexx 5.0 beta
features please open a ticket:
https://sourceforge.net/p/bsf4oorexx/oorexxplugin/

Best Regards
Alexander

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

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

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

    <https://sourceforge.net/projects/bsf4oorexx/files/beta/20190203/>.


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
<https://sourceforge.net/p/bsf4oorexx/bugs/>.

---

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:
<https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. 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
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/> 
(<mailto:bsf...@li...>).

Cheers,

---rony

Re: [Bsf4oorexx-devel] ooRexx and BSF4ooRexx from an USB stick ...

[Rony G. F. <Ron...@wu...>]

Because of a question I got I realized that one needs the "standalone" version of ooRexx for those
platforms as the installers work as in the past and require administrative rights. So I tried to
create these standalone archives for Windows (32- and 64-bit), Linux (64-bit) and MacOSX (64-bit).

You may get at those archives temporarily from my Dropbox at:
<https://www.dropbox.com/sh/e2ghouwglhnlnjf/AAAwK4XkxIn4cpU1I8K3ehf9a?dl=0>.

To use, unzip/untar the archives and run "rexx.exe"/"rexx" from the "bin" directory (e.g. from an
USB stick).

You may want to add the path to that bin directory to your environment to use rexx from any other
location as well.

---rony


On 08.01.2019 10:41, Rony G. Flatscher wrote:
>
> Just noticed that the "adopt open JDK" web site is in the "net" domain, not the "org" domain, so
> here the proper link: <https://adoptOpenJDK.net>; apologies for the confusion.
>
> Modern versions of Java include the compiler, hence "JDK" for "Java developer kit" which
> supersedes "JRE" (Java runtime environment, which was a slightly stripped down version of the JDK).
>
> ---rony
>
>
> On 08.01.2019 10:35, Rony G. Flatscher wrote:
>>
>> Over the past few weeks a lot of development has taken place with ooRexx. One very important
>> option that has become available is the new ability for ooRexx to run it from any place including
>> an USB-stick, i.e. there is no need anymore to install it with administrator rights!
>>
>> Among other things this means, that one has become able to run ooRexx programs and utilities off
>> an USB stick on other computers without having to install ooRexx on to that computer! This would
>> also allow you to show off what ooRexx is capable of by bringing along your USB stick with ooRexx
>> on it.
>>
>> As USB sticks are quite large it would be even possible to have ooRexx for Windows in 32-bit and
>> 64-bit as well as for Linux as well as for MacOS on an USB stick!
>>
>> Now, BSF4ooRexx allows one to be run without administrative installations as well. Here are the
>> directions of how to do it for all operating systems:
>>
>>   * unzip the zip-archive on the stick,
>>
>>   * whenever there is a need for BSF4ooRexx change into "bsf4oorexx/install" on the stick and run
>>     "setupBSF.rex" which will copy the proper DLL/shared library to "bsf4oorexx", create two files
>>       o "rexxj.cmd" (on Unix: "rexxj.sh") which you use to run Rexx scripts interacting, taking
>>         advantage of Java, no need to change the environment (this script runs Java, loads Rexx
>>         and executes the supplied Rexx program; if the environment variable named
>>         "BSF4Rexx_JavaStartupOptions" is set, then its value is used for creating the JVM, this
>>         would allow e.g. to increase the minimum or maximum heap size etc.; just supply the flags
>>         as on the command line, to see them issue "java -X" on the command line)
>>       o "setEnvironment4BSF.cmd" (on Unix: "setEnvironment4BSF.sh"): this script will change the
>>         current Terminal's environment (on Unix you need to issue it as "export
>>         setEnvironment4BSF.sh"). Afterwards you may directly run the Rexx scripts that interact
>>         with Java, BSF4ooRexx will demand load Java)
>>
>>   * should the target machine have OpenOffice or LibreOffice installed, then you can issue
>>     "setupOOo.rex" which will create  the file "setEnvironment4OOo.{cmd|sh}". Run these scripts
>>     to change the environment (CLASSPATH will get extended by the Java archives that allow one to
>>     interact with OpenOffice/LibreOffice). After that any Rexx scripts interacting with
>>     OpenOffice/LibreOffice can be run (cf. the Rexx scripts in the "bsf4oorexx/samples/OOo"
>>     subdirectory).
>>
>> It would be even possible to also have Java for all operating systems available on the stick
>> (e.g. Java from http:/adoptOpenJDK.org or http:/java.com). As long as setupBSF.rex is able to
>> locate it (e.g. via the PATH) the above procedure should work.
>>
>> If you use the stick on a different computer, then you need to simply run "setupBSF.rex" followed
>> by a "setEnvironment4BSF.{cmd|sh}" and then "setupOOo.rex" in that sequence.
>>
>> ---rony
>>
>> P.S.: The current version ooRexx 5.0 beta can be downloaded from the official Sourceforge site
>> at: <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. The current version of
>> BSF4ooRexx 6.00 beta can be downloaded from the official Sourceforge site at:
>> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.
>>
>> Temporarily the latest ooRexx (for all operating systems) and BSF4ooRexx builds can be downloaded
>> from my Dropbox at <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.
>> Please not also that the MacOSX version of BSF4ooRexx includes the latest ooRexx 5.0 beta already
>> (installation package "b4r_600_500_64Bit_macosx-20190107-r11662-macosx-relWithDebInfo.zip").
>>

Re: [Bsf4oorexx-devel] ooRexx and BSF4ooRexx from an USB stick ...

[Rony G. F. <Ron...@wu...>]

Just noticed that the "adopt open JDK" web site is in the "net" domain, not the "org" domain, so
here the proper link: <https://adoptOpenJDK.net>; apologies for the confusion.

Modern versions of Java include the compiler, hence "JDK" for "Java developer kit" which supersedes
"JRE" (Java runtime environment, which was a slightly stripped down version of the JDK).

---rony


On 08.01.2019 10:35, Rony G. Flatscher wrote:
>
> Over the past few weeks a lot of development has taken place with ooRexx. One very important
> option that has become available is the new ability for ooRexx to run it from any place including
> an USB-stick, i.e. there is no need anymore to install it with administrator rights!
>
> Among other things this means, that one has become able to run ooRexx programs and utilities off
> an USB stick on other computers without having to install ooRexx on to that computer! This would
> also allow you to show off what ooRexx is capable of by bringing along your USB stick with ooRexx
> on it.
>
> As USB sticks are quite large it would be even possible to have ooRexx for Windows in 32-bit and
> 64-bit as well as for Linux as well as for MacOS on an USB stick!
>
> Now, BSF4ooRexx allows one to be run without administrative installations as well. Here are the
> directions of how to do it for all operating systems:
>
>   * unzip the zip-archive on the stick,
>
>   * whenever there is a need for BSF4ooRexx change into "bsf4oorexx/install" on the stick and run
>     "setupBSF.rex" which will copy the proper DLL/shared library to "bsf4oorexx", create two files
>       o "rexxj.cmd" (on Unix: "rexxj.sh") which you use to run Rexx scripts interacting, taking
>         advantage of Java, no need to change the environment (this script runs Java, loads Rexx
>         and executes the supplied Rexx program; if the environment variable named
>         "BSF4Rexx_JavaStartupOptions" is set, then its value is used for creating the JVM, this
>         would allow e.g. to increase the minimum or maximum heap size etc.; just supply the flags
>         as on the command line, to see them issue "java -X" on the command line)
>       o "setEnvironment4BSF.cmd" (on Unix: "setEnvironment4BSF.sh"): this script will change the
>         current Terminal's environment (on Unix you need to issue it as "export
>         setEnvironment4BSF.sh"). Afterwards you may directly run the Rexx scripts that interact
>         with Java, BSF4ooRexx will demand load Java)
>
>   * should the target machine have OpenOffice or LibreOffice installed, then you can issue
>     "setupOOo.rex" which will create  the file "setEnvironment4OOo.{cmd|sh}". Run these scripts to
>     change the environment (CLASSPATH will get extended by the Java archives that allow one to
>     interact with OpenOffice/LibreOffice). After that any Rexx scripts interacting with
>     OpenOffice/LibreOffice can be run (cf. the Rexx scripts in the "bsf4oorexx/samples/OOo"
>     subdirectory).
>
> It would be even possible to also have Java for all operating systems available on the stick (e.g.
> Java from http:/adoptOpenJDK.org or http:/java.com). As long as setupBSF.rex is able to locate it
> (e.g. via the PATH) the above procedure should work.
>
> If you use the stick on a different computer, then you need to simply run "setupBSF.rex" followed
> by a "setEnvironment4BSF.{cmd|sh}" and then "setupOOo.rex" in that sequence.
>
> ---rony
>
> P.S.: The current version ooRexx 5.0 beta can be downloaded from the official Sourceforge site at:
> <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. The current version of
> BSF4ooRexx 6.00 beta can be downloaded from the official Sourceforge site at:
> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.
>
> Temporarily the latest ooRexx (for all operating systems) and BSF4ooRexx builds can be downloaded
> from my Dropbox at <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.
> Please not also that the MacOSX version of BSF4ooRexx includes the latest ooRexx 5.0 beta already
> (installation package "b4r_600_500_64Bit_macosx-20190107-r11662-macosx-relWithDebInfo.zip").
>

[Bsf4oorexx-devel] ooRexx and BSF4ooRexx from an USB stick ...

[Rony G. F. <Ron...@wu...>]

Over the past few weeks a lot of development has taken place with ooRexx. One very important option
that has become available is the new ability for ooRexx to run it from any place including an
USB-stick, i.e. there is no need anymore to install it with administrator rights!

Among other things this means, that one has become able to run ooRexx programs and utilities off an
USB stick on other computers without having to install ooRexx on to that computer! This would also
allow you to show off what ooRexx is capable of by bringing along your USB stick with ooRexx on it.

As USB sticks are quite large it would be even possible to have ooRexx for Windows in 32-bit and
64-bit as well as for Linux as well as for MacOS on an USB stick!

Now, BSF4ooRexx allows one to be run without administrative installations as well. Here are the
directions of how to do it for all operating systems:

  * unzip the zip-archive on the stick,

  * whenever there is a need for BSF4ooRexx change into "bsf4oorexx/install" on the stick and run
    "setupBSF.rex" which will copy the proper DLL/shared library to "bsf4oorexx", create two files
      o "rexxj.cmd" (on Unix: "rexxj.sh") which you use to run Rexx scripts interacting, taking
        advantage of Java, no need to change the environment (this script runs Java, loads Rexx and
        executes the supplied Rexx program; if the environment variable named
        "BSF4Rexx_JavaStartupOptions" is set, then its value is used for creating the JVM, this
        would allow e.g. to increase the minimum or maximum heap size etc.; just supply the flags as
        on the command line, to see them issue "java -X" on the command line)
      o "setEnvironment4BSF.cmd" (on Unix: "setEnvironment4BSF.sh"): this script will change the
        current Terminal's environment (on Unix you need to issue it as "export
        setEnvironment4BSF.sh"). Afterwards you may directly run the Rexx scripts that interact with
        Java, BSF4ooRexx will demand load Java)

  * should the target machine have OpenOffice or LibreOffice installed, then you can issue
    "setupOOo.rex" which will create  the file "setEnvironment4OOo.{cmd|sh}". Run these scripts to
    change the environment (CLASSPATH will get extended by the Java archives that allow one to
    interact with OpenOffice/LibreOffice). After that any Rexx scripts interacting with
    OpenOffice/LibreOffice can be run (cf. the Rexx scripts in the "bsf4oorexx/samples/OOo"
    subdirectory).

It would be even possible to also have Java for all operating systems available on the stick (e.g.
Java from http:/adoptOpenJDK.org or http:/java.com). As long as setupBSF.rex is able to locate it
(e.g. via the PATH) the above procedure should work.

If you use the stick on a different computer, then you need to simply run "setupBSF.rex" followed by
a "setEnvironment4BSF.{cmd|sh}" and then "setupOOo.rex" in that sequence.

---rony

P.S.: The current version ooRexx 5.0 beta can be downloaded from the official Sourceforge site at:
<https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. The current version of BSF4ooRexx
6.00 beta can be downloaded from the official Sourceforge site at:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

Temporarily the latest ooRexx (for all operating systems) and BSF4ooRexx builds can be downloaded
from my Dropbox at <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.
Please not also that the MacOSX version of BSF4ooRexx includes the latest ooRexx 5.0 beta already
(installation package "b4r_600_500_64Bit_macosx-20190107-r11662-macosx-relWithDebInfo.zip").

[Bsf4oorexx-devel] New MacOS version of BSF4ooRexx allowing LO and AOO Rexx macros again ...

[Rony G. F. <Ron...@wu...>]

In the past days I have been quite busy analyzing a problem with OpenOffice and LibreOffice Rexx
macros on MacOS.

To make a long story short, the macro support should work with the latest versions of AOO and LO, if
you install BSF4ooRexx for MacOS from
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

---rony

[Bsf4oorexx-devel] [RexxLA] New beta version of BSF4ooRexx available (version 20181221)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

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.

---

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: <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>
. Regularly check for new builds there. [Temporarily there are installations packages of today's
ooRexx trunk, revision 11636, in my dropbox at:
<https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.]

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
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/> 
(<mailto:bsf...@li...>).

Cheers,

---rony

[Bsf4oorexx-devel] New beta version of BSF4ooRexx available (version 20181130)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

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.

---

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: <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>
. Regularly check for new builds there. [Temporarily there are installations packages of today's
ooRexx trunk, revision 11582, in my dropbox at:
<https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>.]

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 11582.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/>
(<mailto:bsf...@li...>).

Cheers,

---rony

[Bsf4oorexx-devel] New beta version of BSF4ooRexx available (version 20181105)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>, which resolves a bug when using
bsf.invokeStrict(). As a result there are no open bugs recorded against this package anymore! :)

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.

  * Notable new addition in this version: new public Rexx routine "box.strictArg(type, value [,
    primitive=.true])", where "type" may be one of the strings "BOolean", "BYte", "Character",
    "Double", "Float", "Integer", "Object", "SHort", "STring", or a Java class object, denoting the
    type of "value", comparable to the already existing public routine "box(type,value)". This
    version however returns a Java object (a RexxStrictArgument object) that, if used as an
    argument, will strictly pick a candidate Java field, method or constructor matching exactly that
    type. All bsf.*strict-methods will use box.strictArg() in place of box() in order to fix a quite
    subtle bug. Cf. an example looking at "samples/JavaFX/fxml_99/MainApp.rex".

---

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: <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>
. Regularly check for new builds there.

(Temporarily the Windows versions for revision 11515 (as of today the latest version) can be
obtained from my DropBox at
<https://www.dropbox.com/sh/gh7v4m04hc2tqgz/AAAY686kv7JDRu0CNn1FoqFDa?dl=0>).

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 11515.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/>
(<mailto:bsf...@li...>).

Cheers,

---rony

[Bsf4oorexx-devel] Request for Paul D. (s390x)

[Rony G. F. <Ron...@wu...>]

Dear Paul,

with separate e-mail addressed directly to your e-mail address I will send the source of
BSF4ooRexx.cc with the request to compile it for s390x to be included in the next BSF4ooRexx
distribution as a binary, replacing the current one.

TIA

---rony

[Bsf4oorexx-devel] New beta version of BSF4ooRexx available (version 20181025)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit Java classes.
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.

  * Notable new addition in this version: binary support for 32-bit ARM (Raspberry Pi), such that
    BSF4ooRexx can be installed on that platform as well!

If 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: <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>
. Regularly check for new builds there.

(Temporarily the Windows versions for revission 11503 can be obtained from my DropBox at
<https://www.dropbox.com/sh/xh2p56y56xrk1f1/AADj5EbDh2ZzA0tl8KzFV9FMa?dl=0>).

The quality of the current beta versions of 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 11503.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/>
(<mailto:bsf...@li...>).

Cheers,

---rony

[Bsf4oorexx-devel] New beta version of BSF4ooRexx available (version 20181002)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

since a few minutes there is a new beta of BSF4ooRexx available from Sourceforge, namely from:
<https://sourceforge.net/projects/bsf4oorexx/files/beta/20181002/>.

BSF4ooRexx is an ooRexx external function package that allows Rexx programs to exploit Java classes.
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.

There are two newer public routines made available via BSF.CLS that I would like to draw your
attention to:

  * bsf.iconv(string, fromCharset, toCharset): translates "string" encoded in the "fromCharset" to
    the "toCharset" and returns it

      o cf. the "samples" folder that gets installed with BSF4ooRexx lookup the sample named
        "1-080_charsetTranslations.rxj", which also has a link pointing at the standard CharSets
        available in Java

  * bsf.contextClassLoader(  [list-of-jarfiles|list-of-directories|list-of-urls] ): this routine
    queries (if no arguments supplied) or sets the Java's Thread ContextClassLoader (according to
    the supplied arguments). This will allow to dynamically add new Java classes to a running program

      o cf. the "samples/JavaFX/fxml_05" folder that gets installed with BSF4ooRexx lookup the
        sample named "staff.rxj"

If 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:
<https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. Regularly check for new builds
there. The quality of the current beta versions is of type "release" and it contains bug fixes over
ooRexx 4.2.

If you have any questions please come forward and ask!

Replies to this e-mail will go to the BSF4ooRexx-Sourceforge-mailing list
<https://sourceforge.net/p/bsf4oorexx/mailman/bsf4oorexx-devel/>
(<mailto:bsf...@li...>).

Cheers,

---rony

Re: [Bsf4oorexx-devel] General question on making a GUI using Bsf4ooRexx

[Rony G. F. <Ron...@wu...>]

Dear P.O.:

On 27.09.2018 10:32, P.O. Jonsson wrote:
> I am in need of a custom built viewer that could load two different documents (PDFs preferably) in
> two separate windows in a single application. Would this be possible with bsf4ooRexx using Swing
> or any other method? How much work is involved? Can you point me to a similar thingy to start from? 
>
> In the initial state it would be fine with a very rudimentary viewer (left text, right images), a
> single application that can load 2 separate (different or the same) PDFs that could be
> independently scrolled would be great.
>
> Or, if you know about such a viewer out there, please point me to it.
>
> Here´s a mockup of what I have in mind
>
>
If possible I would advise to use JavaFX as it allows you to use the SceneBuilder utility to create
and maintain the declarative FXML text file that defines the GUI. Your program would synchronize
both views according to your needs.

You may need to invest some time to get enough different JavaFX related PDF libraries, many are
commercial, however some are LGPL for basic versions to appetite the users for the commercial
version. From a first search it seems that this should be doable, but study the license terms before
committing to a certain library.

Here some hits:

  * <https://alternativeto.net/software/openviewerfx/>
  * <https://github.com/pdf4j/pdf4j-jpedal>
  * <https://www.java-forum.org/thema/pdfviewer-fuer-javafx-anwendung.177591/> (German)
  * <https://kbdeveloper.qoppa.com/javafx-pdf-viewer/>
  * <https://sourceforge.net/directory/os:windows/?q=pdf+viewer+javafx>
  * or even something like <https://stackoverflow.com/questions/48523716/open-source-pdfviewer-javafx>

Whatever you come up with, it would be great, if you would let us know for which libraries you
settled and how you realized your mockup!

Good luck!

---rony

[Bsf4oorexx-devel] General question on making a GUI using Bsf4ooRexx

[P.O. J. <oo...@jo...>]

Dear developers,

I am in need of a custom built viewer that could load two different documents (PDFs preferably) in two separate windows in a single application. Would this be possible with bsf4ooRexx using Swing or any other method? How much work is involved? Can you point me to a similar thingy to start from? 

In the initial state it would be fine with a very rudimentary viewer (left text, right images), a single application that can load 2 separate (different or the same) PDFs that could be independently scrolled would be great.

Or, if you know about such a viewer out there, please point me to it.

Here´s a mockup of what I have in mind




Hälsningar/Regards/Grüsse,
P.O. Jonsson
oo...@jo...

[Bsf4oorexx-devel] Update, new version "20180726", plus MacOSX version available (Re: New beta version of BSF4ooRexx available (version 20180721)

[Rony G. F. <Ron...@wu...>]

Please note, that as of today (July 26th) there is a new version of BSF4ooRexx, including a 64-bit
version for MacOSX users that includes today's ooRexx 5.0 beta version with the new "address with"
feature and "variable reference" features!

---rony


On 21.07.2018 20:21, Rony G. Flatscher wrote:
> Dear fellow Rexxers,
>
> a few minutes ago I uploaded a new beta version of BSF4ooRexx (an ooRexx to Java bridge) to
> Sourceforge at <https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/>.
>
> Its name is "BSF4ooRexx_install_v600-20180721-beta.zip". Unzip it, change into the directory
> "bsf4oorexx/install/windows" or "bsf4oorexx/install/linux" and run the "install" script from
> there. [The installation script will copy all the files to the operating system's proper
> directories like "/opt/bsf4ooRexx" on Linux or "%ProgramFile%\BSF4ooRexx" (64-bit) or
> "%ProgramFile(x86)%\BSF4ooRexx" (32-bit), such that you can delete the unzipped directories and
> files after the installation.]
>
> It is advised to use the latest beta of ooRexx 5.0 from
> <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. E.g. for Windows, look for the
> latest "exe" file, download it and install it. Alternatively, download and install rather new
> installation packages for ooRexx 5.0 beta from my DropBox at
> <https://www.dropbox.com/sh/lsu8inlo2o99j96/AABHGsFLe9E0OVwjehRINwdZa?dl=0>.
>
> As BSF4ooRexx is a bridge between ooRexx and Java you also need to have Java installed on your
> computer. If not yet installed, then you could get a version e.g. from <http://java.com>. In this
> case please make sure that the bitness (32- or 64-bit) of Java matches the ooRexx bitness (look at
> the output of "rexx -v" and look for the output line led in with "Adressing mode:").
>
> ---
>
> First steps after installation: check out the BSF4ooRexx menu on your system and the menu "GUI
> Rexxtry Program" which allows you to enter Rexx code in a GUI and run it from there.
>
> Also highly recommended: pick the menu "BSF4ooRexx -> Samples". This directory/folder and all its
> subdirectories/folders contain numerous very short "nutshell" Rexx programs that demonstrate what
> can be done from Rexx with the external function package "BSF4ooRexx"! Just click on the
> "index.html" file which will briefly explain each Rexx script!
>
> This version of BSF4ooRexx includes the following new nutshell examples, which are highly
> recommended to be run and inspected by you! :)
>
>   * "samples\1-080_charsetTranslations.rxj": this Rexx program will demonstrate the new public
>     Rexx routine "bsf.iconv(string,fromCharset,toCharset)". It will convert the German umlauts and
>     the German sharp-s into different codepages/charsets (Cp850, Cp1252, ISO8859_1, UTF_16,
>     MacRoman, UTF_16BE, UTF_16LE, UTF8, ASCII).
>     This routine will become more and more important for Rexx programmers as more and more text
>     files get encoded in UTF (Unicode). bsf.iconv() makes it easy to convert such text files to
>     your codepage/charset and then process them as usual with Rexx.
>
>   * "samples\JavaFX\javafx_dialog_demo.rxj": JavaFX introduced nice dialogs in Java 8 which are
>     explained in Java in the blog at <http://code.makery.ch/blog/javafx-dialogs-official/>, which
>     not only shows the code but also pictures of the new JavaFX dialogs. This nutshell Rexx
>     program uses the very same JavaFX dialogs in pure ooRexx and demonstrates how simple it is to
>     use them from ooRexx! :)
>
>   * "samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj": this Rexx program will
>     demonstrate how to safely update an awt Label in a GUI from a separate (non-GUI) Rexx thread
>     using the new public class AwtGuiThread's and its methods runLater() and runLaterLatest().
>
>   * "samples\JavaFX\javafx_update_GUI-from-non-GUI-thread.rxj": this Rexx program will demonstrate
>     how to safely update a JavaFX Label in a GUI from a separate (non-GUI) Rexx thread using the
>     new public class FxGuiThread's and its methods runLater() and runLaterLatest().
>
> If you have any questions to ooRexx 5.0 beta, Java, BSF4ooRexx then please come forward!
>
> HTH
>
> ---rony
>
> P.S.: If you want to experiment with the ooRexx 5.0 version that has the experimental
> "ADDRESS...WITH" or "VARIABLE REFERENCE", then you may want to download and install those
> specially built versions from my DropBox from
> <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>, where you will find a
> few Rexx examples exploiting these interesting experimental features of ooRexx 5.

[Bsf4oorexx-devel] New beta version of BSF4ooRexx available (version 20180721)

[Rony G. F. <Ron...@wu...>]

Dear fellow Rexxers,

a few minutes ago I uploaded a new beta version of BSF4ooRexx (an ooRexx to Java bridge) to
Sourceforge at <https://sourceforge.net/projects/bsf4oorexx/files/beta/20180312/>.

Its name is "BSF4ooRexx_install_v600-20180721-beta.zip". Unzip it, change into the directory
"bsf4oorexx/install/windows" or "bsf4oorexx/install/linux" and run the "install" script from there.
[The installation script will copy all the files to the operating system's proper directories like
"/opt/bsf4ooRexx" on Linux or "%ProgramFile%\BSF4ooRexx" (64-bit) or "%ProgramFile(x86)%\BSF4ooRexx"
(32-bit), such that you can delete the unzipped directories and files after the installation.]

It is advised to use the latest beta of ooRexx 5.0 from
<https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/>. E.g. for Windows, look for the
latest "exe" file, download it and install it. Alternatively, download and install rather new
installation packages for ooRexx 5.0 beta from my DropBox at
<https://www.dropbox.com/sh/lsu8inlo2o99j96/AABHGsFLe9E0OVwjehRINwdZa?dl=0>.

As BSF4ooRexx is a bridge between ooRexx and Java you also need to have Java installed on your
computer. If not yet installed, then you could get a version e.g. from <http://java.com>. In this
case please make sure that the bitness (32- or 64-bit) of Java matches the ooRexx bitness (look at
the output of "rexx -v" and look for the output line led in with "Adressing mode:").

---

First steps after installation: check out the BSF4ooRexx menu on your system and the menu "GUI
Rexxtry Program" which allows you to enter Rexx code in a GUI and run it from there.

Also highly recommended: pick the menu "BSF4ooRexx -> Samples". This directory/folder and all its
subdirectories/folders contain numerous very short "nutshell" Rexx programs that demonstrate what
can be done from Rexx with the external function package "BSF4ooRexx"! Just click on the
"index.html" file which will briefly explain each Rexx script!

This version of BSF4ooRexx includes the following new nutshell examples, which are highly
recommended to be run and inspected by you! :)

  * "samples\1-080_charsetTranslations.rxj": this Rexx program will demonstrate the new public Rexx
    routine "bsf.iconv(string,fromCharset,toCharset)". It will convert the German umlauts and the
    German sharp-s into different codepages/charsets (Cp850, Cp1252, ISO8859_1, UTF_16, MacRoman,
    UTF_16BE, UTF_16LE, UTF8, ASCII).
    This routine will become more and more important for Rexx programmers as more and more text
    files get encoded in UTF (Unicode). bsf.iconv() makes it easy to convert such text files to your
    codepage/charset and then process them as usual with Rexx.

  * "samples\JavaFX\javafx_dialog_demo.rxj": JavaFX introduced nice dialogs in Java 8 which are
    explained in Java in the blog at <http://code.makery.ch/blog/javafx-dialogs-official/>, which
    not only shows the code but also pictures of the new JavaFX dialogs. This nutshell Rexx program
    uses the very same JavaFX dialogs in pure ooRexx and demonstrates how simple it is to use them
    from ooRexx! :)

  * "samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj": this Rexx program will demonstrate
    how to safely update an awt Label in a GUI from a separate (non-GUI) Rexx thread using the new
    public class AwtGuiThread's and its methods runLater() and runLaterLatest().

  * "samples\JavaFX\javafx_update_GUI-from-non-GUI-thread.rxj": this Rexx program will demonstrate
    how to safely update a JavaFX Label in a GUI from a separate (non-GUI) Rexx thread using the new
    public class FxGuiThread's and its methods runLater() and runLaterLatest().

If you have any questions to ooRexx 5.0 beta, Java, BSF4ooRexx then please come forward!

HTH

---rony

P.S.: If you want to experiment with the ooRexx 5.0 version that has the experimental
"ADDRESS...WITH" or "VARIABLE REFERENCE", then you may want to download and install those specially
built versions from my DropBox from
<https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>, where you will find a
few Rexx examples exploiting these interesting experimental features of ooRexx 5.

[Bsf4oorexx-devel] How to translate from one codepage/charset to another ...

[Rony G. F. <Ron...@wu...>]

As it may be the case that more and more text files get distributed in Unicode, it may be useful to
know how to convert e.g. UTF-16 to Windows Latin-1 (Codepage 1252) or even from any encoding to any
other (e.g. Cp850 to Cp1252 and vice-versa).

As Java supports Unicode and codepage/charset translations it is quite easy to take advantage of it
from ooRexx (via BSF4ooRexx). Just define a routine named e.g. "iconv" like:

    -- Recode Rexx string from one encoding to another
    ::routine iconv           
      use strict arg str, fromCp, toCp
       -- create Java String using Rexx string encoded in the fromCP codepage
      jstr=.java.lang.String~new(bsfRawBytes(str),fromCp)
       -- get Java byte array in desired toCp codepage and return it as Rexx string (encoded in toCp)
      return bsfRawBytes(jstr~getBytes(toCp))

The arguments "fromCp" and "toCp" may be any string that is defined in
<https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html>. As you will see all
important sets are defined there.

If you have a need to translate e.g. from "UTF-16" to "Cp1252" then invoke it with

    strNew=iconv(str, "UTF-16", "Cp1252")  -- recode the Rexx string referenced by "str"

If you are in western Europe and have a need for DOS-ASCII files encoded in Cp850 to convert to
Windows Latin-1 (Cp1252) then invoke with

    strNew=iconv(str, "Cp850", "Cp1252")  -- recode the Rexx string referenced by "str"

This should also work fast on very large strings due to employing the external BSF Rexx function
BsfRawBytes(), which either translates a Rexx string into a Java byte array or a Java byte array
into a Rexx string using native APIs.

---

The next beta version of BSF4ooRexx will supply a public routine named "bsf.iconv(str, fromCp,
toCp)" as the need to do conversions from/to Unicode has increased in the past years considerably. 

---rony

[Bsf4oorexx-devel] New member of the administration group: P.O. Jonsson

[Rony G. F. <Ron...@wu...>]

Just FYI: today I added P.O. Jonsson as an administrator to the BSF4ooRexx project, such that he becomes able to eventually change adjust the BSF4ooRexx MacOSX GUI installation related parts directly.

---rony

Re: [Bsf4oorexx-devel] ooRexx installation from BSF versus standalone installation

[Rony G. F. <Ron...@wu...>]

On 04.04.2018 17:39, P.O. Jonsson wrote:
> Re "We should stick to the standard by using one of the CPack package generators."
>
> That’s what I tried for about a week without succeeding :-(
>
> I agree that this is the ultimate goal, once you get it right I am sure it looks trivial but this
> is all new waters for me.
Maybe it is possible to define at least a
"/Library/Frameworks/ooRexx.framework/Versions/ooRexx.X.Y.Z-SVNr" with the Apple framework bundle
subdirectories

  * "Commands"
  * "Headers"
  * "Libraries"
  * "Shared"

as the BSF4ooRexx installation does (it currently uses as ooRexx version name the simple name "A"
which stems from some Apple documentation).

Then do a symbolic link of "Versions/Current" to "Versions/ooRexx.X.Y.Z-SVNr" which would make your
installed version of ooRexx the current version to use.

Note, that in "/Library/Frameworks/ooRexx.framework" the following subdirectories are actually
symbolic links to "../Versions/Current":

  * "Commands -> Versions/Current/Commands"
  * "Headers -> Versions/Current/Headers"
  * "Libraries -> Versions/Current/Libraries"
  * "Shared -> Versions/Current/Shared"

Note that in "/usr/local/bin", "/usr/local/include", "/usr/local/lib", and
"/usr/local/share/man/man1" etc. the symbolic links go to the subdirectories of
"/Library/Frameworks/ooRexx.framework", namely:

  * "-> /Library/Frameworks/ooRexx.framework/Commands/..."
  * "-> /Library/Frameworks/ooRexx.framework/Headers/..."
  * "-> /Library/Frameworks/ooRexx.framework/Libraries/..."
  * "-> /Library/Frameworks/ooRexx.framework/Shared/..."

This entire setup and system may look complicated at first, however it easies installation and
maintenance of multiple versions of a software. Switching from one version to another is then simply
the creation of a symbolic link from ".../Versions/ooRexx.X.Y.Z-SVNr" to ".../Versions/Current".

---

One more important thing: at least on Linux it is important to supply additional links to the
libraries that include the major ooRexx version numbers that the ooRexx libraries are ABI compatible
to allow programs linked to earlier versions of ooRexx to still be able to link and run with ooRexx
5. On Linux this means to have e.g. (for the rexx library):

  * /usr/lib/librexx.so -> {wherever}librexx.so.5.0.0
  * /usr/lib/librexx.so.2 -> librexx.so
  * /usr/lib/librexx.so.3 -> librexx.so
  * /usr/lib/librexx.so.4 -> librexx.so

The same might be needed for MacOSX according to
<https://docstore.mik.ua/orelly/unix3/mac/ch05_04.htm>, which for the above example might need to
have something like:

  * /usr/local/lib/librexx.dylib -> /Library/Frameworkds/ooRexx.framework/Libraries/librexx.5.0.0.dylib
  * /usr/local/lib/librexx.2.dylib -> librexx.dylib
  * /usr/local/lib/librexx.3.dylib -> librexx.dylib
  * /usr/local/lib/librexx.4.dylib -> librexx.dylib
  * /usr/local/lib/librexx.5.dylib -> librexx.dylib

or the like.

HTH

---rony

Re: [Bsf4oorexx-devel] ooRexx installation from BSF versus standalone installation

[Rony G. F. <Ron...@wu...>]

Dear P.O.:

thank you very much for your thorough analysis and findings!

Currently, I am quite pressed on time, hence just a few brief remarks:

  * maybe pure ooRexx related discussions should be carried on the ooRexx developer list as people
    might research that mailing list rather than this one,
  * the BSF4ooRexx package for MacOSX is bundled with the trunk version of ooRexx from the time of
    building,
      o the ooRexx compiling is used with CMakeList.txt from the ooRexx project
      o currently while compiling I define the environment variable MACOSX_DEPLOYMENT_TARGET=10.6
        which defines the base version of MacOSX/Darwin for which the compilation should be usable
        (should be updated)
      o currently the linking occurs with the older (but deprecated) standard c library
      o the plist files that controls starting rxapi as a daemon (and keeps restarting it in short
        intervals, whenever rxapi crashes/shuts down) is enclosed in the installation package
      o the binaries, the include files etc should be installed into /Library/Frameworks, cf. the
        entries BSF4ooRexx.framework and ooRexx.framework where the libraries and binaries get
        linked to /usr/local/lib and /usr/local/bin etc.
          + Apple documents this, cf. "framework bundles"
      o the application, i.e. the user-interface for the user giving menu access to various parts of
        ooRexx and BSF4ooRexx gets installed into /Applications/ooRexx.app
          + note: only such applications can define file and icon associations!
          + Apple documents this, cf. "application bundles"
      o the packaging is done with a free utility named "Packages" (very hard to find on the
        Internet due to its name), cf. <s.sudre.free.fr/Software/Packages/about.html>
          + Do not really know whether it takes advantage of Apple utilities and is only a frontend
            creating appropriate plist (property list) files that then are used to create the
            installation packages
      o ad sources for MacOSX installations (still had not had time to really write up a brief
        documentation, so look for text files that have ".txt" in their name they contain very brief
        documentations), they are part of the BSF4ooRexx project at sourceforge. If you check-out
        the entire BSF4ooRexx tree then look in "bsf4oorexx/gui_installers/mac/Packages" and its
        subdirectory. There are also short sh-scripts to clean and create the temporary directories
        that are then used by Packages to build the installer, just open the file
        "newCreatePackageFormAbsolutePaths-2018????.pkgproj" and click around the UI.

Sorry for being so brief, but maybe it helps already a little bit.

Will have to come up with an update to the MacOSX installation scripts that check whether ooRexx is
already installed and if so, if it is of the appropriate minimum type and remember not to uninstall
it when uninstalling BSF4ooRexx. However, we should adhere to Apple's installation guidelines and
take advantage of their clever "Versions" directory structure for Frameworks and Applications
(currently the latter is not an option for pure ooRexx, I am afraid).

HTH,

---rony



On 02.04.2018 17:06, P.O. Jonsson wrote:
> Dear Rony et al,
>
> (Before I start a short remark: I noticed that the Bsf uninstaller seems to lead behind one
> symbolic link *rexxj.sh* in /usr/local/bin, it is pointing to /Versions/A/Commands/rexxj2.sh)
>
> I have been working on making a plain ooRexx installer for the Mac. In the end I could not make a
> drop&drag installer so I wrote a line based installer that will do the work. I will send a
> separate mail about that shortly.
>
> Since I had some performance diffs between the two installs (both run any code impeccably and man
> pages works etc) I wanted to dig a bit deeper. Here is the result of the Swedish Jury:
>
> 1. Despite the fact that I compiled&installed the identical build 113882 from 24.03.2018 I found
> that file sizes differed. When I peeked into the binaries it looked as if the files have been
> compiled against different versions of the c++ libraries. Most likely our machines are a bit
> different. 
>
> Rony:
> /usr/lib/libSystem.B.dylib
> /usr/lib/libstdc++.6.dylib
>
> PO:
> /usr/lib/lib   c++.1.dylib
> /usr/lib/libc++.1.dylib
>
> Not serious I guess but may explain the performance diffs. How can we be sure to use the same
> compiler settings? I am using Sierra, are you using High Sierra?
>
> 2. File comparison Bsf-ooRexx versus /opt-ooRexx
>
> Both installations are structured the same way with a repository somewhere on the machine
>
> Bsf-ooRexx:/Library/Frameworks/BSF4ooRexx.framework/Versions/A/Commands/
> Opt-ooRexx/opt/oorexx5.0.0
> Usr-ooRexx/usr/local/ooRexx5.0.0(same as Opt-ooRexx in principle)
>
>  and create symbolic links into
>
> /usr/local/binfor binaries
> /usr/local/libfor libraries
> /usr/local/includefor header files
> /usr/local/sharefor man pages and ooRexx examples
>
> 3. These files are present in both
>
> /Versions/A/Commands:
> /opt/oorexx5.0.0/bin:
>
> rexx
> rexx.cat
> rexx.img
> rexxc
> rexxtry.rex
> rxapi
> rxapid
> rxftp.cls
> rxqueue
> rxregexp.cls
> rxsubcom
>
> 4. These files differ
>
> /Versions/A/Commands:/opt/oorexx5.0.0/bin:
>
> org.rexxla.oorexx.rxapid.plist
> rexxj2-32.sh
> rexxj2-64.sh
> rexxj2.sh
> rgf-util.rex
>
> callrexx1
> callrex2
> csvstream.cls
> json.cls
> libwpipe1.dylib
> libwpipe2.dylib
> libwpipe3.dylib
> mime.cls
> ncurses.cls
> smtp.cls
> socket.cls
> streamsocket.cls
>
>
> 5. All libraries are present in both
>
> /Versions/A/Libraries:
> /opt/oorexx5.0.0/lib:
>
> librexxapi.5.0.0.dylib
> librexxapi.dylib
> librexx.5.0.0.dylib
> librexx.dylib
> librexxutil.5.0.0.dylib
> librexxutil.dylib
> librxmath.5.0.0.dylib
> librxmath.dylib
> librxsock.5.0.0.dylib
> librxsock.dylib
> librxsock6.5.0.0.dylib
> librxsock6.dylib
> librxregexp.5.0.0.dylib
> librxregexp.dylib
> libhostemu.5.0.0.dylib
> libhostemu.dylib
> librxunixsys.5.0.0.dylib
> librxunixsys.dylib
> liborxncurses.5.0.0.dylib
> liborxncurses.dylib
>
> all are the same except
>
> in bsf-ooRexx dylib and 5.0.0.dylib are physical copies whereas
> in opt-oorRexx dylib is a symlink of dylib5.0.0
>
> many files vary in size, linked towards different libraries?
>
> 6. Header files
>
> /Versions/A/Headers:
> /opt/oorexx5.0.0/include:
>
> rexx.h
> rexxapidefs.h
> rexxapitypes.h
> rexxplatformapis.h
> rexxplatformdefs.h
> oorexxapi.h
> oorexxerrors.h
>
> all the same except *rexxapitypes.h* used by bsf-ooRexx from 2014, opt-oorexx from 2018.
> Difference is in this line:
>
> bsf-oorexx
> #if __WORDSIZE == 64 || defined(__64BIT__)
>
> opt-oorexx
> #if __WORDSIZE == 64 || defined(__64BIT__) || defined(__LP64__) || defined(_LP64)
>
> 7. Man pages
>
> /Versions/A/Shared/man/man1:
> /opt/oorexx5.0.0man/man1:
>
> rexx.1.gz
> rexxc.1.gz
> rxqueue.1.gz
> rxsubcom.1.gz
>
> identical
>
> 8. ooRexx example files
>
> /Versions/A/Shared/ooRexx:
> /opt/oorexx5.0.0ooRexx:
>
> rexxcps.rex
> ccreply.rex
> complex.rex
> greply.rex
> guess.rex
> ktguard.rex
> makestring.rex
> month.rex
> philfork.rex
> pipe.rex
> properties.rex
> qdate.rex
> qtime.rex
> scclient.rex
> scserver.rex
> semcls.rex
> sfclient.rex
> sfserver.rex
> stack.rex
> usecomp.rex
> usepipe.rex
> arithmeticEvaluation.rex
> arrayCallback.rex
> concurrency.rex
> constrained.rex
> timezone.rex
> delegation.rex
> dynamicMethod.rex
> interface.rex
> singleLinkedList.rex
> sortComposite.rex
> synchronousConcurrency.rex
> jabberwocky.txt
> treeTraversal.rex
> treeDirectory.cls
> usetree.rex
> rexx.sh
> rexx.csh
> rxapid.service
> 50-rxapid.preset
> readme
>
> all the same
>
> 10 Further ooRexx examples 
>
> /Versions/A/Shared/ooRexx/native.api:
> /opt/oorexx5.0.0/share/ooRexx/native.api:
>
> stackOverflow
> stackOverflow.cpp
> runRexxProgram
> runRexxProgram.cpp
> HelloWorld.rex
> backward.fnc
> tooRecursiveTrapped.rex
> tooRecursiveUnhandled.rex
> ReadMe.txt
> Makefile.linux
>
> all the same except runRexxProgram and stackOverflow different in size, linked towards different
> libraries?
>
> Questions to Rony et al:
> -Do you see anything that needs intervention? 
> -Do you see a way to benchmark these installations against each other?
>
> I will start to grind through some example files next week, is there a way to do this more
> structured? I was thinking of writing test cases for them, is this a good way forward? I would
> have preferred to have a release candidate before I started testing but with the latest activities
> we seem to be getting away from a recent&stable release, unfortunately.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oo...@jo... <mailto:oo...@jo...>
>
>

[Bsf4oorexx-devel] ooRexx installation from BSF versus standalone installation

[P.O. J. <oo...@jo...>]

Dear Rony et al,

(Before I start a short remark: I noticed that the Bsf uninstaller seems to lead behind one symbolic link rexxj.sh in /usr/local/bin, it is pointing to /Versions/A/Commands/rexxj2.sh)

I have been working on making a plain ooRexx installer for the Mac. In the end I could not make a drop&drag installer so I wrote a line based installer that will do the work. I will send a separate mail about that shortly.

Since I had some performance diffs between the two installs (both run any code impeccably and man pages works etc) I wanted to dig a bit deeper. Here is the result of the Swedish Jury:

1. Despite the fact that I compiled&installed the identical build 113882 from 24.03.2018 I found that file sizes differed. When I peeked into the binaries it looked as if the files have been compiled against different versions of the c++ libraries. Most likely our machines are a bit different. 

Rony:
/usr/lib/libSystem.B.dylib
/usr/lib/libstdc++.6.dylib

PO:
/usr/lib/lib   c++.1.dylib
/usr/lib/libc++.1.dylib

Not serious I guess but may explain the performance diffs. How can we be sure to use the same compiler settings? I am using Sierra, are you using High Sierra?

2. File comparison Bsf-ooRexx versus /opt-ooRexx

Both installations are structured the same way with a repository somewhere on the machine

Bsf-ooRexx:	/Library/Frameworks/BSF4ooRexx.framework/Versions/A/Commands/
Opt-ooRexx	/opt/oorexx5.0.0
Usr-ooRexx	/usr/local/ooRexx5.0.0	(same as Opt-ooRexx in principle)

 and create symbolic links into

/usr/local/bin		for binaries
/usr/local/lib		for libraries
/usr/local/include	for header files
/usr/local/share	for man pages and ooRexx examples

3. These files are present in both

/Versions/A/Commands:
/opt/oorexx5.0.0/bin:

rexx
rexx.cat
rexx.img
rexxc
rexxtry.rex
rxapi
rxapid
rxftp.cls
rxqueue
rxregexp.cls
rxsubcom

4. These files differ

/Versions/A/Commands:			/opt/oorexx5.0.0/bin:

org.rexxla.oorexx.rxapid.plist
rexxj2-32.sh
rexxj2-64.sh
rexxj2.sh
rgf-util.rex

							callrexx1
							callrex2
							csvstream.cls
							json.cls
							libwpipe1.dylib
							libwpipe2.dylib
							libwpipe3.dylib
							mime.cls
							ncurses.cls
							smtp.cls
							socket.cls
							streamsocket.cls


5. All libraries are present in both

/Versions/A/Libraries:			
/opt/oorexx5.0.0/lib:

librexxapi.5.0.0.dylib
librexxapi.dylib
librexx.5.0.0.dylib
librexx.dylib
librexxutil.5.0.0.dylib
librexxutil.dylib
librxmath.5.0.0.dylib
librxmath.dylib
librxsock.5.0.0.dylib
librxsock.dylib
librxsock6.5.0.0.dylib
librxsock6.dylib
librxregexp.5.0.0.dylib
librxregexp.dylib
libhostemu.5.0.0.dylib
libhostemu.dylib
librxunixsys.5.0.0.dylib
librxunixsys.dylib
liborxncurses.5.0.0.dylib
liborxncurses.dylib

all are the same except

in bsf-ooRexx dylib and 5.0.0.dylib are physical copies whereas
in opt-oorRexx dylib is a symlink of dylib5.0.0

many files vary in size, linked towards different libraries?

6. Header files

/Versions/A/Headers:
/opt/oorexx5.0.0/include:

rexx.h
rexxapidefs.h
rexxapitypes.h
rexxplatformapis.h
rexxplatformdefs.h
oorexxapi.h
oorexxerrors.h

all the same except rexxapitypes.h used by bsf-ooRexx from 2014, opt-oorexx from 2018. Difference is in this line:

bsf-oorexx
#if __WORDSIZE == 64 || defined(__64BIT__)

opt-oorexx
#if __WORDSIZE == 64 || defined(__64BIT__) || defined(__LP64__) || defined(_LP64)

7. Man pages

/Versions/A/Shared/man/man1:
/opt/oorexx5.0.0man/man1:

rexx.1.gz
rexxc.1.gz
rxqueue.1.gz
rxsubcom.1.gz

identical

8. ooRexx example files

/Versions/A/Shared/ooRexx:
/opt/oorexx5.0.0ooRexx:

rexxcps.rex
ccreply.rex
complex.rex
greply.rex
guess.rex
ktguard.rex
makestring.rex
month.rex
philfork.rex
pipe.rex
properties.rex
qdate.rex
qtime.rex
scclient.rex
scserver.rex
semcls.rex
sfclient.rex
sfserver.rex
stack.rex
usecomp.rex
usepipe.rex
arithmeticEvaluation.rex
arrayCallback.rex
concurrency.rex
constrained.rex
timezone.rex
delegation.rex
dynamicMethod.rex
interface.rex
singleLinkedList.rex
sortComposite.rex
synchronousConcurrency.rex
jabberwocky.txt
treeTraversal.rex
treeDirectory.cls
usetree.rex
rexx.sh
rexx.csh
rxapid.service
50-rxapid.preset
readme

all the same

10 Further ooRexx examples 

/Versions/A/Shared/ooRexx/native.api:
/opt/oorexx5.0.0/share/ooRexx/native.api:

stackOverflow
stackOverflow.cpp
runRexxProgram
runRexxProgram.cpp
HelloWorld.rex
backward.fnc
tooRecursiveTrapped.rex
tooRecursiveUnhandled.rex
ReadMe.txt
Makefile.linux

all the same except runRexxProgram and stackOverflow different in size, linked towards different libraries?

Questions to Rony et al:
-Do you see anything that needs intervention? 
-Do you see a way to benchmark these installations against each other?

I will start to grind through some example files next week, is there a way to do this more structured? I was thinking of writing test cases for them, is this a good way forward? I would have preferred to have a release candidate before I started testing but with the latest activities we seem to be getting away from a recent&stable release, unfortunately.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oo...@jo...