> I have a strange situation with my work project (Leiningen + lein-figwheel), with four different behaviours on four different machines. Let’s call them A, B, C and D .
@pez Did you manage to sort this out? The problems you described didn’t seem nREPL related to me, more like something to do with Lein.
> Hello, I am going to appear on a Clojure podcast soon, to talk about Calva. In pondering what the heck to say, I started to think about how nice it would be to be able to use Calva together with Lumo. From what I understand, a big hurdle there is the lack of an nrepl server. But I have also heard rumours about an nrepl server being possible on top of the socket server. Is that so? What can you share about the prospects of using an nrepl client with self hosted ClojureScript?
Adding to what was already said here - I think that implementing an nREPL server in ClojureScript won’t be hard, provided someone decides to tackle it. But the real difficulty would be the broader ecosystem of middleware - most of them rely on Java in one way or another and porting a lot of middleware is obviously a lot of work.
That’s why we avoided in general the route of the self-hosted nREPL for ClojureScript and tried to do as much as possible with the boostrapped version - this simplified a lot the work needed to provide “some” ClojureScript support.
In the end of the day it’s always fairly simply to provide some basic eval functionality, but the more complex the features get, the harder it is to avoid using some host features.
> However, I also do not know what unrepl support for self hosted cljs would mean for Calva.
Re: my timeout problems. I thought it might be nrepl related a while because had different results with some different dependencies injected, but that was a smoke screen it seems. It is probably something to do with some libraries we use. We'll figure it out, hopefully.
I assume it would mean nothing, as you’d have to implement a different API if you want to support unrepl/prepl.
I spent some time researching the possibility for supporting different REPL providers in CIDER in the past, but in the end it seemed like too much work for very little gain.
Calva is pretty bare bones. So probably not a lot of middleware involved.
You basically need to provide an abstraction layer over nrepl/unrepl/prepl and have to reconcile the differences between them in that layer.
If you’re mostly using eval I guess you can get away with an nREPL implementation that simply doesn’t support middleware at all and just provides the ops you need for Calva.
I know that’s what Arcadia’s team did to build a working nREPL server for ClojureCLR. Their implementation was something like one file and would be a good starting point for ClojureScript support as well.
Cool. I'll have a look at that. Arcadia is another environment I'd like Calva to be useful with anyway.
For Arcadia it’s simpler in general - I think the piggieback approach (just provide eval support via middleware) would work for them.
Here’s actually an implementation of that https://github.com/spacepluk/arcadia.nrepl/blob/master/src/arcadia/nrepl.clj
> This is an nREPL bridge for Arcadia Unity. It spins up a standard nREPL server and it redirects eval operations to the Arcadia UDP REPL. This will allow to use existing tooling and editor integrations without the need to port nREPL and other middlewares/libraries to ClojureCLR.
That’s the beauty of nREPL modular architecture in action. 🙂
You are making me cry here. 😃
Yep, exactly.
@pez I didn’t want to ruin your day. 😉
Haha, I just have a soft spot for beauty.
😄 😄 😄