Fork me on GitHub
#calva
<
2019-08-30
>
sebn08:08:55

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 ! 🙂

pez09:08:03

@sebn: welcome! And awesome that you are picking that up!

sebn09:08:13

@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...

pez10:08:52

Calva should probably handle the error situation much better than just trying to execute that broken command line.

sebn11:08:43

regarding shadow-cljs config validation, looks like it's already planned in some way: https://github.com/thheller/shadow-cljs/issues/492

pez11:08:52

Good find. But before shadow can detect it Calva needs to start shadow. 😃

sebn11:08:03

makes sense 🙂

pez11:08:45

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.

sebn12:08:20

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

pez12:08:19

Interesting. Does that mean that someone has fixed it in master maybe…

sebn12:08:37

I'll try to run from a tag

pez12:08:47

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!

pez12:08:16

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.

sebn12:08:53

now I'm getting the issue both on master and when checking out this commit 🙈

sebn12:08:42

at least I can try to debug

sebn12:08:30

I couldn't find any clue while debugging (executable/args/task all looked right), except the issue didn't occur after the last breakpoint

pez13:08:21

It is also quite strange why it would behave different on Linux…

sebn17:08:41

possibly just an issue when validating the build selection with the keyboard in the end (see GH)

pez17:08:14

Oh. That’s super strange. Thanks for investigating it so thoroughly.

sebn17:08:54

you're welcome. huge thanks to you for such a useful extension 🙂

❤️ 1
calva 1
pez19:08:17

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.

🎉 1
Danny22:08:09

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 defn ?