@colinkahn that is what :target is for. there could be a :target :goja. from the looks of it the output of :node-script release builds might just work?

see https://github.com/titonbarua/shadow-cljs-gjs-target for a similar thing

Hello, guys! Yesterday I've updated to 2.10.17. Then my setup with Vim Fireplace has stopped working. I can't no more connect to repl... has anyone experience that? Can help me?

I've also lost completion support recently, so have other users of Conjure, we're seeing NPEs (will attach as snippet after this)

clj-suitable is broken currently. https://github.com/rksm/clj-suitable/issues/15

AH!

Thanks!

apparantly its just disabled in cider now?

Like, no cljs completion until it's fixed?

Because Conjure handles it okay, I don't need to disable it. It's just failing in the background and saying there's no completions.

completion still works I think. just the regular kind. so no completion for "live" JS objects

Ah! So I can turn off that advanced flag

I don't really know how any of it works since I don't use it

No problem, I think it's enhanced-cljs-completion?, pretty sure I can just switch that off for now and it'll continue to work. Thank you so much for the insight.

I'd love a tip or two on reading the below stacktrace. I evaluated a function in the CIDER REPL, and got #object[Error Error: No protocol method ReadPort.take! defined for type null: ] . Then, I did a (tap> *e) in the REPL so that I could take a look at the :stack key on the object using the (amazing) shadow-cljs Inspect tool.

Here's what I see:

Error: No protocol method ReadPort.take! defined for type null: 
    at Object.cljs$core$missing_protocol [as missing_protocol] (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core.cljs:318:3)
    at cljs$core$async$impl$protocols$ReadPort$take_BANG_$dyn_37176 (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core/async/impl/protocols.cljs:13:1)
    at Object.cljs$core$async$impl$protocols$take_BANG_ [as take_BANG_] (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core/async/impl/protocols.cljs:13:1)
    at Function.cljs$core$IFn$_invoke$arity$3 (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core/async.cljs:99:1)
    at Function.cljs$core$IFn$_invoke$arity$2 (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core/async.cljs:99:1)
    at cljs$core$async$take_BANG_ (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/cljs/core/async.cljs:99:1)
    at cljsEval (<eval>:1:36)
    at global.SHADOW_NODE_EVAL ([stdin]:105:10)
    at Object.shadow$cljs$devtools$client$node$node_eval [as node_eval] (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow/cljs/devtools/client/node.cljs:11:1)
    at Object.shadow$cljs$devtools$client$shared$IHostSpecific$do_invoke$arity$2 (/Users/neil/Desktop/loserCLI/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow/cljs/devtools/client/node.cljs:100:5)

I don't see any of the names of my own .cljs files on any of these lines, so I'm not sure where to start looking for the error. To be clear, I'm happy to debug the actual error on my own, I'd just love a tip for getting started.

(<! something) where something is nil

Haha that certainly saves me some debugging time, thank you! I'll remember that particular error-cause relationship now, but do you think it would be useful for me to know how to parse this stack trace?

No protocol method ReadPort.take! defined for type null <! is calling that protocol. the trace is basically just going from the helper fn through the entire implementation ending up at the protocol

it starts with something you called from the REPL

<! is also called take! basically

I guess what's throwing me off is that I don't see any of my own source files in the stack trace. I realize that it's probably hidden by all the compilation that's happening, but I was wondering if I should be configuring something to make them more clear.

go block are rewritten pretty heavily so the stack traces often don't quite make sense

I see, so this unclear stack trace might be an issue I'll keep running into with core.async and go blocks. That helps me understand better, thank you once again.

did you not trigger this from the REPL?

I did, yes.

stacktrace looks like you did so there really is no "file" reference to show

Ooooooh

Of course. One of those things that doesn't make sense until you publicly embarrass yourself with it. Is there a smarter way of evaluating my code that would help me see that "file" reference?

what file reference do you want to see? the error was in the code you just eval'd? you know where that came from?

I just evaluated my main function, which calls a few other functions, and I just wasn't really sure where to start looking for the error.

But it sounds like the trick is just to evaluate smaller blocks of code at a time.

I always just load the entire file and then sometimes code from (comment ...) blocks

Ideally, I would have liked to see the line in my app.main cljs file that contained the <! or the go block that I messed up on.

That's a good tip. Thanks for working with me through these rough spots.

the shadow-cljs codebase is littered with these kinds of comments. usually I clean them up after a while but sometimes they just hang arround

eg. https://github.com/thheller/shadow-cljs/blob/83b7d5ac07bd3e9f776290453e2373e993f5dd55/src/main/shadow/cljs/repl.clj#L653

so in Cursive I just open that file and "Load file in REPL" and then place my cursor in that form and "Send form to REPL"

pretty common workflow. others have made videos about that.

I agree that things could be smarter in that each form sent to the REPL could contain a source location and Cursive does this in some way to Clojure

but thats mostly on the editors not sending the information and the REPLs not respecting or consuming it at all

Glad to hear I'm not entirely going crazy!