cursive 2019-05-14 | Slack Archive

Kari Marttila08:05:37

@cfleming - Great! I believe you let us know here when you have updated the documentation - I'm definitely going to read it again from begin to end! I learned so many new Clojure coding productivity boosters yesterday. And you have good style of writing documentation, it's very fluent and also good light humor showing between lines. 🙂

cfleming08:05:05

@kari.marttila Thanks! That’s encouraging to hear. It’s always a slog updating documentation and I often wonder if the ROI is very great, but of course I don’t often hear from the people who struggle because it’s out of date or incomplete (or people that it helps a lot).

Kari Marttila09:05:15

@cfleming The documentation style is really good. The text is clear and informal and especially those short video clips showing e.g. how to do structural editing are great. I remember that when starting to use Cursive I watched those clips especially regarding barfing and slurping and immediately assigned good hot keys for them. I have configured in my Linux workstation a keymap in which "Caps lock" is "Alt Gr", and "Alt Gr" (i.e. Caps Lock) + j,k,l,i are arrow keys, So I have in my finger muscular memory already those keys. I just assigned certain AltGr/shift/ctrl/alt + i/j/k/l/i combinations for barfing and slurping and using barfing and slurping that way in Cursive has been really fast (I don't have to move my fingers from the standard positions in keyboard (using 10 finger style) when barfing/slurping - and those hot keys are in my finger muscular memory so that I don't even think about how to do them - it comes just naturally as part of writing code).

conan08:05:30

I second this, I've learned loads from the cursive documentation, and not just about cursive. It's much appreciated!

cfleming08:05:49

Thanks @U053032QC!

Kari Marttila09:05:17

The only downside with IntelliJ idea is that for some reason it doesn't "honor" the Linux keymaps (I have found this in a short selection of editors - most editors honor it). But luckily I could just "recreate" the same hot keys in the IntelliJ Keymap so, my look-and-feel of editing using IntelliJ IDEA is the same as e.g. in Emacs.

vinai13:05:09

@cfleming Regarding your comment on the REPL stdin input popup box https://github.com/cursive-ide/cursive/issues/835#issuecomment-488126046 > The issue with the standard input popup is caused by using an nREPL type REPL with something that's expecting a clojure.main style one. If you create your REPL as a clojure.main one, this should work. I'm wondering, how can I start the REPL as a clojure.main one in cursive?

flowthing13:05:22

I actually happened to bump into the exact same problem just now. It's quite bizarre.

vinai13:05:46

Oh, I just noticed I can select clojure.main in the run config dialoge when configuring the repl. Trying it now.

vinai14:05:46

Hm, no luck. Any info on starting a cljs browser repl would be cool.

vinai15:05:13

I can start a local REPL and switch to cljs using the clojure.main setting.

flowthing07:05:43

In my case, the issue was that I was using a version of Figwheel (and Figwheel Sidecar) that only supported cemerick/piggieback, but my project depended on the newer cider/piggieback. Updating lein-figwheel and figwheel-sidecar to 0.5.18 fixed the issue.

flowthing07:05:44

I'm now getting clojure.lang.ExceptionInfo: my.awesome.ns does not exist {:cljs.repl/error :invalid-ns} when I try loading a namespace into the CLJS REPL, though.

vinai15:05:40

I've moved a project to a new mac. Fresh IntelliJ and Cursive installation. When I configure a local nREPL with leiningen I get

Starting nREPL server...
/Applications/GraalVM-19.0.0/Contents/Home/bin/java... [...]
2019-05-14 17:24:55.633:INFO::main: Logging initialized @41817ms
No nREPL ack received

Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

vinai15:05:52

REPL configuration

vinai15:05:23

The same settings work on the previous mac... Any idea what I might be missing?

flowthing15:05:52

What happens if you run lein repl?

vinai16:05:56

That works fine

vinai16:05:23

I can run the repl using the clojure.main setting btw. However, I miss the test integration.

flowthing16:05:40

I think I’ve gotten that same error when the project depended on an older nREPL version. Could try updating it, and possibly the piggieback dependency as well.

cfleming04:05:29

@U3WJG25EV The way that this works is that Cursive will listen on its own nREPL port, then start the nREPL server in a new process. That will start to listen on an arbitrary port, then ping the Cursive nREPL process to tell it which port the new server is listening on, and that it has started. That message means that that ping back was not received within the specified timeout.

cfleming04:05:10

That can mean one of various things: the process didn’t start correctly or took a long time to start, nREPL didn’t initialise correctly, the nREPL process can’t open a network socket to the Cursive process, etc etc.

cfleming04:05:43

It’s hard to know unfortunately. One thing is that I see you’re using graalvm which is unusual - if you use a standard JDK does that work?

vinai07:05:32

Thanks for your reply, @cfleming! Interesting to hear the way it works. This is a new machine I'm setting up, and since there will be a bit of native binary building in the near future I thought I'd go ahead and just install GraalVM as the default. I'll try OpenJDK instead now.

vinai07:05:31

@U4ZDX466T Thanks for your reply, too. I'm on the latest versions of nrepl and piggieback already, so nothing I can do there.

vinai08:05:44

@cfleming No luck. Basically the same with an additional warning.

Starting nREPL server...
/Library/Java/JavaVirtualMachines/jdk-12.0.1.jdk/Contents/Home/bin/java ...
2019-05-15 10:17:12.853:INFO::main: Logging initialized @41167ms
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.bouncycastle.jcajce.provider.drbg.DRBG (file:/Users/vinai/.m2/repository/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar) to constructor sun.security.provider.Sun()
WARNING: Please consider reporting this to the maintainers of org.bouncycastle.jcajce.provider.drbg.DRBG
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
No nREPL ack received

Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

vinai08:05:18

The same warning occurs when I start a clojure.main repl, which works (just like when using GraalVM)

flowthing08:05:58

Yeah, that's related to Java 12. You wouldn't see that with Java 8, I think.

flowthing08:05:11

It's unrelated, though, I believe.

vinai08:05:16

Think so, too.

flowthing08:05:06

You could work around the issue by running lein repl :headless on the command line and then connecting to it from Cursive with a remote REPL (https://cursive-ide.com/userguide/repl.html#remote-repls).

vinai08:05:51

Oh, interesting idea! Thanks, I'll try that.

flowthing08:05:21

Short of trying OpenJDK 8 and trying enabling/disabling dependencies one by one, I can't think of what else to try.

flowthing08:05:03

Could try generating a new, minimal Leiningen project with lein new app foo and see whether the same thing happens there, too.

vinai08:05:40

It would be interesting to figure out why the other nRepl started by Cursive doesn't ping back. Especially since the same project with identical dependencies on my old machine worked with a lein repl.

cfleming21:05:18

I wonder if that error might be related. Which JDK were you using on your previous machine?

vinai10:05:21

I was using openjdk 1.8.0

cfleming10:05:50

It would probably be worth testing with that on your new machine too.

vinai14:05:40

Will do!

manutter5115:05:09

There’s a setting in preferences for how long the timeout is, maybe it got set to an unreasonably low value somehow?

vinai16:05:04

I don't think that is the problem... The repl starts faster than the timeout.

2019-05-14

Channels