[Oorexx-devel] Jenkins

[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

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

[P.O. Jonsson]

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

Re: [Oorexx-devel] Planned commits

[P.O. Jonsson]

Dear Rony,

> concurrency trace:
I have no opinion on this feature, although it seems useful for those debugging 
multi-thread programs, but if it is a „showstopper“ for releasing 5.0.0 I would 
also tend to think it is better put in the pipeline for 5.0.1. But only if it 
is REALLY a hindrance to release 5.0.0, which I think should take place asap. 
As I understand the discussion there are no other real showstoppers left?
> 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.
I am also not a fan of overcomplicating things (2 dedicated ooRexx installers 
for Intel/M1 would be easier to maintain IMO) but if it is the wish of the 
community to have „fat“ installers I can work with you to get this into the 
pipeline, but just not at the moment, I am only in Berlin for a couple of days 
and then off again. Mid October I can do some things. At the moment I have no 
M1 to test things on BTW, it would be great to have that for Jenkins.

/P.O.
> 
> ___
> 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

Re: [Oorexx-devel] Planned commits

[Sahananda Sahananda]

To be fair to Rony, he is not the only one keen to have a release and he
has suggested holding back some features for a subsequent release.

I won't rehash the reasons why we need a release - I think we are all
familiar with them.

So, can I suggest that we mark this enhancement (which I think is very
important, but not as important as ending the beta state of 5.0.0) for
5.0.1 And release 5.0.0 as soon as we can?

Jon



On Wed, 15 Sep 2021, 23:15 Rick McGuire,  wrote:

> Since you are the one pushing to get 5.0 released, why are you adding new
> features to the interpreter at this point? I'm OK with the MacOS changes,
> but I'm against adding any new features to 5.0.
>
> Rick
>
> On Tue, Sep 14, 2021 at 12:19 PM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> 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 mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel