netrexx-develop — developers list

Re: [Netrexx-develop] automatic 'uses'

[Marc R. <re...@gm...>]

Hi René,

I think that should be possible.
Let me look at it.

Marc

On 3/23/22 12:12, René Jansen wrote:
> Hi Marc and developers,
> 
> when using ‘uses’ (of which I did not see the use the first few decennia of NetRexx’ existence) there needs to be a ‘class’ defined. As we recently added a lot of Classic Rexx functionality (address, address with, Date, and now stream I/O in the upcoming NetRexx 4.03, it seems fitting that one can ‘uses’ these in scripting mode. Would that be an easy fix? (Auto-include a ‘uses RexxStream, RexxTime on the generated class?) Are there counterexamples?
> 
> best regards,
> 
> René.
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

[Netrexx-develop] automatic 'uses'

[René J. <rvj...@xs...>]

Hi Marc and developers,

when using ‘uses’ (of which I did not see the use the first few decennia of NetRexx’ existence) there needs to be a ‘class’ defined. As we recently added a lot of Classic Rexx functionality (address, address with, Date, and now stream I/O in the upcoming NetRexx 4.03, it seems fitting that one can ‘uses’ these in scripting mode. Would that be an easy fix? (Auto-include a ‘uses RexxStream, RexxTime on the generated class?) Are there counterexamples?

best regards,

René.

Re: [Netrexx-develop] address with stream

[Marc R. <re...@gm...>]

As discussed, latest commit does not exit.
When an exception occurs, it is shown on stdout and RC is blanked ('').

On 3/6/22 17:20, René Jansen wrote:
> 
> Yes, I think it is true that we don’t want to have to wrap address statements in exception handlers. Indeed maybe catching them and showing error messages and (high) returncodes is a better alternative. Or do we want some kind of event signalled - you only see that when you subscribe to it, and it just returns when nobody subscribed to it. That would look a lot like ‘signal on x’.
> 
> René.
> 
>> On 6 Mar 2022, at 15:16, Marc Remes <re...@gm...> wrote:
>>
>> 
>> oorexx signals are different, if you don't want to bother with them, you can just ignored them.
>> You can 'trap' errors such as "address 'bbash' 'bbash'" by signals, if you do not have a 'signal on error' the script just continues.
>> But specifying non-readable/writable streams just plain exits the oorexx script, not trappable.
>>
>> Throwing such exception implies that any method which uses the ADDRESS instruction needs to put it in its signallist if the exception is not catched. Do we want this? And what about 'classless' scripts?
>> There is no other NetRexx instruction that throws exceptions, in fact method interpret in interface RxClauseParser has an empty signallist. Changing that is significant.
>>
>> I'm much in favor of restoring previous behavior, i.e. catching the exceptions in RexxAddress, but clearly show them on stdout as '+++ Error: Exception occurred during ADDRESS invocation', and setting RC empty or as 'RC'.
>>
>> The user anyway would need to check RC after execution, and if desired a NumberFormatException can be catched.
>>
>> Marc
>>
>>
>> On 3/6/22 13:25, Rony G. Flatscher wrote:n
>>>> On 05.03.2022 17:48, René Jansen wrote:
>>>> No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?
>>> Also cf. ooRexx 5.0' reference documentation in "rexxref.pdf", chapters "2.1 ADDRESS" and "11.
>>> Conditions and Condition Traps", for the conditions "error" and "failure" w.r.t. problems while
>>> executing a command. If seen helpful one could distinguish both conditions in a field of
>>> AddressEnvironmentException.
>>> ---rony
>>>>
>>>>> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
>>>>>
>>>>>
>>>>> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
>>>>> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
>>>>> The exitcode is 9.
>>>>> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
>>>>>
>>>>> Personally I don't find such hard exit optimal.
>>>>> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
>>>>> Both options could be coded and controlled by a new ADDRESSEXIT option.
>>>>>
>>>>> Your views?
>>>>>
>>>>> This code now also always correctly handles stderr.
>>>>>
>>>>> Marc
>>> _______________________________________________
>>> Netrexx-develop mailing list
>>> Net...@li...
>>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> 

Re: [Netrexx-develop] address with stream

[René J. <rvj...@xs...>]

Yes, I think it is true that we don’t want to have to wrap address statements in exception handlers. Indeed maybe catching them and showing error messages and (high) returncodes is a better alternative. Or do we want some kind of event signalled - you only see that when you subscribe to it, and it just returns when nobody subscribed to it. That would look a lot like ‘signal on x’.

René.

> On 6 Mar 2022, at 15:16, Marc Remes <re...@gm...> wrote:
> 
> 
> oorexx signals are different, if you don't want to bother with them, you can just ignored them.
> You can 'trap' errors such as "address 'bbash' 'bbash'" by signals, if you do not have a 'signal on error' the script just continues.
> But specifying non-readable/writable streams just plain exits the oorexx script, not trappable.
> 
> Throwing such exception implies that any method which uses the ADDRESS instruction needs to put it in its signallist if the exception is not catched. Do we want this? And what about 'classless' scripts?
> There is no other NetRexx instruction that throws exceptions, in fact method interpret in interface RxClauseParser has an empty signallist. Changing that is significant.
> 
> I'm much in favor of restoring previous behavior, i.e. catching the exceptions in RexxAddress, but clearly show them on stdout as '+++ Error: Exception occurred during ADDRESS invocation', and setting RC empty or as 'RC'.
> 
> The user anyway would need to check RC after execution, and if desired a NumberFormatException can be catched.
> 
> Marc
> 
> 
> On 3/6/22 13:25, Rony G. Flatscher wrote:n
>>> On 05.03.2022 17:48, René Jansen wrote:
>>> No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?
>> Also cf. ooRexx 5.0' reference documentation in "rexxref.pdf", chapters "2.1 ADDRESS" and "11.
>> Conditions and Condition Traps", for the conditions "error" and "failure" w.r.t. problems while
>> executing a command. If seen helpful one could distinguish both conditions in a field of
>> AddressEnvironmentException.
>> ---rony
>>> 
>>>> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
>>>> 
>>>> 
>>>> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
>>>> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
>>>> The exitcode is 9.
>>>> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
>>>> 
>>>> Personally I don't find such hard exit optimal.
>>>> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
>>>> Both options could be coded and controlled by a new ADDRESSEXIT option.
>>>> 
>>>> Your views?
>>>> 
>>>> This code now also always correctly handles stderr.
>>>> 
>>>> Marc
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] address with stream

[Marc R. <re...@gm...>]

oorexx signals are different, if you don't want to bother with them, you can just ignored them.
You can 'trap' errors such as "address 'bbash' 'bbash'" by signals, if you do not have a 'signal on error' the script 
just continues.
But specifying non-readable/writable streams just plain exits the oorexx script, not trappable.

Throwing such exception implies that any method which uses the ADDRESS instruction needs to put it in its signallist if 
the exception is not catched. Do we want this? And what about 'classless' scripts?
There is no other NetRexx instruction that throws exceptions, in fact method interpret in interface RxClauseParser has 
an empty signallist. Changing that is significant.

I'm much in favor of restoring previous behavior, i.e. catching the exceptions in RexxAddress, but clearly show them on 
stdout as '+++ Error: Exception occurred during ADDRESS invocation', and setting RC empty or as 'RC'.

The user anyway would need to check RC after execution, and if desired a NumberFormatException can be catched.

Marc


On 3/6/22 13:25, Rony G. Flatscher wrote:n
> On 05.03.2022 17:48, René Jansen wrote:
>> No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?
> 
> Also cf. ooRexx 5.0' reference documentation in "rexxref.pdf", chapters "2.1 ADDRESS" and "11.
> Conditions and Condition Traps", for the conditions "error" and "failure" w.r.t. problems while
> executing a command. If seen helpful one could distinguish both conditions in a field of
> AddressEnvironmentException.
> 
> ---rony
> 
>>
>>> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
>>>
>>>
>>> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
>>> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
>>> The exitcode is 9.
>>> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
>>>
>>> Personally I don't find such hard exit optimal.
>>> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
>>> Both options could be coded and controlled by a new ADDRESSEXIT option.
>>>
>>> Your views?
>>>
>>> This code now also always correctly handles stderr.
>>>
>>> Marc
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] address with stream

