This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # announcements (2)
- # babashka (48)
- # beginners (59)
- # calva (5)
- # cider (14)
- # clj-kondo (4)
- # cljs-dev (3)
- # clojure (77)
- # clojure-europe (6)
- # clojure-italy (6)
- # clojure-nl (5)
- # clojure-spec (4)
- # clojure-uk (67)
- # clojurescript (19)
- # clr (3)
- # cursive (7)
- # datomic (36)
- # duct (33)
- # events (3)
- # figwheel (1)
- # fulcro (4)
- # funcool (2)
- # graalvm (3)
- # jobs (1)
- # joker (25)
- # kaocha (1)
- # leiningen (45)
- # malli (17)
- # off-topic (103)
- # quil (1)
- # re-frame (16)
- # reitit (1)
- # rewrite-clj (27)
- # shadow-cljs (39)
- # spacemacs (3)
- # sql (11)
- # tools-deps (14)
- # vim (41)
@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…
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
@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?
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…
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.
you keep chanting "async async async" while basic functionality is broken and dom is indulging in hypothetical async use cases
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.
Writing up an issue in the Shadow CLJS repo I found this https://github.com/thheller/shadow-cljs/issues/563
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
Yeah confirmed. This bit has been last touched in
2.8.66 and I’ve been running
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