This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-16
Channels
- # aws-lambda (1)
- # bangalore-clj (2)
- # beginners (121)
- # boot (23)
- # cljs-dev (165)
- # cljsrn (8)
- # clojars (2)
- # clojure (164)
- # clojure-berlin (6)
- # clojure-chicago (3)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-russia (4)
- # clojure-serbia (32)
- # clojure-sg (1)
- # clojure-spec (8)
- # clojure-uk (55)
- # clojurescript (94)
- # cursive (21)
- # datomic (30)
- # events (1)
- # hoplon (6)
- # jobs (1)
- # keechma (1)
- # liberator (2)
- # luminus (8)
- # off-topic (48)
- # om (12)
- # onyx (24)
- # parinfer (15)
- # pedestal (8)
- # re-frame (4)
- # sql (18)
- # test-check (31)
- # unrepl (70)
- # untangled (21)
In bootstrap, when at the repl, one can’t require a namespace fully created through the repl. The minimal test case is:
cljs.user=> (require ‘cljs.user)
No such namespace: cljs.user, could not locate cljs/user.cljs, cljs/user.cljc, or Closure namespace “cljs.user”
@cgrand ^ this might be the same as https://dev.clojure.org/jira/browse/CLJS-1473
How do I run the tests in src/test/clojure/cljs
? In particular cljs.compiler-tests
. Currently running from the REPL.
@mfikes thanks I somehow missed it while reviewing the existing issues. Definitely similar. I haven’t traced the code enough to know if they depend on the same codepaths (`cljs.js/*loaded*` is quite specific to bootstrap)
@rauh Not sure if you’ve seen https://clojurescript.org/community/running-tests
@mfikes Thanks, hadn't actually seen that. For some reason I was looking for something in ./scripts/
@mfikes plus (defmacro ...)
at the REPL won’t ever (for reasonable values of “ever”) work in “regular” cljs, while in bootstrap....
@cgrand Right. I documented what I know here: http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html If you find more, please share 🙂
wild idea: when defmacro
in a non $macros
ns, create the ns on the fly and with a ns obj which has the non-macro ns obj as prototype.
I think there is a strong desire to preserve semantics between bootstrap and regular JVM ClojureScript. (Otherwise there is essentially a fork where codebases target either.) We know, for subtle edge cases, this has already occurred already anyway. What I find philosophically interesting is that ClojureScript lets you turn the knob to two extremes: - The AoT compilation model, massive code minimization, DCE, etc., all geared towards the browser use case. - A dynamic self-hosted model, where code size is not as important, More like Clojure and classic Lisp I actually target non-browsers more (with iOS work, and Planck), the first model is not so important to me, and I almost feel like it is an unfortunate premature optimization that could not be avoided
Inconsistent resolution
cljs.user$macros=> foo
WARNING: Use of undeclared Var cljs.user$macros/foo at line 1
nil
cljs.user$macros=> `foo
cljs.user/foo
While the above is true, I think it is generally OK and matches what happens in JVM ClojureScript for a lot of code: foo
could refer to a Var in the Clojure (maybe it is a Clojure function defined in the same namespace and called during macroexpansion). If you syntax quote, it is oftentimes used to generate code that refers to Vars in the runtime namespace. But, IIRC, cljs.user/foo
could resolve to a Var in the macro namespace if one is there. (Corner cases abound.)
This ticket is related to the above as well https://dev.clojure.org/jira/browse/CLJS-1773
@rauh going through a bunch of tickets w/ patches today and I see you have a few - your name still isn’t showing up on the Contributor list, you said you sent in your CA right? What name did you use?
No, hang on
@dnolen I can confirm we have Andre's CA
@alexmiller thanks!
We got it on May 20 but I think it's been a while since they've been updated
Usually it happens about once a week but I think we are behind
@rauh I’ve bumped your JIRA permissions, you should be able to freely edit tickets now
If you use ClojureScript + Node.js please try this patch and report on the ticket https://dev.clojure.org/jira/browse/CLJS-1990
this fix looked good to me but probably should probably test your projects with master https://github.com/clojure/clojurescript/commit/64f126f136270492555b5afe5a6947646a36bdc4
Just added a patch and a few test in https://dev.clojure.org/jira/browse/CLJS-2046 . Would appreciate if somebody could take a quick look/review. (My first real excursion into the analyzer)
(Prerequestite for https://dev.clojure.org/jira/browse/CLJS-2041 which avoids .call(null ...)
constructs)
@anmonteiro seems to me this old ticket is resolved? https://dev.clojure.org/jira/browse/CLJS-1914
@mfikes I thought we supported ^:const
pattern but I can’t remember where we make this work?
and means you can't really use a case
with symbols w/o having knowledge about the surrounding context
Yeah, it is unfortunately one of the things listed here https://clojurescript.org/about/differences#_special_forms
@mfikes well let’s set aside case
for now 🙂 so we don’t have generalized ^:const
support right?
The only two specific effects of ^:const
are re-def and case
. Nothing generalized that I can think of.
I think the only limitation of Clojure ^:const
is that the value must be a EDN literal correct?
“Clojure Programming”, pg. 200 says “any references to a constant var that aren’t resolved at runtime (as per usual); rather, the value held by the var is retained permanently by the code referring to the var when it is compiled”
https://dev.clojure.org/jira/browse/CLJS-1965 this is a pretty simple looking enhancement, worth testing out
breaking for a bit of lunch, if there’s any ticket + patch you will like to see get pushed through let me know
I think https://dev.clojure.org/jira/browse/CLJS-2030 still applies cleanly.
@dnolen I think I’ve solved something similar in Lumo recently, mind if I assign this to myself? https://dev.clojure.org/jira/browse/CLJS-1959
@dnolen I think this needs to be reverted or revised https://github.com/clojure/clojurescript/commit/bb56fb4a6101e16a7ba072dc0b3d6bd6a2ed2373
it’s a breaking change for people who’ve started using the shorthands you introduced (e.g. :es5
, :es6
)
@anmonteiro I think str/replace
takes care of that, no?
ooops
didn’t see that, sorry
sorry for the noise
@anmonteiro yeah I was confused by that too 🙂
A string?
assertion is triggering for me with the unit tests (perhaps the recently added one for CLJS-1891, but I haven’t isolated it yet)
^ fixable with patch attached to https://dev.clojure.org/jira/browse/CLJS-2094
@anmonteiro I think that CLJS-1959 should piggieback on ^:const
inlining?
@dnolen I think they’re unrelated and we could achieve it by changing how we bootstrap node
@mfikes this doesn’t seem that important https://dev.clojure.org/jira/secure/attachment/15564/CLJS-1601.patch?
@mfikes I think you fixed this one https://dev.clojure.org/jira/browse/CLJS-1625
@dnolen I don't know on CLJS-1601. I believe Nikita converted Quil to to support bootstrapped and perhaps he came up with a use case where it matters.
On CLJS-1625, I did have that recent perf optimization https://dev.clojure.org/jira/browse/CLJS-2066 that does smell awfully similar. I'll see if I can confirm whether they ended up being the same.
@rauh I’m going to close https://dev.clojure.org/jira/browse/CLJS-2041 unless you can show that CLJS-1630 is covered
I’m pretty sure we need absolutely need .call
for users who want to make JS primitives callable
@dnolen Please don't close yet. I really don't see how .call
is needed. I don't understand CLJS-1630.
@mfikes https://dev.clojure.org/jira/browse/CLJS-797 seems like maybe you fixed this?
Ahh, right. Yes the 2^n thing with for
loops was at analysis time.
It would be interesting if anyone had access to Android Chrome to repro
https://dev.clojure.org/jira/browse/CLJS-2095, low hanging fruit for someone 🙂 Nashorn runner
(for [a [[[[[[[1]]]]]]]]
(for [b a]
(for [c b]
(for [d c]
(for [e d]
(for [f e]
(for [g f]
g)))))))
@dnolen I stand by my opinion that the .call
is not needed. I'll comment on the tickets with a longer response.
An interesting side finding that might need clarification:
1. If I extend-protocol
not-native or native, and specify some IFn
, let's say arity 0, at some point and then later at some other point
2. Again extend-protocol
the same type, with let's say arity1, then the prototype has both IFn
for arity 0 and 1, but the .call
method will ONLY be able to handle the latter defined one. So they diverged 😕
@dnolen just updated https://dev.clojure.org/jira/browse/CLJS-1959 with a patch
^ I’m almost certain this covers the Node.js behavior for setting __dirname
and __filename
this is something that has been on my mind for a while since you refactored the way we bootstrap Node.js
@anmonteiro ok that looks great, I tried something like that but I had trouble getting it to work with :npm-deps
trying to run clojurescript compiler tests after a while via ./scripts/test
and getting Unable to find static field: FUNCTION_PARAMS in class com.google.javascript.jscomp.DiagnosticGroups, compiling:(cljs/closure.clj:101:1)
@anmonteiro + lineOffset: 0,
should be 1
in your CLJS-1959
patch
Looks like clojure removes previously defined arities of the protocol:
(defprotocol Foo (foo [a] [a b]))
(extend-type Keyword Foo (foo [a] 0))
(extend-type Keyword Foo (foo [a b] 1))
(foo :a) ;; Error
Strictly cljs should then clear all other arities for correctness, but I don't think anybody wants that code emitted every time extending multi arity protocols. So I vote to ignore this issue.@dnolen https://dev.clojure.org/jira/browse/CLJS-2042 should also be low risk. Also applies cleanly
@thheller I’m not adding a new line
oh you said it
sorry…
@dnolen I think I’m getting some weird failures with :npm-deps
, nice catch
investigating
@anmonteiro yeah I burned a lot of time on it - my experience was that Google Closure compiled modules is fundamentally at odds with Node style CommonJS modules
yeah.. Closure expects global scope to be available
or rather… local scope
it might be possible to work around it by using eval
instead of vm.runInThisContext
but I’m not sure how that would play with source maps
@anmonteiro I wrote this mostly as a reminder for myself, but it works around the issues you are seeing maybe https://github.com/thheller/shadow-build/blob/master/doc/node.md
let me have a look
reading it now
that’s an interesting read, but doesn’t seem like something we could do easily
very different from the CLJS bootstrap but it solved all the issues I had so I’m happy with it 😉
@anmonteiro like I alluded I don’t really see the point
I agree
I’m gonna play with it a little bit more if that works for you
but I’ll probably just adopt the magical globals approach 🙂
I’ve been a bit lazy about organizing tickets around releases, moving forward would be nice to be bit more rigorous about it
actually got some of my own compiler hacking in today 🙂 https://github.com/clojure/clojurescript/commit/a399958cf758a184c0e07cd84bd077c5dceb1a3f