Fork me on GitHub
#cursive
<
2020-05-25
>
jacklombard08:05:34

Is there a shortcut for convolute-sexp ?

cfleming09:05:03

No, there's no shortcut for it due to the simple fact that Cursive doesn't implement it :)

jacklombard12:05:03

It is trivial to search whether there is a shortcut for it. Thought it was understood that I was asking why Cursvie doesn't implement it? 馃檪

cfleming22:05:57

Mostly, because no-one has ever asked for it, and IIRC back in the day I couldn't find a good explanation of how it should actually work.

jacklombard06:05:23

Found this https://github.com/cursive-ide/cursive/issues/809 and http://clojure-log.n01se.net/date/2014-09-14.html but yeah if you think it doesn't demand much priority now, then alright. But it is a very useful shortcut which one can employ often once they understand what it does.

jacklombard06:05:15

Example, if I want to move the let outside the testing while keeping the internal block the same, I can invoke convolute-sexp from the caret position:

(testing "I am a test"
  (let [some-var 10]<caret>
    (is (= some-var 10))))

jacklombard06:05:23

(let [some-var 10]
  (testing "I am a test"
    (is (= some-var 10))))

馃く 4
imre15:05:34

I just came across a situation where this could be useful

Walt Stoneburner18:05:13

Every once in a while, I get an Event Log message that looks like this: "Error running 'REPL for projectname': Deferred parameters have not been cached!" ( I don't remember it ever doing that. ) It seems to happen when I restart the REPL (sometimes). Any idea what it's complaining about or what I do to fix it?

cfleming22:05:29

Which version of Cursive are you using?

Walt Stoneburner23:05:59

Looks like v1.9.2-eap4-2020.1

cfleming23:05:14

Hmm, so that's definitely a bug, but I'm not sure what could cause that to happen sporadically. I fixed a bug relating to this a while back, but that one always happened on every run. If you manage to narrow down when this happens that would be helpful in tracking it down.

Walt Stoneburner23:05:09

From what I can tell, if my code is running and I do a restart REPL (because I changed some source), I get the message. But, if I have stopped my code and then "restart", there's no error. For a little more context, the application is a Ring server application -- so it's very likely that there are background threads, defers, and unresolved promises hanging about. Any idea what the error message means or where it might be coming from?

cfleming23:05:02

It comes from Cursive, and the short answer is: it's complicated :)

馃憤 4
cfleming23:05:41

IntelliJ normally runs run configs on the swing EDT, which means that if running the config takes a long time, the UI will lock up.

cfleming23:05:31

Lein in particular can take a very long time to calculate the classpath if you're using snapshot repos, so I have to do a black magic song and dance behind the scenes to ensure that doesn't happen on the EDT so the UI remains responsive.

Walt Stoneburner23:05:44

I did just note that it wanted exception report #4170 sent to Cursive... java.lang.AssertionError: Assert failed: port at nrepl.core$connect.invokeStatic(core.clj:168) at nrepl.core$connect.doInvoke(core.clj:168) at clojure.lang.RestFn.invoke(RestFn.java:457) at cursive.repl.nrepl$start$fn__12069.invoke(nrepl.clj:121) at cursive.repl.nrepl$start.invokeStatic(nrepl.clj:120) at cursive.repl.nrepl$start.invoke(nrepl.clj:116) at cursive.repl.process_runner$run_nrepl_server$fn__15263.invoke(process_runner.clj:155) at cursive.repl$start.invokeStatic(repl.clj:55) at cursive.repl$start.invoke(repl.clj:51) at cursive.repl.toolwindow$create_new_repl$fn__12021.invoke(toolwindow.clj:753) at cursive.repl$submit$reify__4203.run(repl.clj:176) at com.intellij.util.RunnableCallable.call(RunnableCallable.java:20) at com.intellij.util.RunnableCallable.call(RunnableCallable.java:11) at com.intellij.openapi.application.impl.ApplicationImpl$1.call(ApplicationImpl.java:255) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)

cfleming23:05:55

That error message basically means that that step didn't work properly.

cfleming23:05:25

What sort of project (deps, lein etc) is this?

Walt Stoneburner23:05:16

It was started as a fairly bland Lein project, actually.

cfleming23:05:29

BTW you don't generally have to restart your REPL when you change sources either, you should just be able to load the new sources live into the REPL.

cfleming23:05:16

What sort of REPL config are you using? That exception usually happens with remote REPLs.

cfleming23:05:44

I have to step away for a bit, sorry - I'll be back in an hour or so if you're still around.

Walt Stoneburner23:05:37

This is where you're starting to dance on the edge of my knowledge, so pardon me if none of this is helpful. I just basically followed the how to install Cursive directions off the web page, right click the project.clj file and slect Run 'REPLY for project'. At that point I have a REPL window in IntelliJ. I'm running everything locally at my workstation, and the REPL tab is prefixed with "Local:" .... any of that useful?

cfleming23:05:04

Yes, thanks, I'll try to reproduce based off that info.

Walt Stoneburner23:05:08

( I will be, suspect I may be afk during dinner or so... but I'll leave this open. )

imre09:05:23

For the record, I also encountered this on repl restart sporadically on deps projects.

imre09:05:00

Looks like I can reproduce it

cfleming11:05:44

Is that just using the restart button?

cfleming11:05:33

BTW imre, you're talking about the Deferred parameters error or the Assert failed: port one? Or do you get both messages?

imre11:05:03

Sorry, I did not notice there were 2 errors discussed. It is the deferred parameters error, whenever I try to restart a repl using the restart button.

imre11:05:17

It isn't something I use too often, but sometimes it comes in handy when I feel my running app is too polluted for further work. I quickly got used to stopping and starting it after the first few times I saw the problem.

Walt Stoneburner14:05:54

@U0567Q30W -- this was just the restart (but I can't say that I've done a lot of exploratory work beyond that; happy to conduct experiments). @U08BJGV6E -- did you reproduce it the same way? I didn't know if the Assert failed: port was related or not, but I see that every so often; have not figured out what triggers it. Usually there's just a small red exclamation mark from IntelliJ that I happen to notice much later, so it's hard to correlate what action is causing this.

imre14:05:39

I reprod by starting a repl, waiting for it to initialise, then hitting the restart button

馃憤 4
cfleming22:05:51

I just tried to reproduce this and I can't. I created a new deps project, ran the repl, then used the restart button, and it all worked. Does this happen consistently for you both on all projects?

imre07:05:38

I'll check that later today

imre12:05:02

@U0567Q30W in my case it looks like this is something to do with 'Run with deps' and an alias. See the attached file, it's a pretty much empty deps.edn. When I run the repl with deps, I cannot restart it. If I run it with the intellij classpath, I can. As I was playing with it, changing deps etc, sometimes, after running with the IJ classpath, the issue went away even for the deps repl, but it came back when I changed my deps

cfleming22:05:54

Thanks imre, I'll try to repro with that.