[Rony G. F. <Ron...@wu...>]

On 05.03.2022 17:48, René Jansen wrote:
> No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?

Also cf. ooRexx 5.0' reference documentation in "rexxref.pdf", chapters "2.1 ADDRESS" and "11.
Conditions and Condition Traps", for the conditions "error" and "failure" w.r.t. problems while
executing a command. If seen helpful one could distinguish both conditions in a field of
AddressEnvironmentException.

---rony

>
>> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
>>
>>
>> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
>> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
>> The exitcode is 9.
>> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
>>
>> Personally I don't find such hard exit optimal.
>> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
>> Both options could be coded and controlled by a new ADDRESSEXIT option.
>>
>> Your views?
>>
>> This code now also always correctly handles stderr.
>>
>> Marc

Re: [Netrexx-develop] address with stream

[René J. <rvj...@xs...>]

No, I thinks that is definitely suboptimal. Why don’t we throw a netrexx.lang.AddressEnvironmentException, that the user can catch if they want to?

René.


> On 5 Mar 2022, at 16:24, Marc Remes <re...@gm...> wrote:
> 
> 
> The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
> Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
> The exitcode is 9.
> Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.
> 
> Personally I don't find such hard exit optimal.
> Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such exceptional condition.
> Both options could be coded and controlled by a new ADDRESSEXIT option.
> 
> Your views?
> 
> This code now also always correctly handles stderr.
> 
> Marc
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] address with stream

