This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-25
Channels
- # aleph (12)
- # announcements (2)
- # beginners (40)
- # calva (8)
- # cider (26)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (122)
- # clojure-dev (9)
- # clojure-europe (2)
- # clojure-nl (2)
- # clojure-spec (42)
- # clojure-uk (20)
- # clojurescript (86)
- # cursive (15)
- # data-science (1)
- # datomic (42)
- # duct (4)
- # emacs (33)
- # events (1)
- # figwheel-main (2)
- # fulcro (33)
- # jobs (2)
- # jobs-discuss (46)
- # kaocha (13)
- # leiningen (9)
- # off-topic (62)
- # pathom (75)
- # quil (2)
- # re-frame (6)
- # reagent (13)
- # reitit (3)
- # shadow-cljs (52)
- # spacemacs (3)
- # specter (17)
- # sql (6)
- # tools-deps (2)
- # vim (3)
- # yada (28)
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.
1
{:tag :out, :val "{:tag :ret, :val \"1\", :ns \"cljs.user\", :ms 7, :form \"1\"}\r\n"}
as expected the outer prepl re-encodes whatever the CLJS loop does given that it just communicates over *out*
yeah typically the model for shadow-cljs was to only have one socket port open which starts in CLJ mode
would be nice if there was a *out-fn*
binding that could be re-used to send msgs directly without going through *out*
@thheller did you try to change the ClojureScript pREPL :val-fn
so the outer pREPL gets what it expects
I'm overthinking it really .. tools are probably going to stick with nrepl for a while
you might find this helpful: https://github.com/clojure/clojure-site/blob/master/assets/images/content/reference/prepl/prepl.png
(I have not yet gotten around to writing the accompanying words that go with the picture)
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
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
@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)
@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)
New section mentioning clojure.edn
: https://github.com/clojure/clojurescript-site/blob/news-next/content/news/2019-01-04-release.adoc#clojureedn-namespace
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
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.
like it would think that target is nodejs, but none of my compilations are targeting node
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
yep, travis has a bad day 😞 https://travis-ci.org/cljs-oss/canary/builds/484561888#L534
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
ok, second attempt worked: https://travis-ci.org/cljs-oss/canary/builds/484569128 still I think I’ve seen that error before…