Fork me on GitHub
#vim
<
2019-11-18
>
martinklepsch09:11:01

@tpope @dominicm it seems that this at least some parts of this are known issue with shadow-cljs: https://github.com/thheller/shadow-cljs/issues/373 — that said I had this working with CIDER in Emacs so I think there must be a difference there too…

martinklepsch12:11:37

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

dominicm13:11:31

Ah, that would do it

tpope18:11:51

called it

martinklepsch18:11:18

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

martinklepsch18:11:32

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?

tpope18:11:03

i think you're getting ahead of yourself

tpope18:11:06

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

tpope18:11:37

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

dominicm18:11:46

Figwheel manages it AFAIK

dominicm18:11:31

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.

martinklepsch21:11:02

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

dominicm21:11:04

That will fix the ptintln case at least

martinklepsch21:11:09

But not the async case?

martinklepsch21:11:03

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.

dominicm21:11:19

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

dominicm21:11:37

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

tpope21:11:32

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

tpope21:11:45

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

tpope21:11:20

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

martinklepsch21:11:54

you = me or Dom? 😄

tpope21:11:53

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

tpope21:11:34

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

tpope21:11:51

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

dominicm22:11:59

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.

dominicm22:11:29

But yeah, basic problem first

martinklepsch14:11:12

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

tpope19:11:02

so why does it work in figwheel? :thinking_face:

tpope19:11:11

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

tpope19:11:05

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

tpope19:11:44

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

tpope06:11:17

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

martinklepsch08:11:39

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

martinklepsch12:11:26

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

dominicm17:11:41

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

dominicm09:11:39

It might travel over System/out to the launch process