This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # babashka (51)
- # beginners (292)
- # calva (37)
- # chlorine-clover (40)
- # cider (5)
- # clj-kondo (83)
- # cljs-dev (26)
- # cljsrn (36)
- # clojure (168)
- # clojure-argentina (5)
- # clojure-austin (1)
- # clojure-australia (9)
- # clojure-europe (3)
- # clojure-france (7)
- # clojure-gamedev (3)
- # clojure-nl (3)
- # clojure-spec (4)
- # clojure-uk (34)
- # clojurescript (46)
- # community-development (1)
- # conjure (26)
- # core-async (28)
- # crux (1)
- # data-science (2)
- # datascript (2)
- # datomic (61)
- # devcards (3)
- # emacs (7)
- # events (2)
- # fulcro (65)
- # graalvm (57)
- # instaparse (2)
- # juxt (21)
- # luminus (6)
- # off-topic (21)
- # pathom (1)
- # pedestal (15)
- # reagent (1)
- # shadow-cljs (19)
- # spacemacs (3)
- # specter (1)
- # sql (14)
- # unrepl (4)
- # vscode (1)
- # yada (4)
Wowza. I Had some time to explore the issue I was experiencing https://clojurians-log.clojureverse.org/chlorine/2020-04-05. Herein lies the journey. Let me know if this tracks @mauricio.szabo ?
I started playing with the
repl-tooling repo and found that the problem is https://github.com/mauricioszabo/repl-tooling/blob/67898c9ac95f02162d17bee6aeb5f6e6db34dbfa/src/repl_tooling/integrations/repls.cljs#L19 … but I don’t actually think this is a “chlorine” issue
The idea is this. If we were to run clojurescript
1.10.597 with the
clj -J-D … command (full command in the link in the original thread msg) the
watcher is never called.
The result is that
repl-tooling will not consider the repl “connected”.
However, from my tests, it seems that if we run anything starting at https://github.com/clojure/clojurescript/commit/5b2d4b8a33355dfcde16e54b9175b97cc6d76c91 everything works fine.
It appears the reason for this is because with the change in the 1.10.663 commit, the result is
:browser-repl true is now always passed in as an
env-option . This is happening because
browser-repl true seems to always be part of the default repl options and prior to the change in 1.10.663 it just never made it through
The reason I suspect it’s this change is because this is the commit that makes it possible to run the clojurescript socket repl and connect
repl-tooling to it. the big difference is that :`browser-repl true` now makes it through to
Anyways, I don’t think this is an issue because the latest CLJS release will see it gets resolved, but just wanted to see what was going on and if this tracks or maybe it’s a red herring :thinking_face:
Sorry, I didn't have time to see this issue. But I don't know what's happening, to be honest...
In fact, I mostly work in cljs with shadow-cljs, so other targets are getting a little less attention :)
I imagine that, when the REPL connects, it'll send some data to the socket... But I'll check if it is indeed the case
Thanks and no rush! I just noticed this and thought I would dig in a little 🙂
And yes, the clojurescript socket repl is not really my primary approach to working with a CLJS repl, but this is a generally nice tool for new clojurescript devs (no extra deps) so I thought I would be see if it would work
To be honest, the way node.js works, at these moments, are kinda hard to deal with 😎
> it’ll send some data to the socket Yeah, this is what I think the 1.10.597 cljs setup is not doing so the buffer never runs the watch.
@mauricio.szabo in general, what do you think it would take to get Chlorine working with
figwheel-main? If I have time, and you’re interested, I wouldn’t mind looking into this…if for nothing else than curiosity.
Great, thanks! So, the way that it currently work is the following: everything starts on this file/line: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/editor_integration/connection.cljs#L110-L113
If you follow the paths, you'll get here: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/editor_integration/embedded_clojurescript.cljs#L67
This is probably the first line that needs to be changed - something like "use the current
:clj/aux REPL to discover if we're running shadow-cljs or Figwheel-main"
Currently, there's a special "evaluator" for Shadow-CLJS that uses its internal APIs to evaluate code. This will probably be the default for Shadow in the future. But the "old API" still exists: it basically needs a host / port, and a command. It'll connect to a Clojure REPL, then run a command to transform that REPL in ClojureScript: https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/integrations/connection.cljs#L30-L49
It is also a good idea to save information on how to get the current ClojureScript env from Clojure code, then save it on the "global state": https://github.com/mauricioszabo/repl-tooling/blob/master/src/repl_tooling/editor_integration/embedded_clojurescript.cljs#L25-L26
Great! I think for figwheel you'll have to add piggieback even for Socket REPL to be able to transform the REPL into a CLJS one
At least, when I started to check figwheel-main I had this problem. Don't know if it still exists today 🙂
@mauricio.szabo Where do I have to change to automatic start
deps.edn and connect to it?
BTW, there's a FAQ where I explain some of design decisions on Chlorine, and there's a section for Jack-in: https://github.com/mauricioszabo/repl-tooling/blob/master/doc/FAQ.md#when-jack-in-will-be-implemented The problem with these solutions is that you're inside an editor (that's not known to be fast nor memory-friendly), and then you start a Java process (that's also hard on memory)...
Also... there's lots of coordination for jack-in to work: it's already kinda hard to coordinate between states on the editor (like, when someone connects, disconnects, starts a CLJS REPL, watch configs, the inline results). To add an external process into the mix can become really complicated...
There's also the customizability aspect: as soon as you offer jack in, folks will want to be able to customize all sorts of aspects of it and that gets really nasty.
Because of the way we run REPLs at work, I don't think any "built-in" jack-in functionality would ever work for us... I mean, it would basically need to allow us to enter an arbitrary command to start the appropriate REPL... so why not just type that in at the command-line anyway?
Also, I tend to start a REPL (from the command line) and run it for days, sometimes even weeks -- so I'd only need "jack in" once a week or less. Seems like a waste of time to divert effort to such a feature.
(I've never really understood why CIDER expended so much effort on that... except for it already being a complete "kitchen sink" plugin anyway)
I imagine because it's hard to coordinate all dependencies that it needs to run. This "feature discovery" that I do on Chlorine is yet another state control 😄