Fork me on GitHub
#shadow-cljs
<
2018-07-30
>
prabhath604:07:59

I am having issues connecting to proto-repl in atom. i connected to remote repl and executed (shadow.cljs.devtools.api/nrepl-select :app). Then tried to get into a namespace, but the prompt remains as cljs.user=> it does not change to the new namespace. If i try to access anything from that namespace it returns as nil. Any idea why this is happening. The UI works fine, the only issue is i cannot access anything in repl.

lilactown04:07:12

how are you getting into the namespace?

prabhath604:07:32

(ns lib.data
  (:require [reagent.core :as r]))
pasting this in repl

prabhath604:07:33

This is the .edn file.

caleb.macdonaldblack06:07:33

I’m playing around with shadow-cljs watch in a docker container and the live reload is quite slow (around 10-15 seconds). I have my docker resources at CPUs: 7 and memory: 8.0 GiB. On my mac live reload is usually less than a second. It seems to detect the file changes pretty quickly and then takes forever to compile. Would this be down to docker not being as fast as my mac or something else maybe?

thheller07:07:16

@caleb.macdonaldblack this is usually due to the fs-watch not being slow. you can try setting :fs-watch {:watcher :polling} in your shadow-cljs.edn. at the root not in the build config. should be faster at the cost of more resources used.

thheller07:07:40

if thats not the slow part trying running shadow-cljs watch build --verbose to get more timing infos about where it might be slow

thheller07:07:17

just want to rule it out as a problem

caleb.macdonaldblack07:07:32

I saw the issue with that and ive tried fs-watch already. I think it improved the initial detection but was still otherwise slow to compile

thheller07:07:32

since it has been the most common problem for people running in containers

thheller07:07:56

then please try running with --verbose to see where its slow

thheller07:07:38

