Clojurians Log v2

Hello! I have installed Calva-fmt but not Calva. And in settings.json some calva settings looks disabled ("calva.prettyPrintingOptions": , etc) and some Calva.fmt options looks enabled ("calva.fmt.formatAsYouType": false, etc) But unfortunatelly "calva.fmt.configPath" is disabled and all my custom format settings doesn't work. Is there a way to switch them on?

The configurability of the formatting is not there in Calva-fmt. It is probably much less work to implement it there than in Calva, though, since there is only one formatting mechanism to consider. You can probably make the formatter just slurp the config edn. But I might be oversimplifying. Very long time ago since I archived that repo.

Thanks, I'l try to ask about alternatives

Say I’ve got a new clojure lang window and just pasted a big ol’ line of an edn hash-map. Is there a command to format that nicely in the buffer?

Evaluating it with pretty printing enabled might do it.

It depends a bit on wether you have data readers and stuff in there. Also depends a bit on which pretty printer is used: https://calva.io/pprint/

That worked, thanks! Also realized if the data is formatted correctly and pprint is on, it will pretty print it automatically.

The reason it wasn’t before we as because my query string parser was returning {: nil}

Hey folks, about this problem I was having: https://clojurians.slack.com/archives/CBE668G4R/p1615406922235700 I think I was able to isolate a bit better a scenario. Mainly when I change something in one namespace, and then switch to another one that requires it, the changes are not reloaded from the source/required namespaces when loading the final namespace. Does that makes sense? I think that reloading all the dependencies (or the ones that changed if possible) would solve the problem

If a reload the required namespaces manually things get to work again, but sometimes is a pain to solve the dependency tree inside my head 😛 , then re-starting the REPL is easier

My advice is: always eval the current top-level form any time you make a code change. It’s just a good workflow to get into.

I eval code changes without even saving files and this way my REPL stays up-to-date at all times.

I swap back and forth between files all day long, just eval’ing every top-level form as I change it, often only saving files every 10-15 minutes. I almost never need to reload a namespace, let alone reload-all. And my REPLs stay up and running for weeks (one of my REPLs has been running since January 31st that I’ve used for developing HoneySQL V2 and even my REPL for work has been up since February 26th).

Got it, I am coming from Cursive, and it was able to load the dependencies automatically when re-loading the whole file, so there is a lot of muscular memory to not eval the whole everytime haha. But apart from that, would be expected to dependencies be reloaded, or it shouldn’t be supported by design?

If you change file A (and don’t eval it into the REPL) and then change file B and just eval file B, then file A will not be reloaded by design — because it’s already in memory in compiled form.

Clojure’s require does nothing if the ns is already loaded.

(unless you specify :reload or :reload-all to force it to go back to disk and recompile things)

That’s why I like the workflow I have: I eval each top-level form as I change it and I don’t even need to save files.

