This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-28
Channels
- # admin-announcements (4)
- # beginners (11)
- # boot (148)
- # cider (74)
- # cljs-dev (31)
- # cljsrn (30)
- # clojure (55)
- # clojure-berlin (15)
- # clojure-greece (1)
- # clojure-japan (18)
- # clojure-poland (35)
- # clojure-russia (72)
- # clojure-spec (35)
- # clojure-uk (34)
- # clojurescript (134)
- # cursive (26)
- # datomic (42)
- # dirac (7)
- # editors-rus (1)
- # emacs (17)
- # hoplon (29)
- # jobs-rus (3)
- # juxt (1)
- # luminus (11)
- # off-topic (9)
- # om (66)
- # onyx (49)
- # pedestal (1)
- # perun (19)
- # proton (13)
- # protorepl (5)
- # re-frame (31)
- # reagent (13)
- # ring (2)
- # spacemacs (1)
- # specter (40)
- # spirituality-ethics (2)
- # test-check (41)
- # untangled (7)
- # yada (17)
Is it a bug that adding a jsdoc comment "@param {string} login-name”
fails an advanced build?
WARNING - Parse error. invalid param name "login-name"
* @param {string} login-name
^
It looks like the param should be login_name
Probably early days, but has there been any thought about extending spec with jsdoc? https://github.com/clojure/clojurescript/wiki/Compile-Time-Type-Checking
@danielcompton: I’ve thought about it, but yes too early to seriously consider it for now
@danielcompton: yes we don’t auto-munge parameter names so that won’t work
should I open a bug for that munging param names?
@danielcompton: that stuff is way up in the air for now
hrm I thinking about dropping the double analysis of forms in REPLs, I think people mentioned this before that it interacts badly with macroexpansion in the presence of side effects
but I’m thinking about removing the first analysis which is just used for generated unwrapped js when we throw an exception
which far as I can tell is just an old debugging tool that’s really primarily useful for compiler hackers not users
@dnolen: Double analysis (evaluation really) occurs with :repl-verbose
. Trying to recall where it otherwise occurs.
@dnolen Ahh, you said “unwrapped js”. Yes, we are essentially talking about the same thing.
Thinking about essentially dropping this line, which has bad side effects: https://github.com/clojure/clojurescript/blob/8643c554e7164df4d74d3f71d576df9848b2e363/src/main/clojure/cljs/repl.cljc#L455
we do need to use ast
below to see if we have a :ns
node which we can't see directly with wrap-js
It is tempting to generate the “clean” ast
once, and then patch it up manually to add all the things needed for the REPL (`:def-emits-var`, the effects of wrapping for *1
, *2
, and whatever effects :repl-env
) without doing macroexpansion again. Sounds like that would be very difficult to pull off cleanly. Ugh… tough problem.
One philosophical stance to take is indeed: Eschew exposing JavaScript in the REPL in general. Deprecate :repl-verbose
(or allow the truth to show through if you really want it). Don’t include JavaScript in exceptions, etc.
Just FYI: I just ran the main ClojureScript tests on ChakraCore on OS X. All tests passed. (10x-15x slower than jsc and v8)
people might want to give this one a spin https://github.com/clojure/clojurescript/commit/8524d7b1ac7c1c418ec394e89322e341070414ca
just FYI: getting this warning about cljs.spec when compiling code with advanced
on 1.9.89
WARNING: analyzer.js:4278: WARNING - incomplete alias created for namespace cljs.spec
var mchk = (function (){var and__7137__auto__ = cljs.spec;