This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (1)
- # bangalore-clj (2)
- # beginners (121)
- # boot (23)
- # cljs-dev (165)
- # cljsrn (3)
- # clojars (2)
- # clojure (171)
- # 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 (57)
- # clojurescript (93)
- # cursive (21)
- # datomic (30)
- # events (1)
- # hoplon (6)
- # jobs (1)
- # keechma (1)
- # liberator (2)
- # luminus (8)
- # off-topic (48)
- # om (10)
- # onyx (24)
- # parinfer (15)
- # pedestal (4)
- # re-frame (4)
- # reagent (2)
- # sql (18)
- # test-check (31)
- # unrepl (72)
- # 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”
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)
@mfikes Thanks, hadn't actually seen that. For some reason I was looking for something in
(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 :slightly_smiling_face:
I’m updating that post:
(defmacro ...) now returns the macro var :slightly_smiling_face:
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
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?
@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 :slightly_smiling_face: 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
@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.
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)
@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?
@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.
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 :slightly_smiling_face: Nashorn runner
(for [a [[[[[[]]]]]]] (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
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 :confused:
^ I’m almost certain this covers the Node.js behavior for setting
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
trying to run clojurescript compiler tests after a while via
./scripts/test and getting
Looks like clojure removes previously defined arities of the protocol:
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.
(defprotocol Foo (foo [a] [a b])) (extend-type Keyword Foo (foo [a] 0)) (extend-type Keyword Foo (foo [a b] 1)) (foo :a) ;; Error
@dnolen https://dev.clojure.org/jira/browse/CLJS-2042 should also be low risk. Also applies cleanly
@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
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
very different from the CLJS bootstrap but it solved all the issues I had so I’m happy with it :wink:
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 :slightly_smiling_face: https://github.com/clojure/clojurescript/commit/a399958cf758a184c0e07cd84bd077c5dceb1a3f