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.

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.

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

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

(thus yielding unique namespaces)

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

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

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

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

https://github.com/Unrepl/unrepl/blob/master/src/unrepl/blob-template.clj#L5-L14

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

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

The above code also guards against race conditions between concurennt upgrades

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

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

nope, not dynamically bound

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

(untested, report failure)

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