This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-03
Channels
- # aleph (6)
- # announcements (4)
- # babashka (73)
- # beginners (117)
- # calva (25)
- # chlorine-clover (59)
- # cider (21)
- # clara (3)
- # cljdoc (8)
- # cljs-dev (54)
- # cljsrn (15)
- # clojure (65)
- # clojure-france (5)
- # clojure-spec (3)
- # clojure-uk (13)
- # clojurescript (79)
- # conf-proposals (1)
- # conjure (17)
- # core-logic (11)
- # datomic (21)
- # fulcro (82)
- # graalvm (11)
- # helix (7)
- # jobs-discuss (11)
- # joker (2)
- # juxt (3)
- # local-first-clojure (1)
- # luminus (5)
- # nrepl (61)
- # off-topic (12)
- # pathom (70)
- # re-frame (3)
- # reitit (3)
- # rum (1)
- # shadow-cljs (58)
- # sql (1)
- # tools-deps (26)
- # xtdb (3)
Never seen that, @me1260. Thanks for investigating! I doubt it something recent, but can you try with an old version? .77 or something.
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?
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
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?
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
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?
Here's a build that should improve how Calva handles when a bare file is opened. https://5985-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.98-fix-open-bare-file-622-6e5ad424.vsix
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: https://5985-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.98-fix-open-bare-file-622-6e5ad424.vsix
@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.
I have only used it briefly but the Java language pack ships with a language server. https://marketplace.visualstudio.com/items?itemName=redhat.java
@borkdude @pez the bb/calva combo is pretty exciting. Now if we could only get arm32 graal...
@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