This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-16
Channels
- # alda (1)
- # aws-lambda (1)
- # bangalore-clj (1)
- # beginners (70)
- # boot (24)
- # cider (1)
- # cljs-dev (167)
- # cljsjs (8)
- # cljsrn (17)
- # clojure (224)
- # clojure-android (7)
- # clojure-austin (8)
- # clojure-russia (17)
- # clojure-spec (120)
- # clojure-uk (46)
- # clojurescript (68)
- # community-development (198)
- # conf-proposals (1)
- # core-async (7)
- # cursive (6)
- # datomic (27)
- # dirac (19)
- # events (9)
- # hoplon (2)
- # jobs (1)
- # luminus (9)
- # off-topic (1)
- # om (281)
- # om-next (5)
- # onyx (50)
- # pedestal (1)
- # re-frame (19)
- # reagent (11)
- # ring-swagger (14)
- # slack-help (2)
- # spacemacs (1)
- # untangled (72)
- # yada (30)
for your information https://github.com/rollup/rollup/issues/949
I know similar stuff is being done in the closure compiler, but this seemed like an interesting vector to explore regardless
@plexus can you say a bit more on what that ticket is about? I’m familiar with Rollup but I don’t see how it could help ClojureScript more broadly
This way we could package any lib that uses rollup as a closure library, so cljsjs or similar efforts don't need to deal with externs, modules can be referenced without js/
@dnolen essentially it approaches the module conversion issue at a different spot: GCC vs. Rollup
at first glance it just seems like moving the CLJSJS tradeoff (we have to curate) to Rollup (we have to curate)
It's not "the solution" but might be a neat immediate step compared to :foreign-libs
. Finalizers seem relatively easy to write. Also it might increase Closure popularity in JS which we'd benefit from I guess. (re: easy to write https://gist.github.com/plexus/e3971543bce8840f2e076bbefeec5016)
@martinklepsch hrm I’m not following the later statement, are you saying rollup would allow people to consume Closure modules?
It think issue proposes that rollup would output Closure modules
@dnolen No but rollup could make it easier to produce Closure compatible code, which might be a nudge in the direction of using GCC.js
@anmonteiro somehow this one still needs to be rebased 🙂
@dnolen so yes, and it’s what has been done before
ahaha, sure
let me take care of that
@dnolen probably because of a lot of trailing whitespace in core.cljs
oh no, I see it now, it’s the tests at the end of the file
@dnolen replaced attachment with rebased one
@dnolen re: something for you to look at 🙂 http://dev.clojure.org/jira/browse/CLJS-1600 http://dev.clojure.org/jira/browse/CLJS-1633 http://dev.clojure.org/jira/browse/CLJS-1335 http://dev.clojure.org/jira/browse/CLJS-1536
I think that covers mine
@anmonteiro the first one, there’s no test that destructuring actually works
@dnolen you’re right, I’ll add some
@dnolen attached CLJS-1600-3.patch to that ticket with more tests + rebased
@anmonteiro for the last one 1536, does ((let [x 1] (defn x [] x)))
work for you?
@dnolen I can probably include that test case
trying it out now
@dnolen hrm doesn’t seem to be working
cljs.user=> (let [x 1] (defn x [] x))
#'cljs.user/x
cljs.user=> (x)
#object[cljs$user$x "function cljs$user$x(){
return cljs$user$x;
}"]
invoking x should return 1, I suppose?
@dnolen right because then the function body can’t see x = 1
?
@dnolen ?
Clojure 1.8.0
user=> ((let [x 1] (defn x [] x)))
1
I’m not sure what to expect anymore 😄
@dnolen I can see that ((defn x [] x))
works fine
it returns the function
yeah, I get the weirdness now
maybe it deserves an issue in the Clojure JIRA and following up on the CLJS issue?
@dnolen sorry that deserved it ^
that makes sense to me
I wonder what it means for CLJS
@anmonteiro so I think the only thing is that in parse ‘def
case we need to swap!
the compiler environment with what we know before we analyze the init-expr
@dnolen so ((let [x 1] (defn x [] x)))
should definitely return 1 as in Clojure
that wasn’t very clear to me, it is now
@mfikes http://dev.clojure.org/jira/browse/CLJS-1715?focusedCommentId=43884#comment-43884
@dnolen I think item (1) in that ticket is probably the one case I’m aware of that the $macros
fix doesn’t do anything to resolve, while item (2) may very well be an example that is subsumed. (too bad I conflated two items in one ticket). If you want you could kick it back to me for further investigation
@dnolen re: cljs-1536
don’t we already swap!
before we analyze?
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1207
hrm I might have seen that somewhere, maybe in core.cljc
?
looking at that rn
@anmonteiro I don’t think this particular fubar is in core.cljc
after a quick review
I meant looking at the analyzer
I had already ruled core.cljc
out, sorry miscommunication
@dnolen found the culprit https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1387
or so I think
@anmonteiro need to be careful here
@dnolen might be tricky because the fn
macro is imported from Clojure
@anmonteiro I don’t think so
right I might just not have the full picture
ahhh gotcha
yeah that’s right because we ruled out earlier that we don’t do fn foo
whenever we fn
@dnolen attached CLJS-1536-2.patch
it seems we need both fixes, the one I did before (`(dissoc env :locals)`) and this parse ‘fn*
one
let me know if anything still doesn’t look quite right
so the implementation seems a bit strange to me (but I’m not sure what you tried to get here)
by strange only because the implementation doesn’t really a give a clue to the semantics
@dnolen do you mean the shadow?
naming
they solve different problems
one for the def
, one for the defn
lets set aside your current implementation for now, so I can explain how I think it should work
let’s do it
oh wow. now that you said it, it seems I took the long way
@dnolen it does seem that (dissoc env :locals)
is still needed for the (let [x 1] (def x x))
case
but that’s a whole different case if I understand correctly
I understood it when I worked on this a month ago. can’t seem to remember now
I’ll dig in again
@dnolen ah right. so the problem is here: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1012
for the (let [x 1] (def x x))
case, you want to get the var’s AST, but the x
local is shadowing it
so resolve-var
will return the local instead
so the solution is to either dissoc
locals or to change resolve-var
@anmonteiro oh bam
@anmonteiro ok, we need a comment in var-ast
about this, a couple sentences at least 🙂
definitely
awesome, glad we’re on the same page now
or rather, that I actually understand things now 🙂
@dnolen btw, because :def-emits-var
is only true
for REPLs, my test case in core-test.cljs
doesn’t really fail without the fix
but I have one that fails when running lein test
so it’s all good
@anmonteiro sweet thanks!
@dnolen attached CLJS-1536-3.patch
thanks for all the help
well it’s a lot of nitty gritty stuff there