Checked in the first part of the changes, cf. <http://sourceforge.net/p/oorexx/code-0/12300>.
The Linux API samples should work, however, the readme.txt files need proof reading. Also, the callrexx.README relates to non-existing mak-files, the Makefiles for Linux/Apple are missing. Todo: the C++ samples for external routines and external methods need yet to be integrated. Todo: the Windows API samples need to be adjusted according to the Unix ones. Should you have any remarks, then please come forward. ---rony On 18.10.2021 18:32, Rony G. Flatscher wrote: > > Thank you for your feedbacks: Jon for the kind words, Rick for the thumbs up > and hint about the > licenses, and P.O. for offering help testing the changes! > > It will take a little while though as I will be travelling the coming > weekend. So if there are any > suggestions, advice please let me know. > > ---rony > > P.S.: After that is done I would proceed in attempting to create the > zip-versions after having > learned more about CMake dealing with this little "samples project". > > > On 18.10.2021 15:20, P.O. Jonsson wrote: >> Dear Rony, >> >> If you want I can try the changes out locally before you commit them, on Mac >> and Windows at >> least, maybe also on some Unixes. I think Ricks remark was aimed at me but >> it is not possible to >> try things out while working on a machine (Marks) I have no personal >> connection to. >> >> I have one item on my ToDo list that Erich wanted done: to simplify and >> merge the samples >> testcases into one or two files rather than having one tfile for each >> testcase. This is what >> Erich wrote: >> >> Hi P.O., re your recently committed additional test groups for Samples: >> >> all testGroup files should have set these three SVN properties: >> svn propset svn:eol-style native name.testGroup >> svn propset svn:executable on name.testGroup >> svn propset svn:keywords "Date Rev" name.testGroup >> >> Also testGroup files are expected to have proper headers - exactly like >> below: >> #!/usr/bin/env rexx >> /* >> SVN Revision: $Rev$ >> Change Date: $Date$ >> */ >> >> Your testGroup template defines global variables like shouldStop that aren't >> actually used anywhere. >> This includes a variable stopStop which is actually a typo. >> >> There's no need to special-case ADDRESS "" vs. ADDRESS COMMAND. >> Cross-platform ADDRESS formats >> include ADDRESS SYSTEM or ADDRESS "" >> >> The main tests run the samples with an explicit REXX external command. They >> should be run with >> execRexxPrg() instead. >> >> Your test groups typically run the tested sample twice, which shouldn't be >> necessary. Once run, >> return code and output tests can be done at the same time. There's also no >> need to test for a >> 9999 return code (this was just an internal quirk that I've removed). >> >> Also to simplify maintenance you might check out the template that I just >> committed: >> wmi.testGroup uses a single test per sample, making the tests easier to >> understand and more concise. >> >> Once you are done I will start doing this, with Ricks remark in mind. I have >> enclosed Erichs >> Template FYI. If you want to do the merger you are more than welcome. >> >> >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> Anfang der weitergeleiteten Nachricht: >>> >>> *Von: *"Rony G. Flatscher" <rony.flatsc...@wu.ac.at >>> <mailto:rony.flatsc...@wu.ac.at>> >>> *Betreff: **[Oorexx-devel] Regarding API samples, thoughts and suggested >>> changes* >>> *Datum: *18. Oktober 2021 um 13:09:28 MESZ >>> *An: *oorexx-devel@lists.sourceforge.net >>> <mailto:oorexx-devel@lists.sourceforge.net> >>> *Antwort an: *Open Object Rexx Developer Mailing List >>> <oorexx-devel@lists.sourceforge.net >>> <mailto:oorexx-devel@lists.sourceforge.net>> >>> >>> Sleeping over the current structure of the API samples these are the things >>> that are in place >>> currently: >>> >>> 1. samples/Makefile.am (???) >>> 2. samples/native.api/call.example/ ... for all systems, CMakeLists.txt, >>> Makefile.linux, >>> Makefile.windows, Makefile.am (???) >>> 3. samples/unix/api/callrexx/ ... callrexx1.cpp, callrexx2.c, >>> CMakeLists.txt, no Makefiles >>> 4. samples/unix/api/wpipe{1..3}/... rexxasp{1..3}.c, aspitest{1..3}.rex, >>> CMakeLists.txt, no >>> Makefiles >>> 5. samples/windows/ ... api/ ... misc/ ... ole/ ... oodialog/ ...rexutils/ >>> 6. samples/windows/api/ ... callrxnt/ ... callrxwn/ ... rexxexit/ >>> 7. samples/windows/api/wpipe{1..3}/ .. rexxapi{1..3}.c, apitest{1..3}.rex, >>> CMakeLists.rex, >>> nmake make files named rexxapi{1..3}.mak >>> >>> Suggested changes: >>> >>> 1. It seems that the "Makefile.am" files are left-overs and can be >>> safely deleted? >>> >>> 2. create a new structure for the installed api samples, such that the >>> installation on all >>> systems would look like: >>> >>> samples/api >>> samples/api/classic/ ... having all samples in their own directories >>> that exemplify the SAA >>> API interface, rexxapi.pdf, "Chapter 2. Classic Rexx Application >>> Programming Interfaces" >>> samples/api/c++/ ... having all samples in their own directories that >>> exemplify the ooRexx >>> native API interface, rexxapi.pdf, "Chapter 1. Rexx C++ Application >>> Programming Interfaces" >>> >>> 3. rename "wpipe{1..3}" directory names to "rexxapi{1..3]" to match the >>> names of the >>> programs therein for all systems ("wpipe" is confusing) >>> >>> 4. Unix, rename "rexxsp{1..}.c" to "rexxapi{1..3}.c" and >>> "aspitest{1..3].rex" to >>> "apitest{1..3].rex" to match the Windows names ("asp" does not make >>> any sense in this >>> context); sample change done with "wpipe1" >>> >>> 5. Add Makefiles where there are missing, such that interested >>> programmers can try compiling >>> and running the samples on their own (e.g. missing for the Unix wpipe >>> samples >>> >>> 6. Add "readme.txt" files in each api directory to briefly describe its >>> content >>> >>> In addition I propose to add the c++ samples of the 2015 RexxLA >>> presentation of how to create >>> external routines and external methods, cf. >>> <https://www.rexxla.info/events/2015/schedule.html>, >>> the talk with the code samples entitled "How to Develop a Native Library in >>> C++ for ooRexx in a >>> Nutshell". >>> >>> The easier it becomes for programmers to understand how the APIs work the >>> better. >>> >>> Any comments? >>> >>> ---rony >>>
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
