Watch file system for changes to .nrepl-port

[mhansen]

Currently, we try to updateConnectionParams() by reading the .nrepl-port file during extension activation (when a clojure file is first opened), then we try to auto-connect.

This fails when you open the clojure file first, then the repl after extension activation.

Perhaps we can setup a file watcher, and automatically connect to the repl if a .nrepl-port file becomes available?

This isn't a fully fleshed-out idea: we'll need to think a bit about how to handle a change the .nrepl-port file when we're already connected to a nrepl. Do we connect to the new one? Or keep the existing one - which may be closed, and maybe we haven't noticed it's gone? I'd propose taking the less-destructive route of staying with the existing REPL.

What do you think?

[avli]

That's actually a good suggestion. Any ideas how to implement the watcher properly?

[fasfsfgs]

Good idea indeed.

I wouldn't worry too much about previous nrepl connections since it is merely the information about the nrepl's server location. It is not something leaky like an actual open connection or anything like that.

[fasfsfgs]

With #21, we start our own nrepl when the extension is activated.

But we still let the user connect to a custom running nrepl.

What could we do better here?
One thing that would be great is to at least watch for this .nrepl-port file and disconnect if it gets deleted (if the user chose to connect to that nrepl).

About changes to this file, what do you think @avli and @mhansen?

[mhansen]

It's a little confusing to label it a connection if there is no e.g. TCP connection (I assumed there was a connection). I think disconnecting on .nrepl-port deletion would be an interesting optimisation, but probably wouldn't work for all cases (can the REPL disappear without deleting the file, or vice versa?). Keeping a persistent TCP connection, and disconnecting when that's reset, seems like it'd cover more cases to me.

…

On Sun, 23 Jul 2017 at 11:54 Thiago Almeida ***@***.***> wrote: With #21 <#21>, we start our own nrepl when the extension is activated. But we still let the user connect to a custom running nrepl. What could we do better here? One thing that would be great is to at least watch for this .nrepl-port file and disconnect if it gets deleted (if the user chose to connect to that nrepl). About changes to this file, what do you think @avli <https://github.com/avli> and @mhansen <https://github.com/mhansen>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGcOVKYwlH419JhX83tz_GuI0xgfjlSks5sQqfZgaJpZM4OR-CX> .

[fasfsfgs]

Yup. I completely agree the idea of connection is nonexistent here.
Any idea how to do that persistent TCP connection like in our case?

[mhansen]

Heh - I know next to nothing about the nrepl protocol, but assuming that it's TCP, you could potentially keep the connection open at the end. If it's HTTP, there's well-established ways to make persistent HTTP connections (reuse the same http client is the usual way). Sorry if this speculation is unhelpful :-)

…

On Sun, 23 Jul 2017 at 12:48 Thiago Almeida ***@***.***> wrote: Yup. I completely agree the idea of connection is nonexistent here. Any idea how to do that persistent TCP connection like in our case? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#37 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGcOaWCFQQ-ltm86gSgJmboLoHJyIFVks5sQrR-gaJpZM4OR-CX> .

[fasfsfgs]

haha no worries. Your ideas and feedback are great imo. =)
I might have an idea to test about leaving a listener on a nrepl command we send and watch for anything to signals a "drop" of our connection.