Re: [Oorexx-devel] oorexx.org documents

[René Jansen]

wow, this was on a mobile phone with the wrong glasses.

What I meant to say is that if you now put a static copy of the documentation 
somewhere on the web server, we can change that with the release of 5.01 (5.1?) 
to the location where there release build is situated, and work towards having 
everything dynamically available, so we will not fall so far behind again.

I have invited you as a collaborator on the private github repo which houses 
the RexxLA web server git repository. 

best regards,

René.



> On 21 Apr 2024, at 23:45, René Jansen  wrote:
> 
> Not sure if these are built in a regular interval. I would start with acopy; 
> you canway replace those with links.
> 
> Best regards,
> 
> René.
> 
>> On 21 Apr 2024, at 23:14, taf  wrote:
>> 
>> the ooRexx website has pointers to the docs subdirectory for manuals... but 
>> the manuals are not there.  Does anyone have objection to my installing the 
>> html versions of the docs on the website?
>> 
>> Better yet, is there a location where the html manuals are updated 
>> automatically and accessible to the website?
>> 
>> --
>> taf
>> 
>> 
>> 
>> ___
>> 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] oorexx.org documents

[René Jansen]

Not sure if these are built in a regular interval. I would start with acopy; 
you canway replace those with links.

Best regards,

René.

> On 21 Apr 2024, at 23:14, taf  wrote:
> 
> the ooRexx website has pointers to the docs subdirectory for manuals... but 
> the manuals are not there.  Does anyone have objection to my installing the 
> html versions of the docs on the website?
> 
> Better yet, is there a location where the html manuals are updated 
> automatically and accessible to the website?
> 
> --
> taf
> 
> 
> 
> ___
> 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 website commit authorization

[René Jansen]

The svn checkout should have given it your userid and not mine. The RexxLA 
website is in a private github repository. Mark can help.

Best regards,

René.

> On 21 Apr 2024, at 02:51, taf  wrote:
> 
> 
> I've updated the working copy (which is also the live website), and now I'd 
> like to commit those changes to the repository.  When I try to do so I'm 
> prompted for a password.  I'm running as user oorexx (broke out with cntrl-c 
> at the password prompt):
> 
> [oorexx@home website]$ svn commit --message 'fixup links, copyright dates, 
> add some new products'
> Password:
> svn: E210002: Commit failed (details follow):
> svn: E210002: Unable to connect to a repository at URL 
> 'svn+ssh://rvjan...@svn.code.sf.net/p/oorexx/code-0/websites/main/trunk/docroot'
> 
> the working copy info is:
> 
> [oorexx@home website]$ svn info
> Path: .
> Working Copy Root Path: /home/oorexx/website
> URL: 
> svn+ssh://rvjan...@svn.code.sf.net/p/oorexx/code-0/websites/main/trunk/docroot
> Repository Root: svn+ssh://rvjan...@svn.code.sf.net/p/oorexx/code-0
> Repository UUID: 0b6cbdbe-3aab-466e-b73a-abd511dda0a2
> Revision: 12143
> Node Kind: directory
> Schedule: normal
> Last Changed Author: rvjansen
> Last Changed Rev: 11240
> Last Changed Date: 2017-05-02 19:48:35 + (Tue, 02 May 2017)
> 
> So... should rvjansen.../code-0 have my public ssh key?  should I have a 
> password?  or should I be committing at all?
> 
> Should I check out from the sf site to my own computer and commit from here.  
> If so, how to I synchronize the oorexx.org/home/oorexx/website working (and 
> live) copy?
> 
> Knoobs want to know!
> 
> 
> 
> -- 
> taf
> ___
> 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

[René Jansen]

Hi P.O.,

this is very good news, and thank you for the effort. I will be sure to commit 
exactly nothing today and hope the others follow.

best regards,

René.

> 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 
> 
> 
> 
> ___
> 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] rexxGTK build

[René Jansen]

Hi Ruurd,

even if you could make a video of a presentation I bet lots of people would be 
very interested!

best regards,

René

> On 16 Jan 2024, at 14:28, Ruurd Idenburg  wrote:
> 
> Ok, I'll put some stuff together and make it available somehow.
> 
> Ruurd
> 
> On 1/15/24 18:14, taf wrote:
>> Ruurd you're way ahead of me!  I've been goofing off for the last month... 
>> I'd really like to see what you've done with an eye to adapting it to GTK4.  
>> Thanks for all your hard work
>> 
>> On 2024.01.14 20.01, Ruurd Idenburg wrote:
>>> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Committing change

[René Jansen]

+1

> On 22 Sep 2023, at 19:55, Sahananda Sahananda  wrote:
> 
> 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  > 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 
>> 
>> 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 website

[René Jansen]

The web server runs Regina and Java for NetRexx; ooRexx coexistence seems best done with a Docker container which runs a webserver and ooRexx. This has the advance that you would be able to run an unchanged stack from home. Best regards,René.On 19 Sep 2023, at 13:36, René Jansen  wrote:Hi Terry,in the mean time the NetRexx site is at github: https://github.com/rvjansen/netrexx-siteworks the same way as svn, but then in git.best regards,René.On 18 Sep 2023, at 23:37, taf  wrote:
  


  
  Starting a new thread...I've checked out the website code as per René & Mark: svn checkout svn+ssh://[SFID]@svn.code.sf.net/p/oorexx/code-0/websites/main/trunk/docroot . I've added the changes Jon provided.
  I've run commit (am I missing something here?
  there's a checkout but no checkin?)svn commit -m"add link to GA 5.0.0 download"This fails, I think for lack of update
  authority on the part of my taf23 sf id.  Should I pass the
  changes on to a committer?Separately, but relatedly,René mentions: "You can author (and test) changes at your machine
  and check them in, and push them to the server with an svn up in
  the website directory."As above checkin doesn't seem to be an option, commit is the
  operation, right?push them to the server  this means publish them on the website? with
  svn up[date] from (while ssh-ed into the} website?
Finally, Mark & René:  We want the ooRexx site to be driven
  by ooRexx, and my first attempt at this will be to follow along
  with the NetRexx website, substituting rexx server pages (.rsp)
  for the places where netrexx uses .nsp. Is ooRexx installed on the
  web server?  If not, can ite be?  If it is or can be, can I
  install mod_rexx to support the rexx server pages?  If ooRexx is
  available, but mod_rexx cannot be installed, I'll resort to rexx
  under cgi.
  
-- 
taf
  

___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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 website

[René Jansen]

Hi Terry,

in the mean time the NetRexx site is at github: 
https://github.com/rvjansen/netrexx-site

works the same way as svn, but then in git.

best regards,

René.


> On 18 Sep 2023, at 23:37, taf  wrote:
> 
> Starting a new thread...
> 
> I've checked out the website code as per René & Mark:
> 
> svn checkout 
> svn+ssh://[SFID]@svn.code.sf.net/p/oorexx/code-0/websites/main/trunk/docroot 
>  .
> 
>  I've added the changes Jon provided.
> 
> I've run commit (am I missing something here? there's a checkout but no 
> checkin?)
> 
> svn commit -m"add link to GA 5.0.0 download"
> 
> This fails, I think for lack of update authority on the part of my taf23 sf 
> id.  Should I pass the changes on to a committer?
> 
> Separately, but relatedly,
> 
> René mentions: "You can author (and test) changes at your machine and check 
> them in, and push them to the server with an svn up in the website directory."
> 
> As above checkin doesn't seem to be an option, commit is the operation, right?
> 
> push them to the server  this means publish them on the website? with svn 
> up[date] from (while ssh-ed into the} website?
> 
> Finally, Mark & René:  We want the ooRexx site to be driven by ooRexx, and my 
> first attempt at this will be to follow along with the NetRexx website, 
> substituting rexx server pages (.rsp) for the places where netrexx uses .nsp. 
> Is ooRexx installed on the web server?  If not, can ite be?  If it is or can 
> be, can I install mod_rexx to support the rexx server pages?  If ooRexx is 
> available, but mod_rexx cannot be installed, I'll resort to rexx under cgi.
> 
> -- 
> taf
> ___
> 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] News on Raspberry Pi builds

[René Jansen]

I thinks fixing the installer while taking care the code is still at 5.0.0 is not a big problem.Best regards,René.On 10 Apr 2023, at 22:26, ooRexx  wrote: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. Jonssonoor...@jonases.se


___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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

[René Jansen]

hi P.O.,Thanks!René.On 4 Apr 2023, at 15:49, P.O. Jonsson  wrote:I am making a 2nd attempt to replace my cable modem/router today and tomorrow, so Jenkins may be unavailable for some time.
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se


___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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] Musings with tracing multithreaded ooRexx programs, mt91.rex: on two Rexx interpreter instances (RII)

[René Jansen]

One idea here is to no change the options of TRACE at all (they are very 
portable over variants). For implementations that have threads, why don’t we 
add a 

TRACE THREADS

before the trace statement. We can have an TRACE THREADS OFF option to switch 
back to the regular trace.

also, a 

TRACE THREAD x

would just trace a named thread. Assuming we name them, which would be better 
than following the OS.

In this vein, I would very much like a

TRACE TIME

which timestamps trace messages (for performance work), combinable with threads.

This would have the advantage of keeping TRACE the same on implementations and 
add the extra line length when asked for it.
It can also be done in OPTIONS - where the general line should be that unknown 
options are just ignored.

best regards,

René.

> On 16 Feb 2023, at 22:42, Rony  wrote:
> 
> 
>> Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw :
>>  
>> As for the 'spaced out' case (excerpt below) ... this really would not work 
>> for me.   I often have 5-9 windows open when I'm programming and these are 
>> 80 characters wide so I can minimise overlaps.  With the suggested layout 
>> this would only work for programs less than ~40 characters wide!   Here's 
>> how the excerpt looks for me (and this example has very short lines -- most 
>> of my programs use 72 or more characters per line for better commentary):
>>  
>> ---> mt91.rex_nr_1_via_JSR223
>> R1   T1   A13 *-* t=.Test~new
>> R1   T1   A2V1  1* 21 *-* say "arrived in:" .context~name
>> arrived in: INIT
>> R1   T1   A2V1  1* 22 *-* counter=0
>> R1   T1   A1  >>>   "a TEST"
>> R1   T1   A14 *-* t~m1
>> R1   T1   A3V1  1* 27 *-* counter+=1  -- increase counter
>> R1   T1   A3V1  1* 28 *-* say "arrived in:" .context~name
>> "before reply"
>>  
>> Almost any line of any length will wrap.  That's why the trace headers in 
>> Rexx are kept as short as feasible. 
> Yes trace has been well thought out and well designed.
> 
> It seems that you are under the impression that this extra trace information 
> should get added to trace by default? If so, that is not the case. In effect 
> as designed and 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] The search order bug: a progress report, and some questions

[René Jansen]

Hi Josep,

thank you for this investigation which I am sure we all have read with great 
interest.

> On 7 Feb 2023, at 11:35, Josep Maria Blasco  
> wrote:
> 
> Once more: I don't think there's a clear, evident way to settle this 
> conversation. A decision has to be taken. And it has to be explained (i.e., 
> documented) and, if possible, justified. The last part is optional, of 
> course: one can define a language as one sees fit.
> 
> The weight, if any, of my contribution, is only to emphasize two things:
> Other languages tackle this problem in a particular, coincident way.
> And that way is the most economic in terms of describing the search procedure.
> This does not mean that what I am proposing should be accepted. It's only my 
> point of view.
> 

I think this needs to be well documented (for all platforms Rexx is running on, 
with additions for the oo variants. There is a new Rexx ARB starting up where 
work can be done to isolate the different components of the question where 
things are found - I think one of the most important questions one encounters 
when trying to make something non-trivial.

There is the component of history - CMS and TSO were there before the 
DOS/OS2/Unix world. There is the language philosophy angle - other languages 
make choices the might not be the Rexx way (those full of curly braces or 
significant spaces), while on some platforms (NetRexx - Java) the choices of 
the latter are like gravity.

One question that comes up is if you compared the way ooRexx 5.X does this to 
Regina, Brexx or OS/2. I think one of the things an extended standard document 
could do is to help describe this and propose a standard way of implementing 
this which is straightforward on Windows/Linux(including other Unix like 
platforms like macOS).

It could be argued that this is not part of the language but of the 
implementation - but I am doubting that the documentation of a function(method) 
call or the CALL statement is complete without a specification where it finds 
what it calls. 

Economy in terms of describing - well, that is relative I think - the procedure 
for finding and overriding a BIF in VM at least requires a flowchart in the VM 
documentation (and the way Brexx does it is different) but it expresses a 
common goal of being able to override a built-in-function. In z/OS we have lpa 
(flpa, mlpa), link list, sysproc and sysexec concatenation (and the alt 
library) where a compiled Rexx program could live and I would not be able to 
economically describe that, but they are all there for a reason.

Thank you again for bringing up this discussion.

Could you mail me that zip file so I can put it somewhere where more people can 
look at it?

best regards,

René Jansen.___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Access to the builds

[René Jansen]

Hi Jon,

done - if it does not work, let me know.

best regards,

René.


> On 6 Feb 2023, at 09:54, Sahananda Sahananda  wrote:
> 
> Hi all,
> 
> at some point my access to Jenkins which I set up in around 2015 has fallen 
> off.
> 
> I have recreated my account - username: sahananda
> 
> However, logging in I see 'sahananda is missing the Overall/Read permission'
> 
> I would like to be able to see the builds - particularly the documentation
> 
> thanks
> 
> 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

Re: [Oorexx-devel] Last Artifact for 5.0.0 built

[René Jansen]

I have lightly tested the s390x portable build under docker versions of 
s390x/ubuntu and s390x/almalinux - both work. I think that we even can remove 
the ‘ubuntu’ segment of the name of the zip that contains the portable version.

Next step should probably be to get the ooRexx builds in the platform versions 
of the linux distributions - all people I know will only be willing to ’sudo 
apt install oorexx’ or ‘yum install oorexx’. We had this SUSE person building 
for oorexx years, maybe he can help here. We can start with private 
repositories and publish the way people have to add those to their apt or yum 
or pacman, but getting through to the official ones would be a coup.

Maybe @Mark knows - Regina is in all of them?

best regards,

René.


> On 24 Jan 2023, at 16:43, ooRexx  wrote:
> 
>> 
>> 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.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Patch for revisionless package and "rexx -v" (meant for official release)

[René Jansen]

Hi Rony,

with the remark that this version identifier is a revision number from a 
specific version management system (Subversion) and has proven difficult to 
reproduce in others.
Also, it adds a build dependency that is only there for one reason (tho’ I 
built a few versions from my updated-to-GA git repo and did not see trouble- 
but formally it is).

René.

> On 6 Jan 2023, at 12:33, Rony G. Flatscher  wrote:
> 
> Just another update in the developer list such that readers know: in 
>  Erich has pointed to 
> his RFE  (which I was 
> not aware of anymore) which brought the revision information into the version 
> string.
> 
> For some reasons I got the impression from comments over time that an 
> official release should not carry any specific revision information in the 
> package names and "rexx[c] -v" which caused me to check out the possibility 
> to do that and which yielded RFE:#815 and the patch.
> 
> As personally I am fine with keeping the revision information in the relased 
> package names and "rexx[c] -v" I will not proceed with RFE #815 any further.
> 
> ---rony
> 
> 
> On 06.01.2023 16:37, Michael Lueck wrote:
>> Greetings ooRexx'ers,
>> 
>> 
>> Rony G. Flatscher wrote:
>>> say .rexxinfo~revision
>>> 
>>> will always give you the revision that was in place when the package got 
>>> created.
>>> 
>>> Not showing the revision number on "rexx -v" is meant to indicate that it 
>>> is an official release version and not an interim build.
>> 
>> 
>> 
>> In that case, given the availability of .rexxinfo~revision will always be 
>> supported, I would be fine with removing the precise version from "rexx -v".
>> 
>> I appreciate you explaining.
>> 
>> I am thankful, 
> 
> 
> 
> ___
> 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] Short notice

[René Jansen]

Hi P.O.,

thanks for the heads up and the incredible amount of work you put into this!
ooRexx 5.1.0 is happily humming on all my machines (and several customer 
machines also).

best regards,

René.


> On 6 Jan 2023, at 11:55, P.O. Jonsson  wrote:
> 
> This is just to say that I need to take the machine running the VMs for 
> Jenkins offline. Jenkins itself will be available as well as all the Windows 
> machines, but all Linux/Unix and macOS will be unavailable for a couple of 
> days.
> 
> I will respond sparingly to mail in the coming days.
> 
> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Trademarks

[René Jansen]

“Open Object Rexx as legal successor and derivative work of Object Rexx”

Having said that, I would like to flag this as a contentious subject, because 
solving this, IMHO, does not serve any useful purpose. Also, we have several 
jurisdictions, with you being in Austria, RexxLA being in North Carolina, me 
being in Amsterdam (except for now, on Aruba with Aruban Law based on Dutch Law 
but for some aspects not on European Law …).

In Dutch Law for example, most of what you write is forever yours, and large 
companies requiring you to sign your code over to them can only in corner cases 
do that legally (if they can show *very* specific assignments and 
compensations) and most of the time they lose in court afterwards anyway. IBM 
in the US must be different, but most of the older code was from Boeblingen. 
Most of it now is Rick’s, and was before that, also.

Although the Board should take decisions about these things, my personal view 
here is that this would only matter if their is some blatant misuse 
(reputation-wise, which is stipulated in the contract we signed with IBM) which 
is not covered by the CPL. For example, everybody is free to fork any open 
source repo and call it something else (and people did, also with ooRexx) with 
the only requirement of including some file, notice or other.

Remembering JOVIAL (Jules’s Own Version of the International Algorithmic 
Language) for Algol 58 shows that the best structure for maintenance of 
language infrastructure eventually can claim the rights - and deliver the 
preferred language for the defense department. (And did the Algol-58 committee 
sue the military-industrial complex? No, that would have been unwise.) 

I think that RexxLA is that structure (we have to keep proving that), but the 
team’s decisions are their own, and we should all be very pleasant about it, 
and thankful for everyone who wants to work on it.

best regards,

René.



> On 6 Jan 2023, at 12:43, Erich Steinböck  wrote:
> 
> Hi René,
> 
>> persons employed by IBM at the time, and in charge of Object Rexx
> but then would IBM trademarks not have been for maybe "oRexx or "Object 
> Rexx", but not "ooRexx" or "Open Object Rexx"?
> 
> ___
> 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] Trademarks

[René Jansen]

Hi Erich,