[Marc R. <re...@gm...>]

The latest commit exits the NetRexx program when an exception is thrown during ADDRESS invocation.
Such exception can occur when the specified environment is not executable, or when a specified stream is unusable.
The exitcode is 9.
Note, "address bash 'nonexistingcommand'" will not exit, instead processing will complete and say 'command not found'.

Personally I don't find such hard exit optimal.
Another option is not to exit, and reset the special variable RC to undefined 'RC', where the calling user can find such 
exceptional condition.
Both options could be coded and controlled by a new ADDRESSEXIT option.

Your views?

This code now also always correctly handles stderr.

Marc

[Netrexx-develop] address with stream

[Marc R. <re...@gm...>]

I have pushed an update to branch address-with which supports the ADDRESS WITH invocation with redirection to/from streams.

Now also the NetRexx program will exit when any IOException or InterruptedException occurs during processing of the 
external command.
This is an important change, as previously such exceptions were only 'said' on the console, but the program continued.

Now compiled NetRexx programs will exit(9) upon ADDRESS exception, interpreted programs will properly call RxQuit.
I'm still looking at making this behaviour identical..

But in the meantime, you can already test the code.

Marc

Re: [Netrexx-develop] address with

[René J. <rvj...@xs...>]

Hi Marc,

Thanks! Great …. I am going to have a look at it.

René.

> On 26 Feb 2022, at 14:43, Marc Remes <re...@gm...> wrote:
> 
> I just pushed a first draft of 'ooRexx-like' ADDRESS WITH implementation to the address-with branch.
> Currently it only supports stems, aka indexed strings.
> Input and output stems must be of Rexx type, where
> stem['0'] specifies the number of lines, and each stem['i'] specifies a line (with i from 1 through stem['0']).
> 
> DiagAddress.nrx has some sample code, such as
> <<
> 
> istem=''
> ostem=''
> estem=''
> 
> istem['0']=1
> istem['1']='Hello world'
> 
> address bash 'cat' with input stem istem
> 
> istem['1']='echo Hello world'
> ostem['0']=0
> 
> address bash 'bash' with input stem istem output APPEND stem ostem error stem estem
> loop i=1 to ostem[0]
>  say 'STDOUT: 'ostem[i]
> end
> loop i=1 to estem[0]
>  say 'STDERR: 'estem[i]
> end
> 
> >>
> 
> IMHO, all ooRexx features are supported for stems, including 'permanent' redirection.
> 
> 
> Marc
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

