Fork me on GitHub

Never seen that, @me1260. Thanks for investigating! I doubt it something recent, but can you try with an old version? .77 or something.


It's extra tricky since it seems to be intermittent...

Sam DeSota13:05:59

Yeah, pretty strange. I'll try to reproduce, I can't repro from a fresh figwheel-main project. To get over the problem yesterday, I seperated my project into 2 seperate directories for client + server. Perhaps it only appears with certain deps? I may try to recombine incrementally to see if I can repro. I'll create a GH issue if I can find a repro case. Thanks!


When you get the error, is it only the load file that gets this treatment, or is it evaluations too? And what does the statusbar icon say?

Sam DeSota14:05:03

If I eval something like js/window , it will say no such namespace js, so it looks like it's just load file. Status says NREPL connected + clj

Sam DeSota14:05:42

Actually maybe this is a problem with the running the clj code on the figwheel server. Is the clj repl the same process that runs figwheel?

Sam DeSota14:05:08

Error message, just importing aleph.http, works with a normal project:

[Figwheel:WARNING] Couldn't load Clojure file: clojure.lang.Var$Unbound cannot be cast to clojure.lang.IPersistentCollection  file:/Users/samueldesota/.m2/repository/byte-streams/byte-streams/0.2.4/byte-streams-0.2.4.jar!/byte_streams/graph.clj   line:91  column:1
[Figwheel:SEVERE] java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.IPersistentCollection


Figwheel is run off of the clj repl, yes.

Sam DeSota15:05:24

Got it. So maybe the error is just that importing aleph conflicts somehow with figwheel. Shouldn't the errors appear in the CLJ repl instead of the CLJS repl though?


Yes, I don't understand why it goes to the CLJS repl...


So, with the currently released Calva, if you open a Clojure file in VS Code without having a folder or workspace open, Calva would just not work at all. So it would refuse to delete a character and just complain about anything you try to do. With this build, Calva should function in this situation. The build:


@hindol.adhya: Looking at what CIDER does, it too fails a bit on providing the docs. I',m not sure what is going on, but I suspect that it could depend on the java dist. However, CIDER used the nrepl op eldoc instead of info for some of this, and it at least provides some info. We shoulr probably make Calva do that as well, and build out our REPLInfoParser a bit.


Since I have done Java professionally in the past, I have experience using Intellij IDEA. I can share what it does. Some Java libs distribute the source files in addition to the compiled byte-code. In such cases IDEA can open the source directly. The source is available at a predictable path. (I have seen CIDER do that as well) Some Java libs don't package the source. In such cases, IDEA decompiles the class file using a decompiler (Fernflower). I don't think CIDER can do this bit.


It might be that the java extension has some api we can tap into.


I have only used it briefly but the Java language pack ships with a language server.


@pez, that works much better.


@borkdude @pez the bb/calva combo is pretty exciting. Now if we could only get arm32 graal...


there is aarch64 bb fwiw


@sogaiu, yes that handles most of the rpi platforms, if you use arch. I'm hoping to see some support for smaller embedded plats that only deal with 32-bit code - my particular itch


it would be nice, but i wonder whether it will happen


there seem to be a number of different distributions that do 64 bit on the more recent rpi models from what i gather


which smaller things do you have in mind?


ah, this is far removed from calva 🙂