Conversation with @U05224H0W is here: https://clojurians.slack.com/archives/C6N245JGG/p1574010613387500

> the problem likely is that the node-repl captures stdout/stderr and sends those without any nrepl message id

Ah, that would do it

called it

@tpope do you consider this an issue with Shadow-cljs or something that should be addressed in Fireplace?

I guess for sync stuff it’s shadow-cljs’ fault to not include the message ID With async stuff on the other hand I feel like it’s impossible to properly know that ID and thus it can only be addressed in Fireplace?

i think you're getting ahead of yourself

it's definitely possible for an async process to remember a message id

nfi how the implementation works but "impossible" it is not

Figwheel manages it AFAIK

Well, I'm not sure actually. Unless you have a persistent output buffer, then async println will not have anything listening to it when it happens.

Fair enough 😄 So do you think I should be pushing this on the side of Shadow-CLJS? I’m a bit lost…

That will fix the ptintln case at least

But not the async case?

For me this is a real blocker in terms of workflow and I ended up starting up Emacs because I just couldn’t do without this. Not trying to create any kind of pressure, just giving a data point about the impact of not having reliable access to stdout.

The async case will require fireplace to continue listening even after something has finished evaluation, and put that somewhere.

@tpope can advise best on what that feature would look like in vim.

i already said long term plan is some sort of log buffer

but I am not even close to convinced it's relevant

nobody said anything about "after evaluation" until you brought it up

you = me or Dom? 😄

you keep chanting "async async async" while basic functionality is broken and dom is indulging in hypothetical async use cases

@(future (println "hi")) this is async in clojure and it works fine

https://github.com/thheller/shadow-cljs/issues/373#issuecomment-532180236

doesn't look like anyone followed up on this, I would start by doing that

So the use cases is clojurescript where there's no effective deref. (-> (some-js-promise) (.then println)) is a debugging strategy I use. Fortunately I can just look in the browser console. I missed the log buffer, I expect that would solve the problem.

But yeah, basic problem first

Writing up an issue in the Shadow CLJS repo I found this https://github.com/thheller/shadow-cljs/issues/563

so why does it work in figwheel? :thinking_face:

the obnoxious thing is that it sends a wrong :id. if it just omitted the id, I'd feel more comfortable just fudging it into an active evaluation

actually an omitted :id could come from even a vanilla clojure session, that's not great either

can you figure out what that :id is? if it's from the initial :clone or something like that, then maybe we can use that to line up the fudging

It seems to be the “last message id” (not entirely sure if that is specific enough) https://github.com/thheller/shadow-cljs/blob/164153da559b63520a5748f1dcf9547043360403/src/main/shadow/cljs/devtools/server/nrepl_impl.clj#L221-L237

@U050TNB9F is that the same code in whatever stable release you are using?

@tpope 95% sure but I’ll confirm and report back

Yeah confirmed. This bit has been last touched in 2.8.66 and I’ve been running 2.8.68 https://github.com/thheller/shadow-cljs/releases/tag/2.8.66

Also opened this issue https://github.com/thheller/shadow-cljs/issues/602 to capture the comment that you pointed me at properly https://github.com/thheller/shadow-cljs/issues/602

https://github.com/thheller/shadow-cljs/blob/2.8.66/src/main/shadow/cljs/devtools/server/nrepl_impl.clj#L198-L199 sounds extremely relevant

There's a patch in the history of figwheel that fixed this.