[Netrexx-develop] address with

[Marc R. <re...@gm...>]

I just pushed a first draft of 'ooRexx-like' ADDRESS WITH implementation to the address-with branch.
Currently it only supports stems, aka indexed strings.
Input and output stems must be of Rexx type, where
stem['0'] specifies the number of lines, and each stem['i'] specifies a line (with i from 1 through stem['0']).

DiagAddress.nrx has some sample code, such as
<<

istem=''
ostem=''
estem=''

istem['0']=1
istem['1']='Hello world'

address bash 'cat' with input stem istem

istem['1']='echo Hello world'
ostem['0']=0

address bash 'bash' with input stem istem output APPEND stem ostem error stem estem
loop i=1 to ostem[0]
   say 'STDOUT: 'ostem[i]
end
loop i=1 to estem[0]
   say 'STDERR: 'estem[i]
end

 >>

IMHO, all ooRexx features are supported for stems, including 'permanent' redirection.


Marc

[Netrexx-develop] strictcomment?

[Jason M. <agr...@gm...>]

Stop line comments inside block comments, also?


NetRexxC.properties:299: nested.comment.blocked Nested comment 
disallowed with STRICTCOMMENT option

/* ONLY IF, YOU WISH TO BLOCK LINE COMMENT INSIDE OF BLOCK COMMENT */
RxClauser.nrx:475: if c1="-" & line[pos-1]="-" then do -- strictcomment
RxClauser.nrx:476: if rxt.program.flag.strictcomment then signal 
RxQuit(rxt,tok,"nested.comment.blocked",source.getName())
RxClauser.nrx:477: end -- strictcomment
/* ONLY IF, YOU WISH TO BLOCK LINE COMMENT INSIDE OF BLOCK COMMENT */

RxClauser.nrx:497: if rxt.program.flag.strictcomment then signal 
RxQuit(rxt,tok,"nested.comment.blocked",source.getName())

RxFlag.nrx:65: strictcomment = boolean 0     -- nested comments disallowed
RxFlag.nrx:105: strictcomment=orig.strictcomment
RxFlag.nrx:155: when opt=='STRICTCOMMENT' then strictcomment=new
RxFlag.nrx:217: if strictcomment then acc=acc 'Strictcomment'
RxFlag.nrx:218: else if nose then acc=acc 'NoStrictcomment'
RxFlag.nrx:268: say '  -strictcomment -- block nested comments in source 
code'

Re: [Netrexx-develop] sf certificate login

[René J. <rvj...@xs...>]

Thanks Jason, I can now stop generating new certs and do something useful.

René.

> On 1 Feb 2022, at 14:23, Jason Martin <agr...@gm...> wrote:
> 
> On 2/1/22 07:59, René Jansen wrote:
>> Anyone else having trouble with sourceforge push/pull asking for password? My certificate seems inoperative, but a new one also.
>> 
>> René.
>> 
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> 
> agrellum@vbx:~$ git clone ssh://agr...@gi.../p/netrexx/code WaterTiger
> Cloning into 'WaterTiger'...
> Password:
> 
> Same here.
> 
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] sf certificate login

[Jason M. <agr...@gm...>]

On 2/1/22 07:59, René Jansen wrote:
> Anyone else having trouble with sourceforge push/pull asking for password? My certificate seems inoperative, but a new one also.
>
> René.
>
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

agrellum@vbx:~$ git clone ssh://agr...@gi.../p/netrexx/code 
WaterTiger
Cloning into 'WaterTiger'...
Password:

Same here.

[Netrexx-develop] sf certificate login

[René J. <rvj...@xs...>]

Anyone else having trouble with sourceforge push/pull asking for password? My certificate seems inoperative, but a new one also.

René.

Re: [Netrexx-develop] Bug fix for RxModel commited

[René J. <rvj...@xs...>]

