cursive-ide / cursive

Cursive: The IDE for beautiful Clojure code
579 stars 7 forks source link

REPL history only available after second expression. #2003

Closed d-t-w closed 4 years ago

d-t-w commented 6 years ago

Clojure 1.9, Java 1.8, Intellij 2.0.18.1.5, Cursive 1.7.0-2018.1

Apologies for the ridiculously minor bug ticket, but it's mildly annoying and presumably easy to address. Popped up a couple of Cursive releases ago I think.

  1. Open a new REPL
  2. Evaluate an SEXP
  3. Press 'UP' key, expecting to move to (2)
  4. No dice.
  5. Evaluate another SEXP
  6. Press 'UP' key, expecting to move to (5)
  7. Works a charm, and can progress back to (2), behaviour as expected.
Starting nREPL server...
/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/bin/java -Dfile.encoding=UTF-8 -XX:-OmitStackTraceInFastThrow -Dclojure.compile.path=/Users/derek/troy-west/projects/cronut/target/classes -Dcronut.version=0.1.2-SNAPSHOT -Dclojure.debug=false "-javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=54330:/Applications/IntelliJ IDEA.app/Contents/bin" -classpath /Users/derek/troy-west/projects/cronut/test:/Users/derek/troy-west/projects/cronut/src:/Users/derek/troy-west/projects/cronut/test-resources:/Users/derek/troy-west/projects/cronut/dev-resources:/Users/derek/troy-west/projects/cronut/resources:/Users/derek/troy-west/projects/cronut/target/classes:/Users/derek/.m2/repository/integrant/integrant/0.6.3/integrant-0.6.3.jar:/Users/derek/.m2/repository/com/mchange/mchange-commons-java/0.2.11/mchange-commons-java-0.2.11.jar:/Users/derek/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar:/Users/derek/.m2/repository/org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar:/Users/derek/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar:/Users/derek/.m2/repository/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar:/Users/derek/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar:/Users/derek/.m2/repository/com/stuartsierra/dependency/0.2.0/dependency-0.2.0.jar:/Users/derek/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar:/Users/derek/.m2/repository/org/clojure/tools.logging/0.4.1/tools.logging-0.4.1.jar:/Users/derek/.m2/repository/org/quartz-scheduler/quartz/2.3.0/quartz-2.3.0.jar:/Users/derek/.m2/repository/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar:/Users/derek/.m2/repository/com/mchange/c3p0/0.9.5.2/c3p0-0.9.5.2.jar:/Users/derek/.m2/repository/com/zaxxer/HikariCP-java6/2.3.13/HikariCP-java6-2.3.13.jar:/Users/derek/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar clojure.main -i /private/var/folders/gz/7g238rvd6j1c_jrqqc87_7_m0000gn/T/form-init6058804289662690570.clj
objc[11875]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/bin/java (0x1068d34c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10695f4e0). One of the two will be used. Which one is undefined.
Connecting to local nREPL server...
Clojure 1.9.0
nREPL server started on port 54332 on host 127.0.0.1 - nrepl://127.0.0.1:54332
(+ 1 1)
=> 2 ;; up key at this point has no effect
(+ 1 2)
=> 3 ;; up key at this point works as expected
d-t-w commented 6 years ago

Interestingly, I can only repeatedly reproduce this bug if I adjust the SEXP in step (2) to be one that definitely does not exist in the REPL history.

danielcompton commented 6 years ago

Also, I note that at step 6 I need to press the up key twice to get it to move back to show the previous REPL expression.

cursive-ide commented 6 years ago

I just tried this, and I can't reproduce it. Even with a completely new Leiningen project (so no history) this works as I would expect.

hjrnunes commented 6 years ago

Further to @d-t-w's comment, it seems that pressing "UP", etc, works fine if it's the first thing you do. e.g.

  1. Open a new REPL
  2. Press 'UP' key, expecting to move to last SEXP of previous REPL
  3. Works a charm

However, the issue is there if you then enter a new SEXP.

cursive-ide commented 6 years ago

Oh I see - so the problem is if you have an sexp in the REPL editor and then try to go up? I'll have another go at reproducing this tomorrow.

hjrnunes commented 6 years ago

Hmm, that's not what I meant.

I meant that it seems you have to actually enter a sexp in the editor for the problem to manifest itself.

As in, using 'up', etc to access previous REPL's sexps works fine before you enter a sexp in the current REPL.

Actually, what you describe seems to work fine. I can enter a sexp in the editor and 'up', 'down', etc work fine until I hit 'enter'.

So you have to hit 'enter' (submit the sexp) to reproduce.

hjrnunes commented 6 years ago

@cursive-ide I've been trying to consistently reproduce this. I think I made some progress.

It definitely seems related to the REPL history. It would seem the issue fully manifests only if you enter something which is not in the history. This is easiest to see with unusual stuff you wouldn't otherwise enter.