IBM has stated to have transferred the trademarks to The Rexx Language 
Association. I have heard this statement in person from at least two different 
persons employed by IBM at the time, and in charge of Object Rexx. The document 
signed between RexxLA and IBM has (project phase II) “Transfer of intellectual 
property” (Program Code, […], etc”.

I cannot remember RexxLA ever having followed up to check whether everything 
(including the parts handled by the legal department, which I remember as not 
always the fastest movers in IBM) was formally executed. We need to ask the 
people on the forefront of the open sourcing effort, starting 2004, which were 
Pamela, Chip, Rick, Rony and Mark, if they have memories.

Open Object Rexx (including its name and its publisher) is published under the 
CPL; this is a clear document as to the ownership of the contents of its 
repositories. 

best regards,

René.

> On 6 Jan 2023, at 11:53, Erich Steinböck  wrote:
> 
> Our docs state "Open Object Rexx™ and ooRexx™ are trademarks of the Rexx 
> Language Association".
> 
> I've searched several online Trademark Portals (e. g. TESS at 
> https://tmsearch.uspto.gov/bin/gate.exe?f=searchss=4810:74iqlo.1.1) and 
> cannot verify whether this is actually true.
> 
> Is "Open Object Rexx" and/or "ooRexx" (still) a trademark of RexxLA?
> 
> Our ooRexx icon, which is set as the rexx.exe icon on Windows also shows "TM".
> ___
> 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

[René Jansen]

Not to beat the subject to death, but when it is moved to git, everybody has a full copy of everything - there is no ‘server part’ (in fact there is, a ‘bare’ repo without workspace) in a git server - every local repository has the full data including history, which gives me a much more secure feeling.René.On 28 Dec 2022, at 15:26, ooRexx  wrote: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. Jonssonoor...@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. RickOn Sun, Dec 25, 2022 at 6:04 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 listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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

[René Jansen]

yes, that is the plan. And thanks for delivering the first change - I know I 
have to know these things, but it will proceed most quickly if I am sent lots 
of these links.

Kudos for all the work (and you P.O.!) and for getting the message out.

best regards,

René.


> On 23 Dec 2022, at 18:53, Rony  wrote:
> 
> Thank you René!
> 
> Could you change the download link to < 
> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0/ 
> <https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0/>> ? TIA!
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> 
>> Am 23.12.2022 um 23:50 schrieb René Jansen :
>> 
>> Also,
>> 
>> have a look at https://www.oorexx.org/index2.html - as soon as all the 
>> changed info is know, I can work on updating the rest of the site.
>> 
>> best regards,
>> 
>> René.
>> 
>> 
>>> On 23 Dec 2022, at 18:36, P.O. Jonsson  wrote:
>>> 
>>> In my opinion yes, I think we can deal with the details after the holidays. 
>>> I would appreciate if Rick and Erich had a look as well.
>>> 
>>> 
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>> 
>>> 
>>> 
>>> 
>>>> Am 23.12.2022 um 23:32 schrieb Rony >>> <mailto:rony.flatsc...@wu.ac.at>>:
>>>> 
>>>> Super! +1
>>>> 
>>>> So we are good to send the announcement e-mail?
>>>> 
>>>> —-rony
>>>> 
>>>> Rony G. Flatscher (mobil/e)
>>>> 
>>>>> Am 23.12.2022 um 21:04 schrieb ooRexx >>>> <mailto:oor...@jonases.se>>:
>>>>> 
>>>>> 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 <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 
>>>> <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

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Release of ooRexx 5

[René Jansen]

Also,

have a look at https://www.oorexx.org/index2.html - as soon as all the changed 
info is know, I can work on updating the rest of the site.

best regards,

René.


> On 23 Dec 2022, at 18:36, P.O. Jonsson  wrote:
> 
> In my opinion yes, I think we can deal with the details after the holidays. I 
> would appreciate if Rick and Erich had a look as well.
> 
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
>> Am 23.12.2022 um 23:32 schrieb Rony > >:
>> 
>> Super! +1
>> 
>> So we are good to send the announcement e-mail?
>> 
>> —-rony
>> 
>> Rony G. Flatscher (mobil/e)
>> 
>>> Am 23.12.2022 um 21:04 schrieb ooRexx >> >:
>>> 
>>> 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
>> 
>> 
>> ___
>> 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] Are we good to announce the release by tomorrow (23rd) ?

[René Jansen]

+1

> On 22 Dec 2022, at 14:10, Rony G. Flatscher  wrote:
> 
> Assuming that the rebuilds of the release version of the documentation and 
> installation packages go well by tomorrow, I would propose to officially 
> declare the release final by then.
> 
> This would allow us to announce the 5.0.0 release such that interested Rexx 
> programmers become aware of it and can download and "play" over the Christmas 
> vacation with it.
> 
> 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

Re: [Oorexx-devel] Wrong Apple version of ooRexx serviced by the Sourceforge website

[René Jansen]

I agree, and will enable some more admins of the SourceForge RexxLA repository, 
so we can do a release. This will mean we will not have to discuss this 
seemingly eternal issue here anymore, and the people that are worried by the 
label, can finally stop worrying. I think we owe that to ooRexx and all the 
work that has been done.

best regards.

René. 

> On 14 Dec 2022, at 09:34, Mike Cowlishaw  wrote:
> 
> I fear that if we just keep discussing things that need to be done another
> 10 years will pass.
> 
> Surely the priority here is to get 5.0 out there for most platforms, and
> worry about loose ends afterwards?
> 
> Mike
> 
> 
>> -Original Message-
>> From: Rony G. Flatscher [mailto:rony.flatsc...@wu.ac.at] 
>> Sent: 14 December 2022 13:24
>> To: oorexx-devel@lists.sourceforge.net
>> Subject: Re: [Oorexx-devel] Wrong Apple version of ooRexx 
>> serviced by the Sourceforge website
>> 
>> On 13.12.2022 16:59, P.O. Jonsson wrote:
 This was my point: currently all Apple users get outdated not 
 workable ooRexx by the official ooRexx site. ALLl official 
>> versions 
 of ooRexx for macOS are broken and do not install, not the 
>> 32 bit and 
 not the 64 bit version of ooRexx 4. We do not currently have ANY 
 official version of ooRexx that install with ANY Mac (Intel or 
 M1/ARM) running OS X El Capitan (2015) (OS X 10.11) or newer. This 
 problem is 7 years old :-(
>>> Dear Rony, I take that back, actually the official 64 bit 
>> version DOES work, and installs to /opt. I think this was my 
>> tinkering way back then. But /opt is a hidden folder on macOS 
>> so not so easy to find back once installed.
>>> 
>>> You still need to set PATH=/opt/ooRexx/bin:$PATH (and 
>> DYLD_LIBRARY_PATH=/opt/ooRexx/lib/ooRexx) to make it run and 
>> there is no uninstaller. But changing the pointer to 64 bit 
>> instead of 32 bit would be a good thing, also if the 4.1.2 is 
>> now 10 years old (September 2012).
>> 
>> Just tried it from my Mac and got as download offered a "4.0 
>> all" zip, which is also neither helpful nor useful for Apple 
>> users. So it is really time to get a nice, working and 
>> up-to-date version of ooRexx to the Apple table ...
>> 
>> ---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 "Sir Santa's Bag for 2022" ...

[René Jansen]

Me too. Let’s do it!

René.


> On 10 Dec 2022, at 18:21, P.O. Jonsson  wrote:
> 
> I am in favor of making an official release of ooRexx 5; It is building 
> without error on all platforms on Jenkins and with the exception of a few 
> glitches due to testing in a VM all tests pass on all platforms. In 
> particular Windows 10 and macOS Monterey pass all tests.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
>> Am 08.12.2022 um 14:41 schrieb Rony G. Flatscher > >:
>> 
>> The post  on the Linux 
>> on Z mailing list points the programmers to a set of updated programs. It is 
>> interesting among other things to note that it includes ooRexx! :)
>> 
>> It is ooRexx 4.2 though, which was released on  2014-02-24, almost nine and 
>> three quarters of a year ago.
>> 
>> The current ooRexx 5.0*beta* has many bugs of ooRexx 4.2 fixed, it has many 
>> more and very useful features, and it is noticeably faster! So - we all know 
>> that here - ooRexx 5.0*beta* would be definitely a huge improvement to 
>> anyone who has been using and deploying ooRexx 4.x!
>> 
>> Why not create a release "ooRexx 5.0" from the current trunk and remove 
>> "beta" from it? Continue with enhancing and fixing ooRexx 5.0 and have at 
>> least once a year a new version to be dubbed a "release" when it passes the 
>> ooRexx test suite without any show-stopper errors (preferably right before 
>> the yearly International Rexx Symposium).
>> 
>> Or maybe even a "rolling release": whenever changes occur, but the test 
>> suite passes without any show-stopper errors, place it in a release folder 
>> on SourceForge rather than in a beta folder. This way anyone - including 
>> companies - have the ability to download and use the latest version being 
>> sure that the test-suite ran without any show-stopper errors. It would also 
>> allow for an "up-to-date" feeling and having the world see that it gets 
>> continually enhanced!
>> 
>> If ooRexx 5.0 just had lost the word "beta" in it I am quite sure that the 
>> poster of "Sir Santa's Bag for 2022" would have included ooRexx 5.0 instead 
>> of the almost ten year old 4.2 version. Linux on Z user would then had been 
>> able to take advantage of all those great enhancements and improvements in 
>> ooRexx 5.0.
>> 
>> All it would take is a consensus among the developers and decide which 
>> version (the trunk version?) should be picked for a formal release to signal 
>> the world that it is good enough to be used in production.
>> 
>> ---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] Jenkins

[René Jansen]

Well, the Rockhopper which ran the IBMZ Jenkins client is a Z12 running z/VM 6.4 running Ubuntu for Z. As soon as the electrical power prices normalize it will be switched on again - according to the owner - and we can have a look. As an alternative we can try QEMU and see what that does.René.On 14 Nov 2022, at 11:42, P.O. Jonsson  wrote:Am 14.11.2022 um 15:41 schrieb Dave Jones :Hello, all.Does this problem occur when the virtual machines are hosted by a *real* hypervisor, namely z/VM? :-)I which I had a S/390 running z/VM to play with. And a nuclear reactor to power it with... Or is it just something that happens on VMWare?We use Oracle VirtualBox, not VMWare but I think it is the underlying (desktop) hardware that creates the timing fuss.MAny thanks.DJOn Sun, Nov 13, 2022 at 1:39 PM Mike Cowlishaw  wrote:




OK, thanks!

  
  
  From: Rick McGuire 
  [mailto:object.r...@gmail.com] Sent: 13 November 2022 
  11:13To: Open Object Rexx Developer Mailing ListSubject: 
  Re: [Oorexx-devel] Jenkins
  
  
  
  
  On Sun, Nov 13, 2022 at 5:57 AM Mike Cowlishaw 
   
  wrote:
  

 

  
I'm not familiar with internals of ooRexx, but reading 
this:
I tried to "tune" Virtualbox to get rid of the 
  timing error problems but every attempt actually made things 
  worse, with more than half of the timing tests failing. I have 
  reset Virtualbox to default values now. What *DID* help on the 
  other hand was to deprive the VMs of resources. Changing from 
  2 cores/4 GB memory to 1 core/ 2 GB memory made all *nixes 
  pass all tests, so it looks like the problem were related to 
  Virtualbox rather than to ooRexx. Only exception are the BSDs, 
  that are still a bit problematic to test. But all platforms (Win 
  macOS Linux Unix) build without error now.makes me 
wonder a bit: by reducing to one core then anything multithreadedis 
forced to run on a single thread which makes race conditions much 
lesslikely than when on multicore where multiple threads can run 
simultaneously.
  ooRexx is not truly multithreaded. Only one thread at a time is allowed 
  to run Rexx code at a time, with a cooperative internal dispatch mechanism. 
  Only threads running external code (e.g., calls to native libraries or running 
  commands) truly run concurrently.  Multiple cores might affect the timing 
  of which thread happens to get permission to run next, but which thread gets 
  permission has always been unpredictable. 
  
   
  


  

  Which means that there can be no unexpected time glitches between 
  threads since they run consecutively on one core. And that ooRexx handles 
  any such race conditions GREAT. This shows IMO how robust ooRexx 5 has 
  become. Gold standard ;-) 
Right, but in the real 
world it will be running on multicore 
  machines...
   
  The failing test cases run just fine on multicore machines, they only 
  seem to fail in multicore virtual machines. Also, the failures don't really 
  appear to be race conditions, but rather checks in timer values that are 
  falling outside expected ranges. There's something funny going on with the 
  clocks in the virtual machines in those situations. 
  
   
  

 
Mike ___Oorexx-devel 
mailing listOorexx-devel@lists.sourceforge.nethttps://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 listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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 update

[René Jansen]

Very good!René.On 13 Nov 2022, at 18:47, P.O. Jonsson  wrote:We now have a Manjaro Linux client running on Raspberry Pi 3B+ (SoC Broadcom BCM2837B0  CPU ARM Cortex-A53). Build and test worked on the first try without errors. I only have to figure out how to build a package and we have support for aarch64. 
Hälsningar/Regards/Grüsse,P.O. Jonssonoor...@jonases.se


___Oorexx-devel mailing listOorexx-devel@lists.sourceforge.nethttps://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: Questions for relevant presenters

[René Jansen]

Here some questions from Seymour on the mainframe list.

René.

Begin forwarded message:

> From: Seymour J Metz 
> Date: 7 September 2022 at 17:21:59 CEST
> To: presid...@rexxla.org
> Subject: Questions for relevant presenters
> 
> I have some questions that I would like to submit to the relevant presenters 
> at the upcoming 33rd International Rexx Language Symposium.
> 
> Is there a target GA date for ooRexx 5.0?
> 
> Is anybody working on KDE support for ooRexx, i.e., writing Plasma 
> applications in ooRexx?
> 
> Is anybody working on TSO support for ooRexx?
> 
> Is anybody working on UTF-8 support or named captures for the rxregexp?
> 
> Are there any plans to make the handling of SET prefix in THE compatible with 
> XEDIT?
> 
> Thanks.
> 
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Announcing the 33rd International Rexx Language Symposium, 2022

[René Jansen]

[intentionally cross-posted]

Dear RexxLA members,

The 33rd International Rexx Language Symposium (2022) will be on September 
12-14, with an optional programme on the preceding Sunday.

Like last year, the symposium will be online and conducted via zoom. Also like 
last year, the schedule will be adapted to the time zones in the US and Europe. 
(For other geographies we might re-run some of the presentations - it is our 
firm intention to have some of the presentations available on video this year).

The International Rexx Language Symposium is a yearly event where Rexx users, 
irrespective of implementations and language variants, can meet and mingle. The 
programme committee which judges the presentation proposals consists of the 
President and the Vice President of RexxLA - that is myself and Terry Fuller. 
Please send in your presentation proposals! The separate Call For Papers (CFP) 
will shine more light on this process and its requirements.

Apart from the presentations (which are readable from the RexxLA.org 
<http://rexxla.org/> website right after the presentations takes place, and 
which are often used a reference material), this yearly symposium is also a 
great opportunity to meet your fellow Rexx users, the implementors of the 
various variants, and - if we are lucky - a Q Session with the Father of Rexx 
himself, IBM Fellow Michael Cowlishaw. 

This year there will be even more Q sessions, and social events where we 
leave the session and its microphones and cameras open - and we will even 
experiment with parallel- and breakout sessions (if we understand how to do 
these in Zoom in time). There will be presentations on Classic (including 
mainframe) Rexx on TSO (ISPF) and CMS, Regina Rexx, NetRexx for the JVM world, 
and Open Object Rexx. Also, new implementations will be discussed.

Hope to see you all!

Best regards,

René Jansen,

President, Rexx Language Association.___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [devel] ooRexx 5.0 GA

[René Jansen]

Hi Leslie,

Yes, it seems that ’specs’ keeps growing and growing. The good news is that in 
our implementation Jeff did a separate part for inputRange and if it works 
there, it should work everywhere.
For clarity, I did not try this because at the moment, I did what I would do in 
Rexx.

René.

> On 22 Jun 2022, at 22:11, J Leslie Turriff  wrote:
> 
> René,
>   I see that in this pipeline you use reverse with specs to trim trailing 
> parts of your 
> records. I understand that the nrx specs stage does not yet completely 
> emulate the CMS 
> specs stage, but I hope that as it is improved it will fully support CMS-type 
> inputRange 
> notation.
>   In CMS/TSO Pipelines, Author's Edition, pp. 165, 166 we see that
> | "An inputRange can contain a negative number; this specifies that the 
> count is from the
> | end of the record rather than from the beginning:
> | word -2 1
> | The general form of a range consists of two numbers separated a 
> semicolon. Thus, there
> | is a third idiom to refer to the entire record: 1;-1. When both numbers are 
> positive,
> | there is no difference between using semicolon and using a hyphen to 
> delimit the 
> numbers. When the two numbers have the same sign, the first number must be 
> less than or 
> equal to the second one; it is an error to specify an ending column that is 
> before the 
> beginning one. (Recall that -2 is less than -1.) When the numbers have 
> different signs, 
> a null input field is used when the beginning position is after the end 
> position:
> | word 2;-2 1
> 
>   Thus, your pipeline could eventually use
> | :
> | | specs 7;-2 1
> | :
> | | specs 77;-10 1
> | :
> 
> Leslie
> 
> On 2022-06-22 05:55:59 René Jansen wrote:
>> I think so too. This is why I built the following pipeline to make sure
>> this page is updated daily:
>> 
>> ➜ test git:(master) cat oorexx_downloads.nrx
>> out =''
>> address pipe with output stem out
>> 
>> 'pipe (pipnm) literal curl
>> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ '- '|
>> command '-
>> '| split '-
>> '| locate +href="https://sourceforge.net/projects/oorexx/files+ '-
>> '| nlocate /readme.md/ specs 7-* 1 '-
>> '| reverse '-
>> '| specs 2-* 1 '-
>> '| reverse '-
>> '| o: fanout '-
>> '| specs 77-* 1 '-
>> '| reverse '-
>> '| specs 10-* 1 '-
>> '| reverse '-
>> '| b: juxtapose '-
>> '| sort desc '-
>> '| specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw '-
>> '| change /href/ /] (href/ '-
>> '| cons ? o: '-
>> '| insert / / '-
>> '| b:'
>> 
>> do i=1 to out[0]
>> say out[i]
>> end
>> 
>> As you can see, it takes the RSS feed from SF and turns it into a Markdown
>> page. I will have something by the end of this week.
>> 
>> Best regards,
>> 
>> René.
> -- 
> Operating System: Linux
> Distribution: openSUSE Leap 15.4 x86_64
> java version "18" 2022-03-22
> NetRexx portable processor 4.03-GA build 260-20220503-1730
> 
> 
> ___
> 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

Re: [Oorexx-devel] ooRexx 5.0 GA

[René Jansen]

I think it *should* work on ooRexx, but after changing ‘out' to ‘out.' and 
changing the line continuations from ‘-‘ to ‘,’ (and commenting out the output 
loop) I only get an RC(30). ‘Pipe’ is just an executable known to PATH 
(actually a zsh alias, but I also tried with Marc’s ‘pipe’ shell script). So I 
leave that to the ooRexx specialists.

René.

