unrepl

discussing specification of an edn-based repl and its implementations.
Andrea 2019-06-06T10:06:50.001800Z

Is there a way to upgrade a running socket server twice with an unrepl blob? I upgrade once, then close the connection then connect and upgrade again (with a changed blob). It seems like the second upgrade doesn’t have an effect and I always have to restart the process.

cgrand 2019-06-06T10:13:39.004400Z

Is your blob shaded? From what I can tell here is the scenario that bugs you: you send a first blob which creates impl namespaces for unrepl. Then you tweak the blob and resend it (over a fresh conn). However in the blob there’s code to prevent recreating an existing ns, so most of the new blob is ognored because the ns diddn’t change.

cgrand 2019-06-06T10:14:23.005300Z

It’s intended behaviour to avoid concurrent connections with the same blob to interefer with each other.

cgrand 2019-06-06T10:14:42.005800Z

To allow concurrent connections with different blobs, blobs must be shaded.

cgrand 2019-06-06T10:14:58.006200Z

(thus yielding unique namespaces)

cgrand 2019-06-06T10:15:51.007Z

@andrea712 Could this ^^ explain the behavior you encounter?

Andrea 2019-06-06T10:17:38.007800Z

> in the blob there’s code to prevent recreating an existing ns, if this happens yes.

Andrea 2019-06-06T10:18:56.009300Z

and that behaviour would happen also using un-shaded blobs right? I’m mostly using unshaded ones when debugging so I can re-eval functions in unrepl nsspaces

Andrea 2019-06-06T10:25:15.012300Z

my trouble is currently when the first upgrade fails after emitting the :unrepl/hello but before emitting the first prompt. In that case all unrepl (unshaded) nss are evaluated correctly and all successive connection+upgrade with a changed blob has no effect

cgrand 2019-06-06T10:28:21.013800Z

if -init-done is already set to a promise (well a derefable) then eval becomes a no-op for the whole processing of the blob

cgrand 2019-06-06T10:28:53.014500Z

so redefining -init-done to nil before resending the blob should be ok

cgrand 2019-06-06T10:29:34.015100Z

The above code also guards against race conditions between concurennt upgrades

Andrea 2019-06-06T10:36:31.016300Z

ok nice I suspected it was that template header but couldnt figure out what to remove 🙂

Andrea 2019-06-06T10:37:43.017Z

so something like (set! 'unrepl.repl/-init-done nil) ?

cgrand 2019-06-06T10:51:46.017400Z

nope, not dynamically bound

cgrand 2019-06-06T10:52:39.018200Z

(alter-var-root! #'unrepl.repl/-init-done some?)

cgrand 2019-06-06T10:52:49.018500Z

(untested, report failure)

Andrea 2019-06-06T11:00:49.019500Z

Nice, that works (without the ! …), thank you very much.