Clojurians Log v2

Yeah using the REPL more is clearly superior. But sometimes you're in 20 calls deep, with some data from the DB in scope, and just want to see what keys are there (or whatever). I think breaking up stuff more is probably a good approach. Especially in the middle of a let

Some posted this the other day. Maybe it’s a good fit https://github.com/gfredericks/debug-repl

For that use case, I prefer using https://github.com/vvvvalvalval/scope-capture Rather than stopping at a break point, you “record” all variables in scope and can use REPL to inspect those variables afterwards.

Yes, I think this should have been fixed. I’ll check to see if I can figure out why it’s regressed.

Thanks for the issue, I’ll take a look.

It’s occasionally a little flakey, but it’s not usually that problematic. I’d be interested in seeing a screenshot of the debugger in a case where you’re not seeing locals you think you should be.

I had to invalidate cache

It seems to be related to the "idempotent computation" dialog. It could be that only one of resulting values is saved and that could lead to corrupted indexes. It used to be quite rare but with recent IDEA versions and Cursive I need to "restart and invalidate" on daily basis. If you re-run indexing you're more likely to avoid this race condition (speculating).

I'm sure this has been asked before, but I'm curious what would be the best thing to do to get intellisense for typescript libs? Compilation is much more straightforward now with shadow-cljs, but would be cool if I could get the ability to leverage cursive's ability to auto-import typescript libraries like I can import clojure(script) libraries. My first thought is that I take a stab at generating a bunch of clojurescript namespaces with wrapper methods and defs using the typescript compiler to give me an AST from .d.ts files (or even just ts files). But with cursive is there something even better I could generate? Something that would expose the actual typescript lib's API instead of my wrapper code? (Definitely a lot of work I'm sure, but sounds like a fun side-project)

That’s basically what I’m planning to do (have support based on .d.ts files), but I’ll write a parser for them in Java or Kotlin since the format is not as complex as full typescript.