👍🙏 Von meinem iPhone gesendet
> Am 01.11.2021 um 17:34 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>: > > > 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 >>>> >>>> >>>> >>>>> 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: >>>>> >>>>> samples/Makefile.am (???) >>>>> samples/native.api/call.example/ ... for all systems, CMakeLists.txt, >>>>> Makefile.linux, Makefile.windows, Makefile.am (???) >>>>> samples/unix/api/callrexx/ ... callrexx1.cpp, callrexx2.c, >>>>> CMakeLists.txt, no Makefiles >>>>> samples/unix/api/wpipe{1..3}/... rexxasp{1..3}.c, aspitest{1..3}.rex, >>>>> CMakeLists.txt, no Makefiles >>>>> samples/windows/ ... api/ ... misc/ ... ole/ ... oodialog/ ...rexutils/ >>>>> samples/windows/api/ ... callrxnt/ ... callrxwn/ ... rexxexit/ >>>>> 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
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
