This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-21
Channels
- # admin-announcements (2)
- # aws-lambda (2)
- # beginners (26)
- # boot (179)
- # cider (36)
- # cljs-dev (118)
- # cljsrn (23)
- # clojure (150)
- # clojure-android (1)
- # clojure-austin (7)
- # clojure-austria (3)
- # clojure-canada (1)
- # clojure-dev (7)
- # clojure-dusseldorf (4)
- # clojure-germany (3)
- # clojure-greece (34)
- # clojure-nl (4)
- # clojure-quebec (9)
- # clojure-russia (30)
- # clojure-spec (38)
- # clojure-uk (3)
- # clojurescript (46)
- # clr (1)
- # core-async (2)
- # css (2)
- # cursive (17)
- # datomic (12)
- # devcards (8)
- # dirac (1)
- # docker (2)
- # hoplon (216)
- # jobs (2)
- # kekkonen (1)
- # lein-figwheel (18)
- # leiningen (2)
- # luminus (1)
- # mount (4)
- # off-topic (2)
- # om (15)
- # onyx (1)
- # parinfer (1)
- # pedestal (2)
- # planck (26)
- # reagent (98)
- # spacemacs (6)
- # specter (19)
- # spirituality-ethics (54)
- # untangled (22)
- # vim (24)
- # yada (4)
@dnolen: another thing to consider along these lines, is a simple build-api/input
function to help supply the clojurescript source of a whole namespace directly to the compiler. AFAIK, currently, it's a little tricky to do this, so I'm creating a temp file.
Being able to provide the raw source for a namespace, would make much easier to dynamically inject initialization without needing to create a file. Combining this with :preload
should cover 99% of behavior injection.
if we were able to inject the source code of a namespace there we could inject all the initialization config we need
I didn't have anything like lein plugin in mind, I think I can config my tool in two ways: a) closure-defines b) env variables
with lein plugin you could serialized whole :figwheel, pass it into closure-define and unserialize it in your init namepspace
env variables approach is more tricky, you could use clojure macro to read env setting and then emit it into cljs source code
this works for simple config values, but wouldn't be as expressive as a whole namespace
I agree, generated namespace would be very flexible, but I’m a bit afraid about error feedback when something goes wrong, fishing for non-existent files is no fun
so your tool could read the environment vars and then
"(ns mybooting.tools (:require cljs-devtools))
(cljsdevtools/start {:confg value-from-env})"
as I said, I could encode arbitrary complex config as json/edn, but then I would need a lein-plugin to make people’s lives easier to deal with it
@dnolen: thinking about closure defines, would be handly if not only strings were supported, if you pass edn as a value, clojurescript compiler would serialize it as a string when emitting as CLOSURE_UNCOMPILED_DEFINES
here it would do more work, https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1368
Cool a list or a vector https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L556
oh, wait, maybe it works? arbitrary nested edn will be just emitted as a corresponding json?
could we adopt a convention, something along these lines: for any [key value] in (:closure-defines opts)
whose value does not serialize to {string|number|boolean} we emit two new goog defines with following convention:
[key (pr-str value)] and [(str key “_edn”) true]
this way I could do in my code test for devtools.config_edn, and if it is ideed edn, I can unserialize
I’m probably not going to write lein-plugin to do the string serialization on user’s behalf
are you familiar with :closure-defines
compiler option? https://github.com/clojure/clojurescript/wiki/Compiler-Options#closure-defines
I would like to see people use one key “devtools.config” to pass me whole devtools config
@darwin overloading :closure-defines
is just not the way to do this - :closure-defines
is really for controlling Closure defines / dead code elimination
would be a pretty easy way to contribute and would greatly streamline onboarding new would be compiler hackers
will probably wait till 1.9.0 final before considering them seriously - but just putting it out there if anyone is interested in taking them on when we get there
landed :preloads
https://github.com/clojure/clojurescript/commit/d187ad73ef673c3b1b0c3fe6b9ad3eb944057c3c
I’m excited about it, btw. this is how easy it was to introduce preload ns in cljs-devtools
https://github.com/binaryage/cljs-devtools/commit/26736b0ae71399a9cd24a03f82dacc86f705221c
btw. @bhauman proposed :tooling-config
convention, so figwheel can be less strict about libraries under that key and still strictly validate everything else
I confirm that 1.9.85 works for me as expected: https://github.com/binaryage/cljs-devtools/commit/03c4f6cf4d1fc14ba431f4567891a3d8997858de
@dnolen: maybe I hit an issue with :preloads, if my preload namespace requires other namespaces those do not appear in cljs_deps.js, so goog module system does not know about them
btw. just found a promising hack, how to enable long stack-traces in core.async + Chrome DevTools: https://dl.dropboxusercontent.com/u/559047/core-async-long-stack-traces.png
current behaviour: https://dl.dropboxusercontent.com/u/559047/core-async-normal-traces.png
it is not super useful ATM, because maxAsyncStackChainDepth is currently hard-coded in DevTools and set to only 4, which is not enough for more complex core.asyn code: https://github.com/binaryage/dirac/blob/devtools/front_end/sdk/DebuggerModel.js#L200 but in Dirac I will able to lift in and maybe walk the call stack in a better way, so loops won’t create long stack traces