I certainly did not start on that!

René.

> On 31 Jan 2022, at 17:46, Jason Martin <agr...@gm...> wrote:
> 
> I will also try to work on:
> 
> --strictcomments
> 
> https://github.com/RexxLA/NetRexx/issues/25
> 
> if no one else has started it.
> 
> 
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

[Netrexx-develop] Bug fix for RxModel commited

[Jason M. <agr...@gm...>]

I will also try to work on:

--strictcomments

https://github.com/RexxLA/NetRexx/issues/25

if no one else has started it.

Re: [Netrexx-develop] RxModel exception

[Marc R. <re...@gm...>]

I confirm Jason.

Thanks

Marc

On 1/31/22 16:00, Jason Martin wrote:
> 
>> if 1 == 1 then do
>>   leave
>> end
> 
> 
> The fix for RxModel.nrx is :
> 
>     532              /* get the line we passed on */
>     533              if index>1 then do
>     534                lastline=scrub(Rexx program.clauser.clause(index-1))
>     535              end
> 
> This will generate a -model[0-3] file for above example even when the compile fails.
> 
> Tested by applying Model 2 to the entire NetRexx tree while building.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] RxModel exception

[Jason M. <agr...@gm...>]

> if 1 == 1 then do
>   leave
> end


The fix for RxModel.nrx is :

    532              /* get the line we passed on */
    533              if index>1 then do
    534                lastline=scrub(Rexx program.clauser.clause(index-1))
    535              end

This will generate a -model[0-3] file for above example even when the 
compile fails.

Tested by applying Model 2 to the entire NetRexx tree while building.

Re: [Netrexx-develop] RxModel exception

[Jason M. <agr...@gm...>]

On 1/31/22 06:12, Marc Remes wrote:
> Hi Jason,
>
> your rxModel code is very useful to reformat source code, I really 
> like it.
>
> FWIW, with rxFlag's model=2, I encountered following error when testing:
>
> [~]$ cat t.nrx
>
>
> if 1 == 1 then do
>   leave
> end
>
> [~]$ nrc t.nrx
> NetRexx portable processor 4.03-PRE build 559-20220131-1155
> Copyright (c) RexxLA, 2011,2022.   All rights reserved.
> Parts Copyright (c) IBM Corporation, 1995,2008.
> Program t.nrx
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 
> Index -1 out of bounds for length 500
>     at org.netrexx.process.RxClauser.clause(RxClauser.java:186)
>     at org.netrexx.process.RxModel.process(RxModel.java:756)
>     at 
> org.netrexx.process.RxTranslator.dotranslate(RxTranslator.java:635)
>     at org.netrexx.process.RxTranslator.translate(RxTranslator.java:393)
>     at org.netrexx.process.NetRexxC.process(NetRexxC.java:519)
>     at org.netrexx.process.NetRexxC.main2(NetRexxC.java:341)
>     at org.netrexx.process.NetRexxC.main2(NetRexxC.java:321)
>     at org.netrexx.process.NetRexxC.main2(NetRexxC.java:317)
>     at org.netrexx.process.NetRexxC.main(NetRexxC.java:171)
>
>
> Marc
>
>
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Bug found on line 533 in RxModel for small code chunks

           /* get the line we passed on */
           lastline=scrub(Rexx program.clauser.clause(index-1))

Will try to fix and test soon.

Thanks to Marc

Re: [Netrexx-develop] RxModel exception

[Jason M. <agr...@gm...>]

First, does this compile for you without using any Model?

Program t.nrx

  2 +++   leave
    +++   ^^^^^
    +++ Error: LEAVE without label is not inside LOOP construct
Compilation of 't.nrx' failed [one error]
Compilation failed.

Second, there are still some fringe cases where RxModel does fail.

There are three files in NetRexx itself that will fail because of 
expressions.

Mostly stuff like "--" or "++" where NetRexx sorts those out in the next 
level of code parsing.

RxModel works only at the Clause level.

If I remember right, DiagExpression.nrx, DiagExpressionUnit.nrx and 
DiagUTF8.nrx.