> On 22 Jun 2022, at 16:00, P.O. Jonsson  wrote:
> 
> Ok, did not realize when asking that you were running this on NetRexx 
> 
> The pipe seems neat as well, never used it though.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
> 
>> Am 22.06.2022 um 15:58 schrieb René Jansen > <mailto:rvjan...@xs4all.nl>>:
>> 
>> Hi P.O.,
>> 
>> It is embedded in a NetRexx program. As it does not have stems (but indexed 
>> strings with [ ] I cannot specify a dot (but need not specify it either). I 
>> am tempted to try if Gil’s example works!
>> 
>> René.
>> 
>>> On 22 Jun 2022, at 14:24, P.O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> 
>>> Off Topic:  You have the stem name without the dot (.) whereas I have 
>>> always used it dotted. This is what I did in a recent script (to find back 
>>> my other server when it failed to register DDNS correctly)
>>> 
>> 
>> ___
>> 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 5.0 GA

[René Jansen]

Hi P.O.,

It is embedded in a NetRexx program. As it does not have stems (but indexed 
strings with [ ] I cannot specify a dot (but need not specify it either). I am 
tempted to try if Gil’s example works!

René.

> On 22 Jun 2022, at 14:24, P.O. Jonsson  wrote:
> 
> Off Topic:  You have the stem name without the dot (.) whereas I have always 
> used it dotted. This is what I did in a recent script (to find back my other 
> server when it failed to register DDNS correctly)
> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] ooRexx 5.0 GA

[René Jansen]

I think so too. This is why I built the following pipeline to make sure this 
page is updated daily:

➜  test git:(master) cat oorexx_downloads.nrx
out =''
address pipe with output stem out

'pipe (pipnm) literal curl 
https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ '-
'| command '-
'| split '-
'| locate +href="https://sourceforge.net/projects/oorexx/files+ '-
'| nlocate /readme.md/  specs 7-* 1 '-
'| reverse '-
'| specs 2-* 1 '-
'| reverse '-
'| o: fanout '-
'| specs 77-* 1 '-
'| reverse '-
'| specs 10-* 1 '-
'| reverse '-
'| b: juxtapose '-
'| sort desc '-
'| specs /[/ 1 1-5 nw 7-11 nw 13-* nw /)/ nw '-
'| change /href/ /] (href/ '-
'| cons ? o: '-
'| insert / / '-
'| b:'

do i=1 to out[0]
  say out[i]
end

As you can see, it takes the RSS feed from SF and turns it into a Markdown 
page. I will have something by the end of this week.

Best regards,

René.

> On 21 Jun 2022, at 22:07, P.O. Jonsson  wrote:
> 
> I think the documentation pointers should point to Sourceforge
> 
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/ 
> <https://sourceforge.net/projects/oorexx/files/oorexx-docs/>
> 
> with the appropriate subfolder renamed (currently 5.0.0beta) 
> 
> The documentation can be built automatically (some work needed still to 
> rebuild only the changed docs + upload)
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 21.06.2022 um 21:34 schrieb Terry Fuller > <mailto:t...@pgmguild.com>>:
>> 
>> On the topic of documentation...
>> 
>> I don't want to connect the website issues as showstoppers for a 5.0 GA 
>> release, but...
>> 
>> All of the documentation pointers in oorexx.org/doc <http://oorexx.org/doc> 
>> result in 404 errors.  If memory serves (and sometimes it doesn't, 
>> corrections gratefully received) we now have Jenkins producing both PDF and 
>> html documentation... can that be set up to push the build results to the 
>> website? alternatively, change the links to point to the built files?
>> 
>> Along those lines... the oorexx product brochure is pretty badly out of date 
>> (touts the wonderful 32-bit implementations  ). Once 5.0 is GA the brochure 
>> really should be updated... also might be better implemented in something 
>> more open source than ms.ppt.
>> 
>> On 2022-06-21 05:06, René Jansen wrote:
>>> Another thing was documentation. There has been a lot of work done by Gil 
>>> (and Jon and P.O. - afraid I am forgetting someone).
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net 
>>> <mailto:Oorexx-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>> 
>> -- 
>> taf
>> 
>> 
>> 
>> ___
>> 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

Re: [Oorexx-devel] ooRexx 5.0 GA

[René Jansen]

This from 2019. I will finish the website shortly. (This week).

I am against a freeze, as I've got some changes in the works that I'd
really like to get into the 5.0 release.

Rick

On Tue, Jan 15, 2019 at 10:46 AM René Jansen  wrote:

> I am for it, but I think it is up to Erich and Rick.
>
> To be precise, I am for freezing, setting a date and prepare. I would like
> to have the oorexx.org <http://oorexx.org/> website up to date before we 
> announce. I did some
> work last year, which is accessible through oorexx.org/index2.html 
> <http://oorexx.org/index2.html> , but
> I need to finish that. Also - documentation. We must be able to build it in
> a repeatable fashion and not when someone’s pc has the right configuration.
> We are working towards that, albeit slowly.
>
> I was planning for the symposium, but I can imagine it would be better if
> we did it earlier.
>
> My proposal: freeze now and release March 1st.
>
> best regards,
>
> René.
>
> On 15 Jan 2019, at 10:15, Rony G. Flatscher 
> wrote:
>
> What would be the thoughts about releasing the current trunk version of
> ooRexx 5.0 as "general
> available"?
> (In order for organisations/companies to adopt 5.0 or to replace older
> versions of Rexx/ooRexx with
> 5.0 it would be necessary that it becomes officially GA.)
>
> It would be still possible to create some ooRexx 5.1, 5.2 and the like
> shortly after a GA release,
> if new functionality would be added to it (e.g. applying sandbox
> development results or implementing
> RFEs).
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorex...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>
>
> ___
> Oorexx-devel mailing list
> Oorex...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel>
>




> On 21 Jun 2022, at 13:57, René Jansen  wrote:
> 
> Hi Terry,
> 
> I am happy that you are taking this up. Yes, there was a list some time ago; 
> Jon and P.O. might have done better bookkeeping - I cannot find it now. From 
> memory:
> 
> 1) Website very outdated
> 2) Mac installer missing (now a dmg installer is there)
> 3) Some showstoppers yet (cannot remember, but speed decrease flagged by 
> Walter and others)
> 
> Maybe it is best to use the SourceForge issue tracking for this purpose; sort 
> the issues into version 5.0.0 and beyond, solve the 5.0.0 issues - then 
> release.
> 
> Best regards,
> 
> René.
> 
>> On 17 Jun 2022, at 21:10, Terry Fuller  wrote:
>> 
>> Is there a list somewhere of showstoppers which are preventing 5.0 from 
>> going GA?
>> 
>> If so, can someone point me to it?
>> 
>> If not, can I serve as a clearinghouse for reports of showstoppers?
>> 
>> -- 
>> taf
>> 
>> 
>> 
>> ___
>> 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] ooRexx 5.0 GA

[René Jansen]

This from 2018:

On Sun, Jun 17, 2018 at 8:21 AM Rony G. Flatscher 
wrote:

> Almost a month has passed since my last posting, so assuming that everyone
> is just in "wait and see"
> mode. Therefore throwing another stone into the water: how about releasing
> the current 5.0 Beta this
> coming week?
> :)
>
> Or are there any showstoppers anyone sees? Is there anything that is
> currently missing and needs to
> be done?
>

There are still a number of bugs and features that still need doc or test
work before they can be placed in a pending state. There's also not been
any work on a Mac installer created.


>
> When suggesting the current beta, mentally I included the great new
> features "address with" and
> variable references from Rick's sandbox (for each there is a 64-bit
> Windows ooRexx installation
> package at: <
> https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0>). 
> <https://www.dropbox.com/sh/olh1mqfwb4brp7r/AABI1X-Le9zDCJ0gyfvMdKB8a?dl=0%3E).>
> AFAIK they
> are not in trunk and hence may need to be added to trunk and maybe it may
> make sense to create one
> more ooRexx 5.0 beta to get it tested on a wider scale for a few weeks.
> Alternatively, after
> releasing the current 5.0 beta as GA, these new features may get added to
> trunk and cause a new 5.1
> beta version to be created which may be released sometimes in the fall.
>

There's still a bit a doc and possibly some more testing work needed with
the address with and variable reference features.



>
> Ad rsock6: not seeing any commits in the repository not sure about its
> state. However, like with
> Unicode, in the case that IPv6 is really needed for the time being one can
> use the ooRexx external
> function package BSF4ooRexx to get access to it from ooRexx (in this case
> even SSL etc. becomes
> available to ooRexx programmers).
>
> At this point, I'd say that rxsock6 should not be included. Work sort of
stalled when I had to go without internet service for over 3 weeks. David's
code had a lot of issues and needed a complete redo. There are no tests
written for this and it will also need new documentation written. This will
need to be snipped out of the trunk build and moved to a sandbox before a
release candidate can be created.

Rick


> On 21 Jun 2022, at 14:06, René Jansen  wrote:
> 
> Another thing was documentation. There has been a lot of work done by Gil 
> (and Jon and P.O. - afraid I am forgetting someone).
> 
>> On 21 Jun 2022, at 13:57, René Jansen  wrote:
>> 
>> Hi Terry,
>> 
>> I am happy that you are taking this up. Yes, there was a list some time ago; 
>> Jon and P.O. might have done better bookkeeping - I cannot find it now. From 
>> memory:
>> 
>> 1) Website very outdated
>> 2) Mac installer missing (now a dmg installer is there)
>> 3) Some showstoppers yet (cannot remember, but speed decrease flagged by 
>> Walter and others)
>> 
>> Maybe it is best to use the SourceForge issue tracking for this purpose; 
>> sort the issues into version 5.0.0 and beyond, solve the 5.0.0 issues - then 
>> release.
>> 
>> Best regards,
>> 
> 
> 
> 
> ___
> 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 5.0 GA

[René Jansen]

Another thing was documentation. There has been a lot of work done by Gil (and 
Jon and P.O. - afraid I am forgetting someone).

> On 21 Jun 2022, at 13:57, René Jansen  wrote:
> 
> Hi Terry,
> 
> I am happy that you are taking this up. Yes, there was a list some time ago; 
> Jon and P.O. might have done better bookkeeping - I cannot find it now. From 
> memory:
> 
> 1) Website very outdated
> 2) Mac installer missing (now a dmg installer is there)
> 3) Some showstoppers yet (cannot remember, but speed decrease flagged by 
> Walter and others)
> 
> Maybe it is best to use the SourceForge issue tracking for this purpose; sort 
> the issues into version 5.0.0 and beyond, solve the 5.0.0 issues - then 
> release.
> 
> Best regards,
> 



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] ooRexx 5.0 GA

[René Jansen]

Hi Terry,

I am happy that you are taking this up. Yes, there was a list some time ago; 
Jon and P.O. might have done better bookkeeping - I cannot find it now. From 
memory:

1) Website very outdated
2) Mac installer missing (now a dmg installer is there)
3) Some showstoppers yet (cannot remember, but speed decrease flagged by Walter 
and others)

Maybe it is best to use the SourceForge issue tracking for this purpose; sort 
the issues into version 5.0.0 and beyond, solve the 5.0.0 issues - then release.

Best regards,

René.

> On 17 Jun 2022, at 21:10, Terry Fuller  wrote:
> 
> Is there a list somewhere of showstoppers which are preventing 5.0 from going 
> GA?
> 
> If so, can someone point me to it?
> 
> If not, can I serve as a clearinghouse for reports of showstoppers?
> 
> -- 
> taf
> 
> 
> 
> ___
> 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

[René Jansen]

Hi P.O.,

For NetRexx, which is also built on this machine, there is no impediment to 
move to Java 11 or higher.

Best regards,

René.


> On 21 Apr 2022, at 23:05, P.O. Jonsson  wrote:
> 
> I have just updated Jenkins Controller to the latest version and upgraded all 
> plugins and all went well. There is however a warning:
> 
> "You are running Jenkins on Java 1.8, support for which will end on or after 
> September 1, 2022. Please refer to the documentation 
>  for 
> details on upgrading to Java 11."
> 
> I have used Java 1.8 in most places of Jenkins in the past, including all the 
> agents and in the Controller, and I seem to remember there was an issue with 
> Java 11 for the nginx server used for https support so I am hesitant to do 
> this change, but I guess it is inevitable at some point. Any objections if I 
> give it a try? Is there a reason why we should not go to JAVA 11?
> 
> If you have planned work to commit let me know and I will postpone it, there 
> is still plenty of time.
> 
> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] SourceForge ssh certs do not work

[René Jansen]

Please be advised that SourceForge’s certificates for passwordless ssh login 
(this includes svn+ssh and git operations) do not for for over 8 hours now, so 
you’ll need your password and automated processes that use it, won’t work.

best regards,

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[René Jansen]

One comment on homebrew - don’t choose your own location, but always take the 
default. Some packages do not treat the deviation well, but will not tell you, 
and will, e.g. always build from source and disregard things that are already 
there, so you’ll see gcc and openssl built from source every time, which will 
only heat up your laptop and is not very useful, especially when the package 
build fails anyway.

And always have a large scroll back buffer, because indeed homebrew is very 
talkative, but you need to go over it in detail after an install, yo make sure 
you can find includes or link to libraries later. I still prefer it over 
MacPorts.

Best regards,

René.

> On 31 Jan 2022, at 12:48, Rony G. Flatscher  wrote:
> 
> Hi Mark,
> 
> On 31.01.2022 01:27, Mark Hessling wrote:
>> As P.O. says, Homebrew installs its binaries in /Cellar and 
>> symbolically links those
>> binaries to /usr/local/bin. However, if the package you are installing is 
>> already supplied by
>> Apple in macOS, it DOES NOT do the symbolic link.  In your case ncurses is 
>> supplied by Apple so
>> the symbolic link is not done by HomeBrew.  It does tell you this when you 
>> are installing. So to
>> get the Homebrew version of ncurses, you may have to manually link the 
>> files, or set environment
>> variables so the HomeBrew version is loaded first. 
> 
> thank you very much!
> 
> 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] Apple: cannot build universal orxncurses, linking error, wrong ncurses being picked up, however if ...

[René Jansen]

Tried this on M1, no problem.
Tried this on X86_64, no problem

Both on 12.2, I use ninja for building the CMake-generated stuff, only 
difference is that I use brew and not ports.
There is always some movement needed when upgrading macOS, I mostly do that by 
starting the Xcode GUI once and doing a

xcode-select —install

From the command line. Sometimes that tells me to sudo, which I then do.

Best regards,

René.


> On 30 Jan 2022, at 18:46, Rony G. Flatscher  wrote:
> 
> Upgraded my Intel Apple to macOS Monterey, version 12.2. 
> 
> Using MacPort which got updated as well. MacPort will install its libraries 
> to /opt/local/lib which includes ncurses.
> 
> Downloaded a fresh, pristine version of ooRexx from trunk and started to 
> create a universal build with: 
> 
> cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_OSX_UNIVERSAL_BINARIES=1  
> ~/dev/oorexx_allura/main/trunk
> -- CMake version is 3.22.2
> -- The C compiler identification is AppleClang 12.0.5.12050022
> -- The CXX compiler identification is AppleClang 12.0.5.12050022
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: 
> /Library/Developer/CommandLineTools/usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: 
> /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Building for a 64-bit architecture
> -- OOREXX_SHEBANG_PROGRAM: "/usr/bin/env rexx" (default)
> -- Found Subversion: /opt/local/bin/svn (found version "1.14.1") 
> -- SVN Revision Number is 12352
> -- CMAKE_INSTALL_PREFIX is /Users/rony/Applications/ooRexx5
> -- INSTALL_LIB_DIR is lib
> -- Looking for xlocale.h
> -- Looking for xlocale.h - found
> -- Looking for malloc.h
> -- Looking for malloc.h - not found
> -- Looking for alloca.h
> -- Looking for alloca.h - found
> -- Looking for signal.h
> -- Looking for signal.h - found
> -- Looking for time.h
> -- Looking for time.h - found
> -- Looking for inttypes.h
> -- Looking for inttypes.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for nsleep
> -- Looking for nsleep - not found
> -- Looking for nanosleep
> -- Looking for nanosleep - found
> -- Looking for crypt in crypt
> -- Looking for crypt in crypt - not found
> -- Looking for crypt
> -- Looking for crypt - found
> -- Looking for wordexp
> -- Looking for wordexp - found
> -- Looking for wordexp.h
> -- Looking for wordexp.h - found
> -- Looking for sys/xattr.h
> -- Looking for sys/xattr.h - found
> -- Looking for catopen
> -- Looking for catopen - found
> -- Looking for dlfcn.h
> -- Looking for dlfcn.h - found
> -- Looking for features.h
> -- Looking for features.h - not found
> -- Looking for filehdr.h
> -- Looking for filehdr.h - not found
> -- Looking for euidaccess
> -- Looking for euidaccess - not found
> -- Looking for nl_types.h
> -- Looking for nl_types.h - found
> -- Looking for pthread.h
> -- Looking for pthread.h - found
> -- Looking for pthread_mutex_timedlock
> -- Looking for pthread_mutex_timedlock - not found
> -- Performing Test HAVE_DLADDR
> -- Performing Test HAVE_DLADDR - Success
> -- Looking for _PC_CASE_SENSITIVE
> -- Looking for _PC_CASE_SENSITIVE - found
> -- Looking for FNM_CASEFOLD
> -- Looking for FNM_CASEFOLD - found
> -- Looking for KDMKTONE
> -- Looking for KDMKTONE - not found
> -- Looking for FS_CASEFOLD_FL
> -- Looking for FS_CASEFOLD_FL - not found
> -- Looking for _NSGetExecutablePath
> -- Looking for _NSGetExecutablePath - found
> -- Looking for getexecname
> -- Looking for getexecname - not found
> -- Looking for KERN_PROC_PATHNAME
> -- Looking for KERN_PROC_PATHNAME - not found
> -- Looking for KERN_PROC_ARGV
> -- Looking for KERN_PROC_ARGV - not found
> -- Performing Test HAVE_STAT_ST_MTIM
> -- Performing Test HAVE_STAT_ST_MTIM - Failed
> -- Performing Test HAVE_STAT_ST_MTIMESPEC
> -- Performing Test HAVE_STAT_ST_MTIMESPEC - Success
> -- Looking for pwd.h
> -- Looking for pwd.h - found
> -- Looking for sched.h
> -- Looking for sched.h - found
> -- Looking for strings.h
> -- Looking for strings.h - found
> -- Looking for sys/filio.h
> -- Looking for sys/filio.h - found
> -- Looking for sys/ldr.h
> -- Looking for sys/ldr.h - not found
> -- Looking for sys/resource.h
> -- Looking for sys/resource.h - found
> -- Looking for sys/select.h
> -- Looking for sys/select.h - found
> -- Looking for sys/sem.h
> -- Looking for sys/sem.h - found
> -- Looking for sys/signal.h
> -- Looking for sys/signal.h - found
> -- Looking for sys/time.h
> -- Looking for sys/time.h - found
> -- Looking for sys/utsname.h
> -- Looking for sys/utsname.h - found
> -- Looking for sys/wait.h
> -- Looking for sys/wait.h - found
> -- Looking for wsyncup in /opt/local/lib/libcurses.dylib
> -- Looking for wsyncup in /opt/local/lib/libcurses.dylib 

[Oorexx-devel] 32nd Rexx Symposium Seminar Day starts in 5 hours

[René Jansen]

Dear Rexx users,

Now that we are all out of Daylight saving time, the timezone situation 
hopefully has become more straightforward. The symposium is starting today at 
16:00h UTC, which is 17:00h CET, Amsterdam time.
The Rexxla.org homepage, ’schedule’ button, should bring you to the schedule 
where the session starting times should be in your own timezone. 

This page also contains the Zoom link, which will be refreshed every day. For 
today it is:

Topic: 32nd International Rexx Language Symposium Seminar day
Time: Nov 7, 2021 17:00 Amsterdam

Join Zoom Meeting
https://us02web.zoom.us/j/81333063496?pwd=QTUrMmc2VjluUmVNMEQvalI5bzFQdz09

Meeting ID: 813 3306 3496
Passcode: rexx

Today Prof. Flatscher will run his seminars on ooRexx, Open Object Rexx. The 
have been selected by the organising committee because they are of great value.

It now is 12:05 in Amsterdam, this means the symposium seminar day is starting 
in slightly less than 5 hours - hope to see you all there!

Best regards,

René Vincent Jansen
President, RexxLA.




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Jenkins

[René Jansen]

Hi P.O.,

I did that some two years ago in a previous job with Windows 10, WSL and a 
Ubuntu installed from the Microsoft store. But I remember there was something 
funny with the Windows machine that made that scenario fail every 5 days or so 
(I suspected clock skew at the time, but I was happy to dump that machine).

The bios setting for ‘restart after power failure’ should work, though.

Best regards,

René.


> On 20 Sep 2021, at 10:46, P.O. Jonsson  wrote:
> 
> Hi Erich and thanks, I have done just that and even set up an Agent to start 
> all the VMs. Unfortunately it does not work and also this machine does not 
> come back up again after power off (which it should) so I will leave it on 
> for the time being, I have updated Virtualbox and installed all updates on 
> all the VMs, some 100s of updates. There is some problem with CentOS, will 
> fix that in the coming days.
> 
> If you have any idea on how to make passwordless ssh from a Mac to a Windows 
> machine I would be glad to hear about it. Mac to Linux/Unix is no problem but 
> I cannot make the Windows ssh server respond correctly, not on Windows 7, 8.1 
> or 10.
> 
> PS Do we have a Windows 11 available for testing yet?
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 19.09.2021 um 10:47 schrieb Erich Steinböck > >:
>> 
>> Hi P.O,
>> If this is an option I can put this machine on a separate switch and make it 
>> available with short term (1/2 day) notice.
>> As it is now it is idle 99% of the time and it is a waste of energy to have 
>> it up all the time.
>> I totally understand and agree.
>> 
>> If easier to implement you might make the VMs available for e.g. just one 
>> hour per day on midnight.
>> Any Jenkins jobs would wait until the VM becomes available at the given time.
>> 
>> ___
>> 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

