New REPL: make better use of retries

[daveyarwood]

Playing around with the new client-side REPL in development, I'm getting the "No workers are available at the moment, please wait" message a lot when I enter small lines (e.g. one note) in rapid succession.

I think this is acceptable for command-line usage, but the REPL is a more immersive experience and it feels better to hand control over to the REPL process a bit more. Personally, I think I would prefer if the REPL blocked and retried until a worker became available, instead of just printing an error and making me wait and then manually re-submit that line to be played.

There should always be a timeout, but I think we can be more generous here -- maybe something like 5 or 10 seconds.

---

Another issue is that I sometimes see the "server down, please run alda up" message even if the server is up, and I even hear playback happen shortly after getting the message. I think this is another case where it makes sense to have a longer timeout period for a more immersive REPL experience.

Basically, if you're using the REPL, we want to avoid having you see timeout messages if we can help it.

[daveyarwood]

Improved in 0.1.3.

I'm seeing general problems with slow response times from the server/workers, which I think is an architectural problem. I've been reading the zguide more lately, and I have some ideas about how to improve the overall situation with the Alda server and workers. I think the problem is that there is a level of indirection between the client and the worker, but the way we have things set up, the client needs to talk to the worker to determine the status of its request. I'm going to explore moving to an architecture where the server tracks the status of every request, and workers are stateless.

[daveyarwood]

Another issue is that "parse" requests are synchronous and cause workers to become blocked.

alda-lang/alda-server-clj#2 will fix that.