Attempting to call unbound fn: #'unrepl.core/write

[aviflax]

I only use Chlorine here and there, and I’m an overeager software updater, so my environment is evolving regularly… so sometimes when I jump into Chlorine I discover some new bug.

Here’s what I saw just now:

1. Started my socket REPL from my terminal
2. Launched Atom
3. Connected Chlorine to my socket REPL
4. Invoked Chlorine’s Load File action on my open buffer
5. Switched to my terminal and attempted to call a fn in a var in the namespace I just loaded

I expected the function to run; instead I got this:

user=> (fc4.io.cli.main-test/check-opts)
Execution error (IllegalStateException) at unrepl.core/non-eliding-write (REPL:31).
Attempting to call unbound fn: #'unrepl.core/write

Screenshots

Atom with my open clj file that I’ve loaded, and the Chlorine REPL window showing the result of the Load File action:

My terminal window with my attempt to call the function and the error message:

Environment

• MacOS 10.15.1
• JRE 13.0.2
• Clojure 1.10.1.510
• Atom 1.44.0
• Chlorine 0.4.10
• Ink 0.12.2

Full output of java -version:

openjdk version "13.0.2" 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.2+8)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.2+8, mixed mode, sharing)

deps.edn aliases

I’ve reproduced this when loading two of my aliases: test and repl, like so:

clj -A:test:repl

Here are those two aliases from my deps.edn:

{:repl {:jvm-opts    ["-Dclojure.server.repl={:port,5555,:accept,clojure.core.server/repl}"]}

 :test {:extra-paths ["test"]
        :extra-deps  {org.clojure/test.check     {:mvn/version "0.10.0"}
                      cloverage                  {:mvn/version "1.1.1"}
                      eftest                     {:mvn/version "0.5.8"}
                      orchestra                  {:mvn/version "2018.12.06-2"}
                      image-resizer              {:mvn/version "0.1.10"}
                      info.debatty/java-string-similarity {:mvn/version "1.2.1"}}
        ; It’s crucial to ensure that the JVM’s default character encoding is
        ; UTF-8 because the renderer outputs UTF-8 encoded text to its stderr,
        ; which the main program (the JVM program) then needs to read correctly.
        ; We’ve found that some Linux systems seem to default to US-ASCII which
        ; will generally break the ability of the main program to properly parse
        ; the error output of the renderer.
        :jvm-opts    ["-Dfile.encoding=UTF8"
                      ; Prevent the Java app icon from popping up and grabbing
                      ; focus on MacOS.
                      "-Dapple.awt.UIElement=true"
                      "-XX:-OmitStackTraceInFastThrow"
                      "--illegal-access=deny"
                      "-Djava.awt.headless=true"]}}

[aviflax]

As I mentioned in Slack, I’ve determined that this problem does not occur in the current master branch of my project; rather it’s only occurring in my feature branch. So there must be some clue in the diff that’ll help debug this.

(Sooner or later master will change and that branch will be deleted, so here’s a permalink to that diff.)

[mauricioszabo]

Fixed on version 0.4.12.