[René Jansen]

Well yes you asked the developers … they should check Jenkins to see if they 
broke other platforms. If you ask me, then I would suggest some more energy 
efficient platform, or maybe a raspberry that checks if there were updates and 
then trigger a relay that restores current to the build machine. If you then 
tell the bios of that machine to resume after power loss, you can just set the 
hibernate on that machine to kick in when it’s idle. Instead of a relay (which 
I like because it leaves no doubt if the machine is off, I used IKEA’s stuff), 
you can combine hibernate and wake-on-lan. But course it is your machine, your 
home and your choice.

If push comes to shove we might use RexxLA’s cloud instance for build machine, 
or have a separate instance for that purpose.

Best regards,

René.

> On 17 Sep 2021, at 16:49, P.O. Jonsson  wrote:
> 
> I had expected some explicit approval/disaproval on my request :-( Given the 
> silence I will shut down the virtual machines tonight until further activity 
> makes it necessary to start them again.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
> 
> 
> 
>> Am 16.09.2021 um 21:20 schrieb P.O. Jonsson :
>> 
>> The Jenkins system is running fine for most of the time now but in view of 
>> the low number of commits currently I have a request: I would like to turn 
>> of the machine hosting all virtual machines (currently 11), and turn it on 
>> only when there is major activity. The reason being that the machine is 
>> heating my study with +5 degrees even when its s in standby (200-250 watt 
>> permanently). Would that be acceptable to the developers?
>> 
>> 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 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] Planned commits

[René Jansen]

Hi P.O.,
I had one that ran uninterrrupted from 2006 to last June - 2021 - and I 
switched it off because it made a noise and I did not want it to run 
unsupervised on Aruba, and catch fire. But there must be more people who have 
one … and yes, it was a joke, but with a serious part: I think that if we had 
chosen to distribute fat binaries, we still would have a Power/Intel 
distribution; which I don’t think is what we need.

René.

> On 16 Sep 2021, at 21:12, P.O. Jonsson  wrote:
> 
> Dear René,
> 
> When you write
>> 
>> Power on the Mac
> 
> Do you mean Power-PC driven Mac Pro? The last one sold was in 2005, some 16 
> years ago, is that REALLY something we should support? OR did I misunderstand 
> you remark?
> 
> PS If you had requested it two days earlier I could have brought one back 
> from my supply in Sweden :-)
> ___
> 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] Planned commits

[René Jansen]

Hi Rony,

On the first one I don’t really have an opinion, except that we should avoid 
the patch going stale. On the second one: it should be a welcome addition, but 
I doubt we really need it now. 
Reasons:

- Not a fan of fat binaries: they tend to stay fat until unsupported
- ooRexx currently builds fine (and fast!) on M1
- there should be a decision on what to distribute.

Personally, I would be fine with a Mac distribution for X86_64 and another for 
ARM64/aarch64 - we have separate Windows distributions also, and in fact it 
would be great if someone built it for Power on the Mac because not everybody I 
know got rid of those. We probably also need future differences in Apple OS 
versions due to the ever-annoying additional security work they are doing: save 
file - do you give the application you are using access to your disk? Yes/no - 
can you authenticate yourself (again)? Another favourite is the quarantine-bit: 
you are opening an application (really?) that you downloaded from the internet 
(really? Did I?). Do you want to put it in the bin?

But: that is no reason not to integrate the patch with the option. Would be 
great if Enrico would do that … but if he does not feel like it, maybe P.O. can 
have a look.

Best regards,

René.  

> On 14 Sep 2021, at 18:18, Rony G. Flatscher  wrote:
> 
> As long as there is no architecture review board (ARB) in effect and 
> developers in "land under water" mode that hinders them to communicate, I 
> would like to apply the classic rule: "silence counts as approval" for the 
> following planned changes/patches:
> 
> concurrency trace: this is a tested, important feature as it is for the first 
> time that one becomes able to really trace concurrently executing Rexx 
> programs; this is especially helpful for students who learn programming and 
> must apply their acquired skills also in mastering concurrently executing 
> Rexx programs (e.g. when debugging GUI applications from awt/swing and/or 
> JavaFX); in this context also the documentation needs to be supplemented 
> which I would do (in the area of the existing RXTRACE section in 
> rexxref.pdf), RFE with 
> patch: 
> ,
> 
> extract and commit the CMake definitions from Enrico's patch to allow ooRexx 
> on MacOS to be optionally built as a universal binary such that ooRexx can 
> run with the same binary on Intel and M1 computers.
> Will wait at least a week such that there is enough time for consideration 
> and communication.
> 
> ---rony
> 
> P.S.: Also, if time permits (unfortunately I am also in "land under water" 
> mode myself) I would like to add the ability to create "stick"-versions of 
> ooRexx, such that up-to-date versions can be created each time ooRexx gets 
> compiled. 
> 
> 
> 
> ___
> 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] rxsnippets

[René Jansen]

Hi Enrico,

I tried to pull from your RxSnippets repo but it was not to be found - when 
googling I found some other RxSnippets, but more to do with RxSift and Kotlin.
Is it somewhere else now?

best regards,

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] ooRexx and Apple's "security police" on MacOS

[René Jansen]

Running 

sudo xattr -r -d com.apple.quarantine $YOUR_DIRECTORY 

mostly helps.

René

> On 16 Jul 2021, at 14:10, P.O. Jonsson  wrote:
> 
> What version of MacOS are we talking about? In the past extracting the .dmg 
> caused a warning that could be overwritten but I never experienced that rexx 
> would not launch? Is this a M1 thing only? Or „Fat Binary“ problem? Does it 
> help to install to ~/Applications (a local install) rather than to 
> /Applications (Install for all users)? 
> 
> I run High Sierra (10.13) and the build machine runs Mojave (10.14). In view 
> of the age of the build machine (~ late 2014) I would not go beyond Catalina 
> (10.15) and I see no gain in changing, just risk of running into problems 
> with outdated hardware.
> 
> We do not have at our disposal any machine with macOS Big Sur (11.1) that can 
> run on either Intel or M1 hardware.
> 
> What I can try to do is to see if I can get some Virtual Machines set up with 
> Catalina/Big Sur. But it will not be on M1 hardware.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 16.07.2021 um 13:47 schrieb Rony G. Flatscher > >:
>> 
>> Downloaded the latest MacOS version of ooRexx 5.0 from the ooRexx project 
>> page at sourceforge. 
>> 
>> It turns out that Apple inhibits using anything from that dmg as it was 
>> downloaded from the Internet and not from Apple's store! :(
>> 
>> This is due to Apple's "security policy" that they put in effect, which 
>> simply deprive the owners of those Apple computers. 
>> 
>> Here are two use cases, each demonstrated with an attached screenshot:
>> 
>> Scenario 1: installing ooRexx according to the readme will create 
>> "/Application/ooRexx5" with the "bin", "lib" etc directories. Trying to run 
>> "/Application/ooRexx5/bin/rexx -v" causes "Screenshot 2021-07-16 at 
>> 12.46.04.png" to pop up. Apple suggests to move the program to the bin! :-(
>> 
>> Scenario 2: using Finder to "open" (run) "/Application/ooRexx5/bin/rexx" 
>> yields at first a pop up that seems to indicate, that further opening would 
>> allow the program to run from now on, cf. "Screenshot 2021-07-16 at 
>> 12.53.17.png". However when "rexx" loads the "librexx.4.dylib" the "Move to 
>> Bin" popup as above gets displayed!
>> Probably turning off SIP 
>> (
>>  
>> )
>>  will allow this to work again, however, asking users to turn off SIP may be 
>> too much.
>> 
>> The alternative would be to get and use the keys from Apple and use them to 
>> sign the ooRexx executables. 
>> 
>> The question then is, who should apply/buy this: RexxLA or some individual 
>> developer in this group who signs the releases? Who is going to pursue this?
>> 
>> ---rony
>> 
>> P.S.: @Enrico: this may be also the reason why on M1 with a stricter 
>> "security policy" in place would not pick the amd64 binaries from the fat 
>> distribution! If you look at the first screen shot you can read "Reason: no 
>> suitable image found.", the same error message as on M1, but here there is 
>> additional information pointing ad "Library Validation: ..." that fails.
>> 
>> This behavior might not be present if you create ooRexx on the M1 and run it 
>> from there, as then the binaries did not come from "insecure locations" 
>> according to Apple (which is the Internet and locations that are not under 
>> the control of Apple software). 
>> 
>> 
>> 
>> > 12.53.17.png>___
>> 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] rxsocket example

[René Jansen]

Hi Terry,

just for my understanding of what you mean: you instantiated an object, which’ 
particular purpose was to open a tcp socket. The fact that this did go wrong, 
does not mean you cannot send the object a message of ‘let me know the error 
code of what happened when you tried to open the socket’. You are not sending 
anything over the socket (it is most prpbably not there) - you are 
communicating with your object.

Or seems something else wrong?

best regards,

René.

> On 12 Jul 2021, at 21:34, Terry Fuller  wrote:
> 
> Hello all, 
> 
> I'm working my way thru a project that makes use of rxsockets.   in 
> 
> ooRexx Documentation 5.0.0 
> Open Object Rexx RxSock TCP/IP Socket Functions Reference
> Edition 1
> 
> i found:
> 
>  -- get a new socket
>  s = .socket~new()
>  if s = -1 then do
>  say 'Error' s~errno() 'creating server socket'
>  return
>  end
> 
> but... if s is -1, sending a message to it to extract an error message number 
> seems wrong; at least to me.  Am I missing something?
> 
> -- 
> taf
> ___
> 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] [RexxLA] Dir or Not

[René Jansen]

Hi Andy,

to be on the safe side, I’d open a ticket with the ooRexx team. Also, which 
version? There has been lot of activity on the Sys*File* OS specific parts. So 
it might be solved - or it shows that the main developers have Windows 
machines, in which case this needs to be added to the test suite.

Does it also happen outside of RexxTry?

Cross-posted, by me, to oorexx-devel.

best regards,

René.

> On 17 Jun 2021, at 07:25, Andy McMenemy  wrote:
> 
> Gentlefolk... I could do with a little help (or a slap round the head).
> I have a remotely mounted drive (on Linux) and I wish to use one of its 
> subdirectories. I am, however, getting a response that is currently baffling 
> me...
> 
> I have use REXXTRY to illustrate...
> Firstly let's identify the mounted drive:
> pi@barnowl:/myrexx $ rexx rexxtry.rex
>   /mnt/projects/code/Code/Rexx/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.
> address command 'df'
> Filesystem  1K-blocks  Used  Available Use% Mounted on
> /dev/root27776536  179935528348952  69% /
> devtmpfs  1801496 01801496   0% /dev
> ..
> ..
> ..
> 192.168.1.15:/volume1/projects 3840822656 86688 2973823872  23% 
> /mnt/projects
> 192.168.1.15:/volume1/Public15 3840822656 86688 2973823872  23% /mnt/src
>   rc = 0 ... /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> 
> Clearly Public15 is mounted on /mnt/src
> 
> address command 'ls /mnt/src'
>  ArchivedOldDocuments   Genealogy  IMG_3158.jpg   IMG_3165.jpg   
> IMG_3181.jpg   IMG_3188.jpg passion-facade-detail_42294221_o.jpg   
> ZoesOldLaptopPictures
>  DoculibIMG_1139.jpg   IMG_3161.jpg   IMG_3174.jpg   
> IMG_3183.jpg   IMG_3189.jpg Patchworkers
>  Documents  IMG_1148.jpg   IMG_3163.jpg   IMG_3176.jpg   
> IMG_3185.jpg   LightroomDB '#recycle'
> 'Documents and Letters'   IMG_3157.jpg IMG_3164.jpg   IMG_3178.jpg   
> IMG_3187.jpg  'Onedrive (Backup)'   the-towers_42294309_o.jpg
>   rc = 0 ... /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> srcdir = "/mnt/src/'Documents and Letters'"
>   .. /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> say srcdir
> /mnt/src/'Documents and Letters'
>   .. /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> 
> I can use the ls command to view the drive, and I can see the directory I 
> wish to access, namely, 'Documents and Letters'; I have set a variable 
> 'srcdir' to contain that path. So far, so good.
> 
> I can use the variable to list the contents of the directory 
> 
> address command "ls" srcdir
> '20041222 Libby Rose - Butlin House Complaint.doc' 'KINGSTON PARISH 
> COUNCIL Planning comments.doc'
> '20061212 Kim Heathrow pickup.doc' 'KPC - Planning.mmp'
> 'Kingston Gorse'   'Zoes Stuff'
>   rc = 0 ... /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> 
> So everything seems to be as expected. This is where it suddenly gives me an 
> unexpected result... Let's just check the directory one more time
> 
> if sysisfiledirectory(srcdir) Then say "It is a directory"; else Say "It is 
> NOT a directory"
> It is NOT a directory
>   .. /mnt/projects/code/Code/Rexx/rexxtry.rex on LINUX
> 
> 
> Errr Excuse me! I thought we had just proved, pretty conclusively that it 
> is a directory and we have access to it. But the SysIsFileDirectory doesn't 
> seem to think so.
> 
> Can anyone tell me how stupid I am?
> 
> Andy
> 
> 
> ___
> rexxla-members mailing list -- mailto:rexxla-memb...@rexxla.org
> http://rexxla.org/mailman/listinfo/rexxla-members

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Jenkins: Rockhopper upgraded to CMake 3.20.3 and added local Subversion version

[René Jansen]

This is in place now, with the line that specifies the dpkg executable only.


> On 14 Jun 2021, at 17:49, Erich Steinböck  wrote:
> 
> I don't know if this works with options specified together with the allowed 
> command
> Are you sure you did sudo visudo -f /etc/sudoers.d/rvjansen as there seems to 
> be no  /etc/sudoers.d/rvjansen file
> 
> ls -l /etc/sudoers.d
> -rw-r--r-- 1 root root  31 Sep  5  2020 devops
> -r--r- 1 root root 958 Jan 18  2018 README
> 
> 
> ___
> 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: Rockhopper upgraded to CMake 3.20.3 and added local Subversion version

[René Jansen]

Hi Erich,

just did - let’s see if that works.

best regards,

René

> On 13 Jun 2021, at 05:06, Erich Steinböck  wrote:
> 
> Hi René, thanks!
> 
> Our build jobs now also test installation of the built binary package.
> On Ubuntu this means running dpkg --install and dpkg --remove
> But these require sudo to work.  Would you mind giving the rvjansen user sudo 
> dpkg without password?
> 
> Thanks and regards, Erich
> ___
> 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: Rockhopper upgraded to CMake 3.20.3 and added local Subversion version

[René Jansen]

Dear ooRexx developers,

"to whom it may concern”:

I upgraded the Ubuntu installed CMake (which was quite old at 3.10) with a 
locally built CMake 3.20.3, and removed 3.10. So for Linux on Z at least, this 
is not holding Cmake features back.

Also, on Erich’s request (from some time ago, sorry about that!) I added a 
local install of Subversion, which is now usable from the command line, in 
addition to the Jenkins provided version.

I reran the ooRexx 5.0.0 build manually and all seems ok.

best regards,

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Compiling ooRexx 5.0.0 for Raspberry Pi

[René Jansen]

Hi Terry,

I regularly compile on the Raspberry Pi itself (only ooRexx 5.0.0.beta), and 
there seem no drawbacks other than that I point a fan at it to not slow down 
during the compile due to temperature. I switched to Ubuntu 20.04 LTS for the 
64-bit Raspberry’s; after installing Cmake and curses it is a smooth ride.

You might like this presentation 
https://www.rexxla.org/events/2020/presentations/RexxLA2020-RPi4LinuxDesktopEnvs4Rexx-TDycks.pdf
 

 

There might be regular Jenkins builds for this, but P.O. would know better than 
I do.

best regards,

René.

> On 8 Jun 2021, at 20:07, Terry Fuller  wrote:
> 
> Hello all, 
> 
> I'm starting a project on a Raspberry Pi and need to set up a development 
> environment.  I want to compile ooRexx 5.0.0 for the Raspberry Pi.  After 
> much research, I'm setting up cross compiling as outlined in this github 
> wiki:   cross compilers 
>  for 
> Raspberry Pi...
> 
> I've seen mention of folks compiling 4.2.x for the Pi, but haven't seen much 
> in the way of details, nothing on 5.0.0.  I couldn't tell from the pages I 
> found whether native or cross compiling was used.  Any insights  gladly 
> accepted.
> 
> 
> 
> -- 
> taf
> ___
> 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] Introduction new List member - OORexx for Android

[René Jansen]

Hi Thomas,

welcome! Thank you for introducing yourself, and thank you one more time for 
planning this work, this would be a very welcome addition. If there is any 
question, feel free ask on this list. CMake is well documented, and should not 
be any problem; if it is, there are several experts on this list.

I wish you lots of success with your undertaking!

best regards,

René Jansen.
President, Rexx Language Association. 

> On 2 May 2021, at 18:49, Thomas Kahr  wrote:
> 
> Dear Developers,
>  
> my name is Thomas Kahr and some of you may already know me from a question 
> during my first steps with OORexx about a month ago. At that time, I had a 
> small problem with the lines() method which fortunately was solved very 
> quickly with your input and help. Thanks again for that. In the meantime, I 
> have extended my knowledge in OORexx in the lectures with Prof. Rony 
> Flatscher.
>  
> Now I would like to introduce myself officially here because I decided to 
> port OORexx to Android during my seminar work.
>  
> I have read up on the topic in the last weeks and have developed a rough 
> understanding of the task. So far, I have not worked with CMake but I am 
> confident that it will work well. The real work will happen in the next few 
> weeks.
>  
> Of course, after completion everything will be handed over to the OORexx team 
> with the appropriate license.
>  
> So, I expect that I will run into a lot of problems and I hope I can share my 
> problems here on this list and get some help. If someone already has some 
> tips or essential information that will make the start easier, I will be 
> happy if you share them with me.
>  
> Apart from this project I promised to contribute some new Word examples for 
> the OORexx reference. Of course, also under the necessary license.
>  
> Have a good weekend and a nice evening.
>  
> Best regards Thomas
> ___
> 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

Re: [Oorexx-devel] test case rexxtry

[René Jansen]

Yes, but my point is, I don’t want that. I do want the tests to succeed on a 
non-installed build. I don’t think being able to find rexxtry.rex is a test for 
a working interpreter. If we want to test the lookup facility, we should 
specify a file that is, or needs to be on the $PATH. There are lots of other 
samples beside rexxtry.rex that are non-essential for the purpose of this test, 
which is to determine if a change broke functionality on a platform and 
indicate that to the developer.

But I have the copy now in the test configuration and it is fine. I thought it 
better for conceptual integrity and fit-for-purpose to remove the test but when 
you all disagree it is no problem; case closed.

best regards,

René.

