This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-11
Channels
- # aleph (3)
- # beginners (42)
- # cider (219)
- # cljs-dev (39)
- # cljsjs (19)
- # cljsrn (3)
- # clojure (97)
- # clojure-canada (12)
- # clojure-dev (14)
- # clojure-italy (5)
- # clojure-nl (4)
- # clojure-russia (1)
- # clojure-spec (3)
- # clojure-uk (140)
- # clojurescript (52)
- # clojutre (2)
- # cursive (2)
- # datomic (29)
- # docs (1)
- # duct (13)
- # emacs (19)
- # fulcro (8)
- # funcool (2)
- # graphql (26)
- # hyperfiddle (1)
- # luminus (9)
- # nyc (7)
- # off-topic (26)
- # om (21)
- # onyx (19)
- # overtone (1)
- # pedestal (4)
- # re-frame (10)
- # reagent (109)
- # ring (5)
- # rum (15)
- # shadow-cljs (120)
- # spacemacs (22)
- # specter (7)
- # vim (10)
hi, what’s a good way to handle config stuff that varies across environments? say dev vs production api endpoints,
@eoliphant I'm useing webpack with shadow since recently, and there I can do something like this in plugins, reading from environmental variables
new webpack.DefinePlugin({
'DEVELOPMENT': JSON.stringify(process.env.NODE_ENV === 'development'),
}),
then I can see if I'm in development mode
(def dev? js/DEVELOPMENT)
some plugin like this may exists with other means.I see this for the build itself https://shadow-cljs.github.io/docs/UsersGuide.html#_release_specific_vs_development_configuration wondering if I can use that plus the build hooks
ah, read right past this.. https://shadow-cljs.github.io/docs/UsersGuide.html#closure-defines
sometime you just need to talk stuff thrugh lol. I literally read past this twice lol
I've read past this more than twice, and finally it clicked now in my brain what it's used for.
:closure-defines
is a good option, you can also use https://shadow-cljs.github.io/docs/UsersGuide.html#_conditional_reading or combine both
when I see this line <- Cache write: seekeasy/upload.cljs (4825 ms)
does that mean it is taking 4.8 seconds just to write a single file to disk or does that include some kind of wait time for other writes too?
4,8sec to write the Cache for that file only. does not include any other time. how big is that file?
thats weird. I have never seen this get slower over time. can you check how big .shadow-cljs/builds/<your-build>/dev/ana/seekeasy/upload.cljs.cache.transit.json
is?
there’s just pages and pages of this kind of stuff "^2I","^2D","^43","^44","^5W","^6R"
<mailto:[email protected]|[email protected]> or a gist
okay sent. it took me a really long time to remember how to show a freaking dotfile in mac haha
thx checking it out. now you can try restarting the server and recompiling that file
just to rule out outside factors: do you use pure shadow-cljs.edn or lein/tools.deps?
:dependencies
[[org.clojure/clojure "1.9.0"]
[org.clojure/clojurescript "1.10.238"]
[com.bhauman/spell-spec "0.1.1"]
[expound "0.7.1"]
[metosin/spec-tools "0.7.1"]
[gnl/ghostwheel "0.2.2"]
[org.clojure/test.check "0.9.0"]
[reagent "0.7.0"]
[secretary "1.2.3"]
[venantius/accountant "0.2.3" :exclusions [org.clojure/tools.reader]]
[funcool/promesa "1.9.0"]
[cljs-ajax "0.7.3"]
[com.rpl/specter "1.1.0"]]
module$node_modules$react_dom$lib$reactProdInvariant
module$node_modules$react_dom$lib$ReactPropTypesSecret
module$node_modules$prop_types$factory
module$node_modules$react$lib$React
module$node_modules$fbjs$lib$invariant
module$node_modules$fbjs$lib$warning
shadow.js
module$node_modules$react_dom$lib$reactProdInvariant
module$node_modules$react_dom$lib$ReactPropTypesSecret
module$node_modules$prop_types$factory
module$node_modules$react$lib$React
module$node_modules$fbjs$lib$invariant
module$node_modules$fbjs$lib$warning
these are supposed to be distinct. checking why they are repeated over and over again
hi *. n00b q's: decided to try to build an app on shadow-cljs today. used the
lein new shadow-cljs 8bs-vision-survey +reagent
template. according to the readme it has the following commands: yarn install, yarn watch, yarn clean, yarn release
the shadow-cljs.edn file looks like this ;; shadow-cljs configuration
{:source-paths
["src"]
:dependencies [[binaryage/devtools "0.9.7"]
[reagent "0.8.0-alpha2"]
[org.clojure/core.async "0.4.474"]
[com.pupeno/free-form "0.6.0"]
[cljs-http "0.1.45"]
[com.cemerick/url "0.1.1"]]
;; set an nrepl port for connection to a REPL.
:nrepl {:port 8777}
:builds
{:app {:target :browser
:output-dir "public/js/compiled"
:asset-path "/js/compiled"
:modules
{:main
{:entries [vision-survey-8bs.core]}}
:devtools
;; before live-reloading any code call this function
{:before-load vision-survey-8bs.core/stop
;; after live-reloading finishes call this function
:after-load vision-survey-8bs.core/start
;; serve the public directory over http at port 8700
:http-root "public"
:http-port 8700
:preloads [devtools.preload]}
}}}
got it working while developing and decided to deploy the app. i ran yarn release
and deployed the public folder to a server. the app runs but only displays the placeholder page with "Shadow-cljs rocks!" - text. any pointers how to fix it?@lee.justin.m trying to figure out how this happens over time. do you have one watch
running for very long times (days) or do you restart frequently?
i see, so i have certain utility files that everything depends on. when i touch those files, all of the cache files increase in size
@lee.justin.m should be fixed in 2.4.20
. pretty obvious bug when looking at it. to the degree that I can't figure out how caching works at all. that should really have invalidated the cache all the time.
ok. so got the path working but there is another error "SyntaxError: identifier starts immediately after numeric literal" referring to the line
<script>vision-survey-8bs.core.init();</script>
at the end of the index document. so no numbers allowed in function names?@sakalli that is javascript where -
is actually minus
. must "munge" the name to use _
instead. <script>vision_survey_8bs.core.init();</script>
The Six Stages of Debugging:
1. That can't happen.
2. That doesn't happen on my machine.
3. That shouldn't happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?
@lee.justin.m thanks for the report and the files. would have taken ages to debug without.
is there a hack to munge it other than manually or fixing the whole app (which is quite some work since this name is in the directory structure and all over the app). very little js experience.
@sakalli what do you mean? the CLJS compiler does that automatically. you just need to do it once in the HTML when calling the init
function.
when it doesn't work after changing the _
you just might be missing the important ^:export
bit on the (defn ^:export init [] ...)
@thheller thank YOU for being such a freaking wizard. the fix appears to be working for me
now i think i’m going to have to ditch ghostwheel because it is basically has to be recompiled anytime i change any file. i’d rather have subsecond turnaround i think
on a project of considerable size it must be very frustrating to iterate on utility files as the whole world has to be recompiled
i guess i’m just not sure why, for example, ghostwheel/core.cljc
has to be recompiled when I change file A, which includes file B, which uses ghostwheel, even though B and ghostwheel don’t change
i have fantasies about creating some kind of build system that loads everything up and creates a granular database of functions and macros and transcends the concept of a file. then we can all ascend into developer heaven
oh well if that’s a bug then that’d be a good thing. i thought it was just something inherent to the messiness of macros
oh right. whole lots of magic macros. still shouldn't recompile ghostweel.core
if you touch a namespace that requires it though
If I may chime in – ghostwheel really shouldn't be recompiled every time you just change a namespace which uses it, I would definitely consider this a bug, although not yet sure where. I don't think I've ever witnessed that, but I'll look into it on my end, see if I can reproduce it.
Are you somehow directly referencing the actual ghostwheel source in your project – for example by adding the cloned repo to your source paths or something – or just using the clojars artifact?
@lee.justin.m does this still happen in 2.4.20
? I can totally see this happening with the older versions
@lee.justin.m Okay, try 0.2.3-SNAPSHOT
This is embarrassing – I had ^:dev/always
set on the tracing namespace (leftover from development) and ghostwheel.reporting+ghostwheel.core depend on it, so there's a whole lot of unnecessary work being done.
and now that we’ve fixed the shadow-cljs bug, my 14s builds are less than 1s too 🙂
@thheller one thing: when i updated the version of ghostwheel in shadow-cljs.edn
, it kicked off a recompile, but it didn’t actually download new artifacts. is that intended?
@lee.justin.m I just went through the six stages of debugging you described above in like 15 seconds.
@lee.justin.m recompile should only happen if the build config changed. only :dependencies
should not trigger it. downloading new artifacts is only done of startup since doing that at runtime is way too complicated
okay cool. the recompile must have been because i hadn’t saved some other file because it isn’t doing it now.
@lee.justin.m – if you run into anything like this again, please let me know. Ghostwheel's runtime overhead should be zero and the recompile overhead virtually zero (the code generation here is really not particularly complex or expensive), unless you enable tracing and/or gen-testing on hot-reload, which will of course slow things down.
@clojurians.net cool thanks. i’m still not 100% on how the compiler works so i’m never quite sure if there’s an issue. it’s a real delight to deal with folks like you and @thheller so thanks for that