cider-load-file broken

[abo-abo]

Results in:

error in process filter: user-error: No clj REPLs found.  Have you linked a session?

[bbatsov]

Are you using this in a different project? Not the one in which you jacked-in initially perhaps?

The message is very confusing and we have to improve it, but basically this happens when there's no session linked to the project you're currently visiting. Before 0.18 we didn't check the project in any of the eval commands and they'd just get dispatched to whatever was considered the current REPL, but this behaviour is now stricter (so people won't end up evaluating code in the wrong REPL).

//cc @vspinu

[abo-abo]

Are you using this in a different project? Not the one in which you jacked-in initially perhaps?

No, using it from a jacked-in project. Simply removing the checks makes it work:

(defun lispy-cider-load-file (filename)
  (let ((ns-form  (cider-ns-form)))
    (cider-map-repls :auto
      (lambda (connection)
        (when ns-form
          (cider-repl--cache-ns-form ns-form connection))
        (cider-request:load-file (cider--file-string filename)
                                 (funcall cider-to-nrepl-filename-function
                                          (cider--server-filename filename))
                                 (file-name-nondirectory filename)
                                 connection)))))

[vspinu]

Looks like it's either an older version of CIDER where sesman wasn't correctly matching current directory to the project path, or it's a variant of #2351 where VC sub-directories interfere with the clojure projects.

[abo-abo]

I'd like to call for some robustness here. There's no reason why I should get "no session associated" message when in 100% of my use cases I only have a single CIDER session.

I understand that it's useful to accommodate workflows with multiple sessions. But it should not be done at the expense of edge cases where the simple case of a single REPL stops working.

[bbatsov]

Yeah, certainly. Single connection sessions should be rock-solid. We're working on this. Likely @vspinu is right about the reason. We really need to improve the messages and to show somewhere in the con info/repls their session, so it's clearer where the problems are coming from.

[vspinu]

I intentionally left the configuration of how associations work in single-session workflow for later. I think we first have to be crystal clear about the semantics of session management in multi-session context and then add a custom variable which would allow a lax session matching.

But I am not convinced about the "robustness" argument though. I am incline to think that the lax option should be off by default. It's too easy to overlook that you no-longer have 2 sessions running and send wrong stuff, kill or interrupt the (now) only REPL.

This might not feel like a big deal for clojure users, but in my other use case regarding analytics in R, when I have some sessions running for hours I really don't want to send anything wrong or kill the last session by mistake.

[bbatsov]

But I am not convinced about the "robustness" argument though. I am incline to think that the lax option should be off by default. It's too easy to overlook that you no-longer have 2 sessions running and send wrong stuff, kill or interrupt the (now) only REPL.

I was referring mostly to improving the messaging we use. Frankly, this was super confusing even to me in the beginning. I agree that by default we should be strict with the project -> session mapping. If we do something special for a single session it should disabled by default for the sake of consistency. I've never actually wanted to load code from one project into the REPL of another project, so I'm not even certain if that's worth doing. I don't think @abo-abo was referring to this at all.

[abo-abo]

Frankly, this was super confusing even to me in the beginning.

What's going on right now is super confusing to me. I want CIDER to be able to operate as a "dumb REPL", just like what you get when you start clojure or lein repl in a terminal:

• It should not know anything about the file structure:
  
  
  
  1. The REPL should not care which buffer I'm in when I send it a snippet.
  
  
  2. The REPL should not do any magic to detect or change the namespace: just use the built-in way of tracking the namespace.
  
  

Basically, an eval to a REPL is a synchronous function which takes a string and returns the result, the output and the error message as strings. This is the minimum functionality that I need from CIDER. And unfortunately it gets broken time and time again in order to implement/refine more advanced features. I'm not saying we should refrain from implementing these new features, but please don't break the base REPL functionality.

The base REPL functionality is needed for instance to implement ob-clojure's and lispy's notebook session functionality. Those programs don't have a clear notion of a project or the one-namespace-per-file restriction. So they really need the dumb REPL functionality in order to work.

[vspinu]

It should not know anything about the file structure:

The repl does not use any assumptions. Interaction from the other buffer does. From your message it's not entirely clear what you are complaining about. If you have a constructive complaint please open an issue and we will try to fix asap.

[vspinu]

I don't think @abo-abo was referring to this at all.

I think he does. AFAICU @abo-abo wants sending evals from any buffer whatsoever without project checks. Is this correct?

[bbatsov]

That's the point about ob-clojure and notebooks in general - there you don't have a project per-se from what I gather. You just have some org file with some embedded Clojure code here and there. I'm not even sure how exactly do they start the REPL for such projects, though. If we knew more details about this popular use-case scenario, we could support it better. I often get complaints from org-mode users, but I simply don't have time to get familiar with it as well, so the support for this has been sketchy at best.

Basically, an eval to a REPL is a synchronous function which takes a string and returns the result, the output and the error message as strings.

Depending on what are you using under the hood. CIDER supports both sync and async evaluation. :-)

And unfortunately it gets broken time and time again in order to implement/refine more advanced features. I'm not saying we should refrain from implementing these new features, but please don't break the base REPL functionality.

I don't recall us making changes to the core connection management for quite a while now. I understand your frustration, but keep in mind development builds are somewhat unstable by definition. That's where we experiment with new stuff/features and polish them. The stable (tagged) releases are usually pretty stable.

[abo-abo]

I understand your frustration, but keep in mind development builds are somewhat unstable by definition. That's where we experiment with new stuff/features and polish them. The stable (tagged) releases are usually pretty stable.

These builds are used on MELPA and thus by a considerable part of the user base. So you break their workflow when you experiment, see e.g. https://github.com/abo-abo/lispy/issues/439. In my repos, I always try to keep master in a workable state. If I'm really experimenting with something, I just publish it to a dev branch and test it for a while before putting it on master. Since MELPA exists and is widely used, every commit to master is similar to a release.

[bbatsov]

And we try the same, but sweeping changes are hard to get right without getting enough people to test them. The new connection management works for most use-cases and solves many long-standing issues, but we need the help of our users to hash out other problems (like the ones outlined by you).

Anyways, we'll come up with some solution for your problem. Can you describe for us your ob-clojure workflow?

[vspinu]

I think @abo-abo's concern is a valid one.

In a nutshell if you call (cider-load-file "/tmp/tmp.clj") from some project ~/project) should we consider the current context being "/tmp/" or "~/project"? In the current implementation of cider-load-file it's the former and it's the reason for the error.

We should definitely make cider-load-file pick the context where it was called instead, just like any other interactive function does. In the unlikely case of someone wanting the current semantics, it is easily achieved with (let ((default-directory ... while @abo-abo's use case cannot be accommodated by binding the default-directory.