> On 19 Feb 2021, at 16:44, Rony G. Flatscher  wrote:
> 
> On 19.02.2021 15:28, rvjan...@xs4all.nl <mailto:rvjan...@xs4all.nl> wrote:
>> Ok, will add it to the path like P.O. suggested and hope that it works. Or 
>> will copy it after the build. I think it tests the install process and not 
>> the working of the interpreter.
> You can test the existence of rexxtry.rex next to rexx[.exe] by something 
> like e.g.
> 
> self~assertTrue(SysFileExists(filespec("location",.rexxinfo~executable)||"rexxtry.rex"))
> 
> ---rony
> 
> 
>>> On 19 Feb 2021, at 14:55, Rony G. Flatscher  
>>> <mailto:rony.flatsc...@wu.ac.at> wrote:
>>> 
>>> On 18.02.2021 15:49, René Jansen wrote:
>>>> There is currently only one test case failing on the Linux on Z 
>>>> Rockhopper, which is the test for the reachability of RexxTry. This is 
>>>> because this is the uninstalled version of ooRexx - the so-called USB 
>>>> version. I expect this to fail on other machines where we do not do an 
>>>> install, because RexxTry has not been copied from samples to the $PATH.
>>>> 
>>>> I want to remove this test, does anyone oppose?
>>> hmm, as "rexxtry.rex" has *always* been put into the location where the 
>>> executable rexx[.exe]
>>> resided I would regard this a bug in the USB version you used which should 
>>> place "rexxtry.rex" next
>>> to rexx[.exe]. As such the test unveiled this error and I would keep it! :)
>>> 
>>> ---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] test case rexxtry

[René Jansen]

There is currently only one test case failing on the Linux on Z Rockhopper, 
which is the test for the reachability of RexxTry. This is because this is the 
uninstalled version of ooRexx - the so-called USB version. I expect this to 
fail on other machines where we do not do an install, because RexxTry has not 
been copied from samples to the $PATH.

I want to remove this test, does anyone oppose?

best regards,

René. 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] open() option APPEND

[René Jansen]

Hi Leslie,

I am sure you mean 1984. And then there was still only EXECIO. I have to look 
up when VM/CMS got stream; TSO never had it until now, unless we installed a 
library.
I will try to find out the timeline.

best regards,

René.


> On 10 Feb 2021, at 05:45, J Leslie Turriff  wrote:
> 
> On 2021-02-09 19:02:12 Michael Lueck wrote:
>>> Any ideas on how this was meant to be when it was designed?
>> 
>> I never claim to be the best expert at REXX history, however...
>> 
>> On Mainframe, I believe either the Stream concept came much later or still
>> is not there at all.
> 
>   The file I/O functions [stream(), charin(), charout(), chars(), 
> linein(), lineout(),
> lines()] have been in the language since at least when I first used VM/CMS in 
> ~1974.
> They could operate on CMS minidisk, Shared File System*, or Byte File System* 
> files;
> sockets capabilities came later when a TCP/IP stack was added to VM.  In MVS 
> Rexx could
> use these functions to do I/O to QSAM, Open Edition or Unix System Services 
> files.
>   See https://www.vm.ibm.com/library/640pdfs/64622201.pdf Chapter 9: 
> Input and Output, for
> example.
> 
> Leslie
> 
> 
> --
> 
> 
> ___
> 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] Seven years since the last release

[René Jansen]

HI Erich, good to hear, I’ll work with you on this.

best regards,

René.

> On 31 Jan 2021, at 18:02, Erich Steinböck  wrote:
> 
> René, I'll see what I can do, time and skills permitting.
> I have no experience how to convince distributions to pick up ooRexx 5 or to 
> bring it into the Windows Store.
> 
> Erich
> 
> On Sun, Jan 24, 2021 at 2:02 PM René Jansen  <mailto:rvjan...@xs4all.nl>> wrote:
> I agree with Rick here.
> 
> But: the problem here is that the notions of GA, ‘golden’ are from the last 
> century and might not be applicable in this day and age. I see a lot of 
> software projects having two lines of release, one stable and one rolling. It 
> is a fact, though, that there are companies still adhering to those older 
> notions, some of them are ex-Open Object Rexx clients from IBM, and RexxLA 
> has obligations towards those clients for maintaining and improving the 
> product, on condition of which it was delivered the source code. The moment 
> that the 4.X releases (our ‘stable release’) don’t work properly anymore, we 
> are defaulting on that agreement. I might all be academic because those 
> companies seem to be moving to other languages; that may or may not be our 
> fault.
> 
> But whatever the state of the code, being in beta for 7 years is not a good 
> sign for viability of any project. The problem here was declaring a beta, 
> when in fact it was still pre-release code. For the future, we should refrain 
> from calling a release a beta when we do not have a plan for a release.
> 
> In my opinion, we need a plan to address this problem. It should be a plan to 
> release on a specific date, on the condition that work has been done on a few 
> issues.
> 
> 1) What: Classify the open issues in ‘showstoppers' and ‘other’ categories. 
> Flag them as such. Who: Rick and Erich, René. When: March 31, 2021
> 2) What: Commit all installers, tests and other improvements we have. Who: 
> P.O., Rony and others. When: February 15, 2021
> 3) What: Identify documentation issues. Who: Rick and Rony, Erich, others. 
> When: Februari 28, 2021
> 4) What: Improve documentation along identified issues. Who: Gil, Jon, René, 
> Rony, Walter, others. When: April 15, 2021
> 5) What: fix, freeze, prepare and test GA release. Who: P.O., Erich, Rick, 
> others. When: May 1st, 2021.
> 
> I know I cannot decide on other people’s time, so I just hope we can agree to 
> this, on a best effort base. I hope we all see the predicament we are in. 
> When we have this in the past, we can decide on release approaches that are a 
> better fit. 
> 
> Please react on, and improve on this planning, so we can have something we 
> can commit to soon.
> 
> best regards,
> 
> René.
> ___
> 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] post-release actions

[René Jansen]

Hi Harmander,

one of the identified showstoppers is Walter’s linein slowdown on windows 
issue, https://sourceforge.net/p/oorexx/bugs/1737/ and probably 
https://sourceforge.net/p/oorexx/bugs/1721/ (don’t know the exact relation). It 
would be very beneficial if you could assist testing this and formulating 
hypotheses for the cause.

Things to take into account are reproducibility (windows vs other platforms - 
if you have succinct testcases we can run them or add them to the automated 
testcases to be able to follow this issue and its causes more closely on 
several platforms) and interaction with external factors like virus checking 
software - I ran into several cases of degradation, e.g. in git performance, 
where this ultimately was to blame.

A good starting point would be to see when this was introduced. I am sure Erich 
can help you with this - but first, I’d suggest a close reading of the 
mentioned incident reports.

Thank you very much for any help!

best regards,

René Jansen.

> On 27 Jan 2021, at 15:57, Rony G. Flatscher  wrote:
> 
> Hi Harmander,
> 
> thank you *very* much for your offer!
> 
> As you see there is a communication problem somehow as no one of the official 
> developers (Erich or Rick) would get back to it.
> 
> Maybe we can start out in the documentation corner with the help of Gil and 
> P.O. 
> 
> But still, we need pointers of missing documentation items and I do not know 
> which ones there are that are a) missing and b) show-stoppers to be tackled 
> first. So in this regard, Erich and/or Rick, please point at such items or 
> let us know how to find them ourselves! :)
> 
> ---rony
> 
> 
> 
> 
> 
> On 26.01.2021 08:59, Harmander Singh wrote:
>> Many thanks for your offer: 
>>  if someone can point at an item you could tackle I volunteer to help you 
>> through for the first item, from getting svn, checking out the 
>> documentation, creating the documentation off-line such that you can test 
>> your changes for correctness, to creating a patch to incorporate all your 
>> changes into the trunk at Sourceforge.
>> I can be emailed separately to start off. 
>> Regards
>> 
>> 
>> On Tue, 26 Jan 2021 at 06:17, Rony G. Flatscher > <mailto:rony.flatsc...@wu.ac.at>> wrote:
>> On 25.01.2021 02:34, Harmander Singh wrote:
>>> Could getting more hands on deck help? Maybe specific tasks anyone thinks 
>>> can be offloaded may be announced, and volunteers can then interact with 
>>> the person to accomplish them.
>>>   
>>> I had earlier volunteered but was not offered any task (perhaps none was 
>>> suited to my skill-set which is: a lot of Rexx experience, and a little 
>>> ooRexx knowledge). Maybe documentation/testing help?
>> that would be really great! If it is documentation I would offer the same 
>> help as Walter, except for the offer to visit, assuming that that would be a 
>> little bit too far at the moment... ;)
>> 
>> ---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] post-release actions

[René Jansen]

… that we can start now.

It seems imperative that we get ooRexx added to the different distributions. 
Most people install like that; some run installers; even less build from source.

I know ooRexx is in the SLES build tree and is just waiting for the GA signal. 
We should be able to address RedHat via our IBM contacts. For other 
distributions - I hope people have their own favorites and will try to get them 
into those. It might entail setting up a repository and make sure apt and yum 
can handle that.

For macOS we have Homebrew and Macports to consider. And maybe even the App 
Store (shudder).

For Windows, we should get into that Microsoft app store. I think before that 
we should have solved the false positive problem for some virus businesses, and 
have crypto certificates.
I will go after those. Last time Les and Chip were rebuffed because some 
telephone number was not connected, if I remember correctly.

If someone knows other Windows distribution mechanisms, I would love to hear 
about those. Because I avoid it, I would not know, and I only see corporate 
distribution tools. This might be the only platform where the traditional 
installer exe still matters.

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seven years since the last release

[René Jansen]

I agree with Rick here.

But: the problem here is that the notions of GA, ‘golden’ are from the last 
century and might not be applicable in this day and age. I see a lot of 
software projects having two lines of release, one stable and one rolling. It 
is a fact, though, that there are companies still adhering to those older 
notions, some of them are ex-Open Object Rexx clients from IBM, and RexxLA has 
obligations towards those clients for maintaining and improving the product, on 
condition of which it was delivered the source code. The moment that the 4.X 
releases (our ‘stable release’) don’t work properly anymore, we are defaulting 
on that agreement. I might all be academic because those companies seem to be 
moving to other languages; that may or may not be our fault.

But whatever the state of the code, being in beta for 7 years is not a good 
sign for viability of any project. The problem here was declaring a beta, when 
in fact it was still pre-release code. For the future, we should refrain from 
calling a release a beta when we do not have a plan for a release.

In my opinion, we need a plan to address this problem. It should be a plan to 
release on a specific date, on the condition that work has been done on a few 
issues.

1) What: Classify the open issues in ‘showstoppers' and ‘other’ categories. 
Flag them as such. Who: Rick and Erich, René. When: March 31, 2021
2) What: Commit all installers, tests and other improvements we have. Who: 
P.O., Rony and others. When: February 15, 2021
3) What: Identify documentation issues. Who: Rick and Rony, Erich, others. 
When: Februari 28, 2021
4) What: Improve documentation along identified issues. Who: Gil, Jon, René, 
Rony, Walter, others. When: April 15, 2021
5) What: fix, freeze, prepare and test GA release. Who: P.O., Erich, Rick, 
others. When: May 1st, 2021.

I know I cannot decide on other people’s time, so I just hope we can agree to 
this, on a best effort base. I hope we all see the predicament we are in. When 
we have this in the past, we can decide on release approaches that are a better 
fit. 

Please react on, and improve on this planning, so we can have something we can 
commit to soon.

best regards,

René.
 

> On 24 Jan 2021, at 12:39, Rick McGuire  wrote:
> 
> P.O., you have commit privileges now, so you ARE a developer. If you have an 
> install process working that is working through CMake working, then it should 
> be checked into the project. Having something that is your private setup is 
> not a working solution. You could be hit by a bus tomorrow, so our ability to 
> build an installer would go away. Having an installer available means any 
> interested person can checkout the code and follow the instructions to build 
> it themselves. 
> 
> That would be a big step, but the docs really need a thorough review. A lot 
> of new features in 5.0 (e.g., variable references) make portions of both the 
> reference and programming guide a bit dated. 
> 
> There are currently 83 open bug reports. A few of these I would consider show 
> stoppers, such as Walter's linein performance problems and the issues with 
> Windows file name case. A number of others are not in complete state, missing 
> needed tests and documentation. There are similar incomplete items in the 
> feature requests. This is not a release that is ready to go gold yet. 
> 
> Rick
> 
> On Sun, Jan 24, 2021 at 5:54 AM P.O. Jonsson  > wrote:
> I agree with Rony that version 5 of ooRexx should be formally released, I 
> just did not raise my voice since this is a discussion amongst the developers.
> 
> Due to the delay we may already have lost a major „client, my former 
> employer, the European Patent Office, with more than 4000 ooRexx 4 
> installations. They are now going all-in for Python instead, they will never 
> be able to upgrade to 5.0.0 unless there is an official release.
> 
> Can Rick and/or Erich provide a list of „showstoppers“ so they can be worked 
> off? Are there REALLY any problems that are so severe that they would 
> prohibit a release? I doubt it.
> 
> I can offer to set up the macOS Installer on the Jenkins machine. It is Cmake 
> driven and uses standard Unix commands in the post-processing. It also 
> includes the latest documentation, license, HowTo etc. Example can be found 
> in „MacBuilds“ here 
> 
> 
> I have also written test cases for all sample files, they can be uploaded but 
> require a little fix in the testing framework (that I can provide as well).
> 
> I have set up the documentation (PDF and HTML) to be built on Jenkins every 
> new revision (this is where I get it for the macOS installer) what is missing 
> is an upload to Sourceforge, this needs to be done with someone with R/W 
> access there.
> 
> So what is really missing that prohibits a release? Is it not about time now 
> to kill our baby and go ahead and release 5.0 and 

Re: [Oorexx-devel] Seven years since the last release

[René Jansen]

+1

I agree, but it is a responsibility of the development team. Last time I asked, 
different showstoppers were identified, like in the documentation building 
process and installers. The situation around those issues seems a lot better 
now. We should ask again.

Developers, is there any reason not to release now? Please?

René

> On 11 Jan 2021, at 17:14, Rony G. Flatscher  wrote:
> 
> On February 24th 2021, it will be seven (!) years since the last official 
> release of ooRexx took
> place, believe it or not!
> 
> People who do not follow this list or the ooRexx code updates on Sourceforge 
> will think, that
> maintenance, let alone development, of ooRexx has ceased seven years ago! :(
> 
> This puts pressure on those people in organisations/businesses who use 
> Rexx/ooRexx but are faced
> with demands of replacements with more modern, maintained and continuously 
> developed programming
> languages like Python, Ruby and the like.
> 
> Also, people who suggest to allow usage of ooRexx in organisations/businesses 
> will usually get
> turned down as ooRexx is outdated and not maintained, so why using it? 
> Learning about a beta version
> does not help as everyone knows that beta means error-prone, unstable 
> software and the like, and as
> a result organisations/businesses usually prohibit usage and deployment of 
> beta software.
> 
> As ooRexx 5.0 beta has been in an excellent condition for many years, it 
> could have been released
> years ago! ooRexx 5.0 beta adds a wealth of great new features, in addition 
> very notable speed
> improvements and fixes many bugs of the seven years old ooRexx 4.2, the last 
> official release of
> ooRexx!
> 
> As no show-stoppers are present I think that the current version of ooRexx 
> 5.0 beta should be
> released ASAP as is. The only thing needed would be a new package that is 
> declared to be the release
> package!
> 
> Is there a will for a release? If so, can the release be done by February 
> 24th 2021?
> 
> ---rony
> 
> P.S.: Also, once a release is done, I would suggest to make sure to create a 
> yearly (!) release,
> even if they are only microreleases! This will signal ongoing maintenance and 
> development to
> outsiders/users of ooRexx, which has been the case for all those past years 
> (but lacking releases
> this was not communicated successfully to outsiders/users of ooRexx).
> 
> P.P.S.: In today's world the release cycles are critical to public reception 
> of the healthiness of
> (software) projects it seems, probably the main reason why Linux creates even 
> twice a year a
> release, but also Java/OpenJDK and others. 
> 
> 
> 
> 
> ___
> 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] Quirk of the Day

[René Jansen]

Well I promised too much: CRX gives an error but rounds 18 to 20 in the error 
message.

still i think 2 is also valid

René.

> On 10 Nov 2020, at 10:36, René Jansen  wrote:
> 
> Chip,
> 
> I agree that staying away from sharp objects is good, and the discussion is 
> mostly academic.
> 
> But here some other arguments to consider:
> 1) this can be distilled down to when it is necessary to evaluate an 
> expression. If the expression is a number, one might argue it has been 
> evaluated already, and does not need further evaluation under the numeric 
> digits constraints. When it is not a number, it should be evaluated like any 
> other expression.
> 
> 2) it appears - I have been told - that CRX (of which I do not have a running 
> version), does evaluate the numeric argument under the current settings and 
> comes up (for 18) with 2E+1, so 2. While just as astonishing (well, maybe a 
> bit more), this is even more PLE than ooRexx.
> 
> With this, I will now be silent on this subject until the next ARB meeting.
> 
> René.
> 
>> On 10 Nov 2020, at 00:34, Chip Davis  wrote:
>> 
>> We must be careful we don't cut ourselves on such a sharp edge-case.  The 
>> salient arguments boil down to:
>> - The Principle of Least Astonishment argues for modifying ooRexx to match 
>> the behavior of other Rexx'es.
>> - The Policy of Least Exceptions argues that ooRexx has the right rule.
>> 
>> The purist in me contends that the ooRexx behavior is the correct one, and 
>> we should simply update the errortext: "DIGITS value must be a positive 
>> whole number expressible under the current setting of "NUMERIC DIGITS nn"; 
>> found "dd".  We could do that for ooRexx and NetRexx, but the likelihood of 
>> any IBM Rexx processor following suit, is nil.
>> 
>> There is a valid argument for making ooRexx consistent with all the other 
>> Rexx'es out there, especially the huge installed base of IBM Rexx code.  One 
>> might hope that the number of ooRexx programs affected by this change could 
>> be expressed in Numeric Digits 2, but who knows where (or how critical) that 
>> code may be.  This will also require documenting (and test-casing) this 
>> exception to the current behavior.  But it won't be the only place that the 
>> design of Rexx has bent an ideal consistency to the reality of dealing with 
>> humans.
>> 
>> As big a fan of consistency as I am, I'm afraid I come down on the more 
>> pragmatic PLA side of this issue, especially given the expected amount of 
>> code affected.
>> 
>> -Chip-
>> 
>> 
>> 
>> ___
>> 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] Quirk of the Day

[René Jansen]

Chip,

I agree that staying away from sharp objects is good, and the discussion is 
mostly academic.

But here some other arguments to consider:
1) this can be distilled down to when it is necessary to evaluate an 
expression. If the expression is a number, one might argue it has been 
evaluated already, and does not need further evaluation under the numeric 
digits constraints. When it is not a number, it should be evaluated like any 
other expression.

2) it appears - I have been told - that CRX (of which I do not have a running 
version), does evaluate the numeric argument under the current settings and 
comes up (for 18) with 2E+1, so 2. While just as astonishing (well, maybe a bit 
more), this is even more PLE than ooRexx.

With this, I will now be silent on this subject until the next ARB meeting.

René.

> On 10 Nov 2020, at 00:34, Chip Davis  wrote:
> 
> We must be careful we don't cut ourselves on such a sharp edge-case.  The 
> salient arguments boil down to:
>  - The Principle of Least Astonishment argues for modifying ooRexx to match 
> the behavior of other Rexx'es.
>  - The Policy of Least Exceptions argues that ooRexx has the right rule.
> 
> The purist in me contends that the ooRexx behavior is the correct one, and we 
> should simply update the errortext: "DIGITS value must be a positive whole 
> number expressible under the current setting of "NUMERIC DIGITS nn"; found 
> "dd".  We could do that for ooRexx and NetRexx, but the likelihood of any IBM 
> Rexx processor following suit, is nil.
> 
> There is a valid argument for making ooRexx consistent with all the other 
> Rexx'es out there, especially the huge installed base of IBM Rexx code.  One 
> might hope that the number of ooRexx programs affected by this change could 
> be expressed in Numeric Digits 2, but who knows where (or how critical) that 
> code may be.  This will also require documenting (and test-casing) this 
> exception to the current behavior.  But it won't be the only place that the 
> design of Rexx has bent an ideal consistency to the reality of dealing with 
> humans.
> 
> As big a fan of consistency as I am, I'm afraid I come down on the more 
> pragmatic PLA side of this issue, especially given the expected amount of 
> code affected.
> 
> -Chip-
> 
> 
> 
> ___
> 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] Quirk of the Day

