[Oorexx-devel] Status Jenkins
W 7, 8, 10 are working now and I have restored most Linux and Unix Agents. I will try to restore the rest (macOS mainly) from remote, I will be AFK until the end of August but can do some maintenance from remote. While restoring I noticed this on FreeBSD: Executing .../ooRexx/base/keyword/CALL.testGroup Build timed out (after 25 minutes). Marking the build as aborted. The building is fine but this test might need some looking at.___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Short info on Jenkins
The migration from macOS Catalina to Sonoma did not go so well after all. After a while all VMs crashed, possibly because of a disk was filling up to much. In the end I had to reinstall the machine from zero and delete the previous Jenkins user. As a result I need to get all VMs back from the backup and this might take some time, so there might be missing Linux/Unix builds today and possibly tomorrow. The Windows build is on another machine so they are not affected. Sorry about that. /P.O. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Jenkins
Hi Erich, thanks for letting me know. I will keep it running. It is very small so no problem to keep. FYI I have now upgraded my Mac where the VMs run from Catalina (macOS 10.15) to Sonoma (macOS 14.5). Also Virtualbox was upgraded to the latest version. All went well and everything works except a scanner that stopped scanning pdfs. I will move to Sequoia (macOS 15) once it is stable. Contrary to my expectations I could not make VMs of Ventura (macOS 13) or Sonoma (macOS 14) so I am building macOS on native Sonoma, we now have one macOS dmg installer for Intel (x86_64) and one for M1 Mac for the latest macOS and, ofcourse, the universal zip installer. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 8. Jul 2024, at 09:51, Erich Steinböck wrote: > >> anyone has an idea of how to get Java 17 (or higher) on to Solaris > Hi P.O., > I, too, think Solaris does not support Java 17 or later. > You might still want to keep the VM so in an emergency we could manually > build and test on Solaris 11. > _______ > 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
Re: [Oorexx-devel] Jenkins
So I could finally get all the agents to Java 17, with one exception - I could not find support for Solaris 11 which is weird since it is an Oracle product. Contrary to my original understanding of the (mandatory) migration to Java 17, the Agents must run Java 17 or higher, not lower, as I had understood it. I have no solution for bringing Solaris 11 back online again, if anyone has an idea of how to get Java 17 (or higher) on to Solaris s/he is welcome to provide a solution, otherwise I will detach Solaris from the build machine. FYI On OpenIndiana (another descendant of Sun OS) I could get Java 17, since it was already part of the installation. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 29. Jun 2024, at 18:57, René Jansen wrote: > > Hi P.O., > > Let us know when it is finished … so we can all have a look. > > Best regards, > > René. > >> On 29 Jun 2024, at 17:50, ooRexx wrote: >> >> So Jenkins Master is running Java 17 and I have upgraded the Linux/Unix >> slaves, will do the Mac and Windows in the coming days, it took a bit longer >> than expected. >> >> Building & testing should work but the Win and Mac platforms will be pending >> until I am done with all Agents. sorry but I have limited time right now. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> On 28. Jun 2024, at 18:17, ooRexx >> <mailto:oor...@jonases.se>> wrote: >>> >>> I am upgrading Jenkins to Java 17 so Jenkins may be unresponsive. I would >>> appreciate if no new commits are done in the coming hours. >>> >>> I will upgrade all the Agents as soon as I can, for now they should work >>> with Java 11. >>> >>> The upgrade to Java 17 was mandatory to keep Jenkins running in case you >>> wonder why it was done. >>> >>> Hälsningar/Regards/Grüsse, >>> P.O. Jonsson >>> oor...@jonases.se <mailto:oor...@jonases.se> >>> >>> >>> >>> _______ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto: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 > ___ > 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
Re: [Oorexx-devel] Jenkins
So Jenkins Master is running Java 17 and I have upgraded the Linux/Unix slaves, will do the Mac and Windows in the coming days, it took a bit longer than expected. Building & testing should work but the Win and Mac platforms will be pending until I am done with all Agents. sorry but I have limited time right now. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 28. Jun 2024, at 18:17, ooRexx wrote: > > I am upgrading Jenkins to Java 17 so Jenkins may be unresponsive. I would > appreciate if no new commits are done in the coming hours. > > I will upgrade all the Agents as soon as I can, for now they should work with > Java 11. > > The upgrade to Java 17 was mandatory to keep Jenkins running in case you > wonder why it was done. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > _______ > 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
[Oorexx-devel] Jenkins
I am upgrading Jenkins to Java 17 so Jenkins may be unresponsive. I would appreciate if no new commits are done in the coming hours. I will upgrade all the Agents as soon as I can, for now they should work with Java 11. The upgrade to Java 17 was mandatory to keep Jenkins running in case you wonder why it was done. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Status of RxFTP
On Friday 31 May 2024 07:47:18 Mike Cowlishaw wrote: > > On Thursday 30 May 2024 08:39:56 Mike Cowlishaw wrote: > > > Finally resolved this. The server used to accept: > > > > > > LIST -al *.* > > > > > > but the pattern *.* now causes a 'syntax error'. Removed > > > it, and all > > > is fine; no change to the RxFTP class needed, although one > > > has to pass '' > > > (empty string) to ftpdir to prevent a different pattern > > > (./*) being added. > > > > > > :-) > > > > > > Mike > > > > But that would not match only files that contain ".", > > right? I'm imagining e.g. a directory containing many > > subdirectories but only a few files with extensions, so that > > the files one is looking for become swamped by the rest. > > What is the "that" in this case? Not sure I understand your question. > > Mike > Looks to me like *.* matches any string that contains a . separator, but ./* matches anything after a /, whether or not a . is present? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.5 - x86_64 Open Object Rexx Version 5.0.0 r12583 Build date: Dec 23 2022 Addressing mode: 64 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] End of Life for Java 11 in Jenkins
Dear all, It seems support for Java 11 in Jenkins is running out. There is a guide for moving from Java 11 to Java 17, I think we need to do this eventually. My question is: should we risk this before the next release or not? If something goes wrong in the installation it is not certain that we can restore everything. Read more here: https://www.jenkins.io/doc/book/platform-information/support-policy-java/ <https://www.jenkins.io/doc/book/platform-information/support-policy-java/> Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Test groups that needs attention
I guess this is for Rony, if you did some changes to the test groups in the last days please have a look. It seems all Linux/Unix test groups produce 3 failing tests, here from Debian. Also all macOS seems affected as well. ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 30 May 2024 OS Name:LINUX SysVersion: Linux 5.10.0-28-amd64 Tests ran: 23971 Assertions: 385456 Failures: 3 Errors: 0 [failure] 20240530 17:01:53.147848 Test: TEST_TRACE_EXIT Class: TRACE.TESTGROUP File: .../ooRexx/base/keyword/TRACE.testGroup Line: 346 Failed: assertTrue Expected: 1 Actual: 0 Message: actual and expected trace output have different line counts actual trace output >I> Routine "trace_exit" in package "trace_exit". 1 *-* exit 99 >L> "99" >>> "99" L> "99" >>> "99" I> Method "A" with scope "MYTESTTO" in package "testRoutine".] does not start with [ >I> Method "B" with scope "MYTESTTO" in package "testRoutine".] File search:00:00:01.065236 Suite construction: 00:00:01.024332 Test execution: 00:06:04.732181 Total time: 00:06:06.822100 Build step 'Execute shell' marked build as failure Finished: FAILURE Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Foregoing the "runtime" portable zip archive ?
I think this is a good idea, one package is better than two (since you do not know beforehand which one to use hence confusion), please go ahead and remove one of them. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 30.05.2024 um 19:45 schrieb Rony G. Flatscher : > > A while ago, I think P.O. suggested to not produce the "runtime" versions of > the portable zip archives as having two zip archives per system may be > confusing potential users (which version to download)? > > Indeed, having a single zip-archive per system would simplify things and if > someone wanted, he or she could create the "runtime" version by simply > removing the contained "samples" and "doc" directories. > > Is there anyone who would object to not produce the "runtime" portable zip > archives anymore? > > ---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
Re: [Oorexx-devel] Status of RxFTP
On Thursday 30 May 2024 08:39:56 Mike Cowlishaw wrote: > Finally resolved this. The server used to accept: > > LIST -al *.* > > but the pattern *.* now causes a 'syntax error'. Removed it, and all is > fine; no change to the RxFTP class needed, although one has to pass '' > (empty string)to ftpdir to prevent a different pattern (./*) being added. > > :-) > > Mike > But that would not match only files that contain ".", right? I'm imagining e.g. a directory containing many subdirectories but only a few files with extensions, so that the files one is looking for become swamped by the rest. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.5 - x86_64 Open Object Rexx Version 5.0.0 r12583 Build date: Dec 23 2022 Addressing mode: 64 _______ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Shouldn't there be a caselessVerify() method?
ooRexx has numerous caseless variants of string methods, but it seems that caselessVerify() is missing? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.5 - x86_64 Open Object Rexx Version 5.0.0 r12583 Build date: Dec 23 2022 Addressing mode: 64 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Status of RxFTP
Hi Mike, This might be a dumb proposal but does refreshing the browser help? F5 on my machine. FWIW I use XAMPP <https://www.apachefriends.org/index.html> to try my www stuff locally. Open source and after installing to a place where you have access rights you can put your stuff in the htdocs folder and start the server from a control panel. After that you access the web page on localhost. Restarting the web server is then just a click on a button. The only snag is that you may need to change hardcoded paths for the test, but it is way more convenient for trying things out than uploading to a paid service. I use ssh/scp instead of ftp to shuffle files btw. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 18.05.2024 um 18:19 schrieb Mike Cowlishaw : > > [Wow, your memory of elap is impressive!!] > > But no, the command is called from MemoWiki which is started from a Chrome > browser icon which in turn talks to a goserve HTTP server which runs a Rexx > program to effect the wiki. That Rexx program is continually running -- so > that is likely the underlying cause. > > And indeed the publishpage simply does a: > >call webPublish ftpserver'/'path,, > ftpuser':'ftppassword,, > textTypes, ignoretypes, binarytypes,, > 'memowiki' args, filesdir > > rather than running it in a separate process. > > So I should restart the server, which is faster than rebooting Windows :-), > but is still a bit tedious. > > Is there a simpler way to force reload of the .cls? > > Mike > > > >> From: Rick McGuire [mailto:object.r...@gmail.com] >> Sent: 18 May 2024 17:02 >> To: Open Object Rexx Developer Mailing List >> Subject: Re: [Oorexx-devel] Status of RxFTP >> >> are you calling the program using your custom command shell? I suspect that >> might be the problem. Otherwise it should be picking up the change every >> time the program is run, assuming it runs in a new process. >> >> Rick >> >> On Sat, May 18, 2024 at 11:55 AM Mike Cowlishaw > <mailto:m...@speleotrove.com>> wrote: >>> >>>> >>>> >>>> With a bit more info from the ISP .. I think I can solve this; so for now, >>>> no need for anyone else to spend time on this! >>>> >>>> >>> Well, I was wrong, but am homing in on the problem using a modified >>> rxftp.cls (rxftpx.cls). >>> >>> A quick question: how do I 'refresh' a class .. that is, have ooRexx use a >>> modified version after I have made an experimental change? >>> >>> At present, if I edit the .cls file the next time I use the Rexx program >>> that requires it the old version continues to be used (until I reboot >>> Windows, in which case the change takes effect). >>> >>> Q: So .. how do I get ooRexx to use the modified .cls file without >>> rebooting Windows? >>> >>> Mike >>> ___ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Sandbox
> AFAIR there were no complications because of that, there was a request/demand > to create a branch for 5.0.0. > > I remember it differently :-( having to do all kinds of tweaks since the CMakeLists.txt contained items (references to documents) that were not supposed to be there and lots of missing items when the release candidate was already in /releases. I refer again to how it appear to have been made in the past, but maybe there is someone that remembers how it was done 10 years ago, I am just trying to make sense out of the logics for making a release with less stress > Maybe creating the documentation without any beta in the release version > should be created off it there and maybe the release documentation like > changes.txt and the like should be done there as well. Is that would you mean? > > This is not what I mean :-) but it is nevertheless a very good idea. Once the documentation have been finalised it would be great to change it from beta to 5.1.0, I can change that for all jobs with the script I just wrote (rather than browsing 70 jobs manually and look for changes). > ... cut ... > > But before creating the branch please consult the developer list a few days > before that step, such that work in progress for the release can be finalized > and added to trunk, if necessary. > > HTH > > You misunderstand my intention: I will certainly not be creating any branches, I leave that to you or Erich or Rick, when the time is ripe. At the time of release I need some heads up to prepare Jenkins and I will make sure we build from the right place & upload to the right place, the rest of the work is on others. I will have a look at the document Rick prepared and try to clarify my scribbles there, but later, have to go. > ---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
Re: [Oorexx-devel] Sandbox
> On 22. Apr 2024, at 16:54, Rony G. Flatscher wrote: > > On 22.04.2024 15:24, ooRexx wrote: >> is it ok to branch off and create folders in the Sandbox branch? > A "sandbox" is an area where experiments can be carried out. In the ooRexx > project there are subdirectories by the name of the developers, committers, > such that one can use one own's temporary subdirectories there to carry out > the experiments. > > > >> Can they be deleted after a test? I wanted to make a 2nd short test for the >> next release. >> >> Also, in this context a question: When I look at what was done for 4.2 it >> appears that first two workfolders were created: >> >> .../docs/branches/4.2/trunk/ >> .../main/branches/4.2/trunk/ > AFAICT these are meant to initially match the release versions. In the case > that minor changes are applied to a released version and a minor release is > intended, then the changes should go to branches. Once a release gets created > from branches the new release would carry the version 4.2.1 in your example. > Indeed. As I understand the release process in the past /branches/4,2/trunk is where working copy for 4.2.0 resided. Once that was copied to /releases/4.2.0/trunk it was changed to be the working copy for 4.2.1 and so on. This is not how it was done for 5.0.0, leading to all kinds of complications. Compare to / branches/4.1 that served as the working copy for the release of 4.1.0 4.1.1 4.1.2 4.1.3 What I am asking is if we should not do it this way for 5.1.0, i.e. create a /branches/5.1/trunk with the release candidate (when there is a release candidate...) and do the necessary documentation updates there and THEN move it to releases? >> and then, only at the end, the results were moved to >> >> .../docs/releases/4.2.0/trunk/ >> .../main/releases/4.2.0/trunk/ >> >> Does it make sense to do the same for 5.1->5.1.0? > The release version number should always consist of three digits even if the > third digits remains to be 0. The reason being that ooRexx supplies all three > digits and the name should reflect the full version digits. >> Will it have an impact on the revision? I understand that the release should >> show no revision, something controlled from CMakeLists.txt (according to >> where the build is taking place I think)?# > If you do a "svn cp" to create a branch or a release this does not change the > svn revision number. Deleting a branch with "svn rm" would not change the svn > revision number either AFAIK. The svn revision number only changes if > committing changes/additions to/deletions of files. > > HTH, > > ---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
Re: [Oorexx-devel] Sandbox
> On 22. Apr 2024, at 16:54, Rony G. Flatscher wrote: > > On 22.04.2024 15:24, ooRexx wrote: >> is it ok to branch off and create folders in the Sandbox branch? > A "sandbox" is an area where experiments can be carried out. In the ooRexx > project there are subdirectories by the name of the developers, committers, > such that one can use one own's temporary subdirectories there to carry out > the experiments. > > Ok so I can set up something in /sandbox/PO for testing the Jenkins build modification automation (switching from 5.1.0beta to 5.1.0 for ALL tasks in one go) > >> Can they be deleted after a test? I wanted to make a 2nd short test for the >> next release. There is quite a lot to add so I would prefer to delete it afterwords, using SVN rm, is that possible? >> >> Also, in this context a question: When I look at what was done for 4.2 it >> appears that first two workfolders were created: >> >> .../docs/branches/4.2/trunk/ >> .../main/branches/4.2/trunk/ > AFAICT these are meant to initially match the release versions. In the case > that minor changes are applied to a released version and a minor release is > intended, then the changes should go to branches. Once a release gets created > from branches the new release would carry the version 4.2.1 in your example. > If you look at the folders it seems .../main/branches/4.2 was used as the working area before 4.2.0 was put in /releases. It could then also serve as working area for 4.2.1 and so on. I want to avoid we had earlier where we discovered errors in CMakeList.txt when 5.0.0 was already in /releases. >> and then, only at the end, the results were moved to >> >> .../docs/releases/4.2.0/trunk/ >> .../main/releases/4.2.0/trunk/ >> >> Does it make sense to do the same for 5.1->5.1.0? > The release version number should always consist of three digits even if the > third digits remains to be 0. The reason being that ooRexx supplies all three > digits and the name should reflect the full version digits. Se my remark above, I am talking about the situation where we have a release candidate that we need to do documentation work on BEFORE it goes into the /releases branch. >> Will it have an impact on the revision? I understand that the release should >> show no revision, something controlled from CMakeLists.txt (according to >> where the build is taking place I think)?# > If you do a "svn cp" to create a branch or a release this does not change the > svn revision number. Deleting a branch with "svn rm" would not change the svn > revision number either AFAIK. The svn revision number only changes if > committing changes/additions to/deletions of files. > > HTH, > > ---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
[Oorexx-devel] Sandbox
is it ok to branch off and create folders in the Sandbox branch? Can they be deleted after a test? I wanted to make a 2nd short test for the next release. Also, in this context a question: When I look at what was done for 4.2 it appears that first two workfolders were created: .../docs/branches/4.2/trunk/ .../main/branches/4.2/trunk/ and then, only at the end, the results were moved to .../docs/releases/4.2.0/trunk/ .../main/releases/4.2.0/trunk/ Does it make sense to do the same for 5.1->5.1.0? Will it have an impact on the revision? I understand that the release should show no revision, something controlled from CMakeLists.txt (according to where the build is taking place I think)? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Preparing for the next release
> On 20. Apr 2024, at 13:34, Rony G. Flatscher wrote: > > Hi P.O., > > thank you for your information and efforts! > > How about targeting an initiative to create a new release (5.1.0) at the > beginning of June then? > > I am fine with that Rony, if there is a decision to go ahead at that time, I will iron out the last bits& pieces then. To make a meaningful test I would need to work on a 5.1.0 release candidate, but that can wait until we are closer to a release. I will remove the staged directories today, I noticed that there had been some commits just now before I had the opportunity to revert back to 5.1.0Beta, Jenkins did not respond since it monitored 5.0.0 release brach. When switching back to 5.1.0Beta again it picked up the commits and is now building as expected. On some platforms there will be a conflict since we use -upgrade install (to really test the installer) but I will relaunch those items manually once everything has calmed down. This was a good test I think. As you can see from this snipped the 5.1.0 artifact was created but failed the upgrade because of a 5.0.0 being installed. CPack: Create package CPackRPM: Will use GENERATED spec file: /home/osboxes/workspace/ooRexx-CentOS9-build/oorexxBuild/_CPack_Packages/Linux/RPM/SPECS/oorexx.spec CPack: - package: /home/osboxes/workspace/ooRexx-CentOS9-build/oorexxBuild/oorexx-5.1.0-12831.centos9.x86_64.rpm generated. + pkill rxapi + sudo rpm --upgrade oorexx-5.1.0-12831.centos9.x86_64.rpm file /usr/local/bin/csvStream.cls from install of oorexx-5.1.0-12831.x86_64 conflicts with file from package ooRexx-5.0.0-12830.x86_64 file /usr/local/bin/json.cls from install of oorexx-5.1.0-12831.x86_64 conflicts with file from package ooRexx-5.0.0-12830.x86_64 file /usr/local/bin/rexx from install of oorexx-5.1.0-12831.x86_64 conflicts with file from package ooRexx-5.0.0-12830.x86_64 > Cheers > ---rony > > > > On 19.04.2024 19:01, ooRexx wrote: >> A progress report on my activites today. >> >> The test was partially successful, if you look at Sourceforge you will find >> two folders 5.0.0test under /files/oorexx and /files/oorexx-doc. They are >> staged so only visible if you are logged on to sourceforge. >> >> For the understanding of how Jenkins works: Each job is defined in an xml >> file and each setting in the GUI correspond to a line in the xml. >> >> The test showed that it is possible to parse and modify all those xml files >> and thereby modify all build jobs in one go, replacing "needles" with >> "newneedles", i.e. switching from 5.1.0beta to 5.0.0test or whatever. >> >> I have also modified the uploading script so that it can be redirected by an >> input parameter. This worked with the sideeffect that all the 5.1.0 files >> were uploaded as well. They can be removed manually or deleted in the work >> folder so not a big problem >> >> The zip uploader did not work as expected, not yet sure why. >> >> The documentation build should also accept input parameters to redirect the >> builds, unfortunately this did not work as expected, I will look into that >> later. >> >> Finally, since I reproduced the 5.0.0 I got all the mistakes coming back >> (referring to a missing document; wrong case for the built entities etc) >> >> Have a look on sourceforge and on Jenkins, I will restore everything >> tomorrow 20.4. to 5.1.0beta again. >> >> In my view this will be a doable way to save manual work during the next >> release, unfortunately I will be away from home for the most of April and >> May and can only help at the beginning of june. >> >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> > > _______ > 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
Re: [Oorexx-devel] Preparing for the next release
A progress report on my activites today. The test was partially successful, if you look at Sourceforge you will find two folders 5.0.0test under /files/oorexx and /files/oorexx-doc. They are staged so only visible if you are logged on to sourceforge. For the understanding of how Jenkins works: Each job is defined in an xml file and each setting in the GUI correspond to a line in the xml. The test showed that it is possible to parse and modify all those xml files and thereby modify all build jobs in one go, replacing "needles" with "newneedles", i.e. switching from 5.1.0beta to 5.0.0test or whatever. I have also modified the uploading script so that it can be redirected by an input parameter. This worked with the sideeffect that all the 5.1.0 files were uploaded as well. They can be removed manually or deleted in the work folder so not a big problem The zip uploader did not work as expected, not yet sure why. The documentation build should also accept input parameters to redirect the builds, unfortunately this did not work as expected, I will look into that later. Finally, since I reproduced the 5.0.0 I got all the mistakes coming back (referring to a missing document; wrong case for the built entities etc) Have a look on sourceforge and on Jenkins, I will restore everything tomorrow 20.4. to 5.1.0beta again. In my view this will be a doable way to save manual work during the next release, unfortunately I will be away from home for the most of April and May and can only help at the beginning of june. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 18. Apr 2024, at 23:32, ooRexx wrote: > > Dear all, > > In preparation for the next release I am doing a "dry-run" on some tasks > tomorrow, I would appreciate if no commits (neither for builds nor for > documentation) were made tomorrow, 19/4. > > The test does not involve any commits, hence "dry" > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > ___ > 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
[Oorexx-devel] Preparing for the next release
Dear all, In preparation for the next release I am doing a "dry-run" on some tasks tomorrow, I would appreciate if no commits (neither for builds nor for documentation) were made tomorrow, 19/4. The test does not involve any commits, hence "dry" Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Segmentation faults in environmentEntries.testGroup
Hi Rony, I was imprecise: all Linux/Unix/macOS platforms have a segmentation fault in that group, the test itself is not failing, but the cause of the segfault must be found and my guess is that it is in one of your commits? As for the tests on Windows I assume it is the counterpart of a segfault on Windows. Regarding the notion of “failing” tests on Windows running in Virtual Machines this is the result of the testing framework not finishing (a dangling process) leading to a timeout. All tests normally finish with success you just cannot see it in the Jenkins main screen. This is a candidate for multiple process debugging ;-) If you look at the 32 and 64 bit Windows running on Native Windows they do not show these problems. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 3. Apr 2024, at 16:45, Rony G. Flatscher wrote: > > On 03.04.2024 16:25, ooRexx wrote: >> It seems we currently have ALL platforms failing this test, can the person >> (Rony?) who committed lately check if there was a side-effect of the changes >> and/or amend the test to the new behaviour. >> >> Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup >> /tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault >> (core dumped) rexx testOORexx.rex -s -U >> Build step 'Execute shell' marked build as failure >> Finished: FAILURE >> > Looking at Jenkins I do not see that test failing on all systems at all: > > > > However, I can see those segmentation faults in some of those tests. > > No idea what causes them. > > As TRACE.testGroup and TRACE_TraceObject.testGroup pass in those > failing/segmenting test runs I am not sure what the cause would be (in which > test the segmentation fault gets triggered). > > It is also interesting that the 32-bit Windows 11 test run works, but the > 64-bit Windows 11 test run has an exception. On Windows 10 it seems that > both, the 32- and the 64-bit version have a segmentation fault. But then, the > last successful run of the test suite is reported to have been more than 11 > months ago on Windows 10 64-bit? > > > > ---rony > > P.S.: Will look into this specific testGroup later on my Windows machine with > a debug version of 64-bit ooRexx. > > > > _______ > 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
[Oorexx-devel] Segmentation faults in environmentEntries.testGroup
It seems we currently have ALL platforms failing this test, can the person (Rony?) who committed lately check if there was a side-effect of the changes and/or amend the test to the new behaviour. Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup /tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault (core dumped) rexx testOORexx.rex -s -U Build step 'Execute shell' marked build as failure Finished: FAILURE Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Planned additions, release of ooRexx 5.1 ?
Not entirely related, but if you guys want to automate some builds, consider using Open Build Service (just call the API, even from Jenkins). Here's an example: https://api.opensuse.org/apidocs/#/Sources%20-%20Packages/post_source__project_name___package_name__cmd_runservice In this case it's triggering a service to download and compile ooRexx 5.0 from the trunk on 5 different Linux distros, and publish them to a public repository. It supports almost Linux 30 distros and different architectures, and it's free. Here's my package: https://build.opensuse.org/package/show/home:emendonca:oorexx/oorexx5 Perhaps someone could create an account for the ooRexx project. Just branch my package to it and should be set. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Universal package and rexx.img
As I just found out the hard way it appears that it is possible to build for BOTH architectures on X86 or ARM but only if you build for a “fat binary”, thus I can only build an X86 binary in the VM running on Intel hardware. Enrico explained why in [bugs:#1931]. <https://sourceforge.net/p/oorexx/bugs/1931/> I have modified the uploading job to upload the X86-only installer for Intel HW. We have the option to change the build job on the M1 Mac kindly made available be Mark to upload either an installer with a “fat” binary or an ARM-only binary, what do we want? More inline below > On 16. Jan 2024, at 11:24, Rony G. Flatscher wrote: > > Dear P.O., > > On 15.01.2024 20:51, oorexx wrote: >> I wanted to split the macOS installer and have prepared 2 new jobs. I have >> disabled ooRexx-macOS12-build and created ooRexx-macOS12-X86_64-build and >> ooRexx-macOS12-ARM64-build. > > ... cut ... > > (looks o.k. to me :) ) Actually it was not :-( > > ... cut ... > >> Finally we have to look if there is also a need to change the „Universal“ >> installer. I think Rony must look at this. > > Not sure what problem you see or what I should look after? > (Assuming that the packages will be created by accordingly.) Two further problems were the uploading jobs that needed amendments, also for the universal/portable installer hence my question. Should be ok now. > > Cheers > > ---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
Re: [Oorexx-devel] Universal package and rexx.img
I wanted to split the macOS installer and have prepared 2 new jobs. I have disabled ooRexx-macOS12-build and created ooRexx-macOS12-X86_64-build and ooRexx-macOS12-ARM64-build. I have then replaced in those jobs -DBUILD_OSX_UNIVERSAL_BINARIES=1 With (respectively) -DBUILD_X86_64_BINARIES=1 -DBUILD_ARM64_BINARIES=1 But this is not sufficient, CMakeLists.txt will need to be changed. My proposal is: Lines 61-63: if( APPLE AND BUILD_OSX_UNIVERSAL_BINARIES ) set( CMAKE_OSX_ARCHITECTURES arm64 x86_64 ) endif() be changed to if( APPLE AND BUILD_OSX_UNIVERSAL_BINARIES ) set( CMAKE_OSX_ARCHITECTURES arm64 x86_64 ) endif() if( APPLE AND BUILD_X86_64_BINARIES ) set( CMAKE_OSX_ARCHITECTURES x86_64 ) endif() if( APPLE AND BUILD_ARM64_BINARIES ) set( CMAKE_OSX_ARCHITECTURES arm64 ) endif() I assume we should keep the possibility to build fat binaries, hence 3 different checks. Any objections or improvements? Also I think the lines 53-57 in CMakeLists.txt need to be changed: # must come before the project command # 10.13.6 High Sierra is the minimum system supported if( APPLE AND BUILD_OSX_UNIVERSAL_BINARIES ) set( CMAKE_OSX_DEPLOYMENT_TARGET 10.13.6 CACHE STRING "" FORCE) endif() Would this work? # must come before the project command # 10.13.6 High Sierra is the minimum system supported if( APPLE ) set( CMAKE_OSX_DEPLOYMENT_TARGET 10.13.6 CACHE STRING "" FORCE) endif() The ooRexx test for macOS would then be attached to the X86_64 build job since we run the VMs on Intel hardware. Finally we have to look if there is also a need to change the „Universal“ installer. I think Rony must look at this. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 13.01.2024 um 20:52 schrieb Gilbert Barmwater : > > Feel free to ignore this as I am NOT a MacOS user. I feel that having 2 > packages is the more straightforward way to proceed rather than continuing > with the complexity of a universal package even though that may be "common" > on the MacOS platform. My 2 cents, FWIW. > > Gil > > On 1/13/2024 2:12 PM, oorexx wrote: >> The bitness (64 bit) and the endianness (little-endian) is the same, the >> architecture is the only difference. But I have no objection to split the >> macOS installer, all that is needed is to create two new jobs on Jenkins >> with the different settings. >> >> Any objections? >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >> >>> Am 13.01.2024 um 19:56 schrieb Rony G. Flatscher >> <mailto:rony.flatsc...@wu.ac.at>>: >>> >>> As rexx.img must be of the same architecture, bitness and endianness it is >>> not possible to use a single rexx.img for different architectures, >>> bitnesses and endiannesses. >>> >>> The present packaging and installation of ooRexx can therefore not take >>> advantage of universal packages available on macOS (because of rexx.img) >>> such that we should start to stop producing the universal macOS version and >>> instead have two different macOS packages created, one for amd64 and one >>> for arm64. >>> >>> --- >>> >>> As rexx.img gets installed into and loaded from the lib directory as if it >>> was a native library, would it make sense to think of a >>> universal packaging format for rexx.img which would allow to create a form >>> of universal rexx.img? E.g. a table that indicates the available >>> architectures and positions in a rexx.img file such that ooRexx can pick >>> the appropriate version? >>> >>> If so, then it would be probably be helpful to allow for universal user >>> compiled Rexx programs as well, as the same infrastructure could then be >>> put in place, if not mistaken. >>> >>> What do you think would such an endeavor be worthwhile at all? >>> >>> ---rony >>> >>> >>> >>> >>> ___ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >> >> >> >> _______ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > -- > Gil Barmwater > ___ > 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
Re: [Oorexx-devel] Universal package and rexx.img
The bitness (64 bit) and the endianness (little-endian) is the same, the architecture is the only difference. But I have no objection to split the macOS installer, all that is needed is to create two new jobs on Jenkins with the different settings. Any objections? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 13.01.2024 um 19:56 schrieb Rony G. Flatscher : > > As rexx.img must be of the same architecture, bitness and endianness it is > not possible to use a single rexx.img for different architectures, bitnesses > and endiannesses. > > The present packaging and installation of ooRexx can therefore not take > advantage of universal packages available on macOS (because of rexx.img) such > that we should start to stop producing the universal macOS version and > instead have two different macOS packages created, one for amd64 and one for > arm64. > > --- > > As rexx.img gets installed into and loaded from the lib directory as if it > was a native library, would it make sense to think of a universal packaging > format for rexx.img which would allow to create a form of universal rexx.img? > E.g. a table that indicates the available architectures and positions in a > rexx.img file such that ooRexx can pick the appropriate version? > > If so, then it would be probably be helpful to allow for universal user > compiled Rexx programs as well, as the same infrastructure could then be put > in place, if not mistaken. > > What do you think would such an endeavor be worthwhile at all? > > ---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
Re: [Oorexx-devel] SVN browser on sourceforge - broken?
Dear Jon, It might have been me; I was just uploading something using FTP and that might have blocked you, please try again, it worked for me just now. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 06.01.2024 um 22:07 schrieb Sahananda Sahananda : > > Hi All, > > when I try to browse the SVN through the sourceforge SVN web interface > <https://sourceforge.net/p/oorexx/code-0/> I see this message: > > Browsing this repo on the web is unavailable currently. To fix, please try a > Repository Refresh <https://sourceforge.net/p/oorexx/code-0/refresh>. > Committing and pulling code should still work. > > I can confirm that I can still update my working copy. > I don't know if this message pertains only to my sourceforge login or is > general. I tried clicking on the repository refresh link, but it didn't seem > to fix things. > > I'm not sure how or whether to proceed. > > Jon > _______ > 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
[Oorexx-devel] Documentation build process amended
Forst of all I want to wish everybody a (late) happy new year and a good continuation of 2024! With the kind help of Gil the documentation build service on Jenkins have been amended to reflect the correct date & revision information for any book amended. If you want to know how it looks have a look at oorexxbuild.pdf, where I have started to document the current build system. I did not trigger a rebuild on any of the other books, so the change will only be reflected whenever a change is made to a specific book. Or should I trigger a rebuild of the complete documentation today, 1.1.2024? It's a nice date to remember :-) Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] OORexx 5.0 builds
Answering to myself: ooRexx 4.x had this issue where it embedded the build
time into the main binary, basically violating the "reproducible builds"
compliance. But ooRexx 5.x doesn't have that problem.
However, I had noted this at the time I built the first ooRexx 5.x SPEC
(inside rpmlintrc):
# unfortunately historically ooRexx loads class libraries from .cls files
in the PATH
# a patch was sent to upstream back in 4.x to load these from
/usr/share/ooRexx, but it appears it was ignored for 5.x
addFilter("W: non-executable-in-bin")
Is this still true for the current code?
On Sat, Dec 23, 2023 at 6:36 PM Erico Mendonca
wrote:
>
>
> Em sáb., 23 de dez. de 2023 10:27, Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> escreveu:
>
>> Great!
>>
>> Clicking on the "RPM Lint" tab for 15.5 gives the following hint/advice:
>>
>> liboorexx4.ppc64le: I: binary-or-shlib-calls-gethostbyname
>> /usr/lib64/librxsock.so.4
>> The binary calls gethostbyname(). Please port the code to use
>> getaddrinfo().
>>
>> So maybe we should change that accordingly?
>>
>>
> Yes, that would be nice to look into. I *think* there was another
> (historical) issue where it embedded the current date/time in the main
> binary, which I suppressed with rpmlintrc. That affects reproducible
> builds, as the binary will always be different over different builds of the
> same code. I don't know if it's still true for 5.0, but for 4.x surely this
> was the case. I'll comment out the rpmlintrc later to see what else was
> masked.
>
>>
>> Merry Christmas and a Happy New Year!
>>
>
> Merry Christmas everyone!
>
>
--
*data:image/png;base64,iVBORw0KGgoNSUhEUgAAAQ8eCAYy0pu0AAAF+ElEQVR4Ae3bXWwURRwA8EUEpUcJAnoxIhJDgNa77vxnrjRVHohB/IhRXgoK8StqURMMGNLuzOxdD0j0wUQFH4wPhgf8SBohKuGjtzOzd22BUvEjRowkTdCEmEjgwSBoirJmthw5EtNGw0e5+zfZ7O3s5u7+v3b/nZn/rOPgDwqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAApcZoHGI/nJjWF+6oL+jvol4bM3j/n2Uf4GJ3ImjHkdXoACKFBdAk09G27LlPxHQPGcW+Cf0FAaCMUgVfJLCP1eUOIzV/OtUPRfzhh+HwnXTa8UoEo0kVJ2JzViRWv3+imV5/A1CqBAFQqwUC4mWrwDWhwFLSJ2oCtiB/IR6++KaF8u3lh/bqT9YD5ifbmIKDEMmn8HSm4hRfEAO9w+qUkLGl9f9CPQfn+m5K9hfV1zqpAMQ0KB2hZIlfwGouU2osUZdjAf0VI2AsUjUvBG3wIe2SRDe7NxkiGKnwMjdxMjOCl4Z4k915eLMoc2RVCUR0kg8iklkrWtjdGjQJUI0FCupEb8xPZ3RWDk6MlijGQS91b6cxEJ+HnS0/m3TT62jRT4IdD8KRrw55jiuXl71k6rEj4MAwVqU8BV/DUI5Z/lngaEMoo3e8MHY/Q6RkskF3otEPDIDbwzrUEWrPAixWe6ylvp7utcUZviGDUKVIEAGP4qtcmi5MfDDhLwiGh+ErQ44Ra8c3a4YRPJmEOXUZJI3OtQ/HfQ8i5LxnqzL0DIn2ehfM9xIqzGVMHfEYZQYwI06Gggip+ycxVE8chWT0CJJ1jQmWY9fKGrvWXEiLeI4r/aXsn/SiAXeh1gxCnQYgc1WcYCudgNpaKhPMzeb59UY+wYLgpc/wKg+Ru2akIUP28nMRu785NtVMmeDQkSenPLx8xkW8DIr+IkM0oP41+Ti+3JKH6KaP42aO8L2uvvhWJWQzF73DX+3vJnXP+aGAEK1IiAvWmJFv1sfz4CwwOnu22iDR20fAlC+T2U5DGq5ddu6K+x7XEvxfCh/zKEoUU/Lu/GpVwtTpJAfM6K/sck5B/SgL/ZrOW9NcKNYaJA9Qg0dr8ylSjvR5s8qJbrbGRU8UeJlsNuD99KjHzc9kzAiD/sfuS8/xDRYjieF7EVFCMjW50pb/H8SFxV8UZKvAEfAsM1aHGEKP4LGPEzFP0Qiv7rUJCZ6tHESFCghgRmd6+fAop/Ey8AC/gGGzrVfB0x4sw9+9bPKFOA4luI5sOuys+3bUSLnbTk2/kRW4odiudJArmbKL6LaDEAiv9lJ2DtWg9X+8vsnIZd08GCzjlNezpm26Xt5ffGPQqgwPUoEDkTXCU+ZQMbIwj4bhtCk+lYAFocAyOeLocEBe9J27Ogyltp20B5S+3Qxa42Bc0/Kl/X1t02sWUgP82u4wAjfovLvoG/tnwe9yiAApdZoJ6xWXWs4farsSVSqaTTNjK3YcNwA7EingQ1Ypgo/oxts+XU+VreUQ6TFLztNnkQxZfbtiVh/kaixXbWFy8mO01L2Q+aQ39p+Xq7J4qLeC7Frh0pZrc1GX9B5fmLrxmrq2fzZznOhYfn8Bg98O9h1PvBSSYTF++fepreW0fTQ3WQurIbTQ/V09TgjObUneUPt0MK0J07MoObbHI4C5r7zcq7m4T56a2lLEDA342HKNo7UZlQ7NADSv5jxIhVtCTbqREPVj49O1Kt8ZeTUK4mOveiLfuWP7Nyn6Dp1QmS2uU8PO8m217zxyy96hIPPL42Hkvmxk+MJ8r+4+kYGi6OCpz6RQtnJlpSyauxTQW4tbLnYW/Y1IBIguFhZnBzFCeRgnea9HQeJwE/mzm8ObKlXNBXaPhhexqLFs68pOeBx+PXo7V1yiW/Lzy+6h4OY3WV/4Cv+et0n3eLa+RGosUP9nkU2jvyXAqE8ltqZPs1/4L4BVAABca3QMue/DRmH6Mv+ffbx+ltOXd8f2P8diiAAiiAAiiAAiiAAiiAAiiAAiiAAiiAAiiAAtUk8A/5wXY+a4HbHwBJRU5ErkJggg==
*
*Erico Mendonca*
Premium Services
SUSE
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] OORexx 5.0 builds
Em sáb., 23 de dez. de 2023 10:27, Rony G. Flatscher < rony.flatsc...@wu.ac.at> escreveu: > Great! > > Clicking on the "RPM Lint" tab for 15.5 gives the following hint/advice: > > liboorexx4.ppc64le: I: binary-or-shlib-calls-gethostbyname > /usr/lib64/librxsock.so.4 > The binary calls gethostbyname(). Please port the code to use > getaddrinfo(). > > So maybe we should change that accordingly? > > Yes, that would be nice to look into. I *think* there was another (historical) issue where it embedded the current date/time in the main binary, which I suppressed with rpmlintrc. That affects reproducible builds, as the binary will always be different over different builds of the same code. I don't know if it's still true for 5.0, but for 4.x surely this was the case. I'll comment out the rpmlintrc later to see what else was masked. > > Merry Christmas and a Happy New Year! > Merry Christmas everyone! ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] OORexx 5.0 builds
In case anyone is interested, I reactivated and updated some automated Linux builds for OORexx 5.0 on OpenSUSE Build Service: https://build.opensuse.org/package/show/home:emendonca:oorexx/oorexx5 I added openSUSE 15.5/SLES 15.5, openSUSE Tumbleweed, CentOS 8 and Fedora 39. If anyone needs another supported distro, just let me know. Supported distro list is available here: https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets -- *data:image/png;base64,iVBORw0KGgoNSUhEUgAAAQ8eCAYy0pu0AAAF+ElEQVR4Ae3bXWwURRwA8EUEpUcJAnoxIhJDgNa77vxnrjRVHohB/IhRXgoK8StqURMMGNLuzOxdD0j0wUQFH4wPhgf8SBohKuGjtzOzd22BUvEjRowkTdCEmEjgwSBoirJmthw5EtNGw0e5+zfZ7O3s5u7+v3b/nZn/rOPgDwqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAAqgAApcZoHGI/nJjWF+6oL+jvol4bM3j/n2Uf4GJ3ImjHkdXoACKFBdAk09G27LlPxHQPGcW+Cf0FAaCMUgVfJLCP1eUOIzV/OtUPRfzhh+HwnXTa8UoEo0kVJ2JzViRWv3+imV5/A1CqBAFQqwUC4mWrwDWhwFLSJ2oCtiB/IR6++KaF8u3lh/bqT9YD5ifbmIKDEMmn8HSm4hRfEAO9w+qUkLGl9f9CPQfn+m5K9hfV1zqpAMQ0KB2hZIlfwGouU2osUZdjAf0VI2AsUjUvBG3wIe2SRDe7NxkiGKnwMjdxMjOCl4Z4k915eLMoc2RVCUR0kg8iklkrWtjdGjQJUI0FCupEb8xPZ3RWDk6MlijGQS91b6cxEJ+HnS0/m3TT62jRT4IdD8KRrw55jiuXl71k6rEj4MAwVqU8BV/DUI5Z/lngaEMoo3e8MHY/Q6RkskF3otEPDIDbwzrUEWrPAixWe6ylvp7utcUZviGDUKVIEAGP4qtcmi5MfDDhLwiGh+ErQ44Ra8c3a4YRPJmEOXUZJI3OtQ/HfQ8i5LxnqzL0DIn2ehfM9xIqzGVMHfEYZQYwI06Gggip+ycxVE8chWT0CJJ1jQmWY9fKGrvWXEiLeI4r/aXsn/SiAXeh1gxCnQYgc1WcYCudgNpaKhPMzeb59UY+wYLgpc/wKg+Ru2akIUP28nMRu785NtVMmeDQkSenPLx8xkW8DIr+IkM0oP41+Ti+3JKH6KaP42aO8L2uvvhWJWQzF73DX+3vJnXP+aGAEK1IiAvWmJFv1sfz4CwwOnu22iDR20fAlC+T2U5DGq5ddu6K+x7XEvxfCh/zKEoUU/Lu/GpVwtTpJAfM6K/sck5B/SgL/ZrOW9NcKNYaJA9Qg0dr8ylSjvR5s8qJbrbGRU8UeJlsNuD99KjHzc9kzAiD/sfuS8/xDRYjieF7EVFCMjW50pb/H8SFxV8UZKvAEfAsM1aHGEKP4LGPEzFP0Qiv7rUJCZ6tHESFCghgRmd6+fAop/Ey8AC/gGGzrVfB0x4sw9+9bPKFOA4luI5sOuys+3bUSLnbTk2/kRW4odiudJArmbKL6LaDEAiv9lJ2DtWg9X+8vsnIZd08GCzjlNezpm26Xt5ffGPQqgwPUoEDkTXCU+ZQMbIwj4bhtCk+lYAFocAyOeLocEBe9J27Ogyltp20B5S+3Qxa42Bc0/Kl/X1t02sWUgP82u4wAjfovLvoG/tnwe9yiAApdZoJ6xWXWs4farsSVSqaTTNjK3YcNwA7EingQ1Ypgo/oxts+XU+VreUQ6TFLztNnkQxZfbtiVh/kaixXbWFy8mO01L2Q+aQ39p+Xq7J4qLeC7Frh0pZrc1GX9B5fmLrxmrq2fzZznOhYfn8Bg98O9h1PvBSSYTF++fepreW0fTQ3WQurIbTQ/V09TgjObUneUPt0MK0J07MoObbHI4C5r7zcq7m4T56a2lLEDA342HKNo7UZlQ7NADSv5jxIhVtCTbqREPVj49O1Kt8ZeTUK4mOveiLfuWP7Nyn6Dp1QmS2uU8PO8m217zxyy96hIPPL42Hkvmxk+MJ8r+4+kYGi6OCpz6RQtnJlpSyauxTQW4tbLnYW/Y1IBIguFhZnBzFCeRgnea9HQeJwE/mzm8ObKlXNBXaPhhexqLFs68pOeBx+PXo7V1yiW/Lzy+6h4OY3WV/4Cv+et0n3eLa+RGosUP9nkU2jvyXAqE8ltqZPs1/4L4BVAABca3QMue/DRmH6Mv+ffbx+ltOXd8f2P8diiAAiiAAiiAAiiAAiiAAiiAAiiAAiiAAiiAAtUk8A/5wXY+a4HbHwBJRU5ErkJggg== * *Erico Mendonca* Premium Services SUSE ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Cmake deprecation warning
We are getting loads of this warning when building ooRexx at the moment:
CMake Deprecation Warning at CMakeLists.txt:48 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
It emanates from this piece in CMakeLists.txt:
message(STATUS "CMake version is ${CMAKE_VERSION}")
if (APPLE)
# apple builds with prior cmake version have an @rpath problem
cmake_minimum_required (VERSION 3.12)
else ()
# for other platforms
cmake_minimum_required (VERSION 2.8.12)
endif ()
# CMP0091 introduced in 3.15 must stay OLD for our /MD -> /MT hack to work
cmake_policy(VERSION 2.8...3.3)
I do not know who made the remark but it seems it would be safe to bump the
minimum requirement to 3.12 for ALL platforms now? If there are no objections I
could do this and avoid an error in the future.
FYI here is a listing of what we currently use, 3.16.3 is the lowest version of
CMake we use right now.
W7 [Version 6.1.7601] cmake version 3.20.3
W8.1 [Version 6.3.9600] cmake version 3.20.3
W10 [Version 10.0.19045.3570] cmake version 3.22.2
W10 [Version 10.0.19045.3570] cmake version 3.25.0-rc1 (Physical Machine
W11 [Version 10.0.22621.2428] cmake version 3.25.0-rc2
macOS 10 Catalina Darwin Kernel Version 19.6.0 cmake version 3.27.7
macOS 11 BigSur Darwin Kernel Version 20.3.0cmake version 3.27.7
macOS 12 Monterey Darwin Kernel Version 21.6.0 cmake version 3.27.7
macOS 13 Ventura - currently no VM
macOS 14 Sonoma Darwin Kernel Version 23.0.0cmake version 3.27.3
Debian 11 cmake version 3.18.4
Ubuntu 22.04.3 LTS cmake version 3.22.1
Linux Mint 21.1 cmake version 3.22.1
CentOS 9cmake version 3.20.2
Fedora 38 cmake version 3.27.6
OpenSuse 15.3 cmake version 3.17.0
FreeBSD 13.1cmake version 3.26.1
OpenBSD 7.2 cmake version 3.24.2
NetBSD 9.3 cmake version 3.26.4
OpenIndiana cmake version 3.27.4
Raspberrypi2B 6.1.21-v7+cmake version 3.25.0-rc4
Raspberrypi3Bplus 6.1.21-v8+cmake version 3.25.0-rc4
Jenkins Controller (Ubuntu) cmake version 3.16.3
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Mark's M1 Mac running macOS 13 Ventura failing two tests
It seems Fedora and OpenSuse have the same problems so it may be a *nix problem Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 27. Oct 2023, at 16:31, ooRexx wrote: > > M1 Mac running macOS 13 Ventura (or higher) is failing two tests. Last > successful build was for revision 12718, please have a look what was changed > after that. > > > Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 27 Oct 2023 > OS Name:DARWIN > SysVersion: Darwin 23.0.0 > > Tests ran: 23935 > Assertions: 398125 > Failures: 0 > Errors: 2 > > [Framework exception] 20231027 23:59:53.266639 > Type: Trap Severity: Fatal > File: .../ooRexx/base/directives/search_order_cls.testGroup > Line: 2110 > Initial call of test container failed > Condition: NOVALUE > RESULT > 2110 *-* container = RESULT > 2057 *-* container = self~getContainer(fileName) > 81 *-* containers = finder~seek(testResult) > 79 *-* retCode = 'worker.rex'(arguments) > > [Framework exception] 20231027 23:59:53.267206 > Type: Trap Severity: Fatal > File: .../ooRexx/base/directives/search_order_testgroup.testGroup > Line: 2110 > Initial call of test container failed > Condition: NOVALUE > RESULT > 2110 *-* container = RESULT > 2057 *-* container = self~getContainer(fileName) > 81 *-* containers = finder~seek(testResult) > 79 *-* retCode = 'worker.rex'(arguments) > > File search:00:00:05.838858 > Suite construction: 00:00:00.458428 > Test execution: 00:15:29.334010 > Total time: 00:15:35.637915 > > Build step 'Execute shell' marked build as failure > Finished: FAILURE > > REST API > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > ___ > 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
[Oorexx-devel] Mark's M1 Mac running macOS 13 Ventura failing two tests
M1 Mac running macOS 13 Ventura (or higher) is failing two tests. Last successful build was for revision 12718, please have a look what was changed after that. Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 27 Oct 2023 OS Name:DARWIN SysVersion: Darwin 23.0.0 Tests ran: 23935 Assertions: 398125 Failures: 0 Errors: 2 [Framework exception] 20231027 23:59:53.266639 Type: Trap Severity: Fatal File: .../ooRexx/base/directives/search_order_cls.testGroup Line: 2110 Initial call of test container failed Condition: NOVALUE RESULT 2110 *-* container = RESULT 2057 *-* container = self~getContainer(fileName) 81 *-* containers = finder~seek(testResult) 79 *-* retCode = 'worker.rex'(arguments) [Framework exception] 20231027 23:59:53.267206 Type: Trap Severity: Fatal File: .../ooRexx/base/directives/search_order_testgroup.testGroup Line: 2110 Initial call of test container failed Condition: NOVALUE RESULT 2110 *-* container = RESULT 2057 *-* container = self~getContainer(fileName) 81 *-* containers = finder~seek(testResult) 79 *-* retCode = 'worker.rex'(arguments) File search:00:00:05.838858 Suite construction: 00:00:00.458428 Test execution: 00:15:29.334010 Total time: 00:15:35.637915 Build step 'Execute shell' marked build as failure Finished: FAILURE REST API Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Jenkins
This is just to say that our OpenIndiana VN Agent is offline due to low Disk space. I tried to extend it but it did not work so I will have to make a fresh install with more disk space. Hopefully I can do it this weekend. All other platforms are online and seems to build & test happily. Also I have moved the building of the documentation to a VM (macOS Monterey) and it is now working as intended BUT the changes introduced by Rony for the Revision numbering are not being picked up. I would need an explanation (again) what I need to do to make the revision changes become visible in the documentation. Example todays build of Rexref.pdf ooRexx Documentation 5.1.0 Open Object Rexx Reference Edition 2023.01.01 (last revised on 20221024 with r12526 I guess this is not what it should say. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Committing change
+1 for this proposal as well, from a Sunny Spain Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 22.09.2023 um 19:55 schrieb Sahananda Sahananda : > > Hi Terry, > > It looks like you are not a committer. I believe that Erich as the project > manager could convey that right on you. In the old days that would follow a > poll of all the committers. > Otherwise you would need to create and submit a patch. If you use Tortoise > SVN you can create a patch from the context menu. If you use SVN directly, > someone will tell you what to do. > You submit patches through the patches tracker on sourceforge. > > If I was polled on making you a committer I would vote +1 > > Jon > > On Fri, 22 Sept 2023 at 18:08, taf <mailto:t...@pgmguild.com>> wrote: > I've got the change for the ooRexx.org site that Jon provided. I've > tried to commit the change, but I don't have the appropriate access. > Should I send the change to someone else? > > -- > taf > > > > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx documentation build
> Am 27.08.2023 um 14:40 schrieb Rony G. Flatscher : > > Hi P.O., > > first of all thank you very much for all of your efforts in midst of your > vacation far away from your IT infrastructure! > > No problem, but I cannot do all things from remote so some things may have to wait a month or so. > --- > > One problem is probably that we have not done another release since the last > time where we had quite a few new scripts built to support the release > process. One such little tool is in docs/trunk/tools and named > "updateEntityValues.rex", the "readme.txt" in that directory gives brief > infos on the different utilities and how to use them. > Does this mean that the build process for the documentation needs to be modified? It did work impeccably until 5.0.0 was released, since then I have not touched it. I will check the above, currently the documentation build is a pure shell script on macOS. > We probably should kick a new release (5.0.1?) to re-acquaint ourselves again > and update the release documentation steps if necessary! > > I can not contribute until November at the earliest. And we should agree on a procedure before that, based on the list that Rick started at 5.0.0. > ---rony > > @Rony: can you explain what the printed information below actually means? Should something be changed whenever a commit is made (i.e. before the documentation is built)? That must be made by the committer I assume? > > On 27.08.2023 13:38, oorexx wrote: >> Dear all, >> >> At the moment the building of the documentation is manually triggered, since >> Jenkins cannot find SVN on the build machine (it is there and works, unclear >> why Jenkins does not detect it). When making the latest documentation I >> noticed the following ooRexx build levels: >> >> 12722 for ooRexx itself (This is the current version) >> 12723 for ooRexx TestGroups >> >> 12728 for Rexxref.pdf >> 12715 for Winextensions.pdf >> 12643 for RexxExtensions.pdf >> >> However, when I look at the built documentation I see this information: >> >> rexxref >> ooRexx Documentation 5.1.0 Open Object Rexx Reference Edition 2023.01.01 >> (last revised on 20221024 with r12526) >> >> winextensions >> ooRexx Documentation 5.1.0 Open Object Rexx Windows Extensions Reference >> Edition 2023.01.01 (last revised on 20220524 with r12416) >> >> rexxextensions >> ooRexx Documentation 5.1.0 Open Object Rexx >> Rexx Extensions Library Reference >> Edition 2023.01.01 (last revised on 20220619 with r12444) >> >> i.e. it seems the build revision is not reflected in the edition >> information? Is this as it should be or does something need to be changed? >> >> If someone intends to work on the documentation please trigger manually a >> build of the documentation in Jenkins, or, if you do not now hoot, send me a >> mail and I will do it. >> >> PS I am on leave and check my mail sparingly so there might be delays. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> > > ___ > 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
[Oorexx-devel] ooRexx documentation build
Dear all, At the moment the building of the documentation is manually triggered, since Jenkins cannot find SVN on the build machine (it is there and works, unclear why Jenkins does not detect it). When making the latest documentation I noticed the following ooRexx build levels: 12722 for ooRexx itself (This is the current version) 12723 for ooRexx TestGroups 12728 for Rexxref.pdf 12715 for Winextensions.pdf 12643 for RexxExtensions.pdf However, when I look at the built documentation I see this information: rexxref ooRexx Documentation 5.1.0 Open Object Rexx Reference Edition 2023.01.01 (last revised on 20221024 with r12526) winextensions ooRexx Documentation 5.1.0 Open Object Rexx Windows Extensions Reference Edition 2023.01.01 (last revised on 20220524 with r12416) rexxextensions ooRexx Documentation 5.1.0 Open Object Rexx Rexx Extensions Library Reference Edition 2023.01.01 (last revised on 20220619 with r12444) i.e. it seems the build revision is not reflected in the edition information? Is this as it should be or does something need to be changed? If someone intends to work on the documentation please trigger manually a build of the documentation in Jenkins, or, if you do not now hoot, send me a mail and I will do it. PS I am on leave and check my mail sparingly so there might be delays. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx documentation for 5.10 beta ?
It was not enough to upload again, Jenkins is caching the files in some weird place and prefer the older files over newer ones. I have manually uploaded all Windows versions (normal and portable) for revision 12722. It should report a build date of 25 August 2023. With the next commit this will work automatically. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 27.08.2023 um 12:05 schrieb oorexx : > > Dear Gil, > > The problem follows from the fact that the downloading of the documentation > is hardcoded into a script on the Windows build machine. I changed this to > use 5.1.0 documentation already end of last year (after the release of 5.0.0) > but when moving the build process to a new Windows build machine I copied the > old version of the script by mistake and it went unnoticed since there are > very few changes to the documentation :-(. This has all been corrected now > and I have confirmed that the Windows build uses 5.1.0 documentation. The > reason this is not visible on sourceforge is because the upload script keeps > track of what versions have already been build, I need to delete the latest > version o sourceforge and upload again. In any case any new commit will > trigger a fresh rebuild that should have the correct version of the > documentation also on Windows. > > Here is an excerpt from the lates build attempt: > > Remote file is newer, retrieving. > > --2023-08-25 10:38:55-- > https://kumisystems.dl.sourceforge.net/project/oorexx/oorexx-docs/5.1.0beta/rexxextensions.pdf > > <https://kumisystems.dl.sourceforge.net/project/oorexx/oorexx-docs/5.1.0beta/rexxextensions.pdf> > Connecting to kumisystems.dl.sourceforge.net > <http://kumisystems.dl.sourceforge.net/> (kumisystems.dl.sourceforge.net > <http://kumisystems.dl.sourceforge.net/>)|148.251.120.111|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 330878 (323K) [application/octet-stream] > Saving to: 'rexxextensions.pdf' > > 0K .. .. .. .. .. 15% 986K 0s > 50K .. .. .. .. .. 30% 8,74M 0s >100K .. .. .. .. .. 46% 1,93M 0s >150K .. .. .. .. .. 61% 2,32M 0s >200K .. .. .. .. .. 77% 7,73M 0s >250K .. .. .. .. .. 92% 2,07M 0s >300K .. .. ... 100% 6,80M=0,1s > > 2023-08-25 10:38:56 (2,32 MB/s) - 'rexxextensions.pdf' saved [330878/330878] > > We should amend the script to take the download path (or part of it) as input > so it could be changed from the command line. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > >> Am 26.08.2023 um 20:25 schrieb Gilbert Barmwater > <mailto:gi...@bellsouth.net>>: >> >> I suspect that the problem resides with the build process for the Windows >> installer - NSIS. It incorporates the PDF documentation into the .exe file >> and should be using the files from .../oorexx-docs/5.1.0beta/. Although >> that directory now contains new versions of the PDFs, the r12722 Windows >> builds do not contain them. Can someone look at how the docs are obtained >> for inclusion into the NSIS installers? Thanks! >> >> On 8/16/2023 11:20 AM, Rony G. Flatscher wrote: >>> On 15.08.2023 17:46, Rony G. Flatscher wrote: >>>> Using the latest 64-bit version of ooRexx >>>> (oorexx-5.1.0-12718.windows.x86_64.exe) I noticed that Jean Louis' commits >>>> to the documentation [r12715] for his enhancements to the WindowsClipboard >>>> class is not reflected in the documentation that gets installed with >>>> r12718! Instead it seems that the GA version of the documentation gets >>>> distributed with it. >>> >>> It seems that since February no new documentation for 5.1.0beta got >>> uploaded to >>> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.1.0beta/ >>> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.1.0beta/>>. >>> >>> ---rony >>> >>> >>> >>> _______ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto: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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx documentation for 5.10 beta ?
Dear Gil, The problem follows from the fact that the downloading of the documentation is hardcoded into a script on the Windows build machine. I changed this to use 5.1.0 documentation already end of last year (after the release of 5.0.0) but when moving the build process to a new Windows build machine I copied the old version of the script by mistake and it went unnoticed since there are very few changes to the documentation :-(. This has all been corrected now and I have confirmed that the Windows build uses 5.1.0 documentation. The reason this is not visible on sourceforge is because the upload script keeps track of what versions have already been build, I need to delete the latest version o sourceforge and upload again. In any case any new commit will trigger a fresh rebuild that should have the correct version of the documentation also on Windows. Here is an excerpt from the lates build attempt: Remote file is newer, retrieving. --2023-08-25 10:38:55-- https://kumisystems.dl.sourceforge.net/project/oorexx/oorexx-docs/5.1.0beta/rexxextensions.pdf <https://kumisystems.dl.sourceforge.net/project/oorexx/oorexx-docs/5.1.0beta/rexxextensions.pdf> Connecting to kumisystems.dl.sourceforge.net (kumisystems.dl.sourceforge.net)|148.251.120.111|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 330878 (323K) [application/octet-stream] Saving to: 'rexxextensions.pdf' 0K .. .. .. .. .. 15% 986K 0s 50K .. .. .. .. .. 30% 8,74M 0s 100K .. .. .. .. .. 46% 1,93M 0s 150K .. .. .. .. .. 61% 2,32M 0s 200K .. .. .. .. .. 77% 7,73M 0s 250K .. .. .. .. .. 92% 2,07M 0s 300K .. .. ... 100% 6,80M=0,1s 2023-08-25 10:38:56 (2,32 MB/s) - 'rexxextensions.pdf' saved [330878/330878] We should amend the script to take the download path (or part of it) as input so it could be changed from the command line. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 26.08.2023 um 20:25 schrieb Gilbert Barmwater : > > I suspect that the problem resides with the build process for the Windows > installer - NSIS. It incorporates the PDF documentation into the .exe file > and should be using the files from .../oorexx-docs/5.1.0beta/. Although that > directory now contains new versions of the PDFs, the r12722 Windows builds do > not contain them. Can someone look at how the docs are obtained for > inclusion into the NSIS installers? Thanks! > > On 8/16/2023 11:20 AM, Rony G. Flatscher wrote: >> On 15.08.2023 17:46, Rony G. Flatscher wrote: >>> Using the latest 64-bit version of ooRexx >>> (oorexx-5.1.0-12718.windows.x86_64.exe) I noticed that Jean Louis' commits >>> to the documentation [r12715] for his enhancements to the WindowsClipboard >>> class is not reflected in the documentation that gets installed with >>> r12718! Instead it seems that the GA version of the documentation gets >>> distributed with it. >> >> It seems that since February no new documentation for 5.1.0beta got uploaded >> to <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.1.0beta/>. >> >> ---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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ubuntu 16
Now I have this Failure in macOS 10 as well, In the log file I see this Executing .../ooRexx/base/keyword/TRACE.testGroup 758 *-* trace off Executing .../ooRexx/base/keyword/USE.testGroup Which seems to imply that the trace instruction is not captured in the test? The error message at the end is the one below. Please let me know if I can provide further debugging info. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 24. Jul 2023, at 18:25, ooRexx wrote: > > There is one failing test in the Trace Testgroups for Ubuntu 16, Ubuntu 20 > and 22 and all other platforms all pass the same test. Please have a look > > ooTest Framework - Automated Test of the ooRexx Interpreter > > Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 23 Jul 2023 > OS Name:LINUX > SysVersion: Linux 4.4.0-210-generic > > Tests ran: 23963 > Assertions: 385230 > Failures: 1 > Errors: 0 > > [failure] 20230723 12:29:29.327944 > Test: TEST_TRACE_REPLY_REPLYASSERT > Class: TRACE.TESTGROUP > File: .../ooRexx/base/keyword/TRACE.testGroup > Line: 764 > Failed: assertTrue > Expected: 1 > Actual: 0 > Message: actual and expected trace output have different line counts > actual trace output >757 *-* reply 1 >>L> "1" >>>> "1" > >I> Method "TEST_TRACE_REPLY_REPLYASSERT" with scope "TRACE.TESTGROUP" > in package > "/home/jenkins/slave/workspace/oorexx-ubuntu16-test/ooRexx/base/keyword/TRACE.testGroup". > > expected trace output > 1 *-* reply 1 >>L> "1" >>>> "1" > > File search:00:00:00.923822 > Suite construction: 00:00:00.992980 > Test execution: 00:06:05.789342 > Total time: 00:06:07.706569 > > Build step 'Execute shell' marked build as failure > Finished: FAILURE > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > > ___ > 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
[Oorexx-devel] Failing properties testgroup for Windows 7, 32 and 64 bit
All other platforms seems to pass this test, Windows 7 not. Please have a look. Executing ...\ooRexx\samples\properties.testGroup ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:REXX-ooRexx_5.1.0(MT)_32-bit 6.05 23 Jul 2023 OS Name:WindowsNT SysVersion: Windows 6.1.7601 Tests ran: 76 Assertions: 180 Failures: 1 Errors: 0 [failure] 20230724 18:12:12.32 Test: TEST_04_PROPERTIES.REX Class: properties.testGroup File: ...\ooRexx\samples\properties.testGroup Line: 148 Failed: assertEquals Expected: s_d = 1 Actual: s_d = 2 File search:00:00:00.167000 Suite construction: 00:00:00.005000 Test execution: 00:00:00.321000 Total time: 00:00:00.494000 Build step 'Execute Windows batch command' marked build as failure Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Ubuntu 16
There is one failing test in the Trace Testgroups for Ubuntu 16, Ubuntu 20 and 22 and all other platforms all pass the same test. Please have a look ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 23 Jul 2023 OS Name:LINUX SysVersion: Linux 4.4.0-210-generic Tests ran: 23963 Assertions: 385230 Failures: 1 Errors: 0 [failure] 20230723 12:29:29.327944 Test: TEST_TRACE_REPLY_REPLYASSERT Class: TRACE.TESTGROUP File: .../ooRexx/base/keyword/TRACE.testGroup Line: 764 Failed: assertTrue Expected: 1 Actual: 0 Message: actual and expected trace output have different line counts actual trace output 757 *-* reply 1 >L> "1" >>> "1" >I> Method "TEST_TRACE_REPLY_REPLYASSERT" with scope "TRACE.TESTGROUP" in package "/home/jenkins/slave/workspace/oorexx-ubuntu16-test/ooRexx/base/keyword/TRACE.testGroup". expected trace output 1 *-* reply 1 >L> "1" >>> "1" File search:00:00:00.923822 Suite construction: 00:00:00.992980 Test execution: 00:06:05.789342 Total time: 00:06:07.706569 Build step 'Execute shell' marked build as failure Finished: FAILURE Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Source Package
This is just to say that I think I have cracked it now, as of r12712 we should
have a source package built, I have set up a special job for it so it is not
interfering with other builds.
I am closing bug report #1910 soon if there are no objections.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> On 22. Jul 2023, at 15:35, Rony wrote:
>
> Dear P.O.,
>
> what is the resulting structure and what did you expect?
>
> Have you looked into the prefix switch in the explanation of the
> StackOverflow link?
>
> HTH
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>
>> Am 22.07.2023 um 15:20 schrieb ooRexx :
>>
>> Dear Rony,
>>
>> This did not work (the path inside /Applications/ooRexx is still messed up
>> for the installation because of my “fix") so I need to remove that line for
>> the source package and think of something else. I think moving to a temp dir
>> inside the build path would be more logical.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se <mailto:oor...@jonases.se>
>>
>>
>>
>>> On 22. Jul 2023, at 12:01, Rony >> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>
>>> Hi P.O.,
>>>
>>> forgot DESTDIR, cf
>>> https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make
>>> <https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make>
>>>
>>> Hence something like
>>>
>>>make install DESTDIR=~/Applications/ooRexx
>>>
>>> HTH
>>>
>>> —-rony
>>>
>>> Rony G. Flatscher (mobil/e)
>>>
>>>> Am 22.07.2023 um 11:39 schrieb Rony >>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>>
>>>> Hi P.O.,
>>>>
>>>> being on the road not having access to a computer and not being a CMake
>>>> expert at all there is one thing I vaguely remember: you can supply the
>>>> install directory when issuing make install, maybe something like „make
>>>> install ~/Applications“.
>>>>
>>>> HTH
>>>>
>>>> —-rony
>>>>
>>>> Rony G. Flatscher (mobil/e)
>>>>
>>>>> Am 22.07.2023 um 11:23 schrieb ooRexx >>>> <mailto:oor...@jonases.se>>:
>>>>>
>>>>>
>>>>> I am trying to make the build of a source package work, i.e. a compressed
>>>>> version of the complete source code as it comes out of SVN. With these
>>>>> lines in CMakeLists.txt:
>>>>>
>>>>> # Create a source package
>>>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>>>
>>>>> The package looks like this
>>>>>
>>>>> oorexx-5.1.0-12706
>>>>> |-- usr
>>>>> | |-- local
>>>>> ||-- CHANGES
>>>>> ||-- CMake-build-readme.txt
>>>>> ||-- CMakeLists.txt
>>>>> ...
>>>>>
>>>>> i.e. the default path is included in the compressed source, and we do not
>>>>> want that.
>>>>>
>>>>> I tried to change the install path for the source package like this:
>>>>>
>>>>> # Create a source package
>>>>> set (CMAKE_INSTALL_PREFIX .)
>>>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>>>
>>>>> Now the package looks like this:
>>>>>
>>>>> oorexx-5.1.0-12706
>>>>> |-- CHANGES
>>>>> |-- CMake-build-readme.txt
>>>>> |-- CMakeLists.txt
>>>>> ...
>>>>>
>>>>> i.e. the additional subdirectories are gone, and the package is as we
>>>>> want it to be. That is the good news.
>>>>>
>>>>> The bad news is that (as I just learned) it had the side effect that
>>>>> "make install" fail on macOS and hence the building of an installer
>>>>> consequently fail
>>>>>
>>>>> Does anybody have a solution how to be able to install (make
Re: [Oorexx-devel] Source Package
> On 22. Jul 2023, at 15:35, Rony wrote:
>
> Dear P.O.,
>
> what is the resulting structure and what did you expect?
>
The resulting structure was a mismatch. Rather than oorexx5 as a resulting
folder I end up with
oorexx5/Users/jenkins/Applications/ooRexx5.
The mismatch goes away when I remove the line changing the prefix.
(CMAKE_INSTALL_PREFIX .)
> Have you looked into the prefix switch in the explanation of the
> StackOverflow link?
Yes, but I have no time right now to do something, I have the information I
need for the time being. Thanks for the hint.
>
> HTH
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>
>> Am 22.07.2023 um 15:20 schrieb ooRexx :
>>
>> Dear Rony,
>>
>> This did not work (the path inside /Applications/ooRexx is still messed up
>> for the installation because of my “fix") so I need to remove that line for
>> the source package and think of something else. I think moving to a temp dir
>> inside the build path would be more logical.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se <mailto:oor...@jonases.se>
>>
>>
>>
>>> On 22. Jul 2023, at 12:01, Rony >> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>
>>> Hi P.O.,
>>>
>>> forgot DESTDIR, cf
>>> https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make
>>> <https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make>
>>>
>>> Hence something like
>>>
>>>make install DESTDIR=~/Applications/ooRexx
>>>
>>> HTH
>>>
>>> —-rony
>>>
>>> Rony G. Flatscher (mobil/e)
>>>
>>>> Am 22.07.2023 um 11:39 schrieb Rony >>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>>
>>>> Hi P.O.,
>>>>
>>>> being on the road not having access to a computer and not being a CMake
>>>> expert at all there is one thing I vaguely remember: you can supply the
>>>> install directory when issuing make install, maybe something like „make
>>>> install ~/Applications“.
>>>>
>>>> HTH
>>>>
>>>> —-rony
>>>>
>>>> Rony G. Flatscher (mobil/e)
>>>>
>>>>> Am 22.07.2023 um 11:23 schrieb ooRexx >>>> <mailto:oor...@jonases.se>>:
>>>>>
>>>>>
>>>>> I am trying to make the build of a source package work, i.e. a compressed
>>>>> version of the complete source code as it comes out of SVN. With these
>>>>> lines in CMakeLists.txt:
>>>>>
>>>>> # Create a source package
>>>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>>>
>>>>> The package looks like this
>>>>>
>>>>> oorexx-5.1.0-12706
>>>>> |-- usr
>>>>> | |-- local
>>>>> ||-- CHANGES
>>>>> ||-- CMake-build-readme.txt
>>>>> ||-- CMakeLists.txt
>>>>> ...
>>>>>
>>>>> i.e. the default path is included in the compressed source, and we do not
>>>>> want that.
>>>>>
>>>>> I tried to change the install path for the source package like this:
>>>>>
>>>>> # Create a source package
>>>>> set (CMAKE_INSTALL_PREFIX .)
>>>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>>>
>>>>> Now the package looks like this:
>>>>>
>>>>> oorexx-5.1.0-12706
>>>>> |-- CHANGES
>>>>> |-- CMake-build-readme.txt
>>>>> |-- CMakeLists.txt
>>>>> ...
>>>>>
>>>>> i.e. the additional subdirectories are gone, and the package is as we
>>>>> want it to be. That is the good news.
>>>>>
>>>>> The bad news is that (as I just learned) it had the side effect that
>>>>> "make install" fail on macOS and hence the building of an installer
>>>>> consequently fail
>>>>>
>>>>> Does anybody have a solutio
Re: [Oorexx-devel] Source Package
Dear Rony,
This did not work (the path inside /Applications/ooRexx is still messed up for
the installation because of my “fix") so I need to remove that line for the
source package and think of something else. I think moving to a temp dir inside
the build path would be more logical.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> On 22. Jul 2023, at 12:01, Rony wrote:
>
> Hi P.O.,
>
> forgot DESTDIR, cf
> https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make
> <https://stackoverflow.com/questions/11307465/destdir-and-prefix-of-make>
>
> Hence something like
>
> make install DESTDIR=~/Applications/ooRexx
>
> HTH
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>
>> Am 22.07.2023 um 11:39 schrieb Rony :
>>
>> Hi P.O.,
>>
>> being on the road not having access to a computer and not being a CMake
>> expert at all there is one thing I vaguely remember: you can supply the
>> install directory when issuing make install, maybe something like „make
>> install ~/Applications“.
>>
>> HTH
>>
>> —-rony
>>
>> Rony G. Flatscher (mobil/e)
>>
>>> Am 22.07.2023 um 11:23 schrieb ooRexx :
>>>
>>>
>>> I am trying to make the build of a source package work, i.e. a compressed
>>> version of the complete source code as it comes out of SVN. With these
>>> lines in CMakeLists.txt:
>>>
>>> # Create a source package
>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>
>>> The package looks like this
>>>
>>> oorexx-5.1.0-12706
>>> |-- usr
>>> | |-- local
>>> ||-- CHANGES
>>> ||-- CMake-build-readme.txt
>>> ||-- CMakeLists.txt
>>> ...
>>>
>>> i.e. the default path is included in the compressed source, and we do not
>>> want that.
>>>
>>> I tried to change the install path for the source package like this:
>>>
>>> # Create a source package
>>> set (CMAKE_INSTALL_PREFIX .)
>>> set(CPACK_SOURCE_GENERATOR "TGZ")
>>> set(CPACK_SOURCE_PACKAGE_FILE_NAME
>>> "${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
>>>
>>> Now the package looks like this:
>>>
>>> oorexx-5.1.0-12706
>>> |-- CHANGES
>>> |-- CMake-build-readme.txt
>>> |-- CMakeLists.txt
>>> ...
>>>
>>> i.e. the additional subdirectories are gone, and the package is as we want
>>> it to be. That is the good news.
>>>
>>> The bad news is that (as I just learned) it had the side effect that "make
>>> install" fail on macOS and hence the building of an installer consequently
>>> fail
>>>
>>> Does anybody have a solution how to be able to install (make install) to
>>> ~Applications/ooRexx5 on macOS and still being able to create a source
>>> package without any additional path?
>>>
>>> I have tried to build the package also on Linux but also that did not work.
>>>
>>> Since Rony have managed to build a relocatable package, could such an
>>> approach be made? I do not possess the knowledge of how CMake works so I am
>>> relying on help here.
>>>
>>> If nothing else helps I see so other possibility than creating the package
>>> in a post-process driven from CMake (similar to how the Windows and macOS
>>> installers are created). But it MUST be possible to do this the "right” way
>>> using normal CMake commands?
>>>
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>>
>>>
>>>
>>> ___
>>> 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
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Failing Test
Hi Jeremy,
In the normal case the testing framework DO catch syntax errors and reports
them, but It can be tweaked for special tests. I only spotted this typo because
I saw it once, in a log file. This is how the test looks like (with the typo);
as you can see it is much more complex than “normal” tests to be able to catch
trace output.
-- trace REPLY keyword instruction
-- to work properly, tests using REPLY require the special test framework
-- marker "replyAssert"
::method test_trace_reply_replyAssert
t = .TraceOutput~destination(.ArrayStream~new)
start = .line; trace i
reply 1
trace off
-- before comparing trace output, we remove any trailing >I> Method ...
if t~lastItem~srip("l")~startsWith(">I> Method") then
t~remove(t~last)
self~assertTraceOutput(.resources~reply, t, start)
::resource reply end " ::end"
1 *-* reply 1
>L> "1"
>>> "1"
::end
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> On 22. Jul 2023, at 13:28, Jeremy Nicoll
> wrote:
>
> On Sat, 22 Jul 2023, at 09:53, ooRexx wrote:
>> I changed a typo “srip” to “strip" in the TRACE.testGroup with r12708
>>
>> - if t~lastItem~srip("l")~startsWith(">I> Method") then
>> + if t~lastItem~strip("l")~startsWith(">I> Method") then
>>
>> Now many if not all platforms have a failure instead of just skipping
>> the test ...
>
> Isn't it a flaw in the testing framework if syntax errors in the code are
> not detected when tests are run?
>
> (Though I suppose that may depend on what you mean by "skipping
> the test".)
>
> --
> Jeremy Nicoll - my opinions are my own.
>
>
> ___
> 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
[Oorexx-devel] Source Package
I am trying to make the build of a source package work, i.e. a compressed
version of the complete source code as it comes out of SVN. With these lines in
CMakeLists.txt:
# Create a source package
set(CPACK_SOURCE_GENERATOR "TGZ")
set(CPACK_SOURCE_PACKAGE_FILE_NAME
"${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
The package looks like this
oorexx-5.1.0-12706
|-- usr
| |-- local
||-- CHANGES
||-- CMake-build-readme.txt
||-- CMakeLists.txt
...
i.e. the default path is included in the compressed source, and we do not want
that.
I tried to change the install path for the source package like this:
# Create a source package
set (CMAKE_INSTALL_PREFIX .)
set(CPACK_SOURCE_GENERATOR "TGZ")
set(CPACK_SOURCE_PACKAGE_FILE_NAME
"${CPACK_PACKAGE_NAME}-${ORX_MAJOR}.${ORX_MINOR}.${ORX_MOD_LVL}-${CPACK_PACKAGE_RELEASE}")
Now the package looks like this:
oorexx-5.1.0-12706
|-- CHANGES
|-- CMake-build-readme.txt
|-- CMakeLists.txt
...
i.e. the additional subdirectories are gone, and the package is as we want it
to be. That is the good news.
The bad news is that (as I just learned) it had the side effect that "make
install" fail on macOS and hence the building of an installer consequently fail
Does anybody have a solution how to be able to install (make install) to
~Applications/ooRexx5 on macOS and still being able to create a source package
without any additional path?
I have tried to build the package also on Linux but also that did not work.
Since Rony have managed to build a relocatable package, could such an approach
be made? I do not possess the knowledge of how CMake works so I am relying on
help here.
If nothing else helps I see so other possibility than creating the package in a
post-process driven from CMake (similar to how the Windows and macOS installers
are created). But it MUST be possible to do this the "right” way using normal
CMake commands?
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
_______
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Failing Test
I changed a typo “srip” to “strip" in the TRACE.testGroup with r12708
- if t~lastItem~srip("l")~startsWith(">I> Method") then
+ if t~lastItem~strip("l")~startsWith(">I> Method") then
Now many if not all platforms have a failure instead of just skipping the test
:-( can someone please change the test to work as it was originally intended?
ooTest Framework - Automated Test of the ooRexx Interpreter
Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 21 Jul 2023
OS Name:LINUX
SysVersion: Linux 5.14.0-333.el9.x86_64
Tests ran: 23933
Assertions: 385215
Failures: 1
Errors: 0
[failure] 20230721 18:14:50.837031
Test: TEST_TRACE_REPLY_REPLYASSERT
Class: TRACE.TESTGROUP
File: .../ooRexx/base/keyword/TRACE.testGroup
Line: 762
Failed: assertTrue
Expected: 1
Actual: 0
Message: actual and expected trace output have different line counts
actual trace output
757 *-* reply 1
>L> "1"
>>> "1"
>I> Method "TEST_TRACE_REPLY_REPLYASSERT" with scope "TRACE.TESTGROUP"
in package
"/home/osboxes/workspace/ooRexx-CentOS9-test/ooRexx/base/keyword/TRACE.testGroup".
expected trace output
1 *-* reply 1
>L> "1"
>>> "1"
File search:00:00:01.069582
Suite construction: 00:00:01.085705
Test execution: 00:05:59.822007
Total time: 00:06:01.977835
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Build failed in Jenkins: ooRexx-macOS10-build #52
I have set up Jenkins to be able to send Email following a build failure, the title above is from a (fake) error on macOS build. The standard notification have this default setup: If configured, Jenkins will send out an e-mail to the specified recipients when a certain important event occurs. Every failed build triggers a new e-mail. A successful build after a failed (or unstable) build triggers a new e-mail, indicating that a crisis is over. An unstable build after a successful build triggers a new e-mail, indicating that there's a regression. (Unless configured, every unstable build triggers a new e-mail, indicating that regression is still there.) It can be set up on a user basis and you will then only receive notification if you (or someone else) messed up a commit so there should not be many notifications going out ;-) It is also possible to receive notification for every build, and for all platforms or only a selection. Send me an email off the list if you are interested indicating Email and what platforms you are interested in. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] now MyRexxComp.rex works fine with MyRexxComp.ini
fid='test.txt' Do i=1 to 5 Call lineout fid,'record' i end call lineout fid 'ked' fid uses kedit > Franz Marx hat am 19.05.2023 17:57 CEST geschrieben: > > > Hi, folks! > In the meantime I corrected my "MyRexxComp.rex" with the Text-Editor gedit > and all looks fine. > My new version of MyRexxComp.rex can handle now such "BOM" - characters, as > you canhttp://see.in my attachments. > Thanks for your advice and help. > > Another question: > how can I call "gedit" or"Kate" out of a "Rexx" program? > At the moment i can't > > Greetings > Franz > > > Am Fr., 19. Mai 2023 um 17:15 Uhr schrieb Mark L. Gaubatz via Oorexx-devel > mailto:oorexx-devel@lists.sourceforge.net>: > > > > > Franz wrote: > > > > > > > > I think I do not use the correct editor with KATE for my .ini file, it is > > too silly for me. > > > > I attach to you my last 2 test-files. > > > > I think you can tell me what I have to do. > > > > > > > > Your MyRexxComp.ini file was last edited and saved using UTF-8 codepage > > encoding. This is shown as the UTF-8 marker sequence and text handling > > placed by the editor at the beginning of line one of file MyRexxComp.ini: > > > > > > > > EFBBBF2F2A272A2A… > > ï » ¿ / * ' * * … > > > > > > > > With the editor you’re using, you will need to re-open the file, change the > > codepage to a straight or extended ASCII codepage, and save again. > > > > > > > > Mark > > > > ___ > > Oorexx-devel mailing list > > Oorexx-devel@lists.sourceforge.net mailto: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 > LG Walter ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] my experience with MyRexxComp.rex and MyRexxComp.ini
Franz wrote: I think I do not use the correct editor with KATE for my .ini file, it is too silly for me. I attach to you my last 2 test-files. I think you can tell me what I have to do. Your MyRexxComp.ini file was last edited and saved using UTF-8 codepage encoding. This is shown as the UTF-8 marker sequence and text handling placed by the editor at the beginning of line one of file MyRexxComp.ini: EFBBBF2F2A272A2A… ï » ¿ / * ' * * … With the editor you’re using, you will need to re-open the file, change the codepage to a straight or extended ASCII codepage, and save again. Mark ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Short info
I will be away for a couple of weeks but will keep an eye on Jenkins from remote. I will not be able to do anything major though. I have created /branches/5.0 that can serve as the repository for 5.0.1. I did not have time to commit my 5.0.1 items will do that when I am back. As a late Easter egg for Rony I have created ooRexx 5.0.0 portable installers for most platforms I have also recompiled most 5.0.0 installers and added the documentation (that was missing for most Unix/Linux platforms), should I replace the ones from December last year, or do we wait with that for 5.1.0? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] "Per-Interpreter GIL" will land in Python 3.12
Restated, instead of a common or mutex lock, they are now going to use a per interpreter instance lock. A long time overdue, but the author’s assertion of “truly concurrent Python code” is incorrect and should have been stated otherwise. The real implication is that when multiple Python interpreters are in use within a single process, the interpreters are no longer single threaded by the use of a common GIL (Global Interpreter Lock). In other words, they’re fixing an issue that most Python programmers don’t use directly, but is a feature used by major library routines (for example, AI). The author finally makes this admission directly in their conclusion. Mark L. Gaubatz From: Jean Louis Faucher Sent: Tuesday, May 16, 2023 07:37 To: Open Object Rexx Developer Mailing List Subject: [Oorexx-devel] "Per-Interpreter GIL" will land in Python 3.12 I saw this link in the daily TLDR mail of today: https://martinheinz.dev/blog/97 Real Multithreading is Coming to Python - Learn How You Can Use It Now Did not read in details yet, but seems worth to understand how they implemented their "Per-Interpreter GIL”. ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Closing all tickets on ooRexx 5.0.0
I have tried to close all tickets I was responsible for and moved other forward to 5.1.0 or 5.0.1 (change to none where I did so in error), there is only a small number of tickets left can you please have a look and do something about “your” tickets so that ooRexx can be closed. 1837circular requires: some public classes are not visible 1825CALL with literal name should bypass internal labels 1786RexxPullFromQueue() returning invalid data for a null queue entry 1774Building and Testing on Windows 8 1773Android build issues 1768ncurses.cls doesn't build on some platforms 1763StreamSocket issues 1762pushing very large data hangs RexxQueue 1742Stream RECLENGTH 1 issues 1734Hang with multiple threads 1675classic lineout() 1656Lineout fails (at 2nd call) when path case not matched 1447Clean builds without compiler warnings Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Please help: how can i configure Open Object Rexx 5.1 in OpenSuse Leap 15.4
Hi Franz, An alternative for the shebang would be #!/usr/bin/env rexx (Like this, the space is intentional) You need to google /usr/bin/env to see what is going on, the Linux-way is a bit different from the Windows-way, steep learning curve, been there, done that. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 12. May 2023, at 16:03, ooRexx wrote: > > >> On 12. May 2023, at 15:58, CV Bruce > <mailto:cvbr...@gmail.com>> wrote: >> >> On Linux and Unix, your Rexx program needs to start with a line like >> #!/path/to/rexx >> Where path/to/Rexx is the path to where the Rexx executable is installed. >> > > For Rexx on all Linux the shebang line would be > > #!/usr/local/bin/rexx > > >> And the Rexx program must have its permissions set to executable, I.e. >> “chmod 755 myRexxProgram.rex” >> >> Bruce >> >> Sent by Magic! >> >>> On May 12, 2023, at 5:22 AM, Franz Marx >> <mailto:marx.fr...@gmail.com>> wrote: >>> >>> >>> Hi, >>> i have to learn still a lot for OpenSuse, but I have time. >>> "It's a rainy day, hallelujah ..." >>> 珞 >>> >>> Grüsse aus Österreich >>> Franz >>> >>> Am Fr., 12. Mai 2023 um 14:08 Uhr schrieb ooRexx >> <mailto:oor...@jonases.se>>: >>> Hi, >>> >>> I am not sure I understand the question. Once you have installed ooRexx it >>> should work out of the box, there is nothing to configure on the ooRexx >>> side, you just call it with rexx myprogram.rex, you can leave out the >>> extension so rexx myprogram suffices. Similar to how you call a Python >>> program. Be aware that there are no GUI features for any other >>> implementation than Windows (ooDialog), it is all done on the command line >>> for all the Linuxes and in macOS. >>> >>> If you mean that you want to be able to “click” the program to start it >>> from a Graphical interface you could try to change the rules for how a >>> certain extension is handled in OpenSuse as explained here >>> <https://forums.opensuse.org/t/how-to-set-default-open-with-program/25227>, >>> but I am no expert in how this works out you will have to figure that out >>> yourself. Hope it helps. >>> >>> Hälsningar/Regards/Grüsse, >>> P.O. Jonsson >>> oor...@jonases.se <mailto:oor...@jonases.se> >>> >>> >>> >>>> On 12. May 2023, at 13:39, Franz Marx >>> <mailto:marx.fr...@gmail.com>> wrote: >>>> >>>> Hi, Mr. Jonson! >>>> First of all: the Installation worked with your detailed advice, of course! >>>> >>>> But One thing I still miss: >>>> how can I configure the Open Rexx Version 5.1.0 within OpenSuse Leap 15.4 ? >>>> Like in Windows, my *.rex program should be executed immediately. >>>> i am sorry to be such inexperienced to bore you with this question 蘿 >>>> I only find Rexxtry within the App-Listing (that works, of course) >>>> >>>> regards >>>> Franz >>>> >>>> Am Mi., 10. Mai 2023 um 15:25 Uhr schrieb ooRexx >>> <mailto:oor...@jonases.se>>: >>>> Hi, >>>> >>>> Suse is one of the most unproblematic/stable platforms for ooRexx, I have >>>> hardly ever seen a problem in the testing so go ahead and do not hesitate >>>> to report back any problem you find (I bet one bottle of beer that you >>>> won’t find any :-) ) >>>> >>>> Try to ignore the “Beta” in the name of the rolling release, it is solid >>>> as a rock in my experience. Since 5.0.0 was so long in the coming, a >>>> number of minor things were missed out in the release, mostly in the >>>> documentation area. All those things are ironed out in 5.1.0. Installation >>>> procedure is exactly the same. Good luck. >>>> >>>> Hälsningar/Regards/Grüsse, >>>> P.O. Jonsson >>>> oor...@jonases.se <mailto:oor...@jonases.se> >>>> >>>> >>>> >>>>> On 10. May 2023, at 14:21, Franz Marx >>>> <mailto:marx.fr...@gmail.com>> wrote: >>>>> >>>>> Hi P.O. Jonsson! >>>>> >>>>> Thank you very much for your detailed description, I will now try to >>>>> install release 5.1.0 Beta, >>>>> as you suggest. >>
Re: [Oorexx-devel] Please help: how can i configure Open Object Rexx 5.1 in OpenSuse Leap 15.4
> On 12. May 2023, at 15:58, CV Bruce wrote: > > On Linux and Unix, your Rexx program needs to start with a line like > #!/path/to/rexx > Where path/to/Rexx is the path to where the Rexx executable is installed. > For Rexx on all Linux the shebang line would be #!/usr/local/bin/rexx > And the Rexx program must have its permissions set to executable, I.e. “chmod > 755 myRexxProgram.rex” > > Bruce > > Sent by Magic! > >> On May 12, 2023, at 5:22 AM, Franz Marx wrote: >> >> >> Hi, >> i have to learn still a lot for OpenSuse, but I have time. >> "It's a rainy day, hallelujah ..." >> 珞 >> >> Grüsse aus Österreich >> Franz >> >> Am Fr., 12. Mai 2023 um 14:08 Uhr schrieb ooRexx > <mailto:oor...@jonases.se>>: >> Hi, >> >> I am not sure I understand the question. Once you have installed ooRexx it >> should work out of the box, there is nothing to configure on the ooRexx >> side, you just call it with rexx myprogram.rex, you can leave out the >> extension so rexx myprogram suffices. Similar to how you call a Python >> program. Be aware that there are no GUI features for any other >> implementation than Windows (ooDialog), it is all done on the command line >> for all the Linuxes and in macOS. >> >> If you mean that you want to be able to “click” the program to start it from >> a Graphical interface you could try to change the rules for how a certain >> extension is handled in OpenSuse as explained here >> <https://forums.opensuse.org/t/how-to-set-default-open-with-program/25227>, >> but I am no expert in how this works out you will have to figure that out >> yourself. Hope it helps. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> On 12. May 2023, at 13:39, Franz Marx >> <mailto:marx.fr...@gmail.com>> wrote: >>> >>> Hi, Mr. Jonson! >>> First of all: the Installation worked with your detailed advice, of course! >>> >>> But One thing I still miss: >>> how can I configure the Open Rexx Version 5.1.0 within OpenSuse Leap 15.4 ? >>> Like in Windows, my *.rex program should be executed immediately. >>> i am sorry to be such inexperienced to bore you with this question 蘿 >>> I only find Rexxtry within the App-Listing (that works, of course) >>> >>> regards >>> Franz >>> >>> Am Mi., 10. Mai 2023 um 15:25 Uhr schrieb ooRexx >> <mailto:oor...@jonases.se>>: >>> Hi, >>> >>> Suse is one of the most unproblematic/stable platforms for ooRexx, I have >>> hardly ever seen a problem in the testing so go ahead and do not hesitate >>> to report back any problem you find (I bet one bottle of beer that you >>> won’t find any :-) ) >>> >>> Try to ignore the “Beta” in the name of the rolling release, it is solid as >>> a rock in my experience. Since 5.0.0 was so long in the coming, a number of >>> minor things were missed out in the release, mostly in the documentation >>> area. All those things are ironed out in 5.1.0. Installation procedure is >>> exactly the same. Good luck. >>> >>> Hälsningar/Regards/Grüsse, >>> P.O. Jonsson >>> oor...@jonases.se <mailto:oor...@jonases.se> >>> >>> >>> >>>> On 10. May 2023, at 14:21, Franz Marx >>> <mailto:marx.fr...@gmail.com>> wrote: >>>> >>>> Hi P.O. Jonsson! >>>> >>>> Thank you very much for your detailed description, I will now try to >>>> install release 5.1.0 Beta, >>>> as you suggest. >>>> One explanation from me, why i like to use SuSE: >>>> it`s because i had already experience making SuSE SLES Installations >>>> productive >>>> on PC's in the 2010's and also on IBM zSeries (and it comes from Europe!) >>>> before I retired. >>>> >>>> Yours sincerely >>>> Franz Marx >>>> >>>> >>>> ooRexx mailto:oor...@jonases.se>> schrieb am Mi., 10. >>>> Mai 2023, 12:04: >>>> Hi Franz, >>>> >>>> Nice to hear that you want to try out ooRexx! >>>> >>>> Indeed the package for OpenSuse (and all other packages I think) is >>>> unsigned so you would need to ignore the warning when it arrives. The >>>> steps would be (assuming the installer is in
Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer
Coming back to how to prepare a release: After what Rick wrote I have looked at the structure in the SVN tree. It seems a twig in main/branches is used to populate main/releases. Example: /main/branches/4.1 has been used as the base for 4.1.0, 4.1.1, 4.1.2 and 4.1.3 releases in /main/releases /main/branches/4.2 has been used as the base for 4.2.0 release in /main/releases /main/branches/old-4.3 seems never to have reached a release status So the steps in a release should be to (i) copy a release candidate from trunk to /main/branches/m.n (ii) when it has been confirmed that the release candidate is a good one AND all the necessary changes have been made /main/branches/m.n ONLY THEN is the release candidate copied to /main/releases This provides the advantage that if we decide that we need to select another release candidate this is not a problem, we just replace the old one with a new one in /main/branches/m.n. There is also sufficient time to try out uploads and amending scripts before it becomes visible to the public. Does this make sense to all? Applied to 5.0.0 we need to copy the 5.0.0 release back to /main/branches/5.0 (not 5.0.0 or 5.0.1) and use it for preparing the next bug fix release. THEN, when there is time for 5.1.0 in the distant future we copy trunk to main/branches/5.1 and so on. Looking at the “release rate” for ooRexx 4 the minor bug fix releases have been 3 months to 1.5 year in-between, I interpret this as on a need-to-fix time basis. The major releases have been between 9 months to 2 years (longer time between the later releases). I have also looked at the documents that need revising I will put that into release-steps.md I have no knowledge on how to move/copy entire branches of the SVN tree, are there any volunteers out there? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 10. May 2023, at 22:50, ooRexx wrote: > > >> On 10. May 2023, at 20:37, Gilbert Barmwater > <mailto:gi...@bellsouth.net>> wrote: >> >> On 5/10/2023 1:27 PM, Rick McGuire wrote: >>> >>> >>> On Wed, May 10, 2023 at 12:22 PM ooRexx >> <mailto:oor...@jonases.se>> wrote: >>> I am sorry but I have to come back to this item: >>> >>>>>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? >>>>>> >>>>>> That indicates which release the change is going to ship on. Since the >>>>>> 5.0.0 has already been released, that should never be used again. 5.0.1 >>>>>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0 >>>>>> release will contain new content, as well as bug fixes to 5.0.0 content. >>>>>> Bug fixes like this one should be applied to both the trunk and the >>>>>> 5.0.1 branch and the 5.0.1 milestone used. >>>>>> >>> >>> Currently we do not have a 5.0.1 branch in SVN, so it is not possible to >>> commit anything specifically to 5.0.1; all go into trunk which is then >>> uploaded to 5.1.0beta on sourceforge. >>> Sigh, it looks like an important item got deleted from the release process >>> check list. I know I highlighted this when we were starting up. At the >>> point where the release candidate gets moved from branches to releases, a >>> copy should have been made in branches with the fix level incremented (e.g. >>> 5.0.0 -> 5.0.1). That branch also gets the changes made to change the build >>> number to the matching level. The only updates allowed to that branch are >>> big fixes we wish to ship in a bug-fix release. No new features can be >>> added to this branch. It would be nice if bug fixes get applied to both >>> trunk and the bug fix branch at the same time, but it is not necessary. If >>> we choose to ship a bug-fix release, we can review all of the pending bugs >>> in trunk and apply the changes to the bug-fix branch as part of the release >>> process. >> It seems to me that we should immediately correct this omission and create a >> 5.0.1 branch. I will let others decide if it should be >> ...main/releases/5.0.1 or ...main/releases/5.0.1/trunk. It should be copied >> from ...main/releases/5.0.0 and the necessary changes made to reflect that >> the build number is 5.0.1. (Perhaps it needs to be in /branches until it is >> ready for release?) Then we need to review all the bug fixes in 5.1.0 and >> apply them to 5.0.1. As far as deciding to do a 5.0.1 release goes, I feel >> that there are some significant things that have been fixed that this is >> warranted. And it allows us to "correct" the missing pieces in 5.0.0 i
Re: [Oorexx-devel] Please help: how can i configure Open Object Rexx 5.1 in OpenSuse Leap 15.4
Hi, I am not sure I understand the question. Once you have installed ooRexx it should work out of the box, there is nothing to configure on the ooRexx side, you just call it with rexx myprogram.rex, you can leave out the extension so rexx myprogram suffices. Similar to how you call a Python program. Be aware that there are no GUI features for any other implementation than Windows (ooDialog), it is all done on the command line for all the Linuxes and in macOS. If you mean that you want to be able to “click” the program to start it from a Graphical interface you could try to change the rules for how a certain extension is handled in OpenSuse as explained here <https://forums.opensuse.org/t/how-to-set-default-open-with-program/25227>, but I am no expert in how this works out you will have to figure that out yourself. Hope it helps. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 12. May 2023, at 13:39, Franz Marx wrote: > > Hi, Mr. Jonson! > First of all: the Installation worked with your detailed advice, of course! > > But One thing I still miss: > how can I configure the Open Rexx Version 5.1.0 within OpenSuse Leap 15.4 ? > Like in Windows, my *.rex program should be executed immediately. > i am sorry to be such inexperienced to bore you with this question 蘿 > I only find Rexxtry within the App-Listing (that works, of course) > > regards > Franz > > Am Mi., 10. Mai 2023 um 15:25 Uhr schrieb ooRexx <mailto:oor...@jonases.se>>: > Hi, > > Suse is one of the most unproblematic/stable platforms for ooRexx, I have > hardly ever seen a problem in the testing so go ahead and do not hesitate to > report back any problem you find (I bet one bottle of beer that you won’t > find any :-) ) > > Try to ignore the “Beta” in the name of the rolling release, it is solid as a > rock in my experience. Since 5.0.0 was so long in the coming, a number of > minor things were missed out in the release, mostly in the documentation > area. All those things are ironed out in 5.1.0. Installation procedure is > exactly the same. Good luck. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > >> On 10. May 2023, at 14:21, Franz Marx > <mailto:marx.fr...@gmail.com>> wrote: >> >> Hi P.O. Jonsson! >> >> Thank you very much for your detailed description, I will now try to install >> release 5.1.0 Beta, >> as you suggest. >> One explanation from me, why i like to use SuSE: >> it`s because i had already experience making SuSE SLES Installations >> productive >> on PC's in the 2010's and also on IBM zSeries (and it comes from Europe!) >> before I retired. >> >> Yours sincerely >> Franz Marx >> >> >> ooRexx mailto:oor...@jonases.se>> schrieb am Mi., 10. >> Mai 2023, 12:04: >> Hi Franz, >> >> Nice to hear that you want to try out ooRexx! >> >> Indeed the package for OpenSuse (and all other packages I think) is unsigned >> so you would need to ignore the warning when it arrives. The steps would be >> (assuming the installer is in Downloads): >> >> noob:~/Downloads> sudo zypper install >> ooRexx-5.0.0-12583.opensuse15.x86_64.rpm >> [sudo] password for root: >> Loading repository data... >> Warning: Repository 'Update repository of openSUSE Backports' appears to be >> outdated. Consider using a different mirror or server. >> Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. >> Consider using a different mirror or server. >> Reading installed packages... >> Resolving package dependencies... >> >> The following NEW package is going to be installed: >> ooRexx >> >> 1 new package to install. >> Overall download size: 1.0 MiB. Already cached: 0 B. After the operation, >> additional 6.6 MiB will be used. >> Continue? [y/n/v/...? shows all options] (y): y >> Retrieving package ooRexx-5.0.0-12583.x86_64 >>(1/1), 1.0 MiB ( 6.6 MiB >> unpacked) >> ooRexx-5.0.0-12583.opensuse15.x86_64.rpm: >> Package header is not signed! >> >> ooRexx-5.0.0-12583.x86_64 (Plain RPM files cache): Signature verification >> failed [6-File is unsigned] >> Abort, retry, ignore? [a/r/i] (a): i >> >> After that it should work. >> >> To uninstall it use >> >> sudo zypper remove ooRexx >> >> (Note: there is a minor bug here, the name of the installed package should >> be oorexx to follow convention this is fixed in the running release >> 5.1.0Beta) >> >&
Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer
> On 10. May 2023, at 20:37, Gilbert Barmwater wrote: > > On 5/10/2023 1:27 PM, Rick McGuire wrote: >> >> >> On Wed, May 10, 2023 at 12:22 PM ooRexx > <mailto:oor...@jonases.se>> wrote: >> I am sorry but I have to come back to this item: >> >>>>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? >>>>> >>>>> That indicates which release the change is going to ship on. Since the >>>>> 5.0.0 has already been released, that should never be used again. 5.0.1 >>>>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0 >>>>> release will contain new content, as well as bug fixes to 5.0.0 content. >>>>> Bug fixes like this one should be applied to both the trunk and the 5.0.1 >>>>> branch and the 5.0.1 milestone used. >>>>> >> >> Currently we do not have a 5.0.1 branch in SVN, so it is not possible to >> commit anything specifically to 5.0.1; all go into trunk which is then >> uploaded to 5.1.0beta on sourceforge. >> Sigh, it looks like an important item got deleted from the release process >> check list. I know I highlighted this when we were starting up. At the point >> where the release candidate gets moved from branches to releases, a copy >> should have been made in branches with the fix level incremented (e.g. 5.0.0 >> -> 5.0.1). That branch also gets the changes made to change the build number >> to the matching level. The only updates allowed to that branch are big fixes >> we wish to ship in a bug-fix release. No new features can be added to this >> branch. It would be nice if bug fixes get applied to both trunk and the bug >> fix branch at the same time, but it is not necessary. If we choose to ship a >> bug-fix release, we can review all of the pending bugs in trunk and apply >> the changes to the bug-fix branch as part of the release process. > It seems to me that we should immediately correct this omission and create a > 5.0.1 branch. I will let others decide if it should be > ...main/releases/5.0.1 or ...main/releases/5.0.1/trunk. It should be copied > from ...main/releases/5.0.0 and the necessary changes made to reflect that > the build number is 5.0.1. (Perhaps it needs to be in /branches until it is > ready for release?) Then we need to review all the bug fixes in 5.1.0 and > apply them to 5.0.1. As far as deciding to do a 5.0.1 release goes, I feel > that there are some significant things that have been fixed that this is > warranted. And it allows us to "correct" the missing pieces in 5.0.0 in a > "clean" way as well. > > Gil > I agree that the 5.0.1 should be created, now when I know how it was intended but we should at the same time agree on who does what. I can agree to take care of Jenkins and the changes necessary to the build system but I will not be able or willing to do any kind of SVN branching off, I would feel safer if Rick and/or Erich agree to take on that part. I will then go through all the things I have found so far and apply them in both places and I expect all others to do the same with “their” bugs. I guess one would need to keep 2 separate local SVN repositories then. Before any attempt is made at a new release I need to sort out what went wrong the last time and find a way to automate the transition. I have some ideas, when they are ready I will put them in the document Rick set up. There is like a zillion things to change so the only way to do it is to automate it. /P.O. >> >> >> >> Are you saying that we should have branched off a 5.0.1 from 5.0.0? Where >> should it have gone? Into >> svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1? >> <http://svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1?> >> >> I also looked at the revisions of all the twigs of .../oorexx/code-0/main/ >> and it seems that although we froze 5.0.0 on revision 12583 there are >> commits up to revision 12601, unclear how that can happen. >> >> 5.0.0 was branched off as <…>main/releases/5.0.0 whereas 4.2 and before were >> branched off as <…>main/releases/4.2.0/trunk, is this significant in any way? >> >> That was a mistake really. It just reflected how/where the copy was made >> from. >> >> >> Can all changes (5.0.1 and 5.1.0) stay in trunk? >> >> All changes should be made to trunk. As I mentioned earlier, it would be >> nice if they would also get applied to 5.0.1, but that can be sorted out >> when the decision is made to make a bug-fix release. >> >> Rick >> &g
Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer
I am sorry but I have to come back to this item: >>> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? >>> >>> That indicates which release the change is going to ship on. Since the >>> 5.0.0 has already been released, that should never be used again. 5.0.1 >>> would be a release that will contain only bug fixes to 5.0.0. The 5.1.0 >>> release will contain new content, as well as bug fixes to 5.0.0 content. >>> Bug fixes like this one should be applied to both the trunk and the 5.0.1 >>> branch and the 5.0.1 milestone used. >>> Currently we do not have a 5.0.1 branch in SVN, so it is not possible to commit anything specifically to 5.0.1; all go into trunk which is then uploaded to 5.1.0beta on sourceforge. Are you saying that we should have branched off a 5.0.1 from 5.0.0? Where should it have gone? Into svn.code.sf.net/p/oorexx/code-0/main/branches/5.0.1? I also looked at the revisions of all the twigs of .../oorexx/code-0/main/ and it seems that although we froze 5.0.0 on revision 12583 there are commits up to revision 12601, unclear how that can happen. 5.0.0 was branched off as <…>main/releases/5.0.0 whereas 4.2 and before were branched off as <…>main/releases/4.2.0/trunk, is this significant in any way? Can all changes (5.0.1 and 5.1.0) stay in trunk? > 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
Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer
Just one more question and I be gone: re #1895 <https://sourceforge.net/p/oorexx/bugs/1895/> and the fact that 4 (vital) files are missing on sourceforge in the files/oorexx/5.0.0 section ReadMe.txt ReleaseNotes INSTALL.txt CHANGES.txt Since we cannot modify them for 5.0.0 should we (i) upload them as-is from r12583 or (ii) just ignore them until the next release. my preferred option would be (i) since they still contain useful albeit not always up-to-date information. I have started to update these files as far as I can but that will be for 5.0.1 or 5.1.0 Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 10. May 2023, at 11:45, Rick McGuire wrote: > > > > On Wed, May 10, 2023 at 5:33 AM ooRexx <mailto:oor...@jonases.se>> wrote: > >> On 10. May 2023, at 11:16, Rick McGuire > <mailto:object.r...@gmail.com>> wrote: >> >> >> >> On Wed, May 10, 2023 at 3:51 AM ooRexx > <mailto:oor...@jonases.se>> wrote: >> I added the missing softlink so that Windows users can find rxsock.pdf, Is >> this the right way to do it on sourceforge? >> >> The status “Closed” is only set when there is a release version, right? >> >> When shall the status “Pending” be used? >> >> Pending should be used until the change is available in a shipped release. >> That allows us to determine what changes are actually in a release. Closed >> should never be used until a release containing the change has shipped. >> >> >> What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? >> >> That indicates which release the change is going to ship on. Since the 5.0.0 >> has already been released, that should never be used again. 5.0.1 would be a >> release that will contain only bug fixes to 5.0.0. The 5.1.0 release will >> contain new content, as well as bug fixes to 5.0.0 content. Bug fixes like >> this one should be applied to both the trunk and the 5.0.1 branch and the >> 5.0.1 milestone used. >> >> >> This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is >> still missing it. Is it ok to go in and make a retrospective build for 5.0.0 >> and correct it manually? >> >> No, it is not ok. Once 5.0.0 has shipped, no changes to that tree are >> permitted. Fixes can only be released by spinning a 5.0.1 release. >> >> > > Thanks for the info, makes sense. But unfortunately most people will be using > 5.0.0 rather than the rolling release so they will miss out on things like > this. I guess we need to start thinking about a 5.0.1 then. > We don't ship a new bug-fix release every time there's a change. This should > wait until we have a significant number of them or there's a bug that impacts > a lot of users. This is nowhere near that level. > > > I will change the milestone for #1894 and #1875 to 5.0.1 then. > > Re #1854 it is still ok to add missing files, like the source files to 5.0.0 ? > > I think it's ok to upload the source file archive to sourceforge and label it > 5.0.0, but any changes (e.g. CmakeList changes) only get applied to the > appropriate branches. > > > > /P.O. > >> >> Any information on how the bug tracker should be used is welcome. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> Begin forwarded message: >>> >>> From: "Per Olov Jonsson" >> <mailto:perolovjons...@users.sourceforge.net>> >>> Subject: [oorexx:bugs] #1897 Entry missing in Windows installer >>> Date: 10. May 2023 at 09:02:55 CEST >>> To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net >>> <mailto:1...@bugs.oorexx.p.re.sourceforge.net>> >>> Reply-To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net >>> <mailto:1...@bugs.oorexx.p.re.sourceforge.net>> >>> >>> - **status**: open --> accepted >>> - **assigned_to**: Per Olov Jonsson >>> - **Comment**: >>> >>> Fixed with r12676 >>> >>> >>> >>> --- >>> >>> **[bugs:#1897] Entry missing in Windows installer** >>> >>> **Status:** accepted >>> **Group:** None >>> **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson >>> **Last Updated:** Sun May 07, 2023 08:15 PM UTC >>> **Owner:** Per Olov Jonsson >>> >>> >>> For Windows there is no entry referring to rxSock.cls documentation in the >>>
Re: [Oorexx-devel] Please help: how can i install Open Object Rexx 5.0 into OpenSuse Leap 15.4
Hi, Suse is one of the most unproblematic/stable platforms for ooRexx, I have hardly ever seen a problem in the testing so go ahead and do not hesitate to report back any problem you find (I bet one bottle of beer that you won’t find any :-) ) Try to ignore the “Beta” in the name of the rolling release, it is solid as a rock in my experience. Since 5.0.0 was so long in the coming, a number of minor things were missed out in the release, mostly in the documentation area. All those things are ironed out in 5.1.0. Installation procedure is exactly the same. Good luck. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 10. May 2023, at 14:21, Franz Marx wrote: > > Hi P.O. Jonsson! > > Thank you very much for your detailed description, I will now try to install > release 5.1.0 Beta, > as you suggest. > One explanation from me, why i like to use SuSE: > it`s because i had already experience making SuSE SLES Installations > productive > on PC's in the 2010's and also on IBM zSeries (and it comes from Europe!) > before I retired. > > Yours sincerely > Franz Marx > > > ooRexx mailto:oor...@jonases.se>> schrieb am Mi., 10. Mai > 2023, 12:04: > Hi Franz, > > Nice to hear that you want to try out ooRexx! > > Indeed the package for OpenSuse (and all other packages I think) is unsigned > so you would need to ignore the warning when it arrives. The steps would be > (assuming the installer is in Downloads): > > noob:~/Downloads> sudo zypper install ooRexx-5.0.0-12583.opensuse15.x86_64.rpm > [sudo] password for root: > Loading repository data... > Warning: Repository 'Update repository of openSUSE Backports' appears to be > outdated. Consider using a different mirror or server. > Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. > Consider using a different mirror or server. > Reading installed packages... > Resolving package dependencies... > > The following NEW package is going to be installed: > ooRexx > > 1 new package to install. > Overall download size: 1.0 MiB. Already cached: 0 B. After the operation, > additional 6.6 MiB will be used. > Continue? [y/n/v/...? shows all options] (y): y > Retrieving package ooRexx-5.0.0-12583.x86_64 > (1/1), 1.0 MiB ( 6.6 MiB > unpacked) > ooRexx-5.0.0-12583.opensuse15.x86_64.rpm: > Package header is not signed! > > ooRexx-5.0.0-12583.x86_64 (Plain RPM files cache): Signature verification > failed [6-File is unsigned] > Abort, retry, ignore? [a/r/i] (a): i > > After that it should work. > > To uninstall it use > > sudo zypper remove ooRexx > > (Note: there is a minor bug here, the name of the installed package should be > oorexx to follow convention this is fixed in the running release 5.1.0Beta) > > Good luck. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > >> On 10. May 2023, at 11:05, Franz Marx > <mailto:marx.fr...@gmail.com>> wrote: >> >> To the team of oorexx-devel@lists.sourceforge.net >> <mailto:oorexx-devel@lists.sourceforge.net>> >> >> I already installed the new Open Rexx Version 5.0 on my Windows 10 >> Acer-Laptop. >> I am very pleased and satisfied with the performance of this version. >> I have an older HP-Laptop with dual boot Windows 10 and OpenSuse Leap 15.4. >> Calculating 4 Million Primes with my Rexx-Program using Windows 10 it tooks >> on the ACER-Laptop: 5639 secs. - on my HP-Laptop : 8983 secs., >> as you can see in my 2 attachments. >> >> Now I wish to see the Rexx-Performance running under OpenSuse Leap 15.4. >> >> With the OpenSuse Installation all Apps run very fine (like >> Libre-Officewith, Chrome, >> VLC, etc. etc.), the only exception i got when i was trying to install >> OORexx 5.0! >> I failed with the installation of Open Object Rexx Version 5.0. with the >> install-message >> "Checksum-Error" when I tried to install from your RPM-Package. >> Can you give me some advice on how the installation will succeed? >> >> Yours sincerely >> Franz Marx >> Bahngasse 19 >> 2391 Kaltenleutgeben >> Austria >> ___ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> > > ___ > Oorexx-devel mailing list >
Re: [Oorexx-devel] Please help: how can i install Open Object Rexx 5.0 into OpenSuse Leap 15.4
Hi Franz, Nice to hear that you want to try out ooRexx! Indeed the package for OpenSuse (and all other packages I think) is unsigned so you would need to ignore the warning when it arrives. The steps would be (assuming the installer is in Downloads): noob:~/Downloads> sudo zypper install ooRexx-5.0.0-12583.opensuse15.x86_64.rpm [sudo] password for root: Loading repository data... Warning: Repository 'Update repository of openSUSE Backports' appears to be outdated. Consider using a different mirror or server. Warning: Repository 'Update Repository (Non-Oss)' appears to be outdated. Consider using a different mirror or server. Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: ooRexx 1 new package to install. Overall download size: 1.0 MiB. Already cached: 0 B. After the operation, additional 6.6 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package ooRexx-5.0.0-12583.x86_64 (1/1), 1.0 MiB ( 6.6 MiB unpacked) ooRexx-5.0.0-12583.opensuse15.x86_64.rpm: Package header is not signed! ooRexx-5.0.0-12583.x86_64 (Plain RPM files cache): Signature verification failed [6-File is unsigned] Abort, retry, ignore? [a/r/i] (a): i After that it should work. To uninstall it use sudo zypper remove ooRexx (Note: there is a minor bug here, the name of the installed package should be oorexx to follow convention this is fixed in the running release 5.1.0Beta) Good luck. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 10. May 2023, at 11:05, Franz Marx wrote: > > To the team of oorexx-devel@lists.sourceforge.net > <mailto:oorexx-devel@lists.sourceforge.net>> > > I already installed the new Open Rexx Version 5.0 on my Windows 10 > Acer-Laptop. > I am very pleased and satisfied with the performance of this version. > I have an older HP-Laptop with dual boot Windows 10 and OpenSuse Leap 15.4. > Calculating 4 Million Primes with my Rexx-Program using Windows 10 it tooks > on the ACER-Laptop: 5639 secs. - on my HP-Laptop : 8983 secs., > as you can see in my 2 attachments. > > Now I wish to see the Rexx-Performance running under OpenSuse Leap 15.4. > > With the OpenSuse Installation all Apps run very fine (like > Libre-Officewith, Chrome, > VLC, etc. etc.), the only exception i got when i was trying to install OORexx > 5.0! > I failed with the installation of Open Object Rexx Version 5.0. with the > install-message > "Checksum-Error" when I tried to install from your RPM-Package. > Can you give me some advice on how the installation will succeed? > > Yours sincerely > Franz Marx > Bahngasse 19 > 2391 Kaltenleutgeben > Austria > ___ > 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
Re: [Oorexx-devel] [oorexx:bugs] #1897 Entry missing in Windows installer
> On 10. May 2023, at 11:16, Rick McGuire wrote: > > > > On Wed, May 10, 2023 at 3:51 AM ooRexx <mailto:oor...@jonases.se>> wrote: > I added the missing softlink so that Windows users can find rxsock.pdf, Is > this the right way to do it on sourceforge? > > The status “Closed” is only set when there is a release version, right? > > When shall the status “Pending” be used? > > Pending should be used until the change is available in a shipped release. > That allows us to determine what changes are actually in a release. Closed > should never be used until a release containing the change has shipped. > > > What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? > > That indicates which release the change is going to ship on. Since the 5.0.0 > has already been released, that should never be used again. 5.0.1 would be a > release that will contain only bug fixes to 5.0.0. The 5.1.0 release will > contain new content, as well as bug fixes to 5.0.0 content. Bug fixes like > this one should be applied to both the trunk and the 5.0.1 branch and the > 5.0.1 milestone used. > > > This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is > still missing it. Is it ok to go in and make a retrospective build for 5.0.0 > and correct it manually? > > No, it is not ok. Once 5.0.0 has shipped, no changes to that tree are > permitted. Fixes can only be released by spinning a 5.0.1 release. > > Thanks for the info, makes sense. But unfortunately most people will be using 5.0.0 rather than the rolling release so they will miss out on things like this. I guess we need to start thinking about a 5.0.1 then. I will change the milestone for #1894 and #1875 to 5.0.1 then. Re #1854 it is still ok to add missing files, like the source files to 5.0.0 ? /P.O. > > Any information on how the bug tracker should be used is welcome. > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se <mailto:oor...@jonases.se> > > > >> Begin forwarded message: >> >> From: "Per Olov Jonsson" > <mailto:perolovjons...@users.sourceforge.net>> >> Subject: [oorexx:bugs] #1897 Entry missing in Windows installer >> Date: 10. May 2023 at 09:02:55 CEST >> To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net >> <mailto:1...@bugs.oorexx.p.re.sourceforge.net>> >> Reply-To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net >> <mailto:1...@bugs.oorexx.p.re.sourceforge.net>> >> >> - **status**: open --> accepted >> - **assigned_to**: Per Olov Jonsson >> - **Comment**: >> >> Fixed with r12676 >> >> >> >> --- >> >> **[bugs:#1897] Entry missing in Windows installer** >> >> **Status:** accepted >> **Group:** None >> **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson >> **Last Updated:** Sun May 07, 2023 08:15 PM UTC >> **Owner:** Per Olov Jonsson >> >> >> For Windows there is no entry referring to rxSock.cls documentation in the >> Documentation folder in the ooRexx startup menu item. RxSock.pdf exists but >> the Windows user may not be aware of its existence since it is not in the >> list of links in the Start Menu item for ooRexx. >> >> What is missing is a softlink with an appropriate name >> >> from >> >> C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Open Object >> Rexx\Documentation >> >> to >> >> C:\Program Files\ooRexx\doc\rxsock.pdf >> >> >> --- >> >> Sent from sourceforge.net <http://sourceforge.net/> because you indicated >> interest in <https://sourceforge.net/p/oorexx/bugs/1897/ >> <https://sourceforge.net/p/oorexx/bugs/1897/>> >> >> >> >> To unsubscribe from further messages, please visit >> <https://sourceforge.net/auth/subscriptions/ >> <https://sourceforge.net/auth/subscriptions/>> > > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Fwd: [oorexx:bugs] #1897 Entry missing in Windows installer
I added the missing softlink so that Windows users can find rxsock.pdf, Is this the right way to do it on sourceforge? The status “Closed” is only set when there is a release version, right? When shall the status “Pending” be used? What is the difference between the milestones 5.0.0, 5.0.1 and 5.1.0? This fix solved the problem for 5.1.0Beta but the installer for 5.0.0 is still missing it. Is it ok to go in and make a retrospective build for 5.0.0 and correct it manually? Any information on how the bug tracker should be used is welcome. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Begin forwarded message: > > From: "Per Olov Jonsson" > Subject: [oorexx:bugs] #1897 Entry missing in Windows installer > Date: 10. May 2023 at 09:02:55 CEST > To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net> > Reply-To: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net> > > - **status**: open --> accepted > - **assigned_to**: Per Olov Jonsson > - **Comment**: > > Fixed with r12676 > > > > --- > > **[bugs:#1897] Entry missing in Windows installer** > > **Status:** accepted > **Group:** None > **Created:** Sun May 07, 2023 08:15 PM UTC by Per Olov Jonsson > **Last Updated:** Sun May 07, 2023 08:15 PM UTC > **Owner:** Per Olov Jonsson > > > For Windows there is no entry referring to rxSock.cls documentation in the > Documentation folder in the ooRexx startup menu item. RxSock.pdf exists but > the Windows user may not be aware of its existence since it is not in the > list of links in the Start Menu item for ooRexx. > > What is missing is a softlink with an appropriate name > > from > > C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Open Object > Rexx\Documentation > > to > > C:\Program Files\ooRexx\doc\rxsock.pdf > > > --- > > Sent from sourceforge.net because you indicated interest in > <https://sourceforge.net/p/oorexx/bugs/1897/> > > > > To unsubscribe from further messages, please visit > <https://sourceforge.net/auth/subscriptions/> ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] ooRexx 5.0.0 sources aligned to the 5.0.0 binaries
Dear Enrico, I am the only one working on this thing and I only have two hands. I am sure you are aware of the saying “many hands make the work easier” hence you are free to jump in and do the actual work. I have been busy with this the last 3 days, I did not expect that there would be so many hard-coded features and other problems that needed changing. I have done a source package for ooRexx 5.0.0 manually following (basically) your steps and uploaded it just now, I will ask that Mark have a go at testing it. There are no signatures added for now. FYI the automatic building of a source package fail since CMake adds a /usr/local/ to the package, before that is fixed the automatic building will fail. Feel free to scout for a solution to that problem. PS in the meantime a Pi burned its chip and I am rebuilding everything from source on that one, Then CMake decided it could not find SVN on the Mac and so the artifacts became broken and did not upload, I have moved the build to another platform. All these things take time. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 19. Apr 2023, at 17:09, Enrico Sorichetti via Oorexx-devel > wrote: > > > A long time ago I opened a ticket > > #1854 ooRexx 5.0.0 distribution files > the sources aligned to the binaries are missing in the 5.0.0 distribution > files folder > > And nobody cared to reply or take action > > To make things easier for some good soul willing to do the task > Here is the sequence of commands to do it > > > > Everything in my environment is anchored at $HOME/ooRexx > > cd $HOME/ooRexx > > Checkout the whole code-0 repository into > $HOME/ooRexx/ooRexx-code-0 > > ls -l $HOME/ooRexx/ooRexx-code-0/main/releases > you should find a 5.0.0 directory > > cp $HOME/ooRexx/ooRexx-code-0/main/releases/5.0.0 . > > mv 5.0.0 ooRexx-5.0.0-sources > > tar -cJf ooRexx-5.0.0-sources.txz ooRexx-5.0.0-sources > or > tar -cjf ooRexx-5.0.0-sources.tbz ooRexx-5.0.0-sources > or > zip … … … > > > Expand them to to check > diff -r -q ooRexx-5.0.0-sources ooRexx-5.0.0-sources > And if the diff tells nothing > > Create the checksums > shasum -a 256 -U ooRexx-5.0.0-sources.txz >ooRexx-5.0.0-sources.txz.asc > Repeat for all the compressed files you generated > > > Add the gpg signatures > gpg -s ooRexx-5.0.0-sources.txz > Repeat for all the compressed files you generated > > You will find for each compression type > > ooRexx-5.0.0-sources.txz > ooRexx-5.0.0-sources.txz.asc > ooRexx-5.0.0-sources.txz.gpg > > Verify that signatures checksums agree > gpg --verify ooRexx-5.0.0-sources.txz.gpg > shasum -c ooRexx-5.0.0-sources.txz.asc > > You can upload the tarred /zipped /whatever > The checksums and the signatures > > And then you are done > > > It took me longer to write this email than do it ! > > The checksum is needed for the home-brew formula > > But IMO at least the checksums should have been provided for ALL the > distribution files a long time ago > > Enjoy yourself > > Enrico > > > > > > > > > > > > > > > > > > > > _______ > 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
[Oorexx-devel] ooRexx 5.0.0 sources aligned to the 5.0.0 binaries
A long time ago I opened a ticket #1854 ooRexx 5.0.0 distribution files the sources aligned to the binaries are missing in the 5.0.0 distribution files folder And nobody cared to reply or take action To make things easier for some good soul willing to do the task Here is the sequence of commands to do it Everything in my environment is anchored at $HOME/ooRexx cd $HOME/ooRexx Checkout the whole code-0 repository into $HOME/ooRexx/ooRexx-code-0 ls -l $HOME/ooRexx/ooRexx-code-0/main/releases you should find a 5.0.0 directory cp $HOME/ooRexx/ooRexx-code-0/main/releases/5.0.0 . mv 5.0.0 ooRexx-5.0.0-sources tar -cJf ooRexx-5.0.0-sources.txz ooRexx-5.0.0-sources or tar -cjf ooRexx-5.0.0-sources.tbz ooRexx-5.0.0-sources or zip … … … Expand them to to check diff -r -q ooRexx-5.0.0-sources ooRexx-5.0.0-sources And if the diff tells nothing Create the checksums shasum -a 256 -U ooRexx-5.0.0-sources.txz >ooRexx-5.0.0-sources.txz.asc Repeat for all the compressed files you generated Add the gpg signatures gpg -s ooRexx-5.0.0-sources.txz Repeat for all the compressed files you generated You will find for each compression type ooRexx-5.0.0-sources.txz ooRexx-5.0.0-sources.txz.asc ooRexx-5.0.0-sources.txz.gpg Verify that signatures checksums agree gpg --verify ooRexx-5.0.0-sources.txz.gpg shasum -c ooRexx-5.0.0-sources.txz.asc You can upload the tarred /zipped /whatever The checksums and the signatures And then you are done It took me longer to write this email than do it ! The checksum is needed for the home-brew formula But IMO at least the checksums should have been provided for ALL the distribution files a long time ago Enjoy yourself Enrico ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Package name casing
Dear all Unfortunately too much has been said about the subject issue And more unfortunately it was just a … I think, I heard somewhere, somebody else said … Without having done the due diligence I researched a bit and what I found is that … The casing rules are mandatory for the names of packages distrbuted automagically from the system repositories handled by the system package manager Generally they are all lower case, Fedora makes an exception for that, recognising the right for the owners(s) of SELECTED packages to use a name of their choice An example close to us Mike Cowlishaw’ s General Decimal Arithmetic package is distributed as decNumber-icu-368.zip Another example from my real life experience John Hauser’s Berkeley SoftFloat library conforming to IEEE Standard for Floating-Point Arithmetic is distributed as SoftFloat-3e.zip IMO - with the due respect - Mark Hessing request was due to a misunderstanding of the home-brew rules What has to be LOWER CASE is the the home-brew formula name … not the real package source name ( hidden inside the rb formula ) They suffer from OCD about the naming, they remarked quite a few times that the proper name is formula/( plural formulae) , not package For macports mixed case package names are accepted Anyway I feel that we should respect the brand/trademark name casing For Apple it should be macOS, NOT macos/macOSX/macosx , the distributables are mixed case also for the extra packages (They made a public announcement about changing the system name) Since I am an Apple user I had no need to research A quick and dirty research for other environments gave back For Debian the name should be Debian, the distributable are lower case ==> debian-11.6.0-arm64-netinst.iso For Fedora the name should be Fedora, the distributable are mixed case ==> Fedora-Workstation-38-1.6.aarch64.raw.xz And also found the manual https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/ <https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/> For CentOS the names are … CentOS and CentOS-Stream , the distributable are mixed case ==> CentOS-Stream-9-latest-aarch64-dvd1.iso For the standards CentOS refers to the Fedora manuals For FreeBSD the name is, guess what … FreeBSD, and the distributable are mixed case ==> FreeBSD-13.1-RELEASE-amd64-dvd1.iso.xz My best regards Enrico PS A quick and dirty search gave back that Fedora 36 provides an oorexx-4.2.0-3.x86_64.rpm in third party repository https://fedora.pkgs.org/36/rpm-sphere-x86_64 <https://fedora.pkgs.org/36/rpm-sphere-x86_64> And they even provide an aarch64 rpm Since the repository contains mixed case file names , maybe somebody from the RexxLA might want to ask them to use a proper name casing ( ooRexx ) ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] News on Raspberry Pi builds
Done. Tested them and all tests pass with the installed versions so they should be ok now. As a boon I included the (5.0.0) documentation that we did not manage before Christmas. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 11. Apr 2023, at 09:23, Erich Steinböck wrote: > > Hi P.O., > yes, thanks, rebuild the broken installers. > _______ > 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
[Oorexx-devel] News on Raspberry Pi builds
As I reported earlier the installers for ooRexx 5.0.0 is broken for Raspberry P;, the /lib branch (and maybe more) is missing in the installed ooRexx. Running a simple rexx -v or just rexx will run and look perfectly normal but as soon as a library is loaded there will be a failure. Our testing missed this since we run the test from the latest build and not from an installed ooRexx (to be able to test also the native APIs). ooRexx can be "apt installed" or "apt removed" etc so on the surface it looks ok but in reality it is broken. That is the bad news. The god news is that thanks to Enrico I found out about the reason; apparently the culprit is the CMake that come with raspbianpios, it is to old/defect. I have rebuilt CMake from source on both 32 bit (armv7l) and 64 bit (aarch64) raspbianpios and confirmed that the installed versions of ooRexx passes all tests in the framework. As of at least r12668 it should be ok now for 5.1.0. At the same time I installed a GUI-less version of the 64 bit Raspbian since it crashed on some tests with a GUI (1 GB of memory is not sufficient to run a Gui+the test). What do we do about the 5.0.0 builds? I could do retrospective builds for 5.0.0 if there are no objections. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Problem with the ticker test
Hi Erich, thanks for trying but it is not sufficient to change the Ticker test group, all Windows VMs still hang the test after finalising. What seems to block execution is the Ticker built in to the test framework, the thingy that goes dot dot dot when the test cases executes. It also does not help to disable the ticks using the -u or -U switches. I am quite certain that the Ticker is on a separate thread (It can be seen in the task list with a different number) would it be possible to trace it using the amended trace that was discussed elsewhere? The change also caused an error in the native Windows (32 and 64 bit) testing, I hope you can see what causes the error from this output (the sysdrive error is probably a glitch) ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:REXX-ooRexx_5.1.0(MT)_32-bit 6.05 6 Apr 2023 OS Name:WindowsNT SysVersion: Windows 10.0.19045 Tests ran: 24152 Assertions: 375095 Failures: 1 Errors: 1 [failure] 20230407 00:53:09.998000 Test: TEST_DRIVES Class: SYSDRIVE.TESTGROUP File: ...\ooRexx\base\rexxutil\platform\windows\SysDrive.testGroup Line: 116 Failed: assertTrue Expected: 1 Actual: 0 Message: 445439692800, 445435510784, SysDriveInfo C: C: 445435510784 999074459648 Windows; test expected to sometimes fail with a small free space delta [error] 20230407 00:52:35.02 Test: TEST_TICKER_THREE_ARGS_STRING_TRIGGER_MESSAGE Class: Ticker.testGroup File: ...\ooRexx\base\class\Ticker.testGroup Event: SYNTAX 48.1 raised unexpectedly. Failure in system service: Ticker Stop SetEvent failure code 6. Program: REXX Line:177 *-* Compiled method "!STOPTIMER" with scope "Ticker". 1707 *-* Method CANCEL with scope "Ticker" in package "REXX" (no source available). 177 *-* ticker~cancel *-* Compiled method "SEND" with scope "Message". 1585 *-* .message~new(self, methodName)~send 1548 *-* self~doTheTest(fName, aTestResult) -- carry out the testmethod 552 *-* test~execute(testResult, verbose) 552 *-* test~execute(testResult, verbose) 110 *-* suite~execute(testResult) 79 *-* retCode = 'worker.rex'(arguments) Interpreter:REXX-ooRexx_5.1.0(MT)_32-bit 6.05 6 Apr 2023 OS Name:WindowsNT SysVersion: Windows 10.0.19045 Tests ran: 24152 Assertions: 375095 Failures: 1 Errors: 1 File search:00:00:05.017000 Suite construction: 00:00:00.722000 Test execution: 00:05:52.866000 Total time: 00:05:58.606000 jenkins@PO-XPC-FH97 C:\Users\jenkins\workspace\ooRexx-windows32-test>exit 2 Build step 'Execute Windows batch command' marked build as failure Finished: FAILURE Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 6. Apr 2023, at 19:13, Erich Steinböck wrote: > > I've fixed the Ticker test group to always cancel the Ticker instance even > when an assert fails. > This should fix the hangs. > ___ > 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
[Oorexx-devel] Problem with the ticker test
On Windows (and other platforms) we have the annoying case that the Ticker test misses a tick or two due to time jitter in the virtual machines, like here: [failure] 20230406 16:21:37.70 Test: TEST_TICKER_THREE_ARGS_STRING_TRIGGER Class: Ticker.testGroup File: ...\ooRexx\base\class\Ticker.testGroup Line: 117 Failed: assertTrue Expected: 1 Actual: 0 Message: should have triggered once, but triggered 0 times As a result the test suite hangs at the very last line, after completion of the test. The final result of all tests is there but there are three running dots at the bottom indicating the test is still running. I have set the tests to time out eventually but it would be nice if we could find a way to either kill a missing ticker (it is present in the task list; when killed manually the test suite finishes) or find a way to avoid that a ticker hangs indefinitively. Since this is most likely a problem with the test suite and not ooRexx itself I did not make it a bug report. It rarely happens on a physical machine, just when running in a VM. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Jenkins
Short info: The JSON.testGroup is failing on most *nixes, please have a look whoever wrote it (Rony?) The machine hosting all the VMs will be offline for a couple of days as of this evening while being moved. Also the documentation build will be unavailable a couple of days. Jenkins itself will continue to run and the Windows platform will be available for building but almost no *nixes. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Jenkins Heads-up
I failed to notice that the machine used for building the documentation was offline for some time. I have reconnected it and it will start to rebuild any changed documentation within an hour or so. This line seems to take ages to get past, seems to be a huge file. What is it? AoorexxdocSVN/tools/RailRoadDiagrams/rr-1.67-java8.zip Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] I think I've seen the future...
> Michael Lueck hat am 24.01.2023 17:08 > geschrieben: > parse value Zservice.0+1 THISinstance with THISinstanceID > Zservice.THISinstanceID =1 Zservice.0 . What is the '=' good for? parse value Zservice.0+1 THISinstance with THISinstanceID Zservice.THISinstanceID 1 Zservice.0 . works equally well!?! Greetings Walter ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Last Artifact for 5.0.0 built
> On 24. Jan 2023, at 12:44, Rony G. Flatscher wrote: > > P.O., > > this is *really* great, super! > > Just a question: would it be possible for you to also create the portable > versions for 5.0.0 for s390x (and all other platforms)? > > Rony - I anticipated your question and built the portable s390x for 5.0.0 already ;-) If no-one objects I can add a “portable” folder under 5.0.0 and make retrospective builds for the other platforms. Only snag is that I need to add oobuild.pdf to the documentation, we removed that requirement after build 12583 so it needs to be the there or the build fails. Will take some days though. > --- > > Ad failing test: that looks strange. If you repeat the tests, does it > re-occur? > It does occur every time, I tried a number of times and even rebuilt ooRexx to be sure. Since I did not see this issue on any other platform, in particular not on Ubuntu (16,20,22), I take it that it is a S390X implementation issue, not a ooRexx issue. I have no access to the machine myself so cannot try it out “in the flesh”. > Here the testmethod from test/trunk: > > ::method test_arg_three_invalid > self~expectSyntax((40.904, "DATE", 3, self~optionsArg3, "W")) -- DATE > argument 3 must be one of BDEFINOSTU; found "W" > call date , "Monday", "w" -- although a valid arg 1 format, w is invalid > for arg 3 > It reports (does not supply the wrong option "W" in the error message): > > File: .../ooRexx/base/bif/DATE.testGroup > Event: SYNTAX 40.904 raised unexpectedly. > DATE argument 3 must be one of BDEFINOSTU; found "". > Line:73 > Doing the same in rexxtry.rex session supplies the third argument as "W": > > REXX-ooRexx_5.1.0(MT)_64-bit 6.05 6 Jan 2023 > rexxtry.rex lets you interactively try REXX statements. > Each string is executed when you hit Enter. > Enter 'call tell' for a description of the features. > Go on - try a few...Enter 'exit' to end. > say date( , "Monday", "w") > Oooops ! ... try again. Incorrect call to routine. > DATE argument 3 must be one of BDEFINOSTU; > found "W". > rc = 40.904 ... rexxtry.rex on WindowsNT > ---rony > > > > On 23.01.2023 23:15, ooRexx wrote: >> The IBMZ Agent (René's IBM LinuxONE Rockhopper with Ubuntu 18.04.5) was >> available again temporarily so I took the opportunity to make a retrospekive >> build for 5.0.0: >> ooRexx-5.0.0-12583.ubuntu1804.s390x.deb >> >> I have also built for the latest 5.1.0 these items: >> ooRexx-5.1.0-12625.ubuntu1804.s390x.deb >> ooRexx-5.1.0-12625.ubuntu1804.s390x-portable-release-runtime.zip >> ooRexx-5.1.0-12625.ubuntu1804.s390x-portable-release.zip >> >> If there is someone that have a "Rockhopper" to test these build on it would >> be great ;-) but otherwise I think we can retire this machine now. >> >> There is one test failing on this machine, I do not think it is serious but >> here the error message: >> >> >> ooTest Framework - Automated Test of the ooRexx Interpreter >> >> Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 23 Jan 2023 >> OS Name:LINUX >> SysVersion: Linux 4.15.0-192-generic >> >> Tests ran: 23886 >> Assertions: 385056 >> Failures: 0 >> Errors: 1 >> >> [error] 20230123 23:06:33.925104 >> Test: TEST_ARG_THREE_INVALID >> Class: DATE.TESTGROUP >> File: .../ooRexx/base/bif/DATE.testGroup >> Event: SYNTAX 40.904 raised unexpectedly. >> DATE argument 3 must be one of BDEFINOSTU; found "". >> Line:73 >> 73 *-* call date , "Monday", "w" -- although a valid arg 1 format, w is >> invalid for arg 3 >>*-* Compiled method "SEND" with scope "Message". >> 1585 *-* .message~new(self, methodName)~send >> 1548 *-* self~doTheTest(fName, aTestResult) -- carry out the testmethod >>552 *-* test~execute(testResult, verbose) >> 552 *-* test~execute(testResult, verbose) >>110 *-* suite~execute(testResult) >> 79 *-* retCode = 'worker.rex'(arguments) >> >> File search:00:00:01.376916 >> Suite construction: 00:00:01.392819 >> Test execution: 00:06:50.382749 >> Total time: 00:06:53.153066 >> >> Build step 'Execute shell' marked build as failure >> Finished: FAILURE >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> > > ___ > 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
[Oorexx-devel] Last Artifact for 5.0.0 built
The IBMZ Agent (René's IBM LinuxONE Rockhopper with Ubuntu 18.04.5) was available again temporarily so I took the opportunity to make a retrospekive build for 5.0.0: ooRexx-5.0.0-12583.ubuntu1804.s390x.deb I have also built for the latest 5.1.0 these items: ooRexx-5.1.0-12625.ubuntu1804.s390x.deb ooRexx-5.1.0-12625.ubuntu1804.s390x-portable-release-runtime.zip ooRexx-5.1.0-12625.ubuntu1804.s390x-portable-release.zip If there is someone that have a "Rockhopper" to test these build on it would be great ;-) but otherwise I think we can retire this machine now. There is one test failing on this machine, I do not think it is serious but here the error message: ooTest Framework - Automated Test of the ooRexx Interpreter Interpreter:REXX-ooRexx_5.1.0(MT)_64-bit 6.05 23 Jan 2023 OS Name:LINUX SysVersion: Linux 4.15.0-192-generic Tests ran: 23886 Assertions: 385056 Failures: 0 Errors: 1 [error] 20230123 23:06:33.925104 Test: TEST_ARG_THREE_INVALID Class: DATE.TESTGROUP File: .../ooRexx/base/bif/DATE.testGroup Event: SYNTAX 40.904 raised unexpectedly. DATE argument 3 must be one of BDEFINOSTU; found "". Line:73 73 *-* call date , "Monday", "w" -- although a valid arg 1 format, w is invalid for arg 3 *-* Compiled method "SEND" with scope "Message". 1585 *-* .message~new(self, methodName)~send 1548 *-* self~doTheTest(fName, aTestResult) -- carry out the testmethod 552 *-* test~execute(testResult, verbose) 552 *-* test~execute(testResult, verbose) 110 *-* suite~execute(testResult) 79 *-* retCode = 'worker.rex'(arguments) File search:00:00:01.376916 Suite construction: 00:00:01.392819 Test execution: 00:06:50.382749 Total time: 00:06:53.153066 Build step 'Execute shell' marked build as failure Finished: FAILURE Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se _______ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Ad Commons_Content directory (Re: More info on Jenkins
Hi Gil and thanks for the info. This is not my problem then since I require the
user to install the tools beforehand.
On my own Mac (where also the official doc build is running) I have fop 2.8, on
macOS I just do a brew update - brew upgrade every now and then.
The risk is, ofcourse, that I might break something with a new version, so far
it did not happen though.
For Linux I need to work myself back into how it actually works, again. Pain.
But for Manãna :-)
I sorted my tools out and made sure they were up to date btw.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> On 4. Jan 2023, at 17:57, Gilbert Barmwater wrote:
>
> Hi P.O.,
>
> So the problem with the FOP toolset is that it is an active project so the
> website changes periodically. That includes the level - it is now 2.8 - and
> the mirror sites from which you can download it. I had originally "hard
> coded" both the level and the mirror site in setup.rex. However, as soon as
> the next level of FOP came out, the level I had hard coded was not found
> (they move it to an archive site). So I changed the code to "get" the Web
> page - you could use cURL for example - where the current level was listed
> and used that value in place of what I had hard coded. Now I need to "get"
> the page where the recommended mirror site is listed and use that value in
> place of the hard coded value. HTH,
>
> Gil
>
> On 1/4/2023 2:51 AM, P.O. Jonsson wrote:
>> Dear Gil,
>>
>> Can you share some info on the non-existent FOP mirror? I have a similar
>> problem with using my docbuild tools on Ubuntu, they used to work but when I
>> retry them now they do not work. Could be the same problem.
>>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se <mailto:oor...@jonases.se>
>>
>>
>>
>>
>>> Am 03.01.2023 um 23:04 schrieb Gilbert Barmwater >> <mailto:gi...@bellsouth.net>>:
>>>
>>> Thanks for catching this Rony! I will investigate as I have time along
>>> with the problem with setup.rex on Windows using a non-existent FOP mirror.
>>>
>>> Gil
>>>
>>> On 1/3/2023 12:32 PM, Rony G. Flatscher wrote:
>>>> On 03.01.2023 15:00, Gilbert Barmwater wrote:
>>>>
>>>>> While being there we should also consider to rename the directory
>>>>> "docs/trunk/oorexx" to "docs/trunk/Common_Content" as it gets used for
>>>>> all books. After doing so, we should also consider to change all the
>>>>> xml-files that refer to "Common_Content" to refer relatively to it which
>>>>> would allow us to forgo copying "oorexx\en-US" into all
>>>>> "books\en-US\Common_Content".
>>>>> -1
>>>>>
>>>>> This would "break" the Publican tools and, IMHO, does not provide any
>>>>> real benefit as the "copying" step is only done during the "docprep"
>>>>> stage, once per document and, as the file is very small, does not impose
>>>>> a performance hit.
>>>>>
>>>> Checked oout "bldoc_orx" and could learn that the logic has changed (did
>>>> not realize that): rather than copying "docs/trunk/oorexx/en-US" to
>>>> ${book}/en-US/Common_Content" you copy the xml files to work with to
>>>> "bldoc_orx/work_folder" and change the reference "Common_Content" in those
>>>> files to point to "docs/trunk/oorexx/en-US" instead (and also the base
>>>> element in work_folder/fop.cfg).
>>>>
>>>> As a result, unlike earlier versions, the checked out docs/trunk directory
>>>> structure does not get changed anymore, which is what I was after. So
>>>> please discard this request, or with other words: -1 from my side as well!
>>>> :)
>>>>
>>>> ---
>>>>
>>>> One observation though: generating the html-rendering will use the
>>>> absolute path to srcdir"/oorexx/en-US" instead of "Common_Content" in the
>>>> index.html:
>>>>
>>>> >>> src="F:/work/svn/oorexx/docs/trunk/oorexx/en-US/images/oorexx.jpg
>>>> "
>>>> align="middle <>" />
>>>> As a result the oorexx.jpg image is not displayed on the front page
>>>> (index.html, line # 4). index.html is the only html-file that I found that
>>>> would
[Oorexx-devel] Preparing for easier maintenance
I just committed a script that will monitor svn.code.sf.net/p/oorexx/code-0/docs/trunk/tools/ and upload any new items to oorexx-bildutils in the Files section. The script will be running once a day on Jenkins and make sure the Files/oorexx-bildutils section is up to date to minimise manual maintenance work. I intended to do the same with the oorexx-bildutils, i.e. tools for building ooRexx itself, not its documentation but I In the Files/oorexx-bildutils section there are some tools for Windows but I could not find the same back in the SVN tree. In svn.code.sf.net/p/oorexx/code-0/build-utilities/trunk there are what appear to be earlier version of Windows tools but it is not the same as on the files section. My proposal is to Archive anything under svn.code.sf.net/p/oorexx/code-0/build-utilities/ (or svn.code.sf.net/p/oorexx/code-0/build-utilities/trunk/ and make a script that monitors this place and populates Files/oorexx-bildutils section. Is that acceptable to all? I indend to document the build process on macOS and all the *nixes and put it in this place. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] More info on Jenkins
My attempt to always have the documentation built before windows and macOS build backfired. "monitoring" the documentation build resulted in Windows and macOS building as soon as there was a change to the documentation, also when there is no change to the source codebase. So I have reverted that change. The other way around, to have Windows and/or initiating a documentation build for every source code change might work (the documentation build will exit silently if there are no changes) but I think it will eventually lead to problems. In the normal situation the documentation will be fairly stable so ready to be picked up. For a release scenario we might need to be a bit more disciplined and let a couple of hours pass between documentation changes and final build. I hope this is acceptable. I have amended the script building and uploading the documentation to accept download and upload paths, so that is can be driven by cMake when we know how to use that as variables. Along the same lines I have written yet a rexx script that checks if any changes have been made to docs-bildutils, and if so, update the "Files" section of sourceforge so that we now have an automated way to update also docs-bildutils The script is launched from the Project ooRexx-docs-bildutils-check and hopefully we can provide the necessary input to the script from CMakeLists.txt in a later stage. I did only consider files so far, I have a question on the folders rexxpg bldoc_win bldoc_orx rexxpg only contain two files so it is doable to download them using the enerving "wait five seconds" downloading function but for bldoc_win and bldoc_orx (what is the difference) there are some 20 separate files and folders, making downloading it a nightmare. I suggest to put everything together as a zipfile, in that way it is a one-click to get it. The folder publican_obsolete is just that, obsolete, so I do not expect anyone to use it but it is kept for backwards compatibility. In the coming days I will go through the list and see what is missing on my part and delete/summarize those sections. Sorry about the long mail Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se _______ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Idea for a new sample demonstrating ADDRESS ... WITH ...
Dear Leslie, We use cURL for building the macOS installer, it is a shell script but an example of a command line looks like this: # use cURL to download the latest documentation (this takes some time) curl -L --insecure https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0/rexxref.pdf > $cmake_binary_dir/temp_dmg_dir/Documentation/rexxref.pdf Check the parameters in the documentation, the —insecure is necessary whenever the certificate on SF expires (happens every now and then). Good luck. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 2. Jan 2023, at 23:42, J Leslie Turriff wrote: > > On 2023-01-02 12:05:32 J Leslie Turriff wrote: >> On 2023-01-02 11:19:51 Rony G. Flatscher wrote: >>> Dave, could you look at the enclosed sample and give some feedback >>> whether it serves its purpose (demonstrate the new ADDRESS...WITH in an >>> understandable manner)? >>> >>> ---rony >>> >>> On 02.01.2023 14:53, Dave Jones wrote: >>>> Not knowing very much about the new ADDRESS...WITH... feature, I would >>>> think that it would be a very useful example. >>>> DJ >>>> >>>> On Mon, Jan 2, 2023 at 7:08 AM Rony G. Flatscher >>>> wrote: >>>> >>>>One of the many new great features of ooRexx 5.0.0 is the >>>> ADDRESS...WITH variant. >>>> >>>>In order to demonstrate how to use it, here an idea: have a sample >>>> that uses curl command (available >>>>on all modern operating systems) to fetch the latest ooRexx >>>> documentation files from SourceForge and >>>>download them into a subdirectory named docs.V, where "V" would be >>>> the ooRexx version. Supplying the >>>>optional ooRexx version (e.g. "4.2.0", "5.0.0", "5.1.0beta", etc.) >>>> would download all the documentation files from the given SourceForge >>>> oorexx-docs directory. >>>> >>>>What do you think, would that be a helpful sample to add to ooRexx? >>>> >>>>---rony >> >> 1) "needle" is not very meaningful. Perhaps "component"? >> >> 2) If no directory is supplied, perhaps "ooRexxDocs" should be the default? >> >> 3) After creating ooRexxDocs directory and specifying it on the command >> line, getOoRexxDocs.rex insists that it does not exist: >> >> ~/bin/rexx >> >> | $ mkdir ooRexxDocs >> | @12:01:53,leslie@pinto rc=0 >> | ~/bin/rexx >> | $ getOoRexxDocs.rex ooRexxDocs >> |+++ "LINUX COMMAND /home/leslie/bin/rexx/getOoRexxDocs.rex" >> | 42 *-* dirArr=getDirectories() -- get array of available document >> | directories >> | >> |>>> "an Array" >> | >> | +++ Interactive trace. "Trace Off" to end debug, ENTER to continue. +++ >> | >> | 45 *-* if .sysCargs[1]~isNil=.false, "/h -h /? -? >> | ?"~caselessPos(.sysCargs[1])>0 >> | >> |>>> "1" >> |>>> "0" >> |>>> "0" >> | >> | 55 *-* needle="" >> | >> |>>> "" >> | >> | 56 *-* if arg()>0 >> | >> |>>> "1" >> | >> | 56 *-* then >> | 57 *-* do >> | >> | 58 *-* downloadDir=.sysCargs[1] -- desired directory name >> | >> |>>> "ooRexxDocs" >> | >> | 59 *-* needle =.sysCargs[2] -- text fragment file name >> | must possess to >> >> be downloaded >> >> |>>> "The NIL object" >> | >> | 60 *-* if needle~isNil >> | >> |>>> "1" >> | >> | 60 *-* then >> | 60 *-* needle="" -- any file name qualifies for download >> | >> |>>> "" >> | >> | 61 *-* end >> | 65 *-* if downloadDir~isNil | dirArr~hasItem(downloadDir)=.false >> | >> |>>> "1" >> | >> | 65 *-* then >> | 66 *-* do >> | >> | 67 *-* say pp(downloadDir) "does not exist, aborting ..." >> | >> |>>> "[ooRexxDocs] does not exist, aborting ..." >> | >> | [ooRexxDocs] does not exist, ab
Re: [Oorexx-devel] Idea for a new sample demonstrating ADDRESS ... WITH ...
and save them in a subdirectory named "docs.V" where "V" is the directory name and save them in a subdirectory "docs.V" of the current directory where "V" is the specified verssion and add Say 'Files downloaded to' localDir at the end nice stuff WALTER > Rony G. Flatscher hat am 02.01.2023 18:19 > geschrieben: > > > Dave, could you look at the enclosed sample and give some feedback > whether it serves its purpose (demonstrate the new ADDRESS...WITH in an > understandable manner)? > > ---rony > > > On 02.01.2023 14:53, Dave Jones wrote: > > > > Not knowing very much about the new ADDRESS...WITH... > feature, I would think that it would be a very useful example. > > DJ > > > > On Mon, Jan 2, 2023 at 7:08 AM Rony G. Flatscher > > mailto:rony.flatsc...@wu.ac.at > wrote: > > > > > > > One of the many new great features of ooRexx 5.0.0 is the > > ADDRESS...WITH variant. > > > > > > In order to demonstrate how to use it, here an idea: have a > > > sample that uses curl command (available > > > on all modern operating systems) to fetch the latest ooRexx > > > documentation files from SourceForge and > > > download them into a subdirectory named docs.V, where "V" > > > would be the ooRexx version. Supplying the > > > optional ooRexx version (e.g. "4.2.0", "5.0.0", "5.1.0beta", > > > etc.) would download all the > > > documentation files from the given SourceForge oorexx-docs > > > directory. > > > > > > What do you think, would that be a helpful sample to add to > > > ooRexx? > > > > > > ---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
Re: [Oorexx-devel] At the end of the 5.0.0 release cycle and beyond ...
> On 1. Jan 2023, at 17:43, Rony G. Flatscher wrote: > > Brief info on today's work: > > updating the tickets from "pending" and "accepted" with no open items to > "closed": did not write a utility after finding out about "bulk-edit", all > four categories got updated > added missing processedTickets.rex utility to new > main/trunk/support/sourceForge > updated text files in main/trunk (changing 4.2.0->5.0.0, 5.0.0->5.1.0), also > release-steps.txt which got updated to reflect what I was able to learn > today, including helpful links related to SourceForge > updated the milestones for the four ticket categories such that the milestone > list gets more manageable; did not change the ooDialog-related milestones, > though we probably should, what do you think? > --- > > Ad Jenkins: here we probably need to help P.O. to update the scripts w.r.t. > the "lessons learned" in this release cycle. Please, P.O. let us know what we > can do to help! > > I have made much of the work already but it is in a transitional state so PLEASE refrain from doing anything to the build machine & it’s scripts, I will let you know when I have something working. > --- > > Ad release version of ooRexx without revision information: once we can create > the binaries without revision information we could create new distributions > of 5.0.0, once the Jenkins scripts got updated to allow P.O. to do much of > the work without manual interventions. I would suggest to then also create > the portable versions for each platform (the build scripts need to get an > additional command added, "nmake portable" for Windows and "make portable" > for Unix plus uploading the two zip-archives to a new 5.0.0/portable > directory). > Same here, I think I know what needs to be done but it takes time and I can only work limited time so bear with me for a couple of weeks. We waited 9 years, a couple of days more does not harm. > --- > > In order to re-iterate the release process to check out the updated scripts > and steps I would like to add the little oleinfo-utiltity and dbus-support > with tests (both in my sandbox, need to be updated w.r.t. license etc.) and > the multithreaded trace feature in the next weeks to trunk and then suggest > to build another release cycle 5.1.0 which hopefully goes much easier than > this one where we had to learn all that is necessary for a proper release. A > pre-requisite would be to have the Jenkins build scripts updated and being > able to create a revision-free release version of the binaries. > > Agreed, this will be a good test. I suggest a dummy test before that on 5.0.1 or similar that we can delete afterwards. Maybe end of January? > ---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
Re: [Oorexx-devel] Ad books not included in the (Windows) installation
Dear Rony, Ad 1: was being built by mistake (my mistake, was not aware of what it was) I have left it out of the documentation building for the future and will remove it from 5.0.0 tonight. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 1. Jan 2023, at 18:08, Rony G. Flatscher wrote: > > The following books do not get installed on Windows: > > ooconsole.pdf (not/never complete, leave out?) > oorexxbuild.pdf (up-to-date and helpful?) > oosqlite.pdf (up-to-date and helpful?) > ootest.pdf (up-to-date and helpful?) > orxncurses.pdf > unixextensions.pdf > What do you think? > > ---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
[Oorexx-devel] Release 5.0.0
- Sourceforge could bring most of the documentation back, 3.0.0 and 3.0.1 I extracted from the Windows installers (that still work, 17 years later!). I have set the date of the documentation same as the artifact folders. - all platforms build without problems, including Mark Hessling's M1 Mac running Ventura (macOS 13) - (almost) all test passes, some things todo for 5.1.0 (more about that next year) I found something interesting in the 4.1.3 documentation: ooRexx-4.1.3-all.zip ooRexx-4.1.3-html.zip ooRexx-4.1.3-pdf.zip Would it make sense to make the same for 5.0.0 (at least the -all)? I find it really annoying with the delayed downloading on sourceforge. As Enrico pointed out the revision number should not show for a released version. I do not know how to fix this (5.0.1?) but we also have the revision number in the artifact (installer) filenames (controlled by CMake) -> we should look at how to change this for a release version and document that for the next time. We can manually remove this from the filenames for 5.0.0 but since rexx -v will still show it I don´t think it is necessary? Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Release of ooRexx 5
For 5.1.0beta from trunk I have now set Windows and macOS to build only after (5.1.0beta) documentation has been built. If there are no changes to documentation the delay will be in the order of seconds. I have also set Docbuild project from trunk to go to oorexx-docs/5.1.0beta, currently all the documentation in trunk refer to 5.0.0 I have cleaned oorexx/5.1.0beta there should only be artifacts from 5.1.0 build from trunk now Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 28. Dec 2022, at 19:57, Rick McGuire wrote: > > I just discovered that I have a copy of the 4.1.3 PDFs. I'll send you a copy. > > Rick > > On Sun, Dec 25, 2022 at 6:04 PM ooRexx <mailto:oor...@jonases.se>> wrote: > I have some god news and some bad news > > The good news: > > FreeBSD is now revision 12583, I rebuilt it manually > macOS is also 12583, but now with the correct documentation > Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) > > I set the date to 2022-12-23 so all installers have the same date (except > Ubuntu for S390X, still revision 12506) > > The proposed download for Windows is Windows 64 bit, > The proposed download for macOS now 5.0.0, not 4.1 > The proposed download for BSD is FreeBSD > I did not indicate any Linux default since we have several platforms > > The bad news: My FTP client played me a trick and erased the entire > oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( > > I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on > Sourceforge to get the other folders back from a backup but I guess they are > not so active over Christmas > > If anyone have copies of at least the latest version of the documentation for > version 4 I would like to have a copy so I can upload it. > > If nothing else works I will rebuild it manually from source. > > Rony asked that no changes be made to the documentation right now, he wanted > to do something first. > > I will reactivate Jenkins build system from trunk tomorrow. > > > Hälsningar/Regards/Grüsse, > ooRexx > oor...@jonases.se <mailto:oor...@jonases.se> > > > > > > _______ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Release of ooRexx 5
That would be great for the interim, thanks. I had word back from Sourceforge support today, they think they can get it back but it will take some time. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 28. Dec 2022, at 19:57, Rick McGuire wrote: > > I just discovered that I have a copy of the 4.1.3 PDFs. I'll send you a copy. > > Rick > > On Sun, Dec 25, 2022 at 6:04 PM ooRexx <mailto:oor...@jonases.se>> wrote: > I have some god news and some bad news > > The good news: > > FreeBSD is now revision 12583, I rebuilt it manually > macOS is also 12583, but now with the correct documentation > Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) > > I set the date to 2022-12-23 so all installers have the same date (except > Ubuntu for S390X, still revision 12506) > > The proposed download for Windows is Windows 64 bit, > The proposed download for macOS now 5.0.0, not 4.1 > The proposed download for BSD is FreeBSD > I did not indicate any Linux default since we have several platforms > > The bad news: My FTP client played me a trick and erased the entire > oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( > > I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on > Sourceforge to get the other folders back from a backup but I guess they are > not so active over Christmas > > If anyone have copies of at least the latest version of the documentation for > version 4 I would like to have a copy so I can upload it. > > If nothing else works I will rebuild it manually from source. > > Rony asked that no changes be made to the documentation right now, he wanted > to do something first. > > I will reactivate Jenkins build system from trunk tomorrow. > > > Hälsningar/Regards/Grüsse, > ooRexx > oor...@jonases.se <mailto:oor...@jonases.se> > > > > > > _______ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > <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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Release of ooRexx 5
Hi Gil I think our mails crossed, Just for the understanding of how the upload works. The uploading script look at sourceforge and keep 5 copies of all installers. This means that until we have had 5 commits there will be some 5.0.0 installers still in the queue (we started 5.1.0. with no installers so all the local ones were uploaded the first time). This can easily be fixed, I will manually remove all “Artifacts” with a build nr 12583 and earlier. The additional problem is the feature that the installer for many *nix platforms is actually tested (a clever part that Erich provided), but the name of the item installed is hardcoded to 5.0.0 (that I am now changing to 5.1.0), for the future this should be controlled by a variable in some way. Regarding the Windows installer it is made from this command nmake nsis_template_installer I have no knowledge of this template so someone on Win should maybe have a look to make sure we are getting the naming right also for Windows. I will amend the macOS installer build routine if necessary. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 28. Dec 2022, at 15:40, Gilbert Barmwater wrote: > > P.O., > > I noticed this morning a bunch of new files "released" on SF, both documents > and builds. I assume these were triggered by 12588 that you recently > committed. However there is a problem with the naming of the builds. Here is > an example: /oorexx/5.1.0beta/ooRexx-5.0.0-12558.linuxmint20.x86_64.deb > Note the 5.0.0 in the file name. Hopefully this is easy to fix. > > Gil > > On 12/27/2022 8:19 AM, ooRexx wrote: >> Dear Gil, >> >> Sorry for the lagging reply, I have been AFK for a while. >> >> Thanks for the offer, I can get (parts of) the 4.2 documentation from the >> Win installer on sourceforge but it would not be the complete set since the >> Unix/Linux documents are not there. Instead I downloaded the source and >> could successfully build the 4.2 documentation, which is the most important >> (after 5.0.0) I think. It gave me the possibility to improve my scripts >> somewhat :-) >> >> We should be thinking of how to deliver also the *nixes with documentation. >> Even the macOS before 5.0.0 lack the documentation. >> >> The documentation before 4.2 I could not rebuild, it has a different layout, >> I would probably have to revive Publican again. >> >> I thought I had found the documentation back on the Wayback machine >> <https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwj3yKX375n8AhW3SPEDHeebAZ0QFnoECAkQAQ=https://archive.org/web/=AOvVaw1olZ8IYxs_xjPuf-Ft5fso> >> Everything appeared to be there. Alas, what was stored was the link to the >> “Your Download will start in 5 seconds…” script so no actual data was >> present, just the layout so to speak. >> >> I hope there is a backup on Sourceforge, I have not yet heard from the >> support there. >> >> I am upgrading the Jenkins system today and will start it later tonight. >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> On 26. Dec 2022, at 02:04, Gilbert Barmwater >> <mailto:gi...@bellsouth.net>> wrote: >>> >>> I have 4.2.0 for Windows 64 bit installed which has the included PDFs. Let >>> me know if you need them. >>> >>> Gil >>> >>> On 12/25/2022 6:03 PM, ooRexx wrote: >>>> I have some god news and some bad news >>>> >>>> The good news: >>>> >>>> FreeBSD is now revision 12583, I rebuilt it manually >>>> macOS is also 12583, but now with the correct documentation >>>> Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) >>>> >>>> I set the date to 2022-12-23 so all installers have the same date (except >>>> Ubuntu for S390X, still revision 12506) >>>> >>>> The proposed download for Windows is Windows 64 bit, >>>> The proposed download for macOS now 5.0.0, not 4.1 >>>> The proposed download for BSD is FreeBSD >>>> I did not indicate any Linux default since we have several platforms >>>> >>>> The bad news: My FTP client played me a trick and erased the entire >>>> oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( >>>> >>>> I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on >>>> Sourceforge to get the other folders back from a backup but I guess they >>>> are not so active over Christmas >>>> >>>>
Re: [Oorexx-devel] Release of ooRexx 5
Dear Gil, Thanks for pointing it out, I already detected some problems and am working through the list of builds. This is one of the problems we saw in that Jenkins works well for static situation (which we had for quite some time :-) but for release it was suboptimal with a lot of manual labour. We should have a defined set of variables that are read from all builds so that it is only necessary to change in 1 place, not in 60+ places as we have it today. I note everything for the next time we intend to do a release For information Jenkins is now on the latest LTS release version, 2.375.1 Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > On 28. Dec 2022, at 15:40, Gilbert Barmwater wrote: > > P.O., > > I noticed this morning a bunch of new files "released" on SF, both documents > and builds. I assume these were triggered by 12588 that you recently > committed. However there is a problem with the naming of the builds. Here is > an example: /oorexx/5.1.0beta/ooRexx-5.0.0-12558.linuxmint20.x86_64.deb > Note the 5.0.0 in the file name. Hopefully this is easy to fix. > > Gil > > On 12/27/2022 8:19 AM, ooRexx wrote: >> Dear Gil, >> >> Sorry for the lagging reply, I have been AFK for a while. >> >> Thanks for the offer, I can get (parts of) the 4.2 documentation from the >> Win installer on sourceforge but it would not be the complete set since the >> Unix/Linux documents are not there. Instead I downloaded the source and >> could successfully build the 4.2 documentation, which is the most important >> (after 5.0.0) I think. It gave me the possibility to improve my scripts >> somewhat :-) >> >> We should be thinking of how to deliver also the *nixes with documentation. >> Even the macOS before 5.0.0 lack the documentation. >> >> The documentation before 4.2 I could not rebuild, it has a different layout, >> I would probably have to revive Publican again. >> >> I thought I had found the documentation back on the Wayback machine >> <https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwj3yKX375n8AhW3SPEDHeebAZ0QFnoECAkQAQ=https://archive.org/web/=AOvVaw1olZ8IYxs_xjPuf-Ft5fso> >> Everything appeared to be there. Alas, what was stored was the link to the >> “Your Download will start in 5 seconds…” script so no actual data was >> present, just the layout so to speak. >> >> I hope there is a backup on Sourceforge, I have not yet heard from the >> support there. >> >> I am upgrading the Jenkins system today and will start it later tonight. >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> On 26. Dec 2022, at 02:04, Gilbert Barmwater >> <mailto:gi...@bellsouth.net>> wrote: >>> >>> I have 4.2.0 for Windows 64 bit installed which has the included PDFs. Let >>> me know if you need them. >>> >>> Gil >>> >>> On 12/25/2022 6:03 PM, ooRexx wrote: >>>> I have some god news and some bad news >>>> >>>> The good news: >>>> >>>> FreeBSD is now revision 12583, I rebuilt it manually >>>> macOS is also 12583, but now with the correct documentation >>>> Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) >>>> >>>> I set the date to 2022-12-23 so all installers have the same date (except >>>> Ubuntu for S390X, still revision 12506) >>>> >>>> The proposed download for Windows is Windows 64 bit, >>>> The proposed download for macOS now 5.0.0, not 4.1 >>>> The proposed download for BSD is FreeBSD >>>> I did not indicate any Linux default since we have several platforms >>>> >>>> The bad news: My FTP client played me a trick and erased the entire >>>> oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( >>>> >>>> I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on >>>> Sourceforge to get the other folders back from a backup but I guess they >>>> are not so active over Christmas >>>> >>>> If anyone have copies of at least the latest version of the documentation >>>> for version 4 I would like to have a copy so I can upload it. >>>> >>>> If nothing else works I will rebuild it manually from source. >>>> >>>> Rony asked that no changes be made to the documentation right now, he >>>> wanted to do something first. >>>> >>>> I will reactivat
Re: [Oorexx-devel] Release of ooRexx 5
Dear Gil, Sorry for the lagging reply, I have been AFK for a while. Thanks for the offer, I can get (parts of) the 4.2 documentation from the Win installer on sourceforge but it would not be the complete set since the Unix/Linux documents are not there. Instead I downloaded the source and could successfully build the 4.2 documentation, which is the most important (after 5.0.0) I think. It gave me the possibility to improve my scripts somewhat :-) We should be thinking of how to deliver also the *nixes with documentation. Even the macOS before 5.0.0 lack the documentation. The documentation before 4.2 I could not rebuild, it has a different layout, I would probably have to revive Publican again. I thought I had found the documentation back on the Wayback machine <https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwj3yKX375n8AhW3SPEDHeebAZ0QFnoECAkQAQ=https://archive.org/web/=AOvVaw1olZ8IYxs_xjPuf-Ft5fso> Everything appeared to be there. Alas, what was stored was the link to the “Your Download will start in 5 seconds…” script so no actual data was present, just the layout so to speak. I hope there is a backup on Sourceforge, I have not yet heard from the support there. I am upgrading the Jenkins system today and will start it later tonight. Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se > On 26. Dec 2022, at 02:04, Gilbert Barmwater wrote: > > I have 4.2.0 for Windows 64 bit installed which has the included PDFs. Let > me know if you need them. > > Gil > > On 12/25/2022 6:03 PM, ooRexx wrote: >> I have some god news and some bad news >> >> The good news: >> >> FreeBSD is now revision 12583, I rebuilt it manually >> macOS is also 12583, but now with the correct documentation >> Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) >> >> I set the date to 2022-12-23 so all installers have the same date (except >> Ubuntu for S390X, still revision 12506) >> >> The proposed download for Windows is Windows 64 bit, >> The proposed download for macOS now 5.0.0, not 4.1 >> The proposed download for BSD is FreeBSD >> I did not indicate any Linux default since we have several platforms >> >> The bad news: My FTP client played me a trick and erased the entire >> oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( >> >> I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on >> Sourceforge to get the other folders back from a backup but I guess they are >> not so active over Christmas >> >> If anyone have copies of at least the latest version of the documentation >> for version 4 I would like to have a copy so I can upload it. >> >> If nothing else works I will rebuild it manually from source. >> >> Rony asked that no changes be made to the documentation right now, he wanted >> to do something first. >> >> I will reactivate Jenkins build system from trunk tomorrow. >> >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oor...@jonases.se >> >> >> >> >> >> ___ >> 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 ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Sourceforge release glitch
I think the button's code looks at the OS you are using > Sahananda Sahananda hat am 26.12.2022 13:20 > geschrieben: > > > Hi, > > The page https://sourceforge.net/projects/oorexx/files/ on my laptop has > a button on the top inviting me to download ooRexx 5.0.0 as the current > version. > Looking at this same page on my phone, the same button offers ooRexx > 4.1.0 as the latest version. > > Jon > _______ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > LG Walter ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Release of ooRexx 5
Open Object Rexx Release Notes Version 5.0.0 Copyright 2005-2021 Rexx Language Association. All rights reserved. should be 2022!?! ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Release of ooRexx 5
> On 26. Dec 2022, at 10:43, Rony G Flatscher wrote: > > Ad default download packages: as reported I set them already, but it does not > hurt that they get set once more. :) It was important to set all the Linux > packages as default as otherwise other (older) defaults might get suggested > for download. It will be the Linux user‘s task to pick the appropriate one if > the suggested one dies not match. Dear Rony, When I uploaded the corrected version of macOS and FreeBSD installers that information got lost, I was pointed at macOS 4.1.2 before I activated the setting. For Windows I did not get the hint (since I am on Mac) but I could see that it was checked. I cannot see that any setting is made for Linux did you set this? We build for Solaris (OpenIndiana) but we do not have an installer. Anyone with information on how to accomplish this? _______ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Release of ooRexx 5
I have some god news and some bad news The good news: FreeBSD is now revision 12583, I rebuilt it manually macOS is also 12583, but now with the correct documentation Ubuntu22 has been renamed to Ubuntu2204 (to indicate LTS version) I set the date to 2022-12-23 so all installers have the same date (except Ubuntu for S390X, still revision 12506) The proposed download for Windows is Windows 64 bit, The proposed download for macOS now 5.0.0, not 4.1 The proposed download for BSD is FreeBSD I did not indicate any Linux default since we have several platforms The bad news: My FTP client played me a trick and erased the entire oorexx-docs when I ordered it to delete oorexx-docs/5.0.0beta :-( I recreated oorexx-docs and uploaded 5.0.0 again and I have asked on Sourceforge to get the other folders back from a backup but I guess they are not so active over Christmas If anyone have copies of at least the latest version of the documentation for version 4 I would like to have a copy so I can upload it. If nothing else works I will rebuild it manually from source. Rony asked that no changes be made to the documentation right now, he wanted to do something first. I will reactivate Jenkins build system from trunk tomorrow. Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Release of ooRexx 5
Dear all, I have finally managed to finalise the work for the release. It is clear that we should do it differently in the future, the small hiccups that pop up last minute create lots of extra work. Let’s discuss this after the holidays. 3 caveats, FreeBSD is revision 12563, Jenkins does not allow me to build for FreeBSD right now. Ubuntu for S390X is revision 12506, that machine is currently not available for building macOS still have the older documentation, it is not possible to fix this without a SVN modification, I will do that in trunk later and replace the current version (macOS will then have another revision) All other Platforms now report version 12583 and are available for download. I have renamed the documentation to 5.0.0 I will shut down Jenkins for a few days, after which I will go through and change all things back to “normal”. Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [oorexx:code-0] New commit [r12584] by orexx
There is the possibility to revert a skunky commit, along the lines of svn merge -c 12584 Can you do that? > > > ___ > 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
Re: [Oorexx-devel] [oorexx:code-0] New commit [r12584] by orexx
> On 23. Dec 2022, at 17:33, Rony G. Flatscher wrote: > > On 23.12.2022 17:29, ooRexx wrote: >> Due to this unnecessary commit Windows and macOS are now getting another >> revision than the rest. Should we accept that or should I try to manually go >> back one version? This is causing a LOT of stress one day before Christmas. > > If you apply the patch to branches/5.0.0 then shouldn't all the binaries be > recreated with the same revision number? > > ---rony > > You are asking me to apply an untested patch (that I have not made myself) to a system in a transitional state? That would be madness. I have already set up Jenkins for working from trunk again, this takes several hours, I will make a rollback locally for Windows and macOS, I have shut off all other machines to prevent further accidental commits. PLEASE let me work now, it will be ready when it is ready. > > > ___ > 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
[Oorexx-devel] Fwd: [oorexx:code-0] New commit [r12584] by orexx
Due to this unnecessary commit Windows and macOS are now getting another revision than the rest. Should we accept that or should I try to manually go back one version? This is causing a LOT of stress one day before Christmas. Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se > Begin forwarded message: > > From: "Open Object Rexx SVN repository" > > Subject: [oorexx:code-0] New commit [r12584] by orexx > Date: 23. December 2022 at 16:51:58 CET > To: "Open Object Rexx SVN repository" > > Reply-To: "Open Object Rexx SVN repository" > > > > change files to trigger a new build of the release packages with the same > revision and the latest documentation > > By orexx on 12/23/2022 15:51 > [**View Changes**](https://sourceforge.net/p/oorexx/code-0/12584/) > > > > > > --- > > Sent from sourceforge.net because you indicated interest in > <https://sourceforge.net/p/oorexx/code-0/> > > > > To unsubscribe from further messages, please visit > <https://sourceforge.net/auth/subscriptions/> _______ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Wrong documentation in latest builds ...
Dear Rony, I am working like hell, I have to do chases in some 70 different places, please do not send any more mail and for Gods sake do not make ANY more check-ins, the whole build system is in a transition state and you are messing everything up. Can ALL people refrain from doing ANY changes to the system, Please? I will report back when I am finished. This takes som time still. That said, thank you for spotting that the documentation for Windows is picked up from the wrong place, it is the same for macOS. The documentation is collected with a script that need to be manually corrected. I will take care of a last rebuild with the correct documentation manually Hälsningar/Regards/Grüsse, ooRexx oor...@jonases.se > On 23. Dec 2022, at 16:52, Rony G. Flatscher wrote: > > On 23.12.2022 15:38, Rony G. Flatscher wrote: >> On 23.12.2022 15:16, ooRexx wrote: >>> Since the documentation was not built it was outdated when Windows was >>> built, >> >> The documentation in >> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0_Release_Candidate/> >> was o.k. already! >> >> It seems that the build process for ooRexx picks the documentation from >> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/>. >> >> Could you check that please? >> > Not hearing anything back I just checked-in changes in branches/5.0.0 such > that the build of the binary packages should get triggered. > > ---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