@prabhath6 you must always (require 'lib.data) in the REPL first. otherwise (ns lib.data ...) will just set up an empty namespace which won't have any of your functions. to switch to a loaded namespace you should also use (in-ns 'lib.data) instead.

prabhath603:07:41

thanks for the input. It worked. 👍

caleb.macdonaldblack07:07:55

After restarting my laptop my compile times have improved. Ill run locally outside docker and see what I get

thheller07:07:12

@caleb.macdonaldblack which version are you on? there was a cache issue fixed recently that caused cache to get slower over time

thheller07:07:28

it looks like thats whats happening to you there

thheller07:07:44

yeah please try upgrading

thheller07:07:25

it starts out fine but gets slower over time. regardless of running in a container or not.

thheller07:07:53

it was fixed in 2.4.20+

caleb.macdonaldblack08:07:21

We had tried to update briefly in the past but ended up with the above error

caleb.macdonaldblack08:07:31

We ended up just reverting back

thheller08:07:46

@caleb.macdonaldblack remove shadow-cljs, clojure, clojurescript from your deps

thheller08:07:01

oh wait nevermind thats a lein config

thheller08:07:13

yes then bump clojurescript to 1.10.339 as well.

caleb.macdonaldblack08:07:17

That’s with just the cljs bump

thheller08:07:36

did you lein clean just in case?

thheller08:07:03

FWIW try moving shadow-cljs,clojure,clojurescript to the top

caleb.macdonaldblack08:07:19

The ordering seems to have fixed that

😮 4
caleb.macdonaldblack08:07:37

I had know idea the ordering mattered.

thheller08:07:02

yeah transitives dependencies are weird. the first one encountered is chosen, not the latest version. lein doesn't resolve conflicts very well

thheller08:07:17

deps.edn does a better job there

caleb.macdonaldblack08:07:57

Okay so there is a comparison between docker container and my mac

thheller08:07:58

seems like the disk is really slow

caleb.macdonaldblack08:07:05

Also there doesn’t seem to be any difference before and after the update. But based on what you said ealier it seems like the update will help for longer running shadow-cljs processes

caleb.macdonaldblack08:07:38

I am mapping a volume here. I will try in docker without a mapped volume

caleb.macdonaldblack08:07:27

I looks like it’s probably the docker configuration causing the slow downs here.

thheller08:07:30

check how big .shadow-cljs/builds/caleb/dev/ana/medial_web/core.cljs.cache.transit.json is just in case

thheller08:07:09

maybe its getting bigger than it should be? but since its only happening in the container I'm just guessing a slow disk in the container

caleb.macdonaldblack08:07:09

[:caleb] Build completed. (381 files, 2 compiled, 0 warnings, 0.35s) with no mapped volume

caleb.macdonaldblack08:07:39

So I think what Ill do is just map the src directories as read only volumes

caleb.macdonaldblack08:07:51

Should be fast as then

caleb.macdonaldblack08:07:15

As always thanks for your help @thheller. You’re awsome!

😎 8
👍 4
lilactown15:07:55

thheller, do you have a patreon or some other way that we could buy you a lunch / coffee / beer? 😄

thheller16:07:32

I did start to setup a patreon but kinda got stuck since I don't really know what to do with it 😉

richiardiandrea16:07:52

There are also other programs in the crypto space like gitcoin or status's bounty that are interesting and easy to setup - just an FYI

richiardiandrea16:07:19

Different I know but imho more effective than patreon for one time donations

lilactown16:07:24

either way, put it on your github / site and you'll at least get a meal out of me

richiardiandrea16:07:50

More effective because the maintainer can claim the bounty/prize on issue and everybody wins :i_love_you_hand_sign:

kurt-o-sys17:07:25

maybe I'm missing something, but when I do an app release with some specific preloads/`compiler-options`, my app doesn't always seem to run. It runs fine in non-release mode.

{:lein     true
 :jvm-opts ["--add-modules" "java.xml.bind"]
 :nrepl    {:port 3333}
 :builds   {:app {:target           :browser
                  :output-dir       "resources/public/js"
                  :asset-path       "/js"
                  :modules          {:main {:entries [ui-app.core]}}
                  :compiler-options {:closure-warnings {:global-this :off}
                                     :closure-defines  {"re_frame.trace.trace_enabled_QMARK_"        true
                                                        "day8.re_frame.tracing.trace_enabled_QMARK_" true}}
                  :devtools         {:http-root "resources/public"
                                     :http-port 3449
                                     :preloads  [shadow.cljs.devtools.client.hud
                                                 devtools.preload
                                                 day8.re-frame-10x.preload]}}}}
The problem most probably is the re-frame-10x-dashboard/hud. Since I'm not using devtools and dev-mode is off in release mode, there seem to be issues with that dashboard, giving a null where there shouldn't be one. My question actually is: can you make compiler-options specific to the environment. Now, it defines some closure-defines. I'm not sure if that's the problem, switching them off when not in dev-mode, may solve the problem (I think).

lilactown17:07:57

you can set compiler-options based on dev vs release

lilactown17:07:16

there's an example in the user-guide using closure defines: https://shadow-cljs.github.io/docs/UsersGuide.html#closure-defines

kurt-o-sys17:07:33

👍 what I was looking for (I think)

thheller19:07:34

@kurt-o-sys there is also https://shadow-cljs.github.io/docs/UsersGuide.html#_release_specific_vs_development_configuration but I guess the closure-defines chapter covers that more or less too

dnolen21:07:08

I’m getting with familiar with existing shadow-cljs usage on a client project - is in-ns usage supposed to be a bit slow?

thheller21:07:43

not that I know of no?

dnolen21:07:21

hrm I keep seeing it take 4-5 seconds

dnolen21:07:29

and Timeout while waiting for REPL result.

dnolen21:07:42

in the watch terminal I see

dnolen21:07:52

stuff like client sent unknown msg {:type :repl/set-ns-complete, :id 9, :ns ...}

thheller21:07:03

uhm which REPL are you using?

dnolen21:07:08

unrelated - is there any documentation on using shadow w/o nREPL? i.e. I just want to run a shadow-build / REPL via Clojure code, or wire up to Component, yadda, or you are on you own?

dnolen21:07:20

@thheller shadow-cljs cljs-repl ...

thheller21:07:38

see shadow.cljs.devtools.api ns

thheller21:07:56

basically shadow-cljs compile build is identical to calling (shadow.cljs.devtools.api/compile :build)

thheller21:07:04

same for watch/release/etc

dnolen21:07:16

same for REPL?

dnolen21:07:07

k, any insight onto the ns switching issue?

thheller21:07:42

which version are you on?

thheller21:07:43

$ shadow-cljs cljs-repl browser
shadow-cljs - config: /mnt/c/Users/thheller/code/shadow-cljs/shadow-cljs.edn  cli version: 2.4.22  node: v9.4.0
shadow-cljs - connected to server
[1:1]~demo.browser=> (in-ns 'cljs.core)
nil
[1:1]~cljs.core=>

thheller21:07:51

no problem here

dnolen21:07:15

that’s probably it

dnolen21:07:18

2.1.1 I think

thheller21:07:29

uh yeah thats quite old

thheller21:07:43

there was something related a while ago so thats probably it

thheller21:07:35

2.4.24 is current

dnolen21:07:10

k and I see *nrepl-active* is false by default, so I don’t need to worry about it

thheller21:07:20

btw you can totally skip the entire npm shadow-cljs command if you prefer to just use tools.deps + clj

thheller21:07:40

clj -m shadow.cljs.devtools.cli compile build is identical to shadow-cljs compile build

thheller21:07:49

you just miss out on the built-in server mode support

thheller21:07:47

the npm package should still be installed though since it brings in some required deps like source-map-support, node-libs-browser and so on

thheller21:07:27

I'm working on a guide for CLJ users familiar with lein,deps.edn etc

thheller21:07:36

since most of the docs are currently written from the npm perspective

thheller21:07:55

should be done soon. might answer some of questions you probably have right now 😉

dnolen21:07:01

cool, yes that would be useful, but having the api answers a lot of questions

dnolen21:07:09

in-ns issue is gone after bumping - thanks!

Logan Powell21:07:28

are there any disadvantages to using the :lien true setup with Shadow in Cursive/Idea?

Logan Powell21:07:02

btw, very excited to see David Nolen taking interest in Shadow!

thheller21:07:58

I guess dependency management is a bit more complicated. the shadow-cljs command eliminates some of the most common problems which you have to do manually with lein

thheller21:07:14

ie. ensuring compatible clojure,clojurescript,closure-compiler versions etc

thheller21:07:38

beyond that its totally fine and will have the same results

Logan Powell21:07:40

I see, so it would be better to just duplicate the setup with shadow.edn + project.clj

Logan Powell21:07:01

not a big deal at all, just curious

thheller21:07:24

depends. many people like running shadow-cljs embedded in the main CLJ JVM so they only have to worry about running one JVM that does it all

thheller21:07:53

I prefer running things side by side since CLJ and CLJS don't really need anything from each other technically

thheller21:07:10

so if you prefer embedded its easier to just stick with just project.clj

Logan Powell21:07:22

I'm rather new to the entire clj/s game really, so I don't have any legacy preferences

thheller21:07:12

up to your preference I guess. I recommend running shadow-cljs standalone since thats avoid a whole world of potential dependency conflicts

Logan Powell21:07:24

ok, but just to make sure I understand, in the docs https://shadow-cljs.github.io/docs/UsersGuide.html#_cursive it mentions that I can "create a dummy project.clj or use the full Leiningen integration". I'm just trying to understand what the tradeoffs would be

thheller21:07:56

for cursive I usually just do shadow-cljs pom and create a new project from the generated pom.xml

Logan Powell21:07:01

ok, that will handle everything then? (I'm new to Intellij as well... I actually wrote up an entire article about using Shadow with Atom, but Atom couldn't handle the amount of data I was trying to parse 😄 so I had to up my IDE)

thheller21:07:01

I'm working on properly documenting all this stuff. its all a bit lacking at the moment.

thheller21:07:28

yes. its mostly about properly handling dependencies and the pom.xml takes care of that

thheller21:07:43

just need to manually run shadow-cljs pom whenever you change dependencies

Logan Powell21:07:53

no worries, it's a lot to take on, so many different IDEs, but shadow's been working like a charm for me so far (using NPM like a boss), so it's totally worth the time

Logan Powell21:07:02

gotcha, thank you!

👍 4
Logan Powell21:07:07

Sorry, I'm getting Cannot import anything from C:/Users/Surface/Projects/clojure/cljs/census-geojson/pom.xml when trying that

thheller21:07:59

ah. you need to have the maven support plugin active. for some reason that is disabled for some people.

thheller21:07:28

go into the plugin options and install the "Maven Integration" plugin

Logan Powell21:07:13

That seems to have done it