[René Jansen]

The PTF for this APAR probably did not make it into the code, because TSO and 
CMS Rexx (for z/OS 2.3 and z/VM 6.4 at least) do not have a problem with 
setting numeric digits to 1 and then to 18.

/* */  
numeric digits 1   
say digits()   
numeric digits 18  
say digits()   

 numeric   
1  
18 

At the moment, ooRexx is the only one I can find that behaves like this.

best regards,

René.






> On 9 Nov 2020, at 15:00, Mike Cowlishaw  wrote:
> 
> And some more background .. if I recall correctly, this was set (corrected) 
> to work this way after an APAR (one of only two, ever) was raised for exactly 
> this case because the interpreter did NOT report it as an error whereas the 
> documentation implied that it should.   There was some discussion in 1981 as 
> to whether there should be a minimum value for NUMERIC DIGITS (e.g., 3), but 
> it was hard to argue why that should be -- this would have been a cogent 
> argument if we'd thought of this case!   :-)
>  
> (Separately, the original REX error messages .. the 'headline' error messages 
> ... had to be really short because of the need to keep the interpreter within 
> 32KB (yes, KB) so that it would fit in less then half of one rotation of 
> paging drums ...)
>  
> Mike
> 
>> From: Rick McGuire [mailto:object.r...@gmail.com] 
>> Sent: 09 November 2020 13:47
>> To: Open Object Rexx Developer Mailing List
>> Subject: Re: [Oorexx-devel] Quirk of the Day
>> 
>> 
>> 
>> On Mon, Nov 9, 2020 at 8:21 AM rvjan...@xs4all.nl 
>>  mailto:rvjan...@xs4all.nl>> 
>> wrote:
>>> Hi Walter,
>>> 
>>> Yes, well, it could be a typo. I am worried about all other 
>>> implementations, including NetRexx and z/OS TSO, z/VM, Regina, brexx, etc, 
>>> being wrong if this is the right way. It certainly fails the (however 
>>> subjective) principle of least astonishment, and I also get the feeling the 
>>> ‘numeric digits’ statement is not necessarily meant for the next instance 
>>> of ‘numeric digits’. Changing the error message would go a long way: ‘with 
>>> numeric digits set to X, Y is not a valid positive whole number.’
>>  
>> The mainframe versions all behave the same way. I have had this conversation 
>> several times since 1982, almost always from a tester playing with setting 
>> digits to 1. 
>> 
>>  
>>> 
>>> I’ll put it on the list for the ARB. Who wants to be on the ARB? We have an 
>>> obligation to run an Architecture Review Board, as discussed during the 
>>> symposium. I am looking for volunteers. I suggest at least Erich and Rick 
>>> be on it. I suggest we do not convene more than once a quarter.
>>> 
>>> René.
>>> 
 On 9 Nov 2020, at 13:59, WalterPachl via Oorexx-devel 
 >>> > wrote:
 
 
 Who on earth (except "us nasty testers") would ever issue ND 1
 I am much more concerned about the performance disaster I reported 2 or 3 
 weeks ago :-(
 Greetings
 WALTER
> "Rony G. Flatscher"  > hat am 9. November 2020 um 11:31 
> geschrieben:
> 
> 
> On 09.11.2020 10:35, Erich Steinböck wrote:
>> 
>> This one stunned me!
>> 
>> ~~~
>> numeric digits 1
>> numeric digits 18
>> -- Error 26.5:  DIGITS value must be a positive whole number; found "18".
>> ~~~
> 
> Maybe enhancing the error message to indicate the current setting of 
> numeric digits which makes "18"
> not a positive whole number would explain to the programmer why the error 
> occurs. Something like
> "Error 26.5:  DIGITS value must be a positive whole number; found "18" 
> (numeric digits is currently
> set to 1 digit)."
> 
> ---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 
>>> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___

Re: [Oorexx-devel] ooRexx on github

[René Jansen]

Hi Rony,

this one is from Moritz Hoffmann. I suggest we leave that up to him. I also 
have one on github because that one works better when I build LSPF - I upgrade 
that once in a while but not too often.

René

> On 4 Nov 2020, at 16:06, Rony G. Flatscher  wrote:
> 
>  contains an outdated version of the ooRexx 
> repository. The question is
> what to do with it?
> 
> ---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] Open Object Rexx Reference documentation in OS/2 help file format

[René Jansen]

I am happy to say that I watched so many Swedish television series now that I 
can read almost all of it!

René.

> On 15 Oct 2020, at 14:38, P.O. Jonsson  wrote:
> 
> Sorry this was a private conversation regarding OS/2, please ignore
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
> 
> 
> 
>> Am 15.10.2020 um 14:36 schrieb P.O. Jonsson :
>> 
>> Hej!
>> 
>> Vet inte hur och var din documentation kan passa in, enklast är nog att 
>> ställa frågan på Open Object Rexx Developer Mailing List 
>> oorexx-devel@lists.sourceforge.net
>> 
>> Min erfarenhet är att dom ogärna lägger upp saker som inte direkt genereras 
>> från uppdaterade filer, allra helst direkt styrt från CMake. Jag har lagt in 
>> dom script som skapar dokumentationen i PDF och HTML format (någonting som 
>> nästan hade slutat fungera innan jag och 2 andra tog tag i det) på Jenkins 
>> maskinen men dom som har skrivrättigheter på Sourceforge har fortfarande 
>> inte anpassat uppladdningen så dom ligger bara där på Jenkins maskinen. Det 
>> är lite märkligt. Samma med Installer för macOS: jag har skrivit skript som 
>> skapar en drop installer för mac med rudimentära unixkommandon, den har 
>> dom inte accepterat för upload heller. Snyft :-(
>> 
>>  Skulle det vara mycket jobb att sätta upp dina skript på Jenkins? Jag kan 
>> sköta själva skapandet om du beskriver vad som måste göras. Jag skall ta tag 
>> i det här med uppladdning senare. Allt måste ha CPL licens, inget annat 
>> verkar accepteras.
>> 
>> Jag lyssnade på Roderick men han sa inget om dokumentationen vad jag minns. 
>> Här en länk till hans presentation:
>> 
>> http://home.rexxla.org/events/2019/presentations/rexx_in_os2_rexxla_2019.pdf
>> 
>> Angående ooRexx för OS/2 ser det mörkt ut, vi får se vad som händer. Kommer 
>> nog att köpa en licens bara för att prova på OS/2 lite. Sen får vi se.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>>> Am 15.10.2020 um 12:24 schrieb Jan-Erik Lärka :
>>> 
>>> Hej,
>>> 
>>> har nu fått till en i mitt tycke ok version av hjälpen för Open Object 
>>> Rexx referensdokumentation i OS/2 hjälp fil-formatet.
>>> 
>>> Var du kanske med och fick se en ögonblicksbild av det när tidigare 
>>> version presenterades av Roderick Klein för RexxLA?
>>> 
>>> Det ska finnas visare att ladda ner för windows men inte MacOS... men hur 
>>> skall man gå tillväga för att få godkänt av RexxLA?
>>> 
>>> Har inte synkat ner xml-filerna sedan början av september, men 
>>> förhoppningsvis är det inte så stora syntaktiska skillnader så det 
>>> påverkar rexx-skriptet som genererar hjälpfilen.
>>> 
>>> Är det bara att ladda upp skriptet med tillhörande text-filer och bilder 
>>> eller hur 
>>> ska vi göra? Har ju uppkoppling till filarean du delade ut som enhet på 
>>> datorn men ville inte lägga in något där.
>>> 
>>> Mvh
>>> //Jan-Erik
>> 
>> ___
>> 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] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[René Jansen]

I just assumed that this version would include bsf4ooRexx for several platforms.

René.

> On 30 Sep 2020, at 17:33, P. O. Jonsson  wrote:
> 
> Dear Rony et al,
> 
> As I assume all are aware(?) ooRexx on the Mac platform can be used on a USB 
> stick without any modification whatsoever of the official build. A simple 
> drag to a formatted USB is sufficient to make it run. This has been the 
> case for more than a year, from the brilliant intervention from Enrico. 
> 
> All that is needed to make the installation on MacOS to work is to add its 
> /bin dir to the path. This is irrespective of where it runs. Also on a shared 
> drive this should work. Or in ~/Application or in /Applications or wherever. 
> 
> But maybe you mean something more?
> 
> Von meinem iPhone gesendet
> 
>> Am 30.09.2020 um 17:05 schrieb Rony G. Flatscher :
>> 
>> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
>> drive" at this year's
>> International Rexx symposium (cf. 
>> https://www.rexxla.org/events/2020/schedule.html). In the meantime
>> I finalized the USB-package and it it should be ready for testing and will 
>> demonstrate it tomorrow
>> at the symposium.



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad experimental USB-Version of ooRexx r12113 (MacOS, 32- and 64-bit Linux and Windows)

[René Jansen]

No problem with me.

What I would *most* like is that we can build the package in Jenkins and it 
will be automatically obviated by new builds.

René.


> On 30 Sep 2020, at 15:43, Rony G. Flatscher  wrote:
> 
> Tomorrow there will be a presentation entitled "Running Rexx from a USB 
> drive" at this year's
> International Rexx symposium (cf. 
> https://www.rexxla.org/events/2020/schedule.html). In the meantime
> I finalized the USB-package and it it should be ready for testing and will 
> demonstrate it tomorrow
> at the symposium.
> 
> Now, it would probably make sense to make it also available to interested 
> parties for evaluation and
> testing as it includes ooRexx 5.0 r12113 for MacOS (Darwin), Linux (32- and 
> 64-bit) and Windows (32-
> and 64-bit).
> 
> So now I am contemplating to make it available in the sandbox directory of 
> the ooRexx project for
> others to get access to the package. The zip-archive is appr. 40MB and comes 
> with a short readme.txt
> file.
> 
> The question for the developers: is that o.k. with you? An alternative would 
> be to use a different
> location instead.
> 
> It would be important to remove that particular package ASAP as new versions 
> of ooRexx in the trunk
> should obsolete this particular package, such that ooRexx programmers do not 
> get outdated software
> after a while. OTOH it allows you to check it out and contemplate whether we 
> should also create
> "stick"-versions of ooRexx for all the supported platforms.
> 
> ---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] R5 linein/lineout DRAMATIC slowdown???

[René Jansen]

I would volunteer that it says more about windows than about ooRexx. And 
possibly any virus checking apparatuses that interfere with normal I/O. Though 
the difference with 4.2 still is worrisome. We should add these nonfunctionals 
to the Jenkins.

René.

> On 26 Sep 2020, at 13:26, Jeremy Nicoll  wrote:
> 
> On Sat, 26 Sep 2020, at 08:32, WalterPachl wrote:
>> What am I doing wrong?
> 
>> R5beta takes about 25 times the elapsed time of R4.2
> 
> Looking at your code, 
> 
> ...
>> oid='large.xxx'
>> Call time 'R'
>> Do While lines(fid)>0
> 
> I wonder if this lines() function is doing a  lines(,Count) 
> when you wanted just lines(,Normal) behaviour?
> 
> -- 
> 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

Re: [Oorexx-devel] Status report Jenkins

[René Jansen]

Actually, it ran all the time, it was people messing with vpn’s and other 
modern necessities that rendered it inaccessible. But I’ll ask them to check 
the coal and water, and maybe put in the oil gauge.

best regards,

René.

> On 16 Sep 2020, at 13:20, P.O. Jonsson  wrote:
> 
> You need to refill coal and water I suppose ;-)
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 15.09.2020 um 21:58 schrieb René Jansen > <mailto:rvjan...@xs4all.nl>>:
>> 
>> Hi P.O.,
>> 
>> the IBMZ was just fixed today. I’ll try to get it online again tomorrow!
>> 
>> best regards,
>> 
>> René.
>> 
>>> On 15 Sep 2020, at 21:18, P.O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> 
>>> This is just to confirm that (almost) all machines are up and that 
>>> ooRexx build and test without any major problems at the moment.
>>> 
>>> The following build jobs indicate failure/problems at the moment:
>>> 
>>> netRexx-jvm-1.8-build
>>> ooRexx-linux-aarch64-build
>>> regina-rexx Ubuntu64 build
>>> 
>>> Further one machine, IBMZ, is offline since 6 weeks, this is what the log 
>>> file states:
>>> 
>>> [09/15/20 21:03:09] [SSH] Opening SSH connection to **:
>>> No route to host (Host unreachable)
>>> 
>>> So it seems the machine is either off grid or we have the wrong 
>>> credentials. I have tried to ping it but there is a timeout.
>>> 
>>> 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 
>>> <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] Status report Jenkins

[René Jansen]

Hi P.O.,

the IBMZ was just fixed today. I’ll try to get it online again tomorrow!

best regards,

René.

> On 15 Sep 2020, at 21:18, P.O. Jonsson  wrote:
> 
> This is just to confirm that (almost) all machines are up and that 
> ooRexx build and test without any major problems at the moment.
> 
> The following build jobs indicate failure/problems at the moment:
> 
> netRexx-jvm-1.8-build
> ooRexx-linux-aarch64-build
> regina-rexx Ubuntu64 build
> 
> Further one machine, IBMZ, is offline since 6 weeks, this is what the log 
> file states:
> 
> [09/15/20 21:03:09] [SSH] Opening SSH connection to **:
> No route to host (Host unreachable)
> 
> So it seems the machine is either off grid or we have the wrong credentials. 
> I have tried to ping it but there is a timeout.
> 
> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] ooRexx Performance

[René Jansen]

on behalf of James R. Manchester, xjmanc...@gmail.com 
 :

Is there something in ooRexx that limits its use of the CPU within Windows?  I 
have an application that should use 100% of the CPU but only manages about 20%. 
 The following program runs for 60 seconds and it should use the CPU 
continuously.  However, according to Task Manager, it doesn't quite use 22%.  
What's limiting the use of the CPU?  Is there some setting which can be used to 
change this behavior?

Regards,
Jim Manchester

/* */

Duration = 60--Number of seconds to execute.

Start = Time('S')-- Get the start time.

i = 0
do forever
a = 1234 * 24536
b = a / 25
c = a * b
Elapsed = Time('S') - Start
i += 1
if Elapsed > Duration then
leave
end

say 'There were' i 'iterations in ' Elapsed 'seconds.'

exit

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [oorexx:bugs] #1713 Virus in future (beta) version

[René Jansen]

Hi Erich,

thanks. I’ll write to MS and SourceForge today and register a complaint. I’ll 
also put this in a readme on SourceForge so people are aware.

René.


> On 2 Jul 2020, at 11:40, Erich Steinböck  wrote:
> 
> Hi René, I've removed the build files flagged by Sourceforge as suspicious.
> They were all Trojan.GenericKD, a heuristic detection which sometimes gives a 
> false positive.
> I don't think we can do much to prevent this.
> 
> Sourceforge's Bitdefender doesn't flag ooRexx-5.0.0-12096.windows.x86_32.exe 
> that Doug has reported.
> ___
> 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] #1713 Virus in future (beta) version

[René Jansen]

who has Windows and can confirm? These are mostly false positives, but - Erich 
and P.O. - is there any possibility to run the viruscheckers on this file 
before we upload to SourceForge, and skip the uploads if we have a (false) 
positive? This is a reputation issue and I tend to take those very seriously.

Also, we need a release, seriously. I get email about this, and there better be 
one before ooRexx slips into oblivion. With these annoying Windows-virus things 
we would have been better positioned if we already had a non-virus-flagged, 
released version. There was a lot of work done on documentation, and it is up 
to us to decide what the showstoppers are now.

From where I stand, which is in Enterprise IT, it is much more important to get 
the release into the Linux repositories than any download. I would like to 
start a taskforce for that, I think we have the contacts. Please volunteeer.

P.O., it is possible to have a setup with various virus-checkers to run on 
Jenkins so we can get clarity on what the cause is (‘heuristics’) and how to 
squelch it? You will be reimbursed if any cost is incurred.

René.

> Begin forwarded message:
> 
> From: "Doug L" 
> Subject: [oorexx:bugs] #1713 Virus in future (beta) version
> Date: 1 July 2020 at 19:58:42 CEST
> To: "Ticket #1713: Virus in future (beta) version" 
> <1...@bugs.oorexx.p.re.sourceforge.net>
> Reply-To: "Ticket #1713: Virus in future (beta) version" 
> <1...@bugs.oorexx.p.re.sourceforge.net>
> 
> [bugs:#1713]  Virus in future 
> (beta) version
> 
> Status: open
> Group: Next_Release
> Created: Wed Jul 01, 2020 05:58 PM UTC by Doug L
> Last Updated: Wed Jul 01, 2020 05:58 PM UTC
> Owner: nobody
> 
> When I download 
> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/ooRexx-5.0.0-12096.windows.x86_32.exe/download
>  
> 
>  my Microsoft virus scanner says it has a virus (like earlier, recent 
> versions). I actually had a problem with the 12080 version before it was 
> flagged on SourceForge.
> 
> Sent from sourceforge.net because you indicated interest in 
> https://sourceforge.net/p/oorexx/bugs/1713/ 
> 
> 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] Documentation on Jenkins

[René Jansen]

Hi Rony,

well done! That is a step in the right direction.

René.


> On 24 Apr 2020, at 16:19, Rony G. Flatscher  wrote:
> 
> Looked into it and tested a possible solution, here the steps:
> 
> download the DocBook 4.5 DTDs from 
> <http://www.oasis-open.org/docbook/xml/4.5/> 
> <http://www.oasis-open.org/docbook/xml/4.5/>, unzip them, e.g. to 
> "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd"
> 
> define a new environment variable for xsltproc to point to the directory that 
> contains the unzipped document type definitions, but watch out for the format 
> on Windows: start out with three slashes and turn all backward slashes in the 
> path to forward slashes, also note the trailing slash: 
> set 
> SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/"
> Create the docs. 
> 
> E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more 
> than 10 minutes without the local DTDs!
> 
> ---rony
> 
> 
> 
> On 23.04.2020 19:53, Gil Barmwater wrote:
>> I suspect the slow performance might be due to the (repeated) fetching of 
>> the DTDs/stylesheets by the xsltproc/transform step. My internet connection 
>> is intermittently bad and I would sometimes get "failures" due to the 
>> inability of the program to get one of the files it needed. I'd suggest 
>> someone look into making the files "local" so that they need not be 
>> downloaded multiple times per "book". These files are "ancient" so there is 
>> no need to worry about not getting the latest version.
>> 
>> Gil
>> 
>> On 4/23/2020 1:07 PM, René Jansen wrote:
>>> good work!
>>> 
>>> Amazingly slow performance though - needs more memory?
>>> 
>>> René
>>> 
>>>> On 23 Apr 2020, at 19:04, P.O. Jonsson >>> <mailto:oor...@jonases.se>> wrote:
>>>> 
>>>> This is just to say that we now also have a bild of the HTML documentation 
>>>> on Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and 
>>>> I have set it to build@midnight, PDF first and HTML thereafter. This can 
>>>> be changed if needed. All documents seems to build just fine.
>>>> 
>>>> There is currently no upload of documentation to Sourceforge -> Erich?
>>>> 
>>>> To get hold of the documentation log in to Jenkins 
>>>> <http://build.oorexx.org/> and select ooRexx-docs-build (PDF) or 
>>>> ooRexx-docs-build2 (HTML) and then use the link Last Successful Artifacts
>>>> 
>>>> Due to the way Jenkins create new workspaces ooRexx-docs-build 
>>>> ooRexx-docs-build2 are identical parallel folders with the same latest 
>>>> build tools from Gil, with some minor changes to fit it into Jenkins 
>>>> environment.
>>>> 
>>>> 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] Documentation on Jenkins

