Fix arity error in :std/net/repl

[nafarlee]

Closes #1303

[netlify]

👷 Deploy request for elastic-ritchie-8f47f9 pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	42ee48d

[vyzo]

thank you!

[vyzo]

seems CI is having one of these days...

[vyzo]

I think we need a timeout in the test.

[nafarlee]

I think we need a timeout in the test.

Looking at the 6ish hours of hanging they did, I think you might be right 😅

According to the logs, the test never left setup, which I assume corresponds to test-setup!. Is the request to change it to something like...

(thread-join! (start-repl-server!) 10)

...just to ensure it would crash rather than hang for so long, or are you gesturing to something "corrective" we can do with a timeout (I don't know, like a retry or something)?

Apologies for what might be a basic question.

[vyzo]

oh it needs to run in a separate thread.
Try (thread-join! (spawn start-repl-server! ...))

I will cancel the workflows in the meantime.

Edit: see comment below, just spawn it.
Or does start-repl-server already spawn? I dont remember, check the code.

[vyzo]

ah they already failed.

Speaking of which we should add a timeout to gxtest, care for a pr?

[vyzo]

Ah dont join i setip, it will hang.

Instead spawn the thread, keep a ref and stop it at clran up.

[vyzo]

Ah dont join i setup, it will hang.

Instead spawn the thread, keep a ref and stop it at clean up.

[nafarlee]

I thought start-repl-server! already spawned a thread internally, so it wasn't necessary to spawn the call to start-repl-server! itself?

[vyzo]

yes yes, it does

[nafarlee]

Ah dont join i setup, it will hang.

Instead spawn the thread, keep a ref and stop it at clean up.

Given that start-repl-server! spawns internally, I thought this was functionally what the test was doing already, but I could be mistaken.

I still haven't been able to build master, but this test runs successfully on v0.18.1 locally. Either:

• Something changed since v0.18.1 to cause this to hang
• My local environment is somehow invalid

Given my build issues, I am assuming the latter. Tomorrow, I will try to build my changes on top of master in the Docker image to see if I can get a more authentic testing environment.

[vyzo]

Yes, but you cant block in test-setup. Joining the thread blocks.

[nafarlee]

Okay, I think I figured out the issue. For the short story, you can probably just look at the diff... 42ee48d

For the full explanation, I was finally able to get access to a master + my patch build of gerbil thanks to the docker build instructions. For some reason when I was testing my local build of [email protected], a final return was not necessary for the network REPL session to start executing a command. On the docker build of master, the return was indeed necessary.

The 6 hours of hanging was not due to a threading issue per se, but because read-line was waiting for a newline on the port that would never come: all that was in there was > because no command had executed.

If you want, I could add a timeout to this test to prevent read-line from hanging indefinitely in the future...but as you indicated in an earlier comment, I do personally think "test timeout" functionality is better integrated into gxtest itself.

[vyzo]

yrs, agreed, the proper solution is to add a --timeout option to gxtest.

[vyzo]

thank you!