Fork me on GitHub
#cljs-dev
<
2019-01-25
>
thheller12:01:04

so I'm adding support for prepl to shadow-cljs and wondered how CLJS solved the "upgrade" problem. turns out it doesn't at all.

thheller12:01:20

I guess starting a CLJS prepl from a CLJ prepl is not a supported use case?

thheller12:01:49

ie. I'm in a CLJ prepl

thheller12:01:58

1
{:tag :ret, :val "1", :ns "user", :ms 0, :form "1"}

thheller12:01:17

I launch (cljs.core.server/io-prepl :repl-env ...)

thheller12:01:26

1
{:tag :out, :val "{:tag :ret, :val \"1\", :ns \"cljs.user\", :ms 7, :form \"1\"}\r\n"}

thheller12:01:12

as expected the outer prepl re-encodes whatever the CLJS loop does given that it just communicates over *out*

thheller12:01:23

not sure how any tool is supposed to deal with this in a nice way over a socket

thheller12:01:07

guess by not using io-prepl ...

😬 5
dnolen19:01:18

I don't really understand the perceived problem

dnolen19:01:26

why do you need to wrap prepls in this way?

thheller19:01:39

I'm looking at tool support which will connect to a remote prepl connection

dnolen19:01:39

re: upgrade problem - yeah we're not going to do anything about that same as Clojure

thheller19:01:11

I'll probably resort to something that opens a dedicated socket for CLJS

dnolen19:01:20

re: tool support you can start Clojure and ClojureScript io prepls servers

thheller19:01:22

instead of having one CLJ socket open that "upgrades"

dnolen19:01:24

I don't see why you need to nest them

thheller19:01:37

well you do nest them now don't you?

thheller19:01:51

ie tinker in CLJ then launch a CLJS repl

thheller19:01:21

just with a regular socket REPL where this works without issue of course

dnolen19:01:54

I actually didn't do much of that before, still don't do that now really

dnolen19:01:17

but I did work on a project that did - and it is useful

dnolen19:01:27

but since pREPL returns a value it gets tricky

dnolen19:01:36

because the JS process is only going to return strings

thheller19:01:02

yeah typically the model for shadow-cljs was to only have one socket port open which starts in CLJ mode

thheller19:01:23

you then switch it to whatever CLJS repl you want

thheller19:01:41

which works fine in socket REPL and nrepl

thheller19:01:50

for prepl I'll just open another port I guess

thheller19:01:02

would be nice if there was a *out-fn* binding that could be re-used to send msgs directly without going through *out*

thheller19:01:57

bound by the CLJ version and re-used by CLJS I mean

dnolen19:01:27

@thheller did you try to change the ClojureScript pREPL :val-fn so the outer pREPL gets what it expects

dnolen19:01:38

if you just read the value that would work no?

thheller19:01:19

it works when providing custom :out-fn and not using io-prepl

thheller19:01:32

not sure I understand what :val-fn would do

thheller19:01:54

I'm overthinking it really .. tools are probably going to stick with nrepl for a while

dnolen19:01:13

re-reading the above don't nested Clojure pREPL encode again as well?

Alex Miller (Clojure team)19:01:29

(I have not yet gotten around to writing the accompanying words that go with the picture)

dnolen19:01:24

@thheller I wonder if this is really actually a problem?

dnolen19:01:40

since the client can see what :form is and you are guaranteed order of results

thheller19:01:03

it is the most annoying problem for nrepl so it isn't much different for prepl

dnolen19:01:03

you can probably tweak the client to read out the nested thing

thheller19:01:32

not really since its all :tag :out so any prints in the middle will blow it up

dnolen19:01:09

:out can be treated separately from :ret

dnolen19:01:13

that's the whole point

thheller19:01:38

there is no :ret if its nested

thheller19:01:54

what the client receives is all :tag :out after upgrading

dnolen19:01:16

ah sorry got it - yeah that was the part I was missing

dnolen21:01:26

so I think I have a simple (hopefully temporary) fix for CLJS-3030

dnolen21:01:52

core.async doesn't really use the analyzer, it just needs macroexpand so the structure of the locals doesn't really matter that much far as I can tell

dnolen21:01:19

we can just check to make sure we have a map, meaning this should support core.async which isn't doing the right thing at the moment

dnolen21:01:27

and let ClojureScript keep going with the new way

dnolen21:01:11

@mfikes I added the clojure.edn thing so we should probably mention that one in the post - if this last fix works I think we're good for a release (probably not today since it's getting late)

dnolen21:01:14

but next week for sure

mfikes21:01:39

@dnolen Cool. I'll add a bit about that. Also https://dev.clojure.org/jira/browse/CLJS-3031 is related to this section of the news post https://github.com/clojure/clojurescript-site/blob/news-next/content/news/2019-01-04-release.adoc#improved-loop--recur-inference (without CLJS-3031 a warning would appear—I'll revise that content to avoid the warning)

dnolen21:01:47

testing that one now

dnolen21:01:13

folks might want to give master a try to verify that nothing is amiss

darwin21:01:14

I’m scratching my head, is there anything else than :aot-cache option to disable some shared compiler cache? my lein cljsbuilds are failing when building after doing advanced mode compilation of the same code

darwin21:01:25

still trying to figure out that chromex library issue

darwin21:01:51

setting :aot-cache false explictly does not help me, only setting :process-shim false fixes the issue, because the none build fails with java.io.FileNotFoundException: The file test/.compiled/optimizations_none/process/env.cljs does not exist.

darwin21:01:13

like it would think that target is nodejs, but none of my compilations are targeting node

darwin21:01:28

doing none build after lein clean works as expected

darwin21:01:56

I just briefly tested current master with chromex and the stackoverflow compiler issue is now present in all cases, even with this commit, which I used to work around it: https://github.com/binaryage/chromex/commit/cf5bf7bc490c96310a5fa92f81da305134fcd9ce

mfikes21:01:02

Not sure what's up with that, tried twice, not going for a third now.

darwin21:01:39

let me look, I think I could try to use different ubuntu release (in docker)

darwin21:01:43

ah, this is not our ubuntu in the docker, this is their base ubuntu

darwin22:01:37

I was able to kick it and now it failed in clojurescript compiler build script, have you seen this before? https://travis-ci.org/cljs-oss/canary/builds/484566481#L2038

darwin22:01:00

ok, second attempt worked: https://travis-ci.org/cljs-oss/canary/builds/484569128 still I think I’ve seen that error before…