[René Jansen]

Hi Ruurd,

please try now.

René

> On 24 Apr 2020, at 14:33, Ruurd Idenburg  wrote:
> 
> If I login to Jenkins I get:
> 
> Access Denied
> 
> rji is missing the Overall/Read permission
> 
> So what's going on?
> 
> Ruurd
> 
> On 4/23/20 7:04 PM, P.O. Jonsson wrote:
>> This is just to say that we now also have a bild of the HTML documentation 
>> on Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I 
>> have set it to build@midnight, PDF first and HTML thereafter. This can be 
>> changed if needed. All documents seems to build just fine.
>> 
>> There is currently no upload of documentation to Sourceforge -> Erich?
>> 
>> To get hold of the documentation log in to Jenkins 
>>  and select ooRexx-docs-build (PDF) or 
>> ooRexx-docs-build2 (HTML) and then use the link Last Successful Artifacts
>> 
>> Due to the way Jenkins create new workspaces ooRexx-docs-build 
>> ooRexx-docs-build2 are identical parallel folders with the same latest build 
>> tools from Gil, with some minor changes to fit it into Jenkins environment.
>> 
>> 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 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] Documentation on Jenkins

[René Jansen]

good work!

Amazingly slow performance though - needs more memory?

René

> On 23 Apr 2020, at 19:04, P.O. Jonsson  wrote:
> 
> This is just to say that we now also have a bild of the HTML documentation on 
> Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I have 
> set it to build@midnight, PDF first and HTML thereafter. This can be changed 
> if needed. All documents seems to build just fine.
> 
> There is currently no upload of documentation to Sourceforge -> Erich?
> 
> To get hold of the documentation log in to Jenkins  
> and select ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use 
> the link Last Successful Artifacts
> 
> Due to the way Jenkins create new workspaces ooRexx-docs-build 
> ooRexx-docs-build2 are identical parallel folders with the same latest build 
> tools from Gil, with some minor changes to fit it into Jenkins environment.
> 
> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ping

[René Jansen]

Hi Gil,

I too hope that everyone is well, and just busy. I need to thank you for the 
great looking documentation, and I would like to be able to build it myself, 
and on the Jenkins machine. I will replace the old documents on the oorexx.org 
 server, but we need to be able to point to places where 
people can get version 5.

It seems the open source world is a bit more relaxed about ‘golden’ releases, 
but unfortunately some corporate entities still require us to call it ‘GA’ 
before their people are allowed to touch it. I hope we can reach that point 
somewhere and are able to get ooRexx into the repositories at SLES, RHEL and 
Ubuntu, also homebrew would not be bad. I am going to try to find that email 
with things that needed to be done, documentation was one, Apple installer was 
one; we are much closer now I guess.

best regards,

René.

> On 22 Apr 2020, at 15:17, Gil Barmwater  wrote:
> 
> Things have been very quiet; hope everyone is well.
> 
> -- 
> 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] Are Strings unique?

[René Jansen]

Don’t know about that. But in JDBC, every SQL type has its own NULL typed value.

But I recently learned on this list that there only one NIL in ooRexx, The NIL 
Object (British Accent required here ;-)).

René.

> On 18 Apr 2020, at 18:13, Erich Steinböck  wrote:
> 
> The interpreter doesn't guarantee that String objects are unique, i. e. at 
> most one copy of e. g. a string "FUNCTION" can exist, does it?
> 
> Most of the interpreter code uses strCompare(GlobalNames::NNN), but there are 
> rare exceptions doing a direct compare like == GlobalNames::NULLSTRING or == 
> GlobalNames::FUNCTION.
> 
> Is a null string always unique?
> ___
> 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] Changes in rev 12051

[René Jansen]

Ah ok - that is fine with me.

René.

> On 8 Apr 2020, at 23:46, P.O. Jonsson  wrote:
> 
> Dear René,
> 
> This was a change on my proposal, ooRexx5.0.0 is somewhat over specified and 
> will be incorrect as soon as ooRexx 5.0.1 arrives. ooRexx5 is sufficient to 
> separate it from ooRexx 4.
> 
> If you try one of the dmg installers I have built here 
> <https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0> 
> you can actually just double click the dmg and then drag the entire „app“ to 
> wherever you want it, the installation bundle appears as a single file on 
> macOS.
> 
> The latest installers also include the PDF documentation btw. 
> 
> The default installation to ~/Applications poses two problems:
> 
> 1: ~/Applications does not exist on a freshly installed macOS
> 
> 2: The user needs to amend the path to make the installation fly.
> 
> 
> 
> Problem 1 goes away with an install to /Applications instead of ~/Applications
> 
> Since the installation is atomic it can be dragged to the bin so there is no 
> uninstall process necessary.
> 
> And, I just checked - you do not need elevated rights to install into 
> /Applications
> 
> Just an idea…
> 
> 
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 08.04.2020 um 23:13 schrieb René Jansen > <mailto:rvjan...@xs4all.nl>>:
>> 
>> I have funny stuff going on also: my MacOSX build kept telling me that it 
>> was from June 2019 (which might be the last time I built on this particular 
>> mac).
>> Checking up on it, I found that it now installs in ~/Applications/ooRexx5 
>> instead of ~/Applications/ooRexx5.0.0
>> 
>> No big deal but a tad surprising.
>> 
>> René.
>> 
>>> On 8 Apr 2020, at 18:04, P.O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> 
>>> @Enrico: did you use the rexx -v to confirm the version? For both versions?
>>> 
>>> If so I have a rotten build :-(
>>> 
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>> 
>>> 
>>> 
>>>> Am 08.04.2020 um 17:48 schrieb Enrico Sorichetti via Oorexx-devel 
>>>> >>> <mailto:oorexx-devel@lists.sourceforge.net>>:
>>>> 
>>>> Going back and forth between builds 12050 and 12054 
>>>> Did not cause any problems  on centos 8
>>>> 
>>>> Also using the —replacefiles clause lets You install over an existing 
>>>> installation without uninstalling  the previous one
>>>> 
>>>> After that the rpm -e must be qualified  
>>>> And uninstalling the older only cleanups the rpm/dnf install database
>>>> And leaves a working rexx
>>>> 
>>>> enrico
>>>> 
>>>> 
>>>>> On 8 Apr 2020, at 16:34, Erich Steinböck >>>> <mailto:erich.steinbo...@gmail.com>> wrote:
>>>>> 
>>>>> Try installing an older build (rpm module) after removing the newer build
>>>>> I don't think I can as the two RPM-based slaves CentOS and SLES390 I have 
>>>>> access to don't have full sudo access.
>>>>> 
>>>>> Enrico, can you maybe test what P.O. asks for?
>>>>> ___
>>>>> 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>
>>> 
>>> ___
>>> 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
> 
> ___
> 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] Changes in rev 12051

[René Jansen]

I have funny stuff going on also: my MacOSX build kept telling me that it was 
from June 2019 (which might be the last time I built on this particular mac).
Checking up on it, I found that it now installs in ~/Applications/ooRexx5 
instead of ~/Applications/ooRexx5.0.0

No big deal but a tad surprising.

René.

> On 8 Apr 2020, at 18:04, P.O. Jonsson  wrote:
> 
> @Enrico: did you use the rexx -v to confirm the version? For both versions?
> 
> If so I have a rotten build :-(
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 08.04.2020 um 17:48 schrieb Enrico Sorichetti via Oorexx-devel 
>> > >:
>> 
>> Going back and forth between builds 12050 and 12054 
>> Did not cause any problems  on centos 8
>> 
>> Also using the —replacefiles clause lets You install over an existing 
>> installation without uninstalling  the previous one
>> 
>> After that the rpm -e must be qualified  
>> And uninstalling the older only cleanups the rpm/dnf install database
>> And leaves a working rexx
>> 
>> enrico
>> 
>> 
>>> On 8 Apr 2020, at 16:34, Erich Steinböck >> > wrote:
>>> 
>>> Try installing an older build (rpm module) after removing the newer build
>>> I don't think I can as the two RPM-based slaves CentOS and SLES390 I have 
>>> access to don't have full sudo access.
>>> 
>>> Enrico, can you maybe test what P.O. asks for?
>>> ___
>>> 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

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] update-alternatives (Re: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[René Jansen]

it is great if it works but it is def old skool. This is the type of work 
(evaluating code against releases of whatever) that anyone I work with (yes, 
very young people, well compared to us) would do in a docker container.
I am a bit worried about the release schedule (what release schedule?) but I am 
ok with either fixing or postponing it, not really with spending a lot of time 
on it.

 With the documentation going well we should try to avoid breaking change and 
focus on showstoppers IMHO.

René.

> On 7 Apr 2020, at 13:11, Rony  wrote:
> 
> It may be true that one can individually change the ooRexx location and 
> version by changing PATH such that the operating system can find the desired 
> ooRexx in that particular session that changed the PATH to point to a 
> different ooRexx.. (This ability will not be lost if supporting 
> update-atlernatives on Linux, rather new possibilities of installation 
> combinations that do not break alternate installations becomes possible on 
> Linux.)
> 
> However, this is not matching what update-alternatives defines and allows for:



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[René Jansen]

I am also in favour of the new, relocatable installs, I have ooRexx, Regina and 
brexx on most of my machines, and it is great if they don’t byte each other.
Also, running Java in various versions is just a path switch; I don’t want to 
go back to the years before that when each OS had their own ’sacred places’ to 
put that it.

René.



> On 6 Apr 2020, at 23:23, P.O. Jonsson  wrote:
> 
> Hi Mark,
> 
> It was not me that asked for this change, I was in the middle of an entirely 
> different change for the samples when this change intercepted my changes. And 
> I did not say we should ignore it, I say the better solution is to have a 
> relocatable installation package like macOS (which is a *nix btw).
> 
> I can have 10 different versions of ooRexx installed in parallel and the only 
> thing to do to „switch“ is to change the path to point to the one I use. I 
> have had ooRexx installed in ~/Applications and in /Applications at the same 
> time and none of them disturbs the other. From the package I build for ooRexx 
> it is possible to „install“ oorexx anywhere with a simple drag 
> uninstalling is as easy as dragging to the bin.
> 
> I for myself have suffered a lot from this thing earlier on when trying out 
> ooRexx on different Linux platforms. Using make - make install I ended up not 
> with rexx but rexx-oorexx as an executable. renaming it manually (is there a 
> documentation of the switch? how on earth can one know about it?) I ended up 
> with a broken installation since I was unaware which other items had been 
> switched. Trying to run the testsuite then aborted halfway throug. In the end 
> I had to manually remove all traces of the installation by hand following the 
> manifest file. Since then I learned how to use a rpm or deb package.
> 
> Can you point me to a place where I can read about update-alternatives? I had 
> never heard about it before I stumbled on it here. And I have never been 
> confronted with it in the 6 Linuxes I am using for testing.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 06.04.2020 um 22:29 schrieb Mark Hessling > <mailto:m...@rexx.org>>:
>> 
>> I'm not sure I'd agree that the optimal solution would be to ignore 
>> update-alternatives. update-alternatives is the correct way to have more 
>> than 1 package that provides the same functionality on Linux.  
>> 
>> As René indicated installations worked fine with update-alternatives, and 
>> had been working fine. The only problem I had with the package build was its 
>> name, and that was due to CMake   issues, where on 1 version of CMake 
>> the package built ok but with the wrong name and the newer version of CMake 
>> didn't even make the package. The problem is CMake (or how to use it 
>> properly), not with update-alternatives.
>> 
>> Cheers, Mark
>> 
>> On 7/4/20 1:14 am, P.O. Jonsson wrote:
>>> Hi René and thanks for the info.
>>> 
>>> I had missed the fact that one needed to manually synch CMakelists.txt with 
>>> oorexx.spec.in <http://oorexx.spec.in/> (I did not even realize there was a 
>>> link) and broke the installer for CentOS when adding some samples missing 
>>> CMakeLists.txt. Enrico explained the connection and I could correct it. I 
>>> was in the middle of checking/sorting these two files for the remaining 
>>> missing/superfluous files in /samples when Erichs change came in. I will go 
>>> ahead and make the necessary changes later this week, I did not have time 
>>> to submit it.
>>> 
>>> Regarding the „switch“ I think it is a sub-optimal solution to a problem of 
>>> a few causing problems for the many. The optimal solution would be a 
>>> relocatable ooRexx installation, as we have it now for macOS.
>>> 
>>> Regarding checking Jenkins an automated mail service would be beneficial.
>>> 
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se <mailto:oor...@jonases.se>
>>> 
>>> 
>>> 
>>>> Am 06.04.2020 um 16:56 schrieb René Jansen >>> <mailto:rvjan...@xs4all.nl>>:
>>>> 
>>>> Just last week I generated a .deb for AARCH64 for someone, and it all ran 
>>>> fine - checked it first on a Raspi with Ubuntu on it. It is true that 
>>>> Erich conferred with me about rolling it back; the check in was done in 
>>>> haste when Mark was busy with firefighting (literally! Australia). Its 
>>>> intention was to have update-alternatives working correctly for ooRexx. It 
>>>> sho

Re: [Oorexx-devel] [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[René Jansen]

Just last week I generated a .deb for AARCH64 for someone, and it all ran fine 
- checked it first on a Raspi with Ubuntu on it. It is true that Erich 
conferred with me about rolling it back; the check in was done in haste when 
Mark was busy with firefighting (literally! Australia). Its intention was to 
have update-alternatives working correctly for ooRexx. It should go back in 
when someone gets it to work.

I would politely ask everyone to check Jenkins when a change is made. This goes 
for myself too. P.O. is doing very good work with that. I wonder if we need to 
coordinate more on that, so we can at least check our own platforms when 
significant change is made.

René.

> On 6 Apr 2020, at 16:47, P.O. Jonsson  wrote:
> 
> OK thanks for the info. 
> 
> Does this mean that the „switch“ stuff (rexx-oorexx) is gone?
> 
> Does this also mean that oorexx.spec.in  is now 
> generated by CMake (or Cpack)?
> 
> Are there other files that are affected?
> 
> Unfortunately there seems to be other problems with the installer on the Unix 
> platform, see my other mail. Not sure if this was the reason?
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
>> Am 06.04.2020 um 16:35 schrieb Erich Steinböck > >:
>> 
>> Hi P.O.
>> this removes the CMake changes by Mark Hessling which were committed by René.
>> They had been causing a bunch of issues, where the code duplication you've 
>> seen with oorexx.spec.in  is one of them.
>> 
>> René confirmed that the best option was to roll them back.
>> ___
>> 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] Documentation: using less bold font for some elements ?

[René Jansen]

just want to correct one terminology issue: a monotype font is a font from a 
specific foundry, a monospaced (or non-proportional) font is what you mean.

> On 20 Mar 2020, at 14:15, Rony G. Flatscher  wrote:
> 
> On 19.03.2020 14:31, Gil Barmwater wrote:
>> 
>> Having spent some time looking at the documentation while developing the 
>> system to build the
>> books, I found that we actually have a set of conventions on how things are 
>> displayed. This is
>> part of every document, under the title "Typographic Conventions", right 
>> near the beginning of the
>> book. So this proposal seems rather extreme to me as it could have a major 
>> impact on all our
>> documents. Just my opinion.
>> 
> Gil, of course there is no intention to have any negative impact on the 
> documentation!
> 
> The current boldness is quite strong and looking at the rexxpg book (also in 
> the TOC!) the bolded,
> monotype text stands out prominently. Hence wondering whether removing the 
> boldness (but leaving it)
> to semi-bold would be possible at all. And if it was possible it still needs 
> to be assessed whether
> it negatively impacts the overall look-and feel of the books.
> 
> ---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] Question ad .rexxinfo and CLS-samples ...

[René Jansen]

Thanks for pointing that out. The NetRexx discussion was about product release 
number, i.e. the number that the translator tells you in the logo. The code 
states ‘language level’ indeed, but as far as I can go back this was never 
different from the product release level. (It was a product only for a short 
time, I think from VM/ESA 2.3 to z/VM 5.1).

> On 15 Mar 2020, at 13:45, Rick McGuire  wrote:
> 
> That is the language level, not a product release level. ooRexx also has a 
> language level that is decimal in form, but that is only updated when there 
> is a change to the language handled by the interpreter. Bug fixes would never 
> bump that, nor would new class libraries.
> 
> Rick
> 
> On Sun, Mar 15, 2020 at 8:42 AM René Jansen  <mailto:rvjan...@xs4all.nl>> wrote:
> Not that I am really interested in this, but for your information: CMS and 
> TSO Rexx traditionally has had a decimal version number: 3.40, 3.48. 4.02.
> This is without reason: its inventor is more involved with decimal arithmetic 
> than the man in the street. There was a semi-heated discussion in the NetRexx 
> architecture board some years ago where Mike Cowlishaw did not budge. Out of 
> respect for him I kept the NetRexx numbering like this; NetRexx 3.09 will be 
> released very soon.
> 
> The argument is that decimal version numbers can be easily compared. IBM 
> never changed this for mainframe Rexx.
> 
> best regards,
> 
> René.
> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad .rexxinfo and CLS-samples ...

[René Jansen]

Not that I am really interested in this, but for your information: CMS and TSO 
Rexx traditionally has had a decimal version number: 3.40, 3.48. 4.02.
This is without reason: its inventor is more involved with decimal arithmetic 
than the man in the street. There was a semi-heated discussion in the NetRexx 
architecture board some years ago where Mike Cowlishaw did not budge. Out of 
respect for him I kept the NetRexx numbering like this; NetRexx 3.09 will be 
released very soon.

The argument is that decimal version numbers can be easily compared. IBM never 
changed this for mainframe Rexx.

best regards,

René.

> On 15 Mar 2020, at 13:19, Rony G. Flatscher  wrote:
> 
> 
> On 14.03.2020 21:51, Enrico Sorichetti via Oorexx-devel wrote:
>> There is a clash in the  nomenclature used by IBM software development 
>> And the one used in the *ix word 
>> 
>> The IBM terminology is explained here
>> https://www.ibm.com/support/pages/vrmf-maintenance-stream-delivery-vehicle-terminology-explanation
>>  
>> 
> Wow, very helpful, thank you very much Enrico!
> 
>> On the other side the *ix is a bit murkier due also to the confusion about 
>> library versioning 
>> 
>> The terms used by CMAKE are 
>> 
>> PROJECT_VERSION
>> PROJECT_VERSION_MAJOR
>> PROJECT_VERSION_MINOR
>> PROJECT_VERSION_PATCH
>> PROJECT_VERSION_TWEAK
>> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] rexxpg.pdf: using svg instead of png graphics?

[René Jansen]

SVG is a vector format, and png is a raster format. Print media always has 
(well, needs to have) a higher resolution than screen media. Vector graphics 
can be sized without any loss of sharpness, so are preferred by typographers. 
Also, this screens with higer resolutions than our current screens. I am 
tempted to say that if svg does not render well, it’s the browser’s problem, 
and any graphics in the production of documentation need to be vector graphics.

René.

> On 6 Mar 2020, at 21:21, Erich Steinböck  wrote:
> 
> Rony, the SVG images work fine when building for PDF, but last time I tried 
> building for HTML, I found that they displayed much worse than PNG.
> This was with the old Publican build, not Gil's new tool chain, so I'm not 
> sure how our current results are with building for HTML, but you might want 
> to wait until we understand which format works well for HTML, before doing 
> all the work turning PNGs into SVGs.
> ___
> 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 work in SourceForge Subversion repository

[René Jansen]

Seen the importance of the work on the documentation and its build chain I want 
to propose to have this captured in the ooRexx subversion repository instead of 
sending archives via Dropbox or other means. For this reason Gil, P.O. and Rony 
will be added as committers. (Gil as soon as his SourceForge ID has been made 
known).

