This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-13
Channels
- # beginners (42)
- # boot (33)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # clojars (3)
- # clojure (207)
- # clojure-boston (1)
- # clojure-france (3)
- # clojure-india (7)
- # clojure-miami (1)
- # clojure-nl (8)
- # clojure-poland (13)
- # clojure-russia (102)
- # clojure-spec (22)
- # clojure-uk (37)
- # clojureremote (15)
- # clojurescript (229)
- # cursive (9)
- # datomic (1)
- # emacs (7)
- # figwheel (2)
- # funcool (1)
- # garden (1)
- # hoplon (7)
- # jobs (12)
- # jobs-discuss (27)
- # juxt (2)
- # leiningen (6)
- # luminus (9)
- # lumo (18)
- # off-topic (3)
- # onyx (9)
- # re-frame (54)
- # reagent (5)
- # remote-jobs (3)
- # ring (3)
- # rum (3)
- # specter (28)
- # yada (30)
and why do we need to specify :requires
if a lib has a dep? does this affect ordering in the compiled src?
@devth :foreign-libs
do not go through closure, so no effect on advanced compilation
:requires
is for dependency ordering yes but only amongst the foreign libs themselves.
@thheller so it means that it makes no sense to add externs to :foreign-libs? I've used :foreign-libs a lot, but always provided externs, just assuming that it's needed.
@hlolli no they are necessary. they are used by closure to prevent renaming of the foreign things you use.
@thheller ah ok, so no dead-code elimination I assume, wich makes sense to add :file-min.
@john last time I'll mention this but you are doing things that cannot possibly work in :advanced
or even anywhere else really. you cannot just hack the JS side without telling the compiler about it.
@thheller thanks. so when you specify :file-min
, does it include the min version instead of the file
when advanced is on? seems like that would totally mess up externs. trying to debug why js for one lib is completely broken when advanced is on.
it is used if specified under :advanced
and :simple
https://github.com/clojure/clojurescript/blob/10fc3ce9580d3d4758b5c5b95992ab343deb24a7/src/main/clojure/cljs/closure.clj#L1771-L1772
macbook has frozen up completely requiring hard reboot twice in the last 2 days while running advanced compilation locally 😪
@devth neither :file
nor :file-min
has any impact on what :advanced
is doing. only the :externs
do. :file
or :file-min
are just prepended after closure has done its thing.
try compiling with :pseudo-names true
in :advanced
to see if you can track down the problem
at findScrollParents (superadmin.js:1969)
at new Drop (superadmin.js:34714)
at Menu.componentDidUpdate (superadmin.js:34249)
at r.notifyAll (superadmin.js:24)
at r.close (superadmin.js:26)
at r.closeAll (superadmin.js:27)
at r.perform (superadmin.js:27)
at o.perform (superadmin.js:27)
at o.perform (superadmin.js:27)
at Object.D [as flushBatchedUpdates] (superadmin.js:27)
compile with :pseudo-names
and :pretty-print
and :source-maps
otherwise this is going to be hard to track down
if it comes from an external minified foreign lib, i don't know how cljs compiler settings could help
can you show some code where you are calling into the grommit lib? or the grommet lib calls you?
this calls my wrapper:
(def header
#?(:cljs (js/React.createFactory (.-Header js/grommet))
:clj factory-shim))
Uncaught TypeError: Cannot read property 'parentNode' of null
at findScrollParents (superadmin.js:1969)
at new Drop (superadmin.js:34714)
at Menu.componentDidUpdate (superadmin.js:34249)
at r.notifyAll (superadmin.js:24)
at r.close (superadmin.js:26)
at r.closeAll (superadmin.js:27)
at r.perform (superadmin.js:27)
at o.perform (superadmin.js:27)
at o.perform (superadmin.js:27)
at Object.D [as flushBatchedUpdates] (superadmin.js:27)
findScrollParents @ superadmin.js:1969
Drop @ superadmin.js:34714
componentDidUpdate @ superadmin.js:34249
notifyAll @ superadmin.js:24
close @ superadmin.js:26
closeAll @ superadmin.js:27
perform @ superadmin.js:27
perform @ superadmin.js:27
perform @ superadmin.js:27
D @ superadmin.js:27
closeAll @ superadmin.js:27
perform @ superadmin.js:27
batchedUpdates @ superadmin.js:26
a @ superadmin.js:27
dispatchEvent @ superadmin.js:26
found this externs – https://raw.githubusercontent.com/Codamic/packages/30cb37269a94fe7f9312498b76ab3fef23647b11/grommet/resources/cljsjs/grommet/common/grommet.ext.js – i'm going to try it
yeah. i thought mine covered everything but i don't know how to definitively determine that.
@devth in the example above so grommet.Header = function() {};
is in your extern file?
it worked in the past when we were on previous versions. hadn't deployed in a long time (not in prod yet) so things got stale.
does that mean this one is wrong too? https://raw.githubusercontent.com/Codamic/packages/30cb37269a94fe7f9312498b76ab3fef23647b11/grommet/resources/cljsjs/grommet/common/grommet.ext.js
I would examine other externs file like the one for React and follow the conventions very closely
you don’t need the typing bits but the structure of the code should be exactly the same
gonna try a build with https://raw.githubusercontent.com/Codamic/packages/30cb37269a94fe7f9312498b76ab3fef23647b11/grommet/resources/cljsjs/grommet/common/grommet.ext.js
@devth in general popular CLJSJS libs are safer since they’ve already worked through these issues
:cache-analysis false
:pretty-print true
:pseudo-names true
:optimizations :advanced
:source-map "resources/public/js/superadmin/superadmin.js.map"
:elide-asserts true
:compiler-stats true
:parallel-build true
:foreign-libs [{:file "resources/public/js/libs/grommet.js"
;; :file-min "resources/public/js/libs/grommet.min.js"
:provides ["grommet"]}
ah if I don't include it in foreign-libs it can't find the grommet
namespace that my wrapper requires: (:require #?(:cljs grommet)
actual error is Caused by: clojure.lang.ExceptionInfo: No such namespace: grommet, could not locate grommet.cljs, grommet.cljc, or Closure namespace "grommet"
during compile
actually the inferred externs look right:
var grommet;
grommet.Paragraph;
grommet.Search;
grommet.DateTime;
grommet.TextInput;
grommet.Select;
grommet.FormField;
grommet.App;
grommet.Footer;
grommet.Button;
grommet.Split;
grommet.Label;
;
grommet.Login;
grommet.Table;
grommet.Heading;
grommet.Header;
do i have to tell cljs to use the inferred_externs.js file or does it pick it up automatically?
Maybe problem with React.createFactory
?
minified version available at https://cdnjs.com/libraries/grommet
this is the src for grommet that i use https://gist.githubusercontent.com/devth/47133694a45a7f220e5a1feeabfb5a27/raw/378411c9bb0ce0f2e809c81579dae6d287e4099e/grommet.js
to confirm i'm not crazy, i just re-built with no optimizations and everything works fine.
Would more experienced ClojureScript folks agree with the following statement? >Languages with totally different syntax and semantics, like ClojureScript, are difficult to debug, even when source maps are working perfectly. Source: https://medium.com/@tomdale/glimmer-js-whats-the-deal-with-typescript-f666d1a3aad0
@thheller Can you elaborate? Was there any pain points with debugging cljs code from your experience?
confirmed the problem was old version of react being required by devcards 😫 thx for the help @thheller @dnolen
@rinaldi statement about technology X from people who don’t use technology X usually aren’t worth serious consideration
@rinaldi source mapping was the one of most requested early features and adoption skyrocketed after it’s implementation
it’s not perfect by any means but it works quite well in my experience, the exception being core.async heavy code
source maps work quite well, except for these cases: https://bugs.chromium.org/p/chromium/issues/detail?id=687772
I don’t have a nice repo cases, usually I hit the bugs when doing some other stuff and then tried to debug them in Dirac and discovered those are actually devtools issues
I think devtools devs don’t hear about them because those are corner cases exposed by ClojureScript, so not that many people report them
but they are definitely real and devtools devs assigned the bug priority-1 which speaks for itself 🙂
I have one issue where a source map is off by one line nothing too bad but confused me at one point
you are most likely hitting this issue: https://github.com/binaryage/dirac/commit/adba5772a7f9969ba70f3707c89afc624a52da24
the problem is that that bug does not make it fail, it just causes wrong source-maps lookups, which is quite confusing
is the module-type for :npm-deps in clojurescript 1.9.518
automatically recognized? Having problems with {:monaco-editor "0.8.3"}
currently I have an ugly require mounting our app in a callback, like
(js/require (array "vs/editor/editor.main")
#(do
(re-frame/clear-subscription-cache!)
(r/render [app]
(.getElementById js/document "app"))))
@denik there are several open issues on the monaco editor project about AMD/common.js builds
@thheller btw. my yesterday’s solution failed due to this assumption: https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/optional.cljs#L11-L12, when cljs-devtools is used as a library via dependencies it does not compile that file
so I’m out of ideas, I cannot use a macro to generate my ns form depending on compiler options, that is not possible because I don’t have a way how to import the macro 😉
any ideas how I could :require a library depending on compiler’s :optimizations
settings?
as I said you are trying to solve a problem the user needs to solve IMHO. there is nothing you can do if they decide to include cljs.pprint for example.
I was thinking about adding a warning to :release
builds that include certain namespaces
thanks, I agree, my solution was an overkill, I ended up just issuing a warning: https://github.com/binaryage/cljs-devtools/releases/tag/v0.9.3
@darwin probably simpler to just require it but make the ns empty if you’re compiling :advanced
@dnolen I need to optionally include cljs.pprint
only in non-advanced mode, so I cannot make it empty, I would have to fork it
just to clarify: “I” as a library don’t have control over compiler options or source-paths, I can only observe them in a macro
maybe using two ns forms in a single file? the first one would require the macro and the second one would be generated by the macro, would that work?
I mean, people should not leave any traces of cljs-devtools in :advanced build, because then it will require cljs.pprint and potentially bloat their optimized build
I wonder if something could be defined in the &env
macro data (or via a similar approach) for something like detecting :advanced
? Thinking about how macrovich works, though it seems mildly hacky
Eg https://github.com/cgrand/macrovich/blob/master/src/net/cgrand/macrovich.cljc#L23-L28
@timgilbert https://github.com/binaryage/cljs-devtools/blob/33da7b28506491d002d9cb8a852e6b9eaed181a7/src/lib/devtools/compiler.clj#L17
Oh, I think I see what the problem is now, yeah. You want to rewrite all references to pprint out of your ns trees under :advanced
.
@timgilbert not really rewrite, even if I don’t call anything from cljs.pprint
, just the fact that I put it into :require
in any of my ns-es causes :advanced
build to bloat
In cljs-devtools case pprint
is nice-to have, so I can dynamically decide to use it, if it is present - that is an easy part, the problem is that I cannot decide to require it or not based on compiler options
Gotcha. And a wrapper macro won't help you because the "include pprint" branch will be in the whole ns tree somewhere even if advanced is on
I cannot write (my-macro (ns …))
because my-macro is not known before the ns-form is processed
In Clojure I'd probably use a runtime (require)
statement vs an ns form but I'm guessing that's not workable for the cljs compiler?
but I’m pretty ok with this compile-time warning solution at this moment, don’t want to spend more time on it, frankly
but it would be nice to have some mechanism to optionally require stuff based on compiler options, now in the light of these DCE issues (they are in cljs’s own namespaces like cljs.pprint
or even in goog closure library like goog.userAgent
)
hello all, how does one check for the value null in CLJS ?
and I mean js/null
not cljs/nil
/ (lmk if that makes sense)
but that tells you if a value is nil no ? or are null and nil the same thing?
so technically speaking both js/undefined
and js/null
will be considered as nil values by the nil?
predicate
thanks @darwin