I'm thinking it might be better to use REXX_CURRRENT_INTERPRETER_VERSION rather than REXX_INTERPRETER_5_0_0 for these samples since they will always be associated with the current release level.
Rick On Mon, Nov 1, 2021 at 12:29 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: > 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> > <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 > > > > Anfang der weitergeleiteten Nachricht: > > *Von: *"Rony G. Flatscher" <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 > *Antwort an: *Open Object Rexx Developer Mailing List < > 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> > <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 >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
