This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-27
Channels
- # bangalore-clj (1)
- # beginners (27)
- # boot (16)
- # cider (14)
- # cljs-dev (94)
- # cljsrn (8)
- # clojure (229)
- # clojure-dev (5)
- # clojure-dusseldorf (6)
- # clojure-italy (8)
- # clojure-norway (8)
- # clojure-russia (22)
- # clojure-sanfrancisco (2)
- # clojure-spec (48)
- # clojure-uk (44)
- # clojurescript (47)
- # core-async (87)
- # cursive (43)
- # datascript (22)
- # datomic (20)
- # defnpodcast (5)
- # emacs (6)
- # hoplon (4)
- # jobs-rus (4)
- # keechma (2)
- # klipse (8)
- # leiningen (2)
- # luminus (2)
- # lumo (14)
- # om (38)
- # onyx (4)
- # overtone (3)
- # pedestal (41)
- # planck (72)
- # powderkeg (42)
- # proton (46)
- # protorepl (9)
- # reagent (9)
- # ring (47)
- # ring-swagger (5)
- # rum (7)
- # sql (22)
- # unrepl (1)
- # untangled (24)
- # vim (19)
- # yada (5)
@martinklepsch looked at your mobiledoc-kit issue and it looks to me like a Closure Compiler bug at this point. Maybe something related to module ordering
what's weird to me is that it says module$....$node_modules$mobiledoc_kit$dist$commonjs$mobiledoc_kit$utils$cursor$position
is not defined
but if you type that in the dev tools console it's there
which makes me think it must be loaded after it's required initially
in fact, if you try to compile with optimizations, it will tell you exactly that:
SEVERE: /Users/anmonteiro/Desktop/modules-playground/out/node_modules/mobiledoc-kit/dist/commonjs/mobiledoc-kit/utils/cursor/position.js:2: ERROR - required "module$Users$anmonteiro$Desktop$modules-playground$node_modules$mobiledoc_kit$dist$commonjs$mobiledoc_kit$utils$cursor$range" namespace not provided yet
> but if you type that in the dev tools console it's there yeah that confused me too
@anmonteiro thanks for looking into that. I’ll try to find out if this is a result of the cyclic requires in those namespaces, seems most likely at the moment… Do you know if there are any restrictions in Closure’s module system with regards to that?
@martinklepsch that shouldn't matter, I think
At least it doesnt in JS, because module requires are cached
Particuarly struck that even when the (and...)
expression in the fn body is known to be bool, yet the analyzer doesn't seem to see that. An outer if
still uses truth_()
so much as the compiler determining some other tag vs. explicit one overriding any inferred thing
we should be doing the later - but maybe my tweaks for JS externs inference changed something
@dnolen that would make sense now that you say it. @darwin mentioned some time ago that the externs inference thing broke something in devtools which was fixed by an explicit boolean type hint
something like that
These days I tend to use macros to emit calls to code which is expected to be (optionally) DCE-ed
I think unexpected prevention of DCE is more general problem, once I hit a problem that only mentioning a function in a static config map literal prevented DCE, although the function was never called - closure compiler didn’t see that, e.g. here: https://github.com/binaryage/chromex/blob/fdd491d1971b152d2d20209a696f15649e10c12a/src/lib/chromex/config.clj#L53-L55
@dnolen also have another question: yesterday I stumbled upon a piece of code that I thought would work but didn’t if you self-`require-macros`, should you expect the macros of that namespace to be automatically referred?
is that because of some technical limitation?
it would seem to me that that would be the next step of the automatic inference stuff
should I make a ticket for it?
@dnolen say you have a foo.core
namespace in Clojure. You’d expect macros you define there to be referred automatically
because it’s the same namespace
the fact that in CLJS it happens in a different compilation step shouldn’t change that, IMO
I’m more concerned about whether doing this automatically is going to break existing programs in weird ways
I don’t really understand the implications
I suppose we could try it out and run it in a few well-known libraries
not high priority anyway
just something that I expected to work and didn't
@anmonteiro what will happen to existing programs that :require-macro
once auto refer like you suggest works?
I was only suggesting it for NSes that use the same name
the only problem I foresee would be shadowing vars
so I guess one example would be cljs.core
, right?
you have or
which is both a macro and a function
will they though?
I don’t see how
@dnolen how is that different from what macro inference does today? (require [foo.core :refer [or]])
@anmonteiro it’s completely different
I’m just talking about making this work if you require-macros
of a namespace with the same name
isn’t that also buying in?
everybody wrote separate macros nses following the lead of the ClojureScript libraries we were releasing
what you’re suggesting will definitely affect code right now - since they are definitely require-macros
and using the same ns names
I know I can’t know what naming conventions people use for their own stuff.. But I still don’t predict this would have such an impact as you’re saying. I’m probably still missing something
like, if we auto-refer those macros, doesn’t it only affect that same namespace?
and I would say most people are referring those macros anyway, just like we do here https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L4
I agree that it might not be a problem - but it’s probably not worth doing because we don’t know and it will affect many programs
yeah I’m fine about the way it works today. Just thought it would be interesting to bring up, my point of view is it would be another step in bridging the gap between Clojure and ClojureScript - and I like those kinds of enhancements 🙂
sure, but I don’t like changes where we obviously can’t know all the downstream effects 🙂
Wrt compiler flags I kinda feel we have too many of those already
but we could always add one for people to test it in their own projects and remove it if it turns out to work?
or not remove it, just make it the default
I see. that sounds like something to think about
that could also bear fruits without impacting stability
@dnolen btw I don’t think I ever reported back, but sometime ago I started working on warning about private var usages, and I feel like we can never introduce that
or it would also have to be something we introduce behind a flag so that people can incrementally migrate
it would also be a huge patch as we use so many private things internally as well 🙂
anyway, probably time to get back to work, thanks for the discussion
@anmonteiro pretty much why we still don’t have that 🙂