Fork me on GitHub
#unrepl
<
2019-06-06
>
Andrea10:06:50

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.

cgrand10:06:39

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.

cgrand10:06:23

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

cgrand10:06:42

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

cgrand10:06:58

(thus yielding unique namespaces)

cgrand10:06:51

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

Andrea10:06:38

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

Andrea10:06:56

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

Andrea10:06:15

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

cgrand10:06:21

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

cgrand10:06:53

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

cgrand10:06:34

The above code also guards against race conditions between concurennt upgrades

Andrea10:06:31

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

Andrea10:06:43

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

cgrand10:06:46

nope, not dynamically bound

cgrand10:06:39

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

cgrand10:06:49

(untested, report failure)

Andrea11:06:49

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