This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-17
Channels
- # bangalore-clj (1)
- # beginners (70)
- # boot (1)
- # cider (39)
- # cljs-dev (69)
- # clojure (56)
- # clojure-dev (1)
- # clojure-norway (1)
- # clojure-russia (4)
- # clojure-spec (1)
- # clojure-uk (10)
- # clojurescript (34)
- # clr (3)
- # community-development (3)
- # component (1)
- # datascript (1)
- # datomic (7)
- # emacs (1)
- # figwheel (3)
- # fulcro (5)
- # graphql (2)
- # hoplon (75)
- # jobs (4)
- # jobs-discuss (1)
- # luminus (15)
- # planck (3)
- # portkey (55)
- # re-frame (2)
- # reagent (2)
- # reitit (3)
- # ring (13)
- # ring-swagger (1)
- # shadow-cljs (72)
- # spacemacs (4)
- # tools-deps (2)
- # unrepl (7)
- # vim (2)
got a simple proof of concept of Java_WebSocket with weasel going: https://github.com/johnmn3/weasel
It's fairly broken at the moment, as I'm contemplating adding the multi-connection feature
But this is more of an exercise to see if this java lib can work as a repl, so I'm not sure how much further I'm going to take this experiment
Oh, to run it, you've gotta lein install
on the project dir first and then cd weasel-example/ && lein cljsbuild once && lein repl
Nice, this will also preserve the performance of apply
by avoiding the extra type
check.
@dnolen testing 1.10.191, I get a lot of infer-externs warnings a la “Cannot resolve property value for inferred type” which I didn’t get with .145
hmm, with a simple clj -m cljs.main
and when using chrome, browser launches, eval a form, click reload on the page. Try evaling a form again, hangs... Trying in a fresh dir now.
@dnolen when you get a chance to check out https://github.com/johnmn3/weasel, is there any further work I can do on there that would be helpful to https://dev.clojure.org/jira/browse/CLJS-2626 ? If it's too complicated an not a priority atm I can get back to you after the next release.
@john it looks fine, just put together a patch, we can prioritize for the release after next
k @bhauman has also volunteered to help guide my implementation in the right direction, so hopefully we'll have something pretty robust
after subsequent compiles the browser will not connect and the console error is goog.require could not find: clojure.browser.repl.preload
clj -m cljs.main -w src -e "(require '[figwheel.core :include-macros true])(figwheel.core/hook-cljs-build)(figwheel.core/start-from-repl)" -r
I personally like the new accept function, you can just pass the node one with no cljs.main
or other params and connect
@richiardiandrea not sure what you mean by accept function
Sorry yeah :)
@bhauman in fighweel.core
you should #?(:cljs (:require-macros [figwheel.core]))
so you can omit the :include-macros true
when requiring it.
I was checking that just some minute ago and it seems some refactoring would be necessary for generalizing all these small pieces to all repls...maybe less than I think 😄
@dnolen Suspect a regression related to concurrency https://dev.clojure.org/jira/browse/CLJS-2672
FWIW, I have a ticket in regarding specifying cljs.main
compiler opts in a clj
alias: https://dev.clojure.org/jira/browse/TDEPS-56
I have code splitting working great when loading the splits via script tags on my index page, however there seems to be an issue with cljs.loader
for dynamically loading splits. Before I dig too much further into the compiler, I want to make sure I'm doing this right. Theoretically loading the generated cljs_base.js
file should load all dependencies of the :cljs-base
module split, correct? The set of dependencies that are actually loaded by cljs_base.js
and the uris that cljs.loader/module-uris
(MODULE_URIS) expects to be there for :cljs-base
doesn't line up.
I believe the issue here is with my requiring cljs dependencies that require google closure dependencies. (cljs-time -> goog.date.DateTime, etc. in this case)
Is cljs.loader
considered stable? I'm in pretty far over my head.
Also, to get dynamic loading working in the first place, I had to set goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING
to true, due to document.write
not working after the page is loaded. Is that expected?
It should be noted that all of this is with :optimizations :none
. I believe things are working with :advanced
. I could certainly forgo code splitting in development and just have them in production with :advanced
optimizations.
@dnolen I've been testing with 1.10.191. I'm assuming that fix would be in there?
people are using this now under :none
and :advanced
and I haven’t seen this report before
cljs.loader
is stable and what you’re reporting would mean whats there just isn’t working
@dnolen Alright, thanks. I'll put together an minimal example sometime soon.
I'm probably just doing something incorrectly.
make something minimal and we’ll see - if there’s an issue, probably very simple to fix
I suspect if we crack https://dev.clojure.org/jira/browse/CLJS-2646, it will ultimately cut down on unnecessary compilation, further speeding things up (perhaps also fixing things like https://dev.clojure.org/jira/browse/CLJS-2671)