Fork me on GitHub
#cljs-dev
<
2018-03-17
>
john01:03:48

got a simple proof of concept of Java_WebSocket with weasel going: https://github.com/johnmn3/weasel

john01:03:21

It's fairly broken at the moment, as I'm contemplating adding the multi-connection feature

john01:03:45

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

john01:03:08

Oh, to run it, you've gotta lein install on the project dir first and then cd weasel-example/ && lein cljsbuild once && lein repl

dnolen10:03:00

Just cut 1.10.191, please test when you get a chance

rauh10:03:08

Nice, this will also preserve the performance of apply by avoiding the extra type check.

kommen10:03:36

@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

john11:03:28

tested on 2 projects here. No changes in behavior thus far.

john11:03:23

just tested on one of our more massive projects from work. No complaints.

john11:03:58

at least, for just just compiling and launching the app

john11:03:14

That's about 60 cljs files, mostly around a re-frame setup

john12:03:52

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.

john12:03:29

oh, that's known behavior here, right?

john12:03:44

we're not dealing with reload here

dnolen12:03:02

no we do not reconnect on reload of the page

dnolen12:03:09

what was happening before was incorrect, you can suppress those if you like

john12:03:50

@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.

dnolen12:03:57

@john it looks fine, just put together a patch, we can prioritize for the release after next

john12:03:14

k @bhauman has also volunteered to help guide my implementation in the right direction, so hopefully we'll have something pretty robust

mfikes13:03:55

Successfully tried 1.10.191 on 3 downstream non-trivial projects.

mfikes13:03:37

Kicked off Canary as well; it looks good.

rauh13:03:22

Same here. All good with master.

bhauman14:03:24

alright I'm experiencing a consistent bug when using cljs.main

bhauman14:03:15

clj -e -m cljs.main -w src -c example.core -r

bhauman14:03:37

if I compile like that 2 times and then rm -rf out

bhauman14:03:30

after subsequent compiles the browser will not connect and the console error is goog.require could not find: clojure.browser.repl.preload

bhauman14:03:41

this is very consistent behavior

bhauman14:03:37

apparently goog.getPathFromDeps_("clojure.browser.repl.preload") is failing

bhauman15:03:48

trying to make the example more minimal now

bhauman15:03:38

yeah unable to reproduce reliably

bhauman15:03:05

but :aot-cache false appears to fix it in my more complex setup

bhauman16:03:55

but dang this is cool:

bhauman16:03:59

clj -m cljs.main -w src -e "(require '[figwheel.core :include-macros true])(figwheel.core/hook-cljs-build)(figwheel.core/start-from-repl)" -r

bhauman16:03:55

gives a pretty complete figwheel experience

bhauman16:03:24

cljs.main is so dang helpful

richiardiandrea17:03:46

I personally like the new accept function, you can just pass the node one with no cljs.main or other params and connect

bhauman17:03:37

@richiardiandrea not sure what you mean by accept function

dnolen17:03:47

Socket REPL

bhauman17:03:11

oh makes sense

thheller17:03:31

@bhauman in fighweel.core you should #?(:cljs (:require-macros [figwheel.core])) so you can omit the :include-macros true when requiring it.

dnolen19:03:12

Socket REPLs connecting to Browser REPL now redirect out properly on master

richiardiandrea19:03:27

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 😄

mfikes19:03:47

@dnolen Suspect a regression related to concurrency https://dev.clojure.org/jira/browse/CLJS-2672

dnolen20:03:41

@mfikes actually just a missing nil check

john20:03:30

repl never starts for me

john20:03:12

disregard

dnolen20:03:45

There’s definitely a bug

dnolen20:03:12

We need to check that :repl isn’t nil in :print path in browser REPL

john20:03:40

yup same error repros here

mfikes20:03:39

@dnolen Confirmed and closed CLJS-2672 👍

mfikes20:03:15

FWIW, I have a ticket in regarding specifying cljs.main compiler opts in a clj alias: https://dev.clojure.org/jira/browse/TDEPS-56

Garrett Hopper20:03:52

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.

Garrett Hopper20:03:17

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.

dnolen21:03:16

There was a bug around this fixed in master

Garrett Hopper21:03:48

@dnolen I've been testing with 1.10.191. I'm assuming that fix would be in there?

dnolen22:03:51

@ghopper then make something minimal that demonstrates the perceived problem

dnolen22:03:19

people are using this now under :none and :advanced and I haven’t seen this report before

dnolen22:03:10

cljs.loader is stable and what you’re reporting would mean whats there just isn’t working

dnolen22:03:29

doesn’t matter what you’re loading, it should work

Garrett Hopper22:03:13

@dnolen Alright, thanks. I'll put together an minimal example sometime soon.

Garrett Hopper22:03:38

I'm probably just doing something incorrectly.

dnolen22:03:48

maybe, maybe not

dnolen22:03:21

make something minimal and we’ll see - if there’s an issue, probably very simple to fix

mfikes23:03:24

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)