(and this is the workflow recommended by folks like Rich Hickey, Stu Halloway — and Eric Normand of http://PurelyFunctional.tv — and several others)

It’s different when you’re using cljs since that requires an explicit compile (to JS) and a hot reload — so you have to save files — but both Shadow-cljs and Figwheel Main take care of recompiling and reloading for you behind the scenes, as far as the browser is concerned.

Got it, Thanks! I think I will to get hang of doing it more frequently, and maybe installing some hooks to auto-load it when saving files (which VS code do when changing focus)

I also prefer this workflow and want to add that this “not even saving files” might make some people nervous, but with VS Code I have never experienced that I lose work even though I have those round dots all over the place. Both because VS Code just never crashes and because when I kill it, it remembers my work state perfectly, including active selection even. (Since I do most of my work from Calva running in debug session, I kill the workspace window quite often.)

☝️:skin-tone-2: This is also a good reason to start your REPL outside of the editor so that it survives a restart of your editor. I restart VS Code more often for updates than I restart my REPLs.

(I also switch VS Code between my OSS workspace and my World Singles Networks workspace twice a week, which would kill the REPLs if they were started inside VS Code I believe)

Yes, when switching workspaces all processes started by/from the window are killed.

Quite recently, @brandon.ringe added so that you can copy the jack-in command Calva would use to the clipboard. Making it almost as easy to start any project from outside VS Code as with using jack-in. I use that quite a lot.

Yeah, makes sense, adding the jack-in dependencies into the lein project/profile should also work right?

It would, but I think that editor dependencies do not belong in the project. If you do it like that, at a minimum isolate it to a :calva (or similar) profile so that people using other editors, with other dependencies do not get affected.

Generally I think that having those settings in the project make them more magical and less visible. With jack-in it is more transparent what is going on.

My typical REPL startup command looks like: clojure -M:rebel:reveal:test:dev/repl 🙂 based on my dot-clojure repo. Sometimes with :add-libs if I want to be able to add new dependencies while my REPL is running.

Hey folks, I’m having this weird issue that more often than not, when I point at some symbol in the editor, the following exception is shown in the log. What’s the best way to debug it?

ERROR:ERROR:  Unhandled REPL handler exception processing messageUnhandled REPL handler exception processing message  {{:op :opinfo info, :ns,  :nsmrkam.server.server , mrkam.server.server:symbol,  :symbolcreate-server , create-server:id,  :id10 , 9:session,  :sessionfce47507-2a91-4e2e-b545-e645b0a7241e fce47507-2a91-4e2e-b545-e645b0a7241e}}

java.lang.ClassNotFoundException: com.sun.tools.javac.util.List

        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
        at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:69)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at clojure.lang.DynamicClassLoader.loadClass(DynamicClassLoader.java:77)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:348)

        at clojure.lang.RT.classForName(RT.java:2211)
        at clojure.lang.RT.classForName(RT.java:2220)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$parse_java.invokeStatic(legacy_parser.clj:88)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$parse_java.invoke(legacy_parser.clj:66)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$source_info.invokeStatic(legacy_parser.clj:274)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java.legacy_parser$source_info.invoke(legacy_parser.clj:265)

        at clojure.lang.Var.invoke(Var.java:384)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$source_info.invokeStatic(java.clj:144)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$source_info.invoke(java.clj:139)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$class_info_STAR_.invokeStatic(java.clj:223)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$class_info_STAR_.invoke(java.clj:214)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$class_info.invokeStatic(java.clj:261)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$class_info.invoke(java.clj:253)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$resolve_class.invokeStatic(java.clj:340)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$resolve_class.invoke(java.clj:331)
        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$resolve_symbol.invokeStatic(java.clj:371)

        at cider.nrepl.inlined_deps.orchard.v0v6v4.orchard.java$resolve_symbol.invoke(java.clj:357)

        at cider.nrepl.middleware.stacktrace$analyze_fn.invokeStatic(stacktrace.clj:84)
        at cider.nrepl.middleware.stacktrace$analyze_fn.invoke(stacktrace.clj:63)

        at clojure.core$comp$fn__5807.invoke(core.clj:2569)
        at clojure.core$comp$fn__5807.invoke(core.clj:2569)

        at clojure.core$comp$fn__5807.invoke(core.clj:2569)
        at cider.nrepl.middleware.stacktrace$analyze_frame.invokeStatic(stacktrace.clj:180)
        at cider.nrepl.middleware.stacktrace$analyze_frame.invoke(stacktrace.clj:177)
        at clojure.core$map$fn__5866.invoke(core.clj:2755)
        at clojure.lang.LazySeq.sval(LazySeq.java:42)

        at clojure.lang.LazySeq.seq(LazySeq.java:51)
        at clojure.lang.LazySeq.first(LazySeq.java:73)

        at clojure.lang.RT.first(RT.java:692)

        at clojure.core$first__5384.invokeStatic(core.clj:55)

        at clojure.core$first__5384.invoke(core.clj:55)

        at cider.nrepl.middleware.stacktrace$flag_duplicates.invokeStatic(stacktrace.clj:168)
        at cider.nrepl.middleware.stacktrace$flag_duplicates.invoke(stacktrace.clj:164)

        at cider.nrepl.middleware.stacktrace$analyze_stacktrace.invokeStatic(stacktrace.clj:186)
        at cider.nrepl.middleware.stacktrace$analyze_stacktrace.invoke(stacktrace.clj:182)

        at cider.nrepl.middleware.stacktrace$analyze_cause.invokeStatic(stacktrace.clj:290)

        at cider.nrepl.middleware.stacktrace$analyze_cause.invoke(stacktrace.clj:281)
        at cider.nrepl.middleware.stacktrace$analyze_causes$fn__4786.invoke(stacktrace.clj:315)
        at clojure.core$map$fn__5862$fn__5863.invoke(core.clj:2742)
        at clojure.core$take_while$fn__5913$fn__5914.invoke(core.clj:2901)
        at clojure.lang.Iterate.reduce(Iterate.java:81)

        at clojure.core$transduce.invokeStatic(core.clj:6883)
        at clojure.core$into.invokeStatic(core.clj:6899)
        at clojure.core$into.invoke(core.clj:6887)
        at cider.nrepl.middleware.stacktrace$analyze_causes.invokeStatic(stacktrace.clj:314)

        at cider.nrepl.middleware.stacktrace$analyze_causes.invoke(stacktrace.clj:306)
        at clojure.lang.Var.invoke(Var.java:388)
        at cider.nrepl.middleware.util.error_handling$pp_stacktrace.invokeStatic(error_handling.clj:44)

        at cider.nrepl.middleware.util.error_handling$pp_stacktrace.invoke(error_handling.clj:39)

        at cider.nrepl.middleware.util.error_handling$base_error_response.invokeStatic(error_handling.clj:54)
        at cider.nrepl.middleware.util.error_handling$base_error_response.doInvoke(error_handling.clj:46)

        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at cider.nrepl.middleware.util.error_handling$eval3486$fn__3487.invoke(error_handling.clj:129)
        at clojure.lang.MultiFn.invoke(MultiFn.java:239)

        at cider.nrepl.middleware.util.error_handling$eval3498$fn__3499.invoke(error_handling.clj:140)

        at clojure.lang.MultiFn.invoke(MultiFn.java:239)

        at cider.nrepl.middleware.util.error_handling$eval3502$fn__3503.invoke(error_handling.clj:143)

        at clojure.lang.MultiFn.invoke(MultiFn.java:239)

        at <http://cider.nrepl.middleware.info|cider.nrepl.middleware.info>$handle_info.invokeStatic(info.clj:96)
        at <http://cider.nrepl.middleware.info|cider.nrepl.middleware.info>$handle_info.invoke(info.clj:95)

        at clojure.lang.Var.invoke(Var.java:388)

        at cider.nrepl$wrap_info$fn__2007.invoke(nrepl.clj:203)
        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)

        at nrepl.middleware.load_file$wrap_load_file$fn__1455.invoke(load_file.clj:81)

        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)
        at cider.nrepl$wrap_content_type$fn__1941.invoke(nrepl.clj:105)

        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)
        at cider.nrepl$wrap_tracker$fn__2105.invoke(nrepl.clj:467)

        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)

        at nrepl.middleware.session$session$fn__1091.invoke(session.clj:309)

        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)
        at nrepl.middleware.caught$wrap_caught$fn__926.invoke(caught.clj:97)

        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)

        at nrepl.middleware.print$wrap_print$fn__893.invoke(print.clj:234)
        at nrepl.middleware$wrap_conj_descriptor$fn__658.invoke(middleware.clj:16)
        at nrepl.server$default_handler$fn__1586.invoke(server.clj:130)

        at nrepl.server$handle_STAR_.invokeStatic(server.clj:22)

        at nrepl.server$handle_STAR_.invoke(server.clj:19)
        at nrepl.server$handle$fn__1557.invoke(server.clj:39)

        at clojure.core$binding_conveyor_fn$fn__5754.invoke(core.clj:2030)
        at clojure.lang.AFn.call(AFn.java:18)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)

any chance you're using Java 16?

that com.sun.tools.javac stuff is Java internals and they've been progressively shutting access to that stuff down and I believe it is no longer available in Java 16 (may have been earlier, not sure)

In repl, I’m seeing this:

(System/getProperty "java.version")
"1.8.0_131"

I also do have it in REPL:

(Class/forName "com.sun.tools.javac.util.List")
com.sun.tools.javac.util.List

Well, was just a guess. I thought maybe system Java updated and calva was using it

That looks like this issue: https://github.com/clojure-emacs/orchard/issues/105

Check your version of orchard in your classpath with lein classpath or clj -Sdeps run from your project directory

Well actually you may want to check your cider-nrepl version, rather

If it's not the one you see in the command that runs when you jack-in, it may be added by some other dependency, such as one in your ~/.lein/profiles.clj

It could also be coming from a dep in your project too, I guess

Removing or upgrading that dep may help. Also, if you're using lein, you could instead see if it happens with the clojure cli, which resolves deps differently.

Otherwise, the linked issue and the one also linked in that issue may provide some help