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