Example:

  1. Open a new REPL
  2. Evaluate this: . (that's a dot only)
  3. Press 'UP' key, expecting to move to (2)
  4. No dice.

Replace dot with -, &, or $, etc, all by themselves. All of them reproduce as long as it's the first time I'm entering them.

d-t-w commented 6 years ago

If I follow my original two comments mechanically I can reproduce this bug consistently. Funnily enough I triggered it several times today when pairing.

Basic symptom is 'up doesn't work', basic response is 'type something new into the REPL, now up works again'.

cursive-ide commented 6 years ago

I still can't reproduce this. Are you getting errors in your log when this happens? Help->Show log in Finder/Explorer

hjrnunes commented 6 years ago

@cursive-ide There seems to be nothing, sorry.

cursive-ide commented 6 years ago

When the UP key is not working in the REPL editor, does the "Previous REPL history item" action work? i.e. clicking on the up arrow icon in the REPL toolbar.

joshkh commented 6 years ago

Just chiming in after a few test runs to debug the same issue.

d-t-w commented 6 years ago

@cursive-ide here's an update from me:

Clojure 1.9, Java 1.8, Intellij 2018.2.1, Cursive 1.8.0-eap5-2018.2.

I could not reproduce when creating a brand new project (lein new..) with no history, no dependencies, and typing in a handful of expressions.

I can reproduce when starting a REPL in an active project with lots of dependencies and a fair amount of existing history. I have a number (10+) of different projects with different dependencies for different clients where REPL exhibit this behaviour so I'm not sure it's dependency related as much as "project has lots of history" related.

When I do reproduce, the UP key behaves precisely the same as the "Previous REPL history item" icon in the toolbar in all examples given.

Steps to reproduce are simple enough, few different scenarios:

Scenario 1

Scenario 2

Scenario 3 (basically the same as 2 with slight oddity on first SEXP)

Example: assuming I've no (+ x y) sexp in REPL history

Starting nREPL server...
/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/bin/java -Dfile.encoding=UTF-8 -XX:-OmitStackTraceInFastThrow -Dclojure.compile.path=/Users/derek/troy-west/clients/verrency/projects/monitoring-service/target/classes 
<...> snip <...>
objc[61615]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/bin/java (0x101a484c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x101ad44e0). One of the two will be used. Which one is undefined.
WARNING: Inst already refers to: #'clojure.core/Inst in namespace: schema.core, being replaced by: #'schema.core/Inst
Connecting to local nREPL server...
Clojure 1.9.0
nREPL server started on port 57676 on host 127.0.0.1 - nrepl://127.0.0.1:57676
(+ 18 12)
=> 30 ;; at this point UP does not work, regardless the number of times pressed.
(+ 20 21)
=> 41 ;; at this point UP works on second press
(+ 101 103)
=> 204 ;; at this point UP works on second press
(+ 109 110)
=> 219 ;; at this point UP works on second press
(+ 109 110)
=> 219 ;; at this point UP works first time 
(+ 20 21) 
=> 41 ;; at this point UP works first time
(+ 1000 1001)
=> 2001 ;; at this point UP works on second press
d-t-w commented 6 years ago

As @hjrnunes says, I need to type SEXP and execute by pressing enter to trigger changing UP behaviour.

d-t-w commented 6 years ago

Nothing in Help->Show log in Finder/Explorer logs

antonmos commented 5 years ago

When the UP key is not working in the REPL editor, does the "Previous REPL history item" action work? i.e. clicking on the up arrow icon in the REPL toolbar.

no, clicking on the up arrow does not work either.

katox commented 5 years ago

It happens to me all the time (for a long time, years). Arrow keys don't work at the REPL start at all in older projects. The workaround is to ctrl-alt-e popup the searchable REPL history and pick the last item there.

It doesn't seem to be related to a project or its size - just the REPL history.

I went on and re-created one of the projects and merged IDEA configurations until a I isolated a single configuration item that causes the issue - it's the component replState.

When replState is mostly empty the REPL history (using arrows) works normally. When I copied my old history it stopped working. It could be a long form, big history or something like that.

@cursive-ide repl-history.diff.gz I attach the workspace.xml diff - maybe you'll be able to reproduce the issue.

d-t-w commented 5 years ago

System: Macbook Pro. Intellij: 2019.1.3 Cursive: 1.8.2-eap4.2019.1

Attached: reproducer workspace.xml.

That's from my IDE when working on cronut.

There are 100 commands in the ReplState component contained in the workspace.xml.

In the scenarios below, the up key and 'previous REPL state' icon have the same behaviour.

Before each scenario I shut Intellij down entirely and start fresh, Intellj caches the workspace.xml and flushes to disk on shutdown.

Scenario 1:

  1. Start REPL
  2. Push UP key
  3. History works as expected

Scenario 2:

  1. Start REPL
  2. Enter a SEXP that does not exist in the history
  3. Up key does not work
  4. Can resolve by hitting cmd-shift-e and selecting the SEXP

Scenario 3:

  1. Start REPL
  2. Enter a SEXP that does exist in the history
  3. Up key works on the second push

I thought it might be a gnarly sexp in the history, so I removed the first 50 commands from REPL state, UP key worked fine.

Interested to find the root cause I reverted the original ReplState and removed the last 50 commands from the REPL state, UP key worked fine.

Then I deleted a single entry from the REPL state (99 in history), repeated Scenario 2 and this time UP key worked on the second press.

Closing and restarting a REPL, now with 100 in the history, repeated Scenario 2 and had the original result, UP key no longer works.

Seems like some interplay between appending to history, whether the item exists in the history already, and whether history is full (I presume 100 is the limit).

@cursive-ide

cursive-ide commented 5 years ago

This is fixed! Thanks for the excellent repro cases, this was in fact two different off-by-one errors in different cases, but both when the REPL history was full. Maintaining the REPL history is surprisingly complicated...

d-t-w commented 5 years ago

Pinnacle of my career being involved in fixing this bug.

conan commented 4 years ago

I've always entered (+ 1) into the REPL because it's a short expression and it seems to make the history work again. Never realised it was to do with whether the expression was in my history or not!