Yesterday evening I checked in the concluding changes for the api samples, after testing them on 32-bit Windows, 64-bit Linux and Apple. Today, testing on Win64 was successful as well. So this project is done from my perspective. Of course, if you find any omissions or errors please either fix them :) or let us know about them.
The sources (as well as the installed samples) are now consolidated under "samples/api" with the classic SAA API samples organized under "api/classic" and the new ooRexx C++ APIs under "api/c++" which also contains new samples to demonstrate how easy it is to write external routines and external methods in C++. ---rony P.S.: Sorry for the repeated posts of that single e-mail yesterday which I only sent once. No idea, why that would happen. On 28.10.2021 19:33, Rony G. Flatscher wrote: > > 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
