4.05 beta: new built-in random stage clashes with pipelines version

[rvjansen]

Jeff Hennick: We do have a real Pipelines problem. There is a name conflict between the new BIF RANDOM and the existing stage with that name. The error shows up in random_tests1.njp and a few other stage tests that use a RANDOM stage, too. PS C:\Users\Jeff\nr405\examples\pipes> type t.njp pipe (t) random | take 3 | cons PS C:\Users\Jeff\nr405\examples\pipes> p t

C:\Users\Jeff\nr405\examples\pipes>pipc t pipe (t ) random | take 3 | cons 56 +++ _s_1 = random() +++ ^^^^^^ +++ Error: Cannot convert value of type 'netrexx.lang.Rexx' for assignment to variable of type 'org.netrexx.njpipes.pipes.stage'

[remesm]

I don't think this is solvable. Either the new RANDOM BIF or the existing random pipeline stage needs to be renamed. My vote is to rename the latter, in favour of Classic Rexx compatibility. Marc

[rvjansen]

I agree in general. I would like to play a bit with separating jars so we can have them in another sequence for the pipc and pipe commands - we have those under control now thanks to your action. Unfortunately the pipes people (Hartmann, vande r Hey etc) have coopted more rexx commands without offering a decent namespace mechanism.

[remesm]

Can we rename the stage to 'rand'?

[rvjansen]

We can, but I wonder if that is fair. NetRexx never had random, so it is not missed. Up to now everybody used math.Random and that is properly protected by a namespace. On the other hand, RANDOM is the official pipe program name, was there probably since 1996 and it is used in 4 examples. Because I am trying to solve the TCP pipeline issues, and that sample uses a RANDOM stage, the NetRexx BIF is temporarily out.

[remesm]

Fair enough, first come, first served. Are you going to remove random() from RexxRexx.nrx? The documentation does not need to be updated, as random() is not yet documented ;

[rvjansen]

I committed a fix for the tcpexample.njp case and commented out the random() bif for the moment. The tcpexample runs most of the time; it is still not 100% bulletproof. I tested on macOS and Linux, it would be great if someone could test on windows. The debugging was interesting, involving lots of 'um mani padre hum' chanting and positive thinking; I don't know a lot about TCP sockets but tried a lot of minimal cases with netcat and tried to move forward from those. It might be that some TCP parameters or reintroduction of the deblocking might make it more stable; it seems to stall while starting up sometimes.

[remesm]

On tcpexample (off topic).. It still does not work for me. Actually, when starting 'java tcpreq' without first starting tcpserv, I have thread exceptions:

$ java tcpreq java.lang.NullPointerException: Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null at org.netrexx.njpipes.stages.tcpclient.run(tcpclient.java:388) at org.netrexx.njpipes.pipes.ThreadPool.run(ThreadPool.java:76) at java.base/java.lang.Thread.run(Thread.java:1623) Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#21,Thread-1,5,njPipes] Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#21,Thread-1,5,njPipes] Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes]

[rvjansen]

That is to be expected … but could be handled more elegantly I guess. You tested on windows? For me it runs on macOS and Linux (both aarch64 and X86_64.René.On 26 Apr 2023, at 16:33, remesm @.***> wrote: On tcpexample (off topic).. It still does not work for me. Actually, when starting 'java tcpreq' without first starting tcpserv, I have thread exceptions: $ java tcpreq java.lang.NullPointerException: Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null at org.netrexx.njpipes.stages.tcpclient.run(tcpclient.java:388) at org.netrexx.njpipes.pipes.ThreadPool.run(ThreadPool.java:76) at java.base/java.lang.Thread.run(Thread.java:1623) Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#21,Thread-1,5,njPipes] Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#21,Thread-1,5,njPipes] Exiting due to uncaught Exception Cannot invoke "java.lang.Thread.join()" because "this.et.T" is null ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#21,Thread-1,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#22,Thread-2,5,njPipes] ThreadQ Thread[#25,Thread-5,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes] ThreadQ Thread[#24,Thread-4,5,njPipes]

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were assigned.Message ID: @.***>

[remesm]

It sort of works, when starting tcpserv and then tcpreq, tcpsrv shows $ java tcpserv Socket[addr=/127.0.0.1,port=55500,localport=1958]

$ java tcpreq prints out random numbers, until ctrl-c.

[remesm]

FWIW Fedora 38, openjdk 20

[rvjansen]

closing this because original random() clash is solved for the moment. Will keep working on tcp pipelines issues.