I did not use it as much with -models2 although it does a pretty good job.

I got more use out of it using -model1 to structure the largest files in 
NetRexx to see exactly where I needed to insert code changes.

Lastly, I do need to improve it some and I hope more people find it a 
useful tool to improve code quality.

[Netrexx-develop] RxModel exception

[Marc R. <re...@gm...>]

Hi Jason,

your rxModel code is very useful to reformat source code, I really like it.

FWIW, with rxFlag's model=2, I encountered following error when testing:

[~]$ cat t.nrx


if 1 == 1 then do
   leave
end

[~]$ nrc t.nrx
NetRexx portable processor 4.03-PRE build 559-20220131-1155
Copyright (c) RexxLA, 2011,2022.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program t.nrx
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 500
	at org.netrexx.process.RxClauser.clause(RxClauser.java:186)
	at org.netrexx.process.RxModel.process(RxModel.java:756)
	at org.netrexx.process.RxTranslator.dotranslate(RxTranslator.java:635)
	at org.netrexx.process.RxTranslator.translate(RxTranslator.java:393)
	at org.netrexx.process.NetRexxC.process(NetRexxC.java:519)
	at org.netrexx.process.NetRexxC.main2(NetRexxC.java:341)
	at org.netrexx.process.NetRexxC.main2(NetRexxC.java:321)
	at org.netrexx.process.NetRexxC.main2(NetRexxC.java:317)
	at org.netrexx.process.NetRexxC.main(NetRexxC.java:171)


Marc

Re: [Netrexx-develop] RxJrt.nrx supporting --add-modules

[Marc R. <re...@gm...>]

René, et all,

approaching the modules as plain jar files also works, without the need for Java 9 and its JPMS API.

Branch issues/4-modules contains a fix for issue #4 Extra JMPS modules are not loaded.

Extra modules are provided to the java runtime with the --module-path argument, --module-path describes a list of 
directories containing module jar files.

Because, by default, NetRexx programs compile in the unnamed module, any referenced jar file must be included in the 
--add-modules option at run-time.
So --module-path PATH1:PATH2 is needed at compile-time, --module-path PATH1:PATH2 --add-module JAR1,JAR2 is needed at 
run-time.
Java also supports the --upgrade-module-path PATH1:PATH2 option, which 'adds' all modules in the given paths to the 
unnamed module.

Setting the options in the JDK_JAVA_OPTIONS environment variable will allow NetRexx to find classes in the given modules.

By convenience, NetRexx supports both --module-path and --upgrade-module-path:

$ export JDK_JAVA_OPTIONS='--upgrade-module-path PATH1:PATH2'
$ nrc -run code-needing-classes-from-modules-outside-jrt

or

 > set JDK_JAVA_OPTIONS=--upgrade-module-path "PATH1;PATH2"
 > nrc -run code-needing-classes-from-modules-outside-jrt

Marc