Please try to cooperate as much as possible and communicate over the list first 
for major changes. In this case, to make the publications toolchain work again, 
and to add missing parts of the documentation, there is not much doubt about 
the necessity of the changes. In other cases, please use caution in every 
action (although we can revert any mishap) and make sure changes build on all 
supported platforms, for example by observing the Jenkins build machine closely 
after a change. Please observe that Rick and Erich have the final say in 
architecture issues regarding ooRexx and limit contributions to the 
documentation part at first.

best regards,

René.



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A first (successful) run on creating the rexxref.pdf documentation! (Re: Ad empty line problem (Re: New Process for Building the ooRexx Documentation

[René Jansen]

Hi P.O. and Gil,

Thank you very much for this work, this is a big step forward.

best regards,

René

> On 28 Feb 2020, at 10:37, P.O. Jonsson  wrote:
> 
> Dear Gil,
> 
> This is just to say that I have set up the Jenkins Win build machine to build 
> the docs now, I will add your changes when they are ready.
> 
> I am currently building all documents (17 books), one could consider to split 
> the building in two different runs for ooRexx/ooDialog. Also, since the 
> Windows builds need the documentation it would make sense to run the docs 
> before building Windows. Currently the documentation is picked up in 
> oorexxDocs, that would need to be changed to ooRexx-docs-build\oorexxDocs. 
> @Erich: can you make this change?
> 
> I had expected the build to take more time on a weaker CPU but nope - the 
> time is approximately the same - 1 hour 15 minutes for all (and I mean all) 
> documents. Building only the basic documents will take around 40 minutes.
>  
> 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] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[René Jansen]

Hi P.O.,

that is great! Did you add this to the Jenkins task so we can upload the daily 
builds for macos to sourceforge?

I hope someone fixes the cmake, but it is not my favourite tool. (I) is 
disastrous of course, (II) is not that bad, but will require admin auth if I am 
not mistaken, (III) can be avoided if we add a requirement to reboot after 
install, or if rxapi smells funny.  

Let’s postpone Catalina for the Mac build machine for now. I does not bring any 
advantage for ooRexx anyways. So I add my vote to yours.

best regards,

René.



> On 4 Feb 2020, at 16:47, P.O. Jonsson  wrote:
> 
> Dear René,
> 
> I have built from source now on Catalina and all the build tools work and I 
> can get a working installation as before on Mojave or High Sierra.
> 
> The build tools have slightly different (higher) version numbers but as long 
> as the test suite runs without problems I assume it is ok.
> 
> I am building to ~/Applications/ooRexx5 locally (same as on the Jenkins 
> slave) and then I use Disk Utility to make a .dmg.
> 
> All the user needs to do is to click the .dmg and then drag the content into 
> ~/Applications/ (or to any place of choice, the current build for Mac is 
> truly relocatable!) and adding ~/Applications/ooRexx5/bin to the path.
> 
> For Mojave and older I add the following to .bash_profile in the users home 
> directory to make it work permanently: 
> 
> # Setting PATH for ooRexx
> export PATH=~/Applications/ooRexx5/bin:$PATH
> 
> That is all that is needed for installing ooRexx on Mac.
> 
> For Catalina I used .zshrc instead .bash_profile when using the z shell. An 
> alternative is to switch to bash and use .bash_profile, both works.
> 
> With some minor changes to cmakelists.txt the cpack command can be used to 
> create a .dmg directly from the build, it even installs to the right place so 
> you can omit the make install step.
> 
> unfortunately:
> (i) the dmg is empty, the installation is not included
> (ii) the symlink inside the .dmg that you drag the installation to points to 
> /Applications rather than to ~/Applications
> (iii) pre- and postinstall scripts are missing (such as for making the path 
> addition permanent, stopping rxapi etc).
> 
> Maybe with some detective work this is a way forward. 
> 
> There should be a decision if we want the Mac build machine migrated to 
> Catalina. Currently I would vote against, Catalina is the Millennium (or 
> Windows 8) of Apple :-(
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se <mailto:oor...@jonases.se>
> 
> 
> 
>> Am 02.02.2020 um 18:27 schrieb René Jansen > <mailto:rvjan...@xs4all.nl>>:
>> 
>> Hi P.O.,
>> 
>> I understand your points. I have always been ‘bleeding edge’ and I mostly 
>> enjoy solving the problems. I agree that Apple make a lot of trouble for us 
>> but I always have a linux machine which is one 'git pull' away from me being 
>> able to continue whatever I am working on.
>> 
>> Personally, I used the zsh shell for years and years already and I would not 
>> have noticed the switch if Cataling did not break autoenv that I used a lot. 
>> But I think the decision to discontinue the use of 32bit executables is a 
>> really daft decision; it is really a downward slope: z/OS can run 24, 31 and 
>> 64 bit code alongside and call eachother, OS/2 could thunk 16 and 32 bit 
>> code, then Linux made it impossible to mix libraries and now Apple only has 
>> 64 bit. Even Raspberries can (with nearly everything except Raspbian) mix 
>> ARM7 and aarch64.
>> 
>> I have a plan to have a .dmg installer ready very soon, for my own use but 
>> maybe as a standard for the portable mac version. I’ll let you know this 
>> week, my plan was to just run it from the Jenkins machine after the builds. 
>> I need to look at your portable distribution first. I found you can turn the 
>> notarization off recursively for a directory tree with:
>> 
>> sudo xattr -r -d com.apple.quarantine $OOREXX_HOME
>> 
>> even without turning off SIP. So a .dmg installer seems fine and has my 
>> preference.
>> 
>> best regards,
>> 
>> René.
>> 
>> 
>>> On 2 Feb 2020, at 18:07, P.O. Jonsson >> <mailto:oor...@jonases.se>> wrote:
>>> 
>>> Hi René,
>>> 
>>> I have a new computer running Catalina as well (not updated but clean 
>>> built). I noticed the problems but did not get around to inform you all. 
>>> Sorry.
>>> 
>>> Re "I keep my MacBook always on the latest OS“
>>> 
>>> This is no longer a good strategy with MacOS; you have to wait at least 

Re: [Oorexx-devel] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[René Jansen]

Hi P.O.,

I understand your points. I have always been ‘bleeding edge’ and I mostly enjoy 
solving the problems. I agree that Apple make a lot of trouble for us but I 
always have a linux machine which is one 'git pull' away from me being able to 
continue whatever I am working on.

Personally, I used the zsh shell for years and years already and I would not 
have noticed the switch if Cataling did not break autoenv that I used a lot. 
But I think the decision to discontinue the use of 32bit executables is a 
really daft decision; it is really a downward slope: z/OS can run 24, 31 and 64 
bit code alongside and call eachother, OS/2 could thunk 16 and 32 bit code, 
then Linux made it impossible to mix libraries and now Apple only has 64 bit. 
Even Raspberries can (with nearly everything except Raspbian) mix ARM7 and 
aarch64.

I have a plan to have a .dmg installer ready very soon, for my own use but 
maybe as a standard for the portable mac version. I’ll let you know this week, 
my plan was to just run it from the Jenkins machine after the builds. I need to 
look at your portable distribution first. I found you can turn the notarization 
off recursively for a directory tree with:

sudo xattr -r -d com.apple.quarantine $OOREXX_HOME

even without turning off SIP. So a .dmg installer seems fine and has my 
preference.

best regards,

René.


> On 2 Feb 2020, at 18:07, P.O. Jonsson  wrote:
> 
> Hi René,
> 
> I have a new computer running Catalina as well (not updated but clean built). 
> I noticed the problems but did not get around to inform you all. Sorry.
> 
> Re "I keep my MacBook always on the latest OS“
> 
> This is no longer a good strategy with MacOS; you have to wait at least to 
> the first update (10.15.1 for Catalina) before you can be sure it works. It 
> is now on 10.15.3 and it is still no good, compared to Mojave or High Sierra. 
> Apple have started to ship beta versions of the OS :-(
> 
> 1. As of Catalina Apple have decided to use Z as the standard shell instead 
> of Bash. Unknown why but it messes things up
> 
> 2. There is no support for 32 bit code any more, apparently.
> 
> I could make my ooRexx installation work by switching to the bash shell but 
> we might need to revise the strategy for distributing ooRexx for Mac.
> 
> On the positive side: the oo installer from Bsf4ooRexx works out of the box, 
> it uses dynamic links so it is not affected by the shell change!
> 
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
> 
> 
> 
> 
>> Am 02.02.2020 um 15:51 schrieb René Jansen :
>> 
>> I keep my MacBook always on the latest OS and Xcode levels, and suddenly, 
>> with MacOS Catalina 10.15.2 and the latest XCode the ooRexx build missed 
>> stdlib.h
>> 
>> I googled stackoverflow a bit and encountered a lot of solutions that did 
>> not work. I will not withhold the one that did work from you: 
>> 
>> sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* 
>> /usr/local/include/
>> 
>> best regards,
>> 
>> René.
>> ___
>> 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

[Oorexx-devel] recent MacOS 10.15.2 and Xcode 'misses stdlib.h' build error

[René Jansen]

I keep my MacBook always on the latest OS and Xcode levels, and suddenly, with 
MacOS Catalina 10.15.2 and the latest XCode the ooRexx build missed stdlib.h

I googled stackoverflow a bit and encountered a lot of solutions that did not 
work. I will not withhold the one that did work from you: 

sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* 
/usr/local/include/

best regards,

René.___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Questions ad generating the documentation (publican, pandoc)

[René Jansen]

Hi Gil,

that looks great! I hope we can build the docs on Jenkins so that will be 
available when we need it. Probably P.O. can help us with this. Do you only 
build doc on Windows or also Linux?

best regards,

René

> On 16 Dec 2019, at 11:40, Gil Barmwater  wrote:
> 
> As a result of Jon's request, I have now done the RxMath PDF as well. Doing 
> another document helped me formalize the process so that I can automate it 
> and it identified another small issue which I thought had been corrected. You 
> can download the PDF here 
>  for comparison to 
> the rxmath.pdf that is in the docs folder of your 5.0.0 ooRexx installation 
> or the Files section on SourceForge. The differences I found are 1) the 
> Copyright dates on the second page now show -2019, and 2) the flow of the 
> text in some sections is slightly different due to extra blank lines in the 
> code examples. This issue was identified and fixed by Erich with a preprocess 
> Rexx program when building our docs using Publican so it can be adapted to my 
> process if I am unable to find the cause and change it. His program also 
> needed to fix blank lines in the Index area but that looked OK to me in my 
> build. Comments welcome.
> 
> Gil
> 
> 
> 
> Jon,
> 
> Yes, of course you are right, I need to do a more complex document to see if 
> there are other issues in addition to those I've identified so far. Stay 
> tuned...
> 
> On 12/11/2019 2:19 PM, Jon Wolfers wrote:
>> Hi Gil,
>> 
>> Looks good to me, but I'm not sure what to look for.  Any chance of a doc 
>> with railroad diagrams?
>> 
>> Jon 
>> 
>> On Wed, 11 Dec 2019, 19:00 Gil Barmwater, > > wrote:
>> Thanks for the feedback Rony. Anyone else have any comments? If not, I will 
>> start posting comments on the issues I have found shortly. My goal is to 
>> develop a package containing the tools that anyone can download and install 
>> that will allow them to build our docs on Windows 10 from a fresh checkout 
>> from SourceForge with minimal changes to those files.
>> 
>> On 12/10/2019 12:45 PM, Rony G. Flatscher wrote:
>>> Wow, that is *fantastic* news!! Also, looking at your readme.pdf it looks 
>>> terrific IMHO!
>>> 
>>> Very curious what you have come up with to be able to generate the ooRexx 
>>> 5.0 documentation yourself� (and also about the questions that you will 
>>> pose in order to learn about the current problems from them and become able 
>>> to build the ooRexx documentation in the near future and in a future-safe 
>>> way)!
>>> 
>>> Kudos!
>>> 
>>> ---rony
>>> 
>>> On 10.12.2019 18:17, Gil Barmwater wrote:
 I know it has been over a month since I posted the note below but I now 
 have a lot of progress to report! I have obtained the tools needed to 
 build our docs - they are open source and seem well supported - and have 
 successfully built one document using them on Windows 10. There are no 
 dependencies on Publican other than three files I chose to retain to 
 simplify the transition. Installing and using the tools was pretty 
 painless but in doing so I uncovered a number of issues with our 
 documents, most of which are due to our use of Publican and what it does 
 "under the   covers". Rather than turning this email into 
 a "book", I will send separate notes on each issue and the changes needed 
 in order to use the new tools. In the meantime, here 
  is a link to a 
 file in my Dropbox for the readme.pdf that I built. Once the link opens in 
 your browser, you can click on the ... icon on the right which will open a 
 menu that will allow you to download the file. If you then compare it to 
 the readme.pdf that is in the docs folder of your 5.0.0 ooRexx 
 installation or the Files section on SourceForge, you will see it is 
 (almost) identical. The differences are 1) the text has been updated in 
 section 2.2, 2) the Copyright dates on the first page now show -2019, 3) 
 the flow of the text in some sections is slightly different, in some cases 
 causing text to flow to the next page, and 4) the Table of Contents has 
 more levels listed. I did not feel that either of the last two items were 
 worth pursuing. Let me know what you think after you've had a look.
 
 Gil B.
 
 --
 Just so everyone doesn't think I've abandoned this effort, I am pursuing 
 another approach to building the docs. You can expect an update when I've 
 made some more progress.
 
 
 On 

Re: [Oorexx-devel] dependency on svn

[René Jansen]

Hi Enrico,

can you make it so that cmake does not choke on an absent svn? Working 
revisions on git is a bonus but I don’t really need that - and they are uuids.
I’m all for git, in fact this is one of the last svn instances I pull from. But 
I don’t want to start that discussion, I just want to get rid of the dependency 
(which in my view, is wrong). 
If you can make that happen, that would be great. For now, I just edit it out 
but will leave it in the svn repo.

In NetRexx, we generate the revision as a timestamp, and a build number to a 
file and pick that up, and we made the change to git some years ago without 
even noticing.

best regards,

René

> On 13 Sep 2019, at 09:14, Enrico Sorichetti via Oorexx-devel 
>  wrote:
> 
> The test are coming out pretty well 
> Buillt from a SVN repo
> Open Object Rexx Version 5.0.0 r11911 Svn[11911+]
> Build date: Sep 13 2019
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2019 Rexx Language Association. All rights reserved.
> 
> The “+” tells that there are uncommitted changes
> 
> Built from a GIT Repo
> [enrico@enrico-imac ooRexx.trunk.bin]$/Users/enrico/ooRexx/bin/rexx -v
> Open Object Rexx Version 5.0.0 r1 Git[9e6661ee02d3]
> Build date: Sep 13 2019
> Addressing mode: 64
> Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
> Copyright (c) 2005-2019 Rexx Language Association. All rights reserved.
> 
> Enrico
> 
> PS.: If You want I can also do it for a mercurial repository
> 
> I know the nobody wants to hear about it, but having a GIT repo would make 
> collaboration MUCH MORE EASY
> 
> Fork the repo 
> Commit the proposed changes to the forked repository
> Create a pull request
> Process the pull request ( apply / reject )
> 
> 
>> On 13 Sep 2019, at 11:44, Rick McGuire > <mailto:object.r...@gmail.com>> wrote:
>> 
>> Yes, I object to the removal. Including the revision number information is a 
>> helpful tool for problem determination. I much prefer Enrico's suggestion to 
>> enhance this to obtain the revision number from other sources as well. 
>> 
>> Rick
>> 
>> On Fri, Sep 13, 2019 at 12:18 AM René Jansen > <mailto:rvjan...@xs4all.nl>> wrote:
>> I am maintaining a docker image based on Arch linux that contains LSPF and 
>> ooRexx 5.0.0. I just tried to rebuild that because of the impending 
>> symposium and had spurious behavior from svn on SourceForge (truncated http 
>> response bodies blablabla) and I could not fix that quickly.
>> 
>> So I decided to put up a copy on Github which works brilliantly. But … and 
>> here it comes… CmakeLists.txt has a hard dependency on Subversion and does 
>> an 'svn info' which breaks the build from git, as that is not an svn working 
>> copy.
>> 
>> I cannot see the rationale for this. Took it out and the build succeeds. 
>> Does anybody mind if I take that out of the svn repository CMakeLists.txt 
>> also?
>> 
>> best regards,
>> 
>> René.
>> 
>> ___
>> 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
> 
> ___
> 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] dependency on svn

[René Jansen]

I am maintaining a docker image based on Arch linux that contains LSPF and 
ooRexx 5.0.0. I just tried to rebuild that because of the impending symposium 
and had spurious behavior from svn on SourceForge (truncated http response 
bodies blablabla) and I could not fix that quickly.

So I decided to put up a copy on Github which works brilliantly. But … and here 
it comes… CmakeLists.txt has a hard dependency on Subversion and does an 'svn 
info' which breaks the build from git, as that is not an svn working copy.

I cannot see the rationale for this. Took it out and the build succeeds. Does 
anybody mind if I take that out of the svn repository CMakeLists.txt also?

best regards,

René.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Windows commands change console window title

[René Jansen]

I have no problem in seeing it go. Not that I run a lot of windows (but that 
will change now we have the portable version).

René.


> On 27 Apr 2019, at 14:58, Erich Steinböck  wrote:
> 
> On Windows, our default command handler changes the console window title to 
> "path-to-cmd\cmd.exe /c executing-command" and after the command finishes, 
> reverts it to what it was before.
> 
> Is there a good reason we're doing this? Windows batch files don't do it, and 
> most commands won't run long enough for a user to actually be able to read 
> the new title.
> 
> I intend to make the new SYSTEM and PATH command environments skip this title 
> change.
> 
> Do we want to keep the console title changing for commands running in our 
> existing environments CMD and "" ?
> ___
> 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] Releasing ooRexx 5.0?

[René Jansen]

Hi Michael,

try: svn checkout svn://svn.code.sf.net/p/oorexx/code-0/main/trunk oorexx-code-0

best regards,

René.   

> On 15 Jan 2019, at 13:35, Michael Lueck  wrote:
> 
> Greetings ooRexx'ers,
> 
> Rick McGuire wrote:
>> Also, with changes for rxapi, this really needs a longer beta-test to make 
>> sure we've not overlooked any major issues.
> 
> 
> This tells me it is time to do a pull/build on the 1&1 Linux Shared Web 
> Hosting server.
> 
> How do I do the correct source code pull?
> 
> I am thankful,
> 
> -- 
> Michael Lueck
> Lueck Data Systems
> http://www.lueckdatasystems.com/
> 
> 
> ___
> 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] Releasing ooRexx 5.0?

[René Jansen]

Then we will not freeze. Can you give us a heads up when it is a convenient 
time to freeze?

I was happy we did not freeze last time, because it gave us the rxapi and 
usb-install functionality, the gencat elimination and some more.

best regards,

René.


> On 15 Jan 2019, at 11:51, Rick McGuire  wrote:
> 
> I am against a freeze, as I've got some changes in the works that I'd really 
> like to get into the 5.0 release. 
> 
> Rick
> 
> On Tue, Jan 15, 2019 at 10:46 AM René Jansen  <mailto:rvjan...@xs4all.nl>> wrote:
> I am for it, but I think it is up to Erich and Rick.
> 
> To be precise, I am for freezing, setting a date and prepare. I would like to 
> have the oorexx.org <http://oorexx.org/> website up to date before we 
> announce. I did some work last year, which is accessible through 
> oorexx.org/index2.html <http://oorexx.org/index2.html> , but I need to finish 
> that. Also - documentation. We must be able to build it in a repeatable 
> fashion and not when someone’s pc has the right configuration. We are working 
> towards that, albeit slowly.
> 
> I was planning for the symposium, but I can imagine it would be better if we 
> did it earlier.
> 
> My proposal: freeze now and release March 1st.
> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel