This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (15)
- # announcements (4)
- # aws (2)
- # bangalore-clj (7)
- # beginners (236)
- # calva (24)
- # cider (11)
- # cljs-dev (63)
- # clojure (141)
- # clojure-europe (3)
- # clojure-india (2)
- # clojure-italy (8)
- # clojure-nl (3)
- # clojure-spec (8)
- # clojure-uk (52)
- # clojured (1)
- # clojuredesign-podcast (4)
- # clojurescript (35)
- # clojutre (3)
- # community-development (1)
- # cursive (77)
- # data-science (1)
- # datomic (3)
- # emacs (13)
- # fulcro (7)
- # graalvm (78)
- # graphql (2)
- # nrepl (7)
- # off-topic (18)
- # pathom (25)
- # reagent (12)
- # reitit (31)
- # shadow-cljs (178)
- # spacemacs (7)
- # tools-deps (32)
- # xtdb (10)
- # yada (3)
I was just hit by the "npm <" Linux bug: https://github.com/BetterThanTomorrow/calva/issues/283 . I had already encountered it a few months ago but didn't have the time to report/investigate then. But since I have time today, I'm reading the "How to Contribute" page to set up my debugging env, following the instructions, the first one being about saying hello on slack, so here I am: hello everybody ! 🙂
@pez thanks! when running the extension in debug mode, I started getting a
Doesn't support namespace: ... which pointed to a dependency name I mistakenly specified as a string instead of a symbol. Now the issues doesn't occur anymore when running vscode in normal mode from my project, but I'd like to be sure it wasn't magically fixed by running master in debug mode...
Calva should probably handle the error situation much better than just trying to execute that broken command line.
regarding shadow-cljs config validation, looks like it's already planned in some way: https://github.com/thheller/shadow-cljs/issues/492
But better for now to add it as an issue. Jack in is being reworked majorly as we speak so might be a bit messy merging a PR.
even with a valid shadow-cljs config, when I run the master branch in debug mode, the issue disappears, when I remove/reinstall vscode+stable release, the issue is back
Unfortunatelly there are no release tags. But I sometimes include the version number in the commit message. Really should set the git workflow up better!
I see the
2.0.32 commit there. It is the same code as
2.0.33 I think, because something went wrong in the marketplace, publishing 2.0.32, so I had to re-publish.
I couldn't find any clue while debugging (executable/args/task all looked right), except the issue didn't occur after the last breakpoint
possibly just an issue when validating the build selection with the keyboard in the end (see GH)
So, with that help I could reproduce it on my Mac, @sebn. I updated the issue with my repro. Will add validation of this to Calva.
Hi, friends! When using https://github.com/gnl/ghostwheel the docs recommend
> If you’re using Cursive IDE, it’s probably a good idea to use IntelliJ’s intention actions to tell Cursive to resolve >defn and >fdef as defn, and >defn- as defn- – this way you get proper highlighting, formatting, error handling, structural navigation, symbol resolution, and refactoring support.
When working in VS-Code, the symbols are no longer recognized. It's not as much of a big deal as much as it is annoying for every symbol to come up in the "issues" tab 😞.
Does anyone know of a way to alter the resolution of things like
>defn so that it appears to vscode as if it were