On 1/27/22 17:05, Marc Remes wrote:
> It's the chicken and the egg.
> 
> You cannot access the JPMS API (ModuleFinder.of, ModuleReference etc) from Java 8.
> With NRX 4.02 we only checked if the 'jrt:' URI is present, which is possible in Java 8.
> 
> Indeed the build process will be a headache.
> 
> Marc
> 
> On 1/27/22 15:24, René Jansen wrote:
>> Ah this list does not have a reply to list on the default.
>>
>> I mentioned to Marc that we can do a conditional compile for this. Java 8 does not support JPMS, so we probably just 
>> have that call fail; there is no point in even trying supporting that on Java 8.
>> Harder part here is that we need to make sure the class file version is compatible specially seen the bootstrapping 
>> and ant.  So we might need to do a Class.forName depending on the JVM/Class file version. This might be a strategy to 
>> support even older versions - most of NetRexx is Java 1.1 and 1.2 compatible. But it will be a headache for the build 
>> process. I am severely disgruntled by what Oracle is doing to Java: Java source code looks uglier than ever, and it 
>> became just like Visual Basic to keep up with all the ‘improvements’ in the infrastructure. Removing Applets etc is 
>> just vandalism, I have a math course in applets that works fine using appletviewer only that also vanished. And all 
>> those security bugs were mostly windows and some were self-inflicted by not thinking straight while implementing 
>> invokedynamic.
>>
>> I see these people breaking everything one day by enforcing those method<type> calls and then we are further away from 
>> home. JRuby struggled more than we for Java 9 support, that came about only last week or so. And look at WebSphere. It 
>> might be a strategy.
>>
>> René.
>>
>>
>>
>>
>>> On 27 Jan 2022, at 14:53, Rony G. Flatscher <Ron...@wu...> wrote:
>>>
>>> On 27.01.2022 13:53, Marc Remes wrote:
>>>> And a side note..
>>>> You need java 9 or above to compile and run this.
>>>>
>>>> Which brings up another topic : are we ready to stop supporting java 8?
>>>
>>> Please no, unless you want to remove most of the Java installed base for NetRexx.
>>> :)
>>>
>>> Seriously, NetRexx should support Java 8 as long as Java 8 gets supported by OpenJDK distributors.
>>> E.g. Oracle and Azul support Java 8 until December 2030, for very good reasons! Actually Java 8 gets
>>> currently a longer support than Java 11 LTS and Java 17 LTS, believe it or not.
>>>
>>> [BSF4ooRexx still supports Java 6 as its baseline (that is the reason for "6" in "641", "41" means
>>> ooRexx baseline is version 4.1) as there are companies/organizations that have still Java 6
>>> deployed. This incurs quite some overhead and support efforts as in Java 6 one needs to use
>>> java.lang.reflect whereas starting with Java 9 one must use java.lang.invoke instead (actually
>>> BSF4ooRexx uses by default java.lang.invoke starting with Java 8 as Java 7, where this package got
>>> introduced, has some missing support in that area).]
>>>
>>> In general a good overview of the support dates for different versions of Java by different
>>> distributors can be found here: <https://en.wikipedia.org/wiki/Java_version_history>.
>>>
>>> ---rony
>>>
>>>
>>>
>>> _______________________________________________
>>> Netrexx-develop mailing list
>>> Net...@li...
>>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
>>
>>
>>
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] RxJrt.nrx supporting --add-modules

[Marc R. <re...@gm...>]

It's the chicken and the egg.

You cannot access the JPMS API (ModuleFinder.of, ModuleReference etc) from Java 8.
With NRX 4.02 we only checked if the 'jrt:' URI is present, which is possible in Java 8.

Indeed the build process will be a headache.

Marc

On 1/27/22 15:24, René Jansen wrote:
> Ah this list does not have a reply to list on the default.
> 
> I mentioned to Marc that we can do a conditional compile for this. Java 8 does not support JPMS, so we probably just have that call fail; there is no point in even trying supporting that on Java 8.
> Harder part here is that we need to make sure the class file version is compatible specially seen the bootstrapping and ant.  So we might need to do a Class.forName depending on the JVM/Class file version. This might be a strategy to support even older versions - most of NetRexx is Java 1.1 and 1.2 compatible. But it will be a headache for the build process. I am severely disgruntled by what Oracle is doing to Java: Java source code looks uglier than ever, and it became just like Visual Basic to keep up with all the ‘improvements’ in the infrastructure. Removing Applets etc is just vandalism, I have a math course in applets that works fine using appletviewer only that also vanished. And all those security bugs were mostly windows and some were self-inflicted by not thinking straight while implementing invokedynamic.
> 
> I see these people breaking everything one day by enforcing those method<type> calls and then we are further away from home. JRuby struggled more than we for Java 9 support, that came about only last week or so. And look at WebSphere. It might be a strategy.
> 
> René.
> 
> 
> 
> 
>> On 27 Jan 2022, at 14:53, Rony G. Flatscher <Ron...@wu...> wrote:
>>
>> On 27.01.2022 13:53, Marc Remes wrote:
>>> And a side note..
>>> You need java 9 or above to compile and run this.
>>>
>>> Which brings up another topic : are we ready to stop supporting java 8?
>>
>> Please no, unless you want to remove most of the Java installed base for NetRexx.
>> :)
>>
>> Seriously, NetRexx should support Java 8 as long as Java 8 gets supported by OpenJDK distributors.
>> E.g. Oracle and Azul support Java 8 until December 2030, for very good reasons! Actually Java 8 gets
>> currently a longer support than Java 11 LTS and Java 17 LTS, believe it or not.
>>
>> [BSF4ooRexx still supports Java 6 as its baseline (that is the reason for "6" in "641", "41" means
>> ooRexx baseline is version 4.1) as there are companies/organizations that have still Java 6
>> deployed. This incurs quite some overhead and support efforts as in Java 6 one needs to use
>> java.lang.reflect whereas starting with Java 9 one must use java.lang.invoke instead (actually
>> BSF4ooRexx uses by default java.lang.invoke starting with Java 8 as Java 7, where this package got
>> introduced, has some missing support in that area).]
>>
>> In general a good overview of the support dates for different versions of Java by different
>> distributors can be found here: <https://en.wikipedia.org/wiki/Java_version_history>.
>>
>> ---rony
>>
>>
>>
>> _______________________________________________
>> Netrexx-develop mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netrexx-develop
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop

Re: [Netrexx-develop] RxJrt.nrx supporting --add-modules

[René J. <rvj...@xs...>]

Ah this list does not have a reply to list on the default. 

I mentioned to Marc that we can do a conditional compile for this. Java 8 does not support JPMS, so we probably just have that call fail; there is no point in even trying supporting that on Java 8.
Harder part here is that we need to make sure the class file version is compatible specially seen the bootstrapping and ant.  So we might need to do a Class.forName depending on the JVM/Class file version. This might be a strategy to support even older versions - most of NetRexx is Java 1.1 and 1.2 compatible. But it will be a headache for the build process. I am severely disgruntled by what Oracle is doing to Java: Java source code looks uglier than ever, and it became just like Visual Basic to keep up with all the ‘improvements’ in the infrastructure. Removing Applets etc is just vandalism, I have a math course in applets that works fine using appletviewer only that also vanished. And all those security bugs were mostly windows and some were self-inflicted by not thinking straight while implementing invokedynamic.

I see these people breaking everything one day by enforcing those method<type> calls and then we are further away from home. JRuby struggled more than we for Java 9 support, that came about only last week or so. And look at WebSphere. It might be a strategy.

René.




> On 27 Jan 2022, at 14:53, Rony G. Flatscher <Ron...@wu...> wrote:
> 
> On 27.01.2022 13:53, Marc Remes wrote:
>> And a side note..
>> You need java 9 or above to compile and run this.
>> 
>> Which brings up another topic : are we ready to stop supporting java 8?
> 
> Please no, unless you want to remove most of the Java installed base for NetRexx.
> :)
> 
> Seriously, NetRexx should support Java 8 as long as Java 8 gets supported by OpenJDK distributors.
> E.g. Oracle and Azul support Java 8 until December 2030, for very good reasons! Actually Java 8 gets
> currently a longer support than Java 11 LTS and Java 17 LTS, believe it or not.
> 
> [BSF4ooRexx still supports Java 6 as its baseline (that is the reason for "6" in "641", "41" means
> ooRexx baseline is version 4.1) as there are companies/organizations that have still Java 6
> deployed. This incurs quite some overhead and support efforts as in Java 6 one needs to use
> java.lang.reflect whereas starting with Java 9 one must use java.lang.invoke instead (actually
> BSF4ooRexx uses by default java.lang.invoke starting with Java 8 as Java 7, where this package got
> introduced, has some missing support in that area).]
> 
> In general a good overview of the support dates for different versions of Java by different
> distributors can be found here: <https://en.wikipedia.org/wiki/Java_version_history>.
> 
> ---rony
> 
> 
> 
> _______________________________________________
> Netrexx-develop mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netrexx-develop