Clojurians Log v2

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 env-options.

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

(sorry if its a little overwhelming 😄)

This is a good start! Thanks 🙂 I will follow up with questions I may have.

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?

can be direct to init.coffee?

You mean like a jack-in command, or something?

yes, somethink like that

because I have to write the command into source code to remember 🙂

Add it as an :alias in your ~/.clojure/deps.edn file?

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)

Ah, there's also the problem with env vars! Most editors don't set the environment variables correctly when running external processes. This is not a problem, except when you add private repositories on the mix... and now the REPL doesn't start with bizarre errors

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 😄

Ah, and I have no idea what "kitchen sink" means in this context 😄

Slang for "includes everything"

Thanks 😄